1. SQL Server事务日志被填满的原因是什么
错误描述：数据库的事务日志已满。若要查明无法重用日志中的空间的原因 ，请参阅sys.databases 中的 log_reuse_wait_desc 列 。
首先引入一下事务日志的概念
事务日志是一个与数据库文件分开的文件。它存储对数据库进行的所有更改，并全部记录插入、更新、删除、提交、回退和数据库模式变化。事务日志还称作前滚日志或重做日志。
事务日志是备份和恢复的重要组件，也是使用 SQL Remote 或 [复制代理] 复制数据所必需的。
在缺省情况下，所有数据库都使用事务日志。事务日志的使用是可选的，但是，除非您因特殊原因而不使用，否则您应始终使用它。运行带有事务日志的数据库可提供更强的故障保护功能、更好的性能以及数据复制功能。
引发异常的原因：
a.未提交的事务
b.非常大的事务
c.操作：DBCC DBREINDEX 和 CREATE INDEX
d.在从事务日志备份还原时
e.客户端应用程序不处理所有结果
f.查询在事务日志完成扩展之前超时，您收到假的“Log Full”错误消息
g.未复制的事务
解决办法：
1.释放磁盘空间（菜鸟适用）；
2.把数据库移到内存充足的磁盘（原理同上）；
3.清空日志：DUMP TRANSACTION 库名 WITH NO_LOG；
4.截断事务日志：BACKUP LOG 库名 WITH NO_LOG；
2. 如何从根本上解决SQL数据库日志已满的问题
1、你设置了日志文件的最大数，数据库的恢复模式是完整恢复模式，所有的针对数据库的改动都会记录到日志，不仅仅是你的改动数据库，数据库本身的操作也有记录到日志，所以，日志文件才会不断增长。
2、那是因为大部分的电脑上的数据库，基本没怎么变过，但生产用的数据库经常变动，所以日志记录也变得巨大，我见过数据库200MB，但是日志文件50GB，因为本来数据库有10GB，因为测试需要删除了大部分的数据，结果导致日志文件增长到了50GB。
3、定时备份日志并收缩日志文件。
4、通过备份日志，并收缩日志文件，这个语句你自己网络。
5、日志是一个以事务编号连续的记录，比如，我第一次备份的日志事务编号为1-1000，那么日志就会被截断，并从1001开始，之后的日志备份就从1001开始了，所以，初始备份一直到最后一次备份都不能删除，否则使用日志恢复时会出现问题。
3. SQL server数据库日志满了怎么处理
一、删除日志文件。
二、手动收缩。操作如下：
1、在数据库页面中选择“选项”；
4. SQL server数据库日志满了怎么处理
解决方法
日志文件满而造成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
时才能进行。
注意：一般立成建立的数据库默认属性已设好，但碰到意外情况使数据库属性被更改，请用户清空日志后，检查数据库的以上属性，以防事务日志再次充满。
5. SQL Server日志文件总结及日志满的处理
交易日志（Transaction logs）是数据库结构中非常重要但又经常被忽略的部分 由于它并不像数据库中的schema那样活跃 因此很少有人关注交易日志 交易日志是针对数据库改变所做的记录 它可以记录针对数据库的任何操作 并将记录结果保存在独立的文件中 对于任何每一个交易过程 交易日志都有非常全面的记录 根据这些记录可以将数据文件恢复成交易前的状态 从交易动作开始 交易日志就处于记录状态 交易过程中对数据库的任何操作都在记录范围 直到用户点击提交或后退后才结束记录 每个数据库都拥有至少一个交易日志以及一个数据文件 出于性能上的考虑 SQL Server将用户的改动存入缓存中 这些改变会立即写入交易日志 但不会立即写入数据文件 交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件 当SQL Server重启后 它会查看日志中最新的标记点 并将这个标记点后面的交易记录抹去 因为这些交易记录并没有真正的将缓存中的数据写入数据文件 这可以防止那些中断桐桐毕的交易修改数据文件 维护交易日志 因为很多人经常遗忘交易日志 因此它也会给系统带来一些问题 随着系统的不断运行 日志记录的内容会越来越多 日志文件的体积也会越来越大 最终导致可用磁盘空间不足 除非日常工作中经常对日志进行清理 否则日志文件最终会侵占分区内的全部可用空间 日志的默认配置为不限容量 如果以这种配置工作 它就会不断膨胀 最终也会占据全部可用空间 这两种情况都会导致数据库停止工作 对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间 备份过程会将日志中不再需要的部分截除 截除的方法是首先把旧记录标记为非活动状态 然后将新日志覆盖到旧日志的位置上 这样就可以防止交易日志的体积不断局芹膨胀 如果无法对日志进行经常性的备份工作 最好将数据库设置为 简单恢复模式 在这种模式下 系统会强制交易日志在每次记录标记点时 自动进行截除操作 以新日志覆盖旧日志 截除过程发生在备份或将旧标记点标为非活动状态时 它使得旧的交易记录可以被覆盖 但这并不会减少交易日志实际占用的磁盘空间 就算不再使用日志 它依然会占据一定的空间 因此在维护时 还需要对交易日志进行压缩 压缩交易日志的方法是删除非活动记录 从而减少日志文件所占用的物理硬盘空间 通过使用DBCC SHRINKDATABASE语句可以压缩当前数据库的交易日志文件 DBCC SHRINKFILE语句用来压缩指定的交易日志文件 另外也可以在数据库中激活自动压缩操作 当压缩日志时 首先会将旧记录标记为非活动状态 然后将带有非活动标记的记录彻底删除 根据所使用的压缩方式的不同 你可能不会立即看到结果 在理想情况下 压缩工作应该选在系统不是非常繁忙的时段进行 否则有可能影响数据库性能 恢复数据库 交易记录备份可以用来将数据库恢复到某一指定状态 但交易记录备份本身不足以完成恢复数据库的任务 还需要备份的数据文件参与恢复工作 恢复数据库时 首先进行的轮斗是数据文件的恢复工作 在整个数据文件恢复完成前 不要将其设为完成状态 否则交易日志就不会被恢复 当数据文件恢复完成 系统会通过交易日志的备份将数据库恢复成用户希望的状态 如果在数据库最后一次备份后 存在多个日志文件的备份 备份程序会按照它们建立的时间依次将其恢复 另一种被称为log shipping的过程可以提供更强的数据库备份能力 当log shipping配置好后 它可以将数据库整个复制到另一台服务器上 在这种情况下 交易日志也会定期发送到备份服务器上供恢复数据使用 这使得服务器一直处于热备份状态 当数据发生改变时它也随之更新 另一个服务器被称作监视（monitor）服务器 可以用来监视按规定时间间隔发送的shipping信号 如果在规定时间内没有收到信号 监视服务器会将这一事件记录到事件日志 这种机制使得log shipping经常成为灾难恢复计划中使用的方案 性能优化 交易日志对数据库有重要作用 同时它对系统的整体性能也有一定影响 通过几个选项 我们可以对交易日志的性能进行优化 由于交易日志是一个连续的磁盘写入过程 在这当中不会发生读取动作 因此将日志文件放在一个独立的磁盘 对优化性能有一定作用 另一项优化措施与日志文件的体积有关 我们可以设置日志文件的体积不超过硬盘空间的百分之几 或者确定它的大小 如果将其设置的过大会浪费磁盘空间 而如果设置的过小则会强制记录文件不断尝试扩展 导致数据库性能下降 事务日志文件Transaction Log File是用来记录数据库更新情况的文件 扩展名为ldf 在 SQL Server 和 SQL Server 中 如果设置了自动增长功能 事务日志文件将会自动扩展 一般情况下 在能够容纳两次事务日志截断之间发生的最大数量的事务时 事务日志的大小是稳定的 事务日志截断由检查点或者事务日志备份触发 然而 在某些情况下 事务日志可能会变得非常大 以致用尽空间或变满 通常 在事务日志文件占尽可用磁盘空间且不能再扩展时 您将收到如下错误消息 Error: Severity: State: The log file for database % *ls is full 除了出现此错误消息之外 SQL Server 还可能因为缺少事务日志扩展空间而将数据库标记为 SUSPECT 有关如何从此情形中恢复的其他信息 请参见 SQL Server 联机帮助中的 磁盘空间不足 主题 另外 事务日志扩展可能导致下列情形 · 非常大的事务日志文件 · 事务可能会失败并可能开始回滚 · 事务可能会用很长时间才能完成 · 可能发生性能问题 · 可能发生阻塞现象 原因 事务日志扩展可能由于以下原因或情形而发生 · 未提交的事务· 非常大的事务· 操作 DBCC DBREINDEX 和 CREATE INDEX· 在从事务日志备份还原时· 客户端应用程序不处理所有结果· 查询在事务日志完成扩展之前超时 您收到假的 Log Full 错误消息· 未复制的事务 解决方法 日志文件满而造成SQL数据库无法写入文件时 可用两种方法 一种方法 清空日志 ．打开查询分析器 输入命令DUMP TRANSACTION 数据库名 WITH NO_LOG 再打开企业管理器 右键你要压缩的数据库 所有任务 收缩数据库 收缩文件 选择日志文件 在收缩方式里选择收缩至XXM 这里会给出一个允许收缩到的最小M数 直接输入这个数 确定就可以了 另一种方法有一定的风险性 因为SQL SERVER的日志文件不是即时写入数据库主文件的 如处理不当 会造成数据的损失 : 删除LOG分离数据库 企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库 删除LOG文件附加数据库 企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库此法生成新的LOG 大小只有 多K 注意 建议使用第一种方法 如果以后 不想要它变大 SQL 下使用 在数据库上点右键 >属性 >选项 >故障恢复 模型 选择 简单模型 或用SQL语句 alter database 数据库名 set recovery simple另外 如上图中数据库属性有两个选项 与事务日志的增长有关 Truncate log on checkpoint(此选项用于SQL SQL 中即故障恢复模型选择为简单模型)当执行CHECKPOINT 命令时如果事务日志文件超过其大小的 % 则将其内容清除在开发数据库时时常将此选项设置为True Auto shrink定期对数据库进行检查当数据库文件或日志文件的未用空间超过其大小的 %时 系统将会自动缩减文件使其未用空间等于 % 当文件大小没有超过其建立时的初始大小时不会缩减文件缩减后的文件也必须大于或等于其初始大小对事务日志文件的缩减只有在对其作备份时或将Truncate log on checkpoint 选项设为True 时才能进行 注意 一般立成建立的数据库默认属性已设好 但碰到意外情况使数据库属性被更改 请用户清空日志后 检查数据库的以上属性 以防事务日志再次充满 lishixin/Article/program/SQLServer/201311/22123