有没有办法找出DBCC SHRINKFILE语句的进度？
这是我运行它的方式
dbcc 收缩文件（'main_data'，250000）
我在 SQL Server 2005 和 2008 上运行上述语句。
[更新] 这是我为了检查进度和正在运行的文本而运行的查询。
select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
, R.cpu_time, R.total_elapsed_time, R.percent_complete
from sys.dm_exec_requests R
cross apply sys.dm_exec_sql_text(R.sql_handle) T
可以为数据库启用许多 SQL Server 选项，其中最容易被误解的选项之一是自动收缩。安全吗？如果没有，为什么不呢？
我开始看到具有数百 TB 数据的客户端（在 SQL Server 安装中）。由于某些企业中的数据总量接近 PB 的有意义的部分，我想浏览那里的集体知识库，以了解处理如此大量数据的人正在采取哪些措施来保护它。
一个明显的问题是存储这么多数据的多个备份非常昂贵，使用企业级存储，见鬼，甚至只是 RAID-5。
我看到的选项如下：
我看到选项 #4 被采用为默认值，作为 HA/DR 专家，这真的很可怕，但我有什么建议作为替代方案？我认为 #1 是最好的方法，但是当建议除 #4 和 #3 之外的任何替代方案时，“我不这么认为”是通常的答案。
现在，当然这取决于数据的变化率和重要性。无需回答这个问题，因为我在 Microsoft 工作期间曾负责 SQL Server 的所有 HA 功能，所以我精通“视情况而定”的论点——这是我的口号:-)
我很想知道我错过的任何替代方案，或者听到其他人都在同一条船上，除了花费大量资金购买更多存储空间之外，没有现实的替代方案。
提前致谢 - 所有经过深思熟虑和明确表达的答案都将得到应有的赞誉。
这不是一个我应该如何做的问题，只是为了设置舞台。这是你的经历是什么？请在快速回复之前通读整个问题。
昨天我花了一天时间向当前一轮 SharePoint MCM（Microsoft 认证大师 - 请参阅此处）的学生讲授SQL Server 中的所有高可用性技术，以及 SQL 日志/恢复/备份/还原的工作原理。这非常重要，因为在每个企业级 MOSS 安装下都有一个隐藏的企业级 SQL Server，通常没有 DBA。Kimberly 在周五教他们一天的数据库维护（我们教的 SQL MCM 第一周的缩小版本）。
我们讨论了使用数据库镜像为 SharePoint 数据库提供高可用性的可能性，以及相关的利弊。现在，我知道数据库镜像到它的最低内部深度，因为我曾经在 Microsoft 拥有它，因此无需在您的回复中指出行为和特质。我还知道 SharePoint 人员的镜像白皮书中的各种警告和指南，是的，它们只是通用指南，而不是硬性规则。
我的问题是：我想听听为 SharePoint 实施数据库镜像的任何人，以及您是否发现它对您有用，或者您崩溃和烧毁。特别是，您如何发现故障转移行为对您有用？您是否最终在一台服务器上使用了一些数据库主体，而在另一台服务器上使用了一些数据库主体，从而有效地拆分了您的场并使其无法使用，直到手动干预将所有内容都转移到一台服务器上？您是否将其用于本地或远程 HA？等等。
我们将不胜感激地收到任何答复，这将有助于扩大结合这两种技术的知识库，我会将故事反馈回 SharePoint 产品组，以及我教授的未来 MCM 轮换。
谢谢！
[编辑：PS 我也会在周末写一篇关于经验和指导方针的博客文章]
昨天在教授 MCM 时与 SharePoint 专家交谈的另一个问题。SharePoint 准则是不支持 100GB 以上的内容数据库。没有进入这些准则背后的原因，我很感兴趣地听到内容数据库更大的比100GB，并与他们您的经验（主要是围绕着性能，灾难恢复，以及医管局供应）。
您设法将 SharePoint 安装推到什么程度？我听说过 > 1TB 内容数据库的二手故事，但我想听听 SharePoint 管理员本人的意见。
感谢您提供的任何信息。
我对幽灵清理过程的理解是，每五秒它就会寻找删除索引中的幽灵记录。因此它不会使系统过载，它一次只能“清理”大约十页。
那么，这意味着它每五秒只清理大约 8 万条记录吗？似乎我的索引总是充满了幻影记录，清理工作永远不会完成。
所以，假设我运行了一次删除，可能是一百万行，而这几百万行的索引记录的大小大约为 8Gb。所以大约是 80k 差异的 100,000 倍。这是否意味着幽灵清理过程将需要 500,000 秒或几乎六天才能完成？
显然我在这里遗漏了一些东西，因为清除幻影记录需要那么长时间是没有意义的。那么达到相同索引的其他活动呢？鬼清理过程是否会导致等待，或者必须等待其他进程？
[这个问题是由我们在 OpsMgrDW 中看到的性能问题引起的，我们想了解更多关于这个过程的信息]
这不是关于如何应对或限制停机时间或数据丢失的问题，我知道这一切。我正在为我的 PASS post-con 关于灾难恢复整理一个“故事”部分，我希望能够分享一些比我在 Microsoft 的日子里的故事更近、更令人印象深刻的故事，尽管如果你”在过去的 3 年里，我曾听我展示过我的腐败套牌，你会记得他们都是傻瓜。
所以，想想这是一种忏悔（虽然我不能提供赦免:-）当然，这里讲述的所有故事都发生在朋友或同事身上，或者在以前的公司，除非你很勇敢并且想要'坦白。我不会评判或嘲笑任何答案，只会在被要求时提供见解。
真的，这个想法是让每个人都从错误和错误的步骤中学习。作为我听到的一个故事的例子，请参阅错误步骤和腐败的悲伤故事。
不确定这在这个论坛上是否有效，但值得一试。
谢谢！
PS 如果您还没有看过我的腐败会议并听过这些故事，那是去年 TechEd IT Pro 的第二场会议，他们录制了视频：请参阅TechEd：腐败生存技术演示的 80 分钟视频。博客文章链接到一堆损坏的数据库和演示脚本，您也可以下载和使用（我们网站上没有广告或类似内容，仅提供信息）。
我们刚刚从 SQL Server 2000 迁移到 SQL Server 2008。
我们在 2000 上使用我们自己的日志传送进行故障转移。对于 2008 年，我们需要决定使用我们自己的日志传送、内置日志传送或复制。
我们的服务器上有很多数据库（400+）；有的小，有的大。
数据库服务器故障应该很少见，我们可以接受 15-30 分钟的数据丢失。更重要的是快速启动第二个数据库服务器。
根据上述标准，我更喜欢使用日志传送还是复制？
如果日志传送，是否有一种简单的方法可以确保它在所有数据库上移动？
我有我公司最近接管的一个项目的数据库的 .bak 文件。
我能够恢复几个 .bak 文件，但最重要的一个失败了。
当它失败时，我只会收到一个通用错误，并要求检查日志。
这是发生的错误：Message SQL Server Assertion: File: , line=1443 Failed Assertion = 'pFile'。此错误可能与时间有关。如果重新运行语句后错误仍然存在，请使用 DBCC CHECKDB 检查数据库的结构完整性，或重新启动服务器以确保内存中的数据结构未损坏。
我不知道如何在 *.bak 文件上运行 DBCC CHECKDB。
任何帮助将不胜感激。虽然我作为开发人员有使用 SQL 的经验，但我绝对不是 DBA。所以假设我是个白痴。:)
谢谢！