MS-SQLSERVER数据库SUSPECT状态如何解决
MS-SQLSERVER数据库SUSPECT状态如何解决
如何重置数据库Suppect(置疑)状态
一、 出现这种情况的原因
如果在日常运行当中，数据库的文件或日志增长方式设为以下两种模式：
1、 文件不自动增长
此种状态下，如果数据库中的数据或日志增长到设定的文件大小时，继续添加数据时就没有足够的空间时，MS SQL SERVER将把数据库标记为Suspect（置疑）
2、 文件自动增长但限制最大文件大小
此种状态下，如果数据库中的数据或日志增长到设定的最大文件大小时，继续添加数据时就没有足够的空间时，MS SQL SERVER将把数据库标记为Suspect（置疑）
3、 文件自动增长也没限制文件大小，但存放文件的磁盘剩余空间不够了
4、 意外掉电，造成磁盘文件损坏
5、
二、解决方法：
3、
方法一：
释放含有相关数据库日志文件的任意磁盘驱动器上的磁盘空间。释放的磁盘空间使恢复系统可以自动地增长数据或事务日志文件。
执行 sp_resetstatus 重置置疑状态。
通过执行 DBCC DBRECOVER（数据库）运行恢复操作。
方法二：
释放另一个磁盘驱动器上的磁盘空间。
把可用磁盘空间不足的事务日志文件移动到第一步所指的磁盘驱动器上。
执行 sp_detach_db 分离数据库。
执行 sp_attach_db 附加数据库，指向被移动的文件。
方法三：
向置疑数据库添加一个日志文件，然后执行 sp_add_log_file_recover_suspect_db 以便在数据库上运行恢复操作。
解决错误信息 1105，然后使数据库联机
对于任意一个含有错误信息 1105 提到的文件组中文件的磁盘，释放其磁盘空间。释放磁盘空间使得文件组中的文件可以增长。
执行 sp_resetstatus 重置置疑状态。
执行 DBCC DBRECOVER（数据库）运行恢复操作。
方法四：
释放另一个磁盘驱动器上的磁盘空间。
将可用磁盘空间不足的文件组中的数据文件移动到第一步所指的磁盘驱动器上。
执行 sp_detach_db 分离数据库。
执行 sp_attach_db 附加数据库，指向被移动的文件。
方法五：
向置疑数据库添加一个数据文件，然后执行 sp_add_data_file_recover_suspect_db 以便在数据库上运行恢复操作。
执行 sp_resetstatus。
用 ALTER DATABASE 向数据库添加一个数据文件或日志文件。
停止并重新启动 SQL Server。
用新的数据文件或日志文件所提供的额外空间，SQL Server 应该能完成数据库的恢复。
释放磁盘空间并且重新运行恢复操作。
sp_resetstatus 关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项。
注意 只有在您的主要支持提供者指导下或有疑难解答建议的做法时，才可以使用 sp_resetstatus。
否则，可能会损坏数据库。
由于该过程修改了系统表，系统管理员必须在创建这个过程前，启用系统表更新。要启用更新，使用下面的过程：
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
过程创建后，立即禁用系统表更新：
sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
只有系统管理员才能执行 sp_resetstatus。执行该过程后，立即关闭 SQL Server。
语法为：
sp_resetstatus database_name
下面的例子将关闭 PRODUCTION 数据库的置疑标志。
sp_resetstatus PRODUCTION
下面是结果集：
Database 'PRODUCTION' status reset!
WARNING: You must reboot SQL Server prior to accessing this database!
注释
sp_resetstatus 关闭数据库上的置疑标记。此过程更新 sysdatabases 中的命名数据库的模式和状态列。
在运行此过程之前，应参考 SQL Server 错误日志并解决所有问题。执行 sp_resetstatus 后停止并重新启动 SQL Server。
由于某些原因，数据库可能成为置疑状态。可能的原因包括操作系统拒绝对数据库资源的访问，以及一个或多个数据库文件不可用性或已损坏。
权限
只有 sysadmin 固定服务器角色成员才能执行 sp_resetstatus。
示例
下例重置 PUBS 数据库的状态。
EXEC sp_resetstatus 'PUBS'
数据文件空间不足：
sp_add_data_file_recover_suspect_db
当由于文件组上的"空间不足"(1105) 错误而导致一个数据库上的恢复不能完成时，请为文件组添加一个数据文件。添加日志文件后，该存储过程关闭置疑设置并完成数据库的故障恢复。该参数和 ALTER DATABASE ADD FILE 的参数相同。
示例
在下面的示例中，由于文件组 fg1 中空间不足（错误 1105），数据库 db1 被标记为置疑。
sp_add_data_file_recover_suspect_db db1, fg1, file2,
'c:/Program Files/Microsoft SQL Server/MSSQL/Data/db1_file2.mdf', '1MB'
日志空间不足：
sp_add_log_file_recover_suspect_db
由于数据库上"日志空间不足"(9002) 错误造成恢复不能完成时，请将日志文件添加到文件组中。添加日志文件后，该存储过程关闭置疑设置并完成数据库的故障恢复。参数与 ALTER DATABASE ADD LOG FILE 中的参数相同。
权限
执行权限默认赋予 sysadmin 固定服务器角色的成员。这些权限是不可传递的。
示例
在此示例中，数据库 db1 在故障恢复期间由于日志空间不足（错误 9002）而标记为置疑。
sp_add_log_file_recover_suspect_db db1, logfile2,
'c:/Program Files/Microsoft SQL Server/MSSQL/Data/db1_logfile2.ldf',
'1MB'
严重级别 22：SQL Server 严重错误表的完整性置疑
这些消息表明消息中所指定的表或索引已因软件或硬件问题而损坏。
严重级别 22 错误很少发生；但是，如果遇到该错误，请运行 DBCC CHECKDB 确定数据库中是否有其它对象也受损坏。问题有可能只存在于超速缓存中，而不是存在于磁盘本身。如果是这样，重新启动 SQL Server 将修正该问题。要继续工作，必须重新连接到 SQL Server。否则，用 DBCC 修复该问题。有些情况下，有必要还原数据库。
如果重新启动帮助不大，则问题存在于磁盘上。有时，摧毁在错误信息中指定的对象可以解决该问题。例如，如果消息说 SQL Server 在非聚集索引中发现长度为 0 的行，删除该索引然后重建。
严重级别 23：SQL Server 严重错误：数据库完整性置疑
这些消息表明由于硬件或软件问题，整个数据库完整性存在问题。
严重级别 23 错误很少发生；但是，如果遇到，请运行 DBCC CHECKDB 确定损坏的程度。问题有可能只存在于超速缓存中，而不是存在于磁盘本身。如果是这样，重新启动 SQL Server 将修正该问题。要继续工作，必须重新连接到 SQL Server。否则，用 DBCC 修复该问题。有些情况下，有必要重新启动数据库。
DBCC CHECKDB 建议
在 Microsoft? SQL Server? 2000 中，可以在用户使用数据库时运行 DBCC CHECKDB，因为 DBCC CHECKDB 在检查每个数据库表时在表上控制的锁的类型均更改。
在 SQL Server 7.0 和早期版本中，DBCC CHECKDB（依次在数据库的每个表上运行 DBCC CHECKTABLE 和 CHECKALLOC）常常在表上控制共享锁 (S)，因而阻塞了所有的数据修改语言 (DML) 语句。
在 SQL Server 2000 中，当检查表时 DBCC CHECKDB 在表上控制架构锁以防止元数据的更改，因而允许在正在检查的表上使用除任何数据定义语言 (DDL) 语句之外的 DML 语句。该变化对于决定何时运行 DBCC CHECKDB 提供了更大的灵活性，因为 DBCC CHECKDB 并不完全拒绝用户对系统的使用。
DBCC CHECKDB 是大量占用 CPU 和磁盘的操作。每一个需要检查的数据页都必须首先从磁盘读入内存。另外，DBCC CHECKDB 使用 tempdb 排序。
如果在 DBCC CHECKDB 运行时动态执行事务，那么事务日志会继续增长，因为 DBCC 命令在完成日志的读取之前阻塞日志截断。
建议在服务器负荷较少的时候运行 DBCC CHECKDB。如果在负荷高峰期运行 DBCC CHECKDB，那么事务吞吐量性能和 DBCC CHECKDB 完成时间性能都会受到影响。
要获得好的 DBCC 性能的一些建议
在系统使用率较低时运行 CHECKDB。
请确保未同时执行其它磁盘 I/O 操作，例如磁盘备份。
将 tempdb 放到单独的磁盘系统或快速磁盘子系统中。
允许 tempdb 在驱动器上有足够的扩展空间。使用带有 ESTIMATE ONLY 的 DBCC 估计 tempdb 将需要多少空间。
避免运行占用大量 CPU 的查询或批处理作业。
在 DBCC 命令运行时，减少活动事务。
使用 NO_INFOMSGS 选项显著减少处理和 tempdb 的使用。
考虑使用带有 PHYSICAL_ONLY 选项的 DBCC CHECKDB 来检查页和记录首部的物理结构。当硬件导致的错误被置疑时，这个操作将执行快速检查。
如何重置数据库Suppect(置疑)状态
一、 出现这种情况的原因
如果在日常运行当中，数据库的文件或日志增长方式设为以下两种模式：
1、 文件不自动增长
此种状态下，如果数据库中的数据或日志增长到设定的文件大小时，继续添加数据时就没有足够的空间时，MS SQL SERVER将把数据库标记为Suspect（置疑）
2、 文件自动增长但限制最大文件大小
此种状态下，如果数据库中的数据或日志增长到设定的最大文件大小时，继续添加数据时就没有足够的空间时，MS SQL SERVER将把数据库标记为Suspect（置疑）
3、 文件自动增长也没限制文件大小，但存放文件的磁盘剩余空间不够了
4、 意外掉电，造成磁盘文件损坏
5、
二、解决方法：
3、
方法一：
释放含有相关数据库日志文件的任意磁盘驱动器上的磁盘空间。释放的磁盘空间使恢复系统可以自动地增长数据或事务日志文件。
执行 sp_resetstatus 重置置疑状态。
通过执行 DBCC DBRECOVER（数据库）运行恢复操作。
方法二：
释放另一个磁盘驱动器上的磁盘空间。
把可用磁盘空间不足的事务日志文件移动到第一步所指的磁盘驱动器上。
执行 sp_detach_db 分离数据库。
执行 sp_attach_db 附加数据库，指向被移动的文件。
方法三：
向置疑数据库添加一个日志文件，然后执行 sp_add_log_file_recover_suspect_db 以便在数据库上运行恢复操作。
解决错误信息 1105，然后使数据库联机
对于任意一个含有错误信息 1105 提到的文件组中文件的磁盘，释放其磁盘空间。释放磁盘空间使得文件组中的文件可以增长。
执行 sp_resetstatus 重置置疑状态。
执行 DBCC DBRECOVER（数据库）运行恢复操作。
方法四：
释放另一个磁盘驱动器上的磁盘空间。
将可用磁盘空间不足的文件组中的数据文件移动到第一步所指的磁盘驱动器上。
执行 sp_detach_db 分离数据库。
执行 sp_attach_db 附加数据库，指向被移动的文件。
方法五：
向置疑数据库添加一个数据文件，然后执行 sp_add_data_file_recover_suspect_db 以便在数据库上运行恢复操作。
执行 sp_resetstatus。
用 ALTER DATABASE 向数据库添加一个数据文件或日志文件。
停止并重新启动 SQL Server。
用新的数据文件或日志文件所提供的额外空间，SQL Server 应该能完成数据库的恢复。
释放磁盘空间并且重新运行恢复操作。
sp_resetstatus 关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项。
注意 只有在您的主要支持提供者指导下或有疑难解答建议的做法时，才可以使用 sp_resetstatus。
否则，可能会损坏数据库。
由于该过程修改了系统表，系统管理员必须在创建这个过程前，启用系统表更新。要启用更新，使用下面的过程：
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
过程创建后，立即禁用系统表更新：
sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
只有系统管理员才能执行 sp_resetstatus。执行该过程后，立即关闭 SQL Server。
语法为：
sp_resetstatus database_name
下面的例子将关闭 PRODUCTION 数据库的置疑标志。
sp_resetstatus PRODUCTION
下面是结果集：
Database 'PRODUCTION' status reset!
WARNING: You must reboot SQL Server prior to accessing this database!
注释
sp_resetstatus 关闭数据库上的置疑标记。此过程更新 sysdatabases 中的命名数据库的模式和状态列。
在运行此过程之前，应参考 SQL Server 错误日志并解决所有问题。执行 sp_resetstatus 后停止并重新启动 SQL Server。
由于某些原因，数据库可能成为置疑状态。可能的原因包括操作系统拒绝对数据库资源的访问，以及一个或多个数据库文件不可用性或已损坏。
权限
只有 sysadmin 固定服务器角色成员才能执行 sp_resetstatus。
示例
下例重置 PUBS 数据库的状态。
EXEC sp_resetstatus 'PUBS'
数据文件空间不足：
sp_add_data_file_recover_suspect_db
当由于文件组上的"空间不足"(1105) 错误而导致一个数据库上的恢复不能完成时，请为文件组添加一个数据文件。添加日志文件后，该存储过程关闭置疑设置并完成数据库的故障恢复。该参数和 ALTER DATABASE ADD FILE 的参数相同。
示例
在下面的示例中，由于文件组 fg1 中空间不足（错误 1105），数据库 db1 被标记为置疑。
sp_add_data_file_recover_suspect_db db1, fg1, file2,
'c:/Program Files/Microsoft SQL Server/MSSQL/Data/db1_file2.mdf', '1MB'
日志空间不足：
sp_add_log_file_recover_suspect_db
由于数据库上"日志空间不足"(9002) 错误造成恢复不能完成时，请将日志文件添加到文件组中。添加日志文件后，该存储过程关闭置疑设置并完成数据库的故障恢复。参数与 ALTER DATABASE ADD LOG FILE 中的参数相同。
权限
执行权限默认赋予 sysadmin 固定服务器角色的成员。这些权限是不可传递的。
示例
在此示例中，数据库 db1 在故障恢复期间由于日志空间不足（错误 9002）而标记为置疑。
sp_add_log_file_recover_suspect_db db1, logfile2,
'c:/Program Files/Microsoft SQL Server/MSSQL/Data/db1_logfile2.ldf',
'1MB'
严重级别 22：SQL Server 严重错误表的完整性置疑
这些消息表明消息中所指定的表或索引已因软件或硬件问题而损坏。
严重级别 22 错误很少发生；但是，如果遇到该错误，请运行 DBCC CHECKDB 确定数据库中是否有其它对象也受损坏。问题有可能只存在于超速缓存中，而不是存在于磁盘本身。如果是这样，重新启动 SQL Server 将修正该问题。要继续工作，必须重新连接到 SQL Server。否则，用 DBCC 修复该问题。有些情况下，有必要还原数据库。
如果重新启动帮助不大，则问题存在于磁盘上。有时，摧毁在错误信息中指定的对象可以解决该问题。例如，如果消息说 SQL Server 在非聚集索引中发现长度为 0 的行，删除该索引然后重建。
严重级别 23：SQL Server 严重错误：数据库完整性置疑
这些消息表明由于硬件或软件问题，整个数据库完整性存在问题。
严重级别 23 错误很少发生；但是，如果遇到，请运行 DBCC CHECKDB 确定损坏的程度。问题有可能只存在于超速缓存中，而不是存在于磁盘本身。如果是这样，重新启动 SQL Server 将修正该问题。要继续工作，必须重新连接到 SQL Server。否则，用 DBCC 修复该问题。有些情况下，有必要重新启动数据库。
DBCC CHECKDB 建议
在 Microsoft? SQL Server? 2000 中，可以在用户使用数据库时运行 DBCC CHECKDB，因为 DBCC CHECKDB 在检查每个数据库表时在表上控制的锁的类型均更改。
在 SQL Server 7.0 和早期版本中，DBCC CHECKDB（依次在数据库的每个表上运行 DBCC CHECKTABLE 和 CHECKALLOC）常常在表上控制共享锁 (S)，因而阻塞了所有的数据修改语言 (DML) 语句。
在 SQL Server 2000 中，当检查表时 DBCC CHECKDB 在表上控制架构锁以防止元数据的更改，因而允许在正在检查的表上使用除任何数据定义语言 (DDL) 语句之外的 DML 语句。该变化对于决定何时运行 DBCC CHECKDB 提供了更大的灵活性，因为 DBCC CHECKDB 并不完全拒绝用户对系统的使用。
DBCC CHECKDB 是大量占用 CPU 和磁盘的操作。每一个需要检查的数据页都必须首先从磁盘读入内存。另外，DBCC CHECKDB 使用 tempdb 排序。
如果在 DBCC CHECKDB 运行时动态执行事务，那么事务日志会继续增长，因为 DBCC 命令在完成日志的读取之前阻塞日志截断。
建议在服务器负荷较少的时候运行 DBCC CHECKDB。如果在负荷高峰期运行 DBCC CHECKDB，那么事务吞吐量性能和 DBCC CHECKDB 完成时间性能都会受到影响。
要获得好的 DBCC 性能的一些建议
在系统使用率较低时运行 CHECKDB。
请确保未同时执行其它磁盘 I/O 操作，例如磁盘备份。
将 tempdb 放到单独的磁盘系统或快速磁盘子系统中。
允许 tempdb 在驱动器上有足够的扩展空间。使用带有 ESTIMATE ONLY 的 DBCC 估计 tempdb 将需要多少空间。
避免运行占用大量 CPU 的查询或批处理作业。
在 DBCC 命令运行时，减少活动事务。
使用 NO_INFOMSGS 选项显著减少处理和 tempdb 的使用。
考虑使用带有 PHYSICAL_ONLY 选项的 DBCC CHECKDB 来检查页和记录首部的物理结构。当硬件导致的错误被置疑时，这个操作将执行快速检查。