【导语】“二十的小被子”通过精心收集，向本站投稿了10篇为什么有时候数据库事务日志满了，不能截断日志？数据库，下面是小编为大家整理后的为什么有时候数据库事务日志满了，不能截断日志？数据库，供大家参考借鉴，希望可以帮助到有需要的朋友。
- 目录
篇1：为什么有时候数据库事务日志满了，不能截断日志？数据库
有两种情况，可能出现这个问题，一是应用系统给 SQL Server发送了一个用户自定义事务，一直未提交，这个最早活跃事务阻碍系统截断日志。 二是客户端向SQLServer发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务
有两种情况，可能出现这个问题。一是应用系统给SQLServer发送了一个用户自定义事务，一直未提交，这个最早活跃事务阻碍系统截断日志。二是客户端向SQL Server发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务结束后，才能被截掉。
对于第一种情况，只要督促用户退出应用或者提交事务，系统管理员便可清掉日志，
因为给SQL Server发送Dump transaction with no-log或者with truncate-only，它截掉事务日志的非活跃部分。所谓非活跃部分是指服务器检查点之间的所有已提交或回退的事务。而从最早的未提交的事务到最近的日志记录之间的事务日志记录被称为活跃的。从此可以看明，打开的事务能致使日志上涨，因为在最早活跃事务之后的日志不能被截除。
对于第二种情况，道理也同上。只是在处理它时，需慎重从事。如果这个大事务已运行较长时间，应尽量想法扩大数据库日志空间，保证该事务正常结束。若该事务被强行回滚，SQL Server需要做大量的处理工作，往往是正向执行时间的几倍，系统恢复时间长，可能会影响正常使用的时间。
原文转自：www.ltesting.net
篇2：SYBASE数据库日志详解
SYBASE公司是世界著名的数据库厂家，其关系数据库产品SYBASE SQL Server在中国大中型企事业单位中拥有大量的用户，笔者在多年的使用过程中，总结出SYBASE数据库管理和维护的一些经验，现拿出来与大家分享。 我们知道，SYBASE SQL Server用事务（Transaction）来跟踪所有数据库的变化。事务是SQL Server的工作单元。一个事务包含一条或多条作为整体执行的T-SQL语句。每个数据库都有自己的事务日志（Transaction Log），即系统表（Syslogs）。事务日志自动记录每个用户发出的每个事务。日志对于数据库的数据安全性、完整性至关重要，我们进行数据库开发和维护必须熟知日志的相关知识。
一、SYBASE SQL Server如何记录和读取日志信息
SYBASE SQL Server是先记Log的机制。每当用户执行将修改数据库的语句时，SQL Server就会自动地把变化写入日志。一条语句所产生的所有变化都被记录到日志后，它们就被写到数据页在缓冲区的拷贝里。该数据页保存在缓冲区中，直到别的数据页需要该内存时，该数据页才被写到磁盘上。若事务中的某条语句没能完成，SQL Server将回滚事务产生的所有变化。这样就保证了整个数据库系统的一致性和完整性。
二、日志设备
Log和数据库的Data一样，需要存放在数据库设备上，可以将Log和Data存放在同一设备上，也可以分开存放。一般来说，应该将一个数据库的Data和Log存放在不同的数据库设备上。这样做有如下好处：一是可以单独地备份Backup事务日志；二是防止数据库溢满；三是可以看到Log的空间使用情况。
所建Log设备的大小，没有十分精确的方法来确定。一般来说，对于新建的数据库，Log的大小应为数据库大小的30%左右。Log的大小还取决于数据库修改的频繁程度。如果数据库修改频繁，则Log的增长十分迅速。所以说Log空间大小依赖于用户是如何使用数据库的。此外，还有其它因素影响Log大小，我们应该根据实际操作情况估计Log大小，并间隔一段时间就对Log进行备份和清除。
三、日志的清除
随着数据库的使用，数据库的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”命令。
四、管理庞大的事务
有些操作会大批量地修改数据，如大量数据的修改（Update）、删除一个表的所有数据（Delete）、大量数据的插入（Insert），这样会使Log增长速度很快，有溢满的危险。下面笔者给大家介绍一下如何拆分大事务，以避免日志的溢满。
例如执行“update tab_a set col_a=0”命令时，若表tab_a很大，则此Update动作在未完成之前就可能使Log溢满，引起1105错误（Log Full），而且执行这种大的事务所产生的独占锁（Exclusive Table Lock），会阻止其他用户在执行Update操作期间修改这个表，这就有可能引起死锁。为避免这些情况发生，我们可以把这个大的事务分成几个小的事务，并执行“dump transaction”动作。
上例中的情况就可以分成两个或多个小的事务：
update tab_a set col_a=0 where col_b>x
go
dump transaction database_name with truncate_only
go
update tab_a set col_a=0 where col_b <=x
go
dump transaction database_name with truncate_only
go
这样，一个大的事务就被分成两个较小的事务。
按照上述方法可以根据需要任意拆分大的事务。若这个事务需要备份到介质上，则不用“with truncate_only”选项。若执行“dump transaction with truncate_only”命令，应该先执行“dump database”。以此类推，我们可以对表删除、表插入等大事务做相应的拆分。
篇3：Informix 日志分析数据库
大家都知道informix是需要日志的，但各日志都做什么用，各有什么意义等等，我们在下面做一个探讨： 首先需要说明的是informix的日志有两种：一种是物理日志，用来存放数据的前映象；另一种是逻辑日志，用来存放所有事物的操作过程， 在初始化的配置中，物理
大家都知道informix是需要日志的，但各日志都做什么用，各有什么意义等等，我们在下面做一个探讨：
首先需要说明的是informix的日志有两种：一种是物理日志，用来存放数据的前映象；另一种是逻辑日志，用来存放所有事物的操作过程。
在初始化的配置中，物理日志和逻辑日志的不是存放在根的磁盘空间的。默认的大小物理日志2M，逻辑日志6个，每个日志文件2M。但在实际的生产环境中，这两个参数一般是需要调整的。
从informix的本身的建议来说，要求逻辑日志的大小一般是要求一天的业务量，逻辑日志滚一圈，物理日志/逻辑日志=1/3。但是有的数据量很大的业务系统，这样做是不可能的，要做适当的调整。
物理日志文件的个数仅为1，逻辑日志文件的个数最小为3，最大为32767。关于物理日志和逻辑日志的改变，我们可以使用onparams命令来完成。
C:\\Informix>onparams --
Usage: onparams -a -d
-d -l
-p -s
-a - Add a logical log file
-i - Insert after current log
-d - Drop a logical log file
-p - Change physical log size and location
-y - Automatically responds “yes” to all prompts
上面是onparams的帮助文件，下面我们首先来改变物理日志的位置和大小：
C:\\Informix>onparams -p -s 40000 -d phydbs -y
Shutting down, please wait ...
Initializing, please wait ...
Recovering, please wait ...
可以通过onstat Cl 中的phybegin来查看物理日志当前存在了哪个chunk上。Physize来查看当前物理日志文件大大小，单位是页。在这之前我们创建了phydbs，并指定了他大小。我们在-s后指定物理日志文件的大小，在-d后指定物理日志文件的位置。接着我们来做逻辑日志位置和大小的改变：
C:\\Informix>onparams -a -d logdbs -s 30000 -i
Logical log suclearcase/“ target=”_blank“ >ccessfully added.
然后用onstat Cl来查看新加的逻辑日志：
C:\\Informix>onstat -l
IBM Informix Dynamic Server Version 9.40.TC2E1 -- Quiescent -- Up 00:08:10 -- 25728 Kbytes
Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-1 0 8 8 7 1.14
phybegin physize phypos phyused %used
3:53 10000 12 0 0.00
Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-3 0 8 37 14 14 2.6 1.0
Subsystem numrecs Log Space used
OLDRSAM 37 2628
address number flags uniqid begin size used %used
0CB37CA8 1 U-B---- 1 1:763 500 500 100.00
0CB37CE8 2 U-B---- 2 1:1263 500 500 100.00
0CB37D28 3 U-B---- 3 1:1763 500 500 100.00
0CB37D68 4 U-B---- 4 1:2263 500 500 100.00
0CB37DA8 5 U-B---- 5 1:2763 500 284 56.80
0CB37DE8 6 U---C-L 6 1:3263 500 315 63.00
0CED8B98 12 A------ 0 2:37553 7500 0 0.00
0CED8B58 11 A------ 0 2:30053 7500 0 0.00
0CED8B18 10 A------ 0 2:22553 7500 0 0.00
0CED8AD8 9 A------ 0 2:15053 7500 0 0.00
0CED8A98 8 A------ 0 2:7553 7500 0 0.00
0CED8A58 7 A------ 0 2:53 7500 0 0.00
12 active, 12 total
可以发现新加的逻辑日志状态都是A,先做0级备份ontape Cs CL 0之后用onstat Cl可以发现所有日志的flag位都变成了F状态，
然后用onmode Cl切换逻辑日志到新加的逻辑日志，用onmode Cc强制做检查点操作。最后用onparams Cd Cl log_file_num Cy来删除原来的逻辑日志文件。这样就完成了informix日志的迁移。
在onstat Cl中，flag位表示了逻辑日志的状态，
A表示新加了还不能使用的日志
F表示空闲的可以使用的日志，一般是在0级备份之后才有这样的状态
U表示已经使用的逻辑日志
L表示当前的日志文件包含一个检查点
C表示正在使用当前的日志文件
B表示已经备份的日志文件
一般在新增或删除日志文件之后都要做0级备份。
在onconfig文件中，LOGFILES指定了IDS逻辑日志的个数，LOGSIZE指定了逻辑日志的大小，PHYSDBS指定了物理日志的位置，PHYSFILE指定了物理日志大小。LTAPEDEV指定了逻辑日志备份的位置，LTAPEBLK指定了每个block块的大小，LTAPESIZE指定了备份文件的大小。
下面我们讨论数据库的日志模式：
无日志
无缓冲日志
缓冲日志
ansi模式
我们可以通过ontape 来改变日志的模式
采用无日志的方式时，所有的DML语句都不写日志，也就是说此时，数据库不支持事物。当数据库恢复系统备份的时候，无日志的数据库不能完全恢复。因为在备份中只记录了备份时的状态，备份后的数据库的变化必须从逻辑日志中恢复，所以这些改变是不可恢复的。
缓冲日志：所有的DML语句都写入log buffer,当log buffer写满的时候，就开始写入磁盘。这样就可以大大减少磁盘的I/O，从而提高数据库的性能。但是在系统发生问题恢复的时候，缓冲区内的数据将丢失。这些数据是不可能恢复的。
无缓冲日志模式：所有的 DML语句在发生的时候是写到缓冲里的，但事物commit之后就立刻写回磁盘，这样在系统发生问题就保证了数据丢失的最少，但是增加了磁盘的I/O，所以数据库的性能会受到一定的影响。
Ansi模式：此模式和无缓冲日志模式具有相同的日志缓冲处理方法，但是此模式是不可逆的。
另外BLOB日志的处理也是十分特别的，他不需要物理日志，不写前映象。BLOB页是直接写磁盘的，不经过共享内存的处理。任何BLOB空闲映象的改变都将记录到逻辑日志中，所有的blob spaces数据刷新到硬盘上是随逻辑日志的的备份而写下去的。
原文转自：www.ltesting.net
篇4：有关日志压缩数据库教程
压缩
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS OFF
GO
CREATE PROCEDURE strink_logspace
AS
SET NOCOUNT ON
DECLARE @LogicalFileName sysname,
@MaxMinutes INT,
@NewSize INT
SELECT @LogicalFileName = rtrim(name),
@MaxMinutes = 10, -- 最大执行时间
@NewSize = 10 -- 最小空间
from sysfiles where status & 0x40 = 0x40
-- Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size -- in 8K pages
FROM sysfiles
WHERE name = @LogicalFileName
SELECT db_name +'日志原始大小' +
CONVERT(VARCHAR(30),@OriginalSize) + ' pages/ 8K 或 ' +
CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
(DummyColumn char (8000) not null)
-- Wrap log and truncate it.
DECLARE @Counter INT,
@StartTime DATETIME,
@TruncLog VARCHAR(255)
SELECT @StartTime = GETDATE(),
@TruncLog = 'BACKUP LOG ['+ db_name() + '] WITH TRUNCATE_ONLY'
-- Try an initial shrink.
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
-- Wrap the log if necessary.
WHILE @MaxMinutes >DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired
AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName) -- the log has not shrunk
AND (@OriginalSize * 8 /1024) >@NewSize -- The value passed in for new size is smaller than the current size.
BEGIN -- Outer loop.
SELECT @Counter = 0
WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
BEGIN -- update
INSERT DummyTrans VALUES ('Fill Log') -- Because it is a char field it inserts 8000 bytes.
DELETE DummyTrans
SELECT @Counter = @Counter + 1
END -- update
EXEC (@TruncLog) -- See if a trunc of the log shrinks it.
END -- outer loop
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
SELECT db_name() +'日志最后大小' +
CONVERT(VARCHAR(30),size) + ' pages/ 8K 或 ' +
CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
DROP TABLE DummyTrans
PRINT '*** 数据库日志压缩成功 ***'
SET NOCOUNT OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO
--used
exec strink_logspace
篇5：SYBASE数据库日志详解数据库
我们知道，SYBASE SQL Server用事务（Transaction）来跟踪所有数据库的变化，事务是SQL Server的工作单元。一个事务包含一条或多条作为整体执行的T-SQL语句。每个数据库都有自己的事务日志（Transaction Log），即系统表（Syslogs）。事务日志自动记录每个用
我们知道，SYBASESQLServer用事务（Transaction）来跟踪所有数据库的变化。事务是SQL Server的工作单元。一个事务包含一条或多条作为整体执行的T-SQL语句。每个数据库都有自己的事务日志（Transaction Log），即系统表（Syslogs）。事务日志自动记录每个用户发出的每个事务。日志对于数据库的数据安全性、完整性至关重要，我们进行数据库开发和维护必须熟知日志的相关知识。
一、SYBASESQL Server如何记录和读取日志信息
SYBASE SQL Server是先记Log的机制。每当用户执行将修改数据库的语句时，SQL Server就会自动地把变化写入日志。一条语句所产生的所有变化都被记录到日志后，它们就被写到数据页在缓冲区的拷贝里。该数据页保存在缓冲区中，直到别的数据页需要该内存时，该数据页才被写到磁盘上。若事务中的某条语句没能完成，SQL Server将回滚事务产生的所有变化。这样就保证了整个数据库系统的一致性和完整性。
二、日志设备
Log和数据库的Data一样，需要存放在数据库设备上，可以将Log和Data存放在同一设备上，也可以分开存放。一般来说，应该将一个数据库的Data和Log存放在不同的数据库设备上。这样做有如下好处：一是可以单独地备份?Backup?事务日志；二是防止数据库溢满；三是可以看到Log的空间使用情况。
所建Log设备的大小，没有十分精确的方法来确定。一般来说，对于新建的数据库，Log的大小应为数据库大小的30%左右。Log的大小还取决于数据库修改的频繁程度。如果数据库修改频繁，则Log的增长十分迅速。所以说Log空间大小依赖于用户是如何使用数据库的。此外，还有其它因素影响Log大小，我们应该根据实际操作情况估计Log大小，并间隔一段时间就对Log进行备份和清除。
三、日志的清除
随着数据库的使用，数据库的Log是不断增长的，必须在它占满空间之前将它们清除掉。清除Log有两种方法：
1.自动清除法
开放数据库选项 Trunc Log on Chkpt，使数据库系统每隔一段时间自动清除Log。此方法的优点是无须人工干预，由SQL Server自动执行，并且一般不会出现Log溢满的情况；缺点是只清除Log而不做备份。
2.手动清除法
执行命令“dump transaction”来清除Log。以下两条命令都可以清除日志：
dump transaction with truncate_onlydump transaction with no_log
通常删除事务日志中不活跃的部分可使用“dump transaction with trancate_only”命令，这条命令写进事务日志时，还要做必要的并发性检查，
SYBASE提供“dump transaction with no_log”来处理某些非常紧迫的情况，使用这条命令有很大的危险性，SQL Server会弹出一条警告信息。为了尽量确保数据库的一致性，你应将它作为“最后一招”。
以上两种方法只是清除日志，而不做日志备份，若想备份日志，应执行“dump transaction database_name to dumpdevice”命令。
四、管理庞大的事务
有些操作会大批量地修改数据，如大量数据的修改（Update）、删除一个表的所有数据（Delete）、大量数据的插入（Insert），这样会使Log增长速度很快，有溢满的危险。下面笔者给大家介绍一下如何拆分大事务，以避免日志的溢满。
例如执行“update tab_a set col_a=0”命令时，若表tab_a很大，则此Update动作在未完成之前就可能使Log溢满，引起1105错误（Log Full），而且执行这种大的事务所产生的独占锁（Exclusive Table Lock），会阻止其他用户在执行Update操作期间修改这个表，这就有可能引起死锁。为避免这些情况发生，我们可以把这个大的事务分成几个小的事务，并执行“dump transaction”动作。
上例中的情况就可以分成两个或多个小的事务：
update tab_a set col_a=0 where col_b>xgo
dump transaction database_name with truncate_only
go
update tab_a set col_a=0 where col_b <=x
go
dump transaction database_name with truncate_only
go
这样，一个大的事务就被分成两个较小的事务。
按照上述方法可以根据需要任意拆分大的事务。若这个事务需要备份到介质上，则不用“with truncate_only”选项。若执行“dump transaction with truncate_only”命令，应该先执行“dump database”。以此类推，我们可以对表删除、表插入等大事务做相应的拆分。
(责任编辑：铭铭)原文转自：www.ltesting.net
篇6：压缩MSSQL数据库日志文件大小
在SQL中，如果日志文件太大，我们可以对日志文件进压缩
dump transaction 数据库名 with no_log go
dbcc shrinkdatabase(数据库名)
篇7：如何缩小SQL Server数据库日志文件
问题：数据库实际大小为600MB, 日志文件实际大小为33MB, 但日志文件占用空间为2.8GB!试了多种方式，SHIRNK DATABASE， TRUNCATE LOG FILE, 都没办法将文件缩小，无论如何，这应该算SQL Server的一个BUG吧。
解决方法：
后来找到下面的代码，就可以将日志文件缩小到自己想要的大小了。把代码COPY到查询分析器里，，然后修改其中的3个参数(数据库名，日志文件名，和目标日志文件的大小)，运行即可。
-----
SET NOCOUNT ON
DECLARE @LogicalFileName sysname,
@MaxMinutes INT,
@NewSize INT
USE Marias
-- 要操作的数据库名
SELECT @LogicalFileName = 'Marias_log'
-- 日志文件名
@MaxMinutes = 10,
-- Limit on time allowed to wrap log.
@NewSize = 100
-- 你想设定的日志文件的大小(M)
-- Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size
FROM sysfiles
WHERE name = @LogicalFileName
SELECT 'Original Size of ' + db_name + ' LOG is ' +
CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
(DummyColumn char (8000) not null)
DECLARE @Counter INT,
@StartTime DATETIME,
@TruncLog VARCHAR(255)
SELECT @StartTime = GETDATE(),
@TruncLog = 'BACKUP LOG '
+ db_name() + ' WITH TRUNCATE_ONLY'
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
-- Wrap the log if necessary.
WHILE @MaxMinutes >DATEDIFF
(mi, @StartTime, GETDATE()) -- time has not expired
AND @OriginalSize = (SELECT size
FROM sysfiles WHERE name = @LogicalFileName)
AND (@OriginalSize * 8 /1024) >@NewSize
BEGIN -- Outer loop.
SELECT @Counter = 0
WHILE ((@Counter < @OriginalSize / 16)
AND (@Counter < 50000))
BEGIN -- update
INSERT DummyTrans VALUES ('Fill Log')
DELETE DummyTrans
SELECT @Counter = @Counter + 1
END
EXEC (@TruncLog)
END
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
DROP TABLE DummyTrans
SET NOCOUNT OFF
篇8：Sybase master库日志管理数据库
Sybase master 库日志满了应该如何清除呢?可以通过以下的方法对 master库进行管理，如果确实没有足够的空间了，可以考虑对 master库进行扩容操作， 1、简单的情况下 dump trans with no_log 就可以了，master库一般不会满。 1 use master 2 go 1 checkpoint
Sybase master 库日志满了应该如何清除呢?可以通过以下的方法对 master库进行管理，如果确实没有足够的空间了，可以考虑对 master库进行扩容操作。
1、简单的情况下 dump trans with no_log 就可以了，master库一般不会满。
1>use master
2>go
1>checkpoint
2>go
1>dump tran master with no_log
2>go
00:00000:00011:2006/02/22 14:53:38.06 server WARNING: *************************
**
00:00000:00011:2006/02/22 14:53:38.06 server Attempt by user 1 to dump xact on
db master with NO_LOG
00:00000:00011:2006/02/22 14:53:38.06 server Attempt by user 1 to dump xact on
db master with NO_LOG was suclearcase/” target=“_blank” >ccessful
00:00000:00011:2006/02/22 14:53:38.06 server WARNING: *************************
**
2、如果是windows平台，则找到RUN_your_server_name.bat
如果是Unix平台，则找到RUN_your_server_name文件
编辑上面的启动文件，在行尾加上 -T3067
然后使用启动文件启动数据库，启动后
dump tran master with truncate_onlyu
go
1）备份master数据库
dump database master to '备份路径及文件名'
2）停止sybase服务
shutdown
3）编辑sybase服务启动文件(在unix下一般是“RUN_服务名”的文件，在windows下一般是“RUN_服务名.bat”的批处理文件)，
在启动文件的命令行最后加上 -T3607)
4）使用启动文件启动服务后，再dump tran master with truncate_only
5）这时dump清理日志一般多会成功。然后在停止shutdown服务，去掉-T3607，以正常方式启动服务
3、不行的话，则需要建立一设备来进行扩展或按以下方式重建:
1）备份master数据库
启动backup server，进入isql环境执行:
1>dump database master to '/sybase/master.dump'
2>go
(如果 不行的话 dump 日志 with no log)
hut downSQL/ASE Server
1>shutdown
2>go
2）创建新的足够大的master设备
$buildmaster -d
例:$buildmaster-d/sybase/data/master.dat -s102400
3）修改RUN_servername文件
编辑RUN_server_name文件，-d参数指向新建的设备名。
4）单用户模式重启server
$startserver -f RUN_servername -m
5）执行installmaster脚本
6）由备份文件装载master数据库
1>load database master from '/sybase/master.dump'
2>go
7）修改sysdevices信息
sp_configure 'allow updates', 1
go
begin tran
go
update sysdevices set high = 102399 , phyname = 'e:\\sybase\\data\\master_test.dat' where name = 'master'
go
(102399=200*512-1 master设备大小为200M)
commit tran
go
8）扩展master数据库
1>alter database master on master设备名称=size(此值以M为单位)
2>go
例:alter database master on master=10
将master数据库在master设备上扩展10M
这个操作比较危险，注意先做好备份(比如 GHOST)
(责任编辑：铭铭)原文转自：www.ltesting.net
篇9：用脚本缩小数据库日志数据库教程
脚本|数据|数据库
因为客户使用的数据库时常因为日志过大而导致硬盘空间不够，或者备份出来的文件太大无法通过邮件传送，
闲下有余，参考SQLSERVER的帮助文件，写了如下脚本，可以截断日志，以达到缩小文件的目的。有空大家可以在自己的SQLSERVER上测试下效果哦。。。：）也许对有些情况导致的日志过大没有作用，这点可以同各位同仁互相交流下。
--在MASTER数据库中执行以下脚本（使用查询分析器）
declare @dbname varchar(50)
declare temp_cur cursor scroll for select name from sysdatabases
open temp_cur
fetch first from temp_cur into @dbname
while @@fetch_status =0
begin
exec ('backup log '+@dbname+' with no_log')
exec ('dbcc shrinkdatabase('+@dbname+')')
exec ('dbcc checkcatalog ('+@dbname+')')
exec ('dump transaction '+@dbname+' with no_log')
fetch next from temp_cur into @dbname
end
close temp_cur
deallocate temp_cur
篇10：如何压缩MSSQL数据库日志的大小数据库教程
数据|数据库|日志|mssql|压缩
数据库在日积月累的操作过程中,不但自身体积会慢慢增长,其日志的容量大小同样也随着数据库实体文件的增长而增长,且会占用很大的空间.MSSQL数据库的大小包含数据（Data）和事务日志（TransactionLog）两个部分，
数据部分存储的是用户数据库中的数据，包含用户的数据表、视图、存储过程等等内容。
数据部分一般存储与数据库文件组中的.mdb文件中。一般来说，在正常使用的情况下，这
个部分的大小不会经常性地发生很大的变化，除非是用于存储论坛之类快速变化的数据内
容。一般而言，这个部分很少会需要缩小。
事务日志存储的是用户数据库操作的事务记录，主要是用于在数据库服务器发生故障（比
如电源故障之后），恢复数据库中的数据完整性而用的。这个部分一般存储于数据库文件
组中的.ldf文件中，
这个部分的大小经常会发生剧烈的变化。
在某些情况下，由于用户的查询语句（SQL语句）书写的问题，会造成数据库文件大小的
急剧膨胀，尤其是日志文件会变得非常大。这个时候需要对数据库加以缩小。缩小的操作
分为两个步骤：
步骤一 截断数据库中的日志内容
BACKUP LOG 数据库名称 WITH TRUNCATE_ONLY
步骤二 强制数据库压缩其大小
DBCC SHRINKDATABASE ( 数据库名称 , TRUNCATEONLY )
这两个步骤需要使用查询分析器来执行。关于其具体的意义，请参考MSSQL数据库附带的
Transact-SQL的帮助文件。
还有一种方法就是在MSSQL企业管理器的数据库属性>>选项中,将故障还原>>模型设置为简单,然后确定,这样也可以直接减少日志文件的体积.
★ 日志范文
★ 研修日志
★ 每日日志范文
★ 反思日志
★ 人生经典日志
★ 感恩节日志
★ 工作日志范文
为什么有时候数据库事务日志满了，不能截断日志？数据库（合集10篇）
