数码资讯
如何恢复SQLServer2000损坏的数据库文件
在SQL Server2000，我们应该做什么如果数据库文件（非系统数据库文件）是错误的吗以下是笔者以前的笔记。它只适用于非主、msdb数据库。 以下是以下内容： 1构建测试数据库测试（数据库类型已完成） 2构建一个表，插入点记录 首先创建一个表（C1 varchar（2）） 去 插入一个值（AA）
选购提示
关注价格、性能、续航、售后和真实使用场景，理性比较后再下单。
在SQL Server2000，我们应该做什么如果数据库文件（非系统数据库文件）是错误的吗以下是笔者以前的笔记。它只适用于非主、msdb数据库。
以下是以下内容：
1构建测试数据库测试（数据库类型已完成）
2构建一个表，插入点记录
首先创建一个表（C1 varchar（2））
去
插入一个值（AA）
去
插入一个值（'BB'）
去
3充分的备份，文件test_1.bak
4修改一下
插入一个值（'cc）
去
创建表B（C1 int）
去
插入到B值（1）
去
插入到B值（2）
去
5关闭数据库服务器
6编辑数据库文件test_data.mdf用UltraEdit和修改内容的字节随机，这相当于对数据库的致命伤害。
7启动数据库，运行企业管理器，打开数据库，查看测试变成灰色，并表示怀疑。
8运行ISQL - slocalhost -美国- P
1 >日志备份测试盘=会：FilesMicrosoft SQL servermssqlbackup
est_2 bak'with no_truncate。
2 >去
2页已处理，属于file'test_log'of的database'test（文件1）。
备份日志操作成功处理了2页，花费了0.111秒（0.087兆字节/秒）。
9恢复最老的完整备份
1、恢复盘=会数据库测试：FilesMicrosoft SQL servermssql
est_1 bak'with NORECOVERY备份。
2 >去
96页已处理，属于file'test_data'of的database'test（文件1）。
1页已处理，属于file'test_log'of的database'test（文件1）。
还原数据库操作成功处理了97页，花费了0.107秒（7.368兆字节/秒）。
10还原最新日志
1、恢复盘=会测试日志：FilesMicrosoft SQL servermssqlbacku
P est_2 bak'with恢复。
2 >去
2页已处理，属于file'test_log'of的database'test（文件1）。
还原日志操作成功处理了2页，花费了0.056秒（0.173兆字节/秒）。
数据已完全恢复，可以使用。
选择*从
去
总之，DBA应该有完整的数据库备份计划。在这种情况下，没有完整备份，数据库的恢复是不可能的。
当SQL Server数据库崩溃时，如何恢复
任何数据库系统不能避免碰撞的情况下，即使你使用集群，双机热备…它仍然是不可能完全消除单点故障的系统，而对于大多数用户来说，是不可能承担如此昂贵的硬件投资。所以，当系统崩溃时，如何恢复原有的价值数据已经成为一个非常重要的问题。
在恢复的时候，最理想的情况是您的数据文件和日志文件是完整的，所以只需要sp_attach_db，数据文件可以被添加到新的数据库，或在空闲时间的所有数据文件（必须掌握）被复制到原来的路径线，但一般不推荐这种方法，sp_attach_db相当不错，虽然很多麻烦。
然而，当一个通用数据库崩溃时，系统可能没有时间将未完成的事务和脏页写入磁盘。在这种情况下，sp_attach_db会失败。嗯，希望管理员做出一个好的灾难恢复计划。根据你的恢复计划，还原最新的完全备份，增量备份或事务日志备份，然后祝贺你，如果你的活动事务日志可以看出来的。你可以恢复到之前的状态的崩溃。
一般单位都不是专职DBA，如果备份不可用，更可能是备份的最新时间太长，导致数据丢失不能被接受，而主动事务日志您是不可用的，这是最麻烦的。
不幸的是，一般的数据库崩溃是由存储子系统引起的。在这种情况下，几乎不可能有可用的日志进行恢复。因此我们必须尝试这些计划。当然，至少需要您的数据文件。如果数据文件、日志文件和备份都不见了，请不要找我。你可以在大楼顶上唱给上帝听，帮帮我。
首先，你可以试着sp_attach_single_file_db，尝试恢复您的数据文件，虽然它不太可能恢复，但如果数据库只执行一个检查点，它仍然是可能的。
如果你没有幸运的彩票，最重要的数据库是不是像你抬头，不要气馁，或其他一些计划。
我们可以试着重建一个日志。首先，我们将数据库设置为紧急模式。中的地位是32768，这意味着数据库处于这种状态。
但是系统表不能随意更改，先设置。
使用主
去
sp_configure'allow更新，1
RECONFIGUREWITHOVERRIDE
去
然后
更新sysdatabases设置状态= 32768名=
现在，为god Buddha的祝福祈祷，重新建立一个日志文件。成功的机会仍然很大，并且系统通常识别你的新日志。如果你没有报告任何错误，你现在可以放心了。
虽然恢复了数据，但不要认为如果事务完成了，正在进行的事务必须丢失，并且原始数据也可能被损坏。
首先重新启动SQL Server，然后检查数据库。
首先设置为单用户模式，然后做DBCC
sp_dboption，孤独的用户，真实的
DBCC CHECKDB（' '）
如果没有大的问题，你可以回去改变数据库的状态，记得关闭系统表的修改选项。
更新sysdatabases设置状态= 28名=——当然，你的数据库的状态可不是这样，改变自己正确的价值观，你也可以使用sp_resetstatus
去
sp_configure'allow更新，0
RECONFIGUREWITHOVERRIDE
去
会可能会报告一个错误的数量，你可能要丢弃这些错误的数据。
会有几个修复选项，看了自己，但在一天结束的时候你可能要使用repair_allow_data_loss来完成所有的维修。
Chekcdb不做所有的修理。我们需要把它进一步与DBCC CHECKTABLE检查每个表。
表的列表可以从中。检查所有的客体是istable，这样基本上能解决问题。如果仍然报告错误，请尝试将数据选中到另一个表中。
当所有这些都完成了，所有的索引，视图，存储过程，触发器等rebuilt.dbcc DBREINDEX可以帮助你。
当数据库日志文件丢失时，将描述恢复步骤。在描述事务日志文件（Ldf）被误删除，我试图恢复数据库经过各种尝试。
但许多网民在处理数据库疑问的过程中产生了许多新问题。
我想总结一下提出的一些案例供参考。
2个扎克的脚本
扎克说，每次遇到这种运行数据库的情况时，这个脚本，我：
======================================================
在运行任何脚本之前，运行以下设置
主数据库允许更新
使用主
去
sp_configure'allow更新，1
去
RECONFIGUREWITHOVERRIDE
去
——运行以下脚本
更新主..中设置状态=状态^ 256
name = 'database_name
——运行以下脚本
执行sp_resetstatus database_name
在这个阶段，停止和启动MSDTC
-在创建过程之后，立即禁用
更新系统表：
执行sp_configure'allow更新，0
去
RECONFIGUREWITHOVERRIDE
去
=====================================
正如你所看到的，处理怀疑的基本步骤是我在文章中所说的（注意我使用的字体的颜色）：
的sp_configure执行允许系统表进行更新，然后配置的执行与重写语句的重新配置；
数据库重置紧急模式；
执行sp_resetstatus关闭数据库，但保持数据库没有其他选项（只有系统管理员才能执行它）。该过程执行后，立即重新启动SQL Server服务。
的sp_configure执行禁止系统表的更新，然后配置的执行与重写语句的重新配置。
状态256意味着：
常数值描述
256数据库的完整性是sqldmodbstat_suspect参考数据库的怀疑。
不同之处在于，有时数据库日志文件丢失，需要以下步骤：
将应用程序数据库设置为单用户模式；
做DBCC CHECKDB；
只能 u3002
但一些用户实践的DBCC CHECKDB失败。朋友杨说，但DBCC CHECKDB不会执行它，总是说数据库在恢复模式的回避。我已经试过很多次，但我不能改变它。
另一个瑞执行DBCC CHECKDB时报错：服务器：味精943，级别14，状态1，1号线database'his_yb'cannot，'his_yb，CHECKDB，539。
对于杨来说，他不可能一步做一步。我敏锐地意识到，数据库在单用户模式的应用可以DBCC CHECKDB完成后。之后，也许SQL服务器重启后自动检查数据库是否正常，但数据应该读出来的，至少可以通过DTS向导读。此时的数据库仍存在一些问题，如部分使用数据库时，报告说：错误：2147467259，开始transaction'xxx'failed运行在数据库，因为数据库处于恢复期模式。
对芮来说，他遇到的错误
服务器：MSG 943，级别14，状态1，第2行
database'xxxx'cannot是因为其版本打开（536）晚于
当前服务器版本（515）。
这表明芮正试图：
从SQL Server 2000（版本539536）的数据库备份恢复到SQL Server 7
也许
SQL Server 2000（版本539536）与SQL Server 7的数据库连接，
这是不允许的，如果您必须使用SQL Server 2000的数据备份，请先将备份倒进SQL Server 2000，最后使用DTS将数据库从SQL Server 2000传输到SQL Server 7。
以下是以下内容：
1构建测试数据库测试（数据库类型已完成）
2构建一个表，插入点记录
首先创建一个表（C1 varchar（2））
去
插入一个值（AA）
去
插入一个值（'BB'）
去
3充分的备份，文件test_1.bak
4修改一下
插入一个值（'cc）
去
创建表B（C1 int）
去
插入到B值（1）
去
插入到B值（2）
去
5关闭数据库服务器
6编辑数据库文件test_data.mdf用UltraEdit和修改内容的字节随机，这相当于对数据库的致命伤害。
7启动数据库，运行企业管理器，打开数据库，查看测试变成灰色，并表示怀疑。
8运行ISQL - slocalhost -美国- P
1 >日志备份测试盘=会：FilesMicrosoft SQL servermssqlbackup
est_2 bak'with no_truncate。
2 >去
2页已处理，属于file'test_log'of的database'test（文件1）。
备份日志操作成功处理了2页，花费了0.111秒（0.087兆字节/秒）。
9恢复最老的完整备份
1、恢复盘=会数据库测试：FilesMicrosoft SQL servermssql
est_1 bak'with NORECOVERY备份。
2 >去
96页已处理，属于file'test_data'of的database'test（文件1）。
1页已处理，属于file'test_log'of的database'test（文件1）。
还原数据库操作成功处理了97页，花费了0.107秒（7.368兆字节/秒）。
10还原最新日志
1、恢复盘=会测试日志：FilesMicrosoft SQL servermssqlbacku
P est_2 bak'with恢复。
2 >去
2页已处理，属于file'test_log'of的database'test（文件1）。
还原日志操作成功处理了2页，花费了0.056秒（0.173兆字节/秒）。
数据已完全恢复，可以使用。
选择*从
去
总之，DBA应该有完整的数据库备份计划。在这种情况下，没有完整备份，数据库的恢复是不可能的。
当SQL Server数据库崩溃时，如何恢复
任何数据库系统不能避免碰撞的情况下，即使你使用集群，双机热备…它仍然是不可能完全消除单点故障的系统，而对于大多数用户来说，是不可能承担如此昂贵的硬件投资。所以，当系统崩溃时，如何恢复原有的价值数据已经成为一个非常重要的问题。
在恢复的时候，最理想的情况是您的数据文件和日志文件是完整的，所以只需要sp_attach_db，数据文件可以被添加到新的数据库，或在空闲时间的所有数据文件（必须掌握）被复制到原来的路径线，但一般不推荐这种方法，sp_attach_db相当不错，虽然很多麻烦。
然而，当一个通用数据库崩溃时，系统可能没有时间将未完成的事务和脏页写入磁盘。在这种情况下，sp_attach_db会失败。嗯，希望管理员做出一个好的灾难恢复计划。根据你的恢复计划，还原最新的完全备份，增量备份或事务日志备份，然后祝贺你，如果你的活动事务日志可以看出来的。你可以恢复到之前的状态的崩溃。
一般单位都不是专职DBA，如果备份不可用，更可能是备份的最新时间太长，导致数据丢失不能被接受，而主动事务日志您是不可用的，这是最麻烦的。
不幸的是，一般的数据库崩溃是由存储子系统引起的。在这种情况下，几乎不可能有可用的日志进行恢复。因此我们必须尝试这些计划。当然，至少需要您的数据文件。如果数据文件、日志文件和备份都不见了，请不要找我。你可以在大楼顶上唱给上帝听，帮帮我。
首先，你可以试着sp_attach_single_file_db，尝试恢复您的数据文件，虽然它不太可能恢复，但如果数据库只执行一个检查点，它仍然是可能的。
如果你没有幸运的彩票，最重要的数据库是不是像你抬头，不要气馁，或其他一些计划。
我们可以试着重建一个日志。首先，我们将数据库设置为紧急模式。中的地位是32768，这意味着数据库处于这种状态。
但是系统表不能随意更改，先设置。
使用主
去
sp_configure'allow更新，1
RECONFIGUREWITHOVERRIDE
去
然后
更新sysdatabases设置状态= 32768名=
现在，为god Buddha的祝福祈祷，重新建立一个日志文件。成功的机会仍然很大，并且系统通常识别你的新日志。如果你没有报告任何错误，你现在可以放心了。
虽然恢复了数据，但不要认为如果事务完成了，正在进行的事务必须丢失，并且原始数据也可能被损坏。
首先重新启动SQL Server，然后检查数据库。
首先设置为单用户模式，然后做DBCC
sp_dboption，孤独的用户，真实的
DBCC CHECKDB（' '）
如果没有大的问题，你可以回去改变数据库的状态，记得关闭系统表的修改选项。
更新sysdatabases设置状态= 28名=——当然，你的数据库的状态可不是这样，改变自己正确的价值观，你也可以使用sp_resetstatus
去
sp_configure'allow更新，0
RECONFIGUREWITHOVERRIDE
去
会可能会报告一个错误的数量，你可能要丢弃这些错误的数据。
会有几个修复选项，看了自己，但在一天结束的时候你可能要使用repair_allow_data_loss来完成所有的维修。
Chekcdb不做所有的修理。我们需要把它进一步与DBCC CHECKTABLE检查每个表。
表的列表可以从中。检查所有的客体是istable，这样基本上能解决问题。如果仍然报告错误，请尝试将数据选中到另一个表中。
当所有这些都完成了，所有的索引，视图，存储过程，触发器等rebuilt.dbcc DBREINDEX可以帮助你。
当数据库日志文件丢失时，将描述恢复步骤。在描述事务日志文件（Ldf）被误删除，我试图恢复数据库经过各种尝试。
但许多网民在处理数据库疑问的过程中产生了许多新问题。
我想总结一下提出的一些案例供参考。
2个扎克的脚本
扎克说，每次遇到这种运行数据库的情况时，这个脚本，我：
======================================================
在运行任何脚本之前，运行以下设置
主数据库允许更新
使用主
去
sp_configure'allow更新，1
去
RECONFIGUREWITHOVERRIDE
去
——运行以下脚本
更新主..中设置状态=状态^ 256
name = 'database_name
——运行以下脚本
执行sp_resetstatus database_name
在这个阶段，停止和启动MSDTC
-在创建过程之后，立即禁用
更新系统表：
执行sp_configure'allow更新，0
去
RECONFIGUREWITHOVERRIDE
去
=====================================
正如你所看到的，处理怀疑的基本步骤是我在文章中所说的（注意我使用的字体的颜色）：
的sp_configure执行允许系统表进行更新，然后配置的执行与重写语句的重新配置；
数据库重置紧急模式；
执行sp_resetstatus关闭数据库，但保持数据库没有其他选项（只有系统管理员才能执行它）。该过程执行后，立即重新启动SQL Server服务。
的sp_configure执行禁止系统表的更新，然后配置的执行与重写语句的重新配置。
状态256意味着：
常数值描述
256数据库的完整性是sqldmodbstat_suspect参考数据库的怀疑。
不同之处在于，有时数据库日志文件丢失，需要以下步骤：
将应用程序数据库设置为单用户模式；
做DBCC CHECKDB；
只能 u3002
但一些用户实践的DBCC CHECKDB失败。朋友杨说，但DBCC CHECKDB不会执行它，总是说数据库在恢复模式的回避。我已经试过很多次，但我不能改变它。
另一个瑞执行DBCC CHECKDB时报错：服务器：味精943，级别14，状态1，1号线database'his_yb'cannot，'his_yb，CHECKDB，539。
对于杨来说，他不可能一步做一步。我敏锐地意识到，数据库在单用户模式的应用可以DBCC CHECKDB完成后。之后，也许SQL服务器重启后自动检查数据库是否正常，但数据应该读出来的，至少可以通过DTS向导读。此时的数据库仍存在一些问题，如部分使用数据库时，报告说：错误：2147467259，开始transaction'xxx'failed运行在数据库，因为数据库处于恢复期模式。
对芮来说，他遇到的错误
服务器：MSG 943，级别14，状态1，第2行
database'xxxx'cannot是因为其版本打开（536）晚于
当前服务器版本（515）。
这表明芮正试图：
从SQL Server 2000（版本539536）的数据库备份恢复到SQL Server 7
也许
SQL Server 2000（版本539536）与SQL Server 7的数据库连接，
这是不允许的，如果您必须使用SQL Server 2000的数据备份，请先将备份倒进SQL Server 2000，最后使用DTS将数据库从SQL Server 2000传输到SQL Server 7。
声明：本文内容用于数码产品信息整理与选购参考，具体价格、库存、售后政策以官方渠道和电商页面实时信息为准。