Correzione automatica delle pagine (Gruppi di disponibilità: Mirroring del database)

Si applica a:SQL Server

La correzione automatica della pagina è supportata dal mirroring del database e dai gruppi di disponibilità Always On. Dopo che alcuni tipi di errori danneggiano una pagina rendendola illeggibile, un partner del mirroring del database (principale o mirror) oppure una replica di disponibilità (primaria o secondaria) tenta di ripristinare automaticamente la pagina. Il partner/la replica che non è in grado di leggere la pagina richiede una copia aggiornata della pagina al proprio partner o a un'altra replica. Se la richiesta viene soddisfatta, la pagina illeggibile viene sostituita dalla copia leggibile. In questo modo, l'errore viene in genere risolto.

In generale, gli errori di I/O possono essere gestiti dal mirroring del database e dai gruppi di disponibilità Always On in modi equivalenti. Di seguito sono illustrate in modo esplicito le poche differenze.

• Tipi di errore che provocano un tentativo di correzione automatica delle pagine

• Tipi di pagine che non possono essere corrette automaticamente

• Gestione degli errori di I/O nel database principale o primario

• Gestione degli errori di I/O nel database mirror o secondario

• Procedura consigliata dagli sviluppatori

• Procedura: Visualizzare i tentativi di correzione automatica della pagina

Tipi di errore che provocano un tentativo di correzione automatica delle pagine

Durante la correzione automatica delle pagine tramite mirroring del database, viene eseguito il tentativo di ripristinare solo le pagine in un file di dati in cui non è stato possibile completare un'operazione, a causa di uno degli errori elencati nella tabella seguente.

Per visualizzare gli errori CRC 823 e gli errori 824 recenti, vedere la tabella suspect_pages nel database msdb .

Tipi di pagine che non possono essere corrette automaticamente

La correzione automatica della pagina non può ripristinare i tipi di pagine di controllo seguenti:

• Pagina di intestazione del file (ID pagina 0).

• Pagina 9 (pagina di avvio del database).

• Pagine di allocazione: pagine mappa di allocazione globale (GAM, Global Allocation Map), pagine mappa di allocazione globale condivisa (SGAM, Shared Global Allocation Map) e pagine spazio libero nella pagina (PFS, Page Free Space).

Gestione degli errori di I/O nel database principale o primario

Nel database principale/primario, la riparazione automatica della pagina viene tentata solo quando il database è nello stato SINCRONIZZATO e il database principale/primario sta ancora inviando record di log per il database al database mirror/secondario. La sequenza di azioni di base in un tentativo di correzione automatica della pagina è la seguente:

1. Quando si verifica un errore di lettura in una pagina dati del database principale/primario, il database principale/primario inserisce una riga nella tabella suspect_pages con lo stato di errore appropriato. Per il mirroring del database, il server principale richiede quindi una copia della pagina al server mirror. Per i gruppi di disponibilità Always On, il primario trasmette la richiesta a tutti i secondari e ottiene la pagina dal primo che risponde. Nella richiesta viene specificato l'ID della pagina e il numero LSN presente attualmente al termine del log scaricato. La pagina è contrassegnata come ripristino in sospeso. In questo modo non sarà possibile accedervi durante il tentativo di correzione automatica della pagina. L'accesso a questa pagina durante il tentativo di correzione non verrà consentito e sarà visualizzato l'errore 829 (ripristino in sospeso).

2. Dopo aver ricevuto la richiesta di pagina, il mirror/secondario attende di aver rieseguito il log fino all'LSN specificato nella richiesta. Successivamente, il server mirror/secondario tenta di accedere alla pagina nella propria copia del database. Se è possibile accedere alla pagina, il mirror/secondario invia la copia della pagina al principale/primario. In caso contrario, tramite il database mirror o secondario viene restituito un errore al database principale o primario e il tentativo di correzione automatica della pagina non verrà completato.

3. Il nodo principale/primario elabora la risposta che contiene la copia aggiornata della pagina.

4. Una volta completata la correzione automatica di una pagina sospetta, la pagina viene contrassegnata nella tabella suspect_pages come ripristinata (event_type = 5).

5. Se l'errore di I/O della pagina ha causato una o più transazioni differite, dopo aver riparato la pagina, il server principale/primario tenta di risolvere tali transazioni.

Gestione degli errori di I/O nel database mirror o secondario

Gli errori di I/O nelle pagine di dati che si verificano nel database mirror o secondario sono gestiti in genere nello stesso modo dal mirroring del database e dai gruppi di disponibilità Always On.

1. Con il mirroring del database, se il mirror incontra uno o più errori di I/O della pagina quando ripete un record del log, la sessione di mirroring entra nello stato SUSPENDED. Con i gruppi di disponibilità Always On, se una replica secondaria riscontra uno o più errori di I/O della pagina quando riesegue un record di log, il database secondario entra nello stato SUSPENDED. A quel punto, il mirror/secondario inserisce una riga nella tabella suspect_pages con lo stato di errore appropriato. Dal database mirror o secondario viene quindi richiesta una copia della pagina dal database principale o primario.

2. Il nodo principale/primario tenta di accedere alla pagina nella propria copia del database. Se è possibile accedere alla pagina, il database principale o primario invia la copia della pagina al database mirror o secondario.

3. Se il database mirror o secondario riceve copie di tutte le pagine richieste, tenta di riprendere la sessione di mirroring. Se la correzione automatica di una pagina sospetta viene eseguita, la pagina viene contrassegnata nella tabella suspect_pages come ripristinata (event_type = 4).

   Se da un database mirror o secondario non si riceve una pagina richiesta dal database principale o primario, il tentativo di correzione automatica della pagina non verrà completato. Con il mirroring del database, la sessione di mirroring rimane sospesa. Con i gruppi di disponibilità Always On, il database secondario rimane sospeso. Se la ripresa della sessione di mirroring o del database secondario viene eseguita manualmente, le pagine danneggiate verranno rilevate nuovamente durante la fase di sincronizzazione.

Procedura consigliata dagli sviluppatori

La correzione automatica di una pagina è un processo asincrono eseguito in background. Pertanto, non sarà possibile completare un'operazione sul database tramite cui viene richiesta una pagina illeggibile e verrà restituito il codice di errore relativo alla condizione che lo ha causato. In fase di sviluppo di un'applicazione per un database con mirroring o un database di disponibilità, è consigliabile intercettare le eccezioni per le operazioni con errori. Se il codice di errore di SQL Server è 823, 824 o 829, ripetere l'operazione in un secondo momento.

Procedura: Visualizzare i tentativi di correzione automatica della pagina

Le seguenti viste a gestione dinamica restituiscono righe relative ai tentativi più recenti di ripristino automatico delle pagine in un determinato database di disponibilità o database con mirroring, con un massimo di 100 righe per database.

• Gruppi di disponibilità AlwaysOn:

  sys.dm_hadr_auto_page_repair (Transact-SQL)

  Restituisce una riga per ogni tentativo di ripristino automatico della pagina in qualsiasi database di disponibilità su ogni replica di disponibilità ospitata dall'istanza del server per qualsiasi gruppo di disponibilità.

• Replica del database:

  sys.dm_db_mirroring_auto_page_repair (Transact-SQL)

  Viene restituita una riga per ogni tentativo di correzione automatica della pagina in qualsiasi database con mirroring nell'istanza del server.

Contenuti correlati

• Gestire la tabella suspect_pages (SQL Server)
• Cos’è il gruppo di disponibilità Always On?
• Database Mirroring (SQL Server)