Document ID: 20414
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Database Recovery Operation
Cisco Support Community - Featured Conversations
Related Information
Introduction
This document discusses how the Microsoft SQL Server handles database recovery after a restart.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
-
Cisco Intelligent Contact Management (ICM)
-
Microsoft SQL Query Utilities (Query Analyzer for Microsoft SQL Server version 7.0 or ISQL_W for Microsoft SQL Server version 6.5)
Components Used
The information in this document is based on these software and hardware versions:
-
Cisco ICM version 4.6.2 and later
-
Microsoft SQL version 6.5 and 7
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Database Recovery Operation
When you restart Microsoft SQL Server, each database automatically performs a recovery operation. SQL Server uses the transaction log. Therefore, when SQL Server restarts:
-
Uncommitted transactions are rolled back. Uncommitted transactions refer to transactions that were in progress when SQL Server shut down or when the system failed.
-
Transactions that are committed between the last checkpoint and the failure are verified, and rolled forward.
Note: In each database, the automatic recovery mechanism looks at the transaction log. If the log has committed transactions that are not yet written to the database, the mechanism performs those transactions again. This action is known as "rolling forward".
Automatic recovery begins with the standard databases that exist in all SQL Server installations. Automatic recovery starts with the master database, goes on to model, clears out the tempdb temporary database, recovers msdb, recovers pubs, and finally recovers the ICM database. This recovery process can take some time, during which you cannot start ICM services.
In order to find out when the recovery process is complete, search the error log for the "Recovery complete" message.
In order to view the error log, type cd \mssql\log, and then type errorlog.
You can also use the Enterprise Manager. On the Server menu, select Errorlog.
Here is a typical log entry:
Recovery dbid 4 ckpt (3593,9) oldest tran=(3593,0)
1 transactions rolled forward in dbid 4.
Recovering database 'pubs'
Recovery dbid 5 ckpt (780,19) oldest tran=(780,0)
Recovering database 'fusa0_hds'
Recovery dbid 7 ckpt (425239,4) oldest tran=(436100,16)
1 transactions rolled forward in dbid 7.
1 transactions rolled back in dbid 7.
Recovering database 'fusa0_awdb'
Recovery dbid 8 ckpt (102445,22) oldest tran=(102445,21)
1 transactions rolled forward in dbid 8.
Recovery complete.
SQL Server's default sort order is:
'bin_iso_1' (ID = 50)
on top of default character set:
'iso_1' (ID = 1)
Launched startup procedure 'sp_sqlregister'
Note: The automatic recovery process cannot complete the task when the transaction log is full. In such a case, the recovery process initiates a log dump. When the dump is complete, recovery resumes.
Cisco Support Community - Featured Conversations
Related Information
| Updated: Apr 12, 2005 | Document ID: 20414 |
