sybase数据库tempdb日志相关问题讨论

最新推荐文章于 2023-06-01 23:08:36 发布

QiYe005

最新推荐文章于 2023-06-01 23:08:36 发布

阅读量1.1k

点赞数

分类专栏：数据库运维相关

数据库运维相关专栏收录该内容

3 篇文章 0 订阅

订阅专栏

转自：https://blog.csdn.net/renhui15688/article/details/6700305

你的日志满了，设备空间不够，只要在加个数据库设备，然后在执行就应该可以；
数据库属性日志是否截断啊
我以前也遇到过日志满的问题，不过是在导数据的时候，先将索引删除，禁用触发器，然后在导入；
但如果是 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。你的日志满了，设备空间不够，只要在加个数据库设备，然后在执行就应该可以；
数据库属性日志是否截断啊
我以前也遇到过日志满的问题，不过是在导数据的时候，先将索引删除，禁用触发器，然后在导入；
但如果是 default 和 system 段满的话，也只能加设备了吧，我都是加设备；
还有可以 rog rebulid table_name 是不是也可以减少空间；
有篇文章不知能否用上，可以看看；（希望对你有所帮助）

转自：https://blog.csdn.net/java118/article/details/1801404

开发数据库服务器遇到这样的一个问题，使用了一段时间之的后，突然之间数据库就用不了了，现象是新连接连接不上，已经连接的执行sql时，报出tempdb日志满了，无法进行操作的错误，而且控制台无法连接上服务器，所有操作都无法正常进行。

经过上网查询，得知是tempdb日志满了，缺省情况下，tempdb数据库是放置在master设备上，容量为2M，而临时数据库是活动最为平凡的数据库常常被用来排序、创建临时表、重格式化等操作，所以tempdb的优化应该受到特别的关注。安装Sybase的时候就应该把tempdb的空间扩大，并且最好新建一个表空间给它专门用。

正常的时候可以用sp_helpdb tempdb命令查看tempdb，可以看到tempdb占用空间的情况。

如果日志满了，可以执行dump tran tempdb with truncate_only或者dump tran tempdb with no_log来清除日志，但是现在根本无法执行该语句，因为tempdb已经满了，根本没有空间来执行该语句，这该怎么办，好像进入了一个死循环里，日志满了要清除，但因为满了又无法清除，看来只能先扩容了，现在已经没有一个空闲的表空间了，控制台根本无法连接上数据库，只能用语句来新建一个表空间，下面是新建表空间的语句：

disk init

name="tempdblog",

physname="c:/sybasedb/tempdblog.dat",

vdevno=11,

size= 409600

新建好表空间后，将该空间分配给tempdb存放日志用如下命令：

alter database tempdb log on tempdblog=800

如果要分配数据空间，用如下命令：

alter database tempdb on tempdbdata=1024

分配好后，就可以执行之前的清除日志的语句：

dump tran tempdb with truncate_only

或者 dump tran tempdb with no_log