数据库页已标记为 RestorePending,可能表明磁盘已损坏。要从此状态恢复,请执行还原操作。

简介: 错误提示:消息 829,级别 21,状态 1,第 1 行数据库 ID 15,页 (1:21826) 已标记为 RestorePending,可能表明磁盘已损坏。要从此状态恢复,请执行还原操作。引起原因:RestorePending一般是在进行页恢复的过程中出现的,就是在进行了restore操作之后但还没有进行recovery操作之前页的状态。

错误提示:

消息 829,级别 21,状态 1,第 1 行
数据库 ID 15,页 (1:21826) 已标记为 RestorePending,可能表明磁盘已损坏。要从此状态恢复,请执行还原操作。

引起原因:

RestorePending一般是在进行页恢复的过程中出现的,就是在进行了restore操作之后但还没有进行recovery操作之前页的状态。

出现这样的问题可以肯定这个表是损坏了,但是在查询数据的时候如果不会查询到损坏页面的数据话是不会报错的,也就是说可以有条件的使用这个表。

如果损坏的页只有一个的话,那删除掉这个坏表故障肯定就没有了,因为一个页里面只会放一个表的数据。

损坏的直接原因就是放在磁盘上面的数据被意外的修改了或者写入的时候出错这些,可能是磁盘问题,但是IO系统可能性更大。

可以好好的检查系统日志和SQLServer的LOG,看看里面有没有关于磁盘或者IO之类的警告、报错信息,以进一步确定原因。

至于处理方法,如果表重要那就利用备份做页面还原恢复数据,不重要的话就删掉重建,

或者使用以下方式进行修复,在处理完坏页之后再对整个数据库做一次DBCC CHECKDB操作,确保没有其他的坏页。

解决办法:

复制代码
快速修复
DBCC CHECKDB ('数据库名', REPAIR_FAST) 
重建索引并修复 DBCC CHECKDB ('数据库名', REPAIR_REBUILD)
如果必要允许丢失数据修复 DBCC CHECKDB ('数据库名'', REPAIR_ALLOW_DATA_LOSS)
复制代码

 


 

错误提示:

执行修复命令时,可能会出现以下错误:

未处理修复语句。数据库需处于单用户模式下解决

解决办法:

此时我们需要将数据库设置成单用户模式:

右键点击数据库 -> 属性 -> 选项 -> 状态 -> 限制访问 -> 选择Single-> 确定。

错误提示:

当我们修复完数据库后,需要将其恢复为多用户模式,此时可能出现

数据库 'xxx' 已打开,并且一次只能有一个用户访问

 解决办法:

在设置多用户模式的时候可能会因为还有其它进程的连接导致设置无法进行,所以需要杀掉所有连接的进程。

方式一

复制代码
USE master;   
GO   
DECLARE @SQL VARCHAR(3000);  
SET @SQL = '';  
SELECT @SQL = @SQL+'; KILL ' + RTRIM(SPID)  
FROM [sys].[sysprocesses] AS sps  
WHERE [sps].[dbid] = DB_ID('test');   
SET @SQL = SUBSTRING(@SQL, 2, LEN(@SQL));  
EXEC(@SQL);  
GO  
复制代码

方式二

复制代码
DECLARE @DBName SYSNAME;  
SET @DBName = 'BI_Monitor'; --这个是要删除的数据库库名      
       
DECLARE @KSQL NVARCHAR(1000)  
DECLARE tb CURSOR LOCAL  
FOR    
SELECT  
    KSQL = 'KILL ' + CAST([sps].[spid] AS NVARCHAR(10))  
FROM [sys].[sysprocesses] AS sps  
WHERE dbid = DB_ID(@DBName)--查询@DBName相关的线程  
      
--循环杀掉要删除数据的相关线程  
OPEN tb  
FETCH NEXT FROM tb INTO @KSQL  
WHILE @@FETCH_STATUS = 0    
BEGIN    
    EXECUTE(@KSQL);  
    FETCH NEXT FROM tb INTO @KSQL  
END   
CLOSE tb      
DEALLOCATE tb  
复制代码

最后再将相应数据库设置为多用户模式即可。

ALTER DATABASE [test] SET MULTI_USER;--设置为多用户模式  

 

目录
相关文章
|
1天前
|
存储 关系型数据库 MySQL
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
13 1
|
2月前
|
存储 数据挖掘 数据库
服务器数据恢复—raid磁盘故障导致数据库数据损坏的数据恢复案例
存储中有一组由3块SAS硬盘组建的raid。上层win server操作系统层面划分了3个分区,数据库存放在D分区,备份存放在E分区。 RAID中一块硬盘的指示灯亮红色,D分区无法识别;E分区可识别,但是拷贝文件报错。管理员重启服务器,导致离线的硬盘上线开始同步数据,同步还没有完成就直接强制关机了,之后就没有动过服务器。
|
2月前
|
存储 关系型数据库 MySQL
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
106 5
|
19天前
|
Oracle 关系型数据库 数据库
oracle数据恢复—Oracle数据库文件损坏导致数据库打不开的数据恢复案例
打开oracle数据库时报错,报错信息:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。急需恢复zxfg用户下的数据。 出现上述报错的原因有:控制文件损坏、数据文件损坏、数据文件与控制文件的SCN不一致等。数据恢复工程师对数据库文件做进一步检测分析后发现sysaux01.dbf文件有坏块。修复sysaux01.dbf文件,启动数据库依然有许多查询报错。export和data pump工具无法使用,查询告警日志并分析报错,确认发生上述错误的原因就是sysaux01.dbf文件损坏。由于该文件损坏,从数据库层面无法修复数据库。由于system和用户表空间的数据文件是正常的,
|
4月前
|
Oracle 关系型数据库 Java
实时计算 Flink版操作报错合集之cdc postgres数据库,当表行记录修改后报错,该如何修改
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
4月前
|
SQL 监控 关系型数据库
实时计算 Flink版操作报错合集之在设置监控PostgreSQL数据库时,将wal_level设置为logical,出现一些表更新和删除操作报错,怎么办
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
4月前
|
关系型数据库 Java 数据库
实时计算 Flink版操作报错合集之flinksql采PG数据库时报错,该如何解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
4月前
|
关系型数据库 MySQL 数据库
实时计算 Flink版操作报错合集之在处理PostgreSQL数据库遇到报错。该如何解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
4月前
|
消息中间件 关系型数据库 数据库
实时计算 Flink版操作报错合集之在使用RDS数据库作为源端,遇到只能同步21个任务,是什么导致的
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
4月前
|
SQL 数据库 Python
Django框架数据库ORM查询操作(6)
【7月更文挑战第6天】```markdown Django ORM常用数据库操作:1) 查询所有数据2) 根据ID查询 3) 精确查询 4) 分页排序
61 1