数据库事务日志空间已满，但不能截断日志

zhangdonglin

转载自CUer的几个帖子！

***********************************************
有两种情况，可能出现这个问题。一是应用系统给SQL Server发送了一个用户自定义事务，一直未提交，这个最早活跃事务阻碍系统截断日志。二是客户端向SQL Server发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务结束后，才能被截掉。
　　对于第一种情况，只要督促用户退出应用或者提交事务，系统管理员便可清掉日志。因为给SQL Server发送Dump transaction with no-log或者with truncate-only，它截掉事务日志的非活跃部分。所谓非活跃部分是指服务器检查点之间的所有已提交或回退的事务。而从最早的未提交的事务到最近的日志记录之间的事务日志记录被称为活跃的。从此可以看明，打开的事务能致使日志上涨，因为在最早活跃事务之后的日志不能被截除。
　　对于第二种情况，道理也同上。只是在处理它时，需慎重从事。如果这个大事务已运行较长时间，应尽量想法扩大数据库日志空间，保证该事务正常结束。若该事务被强行回滚，SQL Server需要做大量的处理工作，往往是正向执行时间的几倍，系统恢复时间长，可能会影响正常使用的时间。
***********************************************
如果出现提交了一个大的事务把整个日志库填满了，这时无论你怎么截断日志都是徒劳时，可以有三种办法解决：
1.重启数据库（最笨的但最有效的），但肯定会有REDO和UNDO恢
  复时间长。
2.给数据库日志加空间，但必须有足够的空间。
3.找出执行大事物SESSION的ID，KILL它，但也会回滚，而且不
  定可以KILL得掉。

***********************************************
对于第1个方法，可否直接修改sysdatabases里的status设为-32768,然后再进入数据库dump tran dbname with truncate_only,然后再重启把status设为0。这样的话，可以不用等待redo和undo的时间，这种方法有时会造成数据库数据不一致。

***********************************************
在排除了硬件故障的前提下，Adaptive Server能够启动，但是应用系统不能操作，许多情况下都是由于应用系统数据库日志太慢了，一般在这种情况下使用dump tran dbname with truncate_only就可以解决问题了，但是有时日志满得出了问题，如以下从errorlog文件片断中显示的那样：
server  Database 'sybsystemprocs' is now online.
server  Recovering database 'testdb'.
server  Redo pass: 6000 records done (11%); 47493 records left.
server  Redo pass: 48000 records done (89%); 5493 records left.
server  Redo pass of recovery has processed 787 committed and 44 aborted transactions.
server  Error: 1105, Severity: 17, State: 3
server  Can't allocate space for object 'syslogs' in database 'testdb' because 'logsegment' segment is full/has no free extents. If you ran out of space in syslogs, dump the transaction log. Otherwise, use ALTER DATABASE or sp_extendsegment to increase size of the segment.
server  Error: 3475, Severity: 21, State: 7
server  There is no space available in SYSLOGS for process 1 to log a record for which space has been reserved. This process will retry at intervals of one minute. The internal error number is -4.
kernel  shutdownproc: shutting down SQL Server!
server  SQL Server shutdown by request.
业务系统数据库不能正常启动，对于这一类问题，我们按照如下步骤解决：
第一步，启用allow updates to system tables，这样可以使具有系统管理员角色的用户能够改变系统表并可创建和修改系统表的存储过程，其中系统表包括master数据库中所有Sybase提供的表以及用户数据库中所有以“sys”开头的表和在sysobjects表中其ID值小于或等于100的表。系统表的不正确变更会导致数据库损坏和数据丢失，修改系统表时务必要使用begin transaction来保护数据库不受可能损坏数据库的错误影响，完成修改后应立即禁用allow updates to system tables。
1>;sp_configure "allow update",1
第二步，Adaptive Server中的每个数据库在sysdatabases中都有相应的一行，安装Adaptive Server后，master数据库、model数据库、sybsystemprocs和tempdb数据库在sysdatabases中都将有相应的条目，如果已经安装审计功能，sybsecurity数据库也将在其中有相应的条目。修改sysdatabases表，将testdb的状态修改为-32768，然后在关闭Adaptive Server后重新启动Adaptive Server。
1>; update sysdatabases set status=-32768 where name = "testdb"
1>; shutdown
第三步，由于事务日志已经很满，不能使用常规方法转储此事务日志，如果使用了dump transaction或dump transaction with truncate_only命令，而命令又由于日志空间不足失败时，可以使用dump transaction的特殊选项with no_log，此选项可截断事务日志而不记录转储事务事件。所有dump tran with no_log都将在Adaptive Server错误日志中进行报告，这些消息包括执行此命令的用户ID、指示成功或失败的消息，no_log是唯一生成错误日志消息的转储选项。但是这个选项（包括with truncate_only）没有提供任何方法可恢复自从上次例行转储后提交的事务。
1>; use testdb
1>; dump tran testdb with no_log
第四步，修改sysdatabases表，将testdb的状态恢复为0，然后禁用allow updates to system tables。
1>; use master
1>; update sysdatabases set status = 0 where name = "testdb"
1>;sp_configure "allow update",0




本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/13662/showart_145587.html