Автоматическое восстановление страниц (группы доступности: зеркальное отображение базы данных)Automatic Page Repair (Availability Groups: Database Mirroring)

ОБЛАСТЬ ПРИМЕНЕНИЯ: даSQL Server нетБаза данных SQL AzureнетХранилище данных SQL AzureнетParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

Автоматическое восстановление страниц поддерживается за счет зеркального отображения баз данных и с помощью Группы доступности AlwaysOnAlways On availability groups.Automatic page repair is supported by database mirroring and by Группы доступности AlwaysOnAlways On availability groups. После повреждения страниц вследствие ошибок определенных типов, после чего страницы становятся нечитаемыми, база данных, участвующая в зеркальном отображении (главная или зеркало), либо реплика доступности (основная или вторичная) выполняет попытку автоматического восстановления страницы.After certain types of errors corrupt a page, making it unreadable, a database mirroring partner (principal or mirror) or an availability replica (primary or secondary) attempts to automatically recover the page. Участник или реплика, для которой считывание страницы невозможно, запрашивает новую копию у другого участника или реплики.The partner/replica that cannot read the page requests a fresh copy of the page from its partner or from another replica. Если этот запрос завершается успешно, нечитаемая страница заменяется читаемой копией, что обычно устраняет ошибку.If this request succeeds, the unreadable page is replaced by the readable copy, and this usually resolves the error.

В целом зеркальное отображение базы данных и Группы доступности AlwaysOnAlways On availability groups обрабатывают ошибки ввода-вывода сходным образом.Generally speaking, database mirroring and Группы доступности AlwaysOnAlways On availability groups handle I/O errors in equivalent ways. В этом разделе описываются немногие из отличий.The few differences are explicitly called out here.

Примечание

Автоматическое восстановление страниц отличается от восстановления DBCC.Automatic page repair differs from DBCC repair. При автоматическом восстановлении страниц все данные сохраняются.All of the data is preserved by an automatic page repair. При исправлении ошибок с помощью параметра REPAIR_ALLOW_DATA_LOSS может потребоваться удаление некоторых страниц и, следовательно, данных.In contrast, correcting errors by using the DBCC REPAIR_ALLOW_DATA_LOSS option might require that some pages, and therefore data, be deleted.

Типы ошибок, вызывающие попытку автоматического восстановления страницыError Types That Cause an Automatic Page-Repair Attempt

Система автоматического восстановления страниц зеркального отображения базы данных восстанавливает только страницы, которые находятся в файле данных, для которого операция завершилась с одной из ошибок, перечисленных в приведенной ниже таблице.Database mirroring automatic page repair tries to repair only pages in a data file on which an operation has failed for one of the errors listed in the following table.

Номер ошибкиError number ОписаниеDescription Экземпляры, вызывающие попытку автоматического восстановления страницыInstances that cause automatic page-repair attempt
823823 Действие предпринимается только в том случае, если операционная система выполнила циклическую проверку избыточности (CRC), которая завершилась неудачно для этих данных.Action is taken only if the operating system performed a cyclic redundancy check (CRC) that failed on the data. ERROR_CRC.ERROR_CRC. Код этой ошибки в операционной системе — 23.The operating-system value for this error is 23.
824824 Логические ошибки.Logical errors. Логические ошибки данных, например прерванная запись или несовпадающая контрольная сумма страницы.Logical data errors, such as torn write or bad page checksum.
829829 Страница отмечена, как ожидающая восстановления.A page has been marked as restore pending. Все.All.

Просмотреть все недавние ошибки 823 (CRC) и 824 можно в таблице suspect_pages базы данных msdb .To view recent 823 CRC errors and 824 errors, see the suspect_pages table in the msdb database.

Page Types That Cannot Be Automatically RepairedPage Types That Cannot Be Automatically Repaired

Автоматическое восстановление страниц не может исправить следующие типы страниц управления.Automatic page repair cannot repair the following control page types:

  • Страница заголовка файла (идентификатор страницы 0).File header page (page ID 0).

  • Страница 9 (загрузочная страница базы данных).Page 9 (the database boot page).

  • Страницы размещения: страницы глобальной карты распределения (GAM), страницы общей глобальной карты (SGAM) и страницы свободного места на странице (PFS).Allocation pages: Global Allocation Map (GAM) pages, Shared Global Allocation Map (SGAM) pages, and Page Free Space (PFS) pages.

Обработка ошибок ввода-вывода в основной базы данныхHandling I/O Errors on the Principal/Primary Database

В основной базе данных или в базе данных-источнике попытка автоматического восстановления страницы предпринимается только если база данных находится в состоянии SYNCHRONIZED, а основная база или база-получатель данных продолжает посылать записи журнала в зеркальную базу данных или в базу данных-получатель.On the principal/primary database, automatic page repair is tried only when the database is in the SYNCHRONIZED state and the principal/primary is still sending log records for the database to the mirror/secondary. При попытке автоматического восстановления страницы выполняется следующая основная последовательность действий:The basic sequence of actions in an automatic page-repair attempt are as follows:

  1. При возникновении ошибки чтения на странице данных в базе данных-получателе или в базе данных-источнике база данных-получатель или база данных-источник вставляет в таблицу suspect_pages строку с соответствующим статусом ошибки.When a read error occurs on a data page in the principal/primary database, the principal/primary inserts a row in the suspect_pages table with the appropriate error status. При использовании зеркального отображения базы данных, основная база данных запрашивает копию страницы у зеркального сервера.For database mirroring, the principal then requests a copy of the page from the mirror. При использовании Группы доступности AlwaysOnAlways On availability groups, основная база данных передает запрос всем вторичным базам данных и получает страницу от первой откликнувшейся базы данных.For Группы доступности AlwaysOnAlways On availability groups, the primary broadcasts the request to all the secondaries and gets the page from the first to respond. В запросе указывается идентификатор страницы и номер LSN, находящийся в данный момент в конце текущего журнала.The request specifies the page ID and the LSN that is currently at the end of the flushed log. Страница помечается как ожидающая восстановления.The page is marked as restore pending. Это делает ее недоступной на время попытки автоматического восстановления.This makes it inaccessible during the automatic page-repair attempt. Любое обращение к этой странице во время попытки восстановления завершится с ошибкой 829 (ожидает восстановления).Attempts to access this page during the repair attempt will fail with error 829 (restore pending).

  2. После получения запроса страницы зеркальный/вторичный сервер ожидает, пока его журнал не будет восстановлен до номера LSN, указанного в запросе.After receiving the page request, the mirror/secondary waits until it has redone the log up to the LSN specified in the request. Затем зеркальный/вторичный сервер пытается получить доступ к странице в своей копии базы данных.Then, the mirror/secondary tries to access the page in its copy of the database. Если к странице возможен доступ, зеркальный/вторичный сервер посылает копию страницы на основной/первичный сервер.If the page can be accessed, the mirror/secondary sends the copy of the page to the principal/primary. В противном случае зеркальный/вторичный сервер возвращает основному/первичному серверу ошибку, а попытка автоматического восстановления страницы завершается неудачно.Otherwise, the mirror/secondary returns an error to the principal/primary, and the automatic page-repair attempt fails.

  3. Основной сервер/первичный сервер обрабатывает ответ, содержащий новую копию страницы.The principal/primary processes the response that contains the fresh copy of the page.

  4. После того как попытка автоматического восстановления завершается успешно, подозрительная страница отмечается в таблице suspect_pages как восстановленная (event_type = 5).After the automatic page-repair attempt fixes a suspect page, the page is marked in the suspect_pages table as restored (event_type = 5).

  5. Если ошибка ввода-вывода вызвала возникновение каких-либо отложенных транзакций, то после восстановления страницы основной/первичный сервер попытается разрешить эти транзакции.If the page I/O error caused any deferred transactions, after you repair the page, the principal/primary tries to resolve those transactions.

Обработка ошибок ввода-вывода на зеркальный/вторичный сервер базы данныхHandling I/O Errors on the Mirror/Secondary Database

Ошибки ввода-вывода, возникающие на страницах данных зеркальной базы данных или базы данных-получателе, обычно обрабатываются одинаково, как при зеркальном отображении базы данных, так и при использовании Группы доступности AlwaysOnAlways On availability groups.I/O errors on data pages that occur on the mirror/secondary database are handled in generally the same way by database mirroring and by Группы доступности AlwaysOnAlways On availability groups.

  1. В случае с зеркальным отображением баз данных, если зеркальный сервер обнаруживает одну или несколько ошибок ввода-вывода при восстановлении записи журнала, сеанс зеркального отображения переходит в состояние SUSPENDED.With database mirroring, if the mirror encounters one or more page I/O errors when it redoes a log record, the mirroring session enters the SUSPENDED state. В случае Группы доступности AlwaysOnAlways On availability groups, если вторичная реплика обнаруживает одну или несколько ошибок ввода-вывода при восстановлении записи журнала, база данных-получатель переходит в состояние SUSPENDED.With Группы доступности AlwaysOnAlways On availability groups, if a secondary replica encounters one or more page I/O errors when it redoes a log record, the secondary database enters the SUSPENDED state. В этот момент зеркальный/вторичный сервер вставляет в таблицу suspect_pages строку с соответствующим состоянием ошибки.At that point, the mirror/secondary inserts a row in the suspect_pages table with the appropriate error status. Затем зеркальный/вторичный сервер запрашивает копию страницы у основного/первичного сервера.The mirror/secondary then requests a copy of the page from the principal/primary.

  2. Основной/первичный сервер пытается получить доступ к странице в своей копии базе данных.The principal/primary tries to access the page in its copy of the database. Если к странице возможен доступ, основной/первичный сервер отправляет копию страницы на зеркальный/вторичный сервер.If the page can be accessed, the principal/primary sends the copy of the page to the mirror/secondary.

  3. Если зеркальный/вторичный сервер получает копии всех запрошенных страниц, он попытается возобновить сеанс зеркального отображения.If the mirror/secondary receives copies of every page it has requested, the mirror/secondary tries to resume the mirroring session. Если попытка автоматического восстановления завершается успешно, подозрительная страница отмечается в таблице suspect_pages как восстановленная (event_type = 4).If an automatic page-repair attempt fixes a suspect page, the page is marked in the suspect_pages table as restored (event_type = 4).

    Если зеркальный/вторичный сервер не получает от основного/первичного сервера запрошенную страницу, то попытка автоматического восстановления страницы завершается неудачно.If a mirror/secondary does not receive a page that it requested from the principal/primary, the automatic page-repair attempt fails. При использовании зеркального отображения баз данных, сеанс отображения приостанавливается.With database mirroring, the mirroring session remains suspended. При использовании Группы доступности AlwaysOnAlways On availability groupsбаза данных-получатель остается в приостановленном состоянии.With Группы доступности AlwaysOnAlways On availability groups, the secondary database remains suspended. Если сеанс зеркального отображения или база данных-получатель повторно запускаются вручную, то во время фазы синхронизации снова произойдет обращение к поврежденным страницам.If the mirroring session or secondary database is resumed manually, the corrupted pages will be hit again during the synchronization phase.

Developer Best PracticeDeveloper Best Practice

Автоматическое восстановление страниц — это асинхронный процесс, выполняющийся в фоновом режиме.An automatic page repair is an asynchronous process that runs in the background. Поэтому, если в ходе операции базы данных запрашивается нечитаемая страница, возникает ошибка и возвращается код события, вызвавшего эту ошибку.Therefore, a database operation that requests an unreadable page fails and returns the error code for whatever condition caused the failure. При разработке приложения для отображаемой зеркально базы данных или базы данных доступности следует перехватывать исключения в завершившихся ошибкой операциях.When developing an application for a mirrored database or an availability database, you should intercept exceptions for failed operations. При возникновении ошибок SQL ServerSQL Server с кодами 823, 824 или 829 операцию следует повторить позже.If the SQL ServerSQL Server error code is 823, 824, or 829, you should retry the operation later.

Как Просмотр попыток автоматического восстановления страницыHow To: View Automatic Page-Repair Attempts

В следующих динамических административных представлениях возвращаются строки, связанные с последними попытками автоматического восстановления страниц в определенной зеркальной базе данных, при этом количество строк на каждую базу данных не может превышать 100.The following dynamic management views return rows for the latest automatic page-repair attempts on a given availability database or mirrored database, with a maximum of 100 rows per database.

  • Группы доступности AlwaysOnAlways On Availability Groups:

    sys.dm_hadr_auto_page_repair (Transact-SQL)sys.dm_hadr_auto_page_repair (Transact-SQL)

    Возвращает строку для каждой попытки автоматического восстановления страниц во всех базах данных доступности в реплике доступности, размещенной в группе доступности на экземпляре сервера.Returns a row for every automatic page-repair attempt on any availability database on an availability replica that is hosted for any availability group by the server instance.

  • Зеркальное отображение базы данныхDatabase mirroring:

    sys.dm_db_mirroring_auto_page_repair (Transact-SQL)sys.dm_db_mirroring_auto_page_repair (Transact-SQL)

    Возвращает строку для каждой попытки автоматического восстановления страниц во всех зеркально отображаемых баз данных на экземпляре сервера.Returns a row for every automatic page-repair attempt on any mirrored database on the server instance.

См. также:See Also

Управление таблицей suspect_pages (SQL Server) Manage the suspect_pages Table (SQL Server)
Обзор групп доступности AlwaysOn (SQL Server) Overview of Always On Availability Groups (SQL Server)
Зеркальное отображение базы данных (SQL Server)Database Mirroring (SQL Server)