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

  • 问题

  • 用日志传送方式同步数据库,并且设置成从库(可读还原状态)时,当有连接连到从库的还原库做select查询时从库是不能做还原的对不对?
    2013年7月12日 5:35

答案

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

    2013年7月12日 10:45
  • 在设置Log shipping的时候是有一个选项的,可以选择还原的时候断开连接的。


    Please Mark As Answer if it is helpful.

    2013年7月12日 11:39
  • 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中的复选框勾选则当日志恢复的时候,
    --断开所有用户的连接,如果有一个用户没有断开,则还原无法进行。就是当有用户读取备库的时候,这些用户
    --连接都要断开,不是说主库的用户连接要断开

    2013年7月12日 13:34

全部回复

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


    Please Mark As Answer if it is helpful.

    2013年7月12日 9:09
  • 如何选择?,类似:

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


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

    2013年7月12日 10:45
  • 在设置Log shipping的时候是有一个选项的,可以选择还原的时候断开连接的。


    Please Mark As Answer if it is helpful.

    2013年7月12日 11:39
  • What kind of connection you like to use on secondary server? Disconnect it may cause problem on user side.
    2013年7月12日 12:55
  • 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中的复选框勾选则当日志恢复的时候,
    --断开所有用户的连接,如果有一个用户没有断开,则还原无法进行。就是当有用户读取备库的时候,这些用户
    --连接都要断开,不是说主库的用户连接要断开

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

    比如以下脚本:

    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

    2013年7月12日 15:40
  • 当然要断开,不断开还原不了的
    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您的简单一些
    2013年7月12日 15:49
  • You still have to kill connection if someone get on db before restoring log.
    2013年7月12日 16:53
  • 就是在restoring log.之前执行这个脚本啊
    2013年7月12日 17:39
  • User can still connect to db even it's in single user mode.
    2013年7月12日 18:35
  • 都这个年代了,使用2008的镜像代替LOG SHIP吧

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


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2013年7月15日 0:47