sql数据库质疑的原因及解决办法

sql数据库质疑是设置错误造成的，解决方法为：

1、通过DBCC CHECKCB('DBName') 来检测数据库异常的原因，如果可以检测到数据库的异常，其中红色部分即时数据目前存在的问题，我们也在检测结果最后看到数据的总体的错误情况的汇总。

2、如果数据库的整体结果没有问题，只是部分表的数据结构、索引、存储出现异常，可以通过DBCC CheckTable('DBNamedbotablename')来进行检测。

3、通过sql命令或者 *** 作，将数据库设置为“单用户”模式，然后打开查询分析器，准备进行修改。

4、打开查询分析器器，选择Master数据库，通过DBCC CheckDB('DBName',REPAIR_ALLOW_DATA_LOSS）命令，进行数据库的全面修复，该命令可能会导致数据库中的数据丢失，请注意。

5、处理之后，我们还需要将用户模式恢复为多用户模式，可以选择命令，可以是所使用使用数据库管理工具，进行多用户回复：命令： ALTER DATABASE DBName SET MULTI_USER。

6、重启数据库服务，查看数据库异常是否修复，在控制面板找到sql服务进行重启，如果为sql2000，点击屏幕有下家的数据库服务器工具，进行重新启动。

最近在网上看到破解版本的SQL SERVER 的数据库修复软件越来越多，在\x0d\闲时，下载了所有的试用版本及已经破解版本，找到以前保留的损坏MDF，进\x0d\行一番比较。断断续续经过几天的比较，这些软件的功能与特点基本上了解清楚，\x0d\写出来，与大家共享。\x0d\RecoveryToolboxForSQLServer（产地：俄国）\x0d\特点：数据恢复效果较好，对于库结构恢复较正常。\x0d\使用：直接选择损坏的MDF 文件，将修复结果直接输出到SQLSERVER 中。\x0d\或者保存成SQL 脚本文件。\x0d\SysTools SQL Recovery（产地不详）\x0d\特点：显示数据时，对中文不支持，只显示出UniCode，在运行时容易程度中\x0d\断直接退出；此软件有些像RecoveryToolboxForSQLServer\x0d\使用：直接选择损坏的MDF 文件，将修复结果直接输出到SQLSERVER 中。\x0d\或者保存成SQL 脚本文件。\x0d\officerecovery 中的 Recovery for SQL Server（产地：美国）\x0d\特点：支持BAK，LOG 文件，但修复后的数据容易丢失，库结构提较取较完整。\x0d\使用：直接选择损坏的MDF 文件，将修复结果直接输出到SQLSERVER 中。\x0d\或者保存成SQL 脚本文件。\x0d\Kernel for SQL Database（产地：印度）\x0d\特点：恢复效果好，但日期的显示，它是用国外的方式，库结构提取一般。\x0d\使用：直接选择损坏的MDF 文件，将修复结果直接输出到SQLSERVER 中。\x0d\或者保存成SQL 脚本文件。\x0d\Stellar Phoenix SQL Recovery （产地：印度）\x0d\特点：数据恢复效果较好，程序运行时易不正常退出，库结构提取不出来。\x0d\使用：直接选择损坏的MDF 文件，将修复结果直接输出到SQLSERVER 中。\x0d\无法保存成SQL 脚本。\x0d\上述软件都已经有破解版本或者免费版本，大家在选择时应该有所了解。\x0d\说明：库结构提取不完整，修复后的数据虽然可以在SQL SERVER 中附加，查\x0d\看，导出，备份，但在应用软件下是无法连接此数据库的，经过对上述软件修复后的数据库文件进行研究，已经找到解决MDF 文件加软件的办法，有此修复需

方法/步骤

修改数据库为紧急模式

ALTER DATABASE Test SET EMERGENCY

使数据库变为单用户模式

ALTER DATABASE Test SET SINGLE_USER

修复数据库日志重新生成，此命令检查的分配，结构，逻辑完整性和所有数据库中的对象错误，这个过程时间可能比较长。

DBCC CheckDB (Test , REPAIR_ALLOW_DATA_LOSS)

使数据库变回为多用户模式

ALTER DATABASE Test SET MULTI_USER

重新启动数据库服务

首先先和大家讲一讲SQL

Server恢复master数据库方法，具体步骤如下

第一步：复制modelmdf、mastlogldf、modelmdf、modellogldf、msdbdatamdf、msdblogldf文件。

从X:\Program

Files\Microsoft

SQL

Server\MSSQL10MSSQLSERVER\MSSQL\Binn\Templates

至X:\Program

Files\Microsoft

SQL

Server\MSSQL10MSSQLSERVER\MSSQL\DATA

注：以上“X:\Program

Files\Microsoft

SQL

Server”为SQL

Server的安装目录。以下的“C:\Program

Files\Microsoft

SQL

Server”为系统盘下的目录

第二步：定位并执行安装命令

1

首先找到安装命令：C:\Program

Files\Microsoft

SQL

Server\100\Setup

Bootstrap\Release\setupexe

2

执行命令

如果只是Windows身份验证模式，只需要如下语法即可：

复制代码

代码如下:setup

/ACTION=REBUILDDATABASE

/QUIET

/INSTANCENAME=<instance

name>

/SQLSYSADMINACCOUNTS=<accounts>

如果是复合身份验证模式，则需要使用/SAPWD参数提供sa的密码：

复制代码

代码如下:setup

/ACTION=REBUILDDATABASE

/QUIET

/INSTANCENAME=<instance

name>

/SQLSYSADMINACCOUNTS=<accounts>

/SAPWD=<sa

password>

我安装时设置的是复合认证模式，SQL

Server系统管理员帐号是administrators组，sa密码是123456。并且就一个默认实例：MSSQLSERVER。

所以在命令行执行如下命令：

复制代码

代码如下:setup

/ACTION=REBUILDDATABASE

/QUIET

/INSTANCENAME=MSSQLSERVER

/SQLSYSADMINACCOUNTS=administrators

/SAPWD=123456

第三步：执行完毕后没有任何提示信息（不管成功与否），但是可以马上在C:\Program

Files\Microsoft

SQL

Server\100\Setup

Bootstrap\Log\Summarytxt中查看安装日志。

最后，在Sql

Server

Configuration

Manager中启动SQL

Server服务成功。

在处理过程中出现了这种情况SQL恢复数据库又该怎么办？只有mdf文件时,应当如何进行恢复，即有log文件的数据库如何恢复

SQL恢复数据库具体实现步骤：

1、新建一个同名数据库。

2、停止数据库服务，覆盖新建的数据库主文件（小技巧：最好放在同一个磁盘里面，把新建的数据库主文件删掉或移开，再把要恢复的数据库主文件剪切过去，这样就可以节省时间。）

3、启动数据库服务，数据库变为置疑或可疑状态。然后在查询分析器中运行：

alter

database

无日志文件的数据库名称

set

emergency

设置为紧急状态。

4、再运行：

alter

database

无日志文件的数据库名称

set

single_user

或者：

Sp_dboption

'无日志文件的数据库名称',

'single

user',

'true'

设置为单用户模式。

5、检查并重建日志文件，运行：

dbcc

checkdb('无日志文件的数据库名称',REPAIR_ALLOW_DATA_LOSS)

这个时间比较长。耐心等待！如果有错误提示，再运行：

dbcc

checkdb('无日志文件的数据库名称',REPAIR_REBUILD)

进行修复。如果没有错误，可以跳过。

6、恢复成多用户模式

alter

database

无日志文件的数据库名称

set

multi_user

或者：

Sp_dboption

'无日志文件的数据库名称',

'single

user',

'false'

刷新数据库，你就可以看到已经修复好的数据库了。

以上就是为大家分享的SQL恢复数据库方法，希望对大家恢复数据库有所帮助。

修复数据库坏块

dbv

你也可以用dbv工具看一下你现在其他的数据文件有没有还有坏块的

dbv file='yourfilename'

恢复方法：

当Oracle数据库出现坏块时，Oracle会在警告日志文件（alert_SIDlog）中记录坏块的信息：

ORA-01578: ORACLE data block corrupted (file # 7, block # )

ORA-01110: data file : '/oracle1/oradata/V920/oradata/V816/users01dbf'

其中，＜AFN＞代表坏块所在数据文件的绝对文件号，代表坏块是数据文件上的第几个数据块

出现这种情况时，应该首先检查是否是硬件及 *** 作系统上的故障导致Oracle数据库出现坏块。在排除了数据库以外的原因后，再对发生坏块的数据库对象进行处理。

1．确定发生坏块的数据库对象

SELECT tablespace_name,

segment_type,

owner,

segment_name

FROM dba_extents

WHERE file_id =

AND between block_id AND block_id+blocks-1;

2．决定修复方法

如果发生坏块的对象是一个索引，那么可以直接把索引DROP掉后，再根据表里的记录进行重建；

如果发生坏块的表的记录可以根据其它表的记录生成的话，那么可以直接把这个表DROP掉后重建；

如果有数据库的备份，则恢复数据库的方法来进行修复；

如果表里的记录没有其它办法恢复，那么坏块上的记录就丢失了，只能把表中其它数据坏上的记录取出来，然后对这个表进行重建。

3．用Oracle提供的DBMS_REPAIR包标记出坏块

exec DBMS_REPAIRSKIP_CORRUPT_BLOCKS('','');

4．使用Create table as select命令将表中其它块上的记录保存到另一张表上

create table corrupt_table_bak

as

select from corrupt_table;

5．用DROP TABLE命令删除有坏块的表

drop table corrupt_table;

6．用alter table rename命令恢复原来的表

alter table corrupt_table_bak

rename to corrupt_table;

7．如果表上存在索引，则要重建表上的索引

PART2

2014722研究恢复数据库坏块：

Oracle调用标准C的系统函数，对数据块进行读写 *** 作，因此，坏块是有可能由以下几种原因产生：

硬件的I/O错误

*** 作系统的I/O错误或缓冲问题

内存或paging问题

磁盘修复工具

一个数据文件的一部分正在被覆盖

Oracle试图访问一个未被格式化的系统块失败

数据文件部分溢出

Oracle或者 *** 作系统的bug

遇到“ORA-01578:ORACLE data block corrupted”错误

处理方法：1rman的recover命令可以在数据库保持open状态下只恢复受损的数据块

2如果没有备份，万不得已之下也可以采用DBMS_REPAIR包的存储过程将受损坏块隔离，同时尽可能地挽救部分数据。

rman backup命令也是检查坏数据块的好工具 一旦读取ORA-19566 即可有问题

此时可用backup validate tablespace user观察详细的信息，可查看到坏块数与跟踪文件

grep‘corrupt’/u01/app/oracle/diag/rdbms/br/br/trace/trc

恢复数据块：rman》recover datafile 5 block 203；

批量恢复受损的数据块：recover corruption list;

数据块坏块一号坏块，需要做：

run{

sql 'alter database datafile 5 offline';

restore datafile 5;

recover datafile 5;

sql'alter database datafile 5 online'

}

使用exp/imp恢复

在这种情况下肯定会造成数据的丢失，在这种情况下应采取将数据导出然后重建表再进行导入的方法，来尽量恢复损坏数据块中的数据，但是在有坏块的情况下是不允许导出的，如下命令：Exp test/test file=tdmp tables=t;

导出命令在执行中会报ORA-01578错误，在这错误提示中会提示那个文件号的文件以及这个文件中的哪个块被损坏，如：ORA—01578：ORACLE 数据块损坏（文件号 4，块号 35）

针对以上的提示首先查询那些对象被损坏：

Select tablespace_name,segment_type,owner,segment_name From dba_extents Where file_id=4 and 35 between block_id and block_id+blocks-1;

如果被损坏的块是索引，通常可以通过索引重建来解决，如果损坏的是数据（segment_type为table），那么通过设置如下内部事件使得Exp *** 作跳过坏块。

Alter session set events=’10231 trace name context forever,level 10’;

然后重新执行导出命令，导出相关的表，然后执行Drop Table命令删除相关表，之后重建表最后导入数据。

使用DBMS_REPAIR恢复

用DBMS_REPAIR当然也会丢失数据。这里不做详细的介绍，有兴趣的可以查看oracle的在线文

3、使用dbms_repair包进行坏块处理

1）首先建立repair_table,用于存放dbms_repaircheck_object检测出来的坏块信息

SQL> declare

2begin

3dbms_repairadmin_tables

4(table_name => 'REPAIR_TABLE',--表名

5table_type => dbms_repairrepair_table,

6action => dbms_repaircreate_action,

7tablespace => 'USERS');--用于指定该表存放的表空间

8end;

9/

PL/SQL 过程已成功完成。

SQL> col owner format a10

SQL> col object_name format a20

SQL> col object_type format a20

SQL> select owner, object_name, object_type

2from dba_objects

3where object_name like '%REPAIR_TABLE';

OWNEROBJECT_NAMEOBJECT_TYPE

---------- -------------------- --------------------

SYSREPAIR_TABLETABLE

SYSDBA_REPAIR_TABLEVIEW

Oracle自动创建了一个DBA_REPAIR_TABLE视图。

2）使用dbms_repaircheck_object进行坏块检测

SQL> set serveroutput on size 100000;

SQL> declare

2rpr_count int;

3begin

4rpr_count := 0;

5dbms_repaircheck_object(

6schema_name => 'SYS',--指定对象模式，也就是对象的所有者

7object_name => 'TEST',--指定对象名，也就是表名

8repair_table_name => 'REPAIR_TABLE',

9corrupt_count => rpr_count);

10dbms_outputput_line('repair block count: '

11||to_char(rpr_count));

12end;

13/

repair block count: 4

PL/SQL 过程已成功完成。

SQL> select object_name, block_id, corrupt_type, marked_corrupt,

2corrupt_description, repair_description

3from repair_table;

OBJECT_NAMEBLOCK_ID CORRUPT_TYPE MARKED_COR

-------------------- ---------- ------------ ----------

CORRUPT_DESCRIPTION

-------------------------------------------------------------------------------

REPAIR_DESCRIPTION

-------------------------------------------------------------------------------

TEST196148 TRUE

mark block software corrupt

TEST206148 TRUE

mark block software corrupt

TEST236148 TRUE

mark block software corrupt

TEST316148 TRUE

mark block software corrupt

通过运行dbms_repaircheck_object，将坏块信息存放到了repair_table表中，其中有个字段marked_corrupt，用于标识该块是否被标识为坏块，当被标识为true时，即该块被标识为坏块。其中这一步跟oracle文档中的描述有点进入，根据oracle文档，当执行完dbms_repaircheck_object时，并不会进行坏块标识，也就是marked_corrupt列的值应该为false，而只有当执行dbms_repairfix_corrupt_blocks过程后才会进行坏块标识。

3）使用dbms_repairfix_corrupt_blocks进行坏块标识

SQL> declare

2fix_block_count int;

3begin

4fix_block_count := 0;

5dbms_repairfix_corrupt_blocks (

6schema_name => 'SYS',

7object_name => 'TEST',

8object_type => dbms_repairtable_object,

9repair_table_name => 'REPAIR_TABLE',

10fix_count => fix_block_count);

11dbms_outputput_line('fix blocks count: ' ||

12to_char(fix_block_count));

13end;

14/

fix blocks count: 0

PL/SQL 过程已成功完成。

我们可以见到到fix blocks count=0，即在上一步进行check_object时已经进行了坏块标识了，这一步其实可以省略。（不过没有测试过！）

备份数据文件,然后按下面的步骤处理:

1新建一个同名的数据库(数据文件与原来的要一致)

2再停掉sql server(注意不要分离数据库)

3用原数据库的数据文件覆盖掉这个新建的数据库

4再重启sql server

5此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)

6完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用

数据库的脚本创建一个新的数据库,并将数据导进去就行了

USE MASTER

GO

SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE

GO

UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'

Go

sp_dboption '置疑的数据库名', 'single user', 'true'

Go

DBCC CHECKDB('置疑的数据库名')

Go

update sysdatabases set status =28 where name='置疑的数据库名'

Go

sp_configure 'allow updates', 0 reconfigure with override

Go

sp_dboption '置疑的数据库名', 'single user', 'false

假设数据库为TEST：

按以下步骤执行

A．设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go

B．设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID('test')

此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

C．下面执行真正的恢复 *** 作，重建数据库日志文件

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_logldf')

执行过程中，如果遇到下列提示信息：

服务器: 消息 5030，级别 16，状态 1，行 1

未能排它地锁定数据库以执行该 *** 作。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。

正确执行完成的提示应该类似于：

警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

D．验证数据库一致性（可省略）

dbcc checkdb('test')

一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

E．设置数据库为正常状态

sp_dboption 'test','dbo use only','false'

如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

F．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成

sp_configure 'allow updates',0

go

reconfigure with override

go

上面的语句 *** 作步骤有点问题：

应该如下：

A．我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。

B．停掉数据库服务器。

C．将刚才生成的数据库的日志文件test_logldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_datamdf。

D．启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何 *** 作。

E．设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go

F．设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID('test')

此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

G．下面执行真正的恢复 *** 作，重建数据库日志文件

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_logldf')

执行过程中，如果遇到下列提示信息：

服务器: 消息 5030，级别 16，状态 1，行 1

未能排它地锁定数据库以执行该 *** 作。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。

正确执行完成的提示应该类似于：

警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

H．验证数据库一致性（可省略）

dbcc checkdb('test')

一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

I．设置数据库为正常状态

sp_dboption 'test','dbo use only','false'

如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

J．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成

sp_configure 'allow updates',0

go

reconfigure with override

go

以上就是关于sql数据库质疑的原因及解决办法全部的内容，包括:sql数据库质疑的原因及解决办法、国外的几种SQL SERVER数据库，修复软件技术特点及使用办法是什么、SQL数据库2008数据库显示可疑，属性显示关闭如何修复等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！