Visto che mi è stata chiesta una panoramica su quanto detto nella Track DBA di SQL Server, iniziamo dal Database Mirroring della parte di Avaliability.
Ovviamente sono assolutamente ben graditi ed esortati, commenti/precisazioni su quanto esposto.

Cos'è il Database Mirroring?
Il Database Mirroring è una funzionalità di SQL 2005 che consente di dare all'utente finale la massima sensazione di Disponibilità del Data Server. Nel caso di "caduta" del Servizio SQL su un Server (Principal), subentra quasi istantaneamente un altro Server (Mirror) che prende il posto del Principal. Il tempo di switch fra i 2 Server è inferiore ai 3 secondi (nel migliore dei casi), che è addirittura meno rispetto ad un Cluster Attivo/passivo i cui tempi di switch sono dell'ordine dei 20 secondi + il tempo di allineamento di TUTTI i Database presenti sull'Istanza SQL. Questo perchè con il Mirroring viene allineato un solo Database.
Per ovvi motivi, i 2 Data Server devono essere il più possibile uguali in termini di performances, perchè in caso di Switch l'utente non deve accorgersi di cambiamenti di prestazioni.

Attori nel Database Mirroring: DataServer 1 (Principal), DataServer 2 (Mirror), Server 3 (Witness).

Del Principal e del Mirror abbiamo già detto. Il Witness è un terzo Server, che deve avere al minimo un'istanza di quello che si chiamerà SQL Express (l'attuale MSDE).
E' il Witness che "sente" la caduta del Servizio SQL sul Principal (DataServer 1) ed elegge il Mirror(DataServer 2) a Principal.
Quando il DataServer 1 sarà nuovamente disponibile diventerà Mirror a meno che il DBA lo forzi a ritornare Principal, riportando il DataServer 2 al suo ruolo di Mirror.

Il Mirrror potrà essere di 2 tipi: Sincrono (solo con la Versione SQL SERVER 2005 Enterprise) che Asincrono (altre versioni meno complete: Workgroup e Standard).

Il Mirror Sincrono consente di avere la certezza che alla fine di una transazione, il DB sul Principal e il DB sul Mirror siano perfettamente allineati. Per garantire questo, i passi sono:
1. Begin Transaction.
2. Scrittura sul DB_data_1 e sul Log_1;
3. Passaggio delle "modifiche" al Mirror;
4. Scrittura sul DB_data_2 e sul Log_2;
5. Segnalazione al Principal che i 2 DB sono allineati;
6. Commit Transaction;

Il Mirror Asincrono invece chiude la transazione senza avere un ritorno dal Mirror. Pertanto
1. Begin Transaction.
2. Scrittura sul DB_data_1 e sul Log_1;
3. Passaggio delle "modifiche" al Mirror;
4. Commit Transaction;

Come capirete, non essendoci la garanzia dell'Allineamento del DB_data_2 e del Log_2, qualora il Principal vada offline, il DBA dovrà fare del lavoro aggiuntivo per avere la certezza, quando il Mirror verrà eletto a Principal, che i DB siano perfettamente allineati.
Dovrà fare il backup del Log_1 a farne la restore sul Data Server 2.

In tutto questo, a parte un errore di caduta della connessione al Data Server 1, l'utente non avvertirà la sensazione di avere cambiato Server.

La gestione, a livello di connessione Clent, è gestira da MDAC, che alla connessione riceve le informazioni dei 2 Data Server, e quando il Data Server 1 (Principal) andrà offline, alla successiva connessione del client, andrà ad indirizzare la connessione al Data Server 2 diventato Principal grazie al Witness.

Questo a grandi linee, e fidatevi.... Funziona e anche bene.