下载文档原格式
让知识带有温度。
关于SQLServer压缩日志及数据库文件大小整理
关于SQL Server压缩日志及数据库文件大小
请按步骤进行,未进行前面的步骤时,请不要做后面的步骤，以免损坏你的数据库.
一般不建议做第4,6两步，第4步担心全,有可能损坏数据库或丢失数据。
第6步假如日志达到上限,则以后的数据库处理睬失败,在清理日志后才能恢复。
1.清空日志
DUMP TRANSACTION 库名WITH NO_LOG
2.截断事务日志
BACKUP LOG 数据库名WITH NO_LOG
3.收缩数据库文件(假如不压缩,数据库的'文件不会减小
企业管理器--右键你要压缩的数据库--全部任务--收缩数据库--收缩文件
--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
--选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
也可以用SQL语句来完成
第1页/共2页
千里之行，始于足下。
--收缩数据库
DBCC SHRINKDATABASE(客户资料)
--收缩指定数据文件,1是文件号,可以通过这个语句查询到:
select * from sysfiles
DBCC SHRINKFILE(1)
4.为了最大化的缩小日志文件(假如是sql 7.0,这步只能在查询分析器中进行)
a.分别数据库:
企业管理器--服务器--数据库--右键--分别数据库
b.在我的电脑中删除LOG文件
文档内容到此结束，欢迎大家下载、修改、丰富并分享给更多有需要的人。
第2页/共2页。
SQLServer数据库操作总结（sql语法的使用）电脑资料数据库学完了，但是脑子里还是没有一个系统的数据库操作概念，语法：alter database 数据库名称add file 数据文件[to file group 文件组名称]add log file 日志文件操作：语法：ALTER DATABASE 数据库名MODIFY FILE 文件属性操作：将数据库db1中的数据文件data2的初始大小改为10MB，最大容量为20MB，增长幅度为10%语法：alter database 数据库名称remove file 数据文件或日志文件的逻辑文件名操作：删除数据库db1中的数据文件data4和日志文件log2语法：alter database 数据库名add filegroup 文件组名操作：在数据库db1中增加一个g2文件组语法：alter database 数据库名modify filegroup 文件组名name=新文件组名操作：将数据库db1中的文件组g2更名为g3语法：alter database 数据库名称remove filegroup 文件组名操作：删除数据库db1的文件组g3语法：alter database 数据库名modify name = 新数据库名操作：将数据库db1的名字修改为gl操作：删除数据库DB1,DB2,DB3类型：主键（PRIMARY KEY）约束惟一（UNIQUE）约束外键（FOREIGN KEY）约束检查（CHECK）约束说明：非空和默认值也可看成是约束。
创立表约束的方法：新建表时，在单列后创立约束或者在所有列之后，再创立约束；如果表已存在，只能通过修改表，添加约束。
语法：(字段名类型[(长度)] [,……n])操作：主键约束的作用：1.不允许输入重复的值2.不能取空值（当主键是由多个属性组成时：某一属性上的数据可以重复，但其组合必须是惟一的；每个属性的值都不能为空。
SQL日志文件太大清理方法当SQL日志文件太大时，清理方法包括：备份、压缩、归档和删除等步骤。
下面是一些具体的方法和步骤：1.备份日志文件：首先，需要确保已经备份了当前的SQL日志文件。
这是因为，在清理之前，需要先保存原始的日志文件，以防止出现意外情况。
可以使用数据库管理工具或命令行工具进行备份。
2.压缩日志文件：为了减小日志文件的大小，可以使用压缩工具将其进行压缩。
压缩后的日志文件可以占用更少的磁盘空间，同时也更容易存储和传输。
在压缩之前，要确保不再需要对日志进行任何操作，以免丢失任何重要信息。
3.归档日志文件：归档是将日志文件从当前位置移到另一个位置的过程。
通过归档，可以将旧的日志文件移动到一个备份或存档目录中，以便以后查看或还原。
这样，可以释放当前的日志文件空间，并保留原始的日志记录。
具体的归档方法可以根据数据库管理系统和应用程序的要求进行选择。
4.删除日志文件：一旦已经完成了备份、压缩和归档操作，就可以考虑删除较旧的日志文件。
删除日志文件可以释放磁盘空间，提高系统性能，并且可以避免日志文件过大对系统运行造成负面影响。
但是，在删除日志文件之前，要确保已经备份和归档了这些文件，以防止丢失重要的数据。
需要注意的是，清理SQL日志文件需要谨慎操作，以免出现数据丢失或其他不可预料的问题。
因此，在进行清理操作之前，建议先备份和归档日志文件，以便以后查看或还原。
此外，要保持日志文件的合理大小，可以定期进行备份和归档操作，避免日志文件不断增长而导致系统性能下降。
在执行清理操作时，最好在非繁忙的时间段进行，以减少对系统运行的干扰。
sql server日志已满处理方法sql server日志已满处理方法学习2009-07-2615:42:33阅读323评论0字号：大中小SQL数据库日志文件太大,或者使用软件时提示日志已满的处理方法.sql出现这种题提示,有二种情况,一你的电脑存放数据库文件的盘符不是NTFS格式的,而是别的格式,如FAT32只支持一个文件最大4G,所以超过4G就没有办法再写文件,sql 就会提示日志文件已满.另外就是NTFS格式的,前台见一个卖服装的朋友店里数据库主文件只有100多M,而日志文件却有40G,幸亏是他的硬盘空间多,不然软件早不能用了.估计软件数据库设计的有问题.后来给他重新建了一个日志收银速度明显加快.一--在SQL查询分析器执行--按下边的步骤一步一步的做--删除日志前要先对以前的数据库进行备份(这一步必须做,已免数据出现丢失)--1、使数据库脱机use masterexec sp_Detach_db test,true--2、把对应的.ldf文件删除或改名--需手工做自己手工删除数据库文件的所在目录下的.ldf文件--3、加载数据文件exec sp_attach_single_file_db test,'D:\Program Files\Microsoft SQL Server\MSSQL\Data\test_Data.MDF'--4设置日志文件的增长方式alter database test set recovery simple二1.清空日志DUMP TRANSACTION库名WITH NO_LOG2.截断事务日志：BACKUP LOG数据库名WITH NO_LOG3.收缩数据库文件(如果不压缩,数据库的文件不会减小企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了--选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了也可以用SQL语句来完成--收缩数据库DBCC SHRINKDATABASE(客户资料)--收缩指定数据文件,1是文件号,可以通过这个语句查询到:select*from sysfilesDBCC SHRINKFILE(1)4.为了最大化的缩小日志文件(如果是sql7.0,这步只能在查询分析器中进行)a.分离数据库:企业管理器--服务器--数据库--右键--分离数据库b.在我的电脑中删除LOG文件c.附加数据库:企业管理器--服务器--数据库--右键--附加数据库此法将生成新的LOG，大小只有500多K或用代码：下面的示例分离pubs，然后将pubs中的一个文件附加到当前服务器。
解释⼀下SQLSERVER事务⽇志记录⼤家知道在完整恢复模式下，SQLSERVER会记录每个事务所做的操作，这些记录会存储在事务⽇志⾥，有些软件会利⽤事务⽇志来读取操作记录恢复数据，例如：log explorer那么事务⽇志记录怎麽查看，⾥⾯都记录了些什么？打开可以利⽤下⾯SQL语句来查看所在数据库的事务⽇志记录1 USE [GPOSDB] --要查看事务⽇志记录的数据库2 GO3 SELECT * FROM [sys].[fn_dblog](NULL,NULL)事务⽇志记录⾥很多东西可以看的，⾥⾯记录了⾮常详细的数据库活动信息我这⾥只介绍⼀些重要的需要知道的字段，其他字段由于本⼈能⼒有限⽽且觉得其他字段不是很重要就不介绍了CurrentLSN：当前LSN号，事务⽇志中的每个记录都由⼀个唯⼀的⽇志序列号 (LSN) 标识。
LSN 是这样排序的：如果 LSN2 ⼤于 LSN1，则 LSN2 所标识的⽇志记录描述的更改发⽣在⽇志记录 LSN1 描述的更改之后Operation：当前LSN所做的操作Context：操作的上下⽂TransactoinID：事务ID号Log Record Fixed Length：LSN记录的所占虚拟⽇志⽂件的固定长度Previous LSN：前⼀个LSN号--------------------------------------------------------------------------------------------------------------AllocUnitID：修改的那条数据所属分配单元IDAllocUnitName：修改了数据的表名Page ID：0001:00000121 转换成⼗进制：289 所以查看pageid为289页 DBCC PAGE([pratice],1,289,3)Slot ID：数据所在数据页⾯的第⼏条记录PartitionID：数据所在数据页⾯的所在分区ID如上图，修改数据的表名是Insert_Test，Page ID是0001:00000121 转换为⼗进制为289 Slot ID是6（即数据页的第6条记录）通过下⾯SQL语句就可以查看页⾯所在数据1 USE [pratice]2 GO3 DBCC TRACEON(3604,-1)4 GO56 DBCC PAGE([pratice],1,289,3)7 GO1 Slot 6 Offset 0x552 Length 21123 Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP4 Memory Dump @0x0A2AC55256 00000000: 1000d000 3f080000 61616120 20202020 ?....?...aaa7 00000010: 20202020 20202020 20202020 20202020 ?8 00000020: 20202020 20202020 20202020 20202020 ?9 00000030: 20202020 2020202021 Slot 6 Column 0 Offset 0x4 Length 42223 id = 21112425 Slot 6 Column 1 Offset 0x8 Length 2002627 name = aaa这个表只有两个字段，我们看⼀下表数据--------------------------------------------------------------------------------------------------------Checkpoint Begin：Checkpoint开始时间Checkpoint Begin DB Version：当前数据库版本 SQL2005是611 SQL2012是706Checkpoint End：checkpoint的结束时间，这个时间肯定在Checkpoint Begin的下⼀条事务⽇志记录的位置Minimum LSN: 这个第⼀个⽇志记录的⽇志序列号 (LSN)，称为最⼩恢复 LSN (MinLSN)Dirty Pages：脏的数据页Oldest Replicated Begin LSN：如果数据库配置复制的话，那么最⽼的复制起始LSNNext Replicated End LSN:下⼀个复制结尾LSNLast Distributed End LSN：最新的分发结尾LSNSPID:执⾏当前操作的进程IDBeginlog Status:开始记录事务⽇志的状态，这个状态表⽰现时能够正常记录事务⽇志Begin Time：事务开始时间Transaction Name：事务名称End Time：事务结束时间Transaction Begin：记录这个事务的begin transaction的时候的cureent LSNMaster DBID:显⽰当前master数据库的DBIDPreplog Begin LSN:启动数据库前的前⼀个事务⽇志LSNPrepare Time:准备启动数据库的时间New Split Page：哪个数据页产⽣了页拆分Rows Deleted：数据页有多少⾏被删除了Description：描述这个事务是⼲什么的，有时候事务名称不⼀定就是他所做的操作名称，⽐如这⾥碰巧事务名和描述都是CREATE TABLE 如果你为这个事务命名的话，那么只能看Description列看这个事务是做什么的-------------------------------------------------华丽的分割线-------------------------------------------------------------------现在解释⼀下⼀些常见operation和context，⼀些不常见的我也不知道，呵呵o(∩_∩)oOperation：当前LSN所做的操作Context：操作的上下⽂Operation Context解释LOP_SET_BITS LCX_DIFF_MAP设置位图，资料：差异(Differential)备份:只备份上次完整备份后，做修改的部分。
SqlServer数据库提示“tempdb”的日志已满问题如何
解决
本文主要讲述了笔者在执行sql语句的过程中，遇到SqlServer数据库提示tempdb”的日志已满问题。
请备份该数据库的事务日志以释放一些日志空间”的解决过程，希望对大家有所帮助。
执行sql 语句，中间没有用到临时表
提示服务器: 消息9002，级别17，状态2，行1
数据库‘tempdb’ 的日志已满。
请备份该数据库的事务日志以释放一些日志空间。
网上找了下解决方案，大体是扩大临时库的日志文件的大小解决的
解决过程：
查看了下数据库的属性，是自动增长，不指定文件大小上限。
在网上Google了很久，试了些方法都不行;数据库所在磁盘还有很大的可用空间，试着下重药了。
直接把tempdb的数据文件和日志文件的大小改为3000M，。
SQL Server自动备份清除日志文件一、自动备份数据库日志打开企业管理器，进入“管理”-“数据库维护计划”，在右侧窗口点击右键，选择“新建维护计划”，启动“数据库维护计划向导”;点击“下一步”选择需要维护的数据库，维护特性数据库时，选择最后一个单选框并勾选需要维护的数据库名称;“下一步”选择更新数据优化信息、“下一步”检查数据库完整性、“下一步”指定数据库备份计划、“下一步”指定备份存放位置、“下一步”指定事务日志备份计划、“下一步”指定报表，“下一步”指定历史纪录维护，最后设定维护作业名称;通常来说，如果只需要备份数据库文件，则只需要指定备份计划以及存放位置即可，其他项目不做改动。
在指定备份计划时候，由于需要每日备份，因此要更改调度。
点击“更改”编辑调度。
发生频率选择每天;每日频率选择作业开始时间，最好选择数据库访问量小时进行，多为半夜时间，可根据流量图确定具体时间;持续时间通常不用做改动，开始日期为编辑日期，无结束日期。
编辑好上述维护计划后，还要注意下 sql server代理服务是否启动了，因为每日调度维护计划是要启动这个服务才能执行的。
如果该服务没有启动，需要手动启动一下，这是可以在其子项“作业”中看到刚刚添加过的数据库维护计划。
二、定期自动清理数据库日志文件数据库日志文件是随着时间增长而增长的，如果长时间不清理，文件会变得特别大，因此需要定期清空，但是日至文件是恢复数据库的重要依据，不用日志文件也是不明智的。
手工清除单个数据库的还好说，但数据库多了，或者临时没有来得及清理，可能硬盘空间就会占满了，影响访问。
因此设置自动清理数据库日志文件还是比较实用的。
手动清理方法：右键单击需要清理的数据库，选择“属性”，在“选项”卡上，把故障还原模型设定为简单，确定后关闭;再右键单击该数据库，“所有任务”-“收缩数据库”，确认后即可清除日志文件，最后记得重新选择“属性”，将故障还原模型设置为完全。
sqlserver日志文件总结及充满处理第一篇：sqlserver日志文件总结及充满处理sqlserver日志文件总结及充满处理文章来源：sqlserver论坛作者：hansbj交易日志（Transaction logs）是数据库结构中非常重要但又经常被忽略的部分。
由于它并不像数据库中的schema那样活跃，因此很少有人关注交易日志。
交易日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。
对于任何每一个交易过程，交易日志都有非常全面的记录，根据这些记录可以将数据文件恢复成交易前的状态。
从交易动作开始，交易日志就处于记录状态，交易过程中对数据库的任何操作都在记录范围，直到用户点击提交或后退后才结束记录。
每个数据库都拥有至少一个交易日志以及一个数据文件。
出于性能上的考虑，SQL Server将用户的改动存入缓存中，这些改变会立即写入交易日志，但不会立即写入数据文件。
交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件。
当SQL Server重启后，它会查看日志中最新的标记点，并将这个标记点后面的交易记录抹去，因为这些交易记录并没有真正的将缓存中的数据写入数据文件。
这可以防止那些中断的交易修改数据文件。
维护交易日志因为很多人经常遗忘交易日志，因此它也会给系统带来一些问题。
随着系统的不断运行，日志记录的内容会越来越多，日志文件的体积也会越来越大，最终导致可用磁盘空间不足。
除非日常工作中经常对日志进行清理，否则日志文件最终会侵占分区内的全部可用空间。
日志的默认配置为不限容量，如果以这种配置工作，它就会不断膨胀，最终也会占据全部可用空间。
这两种情况都会导致数据库停止工作。
对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间。
备份过程会将日志中不再需要的部分截除。
截除的方法是首先把旧记录标记为非活动状态，然后将新日志覆盖到旧日志的位置上，这样就可以防止交易日志的体积不断膨胀。
sqlserver⽇志⽂件不停增长的原因⽇志不停增长的原因
1.数据库是完整模式，但是并没有定期的进⾏⽇志备份。
⽇志备份可以截断事务，可以使得空间重⽤。
解决这个问题，只需做好⽇志定时备份的计划作业就⾏
2.有事务长时间没有提交
由于开发⼈员的粗⼼⼤意，没有把已经运⾏完成的事务提交，⽇志⼀直在记录，导致很⼤
解决这个问题，查找出已经运⾏完成但没有提交的事务，kill掉此事务即可
3.有很⼤的事务正在运⾏
这个事务很⼤，⼀直不停的在记录⼤量的⽇志，导致⽇志增⼤
解决这个问题，看看在语句和业务逻辑上看看能否优化的余地，运⾏很⼤的事务能否分事务运⾏
造成2,3两种情况的根本原因是因为：⽇志备份只备份已提交的事务
还需要注意的是：只有⽇志备份才能截断⽇志，使得⽇志空间可以重⽤
转载请注明出处。
SQLServer清理日志文件方法案例详解
这篇文章主要介绍了SQLServer清理日志文件方法案例详解,本篇文章通过简要的案例,讲解了该项技术的了解与使用,以下就是详细内容,需要的朋友可以参考下
很多时候SQLSERVER的日志文件是不看的，但时间久了，够把磁盘撑爆，这时候就需要清理日志文件。
使用以下方法，在实际环境中经过测试，400G的日志文件1秒就被清理。
操作步骤
1. 将恢复模式改成“简单”
右键数据库 - 属性，切换到选项，将恢复模式修改为简单。
2. 收缩日志
右键数据库 - 任务 - 收缩 - 文件
确定后会发现，日志文件被迅速清理。
3. 命令操作
USE [master]
GO
ALTER DATABASE 要清理的数据库名称 SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE 要清理的数据库名称 SET RECOVERY SIMPLE --简单模式
GO
USE 要清理的数据库名称
GO
DBCC SHRINKFILE (N'要清理的数据库名称_log' , 2, TRUNCATEONLY) --设置压缩后的日志大小为2M，可以自行指定
GO
USE [master]
GO
ALTER DATABASE 要清理的数据库名称 SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE 要清理的数据库名称 SET RECOVERY FULL --还原为完全模式
到此这篇关于SQLServer清理日志文件方法案例详解的文章就介绍到这了。
sqlserver 日志文件总结及充满处理
文章来源：sqlserver 论坛 作者：hansbj
交易日志（Transaction logs ）是数据库结构中非常重要但又经常被忽略的部分。
由于它并不像数据库中的schema 那样活跃，因此很少有人关注交易日志。
交易日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。
对于任何每一个交易过程，交易日志都有非常全面的记录，根据这些记录可以将数据文件恢复成交易前的状态。
从交易动作开始，交易日志就处于记录状态，交易过程中对数据库的任何操作都在记录范围，直到用户点击提交或后退后才结束记录。
每个数据库都拥有至少一个交易日志以及一个数据文件。
出于性能上的考虑，SQL Server 将用户的改动存入缓存中，这些改变会立即写入交易日志，但不会立即写入数据文件。
交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件。
当SQL Server 重启后，它会查看日志中最新的标记点，并将这个标记点后面的交易记录抹去，因为这些交易记录并没有真正的将缓存中的数据写入数据文件。
这可以防止那些中断的交易修改数据文件。
维护交易日志
因为很多人经常遗忘交易日志，因此它也会给系统带来一些问题。
随着系统的不断运行，日志记录的内容会越来越多，日志文件的体积也会越来越大，最终导致可用磁盘空间不足。
除非日常工作中经常对日志进行清理，否则日志文件最终会侵占分区内的全部可用空间。
日志的默认配置为不限容量，如果以这种配置工作，它就会不断膨胀，最终也会占据全部可用空间。
这两种情况都会导致数据库停止工作。
对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间。
备份过程会将日志中不再需要的部分截除。
截除的方法是首先把旧记录标记为非活动状态，然后将新日志覆盖到旧日志的位置上，这样就可以防止交易日志的体积不断膨胀。
如果无法对日志进行经常性的备份工作，最好将数据库设置为"简单恢复模式"。
在这种模式下，系统会强制交易日志在每次记录标记点时，自动进行截除操作，以新日志覆盖旧日志。
截除过程发生在备份或将旧标记点标为非活动状态时，它使得旧的交易记录可以被覆盖，但这并不会减少交易日志实际占用的磁盘空间。
就算不再使用日志，它依然会占据一定的空间。
因此在维护时，还需要对交易日志进行压缩。
压缩交易日志的方法是删除非活动记录，从而减少日志文件所占用的物理硬盘空间。
通过使用DBCC SHRINKDATABASE 语句可以压缩当前数据库的交易日志文件，DBCC SHRINKFI LE 语句用来压缩指定的交易日志文件，另外也可以在数据库中激活自动压缩操作。
当压缩日志时，首先会将旧记录标记为非活动状态，然后将带有非活动标记的记录彻底删除。
根据所使用的压缩方式的不同，你可能不会立即看到结果。
在理想情况下，压缩工作应该选在系统不是非常繁忙的时段进行，否则有可能影响数据库性能。
恢复数据库
交易记录备份可以用来将数据库恢复到某一指定状态，
但交易记录备份本身不足以完成恢复数据库的
任务，还需要备份的数据文件参与恢复工作。
恢复数据库时，首先进行的是数据文件的恢复工作。
在整个数据文件恢复完成前，不要将其设为完成状态，否则交易日志就不会被恢复。
当数据文件恢复完成，系统会通过交易日志的备份将数据库恢复成用户希望的状态。
如果在数据库最后一次备份后，存在多个日志文件的备份，备份程序会按照它们建立的时间依次将其恢复。
另一种被称为log shipping的过程可以提供更强的数据库备份能力。
当log shipping配置好后，它可以将数据库整个复制到另一台服务器上。
在这种情况下，交易日志也会定期发送到备份服务器上供恢复数据使用。
这使得服务器一直处于热备份状态，当数据发生改变时它也随之更新。
另一个服务器被称作监视（monitor）服务器，可以用来监视按规定时间间隔发送的shipping信号。
如果在规定时间内没有收到信号，监视服务器会将这一事件记录到事件日志。
这种机制使得log shipping经常成为灾难恢复计划中使用的方案。
性能优化
交易日志对数据库有重要作用，同时它对系统的整体性能也有一定影响。
通过几个选项，我们可以对交易日志的性能进行优化。
由于交易日志是一个连续的磁盘写入过程，在这当中不会发生读取动作。
因此将日志文件放在一个独立的磁盘，对优化性能有一定作用。
另一项优化措施与日志文件的体积有关。
我们可以设置日志文件的体积不超过硬盘空间的百分之几，或者确定它的大小。
如果将其设置的过大会浪费磁盘空间，而如果设置的过小则会强制记录文件不断尝试扩展，导致数据库性能下降。
事务日志文件Transaction Log File是用来记录数据库更新情况的文件，扩展名为ldf。
在SQL Server 7.0 和SQL Server 2000 中，如果设置了自动增长功能，事务日志文件将会自动扩展。
一般情况下，在能够容纳两次事务日志截断之间发生的最大数量的事务时，事务日志的大小是稳定的，事务日志截断由检查点或者事务日志备份触发。
然而，在某些情况下，事务日志可能会变得非常大，以致用尽空间或变满。
通常，在事务日志文件占尽可用磁盘空间且不能再扩展时，您将收到如下错误消息：
Error:9002, Severity:17, State:2
The log file for database '%.*ls' is full.
除了出现此错误消息之外，SQL Server 还可能因为缺少事务日志扩展空间而将数据库标记为SUSP ECT。
有关如何从此情形中恢复的其他信息，请参见SQL Server 联机帮助中的“磁盘空间不足”主题。
另外，事务日志扩展可能导致下列情形：
·非常大的事务日志文件。
·事务可能会失败并可能开始回滚。
·事务可能会用很长时间才能完成。
·可能发生性能问题。
·可能发生阻塞现象。
原因
事务日志扩展可能由于以下原因或情形而发生：
·未提交的事务
·非常大的事务
·操作：DBCC DBREINDEX 和CREATE INDEX
·在从事务日志备份还原时
·客户端应用程序不处理所有结果
·查询在事务日志完成扩展之前超时，您收到假的“Log Full”错误消息
·未复制的事务
日志文件满而造成SQL数据库无法写入文件时，可用两种方法：
一种方法：清空日志。
1．打开查询分析器，输入命令
DUMP TRANSACTION 数据库名WITH NO_LOG
2.再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。
另一种方法有一定的风险性，因为SQL SERVER的日志文件不是即时写入数据库主文件的，如处理不当，会造成数据的损失。
1: 删除LOG
分离数据库企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
2：删除LOG文件
附加数据库企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库
此法生成新的LOG，大小只有500多K。
注意：建议使用第一种方法。
如果以后,不想要它变大。
SQL2000下使用：
在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。
或用SQL语句：
alter database 数据库名set recovery simple
另外，数据库属性有两个选项，与事务日志的增长有关：
Truncate log on checkpoint
(此选项用于SQL7.0，SQL 2000中即故障恢复模型选择为简单模型)
当执行CHECKPOINT 命令时如果事务日志文件超过其大小的70% 则将其内容清除在开发数据库时时常将此选项设置为True
Auto shrink
定期对数据库进行检查当数据库文件或日志文件的未用空间超过其大小的25%时，系统将会自动缩减文件使其未用空间等于25% 当文件大小没有超过其建立时的初始大小时不会缩减文件缩减后的文件也必须大于或等于其初始大小对事务日志文件的缩减只有在对其作备份时或将Truncate log on checkpoint 选项设为True 时才能进行。
注意：一般立成建立的数据库默认属性已设好，但碰到意外情况使数据库属性被更改，请用户清空日志后，检查数据库的以上属性，以防事务日志再次充满。
