SQL server2008无法收缩日志,错误信息为: 1:由于最小日志空间要求,无法收缩日志文件 2:无法收缩日志文件 2 (XXX_log),因为该文件结尾的逻辑日志文件正在使用 描述: 用的是网上普遍有的收缩代码USE [master]GOALTER DATABASE shujuku SET RECOVERY SIMPLE WITH NO_WAITGOALTER DATABASE shujuku SET RECOVERY SIMPLE --简单模式GOUSE shujukuGODBCC S

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

由于安装的时候没有计划好空间,默认装在系统盘,而且又没有做自动备份.截断事务日志等,很快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 中右击数据库选择“属性”--->“选项”,将恢复模式由默认的“完整”改为“简单”. 第二步:再次右键选择数据库的“任务”-->“收缩”--->“文件”菜单,进入收缩文件页面, 将(要收缩的)文件类型选定为“日

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

-- 查询日志文件名,用于下面删除 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

错误如下图: 1.数据库 → 属性 → 选项 → 恢复模式 → 选择‘简单’:如下图: 2.任务 → 收缩 → 文件类型‘文件’ → 收缩模式‘在释放未使用的空间前重新组织页’,将文件收缩到K,大小填 0:如下图: 3.确定之后修改数据库属性中恢复模式为‘完整’.

SQL2008:'在SQL2008中清除日志就必须在简单模式下进行,等清除动作完毕再调回到完全模式. USE [master] GO ALTER DATABASE DBName SET RECOVERY SIMPLE WITH NO_WAIT GO ALTER DATABASE DBName SET RECOVERY SIMPLE --简单模式 GO USE DBName GO , TRUNCATEONLY) GO USE [master] GO ALTER DATABASE DBName SE

直接执行 USE [库名称]GOALTER DATABASE [库名称] SET RECOVERY SIMPLE WITH NO_WAITGOALTER DATABASE  [库名称] SET RECOVERY SIMPLE --简单模式GOUSE IFGMMSGODBCC SHRINKFILE (N'[库名称对应的文件]_log' , 11, TRUNCATEONLY)  --例如 book_log GO

alter database testdb set emergencyalter database testdb set single_userdbcc checkdb('testdb',REPAIR_ALLOW_DATA_LOSS)dbcc checkdb('testdb',REPAIR_REBUILD)alter database testdb set multi_user

CREATE DATABASE DBname ON (FILENAME = 'D:\SalesData\DBname_data.mdf') FOR ATTACH_REBUILD_LOG ; GO 简单好用

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

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

SQL Server 2008删除或压缩数据库日志的方法 2010-09-20 20:15 由 于数据库日志增长被设置为“无限制”,所以时间一长日志文件必然会很大,一个400G的数据库居然有600G的LOG文件,严重占用了磁盘空间.由于主要 是做OLAP,所以数据库本身不会有大变动,所以日志也就没有多少作用了,因此想办法把数据库日志文件收缩到很小或者删除. 网 上搜索相关解决方案后,得到的答案丰富多彩,但是真正管用的方案并不多,这里分享一个csdn上找到的方法.这个方法讲述了SQL Server

由于数据库日志增长被设置为“无限制”,所以时间一长日志文件必然会很大,一个400G的数据库居然有600G的LOG文件,严重占用了磁盘空间.由于主要是做OLAP,所以数据库本身不会有大变动,所以日志也就没有多少作用了,因此想办法把数据库日志文件收缩到很小或者删除. 网上搜索相关解决方案后,得到的答案丰富多彩,但是真正管用的方案并不多,这里分享一个csdn上找到的方法.这个方法讲述了SQL Server 2005和SQL Server 2008在收缩数据库日志的不同之处,颇有帮助.同时,该方法的效率

由于数据库日志增长被设置为“无限制”,所以时间一长日志文件必然会很大,一个400M的数据库居然有4G的LOG文件,严重占用了磁盘空间.由于主要是做OLAP,所以数据库本身不会有大变动,所以日志也就没有多少作用了,因此想办法把数据库日志文件收缩到很小或者删除. 适用于SQL Server 2005的方法 Backup Log DNName WITH no_log GO DUMP TRANSACTION DNName WITH no_log GO USE DNName DBCC SHRINKFILE

一.基础知识 默认情况下,错误日志位于 : C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ERRORLOG 和ERRORLOG.n 文件中.默认保留有7个 SQL Server 错误日志文件,分别是:ErrorLog,Errorlog.1-Errorlog.6 ,当前的错误日志(文件ErrorLog)没有扩展名.每当启动 SQL Server 实例时,将创建新的错误日志ErrorLog,并将之前的ErrorLog更名为ErrorL

删除error咯个文件[SSQL\MSSQL10.MSSQLSERVER\MSSQL\Log目录下面] 由于默认情况下,SQL Server 保存 7 个 ErrorLog 文件,名为: ErrorLog ErrorLog.1 ErrorLog.2 ErrorLog.3 ErrorLog.4 ErrorLog.5 ErrorLog.6 --清除 SQL Server 错误日志文件 存档   EXEC sp_cycle_errorlog    GO 执行一次EXEC sp_cycle_errorl

一.背景 有一天我发现SQL Server服务器的错误日志中包括非常多关于sa用户的登陆错误信息:“Login failed for user 'sa'. 原因: 评估密码时出错.[客户端: XX.XX.XX.XX]”.可是我很久之前就已经禁用了sa用户,怎么还会有那么多的sa用户登陆信息呢?我猜想是有人在暴力破解我们数据库的sa用户的密码:关于这种攻击,大家有没好的解决方案呢? 我查找了一些资料,暂时没有找到好的解决方案.我只想到一个暂时缓解压力的办法,那就是从错误信息中统计出登陆sa用户的客