次の方法で共有

Manutenzione del database in Exchange 2010

  • [アーティクル]

Articolo originale pubblicato mercoledì 14 dicembre 2011

Negli ultimi mesi si è molto parlato della manutenzione in background del database e del perché sia importante per i database di Exchange 2010. Confidiamo che questo articolo contenga le risposte che cercate.

Quali attività di manutenzione devono essere eseguite sul database?

Le attività elencate di seguito devono essere regolarmente eseguite sui database di Exchange:

Compattazione del database

Lo scopo principale della compattazione del database è quello di rendere nuovamente disponibile lo spazio inutilizzato all'interno del file di database (anche se tale spazio inutilizzato non viene restituito al file system). L'obiettivo è quello di rendere disponibili le pagine del database compattando i record nel minor numero possibile di pagine, riducendo così la quantità di I/O necessario. Questa operazione viene eseguita dal motore di database ESE (Extensible Storage Engine) utilizzando i metadati del database, ovvero le informazioni presenti nel database che descrivono le tabelle, visitando le pagine di ogni tabella e tentando di spostare i record in pagine ordinate in modo logico.

Riuscire a mantenere ordinato il footprint di un file di database è importante per diversi motivi, tra cui:

  1. Ridurre il tempo associato al backup del file di database
  2. Mantenere dimensioni prevedibili del file di database, molto importante per il ridimensionamento a livello di server e archiviazione.

Nelle versioni precedenti a Exchange 2010 le operazioni di compattazione del database vengono eseguite durante la manutenzione online. Nel corso di questo processo, durante lo scorrimento del database e il riordinamento dei record tra le pagine, viene generata un'attività di I/O casuale. Al termine del processo le pagine risultano pertanto sempre in ordine casuale. Data l'architettura dello schema di archiviazione, qualsiasi richiesta di un set di dati, come il download di elementi in una cartella, produce sempre un'attività di I/O casuale.

In Exchange 2010 la compattazione del database è stata riprogettata in modo che la contiguità sia prioritaria rispetto alla compattazione dello spazio. È stata inoltre rimossa dalla manutenzione online e resa un processo in background sempre in esecuzione.

Deframmentazione del database

La deframmentazione del database, novità di Exchange 2010, è anche nota come deframmentazione della struttura B+ e v2 OLD (Online Defragmentation). La sua funzione consiste nel compattare e deframmentare, ovvero rendere sequenziali, le tabelle del database che sono state contrassegnate/indicate come sequenziali. La deframmentazione del database è importante per mantenere nel tempo un utilizzo efficiente delle risorse del disco (rendere l'I/O più sequenziale e meno casuale), nonché conservare la compattezza delle tabelle contrassegnate come sequenziali.

La deframmentazione del database può essere intesa come un processo di monitoraggio delle operazioni sulle pagine del database per stabilire se sia necessario intervenire o meno. Lo scopo è quello di individuare tutte le pagine disponibili nelle tabelle. Qualora una tabella raggiunga una soglia in cui una percentuale particolarmente significativa del conteggio pagine totale della struttura B+ è disponibile, le pagine disponibili vengono restituite alla radice. Contemporaneamente viene mantenuta la contiguità all'interno di un set di tabelle con hint spaziale sequenziale (una tabella creata con un modello di utilizzo sequenziale). Se durante la deframmentazione del database viene rilevata un'analisi/pre-lettura su una tabella sequenziale e i record non sono archiviati in pagine sequenziali, questa sezione della tabella viene deframmentata e tutte le pagine interessate vengono spostate in un nuovo extent nella struttura B+. È possibile utilizzare i contatori delle prestazioni (citati nella sezione relativa al monitoraggio) per notare come la deframmentazione del database non sia praticamente necessaria dopo avere raggiunto uno stato stazionario.

La deframmentazione del database è un processo in background durante il quale viene eseguita un'analisi continua del database durante l'esecuzione delle operazioni e vengono avviate le attività asincrone eventualmente necessarie. La deframmentazione del database viene limitata in due scenari:

  1. Numero massimo di attività in attesa In questo modo si impedisce che l'attività di deframmentazione del database diventi troppo intensa al primo passaggio qualora sia stato apportato un numero elevato di modifiche.
  2. Limitazione della latenza di 100 ms In caso di sovraccarico del sistema, l'attività di deframmentazione del database viene bloccata e ripresa all'esecuzione successiva dello stesso schema operativo. Non è disponibile alcuno strumento che memorizzi quali attività di deframmentazione sono state bloccate e che le riprenda nel momento in cui sarà disponibile un maggior numero di risorse.

Checksum del database

Il checksum del database (noto anche come Online Database Scanning) è il processo durante il quale il database viene letto in blocchi di grandi dimensioni e ogni pagina viene sottoposta a checksum, ovvero analizzata per rilevare eventuali pagine fisiche danneggiate. Lo scopo principale del checksum è quello di rilevare i danni fisici e i flush persi che potrebbero non venire rilevati dalle operazioni transazionali (pagine non aggiornate).

In Exchange 2007 RTM e tutte le versioni precedenti, le operazioni di checksum vengono eseguite durante il processo di backup. Ciò costituisce un problema per i database replicati perché l'unica copia da sottoporre a checksum è la copia di cui viene eseguito il backup. Di conseguenza, se è la copia passiva a essere sottoposta a backup, la copia attiva non verrà sottoposta a checksum. In Exchange 2007 SP1 è stata introdotta una nuova attività di manutenzione online facoltativa, Online Maintenance Checksum (per ulteriori informazioni, vedere il blog relativo alle modifiche ESE in Exchange 2007 SP1, parte 2 Exchange 2007 SP1 ESE Changes – Part 2.

In Exchange 2010 il checksum del database viene eseguito e vengono eseguite le operazioni successive all'arresto anomalo dell'archivio di Exchange 2010. L'arresto anomalo può essere causa della perdita di spazio il quale viene rilevato e recuperato dall'analisi del database online. Tramite il checksum vengono letti approssimativamente 5 MB al secondo per ogni database sottoposto attivamente ad analisi (sia copie attive che passive) utilizzando I/O da 256 KB. L'I/O è sequenziale al 100 percento. Il sistema di Exchange 2010 è stato progettato ritenendo che ogni database venga analizzato completamente ogni sette giorni.

Se l'analisi richiede più di sette giorni, viene registrato un avviso nel registro applicazioni:

Event ID: 733
Event Type: Information
Event Source: ESE
Description: Information Store (15964) MDB01: Online Maintenance Database Checksumming background task is NOT finishing on time for database 'd:\mdb\mdb01.edb'. This pass started on 11/10/2011 and has been running for 604800 seconds (over 7 days) so far.

Se l'analisi della copia attiva del database richiede più di sette giorni, al termine dell'analisi verrà registrata la voce seguente nel registro applicazioni:

Event ID: 735
Event Type: Information
Event Source: ESE
Description: Information Store (15964) MDB01 Database Maintenance has completed a full pass on database 'd:\mdb\mdb01.edb'. This pass started on 11/10/2011 and ran for a total of 777600 seconds. This database maintenance task exceeded the 7 day maintenance completion threshold. One or more of the following actions should be taken: increase the IO performance/throughput of the volume hosting the database, reduce the database size, and/or reduce non-database maintenance IO.

Se l'analisi richiede più di sette giorni, viene registrato un avviso nel registro applicazioni.

In Exchange 2010 sono ora disponibili due modi per eseguire il checksum del database sulle copie attive del database:

  1. Esecuzione in background 24×7 Si tratta del comportamento predefinito. Può essere utilizzato per tutti i database, in particolar modo per i database di dimensioni superiori a 1 TB. Il database viene analizzato non più di una volta al giorno. Questo I/O di lettura è sequenziale al 100 percento (cosa che lo rende più semplice sul disco) e corrisponde a una velocità di analisi di circa 5 megabyte (MB) al secondo nella maggior parte dei sistemi. Il processo di analisi è a thread singolo ed è limitato dalla latenza di I/O. Maggiore è la latenza, minore è la velocità del processo di checksum del database poiché trascorre un periodo di attesa più lungo dopo il completamento dell'ultimo batch e prima dell'emissione di una nuova analisi batch di pagine (lettura contemporanea di 8 pagine).
  2. Esecuzione durante il processo di manutenzione del database delle cassette postali pianificato Quando si seleziona questa opzione, il checksum del database è l'ultima attività. È possibile configurarne la durata modificando la pianificazione della manutenzione del database delle cassette postali. Questa opzione deve essere utilizzata solo con i database di dimensioni inferiori a 1 terabyte (TB), per i quali un'analisi completa richiede una minore quantità di tempo.

Indipendentemente dalle dimensioni del database, è consigliabile attenersi al comportamento predefinito e non configurare le operazioni di checksum sul database attivo come processo pianificato (non configurarlo come processo all'interno della manutenzione online).

Per le copie passive del database, i checksum del database vengono eseguiti durante il runtime, continuamente in background.

Applicazione di patch alle pagine

L'applicazione di patch alle pagine è il processo in cui le pagine danneggiate vengono sostituite con copie integre. Come descritto in precedenza, il rilevamento delle pagine danneggiate è una funzione del checksum del database (le pagine danneggiate vengono anche rilevate durante la fase di esecuzione quando le pagine vengono archiviate nella cache del database). L'applicazione delle patch alle pagine è particolarmente adatta per le copie di database altamente disponibili (HA, highly-available). La modalità di ripristino di una pagina danneggiata varia a seconda che la copia del database altamente disponibile sia attiva o passiva.

Processo di applicazione delle patch alle pagine

Sulle copie attive del database Sulle copie passive del database
  1. Viene rilevata una pagina danneggiata.
  2. Nel file di registro attivo viene scritto un indicatore che segnala il numero della pagina danneggiata che deve essere sostituita.
  3. Viene aggiunta una voce all'elenco di richieste di patch per le pagine.
  4. Il file di registro attivo viene chiuso.
  5. Il file di registro viene inviato dal servizio Replica alle copie passive del database.
  6. controllato.
  7. L'Archivio informazioni nel server di destinazione riesegue il file di registro fino all'indicatore, recupera la versione integra della pagina, richiama il callback del servizio di riesecuzione e invia la pagina al server Cassette postali di origine.
  8. Il server Cassette postali di origine riceve la versione integra della pagina, conferma la presenza di una voce nell'elenco di richieste di patch per le pagine, quindi scrive la pagina nel buffer del registro. La pagina viene inserita nella cache del database.
  9. La voce corrispondente nell'elenco di richieste di patch per le pagine viene rimossa.
  10. A questo punto, l'applicazione delle patch al database viene considerata completata (in un momento successivo il checkpoint avanzerà, il contenuto della cache del database verrà rimosso e la pagina danneggiata sul disco verrà sovrascritta).
  11. Qualsiasi altra copia della pagina (ricevuta da un'altra copia passiva) verrà eliminata automaticamente perché nessuna voce corrispondente verrà rilevata nell'elenco di richieste di patch per le pagine.
  1. Nel server Cassette postali in cui viene rilevata la pagina danneggiata, la riesecuzione del registro viene sospesa per la copia del database interessata.
  2. Attraverso il coordinamento con il server Cassette postali che ospita la copia attiva del database, il servizio Replica recupera le pagine danneggiate e l'intervallo del registro necessario dall'intestazione del database della copia attiva.
  3. Il server Cassette postali aggiorna l'intestazione del database per la copia interessata del database, inserendo il nuovo intervallo di registro necessario.
  4. Il server Cassette postali indica al server Cassette postali che ospita la copia attiva del database i file di registro necessari.
  5. Il server Cassette postali riceve i file di registro necessari e li controlla.
  6. Il server Cassette postali inserisce le versioni integre delle pagine del database recuperate dalla copia attiva del database. Le pagine vengono scritte nel buffer di registro e, di conseguenza, vengono inserite nella cache del database.
  7. Il server Cassette postali riprende la riesecuzione del registro.

Azzeramento delle pagine

L'azzeramento delle pagine del database è il processo attraverso il quale le pagine eliminate del database vengono sovrascritte con un modello (azzerate) come misura di sicurezza, cosa che rende il rilevamento dei dati molto più complesso.

In Exchange 2007 RTM e tutte le versioni precedenti le operazioni di azzeramento delle pagine vengono eseguite durante il processo di backup del flusso. Inoltre, proprio perché hanno luogo durante questo processo non vengono considerate operazioni registrate (l'azzeramento delle pagine non risulta nella generazione dei file di registro). Questo costituisce un problema per i database replicati poiché le pagine delle copie passive non vengono mai azzerate, mentre quelle delle copie attive solo se viene eseguito il backup del flusso. In Exchange 2007 SP1 è stata introdotta una nuova attività di manutenzione online facoltativa, Zero Database Pages during Checksum (per ulteriori informazioni, vedere il blog relativo alle modifiche ESE in Exchange 2007 SP1 Exchange 2007 SP1 ESE Changes – Part 2). Se abilitata, questa attività consente di azzerare le pagine durante la manutenzione online e di registrare le modifiche che verranno replicate nelle copie passive.

Con l'implementazione di Exchange 2007 SP1, trascorre un periodo di tempo significativo tra il momento in cui la pagina viene eliminata e quello in cui viene azzerata come conseguenza del processo di azzeramento che viene eseguito durante la manutenzione pianificata. In Exchange 2010 SP1 l'attività di azzeramento delle pagine è ora un evento di runtime in continua esecuzione con cui le pagine vengono azzerate durante la fase transazionale quando si verifica un'eliminazione definitiva.

Le pagine possono anche essere corrette durante il processo di checksum online. In questo caso, le pagine interessate sono:

  • Record eliminati che non è stato possibile correggere durante il runtime in seguito all'interruzione di determinate attività (sovraccarico del sistema) o all'arresto anomalo dell'Archivio prima che i dati vengano annullati dalle attività.
  • Tabelle eliminate e indici secondari. Quando questi elementi vengono eliminati, il relativo contenuto non viene corretto, pertanto il checksum online rileva che queste pagine non appartengono a nessun oggetto valido, per cui vengono corrette.

Per ulteriori informazioni sull'azzeramento delle pagine in Exchange 2010, vedere Informazioni sull'azzeramento delle pagine di Exchange 2010.

Perché queste attività non vengono eseguite semplicemente durante la manutenzione pianificata?

Richiedere una manutenzione pianificata per le operazioni di azzeramento delle pagine, deframmentazione del database, compattazione del database e checksum online causa problemi significativi, tra cui:

  1. Le operazioni di manutenzione pianificata rendono difficoltosa la gestione 24x7 dei data center che ospitano cassette postali appartenenti a diversi fusi orari e che hanno a disposizione pochissimo tempo per la manutenzione pianificata. Nelle versioni precedenti di Exchange la compattazione del database non dispone di meccanismi di limitazione e poiché l'I/O è soprattutto casuale, l'esperienza utente può rivelarsi particolarmente negativa.
  2. Per i database Cassette postali di Exchange 2010 distribuiti in un'archiviazione di livello inferiore, ad esempio 7.2K SATA/SAS, la larghezza di banda di I/O effettiva a disposizione del motore di database ESE per l'esecuzione della manutenzione risulta particolarmente ridotta. Si tratta di un problema poiché significa che le latenze di I/O aumenteranno durante la manutenzione, impedendo il completamento delle attività di manutenzione entro il periodo di tempo desiderato.
  3. L'utilizzo di JBOD rappresenta un'ulteriore problematica per il database in termini di verifica dei dati. Tramite l'archiviazione RAID, è comune che un controller di array esegua in background l'analisi di un determinato gruppo di dischi, individuando e riassegnando i blocchi danneggiati. Un blocco danneggiato (anche noto come settore) è un blocco su un disco che non può essere utilizzato a causa di danni permanenti, ad esempio danni fisici inflitti sulle particelle del disco. È altresì comune che un controller di array legga il disco con mirroring alternativo se è stato rilevato un blocco danneggiato sulla richiesta di lettura iniziale. Il blocco danneggiato verrà contrassegnato come "danneggiato" e i dati verranno scritti in un nuovo blocco. Questo processo non influisce in alcun modo sull'applicazione, se non per un leggero aumento della latenza di lettura sul disco. Senza RAID o un controller di array, entrambi questi metodi di monitoraggio, aggiornamento e rilevamento dei blocchi non sono disponibili. Senza RAID, sarà compito dell'applicazione (ESE) rilevare i blocchi danneggiati e porvi rimedio (checksum del database).
  4. I database di grandi dimensioni su dischi di grandi dimensioni richiedono periodi di manutenzione più lunghi per assicurare la compattezza e la sequenzialità del database.

A causa dei problemi citati in precedenza, in Exchange 2010 è fondamentale che le attività di manutenzione del database vengano rimosse da un processo pianificato e vengano eseguite durante la fase di esecuzione in background.

Queste attività in background influiranno sugli utenti finali?

Queste attività in background sono state progettate in modo che vengano limitate automaticamente in base all'attività eseguita sul database. Anche le indicazioni relative alle dimensioni dei profili di messaggi prendono in considerazione queste attività di manutenzione. L'architettura di archiviazione richiede tuttavia una progettazione molto scrupolosa. Se si intende archiviare più database nello stesso LUN o volume, assicurarsi che le dimensioni aggregate di tutti i database non superi 2 TB. Questo è dovuto al fatto che la manutenzione del database viene limitata eseguendo la serializzazione in base al numero di database/volumi presupponendo che le dimensioni aggregate non superino 2 TB.

Come si può monitorare l'efficienza di queste attività di manutenzione in background?

Nelle versioni precedenti di Exchange gli eventi nel registro applicazioni vengono utilizzati per monitorare funzioni quali la deframmentazione online. In Exchange 2010 non vengono più registrati eventi per le attività di deframmentazione e compattazione. È tuttavia possibile utilizzare i contatori di prestazioni per tenere traccia delle attività di manutenzione in background nell'oggetto MSExchange Database ==> Instances:

Contatore Descrizione
Durata manutenzione del database Numero di ore trascorse dal completamento dell'ultima manutenzione eseguita per questo database
Checksum non validi di pagine della manutenzione del database Numero di checksum di pagine che non è possibile correggere rilevati durante un passaggio di manutenzione del database
Attività di deframmentazione Conteggio delle attività di deframmentazione del database in background attualmente in esecuzione
Attività di deframmentazione completate/sec Percentuale di attività di deframmentazione del database in background completate

I contatori di azzeramento delle pagine seguenti sono disponibili nell'oggetto MSExchange Database:

Contatore Descrizione
Pagine di manutenzione database azzerate Indica il numero di pagine azzerate dal motore di database dopo che il contatore di prestazioni è stato richiamato
Pagine di manutenzione database azzerate/sec Indica la velocità alla quale le pagine vengono azzerate dal motore di database

Come si controlla lo spazio vuoto in un database?

È possibile utilizzare la Shell per controllare lo spazio vuoto disponibile in un database. Per i database Cassette postali, utilizzare:

Get-MailboxDatabase MDB1 -Status | FL AvailableNewMailboxSpace

Per i database delle cartelle pubbliche, utilizzare:

Get-PublicFolderDatabase PFDB1 –Status | FL AvailableNewMailboxSpace

Come si recupera lo spazio vuoto?

Naturalmente, dopo avere rilevato lo spazio vuoto nel database, ci si chiede come poterlo recuperare.

Molti ritengono che la risposta consista nell'eseguire una deframmentazione offline del database tramite ESEUTIL. Questa non è, tuttavia, la soluzione consigliata. Quando si esegue una deframmentazione offline si crea un database completamente nuovo e le operazioni eseguite per crearlo non vengono registrate nei registri delle transazioni. Il nuovo database dispone inoltre di una nuova firma, per cui tutte le copie ad esso associate non sono più valide.

Qualora si disponga di un database contenente una notevole quantità di spazio vuoto e non è previsto che venga recuperato dalle operazioni normali, è consigliabile:

  1. Creare un nuovo database e tutte le relative copie.
  2. Spostare tutte le cassette postali nel nuovo database.
  3. Eliminare il database originale e le copie associate.

Confusione terminologica

Gran parte della confusione è legata al termine manutenzione del database in background. Collettivamente, tutte le attività citate in precedenza compongono la manutenzione del database in background. Tuttavia, la Shell, EMC e JetStress fanno entrambi riferimento al checksum del database come manutenzione del database in background ed è la caratteristica che viene configurata tramite questi strumenti.


Figura 1: Abilitazione della manutenzione in background per un database tramite EMC

Abilitazione della manutenzione del database in background tramite la Shell:

Set-MailboxDatabase -Identity MDB1 -BackgroundDatabaseMaintenance $true


Figura 2: Esecuzione della manutenzione del database in background come parte di un test JetStress

È consigliabile disabilitare il checksum del database come attività di manutenzione in background?

Il checksum del database può diventare un'operazione di I/O alquanto gravosa se l'archiviazione non è stata progettata correttamente (anche se sequenziale) poiché esegue I/O di lettura di 256 K e genera approssimativamente 5 MB al secondo per database.

Nelle indicazioni relative all'archiviazione, è consigliabile configurare le dimensioni di striping dell'array di archiviazione (le dimensioni di striping per ogni disco di un array, note anche come dimensioni del blocco) in modo che siano pari ad almeno 256 KB.

È inoltre importante testare l'archiviazione con JetStress e assicurarsi che l'operazione di checksum del database sia inclusa nel test.

Infine, se l'esecuzione di JetStress ha esito negativo a causa del checksum del database, sono disponibili alcune opzioni:

  1. Non utilizzare lo striping  Utilizzare coppie RAID-1 o JBOD (che potrebbero richiedere modifiche a livello architetturale) e sfruttare al meglio i modelli di I/O sequenziali disponibili in Exchange 2010.

  2. Prevedere una pianificazione  Configurare il checksum del database in modo che non sia un processo in background, ma un processo pianificato. Quando il checksum del database fu implementato come processo in background, si comprese che alcuni array di archiviazione erano così ottimizzati per l'I/O casuale (o presentavano limitazioni della larghezza di banda) da non poter gestire correttamente l'I/O di lettura sequenziale. Ecco perché fu progettato per poter essere disattivato (con conseguente spostamento dell'operazione di checksum nella finestra di manutenzione).

    Se si procede in questo modo, è consigliabile limitare quanto più possibile le dimensioni dei database. Ricordare inoltre che le copie passive continueranno a eseguire il checksum del database come processo in background, pertanto sarà necessario tenere in considerazione questo aspetto nell'architettura di archiviazione. Per ulteriori informazioni su questo argomento, vedere il blog relativo alla manutenzione del database in background e Jetstress 2010 Jetstress 2010 and Background Database Maintenance.

  3. Utilizzare un'archiviazione diversa oppure migliorare le funzionalità dell'archiviazione  Scegliere un'archiviazione conforme alle Best Practices di Exchange (dimensioni di striping superiori a 256 KB).

Conclusione

Le modifiche architetturali apportate al motore di database in Exchange Server 2010 migliorano sensibilmente le prestazioni e l'affidabilità, ma modificano il comportamento delle attività di manutenzione del database rispetto alle versioni precedenti. Confidiamo che questo articolo aiuterà a illustrare il concetto di manutenzione del database in background in Exchange 2010.

Ross Smith IV
Direttore programmi Exchange
Customer Experience

Questo è un post di blog localizzato. Consultate l'articolo originale: Database Maintenance in Exchange 2010