Nel mondo ideale un server deve essere in grado di erogare un servizio in maniera continuativa a partire dal momento in cui termina l'installazione fino a quando viene sostituito con un altro sistema più efficiente per prestazioni o funzionalità.

Il mondo reale è invece fatto di mille barriere che ostacolano, o comunque rappresentano una minaccia, alla continuità del servizio. La rottura di un disco o di un componente HW piuttosto che un problema di tipo software a livello di driver, di sistema operativo o di applicazione sono eventi tutt'altro che improbabili e richiedono la messa in opera di una serie di misure atte a prevenire o almeno mitigare questi fattori di rischio. Oltre a ciò devono aggiungersi quelle cause di downtime dovute alle attività amministrative che, sebbene possano essere controllate ed eseguite per arrecare i minori disagi possibili all'utenza, contribuiscono anch'esse a ridurre i tempi di disponibilità di un servizio.

La soluzione per eccellenza in grado di fornire high availability è il clustering che tuttavia, a prescindere dalla presenza di dischi in RAID, non è in grado di assicurare alcuna forma di protezione da eventuali danni allo storage. Potrebbe essere quindi consigliabile implementare soluzioni in grado di duplicare i dati e porsi così al riparo anche da problemi a carico del supporto di memorizzazione.

Già con le versioni precedenti di SQL Server era possibile ricorrere a funzionalità quali la replica dei dati ed il log shipping in grado di far fronte ad un danneggiamento di un database; a queste soluzioni si va ora ad aggiungere il database mirroring.

La tabella che segue sintetizza le principali caratteristiche delle diverse tecnologie in grado di offrire fault tolerance.

   (1) In FULL SAFETY mode
   (2) In presenza di WITNESS
   (3) Utilizzando le funzionalità di SNAPSHOT
   (4) Accessibilità intermittente in funzione delle attività di ripristino

Come lavora il database mirroring

Il database mirroring (che è possibile implementare con le versioni Standard, Enterprise o Developer di SQL Server 2005) permette di mantenere allineata una copia del database su una istanza indipendente e, in caso di danno al server primario, un meccanismo automatico o manuale promuove il server secondario. Dal lato client, utilizzando una connection string simile:

"Data Source = ServerA; Failover Partner = ServerB; Initial Catalog = MyDatabase; Integrated Security = TRUE;"

la componente di accesso ai dati (ADO.NET o SQL Native Client) ha cognizione della presenza di un partner di mirror.

Il failover partner è utilizzato dal client come se una procedura di error handling dirottasse la connessione verso il ServerB qualora il server principale non fosse disponibile. Una volta eseguita la connessione, il riferimento al server secondario viene posto in cache e, nel caso si verifichi un problema, non appena l'applicazione cerca di riconnettersi al database, il driver rileva il failover e redireziona la connessione stessa verso il server di mirror.

In uno scenario di mirror l'allineamento dei database può avvenire in modalità sincrona o asincrona e l'illustrazione seguente schematizza il flusso dei dati nei due casi.

Nello scenario di sinistra (high availability mode o high protection mode a seconda della presenza o meno del Witness), le modifiche inviate dal client vengono scritte nel database primario, (o, per meglio dire, nel t-log dello stesso) e il server invia contestualmente la richiesta di modifica al server partner; solo quando anche il secondo server da conferma dell'avvenuta modifica viene notificato al client il termine della transazione. Nello scenario di destra (high performance mode, non implementabile con la versione Standard di SQL Server 2005), la conferma al client viene invece data non appena sono stati scritti i dati nel database principale e ciò introduce un seppur breve lasso di tempo in cui i database non sono allineati.

Al fine di rendere automatico il failover tra i database (high availability mode) dobbiamo introdurre nello scenario una terza istanza di SQL Server (Witness) che funge da arbitro nel rilevamento del failure. Questo ruolo può essere svolto da una istanza di qualunque edizione di SQL Server, quindi anche SQL Server Express o Workgroup che peraltro non possono essere configurate come partner di mirror. Il carico di lavoro sostenuto dal Witness può essere considerato trascurabile ed una medesima istanza può assumere il ruolo di Witness per più coppie di mirror.