sybase事务日志已满，怎么清除？

[a569673493]

建立索引的时候，提示：
Can't allocate space for object 'POWER_FILE' in database 'dms' because 'default' segment is full/has no free extents. If you ran out of space in syslogs, dump the transaction log. Otherwise, use ALTER DATABASE to increase the size of the segment.
翻译了下，貌似是日志已经满了，于是我在数据库的属性里，又添加了300MB事务日志，还是不行，以前有个人交过我的，他给了一个sql语句让我执行一下就OK了，里面有dump的，但是不记得

[hobbylu]

你的不是增加日志空间，而是要增加数据空间

[a569673493]

[Quote=引用 1 楼 hobbylu 的回复:]

你的不是增加日志空间，而是要增加数据空间
[/Quote]

那咋办呢？

[a569673493]

我看了syslogs里面总共就128kb全用完了，怎么给它加点空间呢？

[Sybase数据库恢复]

新建一个设备， alter database 数据库名 on 设备名=分配大小

[a569673493]

[Quote=引用 4 楼 andkylee 的回复:]

新建一个设备， alter database 数据库名 on 设备名=分配大小
[/Quote]
新建设备？我日志满了，为啥要新建设备呢？

[a569673493]

4楼啊能解释一下这句话做了哪些事情啊？

[Sybase数据库恢复]

[Quote=引用 5 楼 a569673493 的回复:]

引用 4 楼 andkylee 的回复:

新建一个设备， alter database 数据库名 on 设备名=分配大小

新建设备？我日志满了，为啥要新建设备呢？
[/Quote]

已有的设备满了， 再新建一个设备分配给它啊。

[a569673493]

[Quote=引用 7 楼 andkylee 的回复:]

引用 5 楼 a569673493 的回复:

引用 4 楼 andkylee 的回复:

新建一个设备， alter database 数据库名 on 设备名=分配大小

新建设备？我日志满了，为啥要新建设备呢？


已有的设备满了， 再新建一个设备分配给它啊。
[/Quote]

那我啊可以把日志空间清除的啊
我试着用 dump transaction XXX 但是不行

[Sybase数据库恢复]

楼主真犟 。 先清日志也行，if you can ~

[a569673493]

关键是我清日志来着，但是不行，不晓得哪里出错了，用dump。。。，这不是想知道自己错在哪里了吗？

[Sybase数据库恢复]

because 'default' segment is full/has no free extents　
这和日志没有关系。　

[a569673493]

[Quote=引用 11 楼 andkylee 的回复:]

because 'default' segment is full/has no free extents
这和日志没有关系。
[/Quote]
default段满了？除了增加一个设备，还可以用其他方法吗？增加设备的话不是要浪费存储空间吗

[Sybase数据库恢复]

增加设备的话不是要浪费存储空间吗

-------------------------------

怕浪费空间，干脆把数据都干掉。

[a569673493]

use master
go
dump tran database_name with truncate_only
go

这样行吗

[aspirin18]

好好看看手册先

[Sybase数据库恢复]

有些人就知道贴~

[gyxing168]

你的日志满了，设备空间不够，只要在加个数据库设备，然后在执行就应该可以；
数据库属性 日志是否截断啊
我以前也遇到过日志满的问题，不过是在导数据的时候，先将索引删除，禁用触发器，然后在导入；
但如果是 default 和 system 段满的话，也只能加设备了吧，我都是加设备；
还有 可以 rog rebulid table_name 是不是也可以减少空间；
有篇文章不知能否用上，可以看看；（希望对你有所帮助）
*****************************************
*****************************************
1. Sybase数据库日志详解
Sybase　SQL Server用事务（Transaction）来跟踪所有数据库的变化。事务是SQL　Server的工作单元。一个事务包含一条或多条作为整体执行的T－SQL语句。每个数据库都有自己的事务日志（Transaction　Log），即系统表（Syslogs）。事务日志自动记录每个用户发出的每个事务。日志对于数据库的数据安全性、完整性至关重要，我们进行数据库开发和维护必须熟知日志的相关知识。

（1）Sybase　SQL Server 如何记录和读取日志信息

Sybase　SQL Server是先记Log的机制。每当用户执行将修改数据库的语句时，SQL　Server就会自动地把变化写入日志。一条语句所产生的所有变化都被记录到日志后，它们就被写到数据页在缓冲区的拷贝里。该数据页保存在缓冲区中，直到别的数据页需要该内存时，该数据页才被写到磁盘上。若事务中的某条语句没能完成，SQL　Server将回滚事务产生的所有变化。这样就保证了整个数据库系统的一致性和完整性。

（2）日志设备

Log和数据库的Data一样，需要存放在数据库设备上，可以将Log和Data存放在同一设备上，也可以分开存放。一般来说，应该将一个数据库的Data和Log存放在不同的数据库设备上。这样做有如下好处：一是可以单独地备份Backup　事务日志；二是防止数据库溢满；三是可以看到Log的空间使用情况。

所建Log设备的大小，没有十分精确的方法来确定。一般来说，对于新建的数据库，Log的大小应为数据库大小的20-30%左右。Log的大小还取决于数据库修改的频繁程度。如果数据库修改频繁，则Log的增长十分迅速。所以说Log空间大小依赖于用户是如何使用数据库的。此外，还有其它因素影响Log大小，我们应该根据实际操作情况估计Log大小，并间隔一段时间就对Log进行备份和清除。

（3）日志的清除

随着数据库的使用，数据库的Log是不断增长的，必须在它占满空间之前将它们清除掉。清除Log有两种方法：

1.自动清除法

开放数据库选项 Trunc Log on Chkpt，使数据库系统每隔一段时间自动清除Log。此方法的优点是无须人工干预，由SQL　Server自动执行，并且一般不会出现Log溢满的情况；缺点是只清除Log而不做备份。

2.手动清除法

执行命令“dump transaction”来清除Log。以下两条命令都可以清除日志：

　　dump transaction with truncate_only
　　dump transaction with no_log

通常删除事务日志中不活跃的部分可使用“dump transaction with trancate_only”命令，这条命令写进事务日志时，还要做必要的并发性检查。SYBASE提供“dump transaction with no_log”来处理某些非常紧迫的情况，使用这条命令有很大的危险性，SQL　Server会弹出一条警告信息。为了尽量确保数据库的一致性，你应将它作为“最后一招”。

以上两种方法只是清除日志，而不做日志备份，若想备份日志，应执行“dump transaction database_name to dumpdevice”命令。

2. Sybase日志管理
在创建用户数据库的时候，应尽量为事务日志创建独立的日志设备，这样可以单独备份事务日志、防止数据库溢满、可以看到事务日志的占用情况及可以镜像等。
dump transaction db_name with truncate_only //不备份事务日志，直接清除。
dump transaction db_name with no log
dump transaction db_name to “路径/名字” //备份事务日志
检查log大小
dbcc checktable(syslogs)
go

3. 提示：Can"t allocate space for object "syslogs" in database "csbt?" because the "logsegment" segment is full……

提示数据库的日志已满。

（1） 重启数据库（最笨的但最有效的）。
（2） 给数据库日志加空间，但必须有足够的空间。
（3） 找出执行大事物SESSION的ID，KILL它，但也会回滚，而且不定可以KILL得掉。
（4） 截断日志：

如果从未dump transaction过，transactionlog将最终会满。 SQLServer使用log（日志）是出于恢复目的的。当数据库日志满时，服务器将停止事务的继续进行，因为服务器将不能将这些事务写进日志，而服务器不能运行大多数的dump tran命令，因为SQL Server也需在日志中记录这些命令。这就是为什么当其它dump tran命令不能执行时no_log可执行的原因。但是想一下dump transaction with no_log被设计执行的环境，所有对不做并发性检查。如果在对数据库的修改发生时使用dump transaction with no_log，你就会冒整个数据库崩溃的风险。在多数情况下，它们被反映成813或605错误。为了在数据库被修改时，删除transaction log中的不活跃部分可使用dump transaction with trancate_only。这条命令写进transaction log时，并且它还做不要的并发性检查。这两条命令都有与其相关的警告，在命令参考手册中会看到这些警告。请确保在使用其中任一条命令以前，你已理解这些警告和指示。 Sybase提供dump transaction with no_log来处理某些非常紧迫的情况。为了尽量确保你的数据库的一致性，你应将其作为“最后一招”。

查看是否截断，可用如下方法解决：
（1）如果是 master 库：
dump tran master with no_log
（2）如果是用户数据库（如：csbt）：
可以等待自动清理，过5分钟后，再重启SQLSERVER；否则：
use master
go
sp_dboption csbt,"trunc. log on chkpt",false
go
checkpoint
go
dump tran csbt with no_log
go
sp_dboption csbt,"trunc. log on chkpt",true
go
checkpoint
go


4. 当设置truncate log on checkpoint，对于日志备份就没有意义，建议在生成环境上不要打开truncate log on checkpoint这个选项。

5. Sybase日志无法清除或截断。在使用dump tran.....后清除不了日志，且重启动sybase也无法清除，（已设置了trunc log on chkpt选项）。
（1） 应用系统给SQL Server发送了大量的用户自定义事务，一直未提交，这些最早活跃事务阻碍系统截断日志。要督促用户退出系统或者提交事务，便可清掉日志。因为给SQL Server发送Dump transaction with no-log或者with truncate-only，它截掉事务日志的非活跃部分。所谓非活跃部分是指服务器检查点之间的所有已提交或回退的事务。而从最早的未提交的事务到最近的日志记录之间的事务日志记录被称为活跃的。从此可以看明，打开的事务能致使日志上涨，因为在最早活跃事务之后的日志不能被截除。
（2） 二是客户端向SQL Server发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务结束后，才能被截掉。在处理它时，需慎重从事。如果这个大事务已运行较长时间，应尽量想法扩大数据库日志空间，保证该事务正常结束。若该事务被强行回滚，SQL Server需要做大量的处理工作，往往是正向执行时间的几倍，系统恢复时间长，可能会影响正常使用的时间。
（3） 是否使用了复制服务器？主数据库是否增加了表或者字段？
（4） 如果使用了sybase复制服务器，会存在第二截断点问题。如果复制进程由于某种原因无法正常工作，那么会导致ASE的日志充满的问题，你可以使用下面的命令来忽略第二截断点，但是这样做的时候，会导致复制数据不能同步，需要手工同步。设置数据库为单用户，使用 dbcc tablealloc(syslogs,full,fix) 检查，修复一下数据库日志空间，看是否有问题。如果忽略复制的第二截断点，使用
dbcc settrunc(‘item’,’ignore’)
go

如果复制的第二截断点没有清除，使用
use csbt
go
sp_config_rep_agent csbt,'disable'
go
checkpoint
go

（5） 如果tempdb满了的话，是无法使用dump tran tempdb with truncate_only 或no_log清除掉的，而且用select * from master..syslogshold这个命令查看是哪个进程，在这种状态下只能kill 其他进程，直到可以使用dump tran。