SQL SERVER 日志满的处理方法 |
事务日志文件Transaction Log File是用来记录数据库更新状况的文件, 扩大名为ldf 。 在 SQL Server 7.0 和 SQL Server 2000 中,假如设置了自动增进 性能,事务日志文件将会自动 扩大 。 普通状况下,在 可以 包容两次事务日志截断中间 产生的最大数量的事务时,事务日志的大小是 巩固的,事务日志截断由 审查点或者事务日志备份触发 。 但是,在某些情 事务日志文件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 还可能由于 缺乏事务日志 扩大空间而将数据库标记为 SUSPECT 。有关如何从此 情景中 复原的 其余信息,请参见 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 时 威力进行 。 留神:普通立成 构建的数据库默许属性已设好,但碰到意外状况使数据库属性被更改,请消费者清空日志后, 审查数据库的以上属性,以防事务日志再次 充斥 。 |