Come è possibile vedere dallo script, sono state utilizzate porte TCP diverse per ciascuna delle istanze di SQL Server; ciò si rende necessario in quanto, come detto, le tre istanze risiedono sulla medesima macchina. Qualora venissero utilizzate tre istanze su altrettanti server, come del resto consigliabile per una implementazione in uno scenario di produzione, sarebbe possibile utilizzare la stessa porta.

Qualora le istanze coinvolte utilizzassero account di servizio differenti, ciascuno di questi account dovrebbe essere aggiunto tra i login delle istanze partner e sugli endpoints dovremmo consentire loro il permesso di connessione; il relativo codice sarebbe il seguente:

Una volta definiti i canali di comunicazione tra le istanze occorre istruire ciascun database per renderlo edotto di quali sono i propri interlocutori.

E' fondamentale l'ordine di esecuzione di tali comandi ed alcune fonti, basate su build precedenti alla 9.0.1187 (anche nota come IDW15 o June CTP), riportano indicazioni opposte a riguardo. Il primo database che deve essere informato di quale sia il partner è il Mirror e solo dopo può essere indicata al Principal la destinazione degli aggiornamenti e l'eventuale presenza del Witness.

Con il comando:

impartito dall'istanza che svolge il ruolo di Principal, viene impostata la modalità sincrona di allineamento dei database. Questa modalità di aggiornamento e la presenza del Witness rendono questo scenario del tipo high availability mode.

Come è possibile vedere nell'illustrazione che segue, le medesime impostazioni possono essere eseguite in maniera grafica accedendo alle proprietà del database attraverso SSMS.

Giunti a questo punto il Mirror tra i due database è operativo e qualunque modifica apportata ai dati del Principal viene immediatamente propagata anche al database Mirror. Il Mirror non è accessibile neanche in modalità read-only come invece può avvenire in uno scenario di log shipping a meno che non venga creata una snapshot del database (altra nuova feature di SQL Server 2005), il che rende possibile l'utilizzo del Mirror come database in sola lettura per tutte quelle attività che non necessitano di dati real-time (ad esempio, per le attività di reportistica), contribuendo sia ad alleggerire il carico di lavoro del database Principal che ad aumentare la scalabilità del sistema.

Per conoscere in ogni momento lo stato ed il ruolo dei database è possibile accedere alle viste di catalogo sys.database_mirroring (dal Mirror o dal Principal) o sys.database_mirroring_witnesses (dal Witness). Attraverso l'interfaccia grafica di SSMS, come mostrato nella figura che segue, possiamo vedere nel riquadro Object Explorer (ed anche nel riepilogo di destra) che nell'istanza SQL2K5\Rome il database MyDB svolge il ruolo di Principal e che i DB sono sincronizzati tra loro. Poco più sotto, in SQL2K5\Dallas, sono riportate le informazioni relative al database che ricopre il ruolo di Mirror.

A questo punto eseguiamo alcune attività sui dati, le prime che vengono eseguite dopo l'impostazione del mirroring, per simulare le attività degli utenti.

Facendo refresh nella finestra Object Explorer in SSMS, ovvero utilizzando le viste di catalogo citate in precedenza, possiamo verificare che i database continuano ad essere sincronizzati fra loro. Per poter fare affidamento su una feature in grado di fornire fault tolerance dobbiamo perlomeno testarla in situazioni critiche.

Attenzione: Questo articolo contiene un allegato

Contenuti dell'articolo

• Pagina 1
  • Come lavora il database mirroring
• Pagina 2
  • Implementazione del mirroring
• Pagina 4
  • Login Standard e utenti orfani
  • Conclusioni