IT 部门意识到我们的生产 SQL Server 2005 上存在磁盘写入错误，因此导致备份失败。当他们意识到这一点时，夜间备份已经过时，因此无法在另一台服务器上恢复备份。
数据库仍在运行并不断使用。但是 DBCC CheckDB 失败。此外，SQL Server 备份任务失败、复制数据库失败、导出数据向导失败。但是似乎可以从表中读取所有数据（即使用 bcp 等）
我的另一个观察是，事务日志的大小几乎是数据库的两倍。（这是否意味着所有更改都没有写入 MDF？）
使数据库处于备份正常运行且数据安全的状态的最佳攻击计划是什么？
- 使数据库脱机并使用 MDF/LDF 以某种方式在另一个 SQL 服务器上创建数据库？
- 使用 bcp 从数据库导出数据。在另一个 SQL Server 上创建数据库（使用损坏的数据库上的生成脚本功能在新数据库上创建架构），然后再次使用 bcp 导入数据。
- 在这种情况下还有其他正确的做法吗？
IT 经理说数据是安全的，因为如果服务器发生故障，数据可以从 mdf/ldf 中恢复。我不确定，所以坚持我们每晚都开始导出数据作为故障保护（例如使用 bcp）。
IT 部门在硬件方面也遇到了问题，因为据称磁盘错误发生在虚拟化磁盘上，无法像普通 raid 阵列（或类似的东西）那样进行重建。
请原谅我使用了错误的术语，并且对 SQL Server 的运行方式做出了错误的假设。我是应用程序开发人员，被要求提供帮助（因为 IT 部门似乎对 SQL Server 的了解程度不如我）。
非常感谢，阿米特
DBBC CheckDB的结果：
Msg 1823, Level 16, State 2, Line 1
A database snapshot cannot be created because it failed to start.
Msg 7928, Level 16, State 1, Line 1
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
Msg 5030, Level 16, State 12, Line 1
The database could not be exclusively locked to perform the operation.
Msg 7926, Level 16, State 1, Line 1
Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details.
Msg 823, Level 24, State 3, Line 1
The operating system returned error 1(error not found) to SQL Server during a write at offset 0x00000674706000 in file 'G:\AX40_Dynamics_Live.mdf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
答案1
首先，一定要非常小心 - 你不想让事情变得更糟。我强烈建议咨询 Microsoft 产品支持（你必须付费）、聘请专家或在线查找 Paul Randal 的资料。
您提到有一个旧的备份.....您是否尝试过备份事务日志（GUI Management Studio 允许您轻松完成此操作），然后在新的备份服务器上恢复旧备份和这个新的事务日志备份？
答案2
解雇 IT 部门。显然不称职。
尝试删除并重新创建所有索引。如果您对所有数据都可以重新创建的说法是正确的，则写入错误一定发生在索引中 - 因此您可以“解决它”。
LDF 较大的 MDF 意味着日志可能未备份。鉴于 IT 管理员表现出的无能，这种情况极有可能发生。
IT 经理不知道自己在说什么。如果服务器出现故障，则无法保证 mdf/ldf 在没有外部工具的情况下仍可恢复（即可能要花很多钱）。这种情况不太可能发生，但 IT 经理应该知道他目前在冒着公司的风险。那么，他显然聘请了 IT 部门。
尝试 dbcc checkdb，将结果发布在这里，以便我们真正帮助您。
- 检查您的数据库是否是最新的（补丁级别）。
答案3
DBCC 输出看起来无法获得对数据库的独占访问权限，因此它拒绝运行。如果您想将所有人都排除在数据库之外，以便它真正运行，请使用以下命令：
ALTER DATABASE database_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE
完成此操作后，DBCC CHECKDB 应该会愿意配合。完成后，将数据库重新置于多用户模式：
ALTER DATABASE database_name SET MULTI_USER
答案4
我建议做的第一件事是让应用程序脱机并运行 checkdb 以确保数据库未损坏。如果没有，则一切正常。如果是，则我们需要确定损坏程度并恢复我们能恢复的数据。
要立即运行 checkdb，您需要将数据库置于单用户模式，然后对每个数据库运行 dbcc checkdb。
当尝试手动运行数据库备份时会发生什么？
基于这是动态的事实（并且它可以运行您的业务），您可能想要花钱通过电话联系 PSS 或让 SQL 顾问来查看它（即使有 SQL 顾问，您可能仍会致电 PSS）。
至于标题中的实际问题，您不想只导出数据然后重新导入。很可能不会支持这种做法。