DB异常状态:Recovery Pending,Suspect,估计Recovery的剩余时间
一,RECOVERY PENDING状态
今天修改了SQL Server的Service Account的密码,然后重启SQL Server的Service,发现有db处于Recovery Pending状态。
Recovery Pending状态是指:数据库在还原(recovery)时遇到跟资源相关的错误,虽然数据库没有损坏,但是文件可能丢失,或者系统资源的限制,导致该数据库不能开始还原进程。数据库处于Recovery Pending 状态,表明还原进程被挂起,数据库不能开始数据库的数据和日志的还原进程;这种情况,不能说慢Recovery失败,因为Recovery还没有开始。这种情况下,最可能的原因是丢失数据文件或日志文件。
对于Recovery Pending状态,应该如何修复:
ALTER DATABASE [DB_Name] SET SINGLE_USER WITH NO_WAIT
ALTER DATABASE [DB_Name] SET EMERGENCY;
DBCC checkdb ([DB_Name], REPAIR_ALLOW_DATA_LOSS )
ALTER DATABASE [DB_Name] SET online;
ALTER DATABASE [DB_Name] SET Multi_USER WITH NO_WAIT
在使用CheckDB命令Repair之前,查看DB的大小
select DB_NAME(mf.database_id) as DatabaseName,
mf.type_desc as FileType,
mf.name as FileLogicName,
mf.physical_name as FilePhysicalName,
mf.size as PagesCount,
mf.size*8/1024 as Size_MB,
mf.size*8/1024/1024.0 as Size_GB
from sys.master_files mf
where mf.database_id= db_id(N'dbname')
在执行时,出现各种问题:
1,User does not have permission to alter database 'Office365', the database does not exist, or the database is not in a state that allows access checks.
2,Database 'Office365' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.
最后,我到File 的 Physical path下,找不到相应的MDF文件,但是Log文件是存在的,并且log文件最后修改的时间离现在有2年,可能是被遗弃的DB。修改 Service Account ,不会删除一个18GB的MDF文件,向Leader询问,Leader说这是一个被废弃的DB。虚惊一场,像这种,MDF文件被删除,Log文件还保存的情况,数据文件肯定是被强制删除。
有惊无险,血泪的教训:在Service Restart 之前,一定确保DB没有在运行更新操作,并使用checkpoint保存脏数据。
二,估计Recovery的剩余时间
当一个DB处于 In Recovery 状态时,用户是不能访问的,如果Recovery时间很长,那么对一个DBA来说,等待的过程是虐心的,DBA需要知道剩余的还原时间。如何预测一个DB从In Recovery 状态,还原到正常Online状态所需的时间? SQL Server 没有直接给出答案,但是,在Recovery的过程中SQL Server将还原进程记录到ErrorLog中,可以通过Recovery的历史记录来估计剩余的完成时间。
DECLARE @DBName VARCHAR(64) = 'databasename' DECLARE @ErrorLog AS TABLE
(
[LogDate] CHAR(24),
[ProcessInfo] VARCHAR(64),
[TEXT] VARCHAR(MAX)
) INSERT INTO @ErrorLog
EXEC master..sp_readerrorlog 0, 1, 'Recovery of database', @DBName SELECT TOP 11
[LogDate]
,SUBSTRING([TEXT], CHARINDEX(') is ', [TEXT]) + 4,CHARINDEX(' complete (', [TEXT]) - CHARINDEX(') is ', [TEXT]) - 4) AS PercentComplete
,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0 AS MinutesRemaining
,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0/60.0 AS HoursRemaining
,[TEXT] FROM @ErrorLog
ORDER BY [LogDate] DESC
在SQL Server的Log中,记录的消息是:
Recovery of database 'database name' (16) is 0% complete (approximately 303767 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.
Recovery of database 'database name' (16) is 0% complete (approximately 396166 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
三,Database 处于Suspect状态
在物理机安装Windows更新,重启之后,发现该Server上有一个DB处于Suspect状态,该DB的Files分布在不同的Server上,我怀疑是在Remote Server重启时,导致该DB不能访问Remote Files,因此,SQL Server 进入 Suspect状态。
查看Windows 日志报告,发现一下错误信息:
The operating system returned error 53(The network path was not found.) to SQL Server during a read at offset 0x000001bed08000 in file '\\RemoteServerName\ShareFolder\xxxx.ndf'. 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.
这个错误是由于Remote Server重启,导致该DB不能访问位于Remote Server上的Files,数据库的文件并没有损坏。所以,解决方法是:等到所有的Remote Server都重启之后,只需要使该DB先脱机(offline),再联机(Online),SQL Server会自动检测该数据库的完整性,如果该DB的所有Files都能正常访问,该DB就会恢复到正常的Online状态。
alter database database_name
set offline
--wait for some seconds
alter database database_name
set online
附件:
数据库的状态和描述:
- ONLINE:Database is available for access. The primary filegroup is online, although the undo phase of recovery may not have been completed.
- OFFLINE:Database is unavailable. A database becomes offline by explicit user action and remains offline until additional user action is taken. For example, the database may be taken offline in order to move a file to a new disk. The database is then brought back online after the move has been completed.
- RESTORING:One or more files of the primary filegroup are being restored, or one or more secondary files are being restored offline. The database is unavailable.
- RECOVERING:Database is being recovered. The recovering process is a transient state; the database will automatically become online if the recovery succeeds. If the recovery fails, the database will become suspect. The database is unavailable.
- RECOVERY PENDING:SQL Server has encountered a resource-related error during recovery. The database is not damaged, but files may be missing or system resource limitations may be preventing it from starting. The database is unavailable. Additional action by the user is required to resolve the error and let the recovery process be completed.
- SUSPECT:At least the primary filegroup is suspect and may be damaged. The database cannot be recovered during startup of SQL Server. The database is unavailable. Additional action by the user is required to resolve the problem.
- EMERGENCY:User has changed the database and set the status to EMERGENCY. The database is in single-user mode and may be repaired or restored. The database is marked READ_ONLY, logging is disabled, and access is limited to members of the sysadmin fixed server role. EMERGENCY is primarily used for troubleshooting purposes. For example, a database marked as suspect can be set to the EMERGENCY state. This could permit the system administrator read-only access to the database. Only members of the sysadmin fixed server role can set a database to the EMERGENCY state.
推荐阅读:
How to resolve the issue of a database that was in Recovery Pending mode
Troubleshooting: SCOM DW Database is in a Suspect State
Search Engine Q&A #4: Using EMERGENCY mode to access a RECOVERY PENDING or SUSPECT database
Corruption: Last resorts that people try first…
How To Repair A Suspect Database In MSSQL
Recovering a SQL Server Database from Suspect Mode
DB异常状态:Recovery Pending,Suspect,估计Recovery的剩余时间的更多相关文章
- DataBase异常状态:Recovery Pending,Suspect,估计Recovery的剩余时间
一,RECOVERY PENDING状态 今天修改了SQL Server的Service Account的密码,然后重启SQL Server的Service,发现有db处于Recovery Pendi ...
- SQL Server恢复软件SysTools SQL Recovery/SysTools SQL Server Recovery Manager
SQL Server恢复软件SysTools SQL Recovery/SysTools SQL Server Recovery Manager http://www.systoolsgroup.co ...
- Recovery启动流程(3)--recovery.cpp分析
转载请注明来源:cuixiaolei的技术博客 这篇文章主要通过分析高通recovery目录下的recovery.cpp源码,对recovery启动流程有一个宏观的了解.MTK和高通的recovery ...
- elasticsearch indices.recovery 流程分析(索引的_open操作也会触发recovery)——主分片recovery主要是从translog里恢复之前未写完的index,副分片recovery主要是从主分片copy segment和translog来进行恢复
摘自:https://www.easyice.cn/archives/231 elasticsearch indices.recovery 流程分析与速度优化 目录 [隐藏] 主分片恢复流程 副本分片 ...
- recovery中英对照表 recovery大全图解
一:Recovery主界面 ---reboot system now 重启手机(刷机完毕选择此项就能重新启动系统) ---apply SDcard:up ...
- 当DATABASE进入了suspect模式以后
一个VM的错误就造成了sql2012的脱序.很多一般看不到的模式陆续登场 诸如 recovery pending, suspect, EMERGENCY. 以下脚本可以帮助恢复,如果文件没有损坏的话. ...
- Change the Target Recovery Time of a Database (SQL Server) 间接-checkpoints flushcache flushcache-message
Change the Target Recovery Time of a Database (SQL Server) 间接checkpoints flushcache flushcache-mes ...
- 崩溃恢复(crash recovery)与 AUTORESTART参数
关于这个参数设置的影响,在生产系统中经历过两次: 第一次是有套不太重要的系统安装在虚拟机,这套系统所有应用(DB2 WAS IHS)都配置到/etc/rc.local中,每次启动机器会自 ...
- RMAN RECOVERY
Data Recovery Advisor The health monitor and the ADR The capabilities and limitations of DRA using t ...
随机推荐
- [翻译] SSKeychain
SSKeychain https://github.com/soffes/sskeychain SSKeychain is a simple wrapper for accessing account ...
- 铁乐学Python_day12_装饰器
[函数的有用信息] 例: def login(user, pwd): ''' 功能:登录调用 参数:分别有user和pwd,作用分别是用户和密码: return: 返回值是登录成功与否(True,Fa ...
- 剑指offer 07斐波那契数列
现在要求输入一个整数n,请你输出斐波那契数列的第n项(从0开始,第0项为0).n<=39 java版本: public class Solution { public static void m ...
- (z转)基于CPU的Bank BRDF经验模型,实现各向异性光照效果!
摘抄“GPU Programming And Cg Language Primer 1rd Edition” 中文 名“GPU编程与CG语言之阳春白雪下里巴人” BRDF 光照模型 10.2.1 什么 ...
- centos7.4应用之KVM
最小安装系统: 参考博客:https://www.cnblogs.com/chenjiahe/p/5911965.html 辅助命令 yum install make bison flex autom ...
- Springboot+RestTemplate 简单使用
spring框架提供的RestTemplate类可用于在应用中调用rest服务,它简化了与http服务的通信方式,统一了RESTful的标准,封装了http链接, 我们只需要传入url及返回值 ...
- Loj #2256. 「SNOI2017」英雄联盟
题目 我就是个丝薄 如果要用\(dp_i\)表示凑出\(i\)的最小花费显然不可能的 之后大力猜想能凑出来的状态不会很多,我的暴力也告诉我不是很多,好像也确实不多的样子,大概\(4e4\)左右 但是我 ...
- 如何在Python中获取当前时间
所属网站分类: python基础 > 模块,库 作者:追梦骚年 链接:http://www.pythonheidong.com/blog/article/68/ 来源:python黑洞网,专注p ...
- 创建一个接口Shape,其中有抽象方法area,类Circle 、Rectangle实现area方法计算其面积并返回。又有Star实现Shape的area方法,其返回值是0,Star类另有一返回值boolean型方法isStar;在main方法里创建一个Vector,根据随机数的不同向其中加入Shape的不同子类对象(如是1,生成Circle对象;如是2,生成Rectangle对象;如是3,生成S
题目补充: 创建一个接口Shape,其中有抽象方法area,类Circle .Rectangle实现area方法计算其面积并返回. 又有Star实现Shape的area方法,其返回值是0,Star类另 ...
- HDU 1316 (斐波那契数列,大数相加,大数比较大小)
题目链接: http://acm.hdu.edu.cn/showproblem.php?pid=1316 Recall the definition of the Fibonacci numbers: ...