如何解决无法打开数据库，恢复 *** 作已将数据标记为suspect。

5. 释放磁盘空间并且重新运行恢复 *** 作,按照下面的步骤收缩日志。

sp_resetstatus 关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项。

为从根本上解决这样的问题,你可以按下面的 *** 作配置SQLSERVER 2000:

a.如果不需要恢复到指定的时间点,你可以将数据库的恢复模式配置为简单,这样

UPDATE,DELETE,SELECT就不会记录日志,日志就不会增加的很大:

USE MASTER

GO

ALTER DATABASE DB_NAME SET RECOVERY SIMPLE

b.如果你的恢复模式是全部,你一定要配置日志字段收缩:

USE MASTER

GO

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

OR

BACKUP LOG DATABASE_NAME with truncate_only

**检查日志的容量:DBCC SQLPERF (LOGSPACE) 这时日志并没有收缩!

d.每天在备份数据库完成之后,重新启动MS SQLSERVER SERVICE.

USE DATABASE_NAME

go

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))

go

declare @i int

select @i=0

while(1=1)

begin

while(@i<100)

begin

INSERT INTO T1 VALUES ('A')

SELECT @I=@I+1

END

TRUNCATE table T1

BACKUP LOG youdatabasename with truncate_only

end

GO

注意 只有在您的主要支持提供者指导下或有疑难解答建议的做法时，才可以使用

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。

仲裁是数据库镜像会话中两个或多个服务器实例彼此连接时存在的一种关系。仲裁通常包括三个互连的服务器实例。设置见证服务器时，必须具有仲裁才能使用数据库。仲裁旨在用于具有自动故障转移功能的高安全性模式，可确保一个数据库一次只属于一个伙伴。 如果特定的服务器实例与镜像会话断开连接，则该实例将失去仲裁。如果没有连接任何服务器实例，则会话将失去仲裁，并无法使用数据库。可以进行的仲裁有三种： “完全仲裁”包含伙伴双方以及见证服务器。

“见证服务器-伙伴仲裁”包含见证服务器和一个伙伴。

“伙伴-伙伴仲裁”包含伙伴双方。

下图显示了这三种类型的仲裁。只要当前的主体服务器具有仲裁，它就拥有主体服务器的角色并可继续 *** 作数据库，除非数据库所有者执行手动故障转移。如果主体服务器失去仲裁，它将停止 *** 作数据库。仅当主体服务器失去仲裁时，才会发生自动故障转移，这确保它不再 *** 作数据库。 断开连接的服务器实例将保存其在会话中的最新角色。通常，断开连接的服务器实例将在重新启动并重新获得仲裁时重新连接到会话。 重要提示： 只有在需要使用具有自动故障转移功能的高安全性模式时，才应设置见证服务器。在高性能模式下，由于从不需要见证服务器，因此极力建议将 WITNESS 属性设置为 OFF。有关见证服务器如何影响高性能模式会话中数据库可用性的信息，请参阅异步数据库镜像（高性能模式）。

高安全性模式会话中的仲裁在高安全性模式下，仲裁通过提供上下文来允许自动故障转移，在这个上下文中，具有仲裁的服务器实例可以判定哪个伙伴拥有主体服务器角色。主体服务器如果具有仲裁就可以 *** 作数据库。如果在同步的镜像服务器和见证服务器仍具有仲裁的时候主体服务器丢失仲裁，则会发生自动故障转移。 高安全性模式的仲裁方案包括： 包含伙伴双方和见证服务器的“完全仲裁”。

所有三个服务器实例通常都参与三方仲裁，这称为“完全仲裁”。使用完全仲裁，主体服务器和镜像服务器一直执行其各自的角色（除非发生手动故障转移）。

包含见证服务器和一个伙伴的“见证服务器-伙伴仲裁”。

如果因为其中一个伙伴丢失而中断伙伴之间的网络连接，则可能发生下列两种情况：

镜像服务器丢失，主体服务器和见证服务器仍具有仲裁。

在这种情况下，主体服务器将数据库设置为 DISCONNECTED，并在镜像处于 SUSPENDED 状态的情况下运行。（因为数据库当前尚未镜像，所以这称为“公开运行”。）镜像服务器重新联接会话时，它将作为镜像服务器重新获得仲裁，并开始与其数据库副本重新同步。

主体服务器丢失，见证服务器和镜像服务器仍具有仲裁。

在这种情况下，发生自动故障转移。有关详细信息，请参阅自动故障转移。

两个伙伴与见证服务器之间保持连接时，故障转移伙伴之间的网络连接很少会断开。在这种情况下，存在两个分开的见证服务器-伙伴仲裁，见证服务器作为连接。见证服务器将通知镜像服务器：主体服务器仍在连接状态。因此，不会出现自动故障转移。而镜像服务器将保留镜像角色并等待重新连接到主体服务器。如果此时重做队列包含日志记录，镜像服务器将继续前滚镜像数据库。重新连接后，镜像服务器将与镜像数据库重新同步。

包含伙伴双方的“伙伴-伙伴仲裁”。

只要伙伴仍具有仲裁，数据库就会继续处于 SYNCHRONIZED 状态，手动故障转移就可以进行。如果没有见证服务器，则无法使用自动故障转移功能；但当见证服务器重新获得仲裁时，会话将恢复正常 *** 作，并重新支持自动故障转移。

会话丢失仲裁。

如果所有服务器实例此间的连接断开，就称为会话“丢失仲裁”。当服务器实例恢复彼此间的连接时，它们将重新获得相互仲裁。

如果主体服务器与其他服务器实例中的任何一个重新连接，即可使用数据库。

如果主体服务器依旧断开连接，但镜像服务器和见证服务器恢复了相互之间的连接，则不能进行自动故障转移，因为可能会丢失数据。因此，在主体服务器重新加入会话之前，依旧不能使用数据库。

当三个服务器实例全部恢复连接时，将重新获得完全仲裁，会话将恢复其正常 *** 作。

重要提示： 当会话具有伙伴-伙伴仲裁时，如果任一伙伴失去仲裁，会话将失去仲裁。因此，如果您希望见证服务器在很长一段时间内保持断开，我们建议您暂时将见证服务器从会话中删除。如果删除见证服务器，则不再需要仲裁。然后，如果镜像服务器断开连接，则主体服务器可以继续 *** 作数据库。有关如何添加或删除见证服务器的信息，请参阅数据库镜像见证服务器。

仲裁如何影响数据库可用性下图显示的是见证服务器与伙伴如何相互作用，以确保在给定时间内，只有一个伙伴拥有主体服务器角色并且只有当前主体服务器才能使其数据库在线。两个方案都以完全仲裁（Partner_A 具有主体角色，Partner_B 具有镜像角色）为起点。方案1 显示的是：在原始主体服务器 (Partner_A) 失败后，见证服务器和镜像服务器如何同时认定主体 Partner_A 不再可用并构造仲裁。然后，镜像服务器 Partner_B 承担主体角色。出现自动故障转移时，Partner_B 使其数据库副本在线。然后 Partner_B 出现故障，数据库离线。随后，先前的主体服务器 Partner_A 重新连接到见证服务器重新获取仲裁，但是通过与见证服务器通信，Partner_A 获知不能使其数据库副本在线，因为 Partner_B 现在拥有主体角色。当 Partner_B 重新加入会话时，将使数据库恢复在线。在方案 2 中，见证服务器丢失仲裁，而伙伴 Partner_A 和Partner_B 彼此保留仲裁，数据库保持在线。然后，伙伴们也失去其仲裁，数据库处于离线状态。随后，主体服务器 Partner_A 重新连接到见证服务器以重新获取仲裁。见证服务器确认 Partner_A 仍拥有主体角色，并且 Partner_A 使数据库恢复在线。

挂起不必然就有问题，有时辰资本紧缺，会优先分配权限给此外历程，这时辰有些历程就会挂起。直到资阅暌剐余暇的时辰再措置，可是我初步估量是你的压缩太狠了，还有，你这个事实是压缩仍是缩短啊？我对一个3000万的表进行压缩（2008才有），都没有问题。可是缩短的话，如不美观一次性缩短太年夜规模，会期待良久，我就试过等了几个小时都还没好。后来kill失踪这个历程，然后500M一次来缩短，几分钟就好了。只要你kill的时辰是期待它完成而不是直接重启处事的话，一般不会有侍趵硎题，可是你直接重启处事可能会导致数据库不成用等后不美观。kill也是一个事务，你运行了多久，可能就要期待它回滚多久。有可能的话就等它kill完，否则......重启吧。不是每次城市出意外的

---