Database condivisi scalabili sono supportati da SQL Server 2005

IMPORTANTE: il presente articolo è stato tradotto tramite un software di traduzione automatica di Microsoft ed eventualmente revisionato dalla community Microsoft tramite la tecnologia CTF (Community Translation Framework) o da un traduttore professionista. Microsoft offre articoli tradotti manualmente e altri tradotti automaticamente e rivisti dalla community con l’obiettivo di consentire all'utente di accedere a tutti gli articoli della Knowledge Base nella propria lingua. Tuttavia, un articolo tradotto automaticamente, anche se rivisto dalla community, non sempre è perfetto. Potrebbe contenere errori di vocabolario, di sintassi o di grammatica. Microsoft declina ogni responsabilità per imprecisioni, errori o danni causati da una traduzione sbagliata o dal relativo utilizzo da parte dei clienti. Microsoft aggiorna frequentemente il software e gli strumenti di traduzione automatica per continuare a migliorare la qualità della traduzione.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 910378
INTRODUZIONE
Database condivisi scalabili sono supportati da Microsoft SQL Server 2005 e versioni successive. In questo articolo è stata un'anteprima dell'argomento "Database condiviso scalabile" che è stata pubblicata al seguente argomento della documentazione in linea di SQL Server

Panoramica di database condivisi scalabili
Informazioni

Database condivisi scalabili

Database condivisi scalabili consentono di collegare un database di report di sola lettura a più istanze del server su una rete di archiviazione (SAN). Un database di report è un database di sola lettura che è compilato da uno o più database di produzione vengono utilizzati esclusivamente a scopo di reporting. Per essere trasformata in un database condiviso scalabile, un database di reporting deve risiedere su uno o più volumi dedicati di sola lettura. Lo scopo principale di questi volumi di sola lettura è per ospitare il database di report o un set coordinato di database di reporting. Questi volumi sono noti come volumi di reporting.

Vantaggi

Database condivisi scalabili offrono i seguenti vantaggi:
  • Usingcommodity server per fornire scalabilità orizzontale del carico di lavoro dei report del database. Un database condiviso scalabile è una soluzione conveniente di sola makingread data mart o data warehouse disponibili per la creazione di report, ad esempio l'esecuzione di query o utilizzando i servizi di SQL Server 2005Reporting più instancesfor di server.
  • Fornire l'isolamento del carico di lavoro. Ogni server utilizza il database tempdb , CPU e ownmemory.
  • Garantisce la stessa visualizzazione dei dati serversif tutte le istanze del server sono configurate in modo identico di reporting. Allservers, ad esempio, utilizzare regole di confronto singole.

    Nota Facoltativamente, è possibile aggiornare il database di report in un volume di secondreporting. Per ulteriori informazioni, vedere la sezione "Massimizza la disponibilità di un database condiviso di ascalable".

Restrizioni

Per un database condiviso scalabile esistono le seguenti restrizioni:
  • Il database deve essere in un volume di sola lettura.
  • I file di dati è accessibile attraverso una rete SAN.
  • Database condivisi scalabili sono supportati solo in Microsoft Windows Server 2003 Service Pack 1 (SP1) o una versione successiva di Windows Server 2003.

Ciclo di aggiornamento di un database di report

Quando si utilizza un database condiviso scalabile per un database di report, prevede un ciclo di aggiornamento trifase:
  • Fase di compilazione: il ciclo di aggiornamento di un database di report inizia con la buildphase. Prima di un database di report può essere generato, l'amministratore Monta volume thereporting nel sistema di produzione e rende la lettura/scrittura. Quando avolume è in uno stato di lettura/scrittura, il volume può essere installato solo su un sistema. Se il volume è montato su più sistemi, mightoccur di danneggiamento del file System. L'amministratore crea quindi il database mediante uno della copymethods di dati forniti da SQL Server 2005 per la copia dei dati o database. Dopo che tenga viene compilato, l'amministratore imposta il volume sola lettura e thendismounts esso.
  • Connetti fase: la fase di connessione viene dopo la fase di compilazione. Phasemakes di Connetti al database disponibile come un database condiviso scalabile. Eseguire il phasemust Connetti su ciascun server di report singolarmente. Per configurare il database thereporting come un database condiviso scalabile, l'amministratore Monta solo theread volumi report in un server di report su SAN. Dopo theadministrator assicura che ogni volume sia impostato su sola lettura, theadministrator collega il database di report in un'istanza di SQL Server. Thereporting database in un'istanza di SQL Server è noto anche come un'istanza di reportingserver. Poiché ogni report volume è di sola lettura, l'associazione tenga imposta in sola lettura. A questo punto, il database di report diventa ascalable database condiviso accessibili dai client utilizzando il reportingserver.

    Nota Se si utilizza un secondo volume reporting quando si aggiorna il database di thereporting, è necessario scegliere tra un aggiornamento in sequenza e sincrona. Per ulteriori informazioni, vedere la sezione "Ingrandisci il availabilityof di un database condiviso scalabile".
  • Fase di disconnessione: il terzo è la fase di disconnessione. In genere, la reportingdatabase diventa non aggiornato. Il database deve essere aggiornato per mantenere aggiornati i dati di thereporting. La fase di disconnessione è il processo di rimozione di un database stalereporting dal servizio come un database condiviso scalabile. Prima si canmake un database di report aggiornato disponibile su un particolare server di report, è necessario completare la fase di disconnessione in tale server. Quando aggiornare un report databasemust, deve essere scollegato da tutte le istanze del server. Per startthe scollegare fase, le interruzioni di primo amministratore database loadthat di lavoro la query è provenienti al database da tutte le istanze del server. In ogni serverinstance, l'amministratore del database ottiene accesso esclusivo al database e quindi lo stacca. L'amministratore del database verrà smontato il sistema di host fromeach volume. Quando viene completata la fase di disconnessione, il contabile isdisconnected volume dal SAN.
Nota Per ottimizzare la disponibilità dei dati di reporting, è consigliabile che si alternano cicli di aggiornamento tra due volumi di reporting è consigliabile. Quando ancora installato il primo volume di reporting per i server di report, è possibile montare il volume secondo al server di produzione e quindi compilare una versione aggiornata del database di report. Per ulteriori informazioni, vedere la sezione "Massimizza la disponibilità di un database condiviso scalabile".

Nota Ogni fase è composta da una serie di passaggi che devono essere eseguite da un utente con diritti di amministratore del Database. In questo articolo, tale utente verrà indicata per l'amministratore del database.

Importante Per configurare un database condiviso scalabile, l'ambiente SAN deve già essere funziona correttamente.

Esempi di database condivisi scalabili

Cicli di aggiornamento successivo, il database può essere aggiornato o ricostruito. Il metodo preferito dipende dalle esigenze dell'azienda. È possibile utilizzare i database condivisi scalabili in due modi seguenti:
  • Database del data mart: l'utilizzo più semplice di un database condiviso scalabile è un martdatabase di dati. Un database del data mart viene estratto periodicamente dal contenuto di warehouse adata e utilizzato per il reporting. Per aggiornare il database del data mart, eliminare il database e quindi sostituirla con una nuova versione.
  • Creazione di report da un database aggiornabile: quando il database viene segnalato da non dispone di essere trasformato dal database di origine, il database può essere periodicallyupdated. Per aggiornare periodicamente il database, creare un backup completo del database theproduction e quindi ripristinare il backup del database sulla reportingvolume o volumi.

Assicurarsi che l'ambiente sia corretta per un database condiviso scalabile

Deve essere un database condiviso scalabile in un volume di sola lettura che è possibile accedere tramite una rete SAN. I server di report devono essere in esecuzione il seguente:
  • Windows Server 2003 SP1 o versione successiva di Windows Server 2003
  • SQL Server 2005 Enterprise Edition o una versione successiva ofSQL versione Server 2005
Per supporto, si consiglia di limitare le configurazioni di database condivisi scalabili a otto istanze del server. Tuttavia, SQL Server 2005 non limita il numero di istanze contemporanee che possono accedere a un database condiviso scalabile. In genere, ogni istanza del server viene eseguito su un server di report separato. Tuttavia, è supportato in esecuzione più istanze di server report su un server di report.

Configurare l'ambiente

Per assicurarsi che l'ambiente supporta database condivisi scalabili, si consiglia di attenersi alle seguenti indicazioni:
  • Assicurarsi che i server di report per un database di particularreporting sono in esecuzione su sistemi operativi identici. Ogni volta che youupgrade un server di report, eseguire l'aggiornamento di tutti gli altri server report che servono la stessa scalabile condivisa o più database. Ad esempio, se si applica l'aggiornamento di asoftware o service pack per Windows o SQL Server 2005 per uno qualsiasi dei server di report, è possibile applicare stesso software aggiornamento o un service pack a allthe server di report.

    Nota Spesso, è possibile eseguire aggiornamenti in sequenza della reportingservers fino a quando si completa l'aggiornamento in sequenza in modo tempestivo.
  • Database condivisi scalabili sono testati sotto un carico di lavoro concurrentaccess da fino a otto istanze del server di SQL Server 2005 EnterpriseEdition. SQL Server 2005 non impone un limite di istanza. Tuttavia, werecommend di limitare i tipi condivisi configurazioni di database da istanze di eightserver per ogni database condiviso.
  • Se i file di dati del database di produzione includono multiplevolumes, è necessario utilizzare lo stesso numero di volumi di reporting. Al contrario, poiché il database di report è impostato su sola lettura, i file di registro possono co-existwith i file di dati in un volume di reporting.
  • Per semplificare il processo di creazione o aggiornamento di areporting database, è consigliabile che il percorso del database di report sia lo stesso del database di produzione. Include l'utilizzo di entrambi la stessa letterfor di unità del volume di reporting e lo stesso percorso di directory per il database. Ad esempio, se il database di produzione è su e:\Sqldata., utilizzo E come il letterof di unità del volume di reporting, se è possibile. Inoltre, utilizzare \SQLdata come thedirectory del database di report, se possibile. Tuttavia, un percorsi espliciti thathas di script in grado di gestire eventuali differenze. Se il report volume utilizza la lettera di unità di adifferent a quella del volume di produzione, potrebbe essere necessario apportare modifiche di thefollowing:
    • Se si compila il database di report tramite il ripristino di un backup del database, l'istruzione RESTORE DATABASE deve avere una clausola WITH MOVE che specifica il percorso completo dei file di dati ripristinati.
    • Se il database di report è una copia del database di produzione, la clausola dell'istruzione CREATE DATABASE FOR ATTACH deve elencare tutti i file. La clausola FOR ATTACH è necessario specificare anche il percorso completo quando si collega il database di report. È sempre consigliabile.

      Nota Ottimale, utilizzare la stessa lettera su tutti i server quando si monta un volume di report nel server di report. Questa pratica aiuta a gestire il volume su più server.
  • Il database di report deve in thatcan un volume di sola lettura è possibile accedere attraverso la rete SAN da tutti i server di report:
    • Dopo avere montato il volume di reporting su un server di report, assicurarsi che il volume di reporting è montato correttamente e che i file di dati è possibile accedere. A tale scopo, immettere DIR <drive-letter></drive-letter>:\<database-directory></database-directory> al prompt dei comandi, dove <drive-letter></drive-letter> è la lettera assegnata al volume reporting e <database-directory></database-directory> Specifica il percorso del file di dati del database nel volume. Eseguire il test da ogni server di report per essere certi di ricevere gli stessi risultati per tutti.
    • Per assicurarsi che il database di report è impostato in sola lettura, tenta di creare un file sul volume. Il metodo più semplice consiste nel tentare di copiare o salvare un file di testo normale nel volume. Il tentativo avrà esito negativo perché il volume è di sola lettura.

      Nota Se si esegue la procedura manualmente, si consiglia di ripetere questi test in ogni ciclo di aggiornamento quando si rimontare il volume su ogni server di report reporting. Se si crea script per la procedura per spostarsi avanti e indietro reporting volumi tra il server di produzione e i server di report, test non è più necessario dopo essersi assicurati che gli script funzionano correttamente.

Fase 1: Fase di creazione

Creare o aggiornare un database condiviso scalabile

Un database di report deve essere compilato e aggiornato manualmente. Questo processo è la prima fase del ciclo di aggiornamento di un database di report ed è noto come la fase di compilazione. La fase di compilazione può richiedere l'aggiornamento di un database non aggiornato o creando una nuova versione.

In genere, la versione corrente di un database di report diventa non aggiornata. Il database di report deve essere aggiornato periodicamente per mantenere aggiornati i dati di reporting.

Completare la fase di compilazione

È possibile aggiornare un database di report non aggiornato mediante l'aggiornamento dei dati non aggiornati nel database esistente o la ricostruzione del database.

Nota Prima di poter aggiornare un database di report esistente, è necessario scollegare il database da ogni istanza di reporting Services. Inoltre, è necessario smontare il volume reporting da ogni server di report. Per ulteriori informazioni, vedere la sezione "Scollegamento di un database condiviso scalabile".

Per aggiornare un database di report non aggiornato, attenersi alla seguente procedura sul server di produzione:
  1. Del produttore dell'hardware per utilità Togli maschera i numeri logicalunit (LUN) che corrispondono ai volumi di reporting. Questa azione makesthe dei volumi accessibili sul server di produzione.
  2. Montare il volume di reporting e contrassegnarlo asread/scrittura. Per utilizzare l'utilità della riga di comando Diskpart per montare il volume, enterthe seguenti comandi al prompt dei comandi:DiskPart
    DISKPART > selectvolume =<drive-number></drive-number>
    DISKPART > assignletter =<drive-letter></drive-letter>
    DISKPART > attributo clear readonly
    DISKPART > uscire

    In questo passaggio,<drive-number></drive-number> è il numero del volume che isassigned da Windows, e <drive-letter></drive-letter> è theletter che viene assegnata al volume di reporting.
  3. Se si desidera aggiornare un database di report esistente, attenersi alla seguente procedura:
    1. Collegare il database a un'istanza del server. In genere, si tratta dell'istanza del server di produzione.
      CREATE DATABASE <database_name> ON <filespec_list>   FOR ATTACH
    2. Impostare il database per l'accesso in lettura/scrittura utilizzando la seguente istruzione Transact-SQL.
      ALTER DATABASE <database_name> SET READ_WRITE
      Per ulteriori informazioni, vedere la documentazione in linea di SQL Server 2005.
  4. Creare il database.

    Per aggiornare un reportingdatabase, è possibile aggiornare i dati non aggiornati, ricostruire il database o else dowhatever che si ritiene necessario per aggiornare i dati. Il database utilizzando uno dei metodi di copia dei dati che siano cessati SQL Server 2005 per la copia dei dati o database di administratorbuilds. Per ulteriori informazioni, vedere la sezione "Metodi per la creazione o aggiornamento di un database".

    Nota Nel database di report, si consiglia di impostare tale pageverify di checksum, il valore predefinito. Impostazione di changethis, utilizzare ALTER DATABASE.
  5. Impostare il database di sola lettura utilizzando l'istruzione SQL followingTransact.
    ALTER DATABASE <database_name> SET READ_ONLY
  6. Scollegare il database utilizzando il seguente Transact-SQLstatement.
    sp_detach_db @dbname='<database_name>'
    In questo passaggio, <database_name></database_name> è il nome del database.
  7. Contrassegnare il volume come di sola lettura e quindi disinstallare il server di produzione volumefrom. Per utilizzare il todismount di utilità della riga di comando Diskpart il volume, immettere i seguenti comandi al prompt dei comandi.
    DiskPartDISKPART> select volume=<drive-number>DISKPART> attribute set readonlyDISKPART> remove
    In questo passaggio, <drive-number></drive-number> è il numero di thevolume assegnato da Windows, e<drive-letter></drive-letter> è la lettera è AssegnatoA il volume di reporting.
  8. Utilità del produttore dell'hardware per mascherare il thatcorrespond LUN per i volumi di reporting. Questa operazione rende inaccessibleto i volumi del server di produzione.
A questo punto, il database di report possibile renderla disponibile come un database condiviso scalabile. Per ulteriori informazioni, vedere la sezione "Connetti un database condiviso scalabile".

Metodi per la creazione o l'aggiornamento di un database

Nota Quando si compila un database di report, si consiglia di utilizzare sempre lo stesso percorso per il database di produzione e i relativi database. Inoltre, si consiglia di utilizzare la stessa lettera di unità per la produzione e il reporting di volume quando il volume è montato sui server di report, se possibile.

Per il porting dei dati in un database o per il porting di un intero database, SQL Server 2005 supporta attualmente i seguenti metodi:
  • SQL Server Integration Services: È possibile creare o copiare un database mediante l'esecuzione di pacchetti di IntegrationServices e utilizzando l'attività Esegui SQL o il Databasetask di trasferimento:
    • L'attività Esegui SQL esegue istruzioni SQL o stored procedure da un pacchetto. Quando si utilizza l'attività Esegui SQL, è possibile creare un database eseguendo un'istruzione CREATE DATABASE. È quindi possibile popolare il database copiando in una o più tabelle o viste.
    • L'attività Trasferisci Database è possibile copiare un database nella stessa istanza del server o tra le istanze.

      Nota È inoltre possibile creare un database utilizzando SQL Server importazione / esportazione guidata, ma è necessario copiare almeno una tabella o vista.
  • Backup e ripristino: È possibile ripristinare un backup di un database di produzione in volume di thereporting. A tale scopo, ripristinare e recuperare un volume di reporting ontothe backup completo del database:
    • Se si utilizza la stessa lettera di unità, montare il volume di reporting su un host diverso e quindi connettersi a un'istanza di server disponibili per ripristinare il database.
    • Se il report volume utilizza una lettera di unità diversa rispetto al volume di produzione, l'istruzione RESTORE DATABASE deve avere una clausola WITH MOVE che specifica la lettera di unità del volume report nel percorso del database ripristinato.
  • Copia del database di produzione in volume di reporting: prima manualmente, è possibile copiare un database o utilizzare il metodo andAttach di scollegamento di copia guidata Database, è necessario portare non in linea del database. Dopo avere copiato il database, è necessario portare il database in linea. Tuttavia, la procedura guidata CopyDatabase offre un metodo alternativo. Copiesthe il metodo di trasferimento SMO database anche se il database rimane in linea. Sebbene la Transfermethod SMO è più lento rispetto al metodo di collegamento e scollegamento, il trasferimento SMO methodpreserves connessioni attive al database.
Per ulteriori informazioni su questi metodi di copia dei dati, vedere la documentazione in linea di SQL Server 2005.

Quando il database di report è pronto, è necessario completare la fase di compilazione. Per ulteriori informazioni, vedere la "fase 1: la fase di compilazione" sezione.

Fase 2: La fase di collegamento

Collegare un database condiviso scalabile

Dopo di creare o aggiornare un database di report e si smontare il volume report dal server di produzione, un amministratore deve rendere disponibile il database come un database condiviso scalabile. Questo processo è noto come la fase di connessione.

Completare la fase di connessione

In questa fase, un amministratore deve eseguire le seguenti operazioni:
  1. Utilizzare l'utilità del produttore dell'hardware per la LUNsthat di Togli maschera corrispondono ai volumi di reporting. Questa operazione rende la volumesaccessible ai client dal server di report.
  2. In ogni server di report, montare la thatcorresponds volume al LUN.

    Nota Per semplificare il processo di creazione o aggiornamento di un reportingdatabase, si consiglia sempre di montaggio volume delle sue relazione con la stessa lettera di unità come volume di produzione. Ad esempio, se il productiondatabase è sull'unità E sul server di produzione, il reporting shouldalso volume essere montato come unità E in ogni server di report, se è possibile.

    Per utilizzare l'utilità della riga di comando Diskpart per montare il volume enterthe seguenti comandi al prompt.
    DiskPartDISKPART> select volume=<drive-number>DISKPART> assign letter=<drive-letter>DISKPART> exit
    In questo passaggio, <drive-number></drive-number> è il numero di thevolume assegnato da Windows, e<drive-letter></drive-letter> è la lettera che si desidera utilizzare per il volume di report nel server di report.

    Nota Il volume di reporting deve essere di sola lettura. È consigliabile che bemarked in sola lettura prima del volume viene disinstallato dal server di produzione. Se non è stato contrassegnato come di sola lettura, impostare il volume di sola lettura quando si montaggio del volume sul primo server di report. Per ulteriori informazioni, vedere "fase 1: la fase di compilazione" sezione.

    Ottimale, shouldmake che il volume sia accessibile come un volume di sola lettura tramite il SANafter montare un volume di reporting per ogni server di report. Per ulteriori informazioni, vedere la sezione "Verificare che l'ambiente sia corretta per un database scalableshared".
  3. Collegare il database per il reporting orinstances istanza server su ogni server di report. Per ulteriori informazioni, vedere in linea di SQL Server 2005Books.
Il database di report è ora disponibile come un database condiviso scalabile e possono continuare le query.

Fase 3: La fase di disconnessione

Scollegare un database condiviso scalabile

In genere, la versione corrente di un database di report alla fine diventa obsoleto e deve essere aggiornata per mantenere aggiornati i dati di reporting. Il processo di rimozione di un database di report non aggiornato dal servizio come un database condiviso scalabile è nota come la fase di disconnessione. Questa fase è la terza e ultima fase dell'aggiornamento del ciclo per un database di report. Prima di poter effettuare un database di report aggiornato disponibili su un server di report particolare, deve essere completata la fase di disconnessione in tale server.

Completare la fase di disconnessione

In questa fase, un amministratore deve eseguire le seguenti operazioni su ogni server di report:
  1. Disabilitare nuove query sul database e quindi let currentqueries completare normalmente, se possibile.
  2. Scollegare il database da ogni segnalazione tramite istanza server di sp_detach_db @dbname ='<database_name>'</database_name>.

    In questo passaggio,<database_name></database_name> è il nome del database. Per ulteriori informazioni sul comando sp_detach_db , vedere la documentazione in linea di SQL Server 2005.
  3. In ogni server di report, è necessario smontare il volume di reporting. Per smontare il volume utilizzando l'utilità della riga di comando Diskpart, immettere i comandi di thefollowing un prompt dei comandi.
    DiskPartDISKPART> select volume <drive-number>DISKPART> remove
    In questo passaggio, <drive-letter></drive-letter> viene theletter assegnato al volume di reporting.
  4. Utilità del produttore dell'hardware per mascherare il thatcorrespond LUN per i volumi di reporting. Questa operazione rende i volumi di client inaccessibleto da ogni server di report.

Strategie alternative per la disconnessione di un database di report non aggiornato

Quando si sostituisce la versione di un database non aggiornata, è necessario considerare i requisiti aziendali per l'ambiente di creazione di report. È necessario valutare quale dei seguenti requisiti aziendali hanno la precedenza nel proprio ambiente:
  • Conservazione transazioni in esecuzione fino al theyfinish.
  • Completamento dell'aggiornamento all'interno di un limitedtimeframe.
In base a quale requisito ha la precedenza, è possibile decidere come gestire la fase di disconnessione in ogni server di report. È possibile gestire la fase di disconnessione nei modi seguenti:
  • Consentire le transazioni di fine prima di scollegare il reportingserver: per mantenere tutte le transazioni in corso, è necessario avviare il detachphase interrompendo l'attività in ingresso per il volume di reporting. Quindi, nell'istanza del server eachreporting, attendere prima di scollegare il database fino a quando tutti i currenttransactions sono terminate. Quando il database è stato scollegato da tutte le istanze della cartella, è possibile smontare il volume di reporting.
  • Aggiornare il database durante un intervallo di tempo limitato: In thiscase, è necessario ottenere l'accesso esclusivo al database in ogni serverinstance con un tempo di chiusura che consente l'intervallo di tempo. Qualsiasi queriesdo non completato entro tale periodo di chiusura, verrà arrestati. Tali querieswill essere necessario attendere fino a dopo l'aggiornamento è necessario riavviare. Dopo aver arestopped la query, è possibile scollegare il database da ogni istanza del server e thendismount il volume da ogni server di report reporting.
A questo punto, si è pronti per la prossima fase di compilazione. In alternativa, se è già stato aggiornato il database in un altro volume di reporting come è consigliabile, è possibile eseguire la fase di connessione per il volume alternativo. Per ulteriori informazioni, vedere la sezione "Massimizza la disponibilità di un database condiviso scalabile".

Ottimizzare la disponibilità di un database condiviso scalabile

Per ottimizzare la disponibilità dei dati di reporting, è consigliabile che si alternano cicli di aggiornamento tra due volumi di reporting. Quando ancora installato il primo volume di reporting per i server di report, è possibile montare il volume secondo al server di produzione e creare una versione aggiornata del database di report.

Se si aggiorna il database di report in un secondo volume di reporting, considerare le seguenti opzioni:
  • Se si desidera che tutti i database di reporting per returnidentical i risultati ai client, è necessario disconnettere la vecchia copia da tutti i serverinstances prima di associare la nuova copia di uno di essi.
  • Se è in grado di tollerare ai client che ricevono le istanze del server ondifferent risultati diversi quando si aggiorna il database di report, è possibile eseguire un aggiornamento in sequenza del database di report. Si terminerebbe Aggiorna ciclo su un server di report alla volta.

Sincronizzato, gli aggiornamenti urgenti di tutti i server di report

In questa sezione vengono descritte diverse strategie per l'aggiornamento del contenuto di un database condiviso scalabile, a seconda delle esigenze di business:
  • È necessario mantenere tutti i server di report in sincronia.
  • È necessario eseguire l'aggiornamento entro un intervallo di tempo limitato. Questo intervallo di tempo è più importante preservare le transazioni in esecuzione.
Quando si sincronizza il database in tutti i server di report, il database di report non è disponibile tra la fase di disconnessione per la versione del database non aggiornata e la fase di collegamento della nuova versione.

Per sincronizzare il ciclo di aggiornamento su tutte le istanze del server e fine del ciclo all'interno di un intervallo di tempo limitato l'aggiornamento contabile, attenersi alla seguente procedura:
  1. Per mantenere sincronizzato il contenuto, è necessario terminare la detachphase su tutti i server di report prima la segnalazione canbe server aggiornato. Se tutte le query con esecuzione prolungata sono attive in tutti i server, è necessario stopthem.
  2. Dopo aver disinstallato il primo volume di reporting da tutte le istanze della cartella, è possibile avviare aggiornare i server di report. Sul server eachreporting, montare un altro volume che contiene una versione più aggiornata del database di report. Collegare tale versione per il serverinstance di report locale. Quando il database viene collegato in una determinata istanza, stoppedtransactions può essere riavviato in tale istanza.

Gli aggiornamenti del server di report in sequenza

Un aggiornamento in sequenza consente di aggiornare il database di report su un server di report quando un non aggiornati database di reporting rimangono temporaneamente disponibile su un altro server di report. Per un periodo di tempo, la versione non aggiornata e la versione aggiornata del database sono disponibili nello stesso momento. A seconda delle esigenze aziendali, può verificarsi un aggiornamento in sequenza in un intervallo di tempo limitato o l'aggiornamento in sequenza può essere relativamente aperta per consentire transazioni correnti di fine.

Consentire le transazioni di fine prima l'aggiornamento in sequenza

In questa strategia, un aggiornamento in sequenza consente all'amministratore di database per l'attesa di transazioni a esecuzione prolungata completare l'operazione su un server di report quando viene aggiornato il database su un altro server di report. Questa strategia consente di risolvere i seguenti requisiti:
  • Non sono necessario mantenere sincronizzati i server di report. Thispermits una sequenza di aggiornamento tra il database di report non aggiornato e il database di updatedreporting.
  • Si dispone di un periodo di tempo illimitato per eseguire l'aggiornamento o la scadenza è meno critica conservando attualmente runningtransactions.
Per eseguire questo tipo di aggiornamento in sequenza, attenersi alla seguente procedura su un'istanza del server alla volta:
  1. Per mantenere tutte le transazioni in corso, è necessario startthe scollegare fase interrompendo l'attività in ingresso per il volume di reporting. Query con esecuzione prolungata IFA di ritardare l'aggiornamento su un'istanza del server, attendere che l'interrogazione venga completata prima di disconnettere l'istanza del server.
  2. Dopo aver eseguito tutte le transazioni sono su questo serverinstance, scollegare il database di report.
  3. Dopo avere scollegato un database di report particolare dalle istanze del server allthe, allegare una versione più aggiornata di databaseto il report istanza server.
  4. Per rendere nuovamente disponibili per reportingqueries l'istanza del server, è possibile allegare una copia aggiornata del database.

Completare l'aggiornamento in sequenza in un periodo di tempo limitato

In questa strategia, un aggiornamento in sequenza consente all'amministratore del database per garantire la continuità del servizio reporting brevemente, permettendo la versione del database sia disponibile per nuove query su alcuni server di report non aggiornata. Il servizio rimane senza interruzione quando si aggiorna il database su un altro server di report. Questa strategia consente di risolvere i seguenti requisiti:
  • Non sono necessario mantenere sincronizzati i server di report. Thispermits una sequenza di aggiornamento tra il database di report non aggiornato e il database di updatedreporting.
  • È necessario eseguire l'aggiornamento in un intervallo di tempo limitato. Questo termine è più importante preservare le transazioni in esecuzione.
Per eseguire questo tipo di aggiornamento in sequenza, attenersi alla seguente procedura su un server di report alla volta:
  1. Interrompere l'attività in ingresso per il volume di reporting e, facoltativamente, attendere che le transazioni brevi di fine beforeyou un'istanza di server scollegare il database di report.
  2. Fine della fase di disconnessione a tale server. Per ulteriori informazioni, vedere la sezione "Scollegamento di un database condiviso scalabile".
  3. Verificare la versione aggiornata del reporting databaseavailable nuovamente per le query di report. Per ulteriori informazioni, vedere la sezione "Database scalabile ashared Attach".
Questo tipo di aggiornamento garantisce che le funzionalità di reporting globali non viene mai interrotto. Questa strategia consente di tollerare le transazioni abbastanza lunga in alcune istanze del server per un periodo di tempo. Tuttavia, dato l'intervallo di tempo limitato per l'aggiornamento di tutti i database di report, se una query con esecuzione prolungata in modo significativo Ritarda l'aggiornamento di un'istanza del server, sarà necessario interrompere tale query. La query può attendere prima di eseguire nuovamente la stessa istanza del server dopo che è stato aggiornato il database di report o la query può essere riavviata prima su un server aggiornato.
Riferimenti
Per scaricare la documentazione in linea di SQL Server 2005, visitare il seguente sito Web area Download Microsoft:
SQL Server richiede sistemi per supportare la "consegna garantita su un supporto stabile' come indicato in base al programma di Microsoft SQL Server Always-On archiviazione soluzione revisione. FoPer ulteriori informazioni sui requisiti di input e outpui per il motore di database di SQL Server, fare clic sul seguente numero di articolo per visualizzare l'articolo della Microsoft Knowledge Base:
967576 Requisiti di Input/Output di Microsoft SQL Server Database Engine
SSD kbsql2005addtobol

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 910378 - Ultima revisione: 05/12/2015 03:45:00 - Revisione: 1.0

Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems, Microsoft SQL Server 2005 Enterprise X64 Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard

  • kbsql2005engine kbtshoot kbinfo kbmt KB910378 KbMtit
Feedback