在项目中数据库创建了一个本地发布和订阅,造成日志文件飞涨,想把日志文件缩小. 1:最初使用了最常用的方法: USE [master] GO ALTER DATABASE 库名 SET RECOVERY SIMPLE WITH NO_WAIT GO ALTER DATABASE 库名 SET RECOVERY SIMPLE --简单模式 GO USE 库名 GO DBCC SHRINKFILE (N, TRUNCATEONLY) GO --这里的DNName_Log 如果不知道在sys.datab

USE [master] GO ALTER DATABASE TestDB SET RECOVERY SIMPLE WITH NO_WAIT GO ALTER DATABASE TestDB SET RECOVERY SIMPLE --简单模式 GO --select * from sys.database_files USE [TestDB] GO DBCC SHRINKFILE (N'TestDB_log' , 1, TRUNCATEONLY) GO USE [master] GO ALTE

原文:SQL Server 2008收缩日志文件--dbcc shrinkfile参数说明 DBCC SHRINKFILE 收缩相关数据库的指定数据文件或日志文件大小. 语法 DBCC SHRINKFILE     ( { file_name | file_id }         { [ ,target_size ]             | [ , { EMPTYFILE | NOTRUNCATE | TRUNCATEONLY } ]         }     ) 参数 file_nam

1.新建一个同名数据库. 2.停止数据库服务,覆盖新建的数据库主文件(小技巧:最好放在同一个磁盘里面,把新建的数据库主文件删掉或移开,再把要恢复的数据库主文件剪切过去,这样就可以节省时间.) 3.启动数据库服务,数据库变为置疑或可疑状态.然后在查询分析器中运行: alter database 无日志文件的数据库名称 set emergency 设置为紧急状态. 4.再运行: alter database 无日志文件的数据库名称 set single_user 或者: Sp_dboption '无

最近在转移数据,sqlserver的日志文件ldf,占用空间特别大,为了还原库,节省空间,所以压缩日志文件迫在眉睫.在网上找了一段代码: USE [master] GO ALTER DATABASE AFMS SET RECOVERY SIMPLE WITH NO_WAIT GO ALTER DATABASE AFMS SET RECOVERY SIMPLE GO USE AFMS GO DBCC SHRINKFILE (N, TRUNCATEONLY) GO USE [master] GO A

请按步骤进行,未进行前面的步骤时,请不要做后面的步骤,以免损坏你的数据库. 一般不建议做第4,6两步,第4步不安全,有可能损坏数据库或丢失数据.第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复. 1.清空日志 DUMP  TRANSACTION  库名  WITH NO_LOG 2.截断事务日志 BACKUP LOG 数据库名 WITH NO_LOG 3.收缩数据库文件(如果不压缩,数据库的文件不会减小) 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩

    前几天,在所有数据库服务器部署了监控磁盘空间的存储过程和作业后(MS SQL 监控磁盘空间告警),今天突然收到了两封告警邮件,好吧,存储规划是一方面,但是,是不是要分析一下是什么原因造成磁盘空间不足的呢?会不会是因为突然暴增的日志文件,抑或是系统业务猛增导致数据量暴增,还是历史数据累计原因....分析总得有数据来支撑吧,但是现在只有那些数据文件的当前大小信息,没有数据文件的历史增长变化信息,所以,今天就想实现这么一个功能,每天(频率可以调整)去收集一下数据文件的信息,放到一个表里面,这样

前言碎语 关于对SQL SERVER 日志文件管理方面了解不多的话,可以参考我的这篇博客文章“MS SQL 日志记录管理”,不过这篇文章只是介绍对SQL SERVER日志记录的深入认知了解,并没有提出如何管理日志文件的方案,如果你有兴趣的话,倒不妨可以钻研一下如何管理.提取日志记录信息,这是数据库精细化管理的一个方面,如果手头管理的服务器过多,事情过多,你很难做到精细化管理!很多事情都忙不过来,需要时间去做! 问题现象 这几天有台数据库服务器一天会收到8封左右的告警邮件,大致内容如下: DATE

由于安装的时候没有计划好空间,默认装在系统盘,而且又没有做自动备份.截断事务日志等,很快LDF文件就达到十几G,或者几十G ,此时就不得不处理了. 备份和计划就不说了,现在就说下怎么把它先删除吧: 1:先分离数据库 2:为了保险,先不要删除,把LDF文件重命名下 3:附件数据库. 4:OK. 以上可能遇到的问题: 1:有用户连接,无法分离(勾选“断开所有连接”) 2:附件数数据库的时候提示找不到LDF文件,不要慌,在附件的时候,把LDF的路径一项删除,然后点击"确定",这样就附件成功了

由于安装的时候没有计划好空间,默认装在系统盘,而且又没有做自动备份.截断事务日志等,很快LDF文件就达到十几G,或者几十G ,此时就不得不处理了. 备份和计划就不说了,现在就说下怎么把它先删除吧: 1:先分离数据库 2:为了保险,先不要删除,把LDF文件重命名下 3:附件数据库. 4:OK. 以上可能遇到的问题: 1:有用户连接,无法分离(勾选“断开所有连接”) 2:附件数数据库的时候提示找不到LDF文件,不要慌,在附件的时候,把LDF的路径一项删除,然后点击"确定",这样就附件成功了

最近公司的数据库随着业务量的增多,日志文件巨大(超过300G),造成磁盘空间不够用,进而后来的访问数据库请求无法访问. 网上类似的方法也很多,但不可行,如下是我实践过,可行的,将日志文件收缩至任意指定大小的方法: 第一步: 在SQL SERVER Management Studio 中右击数据库选择“属性”--->“选项”,将恢复模式由默认的“完整”改为“简单”. 第二步:再次右键选择数据库的“任务”-->“收缩”--->“文件”菜单,进入收缩文件页面, 将(要收缩的)文件类型选定为“日

USE 数据库名称 GO ALTER DATABASE 数据库名称 SET RECOVERY SIMPLE WITH NO_WAIT GO ALTER DATABASE 数据库名称 SET RECOVERY SIMPLE GO USE 数据库名称 GO DBCC SHRINKFILE (N'数据库日志名称' , 1, TRUNCATEONLY)--清理为1M日志文件 “数据库日志名称”请查看以下图片中的日志逻辑名称 GO USE 数据库名称 GO ALTER DATABASE 数据库名称 SET

1.手动分离数据库: 2.手动删除日志文件: 3.重新生成日志文件: CREATE DATABASE FMIS0 ON (FILENAME = 'E:\FMIS0_DATA\FMIS0-Date') FOR ATTACH_REBUILD_LOG ;GO

一.准备知识 1.LSN LSN用来标识特定日志在日志文件中位置(详情请见什么是LSN:日志序列号),它由两部分组成:一部分用来标识VLF(虚拟日志文件)的序列号,剩下的用来标识该日志在VLF中的具体的位置. 根据LSN不同,日志一般分为两类:首日志(最新的活动日志序号)和尾日志(保留时间最长的活动日志序号).随着数据库的操作不断增加(如数据库中的update操作),首日志LSN序号不断变化.尾日志的序号只有在日志备份后才会变化. (图一)日志文件结构图 2.VLF 你可以通过DCC LOGIN

-- 查询日志文件名,用于下面删除 USE [data_name] GO SELECT file_id, name FROM sys.database_files /*删除指定数据库的日志文件*/ USE [master] GO ALTER DATABASE 数据库名 SET RECOVERY SIMPLE WITH NO_WAIT GO , TRUNCATEONLY) GO

查询状态语句: SELECT name,log_reuse_wait_desc FROM sys.databases where name='hrsystem'; 收缩日志文件: USE [master] GO ALTER DATABASE hrsystem SET RECOVERY SIMPLE WITH NO_WAIT GO ALTER DATABASE hrsystem SET RECOVERY SIMPLE GO USE hrsystem DBCC SHRINKFILE (N'NewSt

当数据库发生这种操作故障时,可以按如下操作步骤可解决此方法,打开数据库里的Sql 查询编辑器窗口,运行以下的命令. 1.修改数据库为紧急模式 ALTER DATABASE Zhangxing SET EMERGENCY 2.使数据库变为单用户模式 ALTER DATABASE Zhangxing SET SINGLE_USER 3.修复数据库日志重新生成,此命令检查的分配,结构,逻辑完整性和所有数据库中的对象错误.当您指定“REPAIR_ALLOW_DATA_LOSS”作为DBCC CHECKD

首先建立同名的空数据库,然后停止数据库服务运行,将MDF文件覆盖后启动服务,并修改和执行下面的语句. alter database JinMa_NYGL set EMERGENCY alter database JinMa_NYGL set SINGLE_USER dbcc checkdb('JinMa_NYGL',REPAIR_ALLOW_DATA_LOSS) alter database JinMa_NYGL set MULTI_USER ALTER DATABASE JinMa_Colle

Use LingZhong Select NAME,size From sys.database_files ALTER DATABASE LingZhong SET RECOVERY SIMPLE WITH NO_WAIT ALTER DATABASE LingZhong SET RECOVERY SIMPLE USE LingZhong DBCC SHRINKFILE(N'LingZhong_log',0,TRUNCATEONLY) ALTER DATABASE LingZhong SET

USE [master]GOALTER DATABASE DNName SET RECOVERY SIMPLE WITH NO_WAITGOALTER DATABASE DNName SET RECOVERY SIMPLE --简单模式GOUSE DNNameGODBCC SHRINKFILE (N'DNName_Log' , 11, TRUNCATEONLY) GO '这里的DNName_Log 如果不知道在sys.database_files里是什么名字的话,可以用以下注释的语句进行查询 '

To Open Log File Viewer, 1. Expand Server Node > 2. Expand SQL Server Agent > 3. Expand Jobs > 4. Right click on the Job and 5. Select "View History" as shown in the screen shot below: 方法一:可以通过执行该命令来查看错误日志信息:exec xp_readerrorlog 方法二:在SQ