X hits on this document

Word document

SAP with Microsoft SQL Server 2005: Best Practices for High Availability, Maximum Performance, and ... - page 50 / 76

258 views

0 shares

0 downloads

0 comments

50 / 76

SAP with Microsoft SQL Server 2005: Best Practices for High Availability, Maximum Performance, and Scalability46

Redo phase. In the redo phase, data modification that is recorded in the SQL Server transaction log after the last checkpoint is executed is written to the data files. In contrast to earlier SQL Server releases, SQL Server 2005 opens the database after this phase. Any uncommitted data residing in the data files after the redo phase performed is protected by database locks. This prevents the data that is to be rolled back in the next phase of the recovery process from being accessed.

Undo phase. In the undo phase, the data from uncommitted transactions is rolled back. The database is available when the undo begins. In most cases, the undo phase takes significantly longer than the redo phase.

Fast recovery improvements. These improvements in recovery lead to faster failover time for server clustering (MSCS) and faster failover for synchronous database mirroring with failover. In SAP database-mirroring configurations, fast recovery reduces to a minimum the amount of downtime that is triggered by problems.

Media reliability

SQL Server 2005 delivers a number of media reliability improvements including:

Backup with multiple destinations. With SQL Server 2005, a backup can write to up to four different destinations. Multiple sets of tapes can be written for the same backup. When redundant backups are written, the tapes from each destination set are interchangeable with the same tape in the other sets. For example, if a tape from one destination set is lost, the same tape from one of the other sets can be used instead.

Verification of page restores. The RESTORE VERIFYONLY Transact-SQL statement thoroughly investigates the physical structure of a page. The linkage between the pages and the accuracy of the allocation pages is not checked. Pages written with checksum are automatically checked when the page is read into the buffer pool. The change on the page is detected before the page is accessed. This includes disk I/O errors that were not reported by the hardware or operating system.

Restore sequence reliability. The SQL Server 2005 restore sequence continues despite physical inconsistency to give customers an opportunity to repair errors. The restore sequence continues as far as possible before the database needs to be repaired.

Detection of torn pages. SQL Server 2005 allows a checksum to be written on each page. This checksum is used when the page is read back. When irregularities are detected, each is written to the error log.

Microsoft Corporation © 2005

Document info
Document views258
Page views258
Page last viewedTue Dec 06 11:14:51 UTC 2016
Pages76
Paragraphs1372
Words23715

Comments