Sessioni di mirroring del database
Il mirroring del database si verifica nel contesto di una sessione di mirroring del database. In questo argomento si parte dal presupposto che l'utente conosca i ruoli di server principale, mirror e di controllo nel mirroring del database e la procedura di cambio di ruolo nel mirroring del database. Per ulteriori informazioni, vedere Panoramica del mirroring del database.
Quando il database mirror è pronto e le istanze del server sono configurate, il proprietario del database può iniziare il mirroring del database. Quando il mirroring ha inizio, ogni partner inizia a gestire le informazioni sullo stato nel proprio database relativamente al database stesso, all'altro partner e al server di controllo del mirroring, se presente. Queste informazioni sullo stato consentono alle istanze del server di gestire una relazione denominata sessione di mirroring del database. Nel corso della sessione di mirroring del database le istanze del server eseguono il monitoraggio reciproco. Le informazioni sullo stato vengono gestite fino all'interruzione della sessione da parte del proprietario del database. Per ulteriori informazioni, vedere Stati di mirroring e Monitoraggio del mirroring del database.
All'avvio di una sessione di mirroring del database, il server mirror identifica il numero di sequenza del file di log (LSN) dell'ultimo log delle transazioni applicato al database mirror e richiede al server principale il log delle transazioni per tutte le eventuali transazioni successive. In risposta, il server principale invia al server mirror i record di log attivi accumulati dall'ultimo log ripristinato nel database mirror o inviato al server mirror. Il log non inviato che si è accumulato nel disco del log del database principale è definito coda di invio.
Il server mirror scrive immediatamente il log in arrivo sul disco, dove viene mantenuto fino a quando viene applicato al database mirror. Il log in attesa nel disco del server mirror è definito coda di rollforward. La quantità di log non ripristinato in attesa nella coda di rollforward è indicativo del tempo necessario per eseguire il failover del database mirror. Per ulteriori informazioni, vedere Stima dell'interruzione del servizio durante il cambio di ruolo.
A questo punto, il server principale rende il database principale disponibile ai client e alle relative connessioni. Dopo l'inizio del mirroring, ogni volta che un client aggiorna il database principale, quando il server principale scrive nel log del database principale, invia anche il log delle transazioni risultante al server mirror, dove viene immediatamente salvato sul disco quale ultimo record della coda di rollforward.
In background, il server mirror inizia a eseguire il rollforward del log nel database mirror il più rapidamente possibile e a partire dal record meno recente. Per questo scopo è necessario applicare i record del log accodato al database mirror in sequenza, iniziando dal record meno recente. Il rollforward di ogni record del log viene eseguito una sola volta. Durante il rollforward del log, viene parallelamente eseguito il rollforward anche del database mirror. Quando il server principale tronca o compatta il log per il database principale, anche il server mirror compatta il log nel medesimo punto all'interno del flusso di log.
In genere, durante il rollforward il database mirror viene rapidamente aggiornato in base al database principale. L'aggiornamento completo del database mirror rispetto al database principale dipende dalla modalità operativa della sessione. In modalità sincrona a sicurezza elevata, prima di confermare le nuove transazioni il server principale attende che vengano scritte sul disco del log del server mirror. Dopo l'invio dei record di log accumulati al server mirror, il database mirror diventa sincronizzato con il database principale.
Durante una sessione, se il server principale non è in grado di inviare tutti i record di log immediatamente, i record di log non inviati si accumulano nella coda di invio. In modalità sincrona a sicurezza elevata, dopo la sincronizzazione i nuovi log non inviati si accumulano solo quando il mirroring è sospeso. In modalità asincrona a protezione elevata, invece, i log non inviati si accumulano ogni volta che il server mirror non riesce a far fronte al carico di lavoro durante il mirroring, nonché quando il mirroring è sospeso. La quantità di log non inviato è un indicatore della possibile perdita di dati in caso di errore del server principale.
[!NOTA]
Se il rollforward non riesce, il server mirror sospende la sessione impostando lo stato SUSPENDED per il database. È necessario che il proprietario del database risolva il problema prima di riprendere la sessione.
Sessioni simultanee
Una determinata istanza del server può prendere parte a più sessioni di mirroring del database simultanee (una volta per ogni database con mirroring) con la stessa istanza o istanze diverse del server. Spesso, un'istanza del server funge esclusivamente da server partner o da server di controllo del mirroring in tutte le relative sessioni di mirroring del database. Poiché tuttavia ogni sessione è indipendente dalle altre, un'istanza del server può fungere da server partner in alcune sessioni e da server di controllo del mirroring in altre. Si considerino ad esempio le quattro sessioni seguenti tra tre istanze del server (SSInstance_1, SSInstance_2 e SSInstance_3). Ogni istanza del server funge da partner in alcune sessioni e da server di controllo del mirroring in altre:
Istanza del server |
Sessione per il database A |
Sessione per il database B |
Sessione per il database C |
Sessione per il database D |
|---|---|---|---|---|
SSInstance_1 |
Server di controllo |
Partner |
Partner |
Partner |
SSInstance_2 |
Partner |
Server di controllo |
Partner |
Partner |
SSInstance_3 |
Partner |
Partner |
Server di controllo |
Server di controllo |
Nella figura seguente vengono illustrate due istanze del server che partecipano come partner a due sessioni di mirroring. Una sessione è relativa al database denominato Db_1, l'altra al database denominato Db_2.
.gif "Due istanze del server in due sessioni simultanee")
Ogni database è indipendente dagli altri. Ad esempio, un'istanza del server inizialmente può rappresentare il server mirror per due database. Se uno dei database esegue il failover, l'istanza del server diventa il server principale per il database con failover, rimanendo contemporaneamente il server mirror per l'altro database.
Sempre a titolo di esempio, si consideri un'istanza del server che rappresenta il server principale per due o più database in esecuzione in modalità a sicurezza elevata con failover automatico. In caso di errore dell'istanza del server, tutti i database eseguiranno automaticamente il failover ai rispettivi database mirror.
Quando si imposta un'istanza del server perché operi sia come partner che come server di controllo, assicurarsi che l'endpoint del mirroring del database supporti entrambi i ruoli (per ulteriori informazioni, vedere Endpoint del mirroring del database). Assicurarsi inoltre che il sistema disponga di risorse sufficienti per ridurre la contesa tra risorse.
[!NOTA]
I database con mirroring sono indipendenti tra loro, quindi non possono eseguire il failover come gruppo.
Thread creati per una sessione di mirroring del database
I tipi di thread creati da un'istanza del server per una sessione del mirroring del database dipendono in parte dai ruoli di mirroring che l'istanza del server sta eseguendo. Una sessione specifica dispone di alcuni o tutti i thread seguenti:
Un thread globale per le comunicazioni relative al mirroring del database. Questo thread viene avviato da Service Broker.
Se l'istanza del server viene utilizzata come partner di mirroring, ovvero se è costituita dal server principale o da quello mirror):
Un thread per database con mirroring per l'elaborazione dell'evento.
Un thread per database con mirroring per attività asincrone (ad esempio l'invio o la scrittura del log) che in caso contrario bloccherebbero il thread dell'evento.
Ogni qualvolta l'istanza viene utilizzata come un server mirror:
Un thread di gestione di rollforward, che invia log per il rollforward, esegue la lettura read-ahead delle pagine e la riacquisizione del blocco e così via.
In SQL Server Standard, un thread di rollforward per database mirror oppure, in SQL Server Enterprise, un thread di rollforward per database mirror per ogni quattro CPU. Questi thread eseguono il rollfoward del log effettivo.
Se l'istanza viene utilizzata come server di controllo del mirroring:
- Un thread globale per l'elaborazione dei messaggi del server di controllo del mirroring per tutte le sessioni di mirroring nelle quali l'istanza viene utilizzata come server di controllo.
Prerequisiti per una sessione di mirroring del database
Prima di iniziare una sessione di mirroring, è necessario che il proprietario del database oppure l'amministratore di sistema crei il database mirror, imposti gli endpoint e gli account di accesso e, in alcuni casi, crei e imposti i certificati. Per ulteriori informazioni, vedere Impostazione del mirroring del database.
La creazione di un database mirror richiede l'esecuzione di un backup completo del database principale e di un backup del log successivo. Entrambi i backup devono quindi essere ripristinati sull'istanza del server mirror tramite WITH NORECOVERY. Inoltre, prima di avviare il mirroring, se sono stati eseguiti backup aggiuntivi del log dopo quello richiesto, è necessario applicare manualmente ogni backup del log aggiuntivo (sempre tramite WITH NORECOVERY). Dopo aver applicato l'ultimo backup del log, è possibile avviare il mirroring. Per ulteriori informazioni, vedere Preparazione di un database di mirror per il mirroring.
Effetti della sospensione di una sessione sul log delle transazioni principale
Il proprietario del database può sospendere una sessione in qualsiasi momento e, in questo modo, preservare lo stato della sessione mentre si rimuove il mirroring. Quando una sessione viene sospesa, il server principale non invia nuovi record del log al server mirror. Tali record restano attivi e si accumulano nel log delle transazioni del database principale. Inoltre, finché la sessione di mirroring del database rimane sospesa, non è possibile troncare il log delle transazioni. Se la sessione di mirroring del database resta sospesa troppo a lungo, dunque, lo spazio del log può esaurirsi.
Per ulteriori informazioni, vedere Sospensione e ripresa del mirroring del database.
Connessioni client
Le connessioni client per le sessioni di mirroring del database sono supportate da Microsoft .NET Data Provider per SQL Server. Per ulteriori informazioni, vedere Connessione di client a un database con mirroring.
Vedere anche