祝賀SQL版現在高手云聚﹐開個擂台賽如何﹖有問題直管進來﹐1個小時內解決。

magicangel

最初由 Northwindrocker 发布
[B]SQL数据库运行时间长了数据库的LOG增长很快，一段时间后LOG文件达到难以忍受的大，不知各位大侠有什么好的办法？ [/B]

http://www.itpub.net/showthread.php?s=&threadid=157380

zhangjam

由于需要解决死锁问题，想知道引起死锁的具体代码，所以查看 联机帮助，里面提到的使用跟踪标记1204让我很感兴趣，但是苦恼的是，水平不够，不知道如何使用dbcc traceon (1204) 之后如何让死锁的具体信息体现呢？苦恼中，帮帮我

xzh2000

最初由 zhangjam 发布
[B]由于需要解决死锁问题，想知道引起死锁的具体代码，所以查看 联机帮助，里面提到的使用跟踪标记1204让我很感兴趣，但是苦恼的是，水平不够，不知道如何使用dbcc traceon (1204) 之后如何让死锁的具体信息体现呢？苦恼中，帮帮我 [/B]

         你歷害﹐這個問題有點難度﹐主要沒有辦法知道
到底是那條SQL引起了LOCK。

Northwindrocker

quote:
--------------------------------------------------------------------------------
最初由 Northwindrocker 发布
SQL数据库运行时间长了数据库的LOG增长很快，一段时间后LOG文件达到难以忍受的大，不知各位大侠有什么好的办法？
--------------------------------------------------------------------------------



ALTER DATABASE PUBS WITH NO_LOG
ALTER DATABASE PUBS WITH TRUNCATE_ONLY
以上兩個都可以﹐然后再使用DBCC 來收縮數據庫即可。


我一般用backup  database with no_log 很不错 的方法！

chencms

各位大侠，好！
我的服务器是两台服务器作的群集系统，操作系统是微软的advanced server，数据库采用微软的2000企业版，当数据库日志文件达到100多兆时，客户端软件保存数据时（一次更新一条纪录，字段较多，先检索表中最大的单据号，然后加1形成新的插入纪录的单据号）有时出现时间延迟现象（一天大约5，6次吧）（两台计算机同时操作时不定出现，但是一台计算机操作却有时出现延迟），但是采用微软公司给的阻塞监测软件却监测不出来，长的大约5，6秒，只有三个客户端。当把数据库日志截断后，保存数据的延迟就不出现了，但是一旦达到100多兆，就继续出现。从日志截断后，大约5天时间，日志就达到100多兆。系统每天作一次全备份，两次增量备份。

wanqingjian

在数据库还原的过程（还没有完成）停止还原之后，在企业管理器中看见刚才要还原的数据库状态呈灰色，显示“正在装载”，无项目。能不能恢复数据库到还原前的数据状态（数据文件和日志文件还在）？请高手指教，急！！！

xzh2000

這要采用時間點還原。

wanqingjian

请问 XZH2000，怎样用时间点还原呢，我这里可没有事务日志的备份呀，简单化就是说，能不能根据日志文件还原到原来的状态呢？

xzh2000

最初由 wanqingjian 发布
[B]请问 XZH2000，怎样用时间点还原呢，我这里可没有事务日志的备份呀，简单化就是说，能不能根据日志文件还原到原来的状态呢？ [/B]

   
          哦﹐那你只有完全恢復啦。

zhangjam

最初由 xzh2000 发布
[B]

         你歷害﹐這個問題有點難度﹐主要沒有辦法知道
到底是那條SQL引起了LOCK。 [/B]

经过“专家”指导，终于找到了查找死锁问题（具体引起死锁的SQL语句）的好办法，不敢独享，愿意拿出来和各位共享，至于老鸟级人物（如斑竹），欢迎指正：
1。创造死锁环境：
开两个SQL 查询分析窗口，一个执行下面的语句：
begin transaction
    update pub..a set columna= '12'
    waitfor delay '00:00:01'
    update pub..b set columnb= '12'
commit transaction
另一个执行下面的语句：
begin transaction
    update pub..b set columnb= '12'
    update pub..a set columna= '12'
commit transaction
执行第一个，未完成马上执行第二个，死锁就出现了：
事务（进程 ID  58）与另一个进程已被死锁在  lock 资源上，且该事务已被选作死锁牺牲品。请重新运行该事务。
2。跟踪：
－－方法一：使用 DBCC TRACEON 设置跟踪标记
DBCC TRACEON (1204)
－－方法二：在命令提示符下设置跟踪标记
sqlservr –d"C:\Program Files\Microsoft SQL Server\MSSQL\Data\master.mdf" –T1204
备注：1204－－返回参与死锁的锁的类型以及当前受影响的命令。
3。查看跟踪结果：
打开errorlog文件，可以看到下面的结果

Deadlock encountered .... Printing deadlock information
2003-11-28 09:34:07.25 spid4
2003-11-28 09:34:07.25 spid4     Wait-for graph
2003-11-28 09:34:07.25 spid4
2003-11-28 09:34:07.25 spid4     Node:1
2003-11-28 09:34:07.25 spid4     RID: 10:1:208:0                CleanCnt:1 Mode: X Flags: 0x2
2003-11-28 09:34:07.25 spid4      Grant List 0::
2003-11-28 09:34:07.25 spid4        Owner:0x19183280 Mode: X        Flg:0x0 Ref:0 Life:02000000 SPID:60 ECID:0
2003-11-28 09:34:07.25 spid4        SPID: 60 ECID: 0 Statement Type: UPDATE Line #: 1
2003-11-28 09:34:07.25 spid4        Input Buf: Language Event: begin transaction
    update pub..b set columnb= '12'
    update pub..a set columna= '12'
commit transaction



begin transaction
    update fil2k..a set company_name = '12'
    waitfor delay '00:00:01'
    update fil2k..b set c
2003-11-28 09:34:07.25 spid4      Requested By:
2003-11-28 09:34:07.25 spid4        ResType:LockOwner Stype:'OR' Mode: U SPID:58 ECID:0 Ec0x19E29500) Value:0x1917f360 Cost0/54)
2003-11-28 09:34:07.25 spid4
2003-11-28 09:34:07.25 spid4     Node:2
2003-11-28 09:34:07.25 spid4     RID: 10:1:189:0                CleanCnt:1 Mode: X Flags: 0x2
2003-11-28 09:34:07.25 spid4      Grant List 0::
2003-11-28 09:34:07.25 spid4        Owner:0x1917f340 Mode: X        Flg:0x0 Ref:0 Life:02000000 SPID:58 ECID:0
2003-11-28 09:34:07.25 spid4        SPID: 58 ECID: 0 Statement Type: UPDATE Line #: 1
2003-11-28 09:34:07.25 spid4        Input Buf: Language Event: begin transaction
    update pub..a set columna= '12'
    waitfor delay '00:00:01'
    update pub..b set columnb= '12'
commit transaction

2003-11-28 09:34:07.25 spid4      Requested By:
2003-11-28 09:34:07.25 spid4        ResType:LockOwner Stype:'OR' Mode: U SPID:60 ECID:0 Ec0x19E49500) Value:0x191832c0 Cost0/54)
2003-11-28 09:34:07.25 spid4     Victim Resource Owner:
2003-11-28 09:34:07.25 spid4      ResType:LockOwner Stype:'OR' Mode: U SPID:60 ECID:0 Ec0x19E49500) Value:0x191832c0 Cost0/54)