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;

  遇到问题才是我们进步的机会,这些都是从网上搜索的一些解决办法,希望可以帮助到您!

时间: 2024-10-14 20:01:58

SQL Server中事务日志已满的原因以及解决办法的相关文章

SQL Server中TOP子句可能导致的问题以及解决办法

原文:SQL Server中TOP子句可能导致的问题以及解决办法 简介      在SQL Server中,针对复杂查询使用TOP子句可能会出现对性能的影响,这种影响可能是好的影响,也可能是坏的影响,针对不同的情况有不同的可能性.      关系数据库中SQL语句只是一个抽象的概念,不包含任何逻辑.很多元数据都会影响执行计划的生成,SQL语句本身并不作为生成执行计划所参考的元数据(提示除外),但TOP关键字却是直接影响执行计划的一个关键字,因此在某些情况下使用TOP会导致性能受到影响,下面我们来

SQL Server 为什么事务日志自动增长会降低你的性能

原文地址:点击打开链接   在这篇文章里,我想详细谈下为什么你要避免事务日志(Transaction Log)上的自动增长操作(Auto Growth operations).很多运行的数据库服务器,对于事务日志,用的都是默认的日志文件大小和自动增长设置.人们有时会很依赖自动增长机制,因为它们刚好能正常工作.当然,如果它正常工作的话,你不必太关注它,但很快你会发现会有问题出现.   只依赖于事务日志的自动增长机制总不是个好主意.首先它会导致严重的日志碎片(Log Fragmentation),在

数据库-sql server 2005 事务日志删除问题

问题描述 sql server 2005 事务日志删除问题 sql server 2005 事务日志 删除对数据库有多大影响? 如何删除sql server 2005 事务日志 如何做到定期删除半年前的,保留半年的事务日志? 解决方案 如果你的数据库是full模式,那需要先做完整备份,再定期做日志备份,这样才能截断日志 如果数据库是simple模式,就不存在截断日志的问题

《SQL Server企业级平台管理实践》读书笔记——SQL Server中收缩数据库不好用的原因

原文:<SQL Server企业级平台管理实践>读书笔记--SQL Server中收缩数据库不好用的原因 数据库管理员有时候需要控制文件的大小,可能选择收缩文件,或者把某些数据文件情况以便从数据库里删除. 这时候我们就要使用到DBCC SHRINKFILE命令,此命令的脚本为: DBCC SHRINKFILE ( { file_name | file_id } { [ , EMPTYFILE ] | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATE

SQL Server中提前找到隐式转换提升性能的办法

原文:SQL Server中提前找到隐式转换提升性能的办法     http://www.cnblogs.com/shanksgao/p/4254942.html 高兄这篇文章很好的谈论了由于数据隐式转换造成执行计划不准确,从而造成了死锁.那如果在事情出现之前发现了这类潜在的风险岂不是更好?     那么我们来看一个简单的例子,如代码清单1所示.   1: SELECT * 2: FROM HumanResources.Employee 3: WHERE NationalIDNumber = 2

ORACLE LOGFILE 和 SQL SERVER 2005 事务日志管理和恢复的比较

原创,转载请注明    其实如果要说这类日志的重要性,当然2个数据库都知道它的重要性.也淡淡的说一下.日志是进行数据库恢复重要的组建.用于将数据库恢复到故障点,也就是我们通常说的滚动,ORACLE叫他LOGFILE,而SQL SERVER 叫他事务日志.    ORACLE中有归档模式和非归档模式,而这对应了SQL SERVER 中的恢复模式的完整恢复模式和简单恢复模式.完整恢复模式和归档模式都是支持恢复到故障点的,而非归档模式和简单模式其实说白了都是不保存各自数据库的历史LOGFILE和事务日

SQL Server中In-Flight日志究竟是多少

在SQL Server中,利用日志的WAL来保证关系数据库的持久性,但由于硬盘的特性,不可能使得每生成一条日志,就 直接向磁盘写一次,因此日志会被缓存起来,到一定数据量才会写入磁盘.这部分已经生成的,却没有写入磁盘的日志 ,就是所谓的In-Flight日志. 在SQL Server中,In-Flight的日志的大小取决于两个因素,根据Paul Randal的说法,In-Flight日志不能超过60K, 因此In-Flight的日志最大是60K,此外,如果In-Flight日志没有到60K,如果发

SQL Server 磁盘请求超时的833错误原因及解决方法

最近遇到一个SQL Server服务器响应极度缓慢,并且出现客户端请求报错的情况,在数据库中的errorlog中出现磁盘请求超过15s才完成的error消息. 对于此类问题,到底是存储系统或者磁盘的故障,还是SQL Server 自己的问题,亦或是应用程序引发的呢?又要如何解决? 本文将对引起此问题的某一方面的因素进行简单的分析,但是无法涵盖所有潜在的可能性,因此遇到类似问题还要做具体的分析. SQL Server中的磁盘请求超时 该错误的英文版的错误信息如下: SQL Server has e

MS SQL Server的事务日志简介一览

交易日志,或称事务日志(Transaction logs)是数据库结构中非常重要但又经常被忽略的部分.由于它并不像数据库中的schema那样活跃,因此很少有人关注交易日志. 交易日志是针对数据库改变所做的记录,它可以记录针对数据库的任何操作,并将记录结果保存在独立的文件中.对于任何每一个交易过程,交易日志都有非常全面的记录,根据这些记录可以将数据文件恢复成交易前的状态.从交易动作开始,交易日志就处于记录状态,交易过程中对数据库的任何操作都在记录范围,直到用户点击提交或后退后才结束记录.每个数据库