DetailPage-MSS-KB

Microsoft Knowledge Base

Identificativo articolo: 822400 - Ultima modifica: martedì 3 luglio 2012 - Revisione: 1.0

 

In questa pagina

Sommario

Questo articolo vengono descritte varie soluzioni per il ripristino dei dati da un database di Microsoft SQL Server, se si verifica una situazione di emergenza. Anche in questo articolo vengono illustrati i vantaggi e gli svantaggi di ciascuna soluzione.

Ripristino di emergenza è un processo che è possibile utilizzare per il recupero di informazioni sistemi e dati, se si verifica una situazione di emergenza.

Alcuni esempi di situazioni di emergenza includere una naturale o un'emergenza sintetiche o artificiali, ad esempio un incendio o un tecnico emergenza, ad esempio un errore di due dischi in un Redundant Array of Independent Disks () Array RAID 5.

Pianificazione del ripristino di emergenza è il lavoro dedicato alla preparazione di tutte le azioni da eseguire in risposta a una situazione di emergenza. La pianificazione include la selezione di una strategia per il recupero preziosi dati. La scelta della strategia di ripristino d'emergenza appropriato dipende i requisiti aziendali.

Nota Forniscono solo le soluzioni descritte in questo articolo descrizioni generali delle tecnologie da utilizzare. Questi generali le descrizioni sono per il confronto tra i vari metodi di ripristino di emergenza e la piani di ripristino di emergenza. Prima di decidere su quale soluzione di ripristino di emergenza è consigliabile, assicurarsi di osservare ogni emergenza suggerito soluzioni di ripristino in modo più dettagliato. Dopo aver esaminato ogni ripristino di emergenza soluzione, in questo articolo contiene collegamenti in cui è possibile trovare ulteriori informazioni informazioni su tale soluzione.

Clustering di failover

Microsoft SQL Server 2000 clustering di failover è progettato per failover automatico se si verifica un errore hardware o un errore software. Si utilizzare SQL Server 2000 clustering di failover per creare un failover del cluster per un singola istanza di SQL Server 2000 o per più istanze di SQL Server 2000 Il clustering di Failover consente a un sistema di database passare il l'elaborazione di un'istanza di SQL Server da un server non riuscita per un lavoro Server. Di conseguenza, il clustering di failover è utile se un sistema operativo si verifica l'errore o se si esegue un aggiornamento pianificato del sistema di database risorse. Inoltre, il clustering di failover aumenta la disponibilità di server senza tempi di inattività.

Poiché il clustering di failover è progettato per server ad alta disponibilità con quasi alcuna inattività del server, i nodi del cluster devono essere geograficamente vicini. Il clustering di failover potrebbe non essere utile se un si verifica l'errore del disco matrice.

Nota Per implementare il clustering di failover, è necessario installare Microsoft SQL Server 2000 Enterprise Edition.

I seguenti sistemi operativi supporto del clustering di failover:
  • Microsoft Windows NT 4.0 Enterprise Edition
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows Server 2003, Enterprise Edition
  • Microsoft Windows Server 2003, Datacenter Edition
Questi sistemi operativi includono un componente installabile Microsoft Cluster Service (MSCS). Per implementare il failover clustering per SQL Server, è necessario installare MSCS.

Per ulteriori informazioni su MSCS e relativa installazione, fare clic sul numero dell'articolo riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base:
259267  (http://support.microsoft.com/kb/259267/ ) Servizio Cluster Microsoft risorse di installazione

Vantaggi e svantaggi dell'utilizzo del clustering di failover

Vantaggio
Si dispone di un'elevata disponibilità. Se il server primario non riesce, si verifica automaticamente il clustering di failover.
Svantaggi
  • Si comportano una spesa maggiore. Il mantenimento di due server è due volte il costo di gestione di un singolo server. Poiché è necessario gestire due server contemporaneamente, è più costoso installare e gestire i nodi del cluster.
  • I server devono essere nella stessa posizione. Se le succursali di l'organizzazione sono in tutto il mondo e i cluster attivo/attivo devono essere implementata in diramazioni, la rete e l'infrastruttura di archiviazione che è necessario utilizzare è molto diverso da un cluster di server a quorum standard. Pertanto, sebbene sia possibile, è preferibile non utilizzare geograficamente Server distanti.
  • Non si dispone di alcuna protezione contro un array di dischi errore.
  • Il clustering di failover non consentono di creare failover cluster di database di livello o nel database oggetto livello, ad esempio il a livello di tabella.
Per ulteriori informazioni sul clustering di failover, visitare il sito Web Microsoft:
aspx http://msdn2.microsoft.com/en-us/library/aa174512 (SQL.80) (http://msdn2.microsoft.com/en-us/library/aa174512(SQL.80).aspx)
Per ulteriori informazioni sul clustering di failover, fare clic sui seguenti numeri per visualizzare gli articoli della Microsoft Knowledge Base:
243218  (http://support.microsoft.com/kb/243218/ ) Ordine di installazione per SQL Server 2000 Enterprise Edition su Microsoft Cluster Server
822250  (http://support.microsoft.com/kb/822250/ ) WebCast del supporto tecnico: Procedure di ripristino di emergenza di clustering di failover Microsoft SQL Server 2000
Per ulteriori informazioni sui criteri di supporto Microsoft per un cluster di failover di SQL Server, fare clic sul numero dell'articolo riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base:
327518  (http://support.microsoft.com/kb/327518/ ) Criteri di supporto Microsoft per un cluster di failover SQL Server

Il mirroring del database

Mirroring del database è un principalmente soluzione software per aumentare la disponibilità del database. È solo possibile implementare il mirroring su un singolo database. Il mirroring funziona solo con i database che utilizzano il modello di recupero completo. I modelli di recupero semplice e massa non supportano il mirroring del database. Pertanto, tutte le operazioni di massa vengono sempre registrate. Il mirroring del database funziona con qualsiasi livello di compatibilità del database supportati.

Vantaggi e svantaggi dell'utilizzo del mirroring del database

Vantaggi
  • Il mirroring del database aumenta la protezione dei dati.
  • Il mirroring del database aumenta la disponibilità di un database.
  • Il mirroring del database consente di migliorare la disponibilità del database di produzione durante gli aggiornamenti.
Svantaggi
  • Il database mirror dovrà essere identico al database principale. Ad esempio, tutti gli oggetti, gli accessi e le autorizzazioni devono essere identiche.
  • Mirroring del database prevede il trasferimento di informazioni da un computer a un altro computer in rete. Di conseguenza, la protezione delle informazioni che trasferisce il SQL Server è molto importante.

Replica transazionale peer-to-peer

La replica transazionale peer-to-peer è progettata per le applicazioni che potrebbero leggere o potrebbero modificare i dati in qualsiasi database che partecipa alla replica. Inoltre, se tutti i server che ospitano i database sono disponibili, è possibile modificare l'applicazione per instradare il traffico ai server rimanenti. I server rimanenti contengono copie identiche dei dati.

Vantaggi e svantaggi dell'utilizzo di replica transazionale peer-to-peer

Vantaggi
  • Le prestazioni di lettura sono migliorata poiché è possibile distribuire l'attività in tutti i nodi.
  • Aggregare le prestazioni dell'aggiornamento, inserire le prestazioni ed eliminare le prestazioni per la topologia è simile a prestazioni di un singolo nodo perché tutte le modifiche vengono propagate a tutti i nodi.
Svantaggi
  • Replica peer-to-peer è disponibile solo in SQL Server 2005 Enterprise Edition.
  • Tutti i partecipanti database devono contenere dati e schemi identici.
  • Si consiglia di utilizzare il proprio database di distribuzione ogni nodo. Questa configurazione Elimina il rischio di SQL Server 2005 per un singolo punto di errore.
  • Non è possibile includere tabelle e altri oggetti in più pubblicazioni peer-to-peer all'interno di un database di pubblicazione.
  • È necessario disporre di una pubblicazione abilitata per la replica peer-to-peer prima di creare le sottoscrizioni.
  • È necessario inizializzare le sottoscrizioni utilizzando un backup o impostare il valore del tipo di sincronizzazione sottoscrizione supporta solo la replica.
  • La replica transazionale peer-to-peer non fornisce il rilevamento di conflitti o risoluzione dei conflitti.
  • Si consiglia di non utilizzare le colonne identity.

Manutenzione di standby a caldo Server

È possibile creare e gestire un server di standby, utilizzando dei seguenti metodi:
  • Distribuzione dei log
  • Replica transazionale
Ulteriori informazioni su ciascuno di questi due metodi seguono.

Distribuzione dei log

Distribuzione dei log è incluso nel resource kit di Microsoft SQL Server 7.0 che è completamente incorporato in Microsoft SQL Server 2000 Enterprise Edition e in Microsoft SQL Server 2000 Developer Edition. Registro spese di spedizione viene utilizzato un server di standby non viene utilizzato durante il normale funzionamento. A server di standby è utile per recuperare i dati in caso di emergenza. È possibile utilizzare solo a livello di database di distribuzione dei log. Non è possibile utilizzare con l'istanza livello.

Quando un server di standby sta ripristinando i log delle transazioni, il il database è in modalità esclusiva e inutilizzabile. Tuttavia, è possibile eseguire batch processi di segnalazione tra i ripristini del log delle transazioni o la Console di Database I comandi (DBCC) controlla continuamente verificare l'integrità di standby Server. Per le applicazioni server di supporto di decisione che richiedono continua l'elaborazione su un server di database, la distribuzione dei log non è un appropriato opzione.

La latenza del server di riserva è basata sulla modalità di frequente i backup del log delle transazioni acquisiti nel server primario e applicati in il server di standby. Se il server primario non riesce, si potrebbero perdere le modifiche che sono state apportate dalle transazioni avvenute dopo l'ultima operazione backup del log.

Ad esempio, se il backup del log delle transazioni vengono eseguite ogni 10 minuti, le transazioni durante il più recente 10 minuti potrebbero andare perse. Questo non significa necessariamente che gli aggiornamenti dei dati che vengono apportati a primario server durante il periodo di latenza andranno perse. In genere, i nuovi aggiornamenti nel log delle transazioni primario può essere recuperato e applicato al server di riserva con un lieve ritardo nella commutazione dal server primario per il server di standby Server. Lo scopo principale della distribuzione dei log è di mantenere un server di standby. Se la gestione di che un server di standby è l'obiettivo principale è la distribuzione dei log potrebbe essere più appropriato di altre soluzioni che questo articolo vengono illustrati.

Vantaggi e svantaggi dell'utilizzo di distribuzione dei log

Vantaggi
  • È possibile recuperare tutte le attività di database. Il ripristino di emergenza include tutti gli oggetti che sono stati creati come tabelle e viste. Esso inoltre include modifiche di protezione come i nuovi utenti che sono stati creati e qualsiasi modifiche alle autorizzazioni.
  • È possibile ripristinare il database più veloce. Il ripristino di il database e log delle transazioni è basato sui formati di basso livello di pagina. Di conseguenza, la distribuzione dei log consente di velocizzare il processo di ripristino e comporta la recupero rapido dei dati.
Svantaggi
  • Il database non è utilizzabile durante il processo di ripristino Poiché il database è in modalità esclusiva nel server di standby.
  • Non vi è la mancanza di granularità. Durante il ripristino processo, tutte le modifiche nel server primario verranno applicati in standby Server. Non è possibile utilizzare la distribuzione dei log per applicare le modifiche di alcune tabelle e rifiutare le modifiche rimanenti.
  • Non vi è alcun failover automatico delle applicazioni. Quando il server primario non riesce a causa di una situazione di emergenza, non il server di standby failover automatico. Pertanto, è necessario reindirizzare in modo esplicito il applicazioni che si connettono al server primario per il server di standby (failover) Server.
Nota Se lo scopo principale è quello di mantenere un server di standby, Microsoft consiglia di utilizzare la distribuzione dei log. Il server di standby a caldo riflette tutte le transazioni eseguite sul server primario. Tuttavia, si non utilizzare il server di standby quando il server primario non è disponibile.

Per ulteriori informazioni su come configurare un server di standby con distribuzione dei log, fare clic sui seguenti numeri per visualizzare gli articoli della Microsoft Knowledge Base:
323135  (http://support.microsoft.com/kb/323135/ ) Microsoft SQL Server 2000 - come impostare il registro per la spedizione (white paper)
325220  (http://support.microsoft.com/kb/325220/ ) WebCast del supporto tecnico: Distribuzione 2000 dei log Microsoft SQL Server
Per ulteriori informazioni sulla distribuzione dei log, visitare il seguenti siti Web Microsoft:
aspx http://msdn2.microsoft.com/en-us/library/aa213785 (SQL.80) (http://msdn2.microsoft.com/en-us/library/aa213785(SQL.80).aspx)

Replica transazionale

È inoltre possibile utilizzare la replica transazionale per mantenere un a caldo server di standby. La replica transazionale consente di replicare i dati in un unico server (autore) a un altro server (server di sottoscrizione) con minore latenza di registro spese di spedizione. È possibile implementare la replica transazionale con l'oggetto di database livello come livello di tabella. Di conseguenza, Microsoft consiglia di utilizzare Quando si hanno meno dati da proteggere e disporre la replica transazionale un piano di ripristino rapido.

È possibile utilizzare una sottoscrizione push per imporre la replica transazionale tra due server con il server primario come il server di pubblicazione e server di riserva come server di sottoscrizione. Replica transazionale assicura la replica dei dati. Quando il server di pubblicazione non riesce, il server di sottoscrizione può essere utilizzato.

Questa soluzione è vulnerabile agli errori del server di pubblicazione e il server di sottoscrizione allo stesso tempo. In questo scenario, non è possibile proteggere il dati. In tutti gli altri scenari, ad esempio il malfunzionamento di un distributore o un server di sottoscrizione, è consigliabile sincronizzare nuovamente i dati nel server di sottoscrizione con il dati nel server di pubblicazione.

Si consiglia di utilizzare la replica transazionale gestione un server di standby solo quando non si implementa le modifiche dello schema o non implementare altre modifiche al database di modifiche della protezione non supporta la replica.

Nota Replica non è progettata per la manutenzione di standby a caldo Server. Con la replica, è possibile utilizzare i dati replicati nel server di sottoscrizione Creazione di report. È inoltre possibile utilizzare la replica ad altri usi generali senza necessità di eseguire l'elaborazione nel server di pubblicazione relativamente occupato.

Vantaggi e svantaggi dell'utilizzo di replica transazionale

Vantaggi
  • Mentre si applicano le modifiche, è possibile leggere i dati su un server di sottoscrizione.
  • Le modifiche vengono applicate con latenza inferiore.

    Nota Questo vantaggio potrebbe non essere applicabile se dei seguenti è true:
    • Gli agenti di replica non sono impostati su continuo.
    • Gli agenti di replica vengono interrotti a causa di errori che possono verificarsi durante la replica.
La replica transazionale può richiedere più tempo per applicare le modifiche Poiché gli aggiornamenti batch di grandi dimensioni devono essere eseguiti durante la replica.
Svantaggi
  • Modifiche dello schema o modifiche di protezione che vengono eseguite a non sarà disponibile in publisher dopo la definizione di replica di server di sottoscrizione.
  • Il server di distribuzione nella replica transazionale viene utilizzata un'aperta Database Connectivity (ODBC) o una connessione di Database OLE (OLEDB) Per distribuire i dati. Tuttavia, la distribuzione dei log utilizza l'operazione di ripristino istruzione Transact-SQL a basso livello per distribuire i log delle transazioni. UN RIPRISTINO Istruzione TRANSACTION è molto più veloce rispetto a una connessione ODBC o OLEDB un connessione.
  • In genere, passare ai server Cancella la replica configurazioni. Pertanto, è necessario configurare la replica due volte:
    Quando si passa al server di sottoscrizione.
    Quando si passa al server di pubblicazione.
  • Se si verifica una situazione di emergenza, è necessario passare manualmente i server da reindirizzamento di tutte le applicazioni server di sottoscrizione.
Per ulteriori informazioni sulla replica, fare clic sul numero dell'articolo riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base:
195757  (http://support.microsoft.com/kb/195757/ ) Domande frequenti - SQL Server 7.0 - replica

Funzionalità di backup e ripristino

Fornisce un'importante caratteristica di Backup e ripristino di SQL Server salvaguardia per proteggere dati importanti memorizzati nel database di SQL Server. È possibile creare una copia di un database (una copia di backup) utilizzando il Backup e Funzionalità di ripristino e quindi archiviare la copia del database in un percorso contro il rischio di malfunzionamenti del server che esegue l'istanza di SQL Server. Se si verifica un errore di sistema di database o il danneggiamento del database, è quindi possibile utilizzare la copia di backup per ricreare il database o per ripristinare il database.

Quando si prevede il ripristino di emergenza utilizzando il Backup e Funzionalità di ripristino, inoltre di determinare la criticità i dati nel database. Inoltre, determinare i requisiti di ripristino per il database. Per esempio, determinare i requisiti di ripristino seguente:
  • Il punto di ripristino di database. È necessario decidere quale delle seguenti due si desidera eseguire:
    Ripristinare il database alla condizione che la notte prima dell'errore.
    Ripristinare il database per la condizione di un punto di tempo più vicino possibile al momento dell'errore.
  • Quanto tempo il database può essere disponibile. Se necessario ripristinare il database immediatamente.
Dopo aver determinato i requisiti di ripristino, è possibile pianificare un eseguire il backup di processo che gestisce un set di backup per soddisfare la requisiti

È possibile ripristinare solo un database per la condizione del punto di tempo in cui è stato eseguito il backup più recente. Le transazioni che si è verificato dopo che il backup potrebbe andare perso. Di conseguenza, Microsoft consiglia è possibile utilizzare la funzionalità di Backup e ripristino solo per il database non critico applicazioni.

Vantaggi e svantaggi dell'utilizzo di funzionalità di backup e ripristino

Vantaggi
  • È possibile eseguire il database di supporti rimovibili per la Guida in linea protezione contro gli errori del disco.
  • Non si dispone come avviene quando dipendono dalla rete Utilizzare il clustering di failover o la distribuzione dei log.
Svantaggi
  • Quando esegue il backup del database, è possibile eseguire operazioni quali la creazione della tabella, creazione di un indice, di compattazione, database o operazioni non registrate.
  • Se si verifica un errore, si potrebbero perdere i dati più recenti.
  • Se si verifica una situazione di emergenza, è necessario ripristinare manualmente il database.
Nota Prima di utilizzare la procedura di Backup e ripristino di una produzione ambiente, è consigliabile verificare accuratamente questa procedura in un test ambiente.

Per ulteriori informazioni sulla funzionalità di Backup e ripristino, fare clic sui seguenti numeri per visualizzare gli articoli della Microsoft Knowledge Base:
325257  (http://support.microsoft.com/kb/325257/ ) WebCast del supporto tecnico: Ripristino di Database 2000 SQL Server: Backup e ripristino
281122  (http://support.microsoft.com/kb/281122/ ) Descrizione del ripristino dei backup di file e filegroup in SQL Server
Per ulteriori informazioni su Backup e Restore funzionalità, visitare i seguenti siti Web Microsoft:
aspx http://msdn2.microsoft.com/en-us/library/aa196617 (SQL.80) (http://msdn2.microsoft.com/en-us/library/aa196617(SQL.80).aspx)
aspx http://msdn2.microsoft.com/en-us/library/aa196685 (SQL.80) (http://msdn2.microsoft.com/en-us/library/aa196685(SQL.80).aspx)
aspx http://msdn2.microsoft.com/en-us/library/aa178143 (SQL.80) (http://msdn2.microsoft.com/en-us/library/aa178143(SQL.80).aspx)

Ridondanza dei dati utilizzando una matrice ridondante di dischi indipendenti (RAID)

Un RAID archivia i dati ridondanti su più dischi per fornire maggiore affidabilità e tempi di inattività ridotti per i server. Livelli RAID 0, 1 e 5 sono in genere utilizzate come opzioni di ripristino per SQL Server. Le tecnologie RAID che menzionati consentono l'errore e la conseguente sostituzione di un singolo disco senza il server non in linea. Se si verificano più errori del disco, i dati potrebbe non essere recuperabile. Microsoft consiglia pertanto di combinare gestione dei dati ridondanti con una procedura di Backup e ripristino per verificare che non perdere i dati se un hardware guasto o altra calamità si verifica.

RAID 0 utilizza tecnologia striping per un accesso più rapido mentre RAID 1 utilizza la tecnologia della specularità per l'affidabilità dei dati. Una tecnica comune utilizzata nella gestione di database relazionale implica l'utilizzo congiunto di RAID 0 e RAID 1. In Questa tecnica, due matrici con striping identiche di unità vengono aggiornati continuamente in modo che le informazioni memorizzate su entrambe le matrici sono lo stesso. Se uno si verifica un errore di matrice, la matrice di altri automaticamente subentra fino alla matrice originale viene riportato in linea.

RAID 5 (noto anche come striping con parità) utilizza un array di dischi con striping singolo con bit di parità scritta con la dati. Quando ogni disco ha esito negativo, è possibile utilizzare i bit di parità per calcolare il dati mancanti fino a sostituiscono il disco. Quando si sostituisce il disco, è possibile utilizzare le informazioni di parità e i dati rimanenti per ricreare i dati di Errore del disco e copiare i dati di ricreare nel nuovo disco. Tutti questi si verificano le operazioni senza l'inattività del sistema. Un RAID fornisce molte altre opzioni e funzionalità per l'utente per assicurarsi che i sistemi di database esperienza come i tempi di inattività minimo possibile.

Vantaggi e svantaggi dell'utilizzo di una configurazione RAID

Vantaggio
Non perdere i dati in caso di ogni disco.
Svantaggi
  • Potrebbe richiedere molto tempo per recuperare i dati.
  • In caso di più dischi, potrebbe non essere in grado di ripristinare dati più importanti.
Per ulteriori informazioni su RAID, fare clic sul numero dell'articolo riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base:
100110  (http://support.microsoft.com/kb/100110/ ) Cenni preliminari su redundant arrays of inexpensive disks (RAID)

Riferimenti

Per scaricare una versione aggiornata della documentazione di SQL Server 2000 In linea, visitare il seguente sito Web Microsoft:
http://www.microsoft.com/downloads/details.aspx?familyid=8e2dfc8d-c20e-4446-99a9-b7f0213f8bc5 (http://www.microsoft.com/downloads/details.aspx?FamilyId=8E2DFC8D-C20E-4446-99A9-B7F0213F8BC5)
Per ulteriori informazioni su altre opzioni di ripristino di emergenza, fare clic sul numero dell'articolo riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base:
307775  (http://support.microsoft.com/kb/307775/ ) Articoli di ripristino di emergenza per Microsoft SQL Server
Per ulteriori informazioni sul clustering di failover, fare clic sui seguenti numeri per visualizzare gli articoli della Microsoft Knowledge Base:
195761  (http://support.microsoft.com/kb/195761/ ) Domande frequenti - SQL Server 7.0 - Failover
260758  (http://support.microsoft.com/kb/260758/ ) Domande frequenti - 2000 SQL Server - clustering di Failover
274446  (http://support.microsoft.com/kb/274446/ ) L'aggiornamento a SQL Server 2000 failover soluzione consigliata per tutti i server virtuali non SQL Server 2000
280743  (http://support.microsoft.com/kb/280743/ ) Windows clustering e siti geograficamente separati
Per ulteriori informazioni su Backup e Restore funzionalità, visitare il seguente sito Web Microsoft:
http://technet.microsoft.com/en-us/library/cc966495.aspx (http://technet.microsoft.com/en-us/library/cc966495.aspx)
Per ulteriori informazioni sulla funzionalità di Backup e ripristino, fare clic sui seguenti numeri per visualizzare gli articoli della Microsoft Knowledge Base:
253817  (http://support.microsoft.com/kb/253817/ ) Come eseguire il backup dell'ultimo log delle transazioni quando il master e i file di database vengono danneggiati in SQL Server
314546  (http://support.microsoft.com/kb/314546/ ) Come spostare database tra computer che eseguono SQL Server
Per ulteriori informazioni sui file e cartelle del catalogo full-text, fare clic sul numero dell'articolo riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base:
240867  (http://support.microsoft.com/kb/240867/ ) Come spostare e copiare il backup di file e cartelle del catalogo full-text

Le informazioni in questo articolo si applicano a:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Standard Edition
Chiavi: 
kbdisasterrec kbreplication kbreplmgr kbclustering kbinfo kbmt KB822400 KbMtit
Traduzione automatica articoliTraduzione 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: 822400  (http://support.microsoft.com/kb/822400/en-us/ )
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.
Condividi
Altre opzioni per il supporto
Forum del supporto di Microsoft Community
Contattaci direttamente
Ricerca di un partner certificato Microsoft
Microsoft Store