/*
重要：如果有备份，最好是从备份恢复数据。
由于带有 REPAIR 选项的 DBCC CHECKDB 已完全记录并可恢复，因此 Microsoft 始终建议用户在事务中使用带有 REPAIR 选项的 DBCC CHECKDB（在运行命令之前执行 BEGIN TRANSACTION），这样用户可确认其是否愿意接受操作的结果。 然后用户可执行 COMMIT TRANSACTION 来提交修复操作完成的所有工作。 如果用户不想接受操作的结果，可执行 ROLLBACK TRANSACTION 以撤消修复操作的影响。
若要修复错误，建议您通过备份进行还原。 修复操作不会考虑表本身或表之间可能存在的任何约束。 如果指定的表与一个或多个约束有关，建议在修复操作后运行 DBCC CHECKCONSTRAINTS。 如果必须使用 REPAIR，则运行不带有修复选项的 DBCC CHECKDB 来查找要使用的修复级别。 如果要使用 REPAIR_ALLOW_DATA_LOSS 级别，建议在运行带有此选项的 DBCC CHECKDB 之前备份数据库。
*/
--最好是禁用网络。因为单用户模式下可能会有其他客户端争抢。
--修改数据库为紧急模式
ALTER DATABASE basename SET EMERGENCY
--使数据库变为单用户模式
ALTER DATABASE basename SET SINGLE_USER
/*
指定 DBCC CHECKDB 修复发现的错误。仅将 REPAIR 选项作为最后手段使用。 指定的数据库必须处于单用户模式，才能使用以下修复选项之一。
REPAIR_ALLOW_DATA_LOSS
尝试修复报告的所有错误。 这些修复可能会导致一些数据丢失。
警告：REPAIR_ALLOW_DATA_LOSS 选项是受支持的功能，但是，它可能并非总是使数据库处于物理上一致的状态的最佳选项。 如果成功，REPAIR_ALLOW_DATA_LOSS 选项可能会导致一些数据丢失。 实际上，它可能导致的数据丢失多于用户从上次已知成功备份还原数据库导致的数据丢失。
Microsoft 始终建议用户从上次已知成功备份还原，作为从 DBCC CHECKDB 报告的错误恢复的主要方法。 REPAIR_ALLOW_DATA_LOSS 选项不是从已知成功备份还原的替代方法。 这是一个紧急选项，仅当不可从备份恢复时建议作为“最后手段”使用。
仅能使用 REPAIR_ALLOW_DATA_LOSS 选项修复的某些错误可能涉及释放行、页或一些列页以清除错误。 用户不可再访问或恢复已释放的数据，且无法确定已释放数据的准确内容。 因此，释放任何行或页后参照完整性可能不准确，因为此修复操作不包括检查或维护外键约束。 使用 REPAIR_ALLOW_DATA_LOSS 选项后，用户必须检查其数据库的参考完整性（使用 DBCC CHECKCONSTRAINTS）。
在执行修复之前，必须创建属于此数据库的文件的物理副本。 这包括主数据文件 (.mdf)、任意辅助数据文件 (.ndf)、所有事务日志文件 (.ldf) 和构成数据库的其他容器，包括全文目录、文件流文件夹、内存优化数据等。 在执行修复前，请考虑将数据库的状态更改为 EMERGENCY 模式，并尝试从关键表中提取尽可能多的信息并保存这些数据。
*/
DBCC CheckDB ( basename , REPAIR_ALLOW_DATA_LOSS)
--使数据库变回为多用户模式
ALTER DATABASE basename SET MULTI_USER
-- 使用SQL语句查看当前连接的用户
select spid,db_name(dbid) as DBname,login_time ,last_batch ,status ,hostname ,program_name ,loginame
from sys.sysprocesses
where spid >50
order by last_batch desc
--如果数据库连接被其他用户占用，请先切断。
kill 55
