Descrizione delle opzioni di ripristino di emergenza per Microsoft SQL Server

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

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:
259267Servizio 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)
Per ulteriori informazioni sul clustering di failover, fare clic sui seguenti numeri per visualizzare gli articoli della Microsoft Knowledge Base:
243218Ordine di installazione per SQL Server 2000 Enterprise Edition su Microsoft Cluster Server
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:
327518Criteri 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:
323135Microsoft SQL Server 2000 - come impostare il registro per la spedizione (white paper)
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)

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:
195757Domande 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:
325257WebCast del supporto tecnico: Ripristino di Database 2000 SQL Server: Backup e ripristino
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)
aspx http://msdn2.microsoft.com/en-us/library/aa196685 (SQL.80)
aspx http://msdn2.microsoft.com/en-us/library/aa178143 (SQL.80)

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:
100110Cenni 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
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:
307775Articoli 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:
195761Domande frequenti - SQL Server 7.0 - Failover
260758 Domande frequenti - 2000 SQL Server - clustering di Failover
274446 L'aggiornamento a SQL Server 2000 failover soluzione consigliata per tutti i server virtuali non SQL Server 2000
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
Per ulteriori informazioni sulla funzionalitÓ di Backup e ripristino, fare clic sui seguenti numeri per visualizzare gli articoli della Microsoft Knowledge Base:
253817Come eseguire il backup dell'ultimo log delle transazioni quando il master e i file di database vengono danneggiati in SQL Server
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:
240867Come spostare e copiare il backup di file e cartelle del catalogo full-text

ProprietÓ

Identificativo articolo: 822400 - Ultima modifica: martedý 3 luglio 2012 - Revisione: 1.0
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 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
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