mysql错误9001_Error: 9001, Severity: 21, State: 5 The log for database 'xxxx' is not available-阿里云开发者社...

昨天下午5点多收到几封告警邮件，我还没有来得及看,GLE那边的同事就电话过来，说数据库出现告警了。让我赶紧看看，案例具体信息如下所示：

告警邮件内容：

DATE/TIME: 2015/1/23 17:08:52

DESCRIPTION:

The log for database 'ecmsDB' is not available. Check the event log for

related error messages. Resolve any errors and restart the database.

错误日志内容：

看着这个库确实没有多少印象，很奇怪的是每次事务日志备份时，都会看到“starting up datatbase"这类信息

“Starting up database 'ecmsDB'.”

日期     2015/1/23 17:03:44

日志     SQL Server (存档编号1 - 2015/1/24 0:00:00)

源     spid116

消息

CHECKDB for database 'ecmsDB' finished without errors on 2015-01-23 00:00:16.247 (local time). This is an informational message only; no user action is required.

于是检查一下该数据库的一些基本信息，发现该数据库被人启动了”自动关闭“属性，如下所示

SELECT name

,create_date

,compatibility_level

,collation_name

,is_auto_close_on

,is_cleanly_shutdown

FROM sys.databases WHERE name='ecmsDB'

数据库的排序规则(collation_name )

作为数据库中的默认排序规则。NULL = 数据库没有联机，或 AUTO_CLOSE 设置为 ON 且数据库已关闭。

自动关闭

指定在上一个用户退出后，数据库是否完全关闭并释放资源。 可能的值包括 True 和 False。 如果设置为 True，则在上一个用户注销之后，数据库会完全关闭并释放其资源。

is_cleanly_shutdown

1 = 数据库完全关闭；在启动时不需要恢复

0 = 数据库并未完全关闭；在启动时需要恢复

分析与解决方法：

我将数据库ecmsDB脱机，然后联机后问题解决，检查数据库

dbcc checkdb('ecmsDB')发现没有什么问题，然后将“自动关闭”属性设置为False，那么为什么会出现这个问题呢？

根据错误信息表示日志已损坏(log corruption). 我有点不得其解，没有弄明白原因？

难道数据库在“自动关闭”开启后，遇到死锁事务会造成这个错误？这会不会是一个bug来的呢？比较这种特殊案例是比较少见的。有两个外国人遇到的案例情况

跟我一致。如下所示

https://dacosta9.wordpress.com/2014/06/26/sql-server-error-9001-severity-21-state-5-the-log-for-database-database_name-is-not-available-check-the-event-log-for-related-error-messages-resolve-any-errors-and-restart-the-database-e/在微软官方也看到有人提了这个bug，但是好像不了了之。