Sqlerver数据库/事务日志已满处理办法

一、简单方法

1、右键数据库→属性→选项→故障还原模型→设为简单→确定；
2、右键数据库→所有任务→收缩数据库→确定；
3、右键数据库→属性→选项→故障还原模型→设为大容量日志记录→确定。

二、复杂方法

1、清空日志
DUMP　TRANSACTION　库名　WITH　NO_LOG
2、截断事务日志
BACKUP　LOG　数据库名　WITH　NO_LOG
3、收缩数据库文件(如果不压缩,数据库的文件不会减小)
企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件
--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
--选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
也可以用SQL语句来完成
--收缩数据库
DBCC SHRINKDATABASE(客户资料)
--收缩指定数据文件,

1是文件号,可以通过这个语句查询到:select * from sysfiles DBCC SHRINKFILE(1)

事物日志己满解决办法

如果出现提交了一个大的事务把整个日志库填满了，这时无论你怎么截断日志都是徒劳时，可以有三种办法解决：

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文件片断中显示的那样：

业务系统数据库不能正常启动，对于这一类问题，我们按照如下步骤解决：

第一步，启用allow updates to system tables，这样可以使具有系统管理员角色的用户能够改变系统表并可创建和修改系统表的存储过程，其中系统表包括master数据库中所有Sybase提供的表以及用户数据库中所有以“sys”开头的表和在sysobjects表中其ID值小于或等于100的表。系统表的不正确变更会导致数据库损坏和数据丢失，修改系统表时务必要使用begin transaction来保护数据库不受可能损坏数据库的错误影响，完成修改后应立即禁用allow updates to system tables。

第二步，Adaptive Server中的每个数据库在sysdatabases中都有相应的一行，安装Adaptive Server后，master数据库、model数据库、sybsystemprocs和tempdb数据库在sysdatabases中都将有相应的条目，如果已经安装审计功能，sybsecurity数据库也将在其中有相应的条目。修改sysdatabases表，将testdb的状态修改为-32768，然后在关闭Adaptive Server后重新启动Adaptive Server。

第三步，由于事务日志已经很满，不能使用常规方法转储此事务日志，如果使用了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）没有提供任何方法可恢复自从上次例行转储后提交的事务。

第四步，修改sysdatabases表，将testdb的状态恢复为0，然后禁用allow updates to system tables。