Panoramica dei database condivisi scalabili

Data aggiornamento: 14 aprile 2006

La funzionalità database condiviso scalabile consente di implementare la scalabilità orizzontale per un database di sola lettura creato esclusivamente per la generazione di report (database di report). Il database di report deve risiedere in un set di volumi di sola lettura dedicati, il cui scopo principale è ospitare il database. Utilizzando prodotti hardware appositi per server e volumi, è possibile implementare la scalabilità orizzontale per un database di report che offre una vista identica dei dati dei report su più server di report. Questa funzionalità offre inoltre una modalità semplice e veloce per l'aggiornamento del database di report.

Dopo la creazione del database di report su un set di volumi per la gestione di report, i volumi vengono contrassegnati come di sola lettura e montati in più server di report. In ogni server di report, il database di report viene quindi collegato a un'istanza di Microsoft SQL Server 2005 e diventa disponibile come database condiviso scalabile. Dopo essere stato definito come database condiviso scalabile, un database di report può essere condiviso fra client che utilizzano server di report diversi. Per eseguire query sul database, un utente o un'applicazione può connettersi a qualsiasi istanza del server al quale il database è collegato. Per una versione specifica di un database di report, i client in server diversi ottengono una vista identica dei dati dei report che garantisce risultati delle query coerenti in tutti i server.

Vantaggi

I database condivisi scalabili offrono i vantaggi seguenti:

• Scalabilità orizzontale del carico di lavoro sui database di report grazie all'utilizzo di server e hardware appositi.
  Un database condiviso scalabile rappresenta un modo economico per rendere un data mart o un data warehouse di sola lettura accessibile a più istanze del server per la generazione di report, ad esempio per l'esecuzione di query o l'utilizzo di Reporting Services.

• Isolamento del carico di lavoro.
  Ogni server utilizza la propria memoria, la propria CPU e il proprio database tempdb. In questo modo è possibile evitare che una query non ottimizzata correttamente monopolizzi tutte le risorse del server .

• Una vista identica dei dati dei report in tutti i server.
  Ciò presuppone che tutte le istanze del server siano configurate in modo identico, ad esempio che utilizzino un'unica sequenza di confronto.

  [!NOTA] Possibilità di aggiornare il database di report in un secondo volume di report. Per ulteriori informazioni, vedere Ottimizzazione della disponibilità di un database condiviso scalabile.

Restrizioni

I database condivisi scalabili presentano le limitazioni seguenti:

• Il database deve risiedere in un volume di sola lettura.
• I file di dati sono accessibili in una rete di archiviazione (SAN).
• I database sono supportati solo da Microsoft Windows Storage Server 2003 eseguito su Windows Server 2003 SP1 o versione successiva.
• È consigliabile limitare le configurazioni con un database condiviso scalabile a otto istanze del server per ogni database condiviso.
• I database condivisi scalabili non supportano gli snapshot del database.

Importante:
La configurazione di un database condiviso scalabile richiede che l'ambiente della rete SAN funzioni già correttamente. Per indicazioni e linee guida relative all'utilizzo di un database condiviso scalabile, vedere Creazione di un ambiente corretto per un database condiviso scalabile.

Creazione e scalabilità orizzontale di un database di report

Per configurare un nuovo database condiviso scalabile, l'amministratore del database inizia dalla creazione di un nuovo database di report in un set di volumi per la gestione di report, oppure dall'aggiornamento di una versione non aggiornata del database di report nei volumi (fase di creazione o aggiornamento). L'amministratore implementa quindi la scalabilità orizzontale per il database configurandolo come database condiviso scalabile in più istanze del server (fase di collegamento).

Nella figura seguente viene illustrata la creazione di un nuovo database di report mediante l'utilizzo di un unico volume per la gestione di report e il successivo collegamento del database per renderlo disponibile come database condiviso scalabile.

La fase di creazione nella figura illustra la procedura di montaggio del volume per la gestione di report nel server di produzione e la creazione del database di report. Dopo il montaggio nel sistema di produzione, il volume viene contrassegnato per l'accesso in lettura/scrittura. Nel volume viene quindi creato un database di report utilizzando uno dei metodi per la copia di dati o di database disponibili in SQL Server 2005. Il database di report illustrato nella figura è una copia di un database di produzione completo. Dopo aver creato il database, l'amministratore imposta ogni volume per la gestione di report per l'accesso in sola lettura e lo smonta.

La fase di collegamento nella figura illustra la procedura per rendere il database di report disponibile come database condiviso scalabile. Innanzitutto, l'amministratore monta il volume per la gestione di report di sola lettura in più server di report nella rete SAN. Il database di report viene quindi collegato a un'istanza di SQL Server in ogni server di report. Poiché i volumi sono di sola lettura, il database viene collegato in modalità di sola lettura. Dopo il completamento di questa procedura in uno specifico server di report, il database di report diventa un database condiviso scalabile in quel server. La fase di collegamento continua finché il database non è collegato a tutti i server di report.

Una data versione di un database di report resta disponibile come database condiviso scalabile fintanto che resta collegata a uno qualsiasi dei server di report.

Aggiornamento di un set di volumi per la gestione di report

Poiché un database di report è di sola lettura, in genere dopo un certo periodo di tempo diventa obsoleto ed è necessario aggiornarlo. In una configurazione con un database condiviso scalabile, la procedura completa di sostituzione di un database di report in uno specifico set di volumi per la gestione di report con una versione aggiornata dello stesso database viene definita ciclo di aggiornamento.

Ciclo di aggiornamento

Il ciclo di aggiornamento inizia con la fase di scollegamento, che termina con lo smontaggio di tutti volumi per la gestione di report da tutti i server di report. Segue quindi la fase di aggiornamento, che equivale alla fase di creazione di un nuovo database di report. La fase di aggiornamento termina con l'installazione di una versione aggiornata del database nei volumi di sola lettura, attualmente non montati in alcun server. Infine, il database viene definito come database condiviso scalabile durante una fase di collegamento, costituita dagli stessi passaggi utilizzati per collegare un nuovo database di report.

• Fase di scollegamento
  Nella prima fase di un ciclo di aggiornamento, il database non aggiornato viene rimosso dalla configurazione con database condiviso scalabile in tutti i server di report. La procedura di rimozione di un database di report non aggiornato dal servizio come database condiviso scalabile viene definita fase di scollegamento del ciclo di aggiornamento. Prima di rendere disponibile una versione aggiornata di un database di report in uno specifico server di report, è necessario aver completato questa fase in tale server.
  Per iniziare la rimozione del database, l'amministratore interrompe il carico di lavoro di query in arrivo nel database da tutte le istanze del server e quindi scollega il database in tutti i server di report. Nel momento in cui viene scollegato dall'ultima istanza del server, il database di report cessa di essere un database condiviso scalabile. Per completare questa fase, l'amministratore smonta il set di volumi per la gestione di report contenenti il database obsoleto.
• Fase di aggiornamento
  La fase successiva del ciclo di aggiornamento comporta l'aggiornamento del database sullo stesso set di volumi per la gestione di report, ad esempio importando i dati di produzione più recenti oppure ricostruendo il database mediante il ripristino di un backup recente del database di produzione. Il metodo migliore per l'aggiornamento di un database dipende dai requisiti aziendali.
• Fase di collegamento
  Per completare il ciclo di aggiornamento di un set di volumi per la gestione di report, l'amministratore deve implementare la scalabilità orizzontale per il database aggiornato. Se per una configurazione con un database condiviso scalabile viene utilizzato un solo set di volumi per la gestione di report, la procedura di collegamento durante un aggiornamento equivale alla procedura di collegamento originale.

Alternanza delle versioni del database fra due set di volumi per la gestione di report

Per ottimizzare la disponibilità di una configurazione con un database condiviso scalabile è possibile utilizzare alternativamente due set di volumi per la gestione di report. In questo modo è possibile sovrapporre i cicli di aggiornamento di un database obsoleto e un database aggiornato. Il database di report aggiornato risiede in set di volumi diversi. Prima di scollegare la versione non aggiornata del database e di smontare i relativi volumi, è possibile aggiornare il database nel set di volumi alternativo e montare tali volumi nei server di report. Quando la versione non aggiornata del database verrà scollegata da una determinata istanza del server, sarà quindi possibile collegare immediatamente la versione aggiornata.

Per ulteriori informazioni, vedere Ottimizzazione della disponibilità di un database condiviso scalabile.

Vedere anche

Concetti

Creazione di un ambiente corretto per un database condiviso scalabile
Creazione o aggiornamento di un database di report
Collegamento di un database di report come database condiviso scalabile
Scollegamento di un database condiviso scalabile
Ottimizzazione della disponibilità di un database condiviso scalabile

Guida in linea e informazioni

Assistenza su SQL Server 2005

Cronologia modifiche

Versione	Cronologia
14 aprile 2006	Nuovo contenuto: Aggiunta della restrizione in base alla quale gli snapshot del database non sono supportati.
5 dicembre 2005	Nuovo contenuto: Aggiunta dell'argomento relativo alla nuova funzionalità database condiviso scalabile.