Sybase的SYSLOGS日志满了进不了系统，如何清除日志启动系统

摘要: 用过Sybase的同学都清楚Sybase的日志情况，日志不会自增长，需要手动去建大小，同时日志要自己手动去清理

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

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

1>sp_configure "allow update",1

2>go

第二步，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"

2>go

1> shutdown

2> go

第三步，由于事务日志已经很满，不能使用常规方法转储此事务日志，如果使用了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

2> go

1> dump tran testdb with no_log

2> go

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

1> use master

2> go

1> update sysdatabases set status = 0 where name = "testdb"

2> go

1> sp_configure "allow update",0

2> go