Sintomi
Supponiamo che tu usi la funzionalità gruppi di disponibilità AlwaysOn in Microsoft SQL Server 2012. Quando si modifica l'accesso alla connessione della replica secondaria da "leggibile" a "illeggibile", si verifica un danneggiamento nelle pagine che usano la compressione della pagina nella replica specificata.I database di disponibilità che avvertono questo problema alla replica secondaria non possono essere recuperati a causa di un errore durante la fase di ripetizione della sincronizzazione. La replica secondaria non viene sincronizzata con la replica primaria e segnala uno stato di sincronizzazione di "SUSPEND_FROM_REDO". Vengono inoltre visualizzati i messaggi di errore seguenti nel log degli errori di SQL Server che ospita la replica secondaria:
<data> <ora> SPID<ID> errore: 17066, gravità: 16, stato: 1. <data> <ora> SPID> <0 ID> SQL Server Assertion: file: <page. cpp>, line = 3898 asserzione non riuscita ='! pageFull '. Questo errore può essere correlato alla temporizzazione. Se l'errore persiste dopo la riesecuzione dell'istruzione, usare DBCC CHECKDB per controllare il database per l'integrità strutturale oppure riavviare il server per verificare che le strutture di dati in memoria non siano danneggiate. <data> <ora> SPID<ID> errore: 3624, gravità: 20, stato: 1. <data> <ora> SPID> <0 ID> un controllo delle asserzioni di sistema Per informazioni dettagliate, vedere il log degli errori di SQL Server. In genere, un errore di asserzione è causato da un bug software o da un danneggiamento dei dati. Per verificare il danneggiamento del database, provare a eseguire DBCC CHECKDB. Se si è deciso di inviare dump a Microsoft durante l'installazione, verrà inviato un mini dump a Microsoft. Un aggiornamento potrebbe essere disponibile da Microsoft nel Service Pack più recente o in un QFE dal supporto tecnico. <data> <ora> SPID<ID> gruppi di disponibilità AlwaysOn lo spostamento dei dati per il database ' <nome database>' è stato sospeso per il motivo seguente: "sistema" (ID origine 2; Stringa di origine:' SUSPEND_FROM_REDO '). Per riprendere lo spostamento dei dati nel database, è necessario riprendere il database manualmente. Per informazioni su come riprendere un database di disponibilità, vedere la documentazione online di SQL Server. <data> <ora> SPID<ID> errore: 3313, gravità: 21, stato: 2. <Data> <ora> SPID> <0 ID> durante la riproduzione di un'operazione registrata nel database "<nome database>" si è verificato un errore nell'ID record del log (1786:4978584:74). In genere, il problema specifico viene registrato in precedenza come errore nel servizio log eventi di Windows. Ripristinare il database da un backup completo o ripristinare il database. <data> <ora> SPID<ID> ALTER DB param opzione: Resume<data> <ora> SPID> <0 ID> gruppi di disponibilità AlwaysOn lo spostamento dei dati per il database ' <nome database>' è stato ripristinato. Si tratta solo di un messaggio informativo. Non è necessaria alcuna azione per l'utente. <data> <ora> SPID<ID> transazioni non qualificate viene eseguito il rollback in database <nome database> per una modifica dello stato dei gruppi di disponibilità AlwaysOn. Completamento del rollback stimato: 100%. Si tratta solo di un messaggio informativo. Non è necessaria alcuna azione utente. <data> <ora> SPID<ID> gruppi di disponibilità AlwaysOn connessione con il database primario terminato per il database secondario "<nome database>" nella replica di disponibilità con ID replica: {bbdedecb-f26b-47e9-9e7d-7c22f99edb23}. Si tratta solo di un messaggio informativo. Non è necessaria alcuna azione per l'utente. <data> <ora> SPID<ID> l'avvio del database ' <nome database>'. <Data> <ora> SPID> <2 ID> il ripristino del database ' <nome database>' (13) è 0% completamento (circa 781 secondi rimangono). Fase 1 di 3. Si tratta solo di un messaggio informativo. Non è necessaria alcuna azione per l'utente.......
Risoluzione
Il problema è stato risolto per la prima volta nel seguente aggiornamento cumulativo di SQL Server.
Aggiornamento cumulativo 6 per SQL server 2012 SP2 aggiornamento cumulativo 16 per SQL Server 2012 SP1
Ogni nuovo aggiornamento cumulativo per SQL Server contiene tutti gli hotfix e tutti gli aggiornamenti della sicurezza inclusi nell'aggiornamento cumulativo precedente. Vedere gli ultimi aggiornamenti cumulativi per SQL Server:
Ulteriori informazioni
Il problema precedente può verificarsi quando l'accesso in lettura viene modificato per la replica secondaria. Per impostare l'accesso in lettura ai database di disponibilità nella replica secondaria, è possibile usare i due metodi seguenti:
-
Impostare l'accesso in lettura usando il comando ALTER AVAILABILITY GROUP:
ALTER AVAILABILITY GROUP [AGName]MODIFY REPLICA ON N'<SRV>' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = NO))
-
Impostare l'accesso in lettura modificando le impostazioni in Esplora oggetti di SQL Server Management Studio (SSMS):
-
Connettersi al server e quindi aprire la cartella di disponibilità AlwaysOn.
-
Aprire la cartella gruppi di disponibilità.
-
Fare clic con il pulsante destro del mouse sul gruppo disponibilità e scegliere Proprietà.
-
Modificare la proprietà secondaria leggibile per la replica secondaria in Noe quindi fare clic su OK.
-
Stato
Microsoft ha confermato che questo problema si verifica nei prodotti elencati nella sezione "Si applica a".
