Da Luca Bianchi,
Il log shipping è una caratteristica presente nelle versioni Enterprise e Developer di SQL Server 2000; la sua implementazione consente non solo una rapida ripresa del servizio a seguito di un failure del database server ma può anche contribuire a ridurre il carico di lavoro di un server principale e/o il traffico di rete tra la sede centrale dell'azienda e quelle periferiche. Sebbene tale funzionalità sia implementata in maniera nativa solo nelle versioni citate, è possibile sfruttarne il principio di funzionamento per renderla disponibile sia nelle altre edizioni di SQL Server 2000 che nelle versioni precedenti. Il log shipping realizza l'allineamento di un database su un server primario con uno o più server secondari attraverso la distribuzione periodica e automatica del backup del t-log dal server di produzione verso uno o più stand-by server. Questi ultimi possono essere utilizzati come server di sola lettura e in caso di necessità uno dei server secondari può essere promosso per sostituire il database server divenuto non disponibile. L'illustrazione che segue mostra la schematizzazione dell'architettura di uno scenario di Log Shipping.
.jpg)
Le versioni Enterprise e Developer (quest'ultima compatibilmente alle restrizioni dettate dalla sua destinazione d'uso) permettono di utilizzare il wizard per la creazione del piano di manutenzione per la generazione della coppia di distribuzione; le attività create in maniera automatica dal wizard, con riferimento al log shipping, consistono in:
-
Eseguire il full backup del database primario ed il restore su server secondario per l'allineamento iniziale
-
Creare sul server primario i job per il backup del t-log su una risorsa condivisa e sul server secondario quelli per la copia e il ripristino
-
Indicare quali dei server secondari possono diventare primary
-
Specificare un monitor server
Designare un monitor server è del tutto opzionale ma la sua presenza può essere di aiuto per le attività di troubleshooting; non è necessario che questo ruolo sia svolto da un server dedicato ma tale compito può essere delegato ad uno dei server secondari. In caso di failure del primary server, per promuovere uno dei server secondari, si devono compiere alcune semplici operazioni:
-
Backup del t-log sul server principale (se disponibile il log file) al fine di ridurre al minimo la perdita di dati
-
Restore su stand-by server del/dei t-log non ancora ripristinati (dovuti al tempo di latenza pianificato) specificando l'opzione WITH RECOVERY in occasione dell'ultimo restore
-
Allineare i login (http://support.microsoft.com/default.aspx?scid=kb;en-us;246133)
-
Interrompere il processo di log shipping (sp_change_primary_role, sp_change_secondary_role, sp_change_monitor_role, sp_resolve_logins)
Poichè i tempi necessari ad eseguire le suddette operazioni sono relativamente brevi, appare evidente come sia possibile, in pochi minuti, rendere nuovamente disponibile un database.
Il Resource Kit di SQL Server 2000 mette a disposizione una utility (Simple Log Shipper) che può essere utilizzata con tutte le versioni di SQL Server 2000. Tale utility si compone di 2 stored procedure: sp_ShipLog e sp_ApplyStandByLog che vanno installate rispettivamente nei database master del server primario e di quello secondario. Il Simple Log Shipper presenta alcune limitazioni rispetto al tool nativo fornito con le versioni Enterprise e Developer tra cui l'impossibilità di eseguire l'allineamento iniziale per mezzo di un backup completo (che va eseguito manualmente) e la indisponibilità di un monitor server. In compenso l'utilizzo di questo tool è particolarmente indicato per quegli ambienti in cui è richiesta una elevata semplicità di utilizzo. Con il Simple Log Shipper tutte le attività vengono gestite dal server primario e l'unico comando da impostare è l'esecuzione dell'istruzione sp_ShipLog.
Dopo aver registrato il server di destinazione come linked server ed eseguito il ripristino del backup completo, per avviare la distribuzione del log è possibile impartire il seguente comando
EXEC sp_ShipLog
@DBName = 'MyDatabase',
@StandbyServer = 'TargetServer',
@BackupLocationPath = '\\TargetServer\Log',
@UndoFile = 'D:\MyDatabase_undo.dat',
@MinuteInterval = 30,
@HourDuration = 12
I parametri indicati sono alquanto esplicativi ed è possibile schedulare l'istruzione di cui sopra affinché venga eseguita, ad esempio, tutti i giorni alle ore 08:00. Così facendo il processo di backup/ripristino del t-log verrà avviato ogni 30 minuti fino alle ore 20:00 fornendo la copertura da eventuali crash del primary server per tutto l'orario lavorativo.
Entrambe le stored procedure fornite con il Resource Kit sono esposte in chiaro ed è quindi possibile modificare il codice T-SQL per adattarlo e calibrarlo sulle proprie specifiche esigenze ad esempio per inviare una mail di notifica ad allineamento avvenuto oppure in caso di problemi.
Qualunque sia la soluzione adottata, per consentire la continuità di utilizzo del database server da parte degli utenti e delle applicazioni di accesso ai dati, può essere impostato un alias (CNAME) nel DNS aziendale da usare nelle stringhe di connessione. In caso di promozione di uno stand-by server sarà sufficiente modificare l'indirizzo IP dell'alias per farlo puntare al nuovo primary server senza dover apportare alcuna modifica alle applicazioni che accedono al database.
Con l'implementazione di una soluzione basata sul log shipping si sarà in grado di mantenere allineati uno o più server secondari con un tempo di latenza legato alla frequenza di backup del t-log e quindi di:
-
Ridurre i tempi di ripristino a seguito di failure
-
Distribuire il carico di lavoro del primary server utilizzando uno o più stand-by server per soddisfare le query che non richiedono dati real-time (ad esempio attività di reportistica o DSS - Decision Support System)
-
Contribuire a ridurre il traffico wan se i server sono in siti remoti
-
Propagare ai server secondari anche modifiche alla struttura di una tabella
E' possibile trovare ulteriori informazioni su come implementare uno scenario basato sul log shipping ai link