Mirroring asincrono del database (modalità a prestazioni elevate)
Data aggiornamento: 5 dicembre 2005
Quando il livello di protezione delle transazioni viene impostato su OFF, la sessione di mirroring del database opera in modo asincrono. Le operazioni asincrone supportano solo una modalità operativa, ovvero la modalità a prestazioni elevate. Questa modalità migliora le prestazioni, ma comporta una riduzione della disponibilità. La modalità a prestazioni elevate utilizza solo il server principale e il server mirror. I problemi relativi al server mirror non hanno mai alcun impatto sul server principale. In caso di perdita del server principale, il database mirror viene contrassegnato come DISCONNECTED, ma rimane disponibile come standby a caldo (warm standby).
La modalità a prestazioni elevate supporta solo una forma di cambio di ruolo, ovvero il servizio forzato (con possibile perdita dei dati), che prevede l'utilizzo del server mirror come server di standby a caldo (warm standby). Il servizio forzato rappresenta una delle risposte possibili all'errore del server principale. Poiché può verificarsi una perdita di dati, è consigliabile valutare altre alternative prima di forzare il servizio nel server mirror. Per ulteriori informazioni, vedere "Risposta agli errori del server principale" più avanti in questo argomento.
Nella figura seguente viene illustrata la configurazione di una sessione con l'utilizzo della modalità a prestazioni elevate.
.gif "Configurazione dei partner per una sessione")
In modalità a prestazioni elevate, non appena il server principale invia il log per una transazione al server mirror, il server principale invia una conferma al client, senza attendere un acknowledgement dal server mirror. Il commit delle transazioni viene eseguito senza attendere la scrittura su disco del log da parte del server mirror. L'operazione asincrona consente l'esecuzione del server principale con una latenza minima per le transazioni.
Il server mirror tenta di restare sincronizzato con i record del log inviati dal server principale. Il database mirror, tuttavia, è soggetto sempre a un certo ritardo rispetto al database principale. Il divario tra i database è in genere di entità ridotta, ma può diventare significativo se il server principale è soggetto a un ingente carico di lavoro o se il sistema del server mirror è sottoposto a overload.
Casi in cui la modalità a prestazioni elevate rappresenta la soluzione più appropriata
La modalità a prestazioni elevate può essere utile in uno scenario di ripristino di emergenza in cui i server principale e mirror sono separati da una distanza significativa e in cui non si desidera che piccoli errori abbiano un impatto sul server principale.
[!NOTA] La distribuzione dei log può fungere da integrazione al mirroring del database e offre un'alternativa utile al mirroring asincrono. Per informazioni sui vantaggi della distribuzione dei log, vedere Configurazione della modalità a disponibilità elevata. Per informazioni sull'utilizzo della distribuzione dei log con il mirroring del database, vedere Mirroring del database e distribuzione dei log.
Impatto di un server di controllo del mirroring in modalità a prestazioni elevate
Se si utilizza Transact-SQL per configurare la modalità a prestazioni elevate, quando la proprietà SAFETY è impostata su OFF è consigliabile impostare su OFF anche la proprietà WITNESS. Un server di controllo del mirroring può coesistere con la modalità a prestazioni elevate, ma non offre vantaggi e introduce un rischio.
Se il server di controllo del mirroring viene disconnesso dalla sessione quando uno dei partner si arresta, il database non sarà più disponibile. Questo funzionamento dipende dal fatto che, sebbene per la modalità a prestazioni elevate non sia necessario un server di controllo del mirroring, per la sessione è necessario un quorum costituito da due o più istanze del server. Se la sessione perde il quorum, non può rendere disponibile il database.
Quando in una sessione in modalità a prestazioni elevate è impostato un server di controllo del mirroring, l'applicazione del quorum comporta quanto segue:
- Se il server mirror viene perduto, il server principale deve essere connesso al server di controllo del mirroring. In caso contrario, il server principale porta il proprio database non in linea finché il server di controllo del mirroring o il server mirror non si unisce nuovamente alla sessione.
- Se il server principale viene perduto, per forzare il servizio sul server mirror è necessario che il server mirror sia connesso al server di controllo del mirroring.
[!NOTA] Per informazioni sui tipi di quorum, vedere Quorum: Impatto di un server di controllo del mirroring sulla disponibilità del database.
Risposta agli errori del server principale
Quando si verifica un errore nel server principale, il proprietario del database può scegliere tra le operazioni seguenti:
Rendere il database non disponibile fino a quando il server principale non torna a essere nuovamente disponibile.
Se il database principale e il relativo log delle transazioni sono intatti, questa scelta consente di mantenere tutte le transazioni di cui è stato eseguito il commit, a fronte di una riduzione della disponibilità.Interrompere la sessione di mirroring del database, aggiornare manualmente il database e quindi avviare una nuova sessione di mirroring del database.
Se il database principale viene perduto ma il server principale resta in esecuzione, tentare immediatamente di eseguire il backup della parte finale del log nel database principale. Se il backup della parte finale del log ha esito positivo, la rimozione del mirroring può rappresentare l'alternativa più efficace. Dopo avere rimosso il mirroring, è possibile ripristinare il log nel database mirror precedente per mantenere tutti i dati.[!NOTA] Se il backup della parte finale del log ha esito negativo e non è possibile attendere il recupero del server principale, valutare la possibilità di forzare il servizio, operazione che consente di mantenere lo stato della sessione.
Forzare il servizio (con possibile perdita dei dati) nel server mirror.
Il servizio forzato rappresenta esclusivamente un metodo di recupero di emergenza e deve essere utilizzato solo se necessario. È possibile forzare il servizio solo se il server principale non è attivo, la sessione è asincrona (la protezione delle transazioni è impostata su OFF) e non è attivo alcun server di controllo del mirroring (la proprietà WITNESS è impostata su OFF), oppure il server di controllo del mirroring è connesso al server mirror (ovvero è disponibile il quorum).
Forzando il servizio si consente al server mirror di assumere il ruolo di server principale e di rendere disponibile la propria copia del database ai client. Quando il servizio viene forzato, tutti i log delle transazioni non ancora inviati dal server principale al server mirror vengono perduti. È pertanto consigliabile limitare il servizio forzato alle situazioni in cui la perdita dei dati rappresenta un'opzione accettabile e la disponibilità immediata del database è un fattore critico. Per informazioni sul funzionamento di un servizio forzato e sulle procedure consigliate per il relativo utilizzo, vedere Servizio forzato (con possibile perdita di dati).
Vedere anche
Concetti
Servizio forzato (con possibile perdita di dati)
Mirroring sincrono del database (modalità a sicurezza elevata)
Impostazioni di Transact-SQL e modalità operative del mirroring del database
Informazioni sulla distribuzione dei log