【www.bbyears.com--php安装】
一、简单方法
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文件片断中显示的那样：
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