Microsoft sql server I/o basics: Chapter 2



Yüklə 0,61 Mb.
səhifə6/7
tarix16.08.2018
ölçüsü0,61 Mb.
#63142
1   2   3   4   5   6   7
In-memory checksums

SQL Server 2005 extends the protection of data pages by extending the PAGE_VERIFY CHECKSUM to allow for in-memory checksumming. There are limited situations for which this is helpful, such as in-memory scribblers, uncertainty about page file stability, and uncertainty about RAM memory stability.

The same checksum algorithm used by PAGE_VERIFY CHECKSUM is used for the in-memory data page checksum activity. Those pages that have been written to stable media with a CHECKSUM status are eligible for in-memory checksumming if the dynamic trace flag –T831 is enabled. The data page must have received the initial checksum value during a write to stable media to participate in the in-memory checksum operations.

To reduce the performance affect, the in-memory checksum is only audited during certain page state transitions. The key page states that trigger in-memory checksumming are outlined after the table. The following table describes the states that a page can be in.


Page State

State Description

Dirty

The data page is considered to be dirty when the page has been modified and has not been written to stable media. As soon as a dirty page is saved (written) to stable media, it is considered to be clean.

Clean

The data page is considered to be clean or a constant page when it is the same image as that stored on stable media.

In-memory checksum auditing occurs on a data page when the following conditions are true:



  • The page was written to disk when PAGE_VERIFY CHECKSUM was enabled.

  • The PAGE_VERIFY CHECKSUM option is enabled for the database.

  • Trace flag –T831 is enabled.

The PAGE_VERIFY actions continue to occur during the read and write of data pages. The in-memory checksumming occurs when –T831 is enabled. The following table outlines the checksum actions that occur when the database is correctly enabled for CHECKSUM protection, the page contains a valid checksum, and trace flag –T831 is enabled.


Action

Description

Page Read



Page State

State Description

Physical Read

Checksum is validated as soon as the read finishes; the checksum is retained for in-memory validation.

Logical Read

No in-memory checksum auditing occurs.



Page Modification
Request




Page State

State Description

Dirty

As soon as a page has been dirtied, the checksum is no longer maintained. The checksum will be recalculated when the page is written to stable media.

No in-memory checksum auditing occurs.



Clean

The transition from clean to dirty triggers in-memory checksum validation. A failure during this transition indicates that the page was damaged during a period in which it was considered to be read-only.



Discard

A page is termed ‘discarded’ when it is returned to the free list.

Page State

State Description

Dirty

A dirty page cannot be discarded. The page must first be written to stable media and returned to a clean state before it can be discarded.

Clean

The act of discarding a clean page triggers in-memory checksum validation. A failure during this transition indicates that the page was damaged during a period in which it was considered to be read-only.

Note: Pages that are never modified (never dirtied) remain in the clean state until they are discarded at which time the checksum is validated for the constant page.

For added, always on, protection the lazy writer performs clean (constant) buffer checksum validations. This is always on and does not require that –T831 be enabled. Every second the lazy writer updates the buffer pool performance counters and performs various housekeeping activities. During this housekeeping, the lazy writer sweeps over 16 buffers. When the lazy writer finds a clean buffer with a valid checksum, it validates the checksum. If a failure is detected, an 832 error message is logged. This is used as a low affect, background, in-memory checksum audit activity. Pages that remain in a clean (constant) state for lengthy periods enable the lazy writer audit to catch unexpected damage before the page is discarded.



If the audit check fails, SQL Server error message 832 is reported to indicate that the error condition was detected. If you are encountering in-memory checksum failures, perform the following diagnostics.

  • Test backups to make sure that the restore strategy remains correctly intact.

  • Perform full hardware testing, focusing specifically on memory components.

  • Review any third-party products installed on the system or that are used in the SQL Server process space. Third-party components could scribble and cause problems. Such components could be COM objects, extended stored procedures, Linked Servers, or other entities.

  • Make sure that all operating system fixes are applied to the server.

  • Make sure that any virus protection is up to date and the system is free of viruses.

  • Review the location of the page file for SQL Server I/O compliance requirements.

  • Enable latch enforcement as described later in this document to help isolate the source of the damage.

  • Try to use the same input buffers or replay a SQL Server Profiler trace to reproduce the problem. If a reproduction is obtained, can it be reproduced on another computer? If it can be reproduced, contact Microsoft SQL Server Support for additional assistance.

Yüklə 0,61 Mb.

Dostları ilə paylaş:
1   2   3   4   5   6   7




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə