Scalabili database condivisi sono supportati da SQL Server 2005

Traduzione articoli Traduzione articoli
Identificativo articolo: 910378 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

INTRODUZIONE

Scalabili dei database condivisi sono supportati da Microsoft SQL Server 2005 Enterprise Edition. In questo articolo Ŕ un'anteprima dell'argomento "Database condiviso ridimensionabili" che verrÓ pubblicato in un futuro aggiornamento della documentazione in linea di.

Informazioni

Database condivisi scalabili

Scalabili dei database condivisi consentono di allegare 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 viene creato da uno o pi¨ database di produzione utilizzati esclusivamente per la creazione di report. Deve essere eseguita in un database condiviso scalabile, un database di report deve risiedere su uno o pi¨ dedicati sola volumi. Lo scopo principale di questi volumi di sola lettura Ŕ per il reporting di host database o un set coordinato di database di reporting. Questi volumi sono noti come volumi di reporting.

Vantaggi

Database condivisi scalabili offrono i seguenti vantaggi:
  • Utilizzo di voce doganale server fornire scalabilitÓ del carico di lavoro del database per report. Un database condiviso scalabile Ŕ un modo conveniente di rendere disponibili per pi¨ istanze di server per la creazione di report, ad esempio esecuzione di query o l'utilizzo di SQL Server 2005 Reporting Services e di sola lettura i data mart o data warehouse.
  • Fornire l'isolamento del carico di lavoro. Ciascun server utilizza il proprio database tempdb , CPU e memoria.
  • Garantisce la stessa visualizzazione di report i dati di tutti i server se tutte le istanze del server sono configurate in modo identico. Ad esempio, tutti i server di utilizzare un unico confronto.

    Nota Facoltativamente, Ŕ possibile aggiornare il database in un secondo volume di reporting di report. Per ulteriori informazioni, vedere la sezione "Massimizza la disponibilitÓ di un database condiviso scalabile".

Restrizioni

Le seguenti restrizioni disponibili per un database condiviso scalabile:
  • Il database deve essere su un volume di sola lettura.
  • I file di dati Ŕ possibile accedere tramite una rete SAN.
  • Scalabili dei database condivisi sono supportati solo in Windows Server 2003 Service Pack 1 (SP1) o una versione successiva di Windows Server 2003.

Aggiornare il ciclo di un database di report

Quando si utilizza un database condiviso scalabile per un database di report, comporta un ciclo di aggiornamento di tre fasi:
  • fase di generazione : il ciclo di aggiornamento di un database di report inizia con la fase di generazione. Prima di un database di report pu˛ essere generato, l'amministratore installa il volume di report sul sistema di produzione e consente di lettura/scrittura. Quando un volume Ŕ in uno stato di lettura/scrittura, il volume pu˛ essere installato solo su un sistema. Se il volume Ŕ installato su pi¨ di un sistema, file System potrebbe danneggiarsi. L'amministratore crea quindi il database utilizzando uno dei metodi di copia dei dati forniti da SQL Server 2005 per copiare i dati o database. Una volta creato il database, l'amministratore imposta il volume in sola lettura e quindi Scollega.
  • fase collegamento : la fase di connessione viene dopo la fase di generazione. La fase di connessione disponibili nel database come un database condiviso scalabile. La fase di connessione deve essere eseguita su ciascuno dei report server singolarmente. Per configurare il database di report come un database condiviso scalabile, l'amministratore installa i volumi di reporting e di sola lettura in un server report attraverso la rete SAN. Dopo che l'amministratore assicura che ogni volume Ŕ impostato su sola lettura, l'amministratore associa il database di report in un'istanza di SQL Server. Database di report in un'istanza di SQL Server Ŕ noto anche come un'istanza di server report. PoichÚ ogni report volume Ŕ di sola lettura, collegamento del database imposta in sola lettura. A questo punto, il database report diventa un database condiviso scalabile accessibili dai client tramite il server di report.

    Nota Se si utilizza un secondo volume report quando si aggiorna il database di report, Ŕ necessario scegliere tra un aggiornamento in sequenza e un aggiornamento sincronizzato. Per ulteriori informazioni, vedere la sezione "Massimizza la disponibilitÓ di un database condiviso scalabile".
  • Disconnetti fase : la terza fase Ŕ la fase di scollegamento. In genere, il database report diventa infine non aggiornato. Il database deve essere aggiornato per mantenere aggiornati i dati di reporting. La fase di disconnessione Ŕ il processo di rimozione di un database di report non aggiornato dal servizio come un database condiviso scalabile. Prima di un database di report aggiornato possibile rendere disponibile su un particolare server report, Ŕ necessario completare la fase di disconnessione su tale server. Quando un database di report deve essere aggiornato, Ŕ necessario essere scollegato da tutte le istanze del server. Per avviare la fase di disconnessione, l'amministratore del database termina prima il carico di lavoro di query che provenga al database da tutte le istanze del server. Ogni istanza del server, l'amministratore del database ottiene accesso esclusivo al database e quindi la Scollega. L'amministratore del database viene quindi Smonta il volume di ciascun sistema host. Una volta completata la fase di disconnessione, il report volume viene disconnesso dalla rete SAN.
Nota Per ottimizzare la disponibilitÓ di raccolta dei dati, si consiglia che alternativo di cicli di aggiornamento tra due volumi come procedura ottimale si consiglia di reporting. Quando il volume di reporting primo Ŕ ancora installato ai server di report, Ŕ possibile montare il volume secondo al server di produzione e quindi generare una versione aggiornata di database di report. Per ulteriori informazioni, vedere la sezione "Massimizza la disponibilitÓ di un database condiviso scalabile".

Nota Ogni fase Ŕ costituito da una serie di passaggi che devono essere eseguite da un utente con diritti di amministratore di database. In questo articolo, l'utente si fa riferimento l'amministratore del database.

importante Per configurare un database condiviso scalabile, l'ambiente SAN deve giÓ funzioni correttamente.

Esempi di database condivisi scalabili

In cicli di aggiornamento successivo, il database pu˛ essere aggiornato o ricreato. Il metodo migliore dipende dalle esigenze aziendali. ╚ possibile utilizzare database condivisi scalabili in due modi seguenti:
  • database del data mart : il pi¨ semplice l'utilizzo di un database condiviso scalabile Ŕ un database di data mart. Un database di data mart viene estratti periodicamente dal contenuto di un data warehouse e viene utilizzato per la creazione di report. Per aggiornare il database di data mart di dati, eliminare il database e quindi sostituirla con una nuova versione.
  • report da un database aggiornabile : quando il database che viene segnalato da non Ŕ necessario essere trasformato dal database di origine, il database pu˛ essere aggiornato periodicamente. Per aggiornare periodicamente il database, creare un backup completo del database di produzione e quindi ripristinare il backup del database sul volume di report o i volumi.

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

Un database condiviso scalabile necessario un volume di sola lettura che Ŕ possibile accedere tramite una rete SAN. I server di report devono essere in esecuzione le seguenti operazioni:
  • Windows Server 2003 SP1 o versione successiva di Windows Server 2003
  • SQL Server 2005 Enterprise Edition o versione successiva di SQL Server 2005
Per supporto, si consiglia di limitare le configurazioni di database condiviso scalabile per otto istanze del server. SQL Server 2005, tuttavia, non limita il numero di istanze simultanee accessibili a un database condiviso scalabile. In genere, ogni istanza di server viene eseguita su un server reporting separato. Tuttavia, l'esecuzione di pi¨ istanze di server report su un server report Ŕ supportata.

Configurare l'ambiente

Per assicurarsi che l'ambiente supporta database condivisi scalabili, si consiglia di seguire queste linee guida:
  • Assicurarsi che che i server di report per un determinato database reporting sono in esecuzione nei sistemi operativi identici. Ogni volta che si aggiorna un server di report, Ŕ necessario aggiornare eventuali altri server report che servono il database condiviso di scalabile stesso o i database. Ad esempio, se si applica un aggiornamento o service pack di software per Windows o SQL Server 2005 a uno qualsiasi dei server di report, Ŕ possibile applicare lo stesso pack di aggiornamento o un servizio software a tutti i report server.

    Nota Spesso, Ŕ possibile eseguire aggiornamenti in sequenza dei report server purchÚ dopo aver completato l'aggiornamento in sequenza in modo tempestivo.
  • Scalabili database condivisi vengono verificati in un carico di lavoro accesso simultaneo da istanze di server fino a otto di SQL Server 2005 Enterprise Edition. SQL Server 2005 non impone un limite di istanza. Tuttavia, si consiglia di limitare le configurazioni di database condiviso scalabile per otto istanze del server per ogni database condiviso.
  • Se i file di dati del database di produzione si estendono su pi¨ volumi, Ŕ 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 coesistere con file di dati in un volume di reporting.
  • Per semplificare il processo di creazione o aggiornamento di un database di report, si consiglia di che il percorso del database di report coincidere con il database di produzione. Questo include utilizzando entrambi la stessa lettera di unitÓ per il report volume e lo stesso percorso di directory per il database. Ad esempio, se il database di produzione si trova su E:\SQLdata, utilizzare E come la lettera di unitÓ del volume report, se Ŕ possibile. Inoltre, utilizzare \SQLdata come directory del database di report, se possibile. Tuttavia, uno script che dispone di percorsi espliciti pu˛ gestire le eventuali differenze. Se il report volume utilizza una lettera di unitÓ diversa dal volume di produzione, potrebbe essere necessario apportare le seguenti modifiche:
    • Se si crea un database di report ripristinando un backup del database, Ŕ necessario che l'istruzione RESTORE DATABASE necessario una clausola WITH MOVE che specifica il percorso completo del file di dati ripristinati.
    • Se il database report Ŕ una copia del database di produzione, Ŕ necessario che la clausola FOR ATTACH dell'istruzione CREATE DATABASE elencare i file. La clausola FOR ATTACH inoltre necessario specificare il percorso completo, quando si collega database di report. Questo valore Ŕ sempre consigliabile.

      Nota Per una protezione ottimale, utilizzare la stessa lettera di unitÓ su ogni server quando si monta un volume di report nel server di report. Questa esercitazione consente di gestire il volume tra i diversi server.
  • Il database di report deve essere disponibile un volume di sola lettura che Ŕ possibile accedere tramite SAN da tutti i report server:
    • Una volta che si monta il report volume su un server di report, assicurarsi che il report volume sia installato correttamente e che i file di dati sono accessibili. A tale scopo, immettere DIR <drive-letter>: \ <database-directory> al prompt dei comandi, dove <drive-letter> Ŕ la lettera assegnata al report volume e <database-directory> specifica il percorso del file di dati del database nel volume. Eseguire il test da ogni server di report per assicurarsi che viene visualizzato lo stesso risultato per tutti.
    • Per assicurarsi che il database di report Ŕ impostato in sola lettura, tenta di creare un file sul volume. Il metodo pi¨ semplice Ŕ tentare di copiare o salvare un file di testo normale nel volume. Il tentativo deve esito negativo perchÚ il volume Ŕ di sola lettura.

      Nota Se si esegue questa procedura manualmente, si consiglia di ripetere i test in ogni ciclo di aggiornamento quando si reinstallare il volume di report su ogni server di report. Se si creano script per la procedura per spostarsi volumi reporting Avanti e indietro tra il server di produzione e i server report, test non Ŕ pi¨ necessaria dopo avere verificato che gli script funzionino correttamente.

Fase 1: La fase di generazione

Creare o aggiornare un database condiviso scalabile

Un database di report deve essere generato e aggiornare manualmente. Questo processo Ŕ la prima fase del ciclo di aggiornamento per un database di report ed Ŕ noto come la fase di generazione. La fase di generazione potrebbe richiedere l'aggiornamento di un database non aggiornato o creare una nuova versione.

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

Completare la fase di generazione

╚ possibile aggiornare un database di report non aggiornato per aggiornare i dati non aggiornati nel database esistente o per la ricostruzione del database.

Nota Prima Ŕ possibile aggiornare un database di report esistente, il database deve essere scollegato da ogni istanza di server report. Inoltre, deve essere smontare il volume reporting da ogni server di report. Per ulteriori informazioni, vedere la sezione "Scollega un database condiviso scalabile".

Per aggiornare un database di report non aggiornato, attenersi alla seguente procedura sul server di produzione:
  1. Utilizzare utilitÓ al fornitore hardware per unmask il numeri di unitÓ logica (LUN, Logical Unit Number) che corrispondono ai volumi di reporting. Questa azione rende i volumi accessibili sul server di produzione.
  2. Montare il volume di reporting e quindi contrassegnarlo come lettura/scrittura. Per utilizzare l'utilitÓ della riga di comando Diskpart per montare il volume, immettere i seguenti comandi al prompt dei comandi: DiskPart
    DISKPART > select volume =<drive-number>
    DISKPART > assegnare lettera =<drive-letter>
    DISKPART > attributo chiaro readonly
    DISKPART > uscire

    In questo passaggio, <drive-number> Ŕ il numero volume viene assegnato da Windows e <drive-letter> Ŕ la lettera che viene assegnata al volume 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, questo potrebbe essere l'istanza del server di produzione.
      CREATE DATABASE <database_name> ON <filespec_list>
         FOR ATTACH
      
    2. Impostare il database in accesso in lettura/scrittura utilizzando l'istruzione Transact-SQL seguente.
      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 database di report, Ŕ possibile aggiornare i dati non aggiornati, ricostruire il database o eseguire qualsiasi altra cosa si ritiene che Ŕ necessario per aggiornare i dati. L'amministratore crea il database utilizzando uno dei metodi di copia dei dati forniti da SQL Server 2005 per la copia di dati o database. Per ulteriori informazioni, vedere la sezione "Metodi per creare o aggiornare un database".

    Nota Nel database di reporting, si consiglia di tale pagina verificare impostare per il checksum , il valore predefinito. Per modificare questa impostazione, utilizzare ALTER DATABASE.
  5. Impostare il database su sola lettura utilizzando la seguente istruzione Transact-SQL.
    ALTER DATABASE <database_name> SET READ_ONLY
  6. Scollegare il database utilizzando Transact-SQL seguente istruzione.
    sp_detach_db @dbname='<database_name>'
    in questo passaggio, <database_name> Ŕ il nome del database.
  7. Contrassegnare il volume come di sola lettura e quindi smontare il volume dal server di produzione. Per utilizzare l'utilitÓ della riga di comando Diskpart per smontare il volume, immettere i seguenti comandi al prompt dei comandi di.
    DiskPart
    DISKPART> select volume=<drive-number>
    DISKPART> attribute set readonly
    DISKPART> remove
    
    in questo passaggio, <drive-number> Ŕ il numero volume viene assegnato da Windows e <drive-letter> Ŕ la lettera che viene assegnata al volume reporting.
  8. Utilizzare utilitÓ al fornitore hardware per mascherare il LUN che corrispondono ai volumi di reporting. Questa azione rende inaccessibile al server di produzione i volumi.
A questo punto, database di report pu˛ essere disponibili come un database condiviso scalabile. Per ulteriori informazioni, vedere la sezione "Associa un database condiviso scalabile".

Metodi per la creazione o aggiornamento di un database

Nota Quando si crea un database di report, si consiglia di utilizzare sempre lo stesso percorso per il database di produzione e i database di report. Inoltre, si consiglia di utilizzare la stessa lettera di unitÓ per la produzione e reporting volume quando il volume Ŕ installato sui server di report, se possibile.

Per il trasferimento di 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 eseguendo pacchetti di Integration Services e utilizzando l'attivitÓ Esegui SQL o Trasferisci Database attivitÓ:
    • L'attivitÓ Esegui SQL esegue istruzioni SQL o stored procedure da un pacchetto. Quando si utilizza l'attivitÓ Esegui SQL, Ŕ possibile creare un database tramite l'esecuzione di un'istruzione CREATE DATABASE. ╚ quindi possibile popolare il database tramite la copia in uno o pi¨ tabelle o viste.
    • L'attivitÓ Trasferisci Database Ŕ possibile copiare un database nella stessa istanza di server o tra istanze.

      Nota ╚ inoltre possibile creare un database utilizzando l'importazione di SQL Server e l'esportazione guidata, ma Ŕ necessario copiare almeno una tabella o vista.
  • backup e ripristino : ╚ possibile ripristinare un backup di un database di produzione nel volume di reporting. A tale scopo, ripristinare e ripristinare un backup completo del database sul volume di report:
    • Se si utilizza la stessa lettera di unitÓ, montare il volume su un host diversi report e quindi connettersi a un'istanza del server sono per ripristinare il database.
    • Se il report volume utilizza una lettera di unitÓ diversa dal volume di produzione, Ŕ necessario che l'istruzione RESTORE DATABASE necessario una clausola WITH MOVE che specifica la lettera di unitÓ del volume report nel percorso del database ripristinato.
  • Copia database di produzione sul volume di report : prima manualmente, Ŕ possibile copiare un database o utilizzare il Disconnetti e aggiungere il metodo di copia guidata database, Ŕ necessario eseguire il database in modalitÓ non in linea. Dopo avere copiato il database, Ŕ possibile portare in linea del database. Tuttavia, la copia guidata database offre un metodo alternativo. Il metodo di trasferimento SMO copia il database, anche se il database rimane in linea. Sebbene il SMO trasferimento Ŕ inferiore di scollega il metodo e metodo Attach, il metodo SMO Transfer mantiene le connessioni attive al database.
Per ulteriori informazioni su questi metodi di copia dei dati, vedere la documentazione in linea di SQL Server 2005 (informazioni in lingua inglese).

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

Fase 2: La fase di connessione

Collegare un database condiviso di scalabile

Una volta creare o aggiornare un database di report e si smontare il volume report dal server di produzione, un amministratore deve rendere il database disponibile 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 la procedura seguente:
  1. Utilizzare utilitÓ al fornitore hardware per unmask LUN che corrispondono ai volumi di reporting. Questa azione rende i volumi accessibili ai client da ogni server di report.
  2. Su ciascun server report, montare il volume che corrisponde al LUN.

    Nota Per semplificare il processo di creazione o aggiornamento di un database di report, si consiglia di installare sempre il volume di report utilizzando la stessa lettera di unitÓ del volume di produzione. Ad esempio, se il database di produzione Ŕ sull'unitÓ E sul server di produzione, il report volume deve inoltre essere installato come unitÓ E in ogni server di report, se Ŕ possibile.

    Per utilizzare l'utilitÓ della riga di comando Diskpart per montare il volume, immettere i seguenti comandi al prompt dei comandi.
    DiskPart
    DISKPART> select volume=<drive-number>
    DISKPART> assign letter=<drive-letter>
    DISKPART> exit
    
    in questo passaggio, <drive-number> Ŕ il numero volume viene assegnato da Windows e <drive-letter> Ŕ la lettera che si desidera utilizzare per il report volume sul server di report.

    Nota Il volume di reporting deve essere di sola lettura. ╚ consigliabile che da sola lettura prima dal server di produzione Ŕ smontare il volume. Se il volume non Ŕ stato contrassegnato come di sola lettura, impostare il volume in sola lettura dopo che montare il volume sul primo server report. Per ulteriori informazioni, vedere la "fase 1: la fase di generazione" sezione.

    Per una protezione ottimale, Ŕ necessario assicurarsi che il volume Ŕ accessibile come volume di sola lettura sulla SAN dopo montare un volume report a ciascun server report. Per ulteriori informazioni, vedere la sezione "Per assicurarsi che che l'ambiente sia corretto per un database condiviso scalabile".
  3. Collegare il database il report istanza del server o istanze in ogni server di report. Per ulteriori informazioni, vedere la documentazione in linea di SQL Server 2005 (informazioni in lingua inglese).
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 infine diventa non aggiornata e deve essere aggiornata per mantenere i dati di reporting. Il processo di rimozione di un database di report non aggiornato dal servizio come un database condiviso scalabile Ŕ noto come la fase di disconnessione. Questa fase Ŕ la fase di aggiornamento per la terza e ultima del ciclo per un database di report. Prima di un database di report aggiornato possibile rendere disponibile su un particolare server report, Ŕ necessario completare la fase di disconnessione su tale server.

Completare la fase di scollegamento

In questa fase, un amministratore attenersi alla procedura seguente su ciascun server report:
  1. Disattivare le nuove query sul database e quindi consentire query correnti, completare, se Ŕ possibile.
  2. Scollegare il database da ogni istanza di server report utilizzando il sp_detach_db @ dbname = '<nome_database>' comando.

    In questo passaggio, <database_name> Ŕ il nome del database. Per ulteriori informazioni sul comando sp_detach_db , vedere la documentazione in linea di SQL Server 2005 (informazioni in lingua inglese).
  3. Su ciascun server report, disinstallare il volume di reporting. Per smontare il volume mediante l'utilitÓ della riga di comando di DiskPart, dei comandi immettere i seguenti comandi al prompt dei comandi.
    DiskPart
    DISKPART> select volume <drive-number>
    DISKPART> remove
    
    in questo passaggio, <drive-letter> Ŕ la lettera assegnata al volume reporting.
  4. Utilizzare utilitÓ al fornitore hardware per mascherare il LUN che corrispondono ai volumi di reporting. Questa azione Ŕ rende i volumi inaccessibile ai client da ogni server di report.

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

Quando si sostituisce la versione non aggiornata di un database, Ŕ necessario considerare i requisiti aziendali per l'ambiente reporting. ╚ necessario valutare quale dei seguenti requisiti aziendali hanno la precedenza nell'ambiente in uso:
  • Conservazione transazioni attualmente in esecuzione fino al termine.
  • Completamento in corso l'aggiornamento entro un intervallo di tempo limitato.
In base alle quali requisito ha la precedenza, Ŕ possibile decidere come gestire la fase di disconnessione su ciascun server report. ╚ possibile gestire la fase di disconnessione nei seguenti modi:
  • Consentire le transazioni di fine prima di scollegare il server di report: per conservare tutte le transazioni in corso, Ŕ necessario avviare la fase di disconnessione interrompendo l'attivitÓ di I/O in ingresso al volume del report. Quindi, in ogni istanza report server, attendere per scollegare il database finchÚ non sono state tutte le transazioni corrente. Quando il database Ŕ stato scollegato da tutte le istanze del server, Ŕ possibile disinstallare il volume di reporting.
  • Aggiornare il database durante un intervallo di tempo limitato: in questo caso, Ŕ necessario ottenere accesso esclusivo al database in ogni istanza del server con un tempo terminazione che consente l'intervallo di tempo. Se le query termina entro tale periodo di tempo terminazione, verrÓ arrestati. Tali query saranno necessario attendere fino a quando non dopo l'aggiornamento per essere riavviato. Una volta le query, Ŕ possibile scollegare il database da ogni istanza del server e quindi smontare il volume reporting da ogni server di report.
A questo punto, si Ŕ pronti per la successiva fase di generazione. In alternativa, se aver giÓ aggiornato il database in un altro volume reporting, come si consiglia, Ŕ ora 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Ó di raccolta dei dati, si consiglia che alternativo di cicli di aggiornamento tra due volumi di reporting. Quando il volume di reporting primo Ŕ ancora installato ai server di report, Ŕ possibile montare il volume secondo al server di produzione e creare una versione aggiornata di database di report.

Se si aggiorna il database di report in un secondo volume di report, Ŕ necessario considerare le seguenti opzioni:
  • Se si desidera tutti i database reporting per restituire risultati identici a client, Ŕ necessario disconnettere la copia precedente dal tutte le istanze del server prima che si collega la nuova copia a uno di essi.
  • Se ai client che ricevono risultati diversi sulle istanze di server diverso quando si aggiorna il database di report non Ŕ tollerabile, Ŕ possibile eseguire un aggiornamento in sequenza di database di report. Dovrebbe avere il ciclo di aggiornamento in un server di report in un momento.

Sensibili al tempo sincronizzati, gli aggiornamenti di tutti i server di report

In questa sezione vengono descritte diverse strategie per aggiornare il contenuto di un database condiviso scalabile, in base alle esigenze aziendali:
  • ╚ necessario mantenere tutti i reporting server sincronizzati.
  • ╚ necessario eseguire l'aggiornamento entro un intervallo di tempo limitato. Questo intervallo di tempo Ŕ pi¨ importante da mantenendo in esecuzione le transazioni.
Quando si sincronizza il database in tutti i server report, database di report non Ŕ compreso tra la fase di disconnessione per la versione del database non aggiornata e la fase di collegamento della nuova versione disponibile.

Per sincronizzare il ciclo di aggiornamento in tutti i report istanze del server e fine dell'aggiornamento ciclo all'interno di un intervallo di tempo limitato, attenersi alla seguente procedura:
  1. Per sincronizzare il contenuto, che Ŕ necessario terminare la disconnessione pu˛ essere aggiornato fase a tutti i server report prima di uno dei server di report. Se le query a esecuzione prolungata sono attive in tutti i server, Ŕ necessario interrompere le.
  2. Dopo che smontare il volume di reporting primo dalla tutte le istanze del server, Ŕ possibile avviare aggiornare i server di report. Su ciascun server report, Ŕ necessario installare un altro volume che contiene una versione pi¨ aggiornata del database di report. Collegare tale versione l'istanza del server di report locale. Non appena il database Ŕ collegato in una determinata istanza, interruzione delle transazioni possono essere riavviate su tale istanza.

Gli aggiornamenti dei server di report in sequenza

Un aggiornamento in sequenza consente di aggiornare il database report su un server report quando un non aggiornati database report rimangono temporaneamente disponibili in un altro server report. Per un periodo di tempo, sia la versione non aggiornata e la versione aggiornata del database sono disponibili nello stesso momento. In base alle proprie esigenze, in un intervallo di tempo limitato possibile effettuare un aggiornamento in sequenza oppure l'aggiornamento in sequenza pu˛ essere relativamente aperte per consentire le transazioni correnti di fine.

Consentire le transazioni di fine prima dell'aggiornamento in sequenza

In questa strategia, un aggiornamento in sequenza consente all'amministratore di database di attendere che finisca in un server di report quando viene aggiornato il database in un altro server di report le transazioni a esecuzione prolungata. Questa strategia consente di risolvere i seguenti requisiti aziendali:
  • I server di report non sono necessario essere mantenute sincronizzate. In questo modo un aggiornamento in sequenza tra database di report non aggiornato e l'aggiornato database di report.
  • Si dispone di un intervallo di tempo illimitato per eseguire l'aggiornamento o alla scadenza Ŕ meno importanti rispetto mantenendo in esecuzione le transazioni.
Per eseguire questo tipo di aggiornamento in sequenza, attenersi alla seguente procedura in una istanza del server in un momento:
  1. Per mantenere tutte le transazioni in corso, Ŕ necessario avviare la fase di disconnessione interrompendo l'attivitÓ di I/O in ingresso al volume del report. Se una query a esecuzione prolungata ritarda l'aggiornamento in un'istanza del server, attendere per la query completare prima di eseguire l'istanza del server in modalitÓ non in linea.
  2. Termine tutte le transazioni in questa istanza di server, scollegare il database di report.
  3. Dopo che Ŕ scollegare un database di report particolare da tutte le istanze del server, Ŕ possibile allegare una versione pi¨ aggiornata del database di report a tale istanza del server.
  4. Per rendere disponibile per eseguire una query di creazione di report l'istanza del server, allegare una copia aggiornata del database.

Terminare l'aggiornamento in sequenza in un tempo limitato

In questa strategia, un aggiornamento in sequenza consente l'amministratore del database per mantenere un servizio di report senza interruzioni consentendo brevemente la versione del database disponibile per nuove query su alcuni server report non aggiornata. Il servizio rimane senza interruzioni quando si aggiorna il database in un altro server di report. Questa strategia consente di risolvere i seguenti requisiti aziendali:
  • I server di report non sono necessario essere mantenute sincronizzate. In questo modo un aggiornamento in sequenza tra database di report non aggiornato e l'aggiornato database di report.
  • ╚ necessario eseguire l'aggiornamento in un intervallo di tempo limitato. La scadenza Ŕ pi¨ importante pi¨ mantenendo in esecuzione le transazioni.
Per eseguire questo tipo di aggiornamento in sequenza, attenersi alla seguente procedura su un server report in un momento:
  1. Interrompere l'attivitÓ di I/O in ingresso al volume di reporting e, facoltativamente, attendere che le transazioni brevi finire un'istanza del server prima di scollegare il database di report.
  2. Completare la fase di disconnessione in tale server. Per ulteriori informazioni, vedere la sezione "Scollega un database condiviso scalabile".
  3. Rendere la versione aggiornata del database di report disponibili per eseguire una query di creazione di report. Per ulteriori informazioni, vedere la sezione "Associa un database scalabile condiviso".
Questo aggiornamento in tipo di sequenza garantisce che la funzionalitÓ di reporting globale non viene interrotta. Questa strategia consente di tollerare transazioni a esecuzione prolungata piuttosto su alcune delle istanze del server per un periodo di tempo. Tuttavia, dato il periodo di tempo limitato per l'aggiornamento di tutti i database di report, se una query a esecuzione prolungata ritardi in modo significativo l'aggiornamento in un'istanza del server, sarÓ necessario interrompere tale query. La query pu˛ attendere di eseguire nuovamente nell'istanza del server stesso dopo Ŕ 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 sito di area download Microsoft:
http://www.microsoft.com/downloads/details.aspx?FamilyID=be6a2c5d-00df-4220-b133-29c1e0b6585f&DisplayLang=en
SQL Server richiede i sistemi supportano ? garantire il recapito al supporto stabile ? come descritto nel programma di Microsoft SQL Server Always-On archiviazione soluzioni revisione. FOPer ulteriori informazioni sui requisiti di input e outpui per il motore di database di SQL Server, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
967576Requisiti di Microsoft SQL Server Database Engine input/output

ProprietÓ

Identificativo articolo: 910378 - Ultima modifica: martedý 20 novembre 2007 - Revisione: 2.4
Le informazioni in questo articolo si applicano a:
  • 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
Chiavi:á
kbmt kbsql2005engine kbtshoot kbinfo KB910378 KbMtit
Traduzione automatica articoli
Il presente articolo Ŕ stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non Ŕ sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, pi¨ o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non Ŕ la sua. Microsoft non Ŕ responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 910378
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com