DB处于Recovery Pending状态

今天修改了Service Account的密码,然后我restart Service,发现有db处于Recovery Pending状态,查看 Paul Randal 的blog,看到如下定义:

RECOVERY PENDING

  • The database will be in this state if SQL Server knows that recovery needs to be run on the database but something is preventing recovery from starting. This is different from SUSPECT because there’s nothing to say that recovery is going to fail – it just hasn’t started yet.
  • An example of this is when the database wasn’t cleanly shut down (i.e. there was at least one uncommitted transaction active at the time the database was shut down) and the log file has been deleted.

如果是Recovery 还没有开始,那么这将是一个非常好的状态。如果是出现damage,那么,惨了,可能出现数据丢失。

血泪的教训:在Service Restart 之前,一定确保DB没有在运行更新操作,并使用checkpoint保存脏数据。

对于Recovery Pending状态,应该如何修复,引用《How to resolve the issue of a database that was in Recovery Pending mode

This error is closely correlated to that Forcibly deletion process  of File stream file which I do think no other solution except waiting to finish recovery mode and either wise it will end with :

  • The most optimistic   probability  that it will end up with Online mode …So it will be fine and no need for any further action  ( Just you have to wait for a longer time if log file was such huge)..
  • The most pessimistic probability that it will end up with suspect  mode  ..SO it will be need to run the below process of DB Repair  but bear in mind that data loss might be there;

Stop SQL Server and remove transaction log file of this DB then restart again where DB should go with suspect mode ….If so you can run the below query

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文件删除吧,这种情况,是什么原因?

从《Database Status》找到如下解释:

Recovery Pending state: 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.

附上Database Status及其 Definition

State Definition
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.

推荐阅读:

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…

时间: 2024-08-12 05:47:07

DB处于Recovery Pending状态的相关文章

SQL1117N 因为处于 ROLL-FORWARD PENDING

转载:http://www.cnblogs.com/vipsoft/archive/2012/08/08/2628291.html 恢复DB2数据库:所有数据库-创建数据库-从备份 SQL1117N 因为处于 ROLL-FORWARD PENDING刚装了DB2 然后用控制中心从备份中恢复了一个数据库 但访问时就报“SQL1117N 因为处于 ROLL-FORWARD PENDING  状态,所以不能连接或激活数据库 "test". SQLSTATE=57019”这个错 说是没有前滚,

转如何检查数据库是否处于一致性的状态 以及 如果在DG 库上备份,恢复成一个主库

##sample 0 不完全恢复之后,open resetlogs之前,怎么快速的检查数据库是否处于一致性的状态?https://blog.csdn.net/msdnchina/article/details/55515313 How to quickly check that Database is consistent after incomplete recovery (Point in Time Recovery) before OPEN RESETLOGS (Doc ID 135425

错误的配置使reduce tasks一直处于Pending状态

正确设置Hadoop程序运行时的参数可以提高程序的运行效率,但是错误的设置也会带来效率的降低,甚至程序的失败.我今天就遇到了这种情况,事情是这样的: 在Hadoop的配置中有这样一个参数: mapred.reduce.slowstart.completed.maps: 这个参数控制reducer何时开始运行,也就是何时开始将mapper的输出拷贝到reducer本地.通常情况下,reducer不必等待所有mapper都运行结束后才开始拷贝,合理设置这个属性可以减少整个job的运行时间.比如,如果

[翻译自mos文章]不完全恢复之后,open resetlogs之前,怎么快速的检查数据库是否处于一致性的状态?

不完全恢复之后,open resetlogs之前,怎么快速的检查数据库是否处于一致性的状态? 翻译自: How to quickly check that Database is consistent after incomplete recovery (Point in Time Recovery) before OPEN RESETLOGS (Doc ID 1354256.1) 适用于: Oracle Database - Enterprise Edition - Version 9.0.1

【翻译自mos文章】CRS显示 正在运行的db instance 是offline状态

CRS显示 正在运行的db instance 是offline状态 转自: CRS shows Running Instance Status as OFFLINE (Doc ID 1673397.1) 适用于: Oracle Database - Enterprise Edition - Version 11.2.0.2 to 11.2.0.3 [Release 11.2] Information in this document applies to any platform. 症状: 在c

winform如何实现一个窗体显示后,他的窗体处于不可编辑状态

1)可以使用this.Enabled = false;是窗体处于不可编辑状态. 2)使用showDialog(),showDialog()是一个对话框窗口界面```执行结果以新窗口界面出现```不允许进行后台运行```就是你想编辑什么的时候```非得先关闭showDialog()窗口界面才可以进行其他操作

ORA-01502: 索引或这类索引的分区处于不可用状态

在 Oracle中的rowid例子中 执行了 alter table ACTOR move tablespace users; 后来在ACTOR表上执行插入语句时候报错 INSERT INTO "SAKILA"."ACTOR" ("FIRST_NAME","LAST_NAME","LAST_UPDATE")VALUES('张', '三', SYSDATE); 错误信息 ORA-01502: 索引或这类索引的

summit交易的expect flow不能从pending状态更新到SAPR状态

[问题描述] 交易的expect flow不能从pending状态更新到SAPR状态,可能是pre-settlement server的问题. [解决方法] 该问题是因为目前系统内堆积了比较多的待处理的消息,约40万的样子, 且系统环境比较慢, 所以新录入的交易的EXPFLOW无法正常编程SAPR, 通过调整了表dmLC_PROCESSED_SEQ 里面的presettlement的seqnum, 将历史的消息报文都跳过去了,现在现金流已经可以正常SAPR了,业务用户可以测试SWIFT和CHAT

请教 JTable 里的单元格如何使得双击进入单元格后,单元格的内容处于全选中状态

http://bbs.csdn.net/topics/390195204 ———————————————————————————————————————— java 达人, 最近在开发一个 java 模块,用到了 JTable.现在对 JTable 里的单元格的操作中,在双击进入单元格后,单元格的内容不是全选中状态. 请问有啥办法使得双击进入单元格后,单元格的内容处于全选中状态?如下面的图片所示 十分感谢! 下面是已经写好的代码: Java code? 1 2 3 4 5 6 7 8 9 10