用dump tran with no_log都无法截断日志时候

lee2223

我的系统是是SUN-solaris8，主机是SUN-v880，SYBASE版本是12.0.在一天的检查中我发现一个库的全部session因为日志挂起，然后检查日志10G全部用完了。为了尽快恢复我用了 dump tran with_log，但居然都无法截断日志。在ERROR.log中发现有库和段空间不足，无法截断日志，请给日志加空间，但我的系统以无空间可加。无奈之下只好重启了SYBASE库，经过了2小时的REDO和UNDO才恢复正常。我的库中打开了checkpoint时截断日志的选项，用的默认值5分钟，库空间为70G，日志为10G。各位大虾为什么如此频繁的截断日志，日志空间还会满，而且为什么用dump tran with no_log都无法截断日志。除了重启之外有没有其他方法解决此问题。

rosehu

应该是你的操作方法不对!

lee2223

操作不对吗？那应该怎么操作，说详细点可以吗？谢谢。

jsxzlj

我也遇到过这种情况，也不知道如何解决，请高手指教!

hawker

比较奇怪的现象，估计是日至段出现问题,你可以用sa来做先面这个dbcc
dbcc rebuild_log(dbid,1,1)
谨记，这个命令很危险，慎用!!!

lee2223

为什么有时候数据库事务日志满了，不能截断日志？

有两种情况，可能出现这个问题。一是应用系统给SQL　Server发送了一个用户自定义事务，一直未提交，这个最早活跃事务阻碍系统截断日志。二是客户端向SQL　Server发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务结束后，才能被截掉。

　　对于第一种情况，只要督促用户退出应用或者提交事务，系统管理员便可清掉日志。因为给SQL　Server发送Dump　transaction　with　no-log或者with　truncate-only，它截掉事务日志的非活跃部分。所谓非活跃部分是指服务器检查点之间的所有已提交或回退的事务。而从最早的未提交的事务到最近的日志记录之间的事务日志记录被称为活跃的。从此可以看明，打开的事务能致使日志上涨，因为在最早活跃事务之后的日志不能被截除。

　　对于第二种情况，道理也同上。只是在处理它时，需慎重从事。如果这个大事务已运行较长时间，应尽量想法扩大数据库日志空间，保证该事务正常结束。若该事务被强行回滚，SQL　Server需要做大量的处理工作，往往是正向执行时间的几倍，系统恢复时间长，可能会影响正常使用的时间。

如果截断时事务没有完成，该事务的日志是不被截断的。比如数据库设置的自动清日志选项，而你提交了一个打的事务把整个日志库填满了，这时无论你怎么截断日志都是徒劳的，你需要其它的处理手段来解决这种问题。这种极端情况还是有可能得，所以，还是要充分估计日志空间的分配！！

lee2223

我仔细分析出问题时的情况，发现当时有一个用户在做delete * from table ，而table中有8000万条数据，使得该操作把日志空间用完而操作还没有做完。因此截断不了日志，只有给日志加空间或是重启。 希望大家以后写SQL时一定要分布提交以免出现类似问题。

Blackrose

能够使用 dump tran 清除掉的只是已经明确提交或者回滚的非活动事务
对于活动事务是不可能清除的

zly0216

1. 关闭数据库:
   isql ---->;  shutdown with nowait

2. 启动数据库, 在到“Recovering database 'DBNAME'”时在master库做下列操作:
   sp_configure "allow"
   sp_configure "allow updates to system tables", 1

   select * from sysdatabases
   update sysdatabases set status=-32768 where name = 'DBNAME'

3. 关闭数据库:
   isql ---->;  shutdown with nowait

4. 启动数据库, 在对DBNAME库做recover时在master库做下列操作:
   dump tran DBNAME with no_log
   update sysdatabases set status=0 where name = 'DBNAME'

5. 关闭数据库; 启动数据库;
   sp_configure "allow updates to system tables", 1
   对可能出错的表做dbcc

-------------------------------------------------------
SELECT COUNT(*) FROM TABLENAME

Server Message:  Number  692, Severity  20
Server 'SYBASEJF', Line 1:
Uninitialized logical page '15259844' was read while accessing object '329976452' in database '4'. Please contact Sybase Technical Support.
-------------------------------------------------------

chuxu

这样处理是很危险的，我曾经做过一次，数据库有问题了。
我觉得还不如重启，然后慢慢等它Recovering