这个问题到底是sybsystemprocs太小还是数据库log小?

[zhongchao]

出错信息如下:
00:2005/03/22 09:39:57.67 server Error: 1105, Severity: 17, State: 3
00:2005/03/22 09:39:57.67 server Can't allocate space for object 'syslogs' in d
atabase 'sybsystemprocs' because the 'logsegment' segment is full. If you ran ou
t of space in syslogs, dump the transaction log. Otherwise, use ALTER DATABASE o
r sp_extendsegment to increase the size of the segment.
00:2005/03/22 09:39:57.67 server Error: 3639, Severity: 17, State: 1
00:2005/03/22 09:39:57.67 server There is no space available in syslogs in data
base 4 for process 6 to log a record for which space has been reserved. This pro
cess will retry at intervals of 60 seconds.

[hobbylu]

是sybsystemprocs太小,sybsystemprocs是数据和日志放在一起的

[crazycfb]

(转)许多情况下都是由于应用系统数据库日志太慢了，一般在这种情况下使用dump tran dbname with truncate_only就可以解决问题了
第一步，启用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