数据库压缩日志

--收缩LDF:
USE [master]
GO
ALTER DATABASE UltimusDB SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE UltimusDB SET RECOVERY SIMPLE --简单模式
GO
USE UltimusDB
GO
DBCC SHRINKFILE (N‘UltimusDB_log‘ , 11, TRUNCATEONLY)

GO

USE [master]
GO
ALTER DATABASE UltimusDB SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE UltimusDB SET RECOVERY FULL --还原为完全模式
GO

时间: 2024-12-19 00:11:26

数据库压缩日志的相关文章

System.Data.SqlClient.SqlError: 尚未备份数据库的日志尾部

SQL还原时出现下面的错误,System.Data.SqlClient.SqlError: 尚未备份数据库 "***" 的日志尾部.如果该日志包含您不希望丢失的工作,请使用 BACKUP LOG WITH NORECOVERY 备份该日志.请使用 RESTORE 语句的 WITH REPLACE 或 WITH STOPAT 子句来只覆盖该日志的内容. (Microsoft.SqlServer.Smo)原因分析:    这是因为在线还原的数据库在最后备份后又产生了新的日志,所以按照默认设

归档—监控ORACLE数据库告警日志

ORACLE的告警日志里面包含许多有用的信息,尤其是一些ORACLE的ORA错误信息,所以有必要及时归档.监控数据库告警日志的ORA错误,及时提醒数据库管理员DBA处理这些错误信息,那么我们首先来看看告警日志的内容片断:   归档告警日志文件 告警日志文件如果不加管理的话,那么文件会持续增长,有时候文件会变得非常大,不利于读写.一般建议将告警日志按天归档,归档文件保留三个月(视情况而定),下面来看看将告警日志文件归档的两个Shell脚本: alert_log_archive.sh version

(转)对SQLSERVER数据库事务日志的疑问

本文转载自桦仔的博客http://www.cnblogs.com/lyhabc/archive/2013/06/10/3130856.html 对SQLSERVER数据库事务日志的疑问 摸不透SQLSERVER了 实验环境:SQLSERVER2005 SP4,Windows7 本来没什么心情写文章,反正没人看,关于我文章中提到的问题,有些可以从文章结尾的MSDN补充那里找到答案,而有些还没有答案 根据CSDN博客的这篇文章介绍,大家可以先看一下,然后再继续往下看,因为下面会引用到CSDN博客里的

【翻译自mos文章】在重建控制文件之后,丢失了数据库补充日志信息(Missed Database Supplemental Log Information)

在重建控制文件之后,丢失了数据库补充日志信息(Missed Database Supplemental Log Information) 参考原文: Missed Database Supplemental Log Information After Recreate Controlfile In 10g Database. (Doc ID 1474952.1) 适用于: Oracle Server - Enterprise Edition - Version 10.1.0.2 and late

exchange企业实战之邮箱数据库与日志文件迁移

移动邮箱数据库和日志,将执行3个步骤 如果目标数据库已经装载,首先卸除邮箱数据库: 迁移目标邮箱数据库: 装载邮箱数据库: 卸载邮箱数据库 迁移邮箱数据库和日志文件 第一步,确认目标邮箱数据库的当前位置.键入一下命令. Get-MailboxDatabase Get-MailboxDatabase Identity Mailbaox51 |FL *PATH* 命令执行后, 第一条命令,查询组织中的所有exchange邮箱数据库: 第二条命令,确认目标数据库Mailbaox51以及日志文件路径:

数据库更新日志

=========================================================================== 注:这是软件工程团队的数据库更新日志及交流日志,在做的过程中如果发现数据库缺少一些东西或有错误,每个人都可以按照以下       编辑格式编辑条目,从而不断完善数据库,同时维持其统一性,另外每个人还可发布博文交流意见.   日志编辑格式: 序号 [时间] [修改的表名] 修改意见 [修改原因] ==========================

转:关于数据库压缩技术的Survey

原文来自于:http://outofmemory.cn/mysql/database-compression-tech 昨天给团队内的小伙伴做了一个关于数据库压缩技术的Survey,现将其中可以公开的部分分享出来.数据库压缩技术目前已经成为了各种数据库的标配技术,这里面包括三大商业数据库.各种专业的分新型数据库,也包括各种开源数据库和NoSQL数据库. 到了今天,数据库压缩技术的运用已经不单纯是为了节省存储成本,更多的时候,是为了提供更高的计算密度(比如容量受限的SSD),以及提供更高的查询性能

配置了AlwaysOn的数据库事务日志收缩

由于配置了AlwaysOn的数据库为完整恢复模式,使得数据库的事务日志增长飞快,导致报错“事务日志已满”. 解决方法: 1 完整备份事务日志,选中截断事务日志选项* 2 收缩数据库事务日志文件* 3 完整备份数据库 4 再次备份事务日志,同选中截断事务日志选项 5 再次收缩数据库事务日志文件 步骤1与2是否可省略待验证.

SQL2008R2 收缩数据库问题 - 日志文件不变小

数据库的日志文件(*.ldf)越来越大,怎么办? 收缩吧.收缩日志文件的操作真不简单哟,还跟数据库的恢复模式有关啊. 一.“简单恢复模式”时的日志收缩 1. 截断日志 当数据库的恢复模式为“简单”的时候,日志文件会在以下情况被截断: (1)完整备份 (2)遇到检查点(checkpoint) 2. 手动收缩日志文件 当日志被截断后,日志文件的内部空间就会标记为“可复用”,因此日志文件就不需要持续增长.关于日志文件空间状态的解释,详见 http://jimshu.blog.51cto.com/317