广州市天河路592号百脑汇A804
电话：020-
传真：020-
广州市石牌西路8号展望数码广场405
电话：020-
传真：020-数据库置疑问题解决 - mengfanrong - 推酷
数据库置疑问题解决 - mengfanrong
1、停止数据库server，将数据库MDF文件和LDF文件复制备份一份
2、启动数据库server，删除置疑的数据库
3、仅用备份的数据库MDF文件附加数据库，sp_attach_db或者sp_attach_single_file_db能够附加数据库，出现相似以下的提示信息：
设备激活错误。物理文件名称 'C:/Program Files/Microsoft SQL Server/MSSQL/data/myDb_Log.LDF' 可能有误。
已创建名为 'C:/Program Files/Microsoft SQL Server/MSSQL/Data/myDb_log.LDF' 的新日志文件。
这个表明数据库附加成功，问题攻克了，假设成功则要恭喜你了，反正我是符加不成功，提示相似以下的错误信息
未能打开新数据库 'myDb'。CREATE DATABASE 将终止。
设备激活错误。物理文件名称 'e:/www/myDb_log.LDF' 可能有误。
此时我用了以下方法解决（參考了网上的方法）。
&& A．我们SQL SERVER企业管理器新建立一个供恢复使用的同名数据库(注意：要跟问题数据库同名，本例中为myDb)。
&& B．停掉数据库server。
&& C．将刚才生成的数据库的日志文件myDb_log.ldf删除（本例中的示列数据库名，实际使用您自己的数据库名称），用刚才备份的数据库mdf文件覆盖新生成的数据库数据文件myDb_data.mdf。
&& D．启动数据库server。此时会看到数据库myDb的状态为“置疑”。这时候不能对此数据库进行不论什么操作。
&& E．设置数据库同意直接操作系统表。此操作能够在SQL Server Enterprise Manager里面选择数据库server，按右--键，选择“属性”，在“server设置”页面中将“同意对系统文件夹直接改动”一项选中。也能够使用例如以下语句来实现。
use master
sp_configure 'allow updates',1
reconfigure with override
go&& F．设置myDb为紧急修复模式
&&&&& 在查询管理器里设置例如以下命令：
update sysdatabases set status=-32768 where dbid=DB_ID('myDb')此时能够在SQL Server Enterprise Manager里面看到该数据库处于“仅仅读/置疑/脱机/紧急模式”能够看到数据库里面的表，可是仅仅有系统表
&& G．以下运行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('myDb','C:/Program Files/Microsoft SQL Server/MSSQL/Data/myDb_log.ldf')警告: 数据库 'myDb' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，而且可能须要删除多余的日志文件。
DBCC 运行完成。假设 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“仅仅供DBO使用”。此时能够訪问数据库里面的用户表了。
&& H．验证数据库一致性（可省略）
dbcc checkdb('myDb')一般运行结果例如以下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'myDb' 中）。
DBCC 运行完成。假设 DBCC 输出了错误信息，请与系统管理员联系。
&& I．设置数据库为正常状态
sp_dboption 'myDb','dbo use only','false'&& J．最后一步，我们要将步骤E中设置的“同意对系统文件夹直接改动”一项恢复。由于平时直接操作系统表是一件比較危急的事情。当然，我们能够在SQL Server Enterprise Manager里面恢复，也能够使用例如以下语句完成
sp_configure 'allow updates',0
reconfigure with override
到此数据库置疑问题解决。
MS SQL SERVER数据库置疑后恢复步骤
--SQL SERVER数据库置疑后恢复步骤&&
--1． 恢复步骤：&&
--a.将smlog_log.ldf文件备份到其他文件夹下；&&
--b.将源文件夹下的smlog_log.ldf文件改名为smlog_log_bak.ldf；&&
--c.运行下面语句改动数据库的状态：&&
use Master&&
update sysdatabases set status=32768 where name='数据库名称'&&&& --改动状态,設為緊急狀態
shutdown with nowait&&&& --停止数据库服务器&&
--d.退出SQL并在(COMMAND)命令行模式中通过下面的代码又一次启动SQL：&&
sqlservr -c -T3608 -T4022&&&& --安全模式启动SQL SERVER
--e.在查询分析器中运行下面语句来查看刚刚改动过状态的数据库状态：&&
select Name,Status from sysdatabases where Name='数据库名稱'&
--f.运行下面代码新建日志文件：&&
dbcc traceon(3604)--跟踪&&
dbcc rebuild_log('数据库名称','日志文件全路徑') --文件名称要有全路径和扩展名
--dbcc rebuild_log('prs_msc','d:/mscsql/mssql/data/prs_msc_log.ldf
--g.将数据库置回正常状态：&&
update sysdatabases set status=0 where name='数据库名称'&&
--h.又一次启动数据库后运行下面语句检查数据库：&&
DBCC CHECKDB --假设运行完有错误用下面语句修复&&
--i.要修复数据库必需将数据库改为单用户模式：&&
Exce sp_dboption '数据库名称','single user','true'---('false'恢复多用户)&&
--j.运行下面语句修复数据库：&&
DBCC CHECKDB('数据库名称',REPAIR_ALLOW_DATA_LOSS)&&
REPAIR_ALLOW_DATA_LOSS：是比較高级的修复方式&&
REPAIR_FAST：是简单高速的修复方式
處理状态就为&置疑&的數據庫
备份数据文件,然后按下面的步骤处理:&&
1.新建一个同名的数据库(数据文件与原来的要一致)&&
2.再停掉sql server(注意不要分离数据库)&&
3.用原数据库的数据文件覆盖掉这个新建的数据库&&
4.再重新启动sql server&&
5.此时打开企业管理器时会出现置疑，先无论，运行下面的语句（注意改动当中的数据库名)&&
6.完毕后一般就能够訪问数据库中的数据了,这时,数据库本身一般还要问题,解决的方法是,利用数据库的脚本创建一个新的数据库,并将数据导进去即可了.
USE&& MASTER&&
SP_CONFIGURE 'ALLOW UPDATES',1
RECONFIGURE WITH OVERRIDE&&
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'&&
sp_dboption '置疑的数据库名','single user','true'&&
DBCC CHECKDB('置疑的数据库名')&&&&
update sysdatabases set status=28 where name='置疑的数据库名'&&
sp_configure 'allow updates',0
reconfigure with override&&
sp_dboption '置疑的数据库名', 'single user','false'&&
仅仅有mdf文件的恢复技术
由于种种原因，我们假设当时仅仅备份了mdf文件，那么恢复起来就是一件非常麻烦的事情了。
假设您的mdf文件是当前数据库产生的，那么非常侥幸，或许你使用sp_attach_db或者sp_attach_single_file_db能够恢复数据库，可是会出现相似以下的提示信息
设备激活错误。物理文件名称 'C:/Program Files/Microsoft SQL Server/MSSQL/data/test_Log.LDF' 可能有误。
已创建名为 'C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.LDF' 的新日志文件。
可是，假设您的数据库文件是从其它计算机上复制过来的，那么非常不幸，或许上述办法即可不通了。你或许会得到相似以下的错误信息
server: 消息 1813，级别 16，状态 2，行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名称 'd:/test_log.LDF' 可能有误。
怎么办呢？别着急，以下我们举例说明恢复办法。
--A．我们使用默认方式建立一个供恢复使用的数据库(如test)。能够在SQL Server Enterprise Manager里面建立。
--B．停掉数据库server。
--C．将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
--D．启动数据库server。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行不论什么操作。
--E．设置数据库同意直接操作系统表。此操作能够在SQL Server Enterprise Manager里面选择数据库server，按右--键，选择“属性”，在“server设置”页面中将“同意对系统文件夹直接改动”一项选中。也能够使用例如以下语句来实现。
use master
sp_configure 'allow updates',1
reconfigure with override
--F．设置test为紧急修复模式
--在查询管理器里设置例如以下命令：
update sysdatabases set status=-32768 where dbid=DB_ID('test')
--此时能够在SQL Server Enterprise Manager里面看到该数据库处于“仅仅读/置疑/脱机/紧急模式”能够看到数据库里面的表，可是仅仅有系统表
--G．以下运行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.ldf')
运行过程中，假设遇到下列提示信息：
server: 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以运行该操作。
DBCC 运行完成。假设 DBCC 输出了错误信息，请与系统管理员联系。
说明您的其它程序正在使用该数据库，假设刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就能够了。
正确运行完成的提示应该相似于：
警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，而且可能须要删除多余的日志文件。
DBCC 运行完成。假设 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“仅仅供DBO使用”。此时能够訪问数据库里面的用户表了。
--H．验证数据库一致性（可省略）
dbcc checkdb('test')
/*一般运行结果例如以下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。
DBCC 运行完成。假设 DBCC 输出了错误信息，请与系统管理员联系。*/
--I．设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
--假设没有出错，那么恭喜，如今就能够正常的使用恢复后的数据库啦。
--J．最后一步，我们要将步骤E中设置的“同意对系统文件夹直接改动”一项恢复。由于平时直接操作系统表是一件比較危急的事情。当然，我们能够在SQL Server Enterprise Manager里面恢复，也能够使用例如以下语句完成
sp_configure 'allow updates',0
reconfigure with override
--日志文件出现故障（丢失或文件格式非法），怎么使数据库恢复正常&&
--假设用sp_attach_single_file 'TEST','C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.mdf'失败则须要用下列步骤完毕&&
--1.将置疑的数据库分离，将mdf文件移走或改名！&&
sp_detach_db 'TEST'&&
--2.又一次在原来文件夹下建立同名的数据库TEST&&
--3.停掉SQL Service,将先前的mdf文件拷贝回来覆盖(或改名),删除原来的log文件(或改名)&&
--4.启动SQL Service(否则以下的语句没办法执行)&&
--5.将数据库设成紧急模式(status=32768)&&
sp_configure 'allow updates',1&&
reconfigure with override&&
update sysdatabases set status=32768 where name='TEST'&&
--又一次建立日志文件&&
DBCC traceon(3604)&&
dbcc rebuild_log('test','C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.ldf')&&
--6.又一次启动SQL Service&&
--7.将数据库设置成单用户模式(以下三个语句均可)&&
--sp_dboption 'TEST','single user','true'&&
update sysdatabases set status=4096 where name='TEST'&&
--alter database TEST set Single_user&&
--8.检查数据库的完整性和一致性,OK了就能够用了&&
DBCC CheckDB(TEST)&&
--9.将数据的訪问权限设置成多用户模式&&
sp_dboption 'TEST','single user','false'&&
--或alter database TEST set multi_user&&
--10.关闭高级选项&&
sp_configure 'allow updates',0&&
reconfigure with override&&
SQL Server安装挂起
在安装sql server时出现“曾经的某个程序安装已在安装计算机上创建挂起的文件操作。执行安装程序之前必须又一次启动计算机”错误。无法进行下去。 參考有关资料后,下面步骤基本能够解决：
1）加入/删除程序中彻底删除sql server。
2）将没有删除的sql server文件夹也删除掉。
3）打开注冊表编辑器，在HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/ Session Manager中找到PendingFileRenameOperations项目，并删除它。这样就能够清除安装暂挂项目。
4）删除注冊表中跟sql server相关的键
要是不想又一次启动就顺利安装，一般来说依照第三步就能够解决……
--SQL SERVER数据库置疑后恢复步骤&&
--1． 恢复步骤：&&
--a.将smlog_log.ldf文件备份到其他文件夹下；&&
--b.将源文件夹下的smlog_log.ldf文件改名为smlog_log_bak.ldf；&&
--c.运行下面语句改动数据库的状态：&&
use Master&&
update sysdatabases set status=32768 where name='数据库名称'&&&& --改动状态,設為緊急狀態
shutdown with nowait&&&& --停止数据库server&&
--d.退出SQL并在(COMMAND)命令行模式中通过下面的代码又一次启动SQL：&&
sqlservr -c -T3608 -T4022&&&& --安全模式启动SQL SERVER
--e.在查询分析器中运行下面语句来查看刚刚改动过状态的数据库状态：&&
select Name,Status from sysdatabases where Name='数据库名稱'&
--f.运行下面代码新建日志文件：&&
dbcc traceon(3604)--跟踪&&
dbcc rebuild_log('数据库名称','日志文件全路徑') --文件名称要有全路径和扩展名
--dbcc rebuild_log('prs_msc','dmscsqlmssqldataprs_msc_log.ldf
--g.将数据库置回正常状态：&&
update sysdatabases set status=0 where name='数据库名称'&&
--h.又一次启动数据库后运行下面语句检查数据库：&&
DBCC CHECKDB --假设运行完有错误用下面语句修复&&
--i.要修复数据库必需将数据库改为单用户模式：&&
Exce sp_dboption '数据库名称','single user','true'---('false'恢复多用户)&&
--j.运行下面语句修复数据库：&&
DBCC CHECKDB('数据库名称',REPAIR_ALLOW_DATA_LOSS)&&
REPAIR_ALLOW_DATA_LOSS：是比較高级的修复方式&&
REPAIR_FAST：是简单高速的修复方式
處理状态就为置疑的數據庫
备份数据文件,然后按以下的步骤处理&&
1.新建一个同名的数据库(数据文件与原来的要一致)&&
2.再停掉sql server(注意不要分离数据库)&&
3.用原数据库的数据文件覆盖掉这个新建的数据库&&
4.再重新启动sql server&&
5.此时打开企业管理器时会出现置疑，先无论，运行以下的语句（注意改动当中的数据库名)&&
6.完毕后一般就能够訪问数据库中的数据了,这时,数据库本身一般还要问题,解决的方法是,利用数据库的脚本创建一个新的数据库,并将数据导进去即可了.
USE&& MASTER&&
SP_CONFIGURE 'ALLOW UPDATES',1
RECONFIGURE WITH OVERRIDE&&
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'&&
sp_dboption '置疑的数据库名','single user','true'&&
DBCC CHECKDB('置疑的数据库名')&&&&
update sysdatabases set status=28 where name='置疑的数据库名'&&
sp_configure 'allow updates',0
reconfigure with override&&
sp_dboption '置疑的数据库名', 'single user','false'&&
唯独mdf文件的恢复技术
因为种种原因，我们假设当时只备份了mdf文件，那么恢复起来就是一件非常麻烦的事情了。
假设您的mdf文件是当前数据库产生的，那么非常侥幸，或许你使用sp_attach_db或者sp_attach_single_file_db能够恢复数据库，可是会出现相似以下的提示信息
设备激活错误。物理文件名称 'CProgram FilesMicrosoft SQL ServerMSSQLdatatest_Log.LDF' 可能有误。
已创建名为 'CProgram FilesMicrosoft SQL ServerMSSQLDatatest_log.LDF' 的新日志文件。
可是，假设您的数据库文件是从其它计算机上复制过来的，那么非常不幸，或许上述办法即可不通了。你或许会得到相似以下的错误信息
server 消息 1813，级别 16，状态 2，行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名称 'dtest_log.LDF' 可能有误。
怎么办呢？别着急，以下我们举例说明恢复办法。
--A．我们使用默认方式建立一个供恢复使用的数据库(如test)。能够在SQL Server Enterprise Manager里面建立。
--B．停掉数据库server。
--C．将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
--D．启动数据库server。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行不论什么操作。
--E．设置数据库同意直接操作系统表。此操作能够在SQL Server Enterprise Manager里面选择数据库server，按右--键，选择“属性”，在“server设置”页面中将“同意对系统文件夹直接改动”一项选中。也能够使用例如以下语句来实现。
use master
sp_configure 'allow updates',1
reconfigure with override
--F．设置test为紧急修复模式
--在查询管理器里设置例如以下命令：
update sysdatabases set status=-32768 where dbid=DB_ID('test')
--此时能够在SQL Server Enterprise Manager里面看到该数据库处于“只读置疑脱机紧急模式”能够看到数据库里面的表，可是唯独系统表
--G．以下运行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','CProgram FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf')
运行过程中，假设遇到下列提示信息：
server 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以运行该操作。
DBCC 运行完成。假设 DBCC 输出了错误信息，请与系统管理员联系。
说明您的其它程序正在使用该数据库，假设刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就能够了。
正确运行完成的提示应该相似于：
警告 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，而且可能须要删除多余的日志文件。
DBCC 运行完成。假设 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“仅仅供DBO使用”。此时能够訪问数据库里面的用户表了。
--H．验证数据库一致性（可省略）
dbcc checkdb('test')
一般运行结果例如以下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。
DBCC 运行完毕。假设 DBCC 输出了错误信息，请与系统管理员联系。
--I．设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
--假设没有出错，那么恭喜，如今就能够正常的使用恢复后的数据库啦。
--J．最后一步，我们要将步骤E中设置的“同意对系统文件夹直接改动”一项恢复。由于平时直接操作系统表是一件比較危急的事情。当然，我们能够在SQL Server Enterprise Manager里面恢复，也能够使用例如以下语句完毕
sp_configure 'allow updates',0
reconfigure with override
--日志文件出现故障（丢失或文件格式非法），怎么使数据库恢复正常&&
--假设用sp_attach_single_file 'TEST','CProgram FilesMicrosoft SQL ServerMSSQLDatatest_log.mdf'失败则须要用下列步骤完毕&&
--1.将置疑的数据库分离，将mdf文件移走或改名！&&
sp_detach_db 'TEST'&&
--2.又一次在原来文件夹下建立同名的数据库TEST&&
--3.停掉SQL Service,将先前的mdf文件拷贝回来覆盖(或改名),删除原来的log文件(或改名)&&
--4.启动SQL Service(否则以下的语句没办法执行)&&
--5.将数据库设成紧急模式(status=32768)&&
sp_configure 'allow updates',1&&
reconfigure with override&&
update sysdatabases set status=32768 where name='TEST'&&
--又一次建立日志文件&&
DBCC traceon(3604)&&
dbcc rebuild_log('test','CProgram FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf')&&
--6.又一次启动SQL Service&&
--7.将数据库设置成单用户模式(以下三个语句均可)&&
--sp_dboption 'TEST','single user','true'&&
update sysdatabases set status=4096 where name='TEST'&&
--alter database TEST set Single_user&&
--8.检查数据库的完整性和一致性,OK了就能够用了&&
DBCC CheckDB(TEST)&&
--9.将数据的訪问权限设置成多用户模式&&
sp_dboption 'TEST','single user','false'&&
--或alter database TEST set multi_user&&
--10.关闭高级选项&&
sp_configure 'allow updates',0&&
reconfigure with override&&
怎样修复SQLSERVER 数据库&置疑&之(二) 收藏
&&&&& 假设 SQL Server 由于磁盘可用空间不足，而不能完毕数据库的恢复，那么& SQL Server 2000 会返回错误 1105 而且将 sysdatabases 中的 status 列设为置疑。
你能够看到在SQLSERVER 的ERROR LOG 和OS的应用程序日志中应该有1105的错误信息:
SQL Server事务日志可能会被填满，这会阻止之后的数据库操作，包含UPDATE， DELETE， INSERT 和CHECKPOINT。
事务日志填满会导致1105错误:
&&& Can't allocate space for object syslogs in database dbname because
&&& the logsegment is full。 If you ran out of space in syslogs， dump
&&& the transaction log。 Otherwise use ALTER DATABASE or
&&& sp_extendsegment to increase the size of the segment。
这样的现象可能出现于不论什么一个数据库中，包含Master和TempDB。一些难以预见的因素可能消耗日志空间。 比如:
一个大型事务， 尤其像批量数据更新、插入或删除。
一个未提交的事务。
检查点处理程序截除时所需的带宽过大。
截除时超过阈值
上述各种条件互相作用的结果。
用于公布的标记事务没有被日志读取程序读走
以下是修复的步骤和收缩日志的步骤:
1.在命令提示符下执行下面命令启动 SQL Server：
SQLSERVER -f -m
备注：-m 开关以单用户模式启动 SQL Server。在单用户模式下，仅仅能成功建立一个连接。 请注意是否有不论什么其它客户机或服务可能会在您通过 SQL Server 查询分析器&&& 建立连接前使用那个连接。
2. 重置置疑数据库的状态。
sp_resetstatus 'database_name'
以下是结果集：
Database'database_name'status reset!
&WARNING: You must reboot SQL Server prior to accessing this database!
3. 用 ALTER DATABASE 向数据库加入一个数据文件或日志文件:
USE master
&CREATE DATABASE db_name ON
& NAME = dbname_dat1,
& FILENAME = 'D:/MSSQL/Data/dbname_dat1.ndf',
& SIZE = 1000MB,
& FILEGROWTH = 50MB
&GO&--更改该数据库以加入一个 2GB 大小的新数据文件
&ALTER DATABASE db_name
& NAME = dbname_dat2,
& FILENAME = 'F:/MSSQL/DATA/dbname_dat2.ndf',
& SIZE = 2000MB,
& FILEGROWTH = 50MB
&--更改该数据库以加入一个1GB 大小的新日志文件
&ALTER DATABASE db_name
&ADD LOG FILE
&( NAME = db_name_log2,
&& FILENAME = 'F:/MSSQL/Data/db_name_log2.ldf',
&& SIZE = 1000MB,
&& FILEGROWTH = 20MB),
&&& 4. 停止并又一次启动 SQL Server:
&& 用新的数据文件或日志文件所提供的额外空间，SQL Server 应该能完毕数据库的恢复。
5. 释放磁盘空间而且又一次执行恢复操作,依照以下的步骤收缩日志。
&sp_resetstatus 关闭数据库的置疑标志，可是原封不动地保持数据库的其他选项。
为从根本上解决这种问题,你能够按以下的操作配置SQLSERVER 2000:
a.假设不须要恢复到指定的时间点,你能够将数据库的恢复模式配置为简单,这样
UPDATE,DELETE,SELECT就不会记录日志,日志就不会添加的非常大:
USE MASTER
&&&& ALTER DATABASE DB_NAME SET RECOVERY SIMPLE
b.假设你的恢复模式是所有,你一定要配置日志字段收缩:
USE MASTER
&&& sp_dboption 'databasename','trunc. log on chkpt.',true
&&& sp_dboption 'databasename','autoshrink',true
c.通过每日备份将日志收缩:
&& BACKUP DATABASE DATABASE_NAME TO BACKUP_DEVICES
&& BACKUP LOG DATABASE_NAME TO LOG_DEVICES
&& BACKUP LOG DATABASE_NAME with truncate_only
**检查日志的容量:DBCC SQLPERF (LOGSPACE) 这时日志并没有收缩!
d.每天在备份数据库完毕之后,又一次启动MS SQLSERVER SERVICE.
&&&& USE DATABASE_NAME
&&&& DBCC& SHRINKFILE(2,truncateonly)
**检查日志的容量:DBCC SQLPERF (LOGSPACE) 这时日志已经收缩!
e.手动高速收缩日志:
& / *run& below& script,you& will& shrink& you& database& log& files
immediately,& in& my& experience,you& need& to& run& the& script& for& 3& or
4& minutes& before stopping& it& manually& */
use& databasename
dbcc& shrinkfile(2,notruncate)
dbcc& shrinkfile(2,truncateonly)
create& table& t1(char1& char(4000))
declare& @i& int
select& @i=0
while(1=1)
&&&& while(@i&100)
&&&&&&&&&&&& begin
&&&&&&&&&& INSERT& INTO& T1& VALUES& ('A')
&&&&&&&&&& SELECT& @I=@I+1
&&&&&&&&&& END
TRUNCATE& table& T1
BACKUP& LOG& youdatabasename& with& truncate_only
注意& 仅仅有在您的主要支持提供者指导下或有疑难解答建议的做法时，才干够使用
&sp_resetstatus。否则，可能会损坏数据库。
因为该过程改动了系统表，系统管理员必须在执行 sp_resetstatus这个过程前，启用系统表更新。要
启 用更新，使用以下的过程：
USE master
&sp_configure 'allow updates', 1
&RECONFIGURE WITH OVERRIDE
&过程创建后，马上禁用系统表更新：
sp_configure 'allow updates', 0
&RECONFIGURE WITH OVERRIDE
&仅仅有系统管理员才干运行 sp_resetstatus。运行该过程后，马上关闭 SQL Server。
本文来自CSDN博客，转载请标明出处：
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致