数据库startup报错_SQL Server数据库恢复过程内部–数据库STARTUP命令

数据库startup报错

A database recovery process is an essential requirement for database systems, It can be a tedious job and the process of recovery varies on lot of scenarios. The desire to improve recovery results has resulted in various procedures, but understood by few and prone to errors. In this article, I’ll illustrate the impact of stopping the database instance in the middle of a large transaction that was running and discuss several techniques and tools that are available for faster and successful recovery.

数据库恢复过程是数据库系统的基本要求，这可能是一项繁琐的工作，并且恢复过程在许多情况下都不同。 改善恢复结果的愿望导致了各种程序，但很少被人理解并且容易出错。 在本文中，我将说明在正在运行的大型事务中间停止数据库实例的影响，并讨论可用于更快，成功恢复的几种技术和工具。

介绍 (Introduction)

Let’s discuss a scenario where we have a SAN disk issue and latency is really high and think many jobs on the data warehouse systems started running indefinitely without a success.

让我们讨论一个存在SAN磁盘问题且延迟确实很高的情况，并认为数据仓库系统上的许多作业会无限期地开始运行，但没有成功。

The owner of the server felt this might be a server issue and decided to restart the server but from that point he’s invited trouble. Everything comes back but he’s nw not able to query the database because of a block generated by the system process on the user sessions during the recovery process. This leads to an involvement of senior DBA to troubleshoot the problem.

服务器的所有者认为这可能是服务器问题，因此决定重新启动服务器，但是从那点起，他引起了麻烦。 一切都恢复了，但是由于在恢复过程中系统进程在用户会话上对用户会话产生了阻止，因此他现在无法查询数据库。 这导致高级DBA介入以解决问题。

The server came back and databases were up and running, however, they were able to query the other objects but not the one which took part in the recovery process.

服务器恢复，数据库启动并运行，但是，它们能够查询其他对象，但不能查询参与恢复过程的对象。

After brainstorming sessions, they came to know that the SQL job was purging 25 Million rows from the database. A general rule of thumb is that it will take about the same amount of time, or more, for an aborted transaction to rollback as it has taken to run. The rollback can’t be avoided even with the SQL Server stops and starts. There might be chances of corruption if you try to restart multiple times.

经过集思广益的会议后，他们知道SQL作业正在从数据库中清除2500万行。 一般的经验法则是，中止的事务回滚所花费的时间与运行所花费的时间相同或更多。 即使SQL Server停止并启动，也无法避免回滚。 如果尝试多次重新启动，则可能会损坏。

Now, we have to address two issues

现在，我们必须解决两个问题

• Work with network team to fix poor I/O subsystems which directly impacting the disk latency
  与网络团队合作修复可直接影响磁盘延迟的不良I / O子系统
• The disk latency has a direct impact on the recovery process
  磁盘延迟会直接影响恢复过程

The first and foremost important thing is that checking the status of each database

首先，最重要的是检查每个数据库的状态

Though the database came online, it doesn’t mean that the recovery of each database is done and it’s available for further operations that are what happened in this case.

尽管数据库已联机ÿ