SQL Server

Disponibilità elevata per SQL Server

Zach Nichter

Panoramica:

• Mirroring
• Snapshot di database
• Distribuzione dei log
• Clustering
• Replica

Scarica il codice per questo articolo: NichterHA2007_03.exe (151KB)

Tutti gli amministratori del database dovrebbero essere a conoscenza del concetto di disponibilità elevata. Tale concetto si rifersce alla capacità di risposta e all'accessibilità del sistema. Talvolta disponibilità elevata significa un tempo di risposta di qualche secondo, mentre altre situazioni richiedono tempi di risposta pari a

frazioni di secondo. In passato ho lavorato come consulente presso un'azienda dove i server Web richiedevano che le query SQL avessero tempi di risposta con sequenza di andata e ritorno di millisecondi. Se la risposta eccedeva tale limite, il sistema di database veniva considerato guasto e il server Web si riconnetteva al primo server di database disponibile.

Oggi gli utenti hanno bisogno di applicazioni sempre più veloci, pertanto sapere come ottenere una disponibilità elevata e tempi di risposta rapidi sarà molto utile per ottenere una pianificazione efficace delle applicazioni dipendenti da dati.

Fortunatamente SQL Server™ 2005 offre numerose opzioni per migliorare la disponibilità, fra cui la replica, il clustering, il mirroring del database, gli snapshot di database e la distribuzione dei log. Esamineremo queste funzionalità e cercheremo di scoprire come decidere quali siano le più appropriate all'ambiente in cui si lavora. Iniziamo con la Figura 1, in cui sono descritte le opzioni di disponibilità in SQL Server 2005.

Figure 1 Opzioni di disponibilità elevata

Definizione di disponibilità elevata

Uno dei primi obbiettivi quando si progetta un'applicazione di disponibilità elevata è definire che cosa ciò significhi in ogni ambiente specifico. Per alcune organizzazioni, disponibilità elevata significa che l'hardware ridondante deve essere pari all'hardware di produzione e sia i dati sia l'hardware devono offrire un tempo di attività e una disponibilità pari al 99,995 percento o superiore. Altre organizzazioni possono richiedere tale disponibilità elevata solo per i dati ed essere meno interessate alla prestazione del livello di produzione qualora fosse necessario un failover. Essere in grado di definire la disponibilità elevata è importante per determinare la corretta soluzione in ogni situazione.

Inoltre, è necessario identificare i tipi di interruzione di corrente che si possono verificare e indicare in che modo influiscano sui propri contratti di servizio. Le interruzioni di corrente che possono influire sulla disponibilità includono le prestazioni pianificate, non pianificate e a livello ridotto.

Un'interruzione di corrente pianificata è, di solito, una finestra di manutenzione pianificata, di cui gli utenti del sistema sono informati anticipatamente. Un'interruzione di corrente non pianificata è, di solito, il risultato di un'operazione hardware o software non riuscita che rende i dati inaccessibili. Anche un livello di prestazione ridotto può causare interruzioni di corrente e viene spesso misurato in tempo di risposta dell'utente finale. Quest'ultimo viene, di solito, concordato in anticipato dall'azienda o dall'organizzazione IT in alcuni tipi di contratti di servizio.

Oltre a identificare le cause potenziali delle interruzioni di corrente, è necessario determinare il livello di attività dei propri dati e stabilire se debbano sempre essere in linea o se talvolta possano essere su supporto rimovibile o non in linea. Bisogna decidere inoltre se l'opzione di disponibilità debba trovarsi nella stessa posizione geografica o in una posizione remota. Probabilmente anche le limitazioni di budget devono essere tenute presenti nel prendere questa decisione. E ora esaminiamo ogni singola opzione di disponibilità.

Mirroring del database

Prima di analizzare il mirroring del database, è opportuno definirne la terminologia.

Il server principale è il server di produzione primario contenente il database che invia continuamente i log delle transazioni al server e al database di mirroring.

Il server mirror è il server secondario che ospita la copia di backup del database. La copia mirror viene sempre sincronizzata con il database principale.

Il ruolo indica lo scopo di quel particolare server, se sia primario o di copia.

Il server di controllo del mirroring è l'istanza che monitora il server principale e il server mirror durante l'esecuzione delle loro attività e può iniziare un failover automatico.

Il server partner può essere sia il server principale sia il server mirror.

In un ambiente tipico, il database principale sarà sottoposto a backup sull'istanza principale e il backup sarà ripristinato sull'istanza di mirroring (vedere la Figura 2). Una volta ripristinato il database, bisogna impostare il mirroring sul server principale utilizzando la finestra delle proprietà del database principale in SQL Server Management Studio (SMS) oppure gli script T-SQL.

Figura 2** Architettura del mirroring del database **(Fare clic sull'immagine per ingrandirla)

Dopo che è stato configurato il mirroring e si è stabilita la sessione di mirroring, il database principale e il database mirror si sincronizzano. Il database principale invierà quindi il log delle transazioni degli eventi verificatisi dall'ultima applicazione del backup al database mirror. Il server mirror riceverà il log e tenterà di applicarlo il più rapidamente possibile. Se si utilizza SQL Server 2005 Enterprise Edition, questo processo è a thread multipli; altrimenti si tratterà di un'operazione a thread singolo. Non appena questi log vengono applicati al server mirror, i database sono considerati sincronizzati e rimarranno sincronizzati finché la sessione mirror non sarà interrotta.

Man mano che i client eseguono nuove transazioni, il server principale esegue le transazioni a fronte del database principale e invia i record dei log delle transazioni dal database principale al log di ripristino del database mirror, o code del log, dove vengono prelevati e applicati al database mirror. Una volta che la transazione è stata applicata e ne è stato eseguito il commit al database mirror, viene inviata una risposta al server principale, che annuncia che è stato eseguito il commit della transazione al server mirror. Il server principale non confermerà alcuna nuova transazione che potrebbe arrivare al sistema finché non sia stata ricevuta la conferma dal server mirror.

In caso di errore, il mirror può iniziare una procedura di errore automatica e il server di controllo del mirroring supporta il processo determinando se il database principale sia disponibile o meno. In caso di errore, il problema sul server che adesso è diventato il partner di mirroring deve essere risolto prima che possa diventare nuovamente il partner primario. Dopo che sono stati risolti i problemi sul server mirror partner, viene iniziato lo spostamento sul server mirror partner e i database vengono nuovamente sincronizzati. Una volta sincronizzati, la sessione di mirroring può ricominciare.

Questa particolare modalità di mirroring è una modalità di alta protezione che fornisce operazioni per transazioni sincrone attivando la protezione delle transazioni, ma non richiede un server di controllo del mirroring perché non utilizza il failover automatico, in quanto tutti i failover sono inziati manualmente. Esiste un altro tipo di modalità di mirroring che fornisce disponibilità elevata alle operazioni di transazioni sincrone. Non solo richiede l'attivazione della protezione delle transazioni, ma anche l'utilizzo di un server di controllo del mirroring per il failover automatico in caso di errore.

La terza e ultima modalità di mirroring disponibile è la prestazione elevata. Richiede che la protezione delle transazioni sia disattivata per consentire il supporto asincrono delle operazioni che, a sua volta, permette di eseguire il commit delle transazioni sul partner principale senza dover aspettare la scrittura del record della transazione sul server mirror. La modalità a prestazione elevata non richiede un server di controllo del mirroring nella configurazione.

Notare che il mirroring richiede la stessa edizione di SQL Server sul server primario e sul mirror ma non sul server di controllo del mirroring, che può essere l'edizione SQL Server Express. Inoltre è importante che il database principale sia in modalità di ripristino completa.

ADO.NET 2.0 è integrato con SQL Server 2005: supporta il mirroring del database e fornisce un failover trasparente per l'applicazione sull'ambiente di mirroring. Questo offre all'applicazione ADO.NET la funzionalità di failover automatico senza alcuna codificazione o configurazione aggiuntiva qualora non sia possibile stabilire una connessione con il database principale. La configurazione è facile, basta specificare un utente comune tra i due ambienti e il partner di failover nella stringa di connessione. Segue un esempio di una stringa di connessione ADO.NET con l'identificazione del partner di failover per l'ambiente di database mirror:

"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
 Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"

Il mirroring del database può essere la scelta adatta per un'azienda, in base ai requisti delle sue applicazioni e dei suoi dati, tuttavia, è necessario considerare altri punti per poter ottenere un'ottima prestazione. Ad esempio, qual è la frequenza delle transazioni del sistema o il volume della modifica dati? Quando si considera il mirroring del database, è essenziale determinare se la velocità della larghezza di banda e della rete siano sufficienti per gestire il volume dei dati e la velocità di elaborazione delle transazioni. Bisogna inoltre considerare la saturazione del collegamento. Ciò è importante soprattutto se il server mirror si trova in una posizione geografica diversa. Il controllo anticipato del sistema è cruciale nel determinare se esistano limitazioni ambientali che possano impedire un funzionamento efficiente del mirroring.

Il mirroring del database può essere un'opzione particolarmente adatta se si desidera mantenere bassi i costi. Infatti, l'architettura del mirroring del database non richiede la condivisione dei dischi e nessuna abilità avanzata o specializzata per eseguire l'ambiente. E, a differenza del clustering, il mirroring del database non richiede che i due partner dispongano dello stesso hardware. Inoltre, è semplice implementare il mirroring utilizzando la procedura di installazione guidata presente sulla scheda di mirroring nella finestra delle proprietà del database (vedere la Figura 3). Consiglio oltretutto di leggere il white paper "Database Mirroring Best Practices and Performance Considerations" (in inglese) all'indirizzo go.microsoft.com/fwlink/?LinkId=80897 per ulteriori utili informazioni.

Figura 3** Installazione guidata del mirroring **(Fare clic sull'immagine per ingrandirla)

Snapshot di database

Gli snapshot di database sono una nuova tecnologia offerta in SQL Server 2005 Enterprise Edition, ma non sono considerati un'opzione a disponibilità elevata. Gli snapshot di database svolgono la funzione di opzione di ripristino o di possibile reporting quando sono utilizzati con altre tecnologie. Uno snapshot è semplicemente la visualizzazione in sola lettura di un database in un particolare momento.

Lo snapshot viene creato utilizzando il comando CREATE DATABASE nel modo seguente:

CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME = 
    'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO

quando viene creato, lo snapshot del database utilizza uno o più file chiamati file sparse, come farebbe un database tipico. Questi file sparse sono essenzialmente luoghi virtuali di transito che inizialmente non utilizzano dati. Sono utilizzati per contenere dati solo se questi vengono modificati o cancellati nel database di origine. I dati sono scritti nei file sparse una pagina alla volta e lo snapshot del database visualizza soltanto i dati che sono stati modificati al momento della cattura dello snapshot stesso. Il resto dei dati proviene dalle pagine di dati del database di origine.

I file snapshot di database sono allocati alla dimensione del database quando lo snapshot è stato catturato. La dimensione allocata non indica l'entità dei dati effettivamente contenuta. Per ottenere tale informazione, bisogna eseguire un'istruzione T-SQL come la seguente:

SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
    2030'), 1);
GO

I dati sono memorizzati nei file sparse e nel database di origine in modo tale che quando si accede a uno snapshot di database, le pagine di dati nei file dati del database originali e le pagine dei dati nei file sparse dello snapshot vengono recuperati. Gli snapshot possono esistere soltanto sul server con il database di origine dello snapshot, a causa della necessità di condividere le pagine di dati. Poiché questa architettura non risolve le operazioni di I/O sul database di origine, gli snapshot non sono un'opzione di reporting valida in quanto non rappresentano lo stato reale del database.

Consideriamo uno scenario in cui il mirroring del database sia utilizzato insieme agli snapshot. Ciò consente ai dati di reporting, al mirroring e agli snapshot di database di essere fisicamente separati dal database principale. Lo snapshot di database viene pianificato utilizzando SQL Server Agent e uno script personalizzato per fornire nuovi snapshot ad intervalli regolari. Lo script di esempio nella Figura 4 mostra la stored procedure utilizzata per realizzare questa attività. È progettato per essere utilizzato all'interno di un processo per gestire la creazione e l'eliminazione di snapshot per un database particolare nell'ambiente dell'utente. Ciò consente una soluzione di reporting accettabile in quanto i dati di reporting sarebbero isolati dai dati di produzione.

Figure 4 Stored procedure per la pianificazione degli snapshot

use msdb;
GO
set nocount on
GO

CREATE PROCEDURE usp_snaprefresh 
     @database    sysname = NULL    --name of the database to snapshot
    ,@keepsnap    int        = 24   --# of hours to keep a snapshot 
                                    --after it was created 
                                    --use a value of '0' to keep all
                                    --existing snapshots
    ,@fileloc    sysname            --location for snapshot
        = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'    
AS

DECLARE 
     @dt            datetime        ,@cnt          int
    ,@databaseid    int             ,@snap         sysname
    ,@sql           nvarchar(1000)  ,@yy           varchar(4)
    ,@mm            varchar(2)      ,@dd           varchar(2)
    ,@h             varchar(2)      ,@m            varchar(2)
    ,@lname         sysname         ,@pname        sysname
    ,@file          sysname         ,@pos1         int
    ,@pos2          int

-- initialize variables
SELECT 
     @dt = getdate()
    ,@cnt = 0, @pos1 = 0, @pos2 = 0
    ,@databaseid = db_id(@database)

-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
    RAISERROR ('Missing database name. Rerun the procedure specifying a
       valid database name.',16,1)
    RETURN (0) 
END

--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
    -- determine if other snapshots exist for this server older than @
    -- keepsnap value hrs
    SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum], 
        name INTO #t1 
    FROM master.sys.databases 
    WHERE source_database_id = @databaseid
        AND create_date < dateadd(hh,-(@keepsnap),getdate())

    IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
    BEGIN
        WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
        BEGIN
            SELECT @snap = name FROM #t1 WHERE RowNum = @cnt

            PRINT 'Dropping snapshot ''' + @snap + ''''

            SET @sql = 'DROP DATABASE ' + @snap

            EXEC(@sql)
            SELECT @cnt = @cnt + 1
        END
    END
END

-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
   month(@dt))
    ,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
         datepart(hh,@dt)) 
    ,@m = convert(varchar(2), datepart(mi,@dt))

-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m

-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files 
WHERE file_id = 1'

EXEC(@sql)

--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1

-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
    SET @fileloc = @fileloc + '\'
END

-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database

EXEC(@sql)

-- cleanup
DROP TABLE tempdb..t1;
GO

Bisogna ricordare tuttavia che gli snapshot di database sono considerati temporanei in quanto non possono essere sottoposti a backup e non possono esistere senza il database di origine. Se un file sparse rimane senza spazio, lo snapshot sarà considerato corrotto e dovrà essere eliminato.

Inoltre con gli snapshot di database il ivello di prestazione del sistema può essere ridotto durante le operazioni di modifica dei dati sul database di origine, in quanto le pagine di dati vengono scritte per ogni snapshot nei file sparse dai file di dati del database di origine. Ciò a sua volta moltiplica il numero di scritture per il numero di snapshot contenuto nel database.

Le autorizzazioni di lettura sono definite dal database di origine al punto dello snapshot e non possono essere modificate. Lo snapshot deve risiedere nella stessa istanza del database di origine poiché questi condividono le pagine di dati e la cache buffer.

È possibile considerare di utilizzare snapshot come soluzione di reporting solo se al contempo si utilizza il mirroring; altrimenti non ci sarà alcun miglioramento della prestazione per l'ambiente. Gli snapshot di database sono forse il modo più rapido per proteggere i dati prima che un'operazione ambigua sia eseguita sul sistema. Il database può essere riportato allo stato dello snapshot oppure i dati possono essere estratti dallo snapshot e sostituire i dati nel database di origine.

Sarà necessario determinare una denominazione standard per i database snapshot. Lo standard che utilizzo è originaldatabasename_date_time.snp. Specifica prima il database di origine, poi il giorno e l'ora (nel formato a 24 ore) in cui lo snapshot è stato catturato.

Distribuzione dei log

La distribuzione dei log è un'opzione di disponibilità elevata limitata che utilizza il backup e il ripristino per eseguire una soluzione a basso costo. La distribuzione dei log approfitta dei backup dei log delle transazioni a intervalli pianificati per mantenere aggiornato un database secondario.

La distribuzione dei log in SQL Server 2005 utilizza procedure guidate per seguire i processi di installazione, pianificazione, inizializzazione e monitoraggio (vedere la Figura 5). Il processo è semplice e può essere completato in pochi minuti.

Figura 5** Installazione guidata della distribuzione dei log **(Fare clic sull'immagine per ingrandirla)

Dopo che è stato identificato il database primario, viene creata una pianificazione e viene determinata l'età del file per i file di backup. Quindi è necessario stabilire le condivisioni file per i file di backup. Dopo avere impostato le condivisioni file, deve essere stabilito il percorso di file del database secondario e il database deve essere inizializzato completando un ripristino del database primario. Infine, bisogna impostare le pianificazioni per le copie dei file di backup e i ripristini dei backup dei log delle transazioni insieme a tutti gli avvisi o i ritardi necessari per ogni passaggio.

Una volta completata l'impostazione, la distribuzione dei log esegue periodicamente il back up del log delle transazioni di un database in un percorso di rete condiviso. Una volta che i file sono stati inviati al percorso condivisio, il backup viene applicato al database secondario in maniera pianificata.

La distribuzione dei log funziona bene in situazioni diverse in quanto è molto semplice. È una buona soluzione per una disponibilità elevata poco costosa e può gestire un sistema di transazione elevato. Il database secondario impiegato nella distribuzione dei log può essere utilizzato in modalità di sola lettura, cosa utile per un database di reporting. La distribuzione dei log richiede un overhead minimo ma necessita di criteri di avviso per la gestione degli errori.

Altri due punti da considerare se si intende adottare la distribuzione dei log nel proprio ambiente sono l'installazione e la gestione semplici e il fatto che non richiede alcuna abilità particolare. Tuttavia la distribuzione dei log non è una soluzione di elevata disponibilità in tempo reale, benché a questo fine possa essere combinata con il mirroring del database. È limitata da pianificazioni e da operazioni quali backup, copie di file e ripristini. Richiede inoltre un failover manuale. Per queste ragioni, la distribuzione dei log fornisce una soluzione semplice per ambienti che non abbiano esigenze legate al tempo.

Clustering di SQL Server

Le attività di clustering del server a livello di sistema operativo comportano hardware duplicato e risorse disco condivise per consentire l'accesso del cluster. Il clustering potrebbe forse essere l'opzione meno intrusiva per gli utenti finali, ma è la più costosa. Richiede almeno il doppio dell'hardware necessario per eseguire un'istanza cluster.

Il clustering è un argomento piuttosto complesso, pertanto, invece di esplorarne tutti i dettagli adesso, ne fornirò una panoramica generale. Il clustering richiede due o più server, in cui devono installate le stesse versioni di Windows® 2000 Advanced Edition o Datacenter Edition o di Windows Server® 2003 Enterprise Edition o Datacenter Edition. Richiede inoltre l'installazione di Microsoft® Cluster Services (MSCS) per gestire la proprietà delle risorse condivise tra i server e gestire gli indirizzi IP, i dischi condivisi e i nomi delle reti. Il clustering richiede inoltre una risorsa del disco condivisa, di solito sotto forma di rete di archiviazione (SAN) o di periferica di archiviazione SCSI collegata.

Anche un'istanza SQL Server è considerata una risorsa e le due edizioni Standard ed Enterprise di SQL Server 2005 possono essere installate in una configurazione cluster. Per un elenco delle funzionalità supportate da entrambe le edizioni di SQL Server 2005, vedere "Feature Comparison Chart for SQL Server 2005" (in inglese) (microsoft.com/sql/prodinfo/features/compare-features.mspx).

Una volta stabilite le risorse sul cluster, il nodo secondario del cluster mantiene una comunicazione regolare con il nodo primario del cluster attraverso una pulsazione stabilita su una rete privata tra i due nodi del cluster. L'hearbeat è un punto di controllo dell'intervallo, misurato per stabilire se il server primario ha generato un errore.

Nel caso di errore del server primario, le risorse vengono spostate sul nodo secondario mantenendo invariato lo stato del server logico. Questo consente ai client di continuare a lavorare con solo una pausa di interazione. L'intero processo di failover può richiedere da 5 a 30 secondi o più in alcuni casi, in funzione dell'hardware, del software e dei componenti di rete coinvolti nel cluster.

Il clustering può rivelarsi una tecnologia costosa e complicata e richiedere abilità specializzate per la risoluzione degli errori del sistema; offre, tuttavia, il failover più facile fra tutte le opzioni di failover automatico disponibili agli utenti finali. Ogni applicazione è diversa e alcune potrebbero non essere abilitate al clustering, o compatibili. Nella peggiore delle ipotesi, può essere necessaria la riconnessione dell'applicazione.

Replica

La replica di SQL Server 2005 può essere utilizzata anche in architetture a disponibilità elevata. Sono disponibili quattro tipi di replica: snapshot, transazionale, peer-to-peer e unione (merge). Peer-to-peer è in realtà una forma di replica transazionale che pertanto non verrà trattata in questa sede.

La replica permette di disporre di un sito e di un database secondari per disponibilità elevata, con funzionalità esattamente uguali a quelle del database primario. Ciò può essere conseguito utilizzando la replica di tipo merge, che gestisce le transazioni dei database primario e secondario e quindi incorpora le modifiche di entrambi i database nei due database. Si potrà ben immaginare come in questa configurazione sia necessaria una procedura di risoluzione dei conflitti.

La replica transazionale è molto simile nella progettazione logica al mirroring del database. Le transazioni applicate al database primario vengono distribuite nel database secondario per assicurare la coerenza dell'ambiente. Una volta arrivate, le transazioni vengono applicate al database secondario, che quindi attende l'applicazione della successiva transazione nel sistema.

La replica snapshot è molto simile alla distribuzione dei log in quanto entrambe sono eseguite a intervalli pianificati e aggiornano il database secondario in modifiche di massa piuttosto che applicare ogni transazione a entrambi i sistemi man mano che ne viene eseguito il commit. Le due tecnologie sono utilizzate pressocché nello stesso modo.

La replica richiede conoscenze specializzate e questo potrebbe essere uno svantaggio in ambienti che non dispongono di un amministratore del database (DBA) dedicato. La replica può rivelarsi relativamente complicata nella risoluzione dei problemi e richiede una progettazione più complessa se deve essere utilizzata come opzione di disponibilità elevata.

La replica può soddisfare in maniera appropriata i requisiti per una soluzione di disponibilità elevata. Questa tecnologia offre quanto può offrire il mirroring del database a livello di record utilizzando la replica transazionale, senza però fornire l'opzione di failover automatico. Supponendo che l'utente disponga di risorse sufficienti e di un pizzico di creatività, creare lo script per una soluzione di failover automatico non dovrebbe rivelarsi troppo complicato.

A differenza del mirroring del database, i database di origine e di destinazione sono entrambi completamente accessibili dalle applicazioni client. La replica fornisce la stessa funzionalità della distribuzione dei log con l'aggiunta della replica degli snapshot.

Bisogna ricordare comunque che la tecnologia della replica è comprovata e ben documentata. Utilizzare la replica per una soluzione di disponibilità elevata comporta alcune limitazioni e le prestazioni possono non essere perfetta, ma solo nella stessa misura del mirroring del database. Qualsiasi soluzione di disponibilità elevata progettata con la replica avrà probabilmente un'architettura più complicata da gestire; non necessariamente più avanzata ma indubbiamente più complessa. Inoltre, uno dei maggiori ostacoli da considerare è che se la struttura del database viene modificata o se si desidera aggiungere una tabella da replicare, è necessario scomporre e ridefinire la pubblicazione affinché le modifiche siano integrate su entrambi i database.

Conclusioni

Si può vedere adesso come creare una soluzione di disponibilità elevata per il proprio ambiente richieda una dose di creatività. Ogni tecnologia SQL Server 2005 di disponibilità elevata possiede punti di forza e punti deboli e ognuna si presta a situazioni diverse.

La distribuzione dei log, la replica degli snapshot e anche il mirroring del database in modalità di prestazione elevata sono utili quando si separa geograficamente un database Web primario dagli ambienti database secondari (in particolare se non richiedono che i dati secondari siano disponibili in tempo reale).

Se, d'altra parte, esiste un requisito secondario di database per dati in tempo reale, allora la replica transazionale o il mirroring del database possono sopportare il carico se la frequenza delle transazioni sul server primario è bassa e il collegamento tra i due siti di ambiente è veloce e non saturato.

Bisogna inoltre considerare in che misura ci si sente a proprio agio con queste tecnologie. Se già si possiede esperienza in alcune delle tecnologie suddette, non ci dovrebbero essere problemi. Se si è manager ma non si dispone di un amministratore del database dedicato, è meglio evitare le tecnologie più complicate come la replica, che presentano molte parti in movimento e una risoluzione dei problemi complicata. Non è escluso considerare di assumere un consulente esperto SQL Server per ottenere assistenza nel progettare, implementare e forse anche formare lo staff nella gestione di una nuova disponibilità elevata che si adatti al proprio ambiente.

Se nella propria organizzazione la disponibilità elevata richiede che i dati siano disponibili in una percentuale di tempo elevata e il tempo di inattività dei dati è un fatto molto serio, il clustering potrebbe essere l'opzione ideale.

In conclusione, per implementare la disponibilità elevata SQL Server 2005 fornisce numerose nuove opzioni, che vengono adattate per servire tipi diversi di ambienti. Una singola opzione di disponibilità potrebbe adattarsi alle proprie esigenze o si potrebbe scegliere di approfittare di una combinazione di tecnologie, ma è oramai chiaro, sono disponibili molte opzioni.

Zach Nichter è un professionista SQL Server con oltre 10 anni di esperienza. Ha ricoperto ruoli di supporto SQL Server diversi, fra cui amministratore del database (DBA), responsabile del team, manager e consulente. Attualmente Zach è architetto DBA presso Levi Strauss & Co. e si dedica in particolare a prestazioni, monitoraggio, architettura e altre atività strategiche di SQL Server.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.