create snapshot db 和drop snapshot db一般来说 是很快的一个过程 只要几秒就可以完成。。但是最近客户发现有1次 create/drop snapshot 很久才跑完。我重现不了这个问题。。请求各位大侠支招--create snapshot和drop snapshot示例代码如下
USE [master]
IF EXISTS (SELECT name FROM sys.databases WHERE name = 'TestDBSnapShot')
DROP DATABASE [TestDBSnapShot]
GO
CREATE DATABASE [TestDBSnapShot] ON
(NAME = TestDB, FILENAME = 'E:\test\TestDB.ss') AS SNAPSHOT OF TestDB
GO什么情况下上述这段代码会被执行很长时间(比如半小时,甚至更久)?以下几个方法尝试了下都不行:
1.TestDB中有事务,使得TestDB被阻塞,然后运行上述代码,但是TestDBSnapShot仍能够成功创建,只是数据是TestDB中没有commit的
2.在TestDBSnapShot进行select 查询,一旦执行上述代码,则查询snapshot上的查询中断,create/drop snapshot 仍能够执行成功。
3.把磁盘刷爆,没有存储空间,create snapshot直接失败,不是进入阻塞状态。

解决方案 »

  1.   

    查一下create/drop snapshot进程(session)的等待类型(waittype)是什么?
      

  2.   

    我现在无法去看 事件查看器等等。。因为这个是客户1个月前左右反馈过来的,现在要去研究这个问题是如何出现的。。 我想在本机重现这个问题。。 
    用以下语句查询 只要有 blocking_session_id 就说明有阻塞drop/create snapshot的session存在SELECT blocking_session_id
    FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(sql_handle) q
    WHERE r.session_id > 50
    AND r.session_id <> @@SPID
    AND r.blocking_session_id > 0
    AND (
    CHARINDEX('AS SNAPSHOT OF TestDB',q.text)>0
    OR
    CHARINDEX('DROP DATABASE TestDBSnapShot',q.text)>0
    );
      

  3.   


    磁盘在创建snapshot的时候有别的写入操作。写等待中... 也可以造成这样的状况。
    不过snapshot的db一般都不大,用不了半个钟头吧。 LZ建个跟踪监控一下吧。 同时建立一个磁盘性能监视器,看看磁盘当时的性能有变化没有。 无非硬件或者软件,先排除一端,再看看另一端。