La registrazione di SQL Server 7.0, SQL Server 2000 e SQL Server 2005 e gli algoritmi di archiviazione di dati consente di estendere l'affidabilità dei dati

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

In questa pagina

Sommario

SQL Server 7.0, SQL Server 2000 e SQL Server 2005 ristrutturare e riprogettare gli algoritmi di registrazione e i dati da versioni precedenti di Microsoft SQL Server per migliorare l'affidabilità dei dati e l'integrità.

Per ulteriori informazioni sui concetti sottostanti di motori di SQL Server 7.0 e SQL Server 2000, vedere "ARIES (algoritmo per il ripristino e semantica Exploiting isolamento): un metodo di ripristino di transazioni-granularità fine supporto blocco e ripristini parziali mediante scrittura Avanti registrazione", delle transazioni di ACM nei sistemi di database. Questo documento è stato scritto da Chunder Mohan.

Questo documento consente di risolvere le tecniche per estendere l'affidabilità dei dati e l'integrità in relazione a errori di SQL Server 7.0, SQL Server 2000 e SQL Server 2005.

Si consiglia di leggere i seguenti articoli nella Microsoft Knowledge Base per ulteriori chiarimenti sulla memorizzazione nella cache e alternativo discussioni di modalità di errore:
86903Descrizione della cache del controller del disco in SQL Server
46091Utilizzando la cache di controller del disco rigido con SQL Server
234656Utilizzando la cache del disco con SQL Server

Informazioni

Prima di iniziare la discussione approfondita, alcuni dei termini utilizzati in questo articolo vengono definiti nella sezione seguente.
Riduci questa tabellaEspandi questa tabella
TermineDefinizione
Supporto batteria Batteria separato e localizzate funzionalità di backup disponibili direttamente e controllata dal meccanismo di memorizzazione nella cache per evitare la perdita di dati.
Nota Non si tratta di un gruppo di continuità (UPS). Un gruppo di continuità non garantisce alcuna attività di scrittura e può essere disconnessi dalla periferica di memorizzazione nella cache.
Cache Meccanismo di archiviazione intermedia utilizzato per ottimizzare le operazioni di I/O fisiche e migliorare le prestazioni.
Pagina dirty Pagina contenente modifiche di dati che devono ancora essere scaricate all'archiviazione stabile. Per ulteriori informazioni relative a un buffer di pagina dirty, consulta la documentazione in linea di SQL Server.
Errore Qualsiasi cosa che potrebbe causare un'interruzione imprevista del processo di SQL Server. Di seguito sono riportati alcuni esempi: interruzione, reimpostazione di computer, errori di memoria, altri problemi hardware, settori danneggiati, interruzioni di unità, errori del sistema operativo, e così via.
Svuotamento Forzato di un buffer di cache per stabile di archiviazione.
Latch Oggetto di sincronizzazione utilizzato per proteggere la consistenza fisica di una risorsa.
Archiviazione non volatile Qualsiasi supporto che rimane disponibile tra gli errori di sistema.
Pagina bloccata Pagina che rimane nei dati nella cache e non possono essere scaricate archiviazione stabile fino a quando tutti i record log associato sono protetti in un percorso di archiviazione stabile.
Archiviazione stabile Come archiviazione non volatile.
Memoria volatile Qualsiasi supporto che non rimangono invariate in caso di errori.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, le versioni precedenti di SQL Server e molti database principali prodotti sul mercato oggi utilizzano il protocollo di registrazione scrittura in avanti (WAL).

Protocollo di registrazione write-ahead (WAL)

Il protocollo di termine è un metodo eccellente per descrivere WAL. È una specifica ed insieme definito di passaggi di implementazione necessari per assicurare i dati è memorizzata scambiati correttamente e possono essere recuperate uno stato noto in caso di errore. Proprio come una rete contiene un protocollo definito scambio di dati in modo coerenza e protetto, in modo troppo il WAL descrivere il protocollo per proteggere i dati.

Il documento di ARIES definisce il WAL come:
Il protocollo WAL asserisce che i record del log che rappresentano modifiche ad alcuni dati devono essere già in archiviazione stabile prima che i dati modificati possa sostituire la versione precedente dei dati di archiviazione non volatile. Vale a dire il sistema non è consentito scrivere una pagina aggiornata la versione di archiviazione non volatile della pagina fino almeno le parti di annullamento del record di log che descrivono gli aggiornamenti per la pagina sono stati scritti stabile di archiviazione.
Per ulteriori informazioni sulla registrazione di scrittura in avanti, consultare la documentazione in linea di SQL Server.

SQL Server e il WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 e versioni precedenti di SQL Server utilizzano il protocollo WAL. Per garantire la corretta committal di una transazione, tutti i record associati alla transazione del log devono essere protetto nell'archiviazione stabile.

Per chiarire questo, considerare l'esempio di specifico seguente (per questo esempio si supponga che nessun indice e che la pagina interessata è pagina 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
ora suddividere l'attività in operazioni di registrazione semplice:
Riduci questa tabellaEspandi questa tabella
IstruzioneAzioni eseguite
INIZIO TRANSAZIONE Scrivere l'area della cache di registro ma non è necessario scaricare archiviazione stabile perché SQL Server non dispone di eventuali modifiche fisiche.
INSERT INTO tblTest1. I dati pagina 150 vengono recuperati nella cache di dati di SQL Server, se non è già disponibile.

2. Nella pagina è latch , bloccati e contrassegnata come dirty e vengono ottenuti i blocchi appropriati.

3. Un record di log di inserimento viene creato e aggiunto la cache del registro.

4. Una nuova riga viene aggiunta alla pagina di dati.

5. Il latch viene rilasciato.

6. I record del log è associate alla transazione o non è necessario essere scaricate a questo punto, poiché tutte le modifiche rimangono nella memoria volatile pagina.
COMMIT DELLA TRANSAZIONE1. Un record di log commit non è valido e i record del log associati alla transazione devono essere scritto stabile di archiviazione. La transazione non è considerata il commit fino a quando i record di log vengono assegnati correttamente archiviazione stabile.

2. Dati 150 pagina rimangono nella cache di dati di SQL Server e non viene svuotati immediatamente archiviazione stabile. Quando i record di log sono correttamente ripristino protetto possibile ripetere l'operazione se necessario.

3. Transazionali i blocchi vengono rilasciati.
Non essere confuso con il blocco e registrazione. Sebbene sia importante, blocco e registrazione sono problemi distinti quando si utilizzano il WAL. Nell'esempio sopra riportato, SQL Server 7.0, SQL Server 2000 e SQL Server 2005 in genere tenere il latch nella pagina 150 per il tempo necessario per eseguire le modifiche di inserimento fisico nella pagina, non l'intera ora della transazione. Il tipo di blocco appropriato viene stabilito per proteggere la riga, intervallo, pagina o tabella come necessario. Vedere le sezioni blocco documentazione per ulteriori informazioni sui tipi di blocco.

Osservando l'esempio in modo più dettagliato, si potrebbe chiedere cosa accade quando eseguire i processi di LazyWriter o di CheckPoint. SQL Server 7.0, SQL Server 2000 e SQL Server 2005 consente di rilasciare tutte le cancellazioni appropriati per stabile di archiviazione per i record di registro delle transazioni associati alla pagina dirty e bloccata. In questo modo il protocollo WAL che non è possibile scrivere una pagina di dati per stabile archiviazione fino a che record di log transazione associata è stato svuotato.

Archiviazione di SQL Server e stabile

SQL Server 7.0, SQL Server 2000 e SQL Server 2005 è possibile migliorare le operazioni di pagina di registro e dati includendo la conoscenza di dimensioni di settore del disco (comunemente 512 byte).

Per mantenere le proprietà di una transazione ACID, SQL Server necessario considerare punti di errore. Durante un errore di molte unità disco specifiche garantiscono solo una quantità limitata di operazioni di scrittura del settore. La maggior parte delle specifiche garantiscono il completamento di una scrittura di settore singolo quando si verifica un errore.

SQL Server 7.0, SQL Server 2000 e SQL Server 2005 è possibile utilizzare le pagine di dati di 8 KB e il registro (se scaricato) in multipli della dimensione del settore. (La maggior parte delle unità disco utilizzare 512 byte come la dimensione del settore). In caso di errore, SQL Server può rappresentare per le operazioni di scrittura superiore a un settore mediante l'utilizzo di registro parità e tecniche di scrittura incompleta.

Torn page detection

Nella sezione seguente proviene da in linea di SQL Server 7.0 documentazione che descrive torn page detection:
Questa opzione consente a SQL Server di rilevare operazioni di I/O incomplete causate da interruzioni dell'alimentazione o da altre interruzioni di sistema. Se è impostata su true, viene creato un bit debba essere capovolta per ogni settore di 512 byte in una pagina di database di 8 kilobyte (KB) ogni volta che la pagina viene scritta su disco. Se un bit è nello stato errato quando la pagina è successiva lettura da SQL Server, quindi la pagina è stata scritta in modo non corretto, viene rilevata una pagina incompleta. Le pagine incomplete in genere vengono rilevate durante il ripristino perché probabilmente da leggere dal ripristino qualsiasi pagina che è stato scritto correttamente.

Anche se le pagine di database di SQL Server sono di 8 KB, dischi eseguire operazioni di I/O utilizzando un settore di 512 byte. Di conseguenza, vengono scritti i 16 settori per pagina di database. Una pagina incompleta può verificarsi se il sistema errore (ad esempio, a causa dell'alimentazione) tra l'ora che del sistema operativo scrive il primo settore di 512 byte su disco e il completamento dell'operazione I/O di 8 KB. Se il primo settore di una pagina di database è scritta correttamente prima dell'errore, pagina del database sul disco verrà visualizzata come aggiornamento, anche se potrebbe non è riuscita.

Utilizzo delle cache del controller di disco batteria può garantire che i dati correttamente siano scritti su disco o non scritto affatto. In questo caso, per evitare non impostare torn page detection su true, per non è più necessaria.
Nota Torn page detection non è attivato per impostazione predefinita in SQL Server 7.0. Vedere sp_dboption per l'abilitazione del rilevamento nel sistema.

Registro parità

Controllo della parità di log è molto simile al rilevamento pagine incomplete. Ogni settore di 512 byte contiene bit di parità. Questi bit di parità vengono sempre scritti con il record del log e valutati quando viene recuperato il record del registro. Per imporre registro scritto su un limite di 512 byte, SQL Server 7.0, SQL Server 2000 e SQL Server 2005 possibile garantire che le operazioni di committal completamente vengono scritti i settori di disco fisico.

Le modifiche forniscono coerenza dei dati maggiore, anche su versioni precedenti di SQL Server.

Versioni di SQL Server precedenti alla 7.0

Alla 7.0 versioni precedenti di SQL Server non hanno fornito registro parità o funzionalità di rilevamento di bit incompleta. Infatti, tali versioni possono scrivere la stessa pagina registro più volte fino a riempire di record di log la pagina di registro da 2 KB. Questo può esporre le transazioni che hanno eseguito il commit correttamente. Se la pagina di registro è viene riscritto durante un errore, un settore con la transazione di cui è stato eseguito il commit potrebbe non ottenere riscritto correttamente.

Impatto sulle prestazioni

Tutte le versioni di SQL Server aprire i file di registro e i dati utilizzando la funzione CreateFile di Win32. Il membro dwFlagsAndAttributes include un'opzione FILE_FLAG_WRITE_THROUGH apertura da SQL Server.
FILE_FLAG_WRITE_THROUGH
Indica al sistema per scrivere a tutte le cache intermedie e accedere direttamente al disco. Il sistema è ancora possibile memorizzare le operazioni di scrittura, ma lentamente Impossibile svuotare.

L'opzione FILE_FLAG_WRITE_THROUGH garantisce che, quando un scrittura operazione restituisce completamento che i dati correttamente vengono memorizzati nell'archivio stabile. Questo consente di allineare con il protocollo WAL verifica i dati.
Numero di unità (SCSI e IDE) contiene cache incorporate di 512 KB, 1 MB o superiore. Tuttavia, le cache dell'unità in genere basano su un condensatore e non una soluzione batteria. Questi meccanismi di caching non garantisce il ciclo scrive in un risparmio di energia o punto di errore simile. Solo garantisce il completamento di operazioni di scrittura del settore. Si tratta in particolare perché la scrittura incompleta e il rilevamento di parità di registro sono stati realizzati in SQL Server 7.0, SQL Server 2000 e SQL Server 2005. Come le unità continuano a crescere in dimensioni, le cache diventano più grandi e possibile espongono grandi quantità di dati durante un errore.

Molti fornitori di hardware offrono soluzioni di controller di disco batteria. Cache questi controller possono essere di gestire i dati nella cache per diversi giorni e consentono anche l'hardware di memorizzazione nella cache per essere inserito in un secondo computer. Quando risparmio di energia viene ripristinato correttamente, i dati unwritten completamente viene svuotati prima di consentire l'accesso ai dati ulteriore. Molti dei quali consentono una percentuale di lettura e la cache in scrittura per stabilire per ottenere prestazioni ottimali. Alcuni contenuti di aree di archiviazione di grandi quantità di memoria. Infatti, per un segmento molto specifico del mercato, alcuni fornitori di hardware forniscono la cache di sistemi di controller con 6 GB di cache disco batteria fascia alta. Questi può migliorare significativamente le prestazioni del database.

Avanzate implementazioni di memorizzazione nella cache verrà handle il FILE_FLAG_WRITE_THROUGH richiesta non disattivando la cache del controller perché garantiscono true riscrivere funzionalità in caso di un riavvio del sistema, interruzione dell'alimentazione elettrica o altro punto di errore.

È possibile aumentare notevolmente a causa di meccanico tempo necessario per spostare le testine di unità, i tassi di selezione e altri fattori limitanti trasferimenti di I/O senza l'utilizzo di una cache.

Ordinamento del settore

Una tecnica comune utilizzata per aumentare le prestazioni di I/O è è settore ordinamento. Per evitare di spostamento head meccanico sono ordinate le richieste di lettura/scrittura, consentendo un movimento della testina per recuperare o memorizzare i dati di più coerenza.

La cache può contenere più di registro e dati scrittura richieste nello stesso momento. Il protocollo WAL e l'implementazione di SQL Server del protocollo WAL richiedono lo svuotamento del log scrive stabile di archiviazione prima dell'emissione della scrittura della pagina. Utilizzo della cache tuttavia potrebbe restituire successo da una richiesta di scrittura registro senza i dati scritti l'unità effettiva (che è, scritta stabile di archiviazione). Questo può causare a emissione della richiesta di scrittura della pagina dati di SQL Server.

Con il coinvolgimento di cache di scrittura, i dati vengono comunque considerati in archiviazione volatili. Tuttavia, dalla chiamata Win32 API WriteFile , esattamente come in SQL Server vede l'attività, un codice restituito riuscito è stato ottenuto. SQL Server o qualsiasi processo utilizzando il chiamata di API WriteFile può solo dedurre i dati correttamente ha ottenuto archiviazione stabile.

Per motivi di discussione, supponga che tutti i settori della pagina di dati sono ordinati da scrivere prima i settori dei record di log corrispondente. Questo viola immediatamente il protocollo WAL. La cache scrive una pagina di dati prima i record del log. Se la cache non è completamente batteria, un'eventuale potrebbe causare risultati irreversibili.

Valutare i fattori di ottenere prestazioni ottimali per un server di database, esistono molti fattori da considerare. Il principale di queste considerazioni è "Mio sistema Consenti funzionalità FILE_FLAG_WRITE_THROUGH valida?"

Nota Si utilizza necessario completamente tutte le cache supporta una soluzione a batteria. Tutte le altri meccanismi di memorizzazione nella cache sono di sospetto danneggiamento dei dati e la perdita di dati. SQL Server rende massimo per garantire il WAL attivando FILE_FLAG_WRITE_THROUGH.

Test hanno dimostrato che molte configurazioni di unità disco possono contenere write-behind senza batteria appropriato di backup. Unità SCSI, IDE ed EIDE sfruttare appieno le cache di scrittura.

In molte configurazioni, l'unico modo per disattivare correttamente la cache in scrittura di un'unità IDE o EIDE consiste con un'utilità del produttore o ponticelli presente sull'unità stessa. Per garantire che la cache in scrittura sia disattivata per l'unità stessa, contattare il produttore di unità.

Unità SCSI dispongono anche di cache di scrittura, ma questi cache comunemente possono essere disabilitate dal sistema operativo. Se è presente delle domande, contattare il produttore di unità per utilità appropriata.

Scrivere la sovrapposizione di cache

Scrivere la che sovrapposizione di cache è simile a ordinamento settore. Direttamente da un sito Web produttore di unità IDE iniziale è stata scattata la seguente definizione:
In genere, questa modalità è attiva. Scrivere la modalità cache accetta che l'host scrivere dati nel buffer fino a quando il buffer viene completo o il trasferimento di host è stato completato.

Un'attività di scrittura del disco si inizia a memorizzare i dati host su disco. I comandi di scrittura di host continuano a essere accettati e dati trasferiti nel buffer finché non lo stack del comando di scrittura è completo o il buffer di dati è pieno non. L'unità potrebbe riordinare i comandi di scrittura per ottimizzare la velocità effettiva unità.

Riassegnazione automatica di scrittura (AWR)

Altri tecnica comune utilizzata per proteggere i dati è rilevare i settori danneggiati durante la manipolazione dei dati. La spiegazione seguente proviene da stesso iniziale IDE unità produttore sito Web:
Questa funzionalità fa parte della cache di scrittura e riduce il rischio di perdita di dati durante le operazioni di posticipata di scrittura. Se si verifica un errore di disco durante il processo di scrittura del disco, l'attività di disco viene interrotta e il settore sospetto viene riallocata per un pool di settori alternativi situato alla fine dell'unità. Dopo la riassegnazione, l'attività di scrittura di disco continua fino al completamento.
Può trattarsi di una funzionalità molto potente se batteria di backup viene fornita per la cache, consentendo la modifica corretta dopo il riavvio. È preferibile per rilevare gli errori del disco, ma la protezione dei dati del protocollo WAL richiede nuovamente per essere eseguita a tempo reale e non in modo posticipato. Nei parametri WAL, la tecnica AWR Impossibile account per una situazione in cui ha esito negativo una scrittura registro a causa di un errore di settore ma l'unità è piena. Il motore di database deve immediatamente conoscere l'errore in modo che la transazione può essere correttamente interrotta, l'amministratore può ricevere un avviso e di appropriate misure intraprese per proteggere i dati e correggere la situazione di errore di supporto.

Garantire la protezione dei dati

Esistono diverse precauzioni che un amministratore di database deve adottare per garantire la sicurezza dei dati.
  • È sempre buona norma assicurarsi che la strategia di backup sia sufficiente per il ripristino da un errore irreversibile. Archiviazione fuori sede e altre precauzioni sono appropriate.
  • Verificare che l'operazione di ripristino del database in un database secondario o il test database a intervalli frequenti.
  • Assicurarsi che le periferiche di memorizzazione nella cache possono gestire tutte le situazioni di errore (interruzione dell'alimentazione, settori, unità non valida, interruzione del sistema, lockups, alimentazione Raccoglitore e così via).
  • Verificare che il dispositivo di memorizzazione nella cache:
    • È stato integrato batteria di backup.
    • Nuova edizione possibile scrive sul risparmio di energia.
    • Può essere completamente disattivato, se necessario.
    • Gestisce il settore rimappatura in tempo reale.
  • Attivare il rilevamento pagine incomplete; piccolo impatto sulle prestazioni.
  • Configurare le unità RAID consentendo un scambio a caldo di un'unità disco non valida, se possibile.
  • Utilizzare i controller di memorizzazione nella cache più recenti che consentono l'aggiunta di spazio su disco senza riavviare il sistema operativo. Può trattarsi di una soluzione ideale.

Test di unità

Per proteggere completamente i dati, è necessario assicurarsi che la memorizzazione di tutti i dati nella cache viene gestito correttamente. In molti casi, ciò significa che è necessario disattivare la cache in scrittura dell'unità disco.

Nota Assicurarsi che un meccanismo di memorizzazione nella cache alternativo correttamente grado di gestire più tipi di errore.

Microsoft ha eseguito test su più unità SCSI e IDE mediante l'utilità SQLIOStress . Questa utilità simula attività ad alta densità lettura/scrittura asincrona per una periferica di dati simulati e la periferica del file di registro. Statistiche di prestazioni di test indicano le operazioni di scrittura Media al secondo, compreso tra 50 e 70 per un'unità con la cache in scrittura disattivato e un intervallo RPM tra 5,200 e 7,200.

Per ulteriori informazioni e per dettagli sull'utilità SQLIOStress , vedere il seguente articolo della Microsoft Knowledge Base riportato di seguito:
231619Come utilizzare l'utilità SQLIOStress per sottolineare un sottosistema di disco, ad esempio SQL Server
Molti produttori di computer (ad esempio, Compaq, Dell, gateway, HP e così via) consente di ordinare le unità con disabilitata la cache di scrittura. Tuttavia, test indica che questo potrebbe non essere sempre caso sempre verificare completamente.

I dispositivi di dati

In situazioni tutti ma non registrate, SQL Server richiede solo i record di registro per essere scaricate. Quando si effettuano operazioni non registrate, le pagine di dati inoltre devono essere svuotate all'archiviazione stabile, nessun record di log per rigenerare le azioni in caso di un errore.

Le pagine di dati possono rimangono nella finestra di cache fino a quando il processo LazyWriter o CheckPoint li scarica archiviazione stabile. L'utilizzo del protocollo WAL per garantire che i record di log siano memorizzati correttamente garantisce che ripristino possibile recuperare una pagina di dati a uno stato conosciuto.

Ciò non significa che è consigliabile memorizzare file di dati su un'unità memorizzato nella cache. Quando SQL Server elimina le pagine di dati per stabile di archiviazione, è possono troncare i record di log dal log delle transazioni. Se le pagine di dati sono memorizzate nella cache volatile, è possibile troncare i record del log da utilizzare per recuperare una pagina in caso di errore. Assicurarsi di dispositivi di dati e il Registro di gestire archiviazione stabile correttamente.

Miglioramento delle prestazioni

La domanda iniziale che si verifica è: "si dispone di un'unità IDE è stato memorizzazione nella cache, ma quando è disattivato,, le prestazioni sono significativamente inferiore a previsto--perché?"

Molte delle unità IDE testate da Microsoft eseguire con un tasso di RPM del 5,200 e SCSI l'unità in un RPM di 7,200. Quando si disattiva la scrittura nella cache dell'unità IDE le prestazioni meccaniche possono diventare un fattore.

Non vi è un'area molto chiara per risolvere la differenza di prestazioni: "Address" la frequenza delle transazioni.

Esistono molti sistemi online transaction processing (OLTP, Online Transaction Processing) che richiedono una velocità di transazione elevato. Per questi sistemi, si consiglia di utilizzare un controller di memorizzazione nella cache che supporti una cache di scrittura correttamente e fornire l'incremento delle prestazioni assicurando l'integrità dei dati.

Per la verifica in modo significativo le prestazioni (modifiche) con SQL Server in un'unità di memorizzazione nella cache, la frequenza delle transazioni è stata aumentata utilizzano transazioni piccole.

Test, viene illustrato che attività di scrittura elevato di buffer inferiore 512 KB o superiore a 2 MB può causare il rallentamento delle prestazioni.
Si consideri l'esempio riportato di seguito:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
   INSERT INTO tblTest VALUES ('Test')
				
di seguito è risultati di test di esempio per SQL Server:
Secondi SCSI(7200 RPM) 84
SCSI(7200 RPM) 15 secondi (controller cache)

14 IDE(5200 RPM) secondi (cache veloce attivata)
IDE(5200 RPM) 160 secondi
Ritorno a capo l'intera serie di operazioni INSERT in una singola transazione esegue in secondi circa 4 in tutte le configurazioni.

Il motivo è il numero di cancellazioni di registro necessari. Senza la transazione, ogni INSERT è una transazione di per sé e ogni volta che i record del log per la transazione devono essere svuotati. Ogni svuotamento è di 512 byte di dimensioni, che richiede l'intervento dell'unità meccanico significativo.

Quando viene utilizzata una singola transazione, i record del log per la transazione possono essere combinati e una scrittura singola, più grande può essere utilizzata per cancellare i record del log raccolti. L'intervento meccanico è notevolmente ridotto.

avviso Non è consigliabile aumentare l'ambito della transazione. Transazioni a esecuzione prolungata possono portare a blocco eccessivo e indesiderato, nonché aumento di overhead. È possibile utilizzare SQL Server 7.0, SQL Server 2000 e contatori di SQL Server 2005 Database di SQL Server: per visualizzare i contatori di basato su un log delle transazioni. In particolare, scaricamento log byte/sec può indicare molte transazioni di piccole con attività del disco meccanico elevato.

Esaminare le istruzioni associate nel Registro di svuotamento e determinare se è possibile ridurre il numero di cancellazioni di registro. Nell'esempio precedente è stata implementata una singola transazione. Tuttavia, in molti scenari si può verificare un comportamento di blocco indesiderato. Esaminare la struttura di transazione. Probabilmente qualcosa come seguenti per eseguire il batch per ridurre il log frequente e le piccolo implica lo svuotamento attività:
BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
   INSERT INTO tblTest VALUES ('Test')

   if(0 = cast(@@IDENTITY as int) % 10)
   BEGIN
      PRINT 'Commit tran batch'
      COMMIT TRAN
      BEGIN TRAN
   END
END
GO

COMMIT TRAN
GO
				
SQL Server 6. x potrebbe non essere possibile visualizzare lo stesso impatto sulle prestazioni da frequenti e scrive del log delle transazioni di piccole dimensioni. SQL Server 6. x riscrive la stessa pagina registro da 2 KB, in quanto è stato eseguito il commit di transazioni di. Questo può ridurre le dimensioni del log in modo significativo rispetto agli svuotamenti del limite del settore di 512 byte in SQL Server 7.0, SQL Server 2000 e SQL Server 2005. Ridurre le dimensioni del log direttamente si riferisce la quantità di attività dell'unità meccanico. Tuttavia, come illustrato sopra, SQL Server 6. x algoritmo potrebbe esporre le transazioni di cui è stato eseguito il commit.
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: 230785 - Ultima modifica: giovedì 9 febbraio 2006 - Revisione: 5.3
Le informazioni in questo articolo si applicano a:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Chiavi: 
kbmt kbhowto kbinfo KB230785 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: 230785
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