Sessioni di mirroring del database

Data aggiornamento: 14 aprile 2006

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:

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.

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.

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 del server 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

Concetti

Mirroring asincrono del database (modalità a prestazioni elevate)
Stati di mirroring
Panoramica del mirroring del database
Quorum: Impatto di un server di controllo del mirroring sulla disponibilità del database
Mirroring sincrono del database (modalità a sicurezza elevata)

Altre risorse

Monitoraggio del mirroring del database
Impostazione del mirroring del database

Guida in linea e informazioni

Assistenza su SQL Server 2005

Cronologia modifiche