日志传送方式同步数据库问题

Question

用日志传送方式同步数据库，并且设置成从库（可读还原状态）时，当有连接连到从库的还原库做select查询时从库是不能做还原的对不对？

Answer 1

在设置的时候需要可以选择断开当前连接再还原，如果不选这个选项的话，还原可能会失败，因为无法获得独占锁。

---

Please Mark As Answer if it is helpful.

Answer 2

如何选择？，类似：

RESTORE LOG [t] 
FROM  DISK = N'D:\test1.bak' WITH  FILE = 1,  
STANDBY = N'D:\ROLLBACK_UNDO_t.BAK',  NOUNLOAD,  STATS = 10
GO

Answer 3

SELECT 没有结束前不能还原,  还原的进程会报 3101 错误 (还原不会立即出错, 会在等等一段时间之后, 如果还是无法等到 select 结束, 才会出错)

Answer 4

在设置Log shipping的时候是有一个选项的，可以选择还原的时候断开连接的。

---

Please Mark As Answer if it is helpful.

Answer 5

What kind of connection you like to use on secondary server? Disconnect it may cause problem on user side.

Answer 6

with standby

--事务日志模式
--   在设置辅助数据库时，对于恢复事务日志Restore Transaction Log选项卡，我们设定了为No recovery mode，
--   还有一个可供选择的则为Standby mode。在事物日志的传送过程中，
--   恢复事务日志Restore Transaction Log与我们普通的恢复不同，一般情况下的恢复是回滚所有未提交的事务，
--   前滚所有已提交但未写入磁盘的事务。事务日志中，如果一个事务回滚，所有改变的数据将会被丢失，
--   因为在这个时候，你并不知道下一事物究竟是回滚还是提交。故在事务日志传送中提供了No recovery mode和Standby mode，
--   两者的介绍如下：
--1. 无恢复模式(No recovery mode):既不前滚也不回滚未提交的事务，数据不可读。
--2. 备用模式(Standby mode):在恢复日志期间回滚所有未提交的事务，并且将所有未提交的事务保存为一个单独的Transaction Undo File(TUF)文件，
--恢复过程通过该文件来维护事务的完整性，当恢复下一个事物的时候则恢复所有已提交的事务。
--Standby mode中的复选框勾选则当日志恢复的时候，断开所有用户的连接，如果有一个用户没有断开，则还原无法进行。


--辅助服务中hengshan 数据库由restoring显示为standby/read-only模式。如果设定的复制和恢复间隔时间很长，
--可以手动执行主服务器中的backup作业和辅助服务器其中的copy 作业和restore作业，将主服务器上所有未复制的日志文件复制到设定的恢复目录(restorelog)中，
--然后恢复到辅助服务器中。


--同样也可以将Standby mode切换回No recovery mode期间回滚所有未提交的事务，并且将所有未提交的事务
--保存为一个单独的Transaction Undo File(TUF)文件，恢复过程通过该文件来维护事务的完整性，
--当恢复下一个事物的时候则恢复所有已提交的事务。Standby mode中的复选框勾选则当日志恢复的时候，
--断开所有用户的连接，如果有一个用户没有断开，则还原无法进行。就是当有用户读取备库的时候，这些用户
--连接都要断开，不是说主库的用户连接要断开

Answer 7

非常感谢，还有个问题，如果我不是用日志传送的，是自己手动先还原了一个完整备份（状态是只读的），那么如果我再次在这个完整备份的基础上还原一个日志文件的时候，是不是要首先断开所有的连接，并且这个连接要自己写,

比如以下脚本：

USE master
DECLARE @spid int
DECLARE CUR CURSOR
FOR SELECT spid FROM [Master].[dbo].[SYSPROCESSES] WHERE [DBID]
IN(SELECT [DBID] FROM [Master].[dbo].[SYSDATABASES] WHERE NAME='库名')
open CUR
FETCH NEXT FROM CUR INTO @spid
WHILE @@FETCH_STATUS = 0
BEGIN
EXEC ('KILL ' + @spid)
print @spid
FETCH NEXT FROM CUR INTO @spid
END
CLOSE CUR
DEALLOCATE CUR

Answer 8

当然要断开，不断开还原不了的

USE master
 GO
 ALTER DATABASE [GPOSDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
 GO
 --查看是否还有用户连接
 SELECT * FROM sys.[sysprocesses] WHERE DB_NAME([dbid])='gposdb'
 GO
 ALTER DATABASE [GPOSDB] SET MULTI_USER 
 GO

上面断开连接的方法比LZ您的简单一些

Answer 9

You still have to kill connection if someone get on db before restoring log.

Answer 10

就是在restoring log.之前执行这个脚本啊

Answer 11

User can still connect to db even it's in single user mode.

Answer 12

都这个年代了，使用2008的镜像代替LOG SHIP吧

或者，2012的AlwaysOn ，不过听闻说还不够稳定

---

Try SQL Server 2008 QQ:315054403 [e-mail]