Requisiti del sottosistema di I/O di Microsoft SQL Server per il database tempdb

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

In questa pagina

Sommario

Microsoft SQL Server richiede che il sottosistema di I/O utilizzato per archiviare database utente e di sistema completamente rispetta i requisiti di registrazione in avanti di scrittura (WAL) tramite specifica identitÓ di I/O. Questi requisiti sono necessari per rispettare le proprietÓ ACID delle transazioni: atomica, Consistent, Isolated e Durable. Nei seguenti riferimenti sono disponibili informazioni sui requisiti conformitÓ sottosistema di I/O:Nell'elenco riportato di seguito Ŕ riportato un rapido riepilogo dei requisiti:
  • Ordine di scrittura devono essere mantenuti.
  • Necessario mantenere la coerenza di scrittura di dipendenti.
  • Scrive sempre devono essere protetti in/su un supporto stabile.
  • Deve essere la prevenzione di I/O incompleta.
Durata manutenzione rimane fondamentale per tutti gli altri database ma potrebbe essere relaxed per il database tempdb . Nella tabella seguente sono riepilogati numerose importanti requisiti di I/O per i database di SQL Server.
Riduci questa tabellaEspandi questa tabella
requisiti di I/O breve descrizione utente o di sistema tempdb
ordinamento scrittura

Scrittura dipendenti coerenza
La capacitÓ del sottosistema di mantenere l'ordine corretto delle operazioni di scrittura. Pu˛ essere particolarmente importante per il mirroring di soluzioni, i requisiti di coerenza di gruppo e utilizzo del protocollo WAL di SQL Server.RichiestoSi consiglia
lettura dopo scrittura La capacitÓ di sottosistema di servizio richieste con l'immagine dei dati pi¨ recente di lettura quando la lettura viene eseguita dopo ogni scrittura Ŕ completato.RichiestoRichiesto
sopravvivenza tra interruzione La possibilitÓ per i dati rimangono completamente invariate (Durable) in un'interruzione, ad esempio un sistema riavvia.RichiestoNon applicabile
prevenzione di I/O incomplete La capacitÓ del sistema per evitare la suddivisione delle singole richieste di I/O.RichiestoSi consiglia
riscrittura del settore Il settore Ŕ possibile scrivere solo nel suo complesso e non pu˛ essere riscritto causa di una richiesta di scrittura su un settore nelle vicinanze.* Sconsigliato, solo consentito se transazionale* Sconsigliato, solo consentito se transazionale
dati Hardened Nella previsione che quando una richiesta di scrittura o FlushFileBuffers operazione viene completata, i dati sono stati salvati su un supporto stabile.RichiestoNon applicabile
allineamento di settore fisico e la dimensione SQL Server interroga le posizioni di archiviazione dei file di dati e di log. Tutte le periferiche sono necessarie per supportare attributi settore consentendo di SQL Server per operazioni di scrittura su confini fisici allineate ai settori e in multipli della dimensione del settore.RichiestoRichiesto
Riscrittura del settore * transazionale implicano operazioni completamente registrate dal sottosistema di consentire un settore deve essere completamente spostati, sostituito o il rollback all'immagine originale. Questi riscrive sono in genere sconsigliati causa dell'overhead richiesto per eseguire tali azioni aggiuntive. Un esempio sarebbe da un'utilitÓ di deframmentazione che sta passando i dati del file. Il settore originale nel file pu˛ essere sostituito con la nuova posizione settore fino a quando il nuovo settore di avvio e i dati sono completamente protetti. Modifica del mapping del settore deve trovarsi in modo transazionale in modo che qualsiasi errore, tra cui un'interruzione dell'alimentazione, il re-establishment dei dati originali. Assicurarsi che si abbiano meccanismi di blocco disponibili durante questo tipo di processo per impedire l'accesso di dati non validi, quindi upholding di altri titolari di I/O di SQL Server.

Sopravvivenza tra interruzione

Il database di tempdb Ŕ un'area di lavoro per SQL Server e viene ricreato a ogni avvio di SQL Server. L'inizializzazione sostituisce la necessitÓ di dati a sopravvivere un riavvio.

Operazioni di riscrittura di settore transazionale

Per garantire il successo dei processi di ripristino, ad esempio ripristino rollback e l'arresto anomalo del sistema, i record di log devono essere memorizzati correttamente su un supporto stabile prima che la pagina di dati viene archiviata e non pu˛ essere riscritto senza rispettare le proprietÓ di transazione. ╚ necessario che il sottosistema e SQL Server per gestire gli attributi di specifici, ad esempio ordine di scrittura, settore allineato e dimensioni scritture e altri tali attributi di sicurezza I/O descritte nei documenti menzionati in precedenza. Per il database tempdb , il ripristino di arresto anomalo del sistema non Ŕ necessario perchÚ il database Ŕ sempre inizializzato durante l'avvio di SQL Server. Tuttavia, il database tempdb richiede comunque le funzionalitÓ di rollback. Di conseguenza, alcuni attributi del protocollo WAL possono essere relaxed.

La posizione di archiviazione per il database tempdb necessario agire in conformitÓ rigida con protocolli di unitÓ del disco stabilito. In tutti i metodi, la periferica in cui Ŕ archiviato il database tempdb necessario vengono visualizzati e fungono da un disco fisico fornisce lettura dopo la funzionalitÓ di scrittura. Le operazioni di riscrittura del settore delle transazioni possono essere un requisito aggiuntivo di implementazioni specifiche. Ad esempio, SQL Server non supporta database le modifiche utilizzando la compressione del file system NTFS perchÚ la compressione NTFS Ŕ possibile riscrivere settori del log che sono giÓ stati scritti e considerati protetti. Il mancato durante questo tipo di riscrittura pu˛ causare il database sia inutilizzabile, i dati SQL Server giÓ considerato sicuro.

Nota SQL Server 2005 esteso supporto o la compressione per leggere solo i database e gruppi di file. Vedere la SQL Server 2005 documentazione in linea per informazioni dettagliate.

Le operazioni di riscrittura del settore transazionale sono pertinenti a tutti i database SQL Server che includono il database tempdb . Svariati crescente di tecnologie di archiviazione estesa utilizzare dispositivi e utilitÓ che Ŕ possibile riscrivere i dati SQL Server considera protetto. Ad esempio, alcune delle tecnologie emergenti eseguire memorizzazione nella cache in memoria o la compressione dei dati. Per evitare danni gravi del database, qualsiasi riscrittura del settore necessario disporre di supporto completo transazionale in modo che se si verifica un errore, i dati, viene ripristinati alle immagini di settore precedente. Ci˛ garantisce che SQL Server non Ŕ esposto a un'interruzione imprevista o condizione di danneggiamento dei dati.

╚ possibile inserire il database tempdb in sottosistemi di specializzazione, ad esempio dischi RAM, stato solido o altre implementazioni di ad alta velocitÓ che non possono essere utilizzati per altri database. Tuttavia, Ŕ necessario considerare i fattori chiave presentati nella sezione ? informazioni ? quando si valuta queste opzioni.

Informazioni

Da diversi fattori devono essere studiati con attenzione quando si valuta la posizione di archiviazione del database tempdb . Ad esempio, l'utilizzo del database tempdb implica ma non Ŕ limitato a footprint di memoria, piano di query e le decisioni di I/O. La tuning appropriato e l'implementazione del database tempdb possono migliorare la scalabilitÓ e di una capacitÓ di risposta di un sistema. In questa sezione vengono descritti i fattori chiave per determinare le esigenze di archiviazione per il database tempdb .

Sottosistemi ad alta velocitÓ

Sul mercato che forniscono il sottosistema di I/O di SQL Server i requisiti del protocollo ma che non forniscono la durata del supporto sono disponibili diverse implementazioni di sottosistema ad alta velocitÓ.

importante Verificare sempre il fornitore del prodotto per garantire la piena conformitÓ con esigenze di I/O di SQL Server.

Un disco di RAM Ŕ un esempio comune di tale implementazione. Dischi RAM installa i driver necessari e attivare la parte del disco RAM principale vengono visualizzati come a funzionare come un'unitÓ di disco Ŕ collegata al sistema. Tutti i sottosistemi di I/O devono fornire piena conformitÓ con i requisiti di I/O di SQL Server. Tuttavia, Ŕ evidente che un disco RAM non Ŕ supporto permanente. Di conseguenza, un'implementazione ad esempio un disco RAM pu˛ essere utilizzata solo come percorso del database tempdb e non pu˛ essere utilizzata per qualsiasi altro database.

Tasti per la prima implementazione e distribuzione

Esistono vari punti da considerare prima distribuzione del database tempdb su questo tipo di sottosistema. In questa sezione viene utilizzato un disco RAM come base per informazioni, ma i risultati simili si verificano in altre implementazioni ad alta velocitÓ.

Protezione di I/O

ConformitÓ di lettura dopo la scrittura e operazioni di scrittura transazionale settore Ŕ indispensabile. Non distribuire SQL Server su qualsiasi sistema che non supporta completamente i requisiti di I/O di SQL Server e si rischia di danni e la perdita dei dati.

Pagina giÓ memorizzata nella cache (cache RAM Double)

Le tabelle temporanee sono simili tutte le altre tabelle un database. Sono memorizzati nella cache dal pool di buffer e gestiti da operazioni di scrittura lazy. Memorizzazione di pagine della tabella temporanea su un disco RAM provoca la RAM doppie memorizzazione nella cache, uno nel pool di buffer e uno sul disco RAM. Questo richiede direttamente dal possibile dimensione ?s pool di buffer e in genere riduce le prestazioni di SQL Server.

Rinunciare alla RAM

Come suggerisce il nome, il disco RAM designa una parte della RAM principale. Sono disponibili diverse implementazioni di dischi RAM e la cache di file basati su RAM. Alcune consentono inoltre / O fisico le operazioni di backup. L'elemento chiave della cache dei file basati su RAM Ŕ che direttamente occorrono lontano dalla memoria fisica che pu˛ essere utilizzata da SQL Server. Disporre sempre prova solida, tale aggiunta di una cache di file basati su RAM migliora le prestazioni dell'applicazione e non si ridotta altre prestazioni di query o un'applicazione.

Prima di ottimizzare

Un'applicazione deve ottimizzare per rimuovere gli ordinamenti inutili e indesiderati e hash, che potrebbe causare l'utilizzo del database tempdb . Numero di volte l'aggiunta di un indice possibile rimuovere la necessitÓ dell'ordinamento o hash nel piano di completamente, causando prestazioni ottimali senza l'utilizzo del database tempdb .

Vantaggi possibili punti

I vantaggi di collocare il database tempdb su un sistema ad alta velocitÓ possono essere determinati solo tramite test rigorosi e le misurazioni dei carichi di lavoro applicazione. Il carico di lavoro deve essere studiato con attenzione per le caratteristiche del database tempdb pu˛ trarre vantaggio da e deve essere confermata la sicurezza di I/O prima della distribuzione.

Le operazioni di ordinamento e hash utilizzare insieme i gestori di memoria SQL Server per determinare le dimensioni dell'area di lavoro in memoria per ogni operazione di ordinamento o di hash. Non appena i dati di ordinamento o hash superano l'area di lavoro in memoria allocata, i dati possono essere scritti nel database tempdb . Questo algoritmo Ŕ stato ampliato in SQL Server 2005, riducendo i requisiti di utilizzo del database tempdb rispetto alle versioni precedenti di SQL Server. Ad esempio, utilizzando un ordinamento forzato puro di una tabella, Nessun indice decrescente ordine e la stessa configurazione hardware, SQL Server 2005 illustrata notevoli miglioramenti su SQL Server 2000.

attenzione SQL Server Ŕ progettato per l'account per i livelli di memoria e le attivitÓ di query corrente quando si effettua le decisioni di piano di query che implicano l'utilizzo di operazioni di database tempdb . Pertanto, l'incremento delle prestazioni varia notevolmente in base alle carichi di lavoro e progettazione dell'applicazione. Si consiglia di completare il test con la soluzione migliore per individuare possibili guadagni e valutare i requisiti di sicurezza I/O prima di una distribuzione di tali.

SQL Server utilizza il database tempdb per gestire diverse attivitÓ che coinvolgono Ordina, hash, l'archivio della versione di riga e temp tabelle:
  • Le tabelle temporanee vengono gestite dalle routine di pool di buffer comuni per le pagine di dati e in genere non manifestano vantaggi di prestazioni da implementazioni di sottosistema speciale.
  • Il database tempdb viene utilizzato come un'area di lavoro per l'hash e ordinati. Pu˛ essere utile ridurre la latenza di I/O per tali operazioni. Tuttavia, indica che l'aggiunta di un indice per evitare un hash o un ordinamento pu˛ fornire un vantaggio simile.
Eseguire previsioni con e senza il database di tempdb memorizzate sul sottosistema ad alta velocitÓ per confrontare i vantaggi. Del test dovrebbe includere query sul database utente che non coinvolgono Ordina, hash o tabelle temporanee e quindi confermare che tali query non siano influenzate negativamente. Quando si valuta il sistema, gli indicatori di prestazioni seguente possono essere utili.
Riduci questa tabellaEspandi questa tabella
indicatore descrizione/utilizzo
pagina letture e scritture Migliorare le prestazioni di tempdb database I/o potrebbe modificare il tasso di letture di pagine e di scrittura per i database utente causa della latenza ridotta associata al database tempdb I/O. Per pagine di database utente, il numero globale non deve variare tra il carico di lavoro stesso.
fisico leggere e scrivere i byte nel database tempdb Se verso il database tempdb in un dispositivo, ad esempio un disco RAM, aumenta i/O effettivo per il database tempdb , indica che la memoria utilizzata lontano dal pool di buffer causa attivitÓ del database maggiore tempdb si verifichi. Questo modello Ŕ un indicatore presunta la pagina del database di pagine pu˛ inoltre dipendere in modo negativo.
pagina presunta Un rifiuto presunta delle pagine pu˛ indicare un aumento dei requisiti I/O fisici per un database utente di. La riduzione di velocitÓ probabilmente potrebbe indicare che la memoria utilizzata lontano dal pool di buffer sta forzando pagine di database per uscire dal pool di buffer in modo anomalo. Combinare con gli altri indicatori e verificare a fondo i limiti del parametro.
velocitÓ effettiva globale
Utilizzo della CPU
ScalabilitÓ
Tempo di risposta
L'obiettivo principale di una modifica configurazione del database tempdb Ŕ per aumentare il throughput complessivo. La verifica deve includere una combinazione di carichi di lavoro ripetibili che possono essere ridimensionati per determinare l'effetto velocitÓ effettiva.

Simile a un'implementazione di disco RAM basato sulla compressione potrebbe funzionare anche con 10 utenti. Tuttavia, con maggiore carico di lavoro, questo potrebbe push CPU livelli oltre i livelli desiderati e che produca effetti negativi sui tempi di risposta quando sono elevati carichi di lavoro. Test di stress true e test di stima del carico futuro si consiglia.
file di lavoro e azioni di creazione tabella di lavoro Se verso il database tempdb in un dispositivo, ad esempio un disco RAM viene modificato il piano di query aumentando il numero o la dimensione del file di lavoro o tabelle di lavoro, indica che la memoria utilizzata lontano dal pool di buffer causa attivitÓ del database maggiore tempdb si verifichi. Questo modello Ŕ un'indicazione che la pagina permanenza presunta delle pagine di database potrebbe essere interessato anche in modo negativo.

Esempio di riscrittura di settore transazionale

Nell'esempio seguente vengono illustrate le la protezione dei dati richiesto dal database di SQL Server.

Si supponga che un fornitore di disco RAM utilizza un'implementazione di compressione in memoria. Fornendo l'aspetto fisico del flusso di file come se il settore Ŕ stato allineato e dimensioni in modo che SQL Server sia correttamente protetti dall'implementazione sottostante e deve essere incapsulato correttamente l'implementazione. Esaminare l'esempio di compressione pi¨ vicino.
Riduci questa tabellaEspandi questa tabella
azione
Settore 1 viene scritto sulla periferica e viene compressa per risparmiare spazio.
Settore 2 viene scritto sulla periferica ed Ŕ compresso con settore 1 per risparmiare spazio.
La periferica potrebbe procedere come indicato seguito per proteggere i dati di settore ?s 1 viene associata a dati di settore ?s 2.
Riduci questa tabellaEspandi questa tabella
azione
Bloccare tutte le scritture a settori 1 e 2.
Decomprimere il settore 1 in un'area di lavoro, lasciando archiviazione settore 1 corrente come attivi dati da recuperare.
Comprimere settori 1 e 2 in un nuovo formato di archiviazione.
Bloccare tutte le letture e scritture dei settori 1 e 2.
Precedente di archiviazione per settori 1 e 2 con nuovo archivio di Exchange.
Se il tentativo di exchange ha esito negativo (ripristino):
  • Ripristinare l'archivio originale per settori 1 e 2.
  • Rimuovere i dati di settori 1 e 2 combinati dall'area di lavoro.
  • Impossibile l'operazione di scrittura del settore 2.
Sbloccare le letture e scritture per settori 1 e 2.
La possibilitÓ di fornire meccanismi di blocco intorno le modifiche di settore e il rollback delle modifiche quando il tentativo di scambio di settore non riesce Ŕ considerata sempre compatibile. Per le implementazioni che utilizzano memoria fisica per backup estesa, includerÓ gli aspetti del log delle transazioni appropriato per proteggere e il rollback modifiche che sono state applicate a strutture su disco per mantenere l'integritÓ dei file di database SQL Server.

Qualsiasi periferica che consente la riscrittura di settori deve supportare la riscrittura in modo transazionale in modo che SQL Server non Ŕ esposta una perdita di dati.

Nota L'istanza di SQL Server viene riavviato quando si verificano in linea di I/O e gli errori di rollback nel database tempdb .

Prestare attenzione quando si sposta il database tempdb

Prestare attenzione quando Ŕ spostare il database tempdb , in quanto se il database tempdb non pu˛ essere creato, SQL Server non verrÓ avviato. Se il database tempdb non pu˛ essere creato, Ŕ possibile avviare SQL Server utilizzando il (-f) parametro di avvio e spostare il database tempdb in un percorso valido.

Per modificare la posizione fisica del database tempdb , attenersi alla seguente procedura:
  1. Utilizzare l'istruzione ALTER DATABASE e la clausola MODIFY FILE per modificare i nomi di file fisico di ogni file nel database tempdb per fare riferimento alla nuova posizione fisica, ad esempio il nuovo disco.
    Alter database tempdb modify file 
    (name = tempdev, filename = 'C:\MyPath\tempdb.mdf')
    
    Alter database tempdb modify file 
    (name = templog, filename = 'C:\MyPath\templog.ldf')
  2. Arrestare e riavviare SQL Server.

Certificazioni prodotto partner non sono un adeguatezza di compatibilitÓ o di protezione

Un prodotto di terze parti o un fornitore specifico pu˛ ricevere una certificazione del logo di Microsoft. Tuttavia, certificazione di partner o un logo di Microsoft specifico non certificare compatibilitÓ o di adeguatezza per uno scopo particolare in SQL Server.

Supporto

Se si utilizza un sottosistema con SQL Server supporta le garanzie di I/O per l'utilizzo di transazionale del database come descritto in questo articolo, Microsoft fornirÓ supporto per SQL Server e applicazioni basate su SQL Server. Tuttavia, problemi, o causato da, il sottosistema si fa riferimento al produttore.

Per problemi correlati al database tempdb , supporto tecnico verrÓ chiesto di spostare il database tempdb . Consente di contattare il fornitore di periferica per verificare che sia stato correttamente distribuito e configurato il dispositivo per database transazionale.

Microsoft non certifica o convalida che prodotti di terze parti funzionino correttamente con SQL Server. Inoltre, Microsoft non fornisce alcuna garanzia, adeguatezza o istruzione di idoneitÓ qualsiasi prodotto di terze ?s per l'utilizzo con SQL Server.

Riferimenti

Per ulteriori informazioni, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportato di seguito:
826433PRB: Diagnostica aggiuntive di SQL Server aggiunto a rilevare problemi di I/O
828339Messaggio di errore 823 possibile problemi hardware oppure problemi del sistema in SQL Server
234656Utilizzando la cache del disco con SQL Server
110352Ottimizzazione delle prestazioni di Microsoft SQL Server
304261Descrizione del supporto per i file di database di rete in SQL Server
913945Microsoft certificare non funzionamento di prodotti di terze parti con Microsoft SQL Server
910716Requisiti per SQL Server 2005 e SQL Server 2000 per supportare il mirroring remoto dei database utente
917043Principali fattori da considerare quando si valutano i sistemi di cache del file di terze parti con SQL Server
Le informazioni contenute nel presente documento rappresentano le conoscenze attuali di Microsoft Corporation sull'argomento trattato, alla data di pubblicazione. PoichÚ Microsoft deve rispondere ai cambiamenti delle condizioni di mercato, documento non deve essere interpretato come un impegno da parte di Microsoft e Microsoft non garantisce l'accuratezza delle informazioni presentate dopo la data di pubblicazione.

In questo white paper Ŕ informativi esclusivamente per scopi. MICROSOFT NON GARANZIA, ESPLICITA O IMPLICITA, RELATIVA ALLE INFORMAZIONI CONTENUTE IN QUESTO DOCUMENTO.

ConformitÓ tutte le applicabili leggi in materia di copyright Ŕ responsabilitÓ dell'utente. Senza limitare i diritti coperti da copyright, nessuna parte di questo documento pu˛ essere riprodotto, memorizzata in o introdotta in un sistema di recupero o trasmessa in qualsiasi forma o con qualsiasi mezzo (elettronico, meccanico, tramite fotocopie, registrazione o in caso contrario) o per qualsiasi scopo, senza il permesso scritto di Microsoft Corporation.

Microsoft pu˛ essere titolare di brevetti, domande di brevetto, marchi, copyright o altri diritti di proprietÓ intellettuale relativi all'oggetto in questo documento. Salvo quanto espressamente previsto in un contratto scritto di licenza da Microsoft, di fornire di questo documento non concessione Ŕ alcuna licenza su tali brevetti, marchi, copyright o altra proprietÓ intellettuale.

ę 2006 Microsoft Corporation. Tutti i diritti riservati.

Microsoft, Windows, Windows Server e SQL Server sono marchi registrati o marchi di Microsoft Corporation negli Stati Uniti e/o negli altri paesi.
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: 917047 - Ultima modifica: venerdý 2 novembre 2007 - Revisione: 1.6
Le informazioni in questo articolo si applicano a:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 Workgroup Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Chiavi:á
kbmt kbsql2005setup kbsql2005engine kbexpertiseadvanced kbinfo KB917047 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: 917047
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