Informazioni sull'archivio di Exchange 2010

  • Articolo

 

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2016-11-28

L'archivio di Exchange è una piattaforma di archiviazione che fornisce un'unica soluzione per la gestione di diversi tipi di informazioni in una singola infrastruttura. L'archivio di Exchange (store.exe) è l'archivio dati principale di MicrosoftExchange Server 2010.

Sommario

I database nelle edizioni di Exchange 2010

Componenti logici dell'archivio di Exchange

Struttura del file dell'archivio di Exchange

Informazioni sulla registrazione delle transazioni

Extensible Storage Engine

Integrità dell'archivio

Spazio su disco insufficiente per i registri o le unita del database

Limiti di archiviazione di Exchange

I database nelle edizioni di Exchange 2010

Exchange 2010 è disponibile in due edizioni server: Standard Edition ed Enterprise Edition. Exchange 2010 Standard Edition è progettato per soddisfare le esigenze di messaggistica e collaborazione di piccole e medie imprese e può inoltre essere appropriato per specifici ruoli di server o filiali. Exchange 2010 Enterprise Edition è progettato per le grandi imprese.

Exchange 2010 Standard Edition supporta fino a 5 database. Exchange 2010 Enterprise Edition supporta fino a 100 database.

Componenti logici dell'archivio di Exchange

I componenti principali dell'archivio di Exchange sono i database delle cassette postali e i database delle cartelle pubbliche. Tali componenti possono risiedere in un singolo server o possono essere distribuiti in più server.

I database delle cassette postali contengono dati, definizioni di dati, indici, checksum, flag e altre informazioni relative alle cassette postali in Exchange 2010. I database delle cassette postali contengono i dati riservati di un singolo utente e le cartelle delle cassette postali generate quando si crea una nuova cassetta postale per quell'utente. Un database delle cassette postali viene archiviato come un file del database di Exchange (con estensione edb).

I database delle cartelle pubbliche contengono dati, definizioni di dati, indici, checksum, flag e altre informazioni relative alle cartelle pubbliche nell'organizzazione Exchange.

In Exchange 2010 è possibile gestire le cartelle pubbliche utilizzando Exchange Management Shell. (È inoltre possibile eseguire alcune attività di gestione del database delle cartelle pubbliche in Exchange Management Console.) Per ulteriori informazioni sulla gestione delle cartelle pubbliche, vedere Gestione delle cartelle pubbliche e Informazioni sulle cartelle pubbliche.

I database nelle edizioni di Exchange 2010

Struttura del file dell'archivio di Exchange

L'archivio di Exchange viene gestito utilizzandone i componenti logici, ad esempio i database. Tuttavia, Exchange 2010 archivia i dati in un insieme di file di dati specializzato, ad esempio i file di database di Exchange (edb), i file di registrazione delle transazioni (log) e i file del checkpoint (chk). A meno che non si stia eseguendo il backup o il ripristino dei dati, solo in rari casi si ha la possibilità di interagire direttamente con questi file. Nella tabella seguente vengono descritti in dettaglio questi file.

Struttura dei file dell'archivio di Exchange

File di dati Descrizione

Exchange database (edb)

Questi file costituiscono l'archivio dati delle cassette postali. Sono accessibili direttamente da ESE (Extensible Storage Engine) e dispongono di una struttura ad albero B progettata per l'accesso rapido. Ciò consente agli utenti di accedere a qualsiasi pagina di dati all'interno di un ciclo di I/O, il che significa una velocità quadruplicata rispetto a Microsoft Exchange Server 2007. I database di Exchange sono costituito da più strutture ad albero B, con alberi complementari che interagiscono con la struttura ad albero principale mantenendo l'indicizzazione e le visualizzazioni.

Registro delle transazioni (log)

Questi file costituiscono l'archivio delle operazioni di database, quali la creazione e la modifica di un messaggio. Le transazioni salvate vengono in seguito scritte nel database stesso (in un file con estensione edb). Grazie a questa operazione tutte le transazioni completate e in corso vengono registrate per mantenere l'integrità dei dati in caso di interruzione del servizio. Ogni database dispone del proprio gruppo di registri delle transazioni.

Checkpoint (chk)

Questi file costituiscono l'archivio dei dati che indicano quando un'operazione è stata salvata correttamente nel database sul disco rigido. Exchange 2010 utilizza i file con estensione chk in modo tale che un'istanza di ESE (Extensible Storage Engine) possa automaticamente rieseguire i file di registro all'interno di un database incoerente durante il ripristino conseguente a un'interruzione del servizio, a partire dalla successiva operazione non scritta. I file chk si trovano nello stesso percorso dei file log.

I database nelle edizioni di Exchange 2010

Informazioni sulla registrazione delle transazioni

La registrazione delle transazioni in Exchange è un solido meccanismo di ripristino di ESE (Extensible Storage Engine) progettato per ripristinare in modo affidabile lo stato di coerenza di un database di Exchange dopo un arresto improvviso del database. Il meccanismo di registrazione viene utilizzato anche per il ripristino di backup in linea. In questa sezione vengono descritti i dettagli relativi alla registrazione delle transazioni in Exchange 2010, inclusa una breve descrizione della registrazione circolare.

Registrazione delle transazioni in Exchange

Prima di apportare modifiche al file di database di Exchange, in Exchange le modifiche vengono scritte in un file di registro delle transazioni. Dopo averle registrate in modo sicuro, è possibile scrivere le modifiche nel file di database. In genere, le modifiche sono disponibili per gli utenti finali subito dopo la memorizzazione nel registro delle transazioni, ma prima della scrittura nel file di database.

Exchange adotta un sistema avanzato di gestione della memoria interna ottimizzato per elevate prestazioni e in grado di gestire efficacemente la memorizzazione nella cache di decine di gigabyte(GB) di pagine di database. La scrittura fisica delle modifiche nel file di database è un'attività con bassa priorità durante le normali operazioni.

Se un database si arresta improvvisamente, le modifiche memorizzate nella cache non andranno perdute solo perché la memoria cache è stata distrutta. Quando il database viene riavviato, Exchange analizza i file di registro e ricostruisce e applica le modifiche non ancora scritte nel file di database. Questo processo viene denominato riesecuzione dei file di registro. Il database è strutturato in modo tale che Exchange può determinare se una qualsiasi operazione in un file di registro è già stata applicata al database, se deve essere applicata al database o se non appartiene al database.

Anziché scrivere tutte le informazioni di registro in un unico file di grandi dimensioni, Exchange utilizza una serie di file di registro, ognuno dalle dimensioni esatte di un megabyte (MB) o 1.024 kilobyte (KB). Quando un file di registro è pieno, in Exchange il file viene chiuso e rinominato con un numero sequenziale. Il primo file di registro che viene riempito termina con il nome Enn00000001.log. Le lettere nn si riferiscono a un numero di due cifre noto come nome di base o prefisso del registro.

I file di registro di ciascun database si distinguono in base ai nomi file con prefissi numerati (ad esempio, E00, E01, E02 o E03). Il file di registro corrente (vale dire, quello aperto al momento) di un database ha il nome Enn.log. A questo file non viene assegnato un numero di sequenza fino a quando non viene riempito e chiuso.

Il file del checkpoint (Enn.chk) consente di tenere traccia del processo di scrittura in corso delle informazioni registrate nei file di database in Exchange. Esiste un file del checkpoint per ogni flusso di registri e un flusso di registri separato per ciascun database.

I file di registro sono numerati in formato esadecimale, quindi il file di registro successivo a E0000000009.log è E000000000A.log, non E0000000010.log. È possibile convertire i numeri di sequenza dei file di registro nei relativi valori decimali utilizzando l'applicazione Calcolatrice di Windows (Calc.exe) in modalità Scientifica. A tale scopo, eseguire Calc.exe, quindi scegliere Scientifica dal menu Visualizza.

Per visualizzare il numero di sequenza decimale per un file di registro specifico, è possibile esaminarne l'intestazione utilizzando lo strumento Utilità database di Exchange Server (Eseutil.exe). La prima pagina di 4 KB di ciascun file di registro contiene le informazioni di intestazione che descrivono e identificano il file di registro e i database a cui appartiene. Il comando Eseutil /ml [log file name] consente la visualizzazione delle informazioni di intestazione.

Se si utilizza l'opzione errata per la visualizzazione dell'intestazione (ad esempio, utilizzando /ml con un'intestazione di database anziché /mh), viene visualizzato un messaggio di errore o le informazioni di intestazione visualizzate possono risultare confuse o errate.

Non è possibile visualizzare l'intestazione di un database mentre è montato. Non è altresì possibile visualizzare l'intestazione del file di registro corrente (Enn.log) mentre uno qualunque dei database è montato. Exchange mantiene aperto il file di registro corrente per tutto il tempo in cui una database lo utilizza. Tuttavia, è possibile visualizzare l'intestazione del file del checkpoint mentre i database sono montati. Exchange aggiorna il file del checkpoint ogni trenta secondi e la sua intestazione è visualizzabile, salvo nel preciso momento in cui è in corso l'aggiornamento del file.

In quanto amministratore di Exchange, può essere utile interpretare le intestazione dei file di Exchange. Se si comprendono le intestazioni dei file, è possibile determinare a quali database appartengono i file di registro e quali file sono necessari per un corretto ripristino.

Nell'intestazione del file di registro dell'esempio seguente, si notino le prime quattro righe.

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

Le righe dell'intestazione del file di registro mostrano che si tratta del file di registro corrente, in quanto il suo nome non contiene un numero di sequenza. La riga lGeneration mostra che il registro è stato riempito e chiuso, che il suo numero di sequenza è B, che corrisponde al valore decimale 11. Il nome di base è e00, pertanto il nome definitivo del file di registro sarà E000000000B.log.

Il valore Checkpoint nell'esempio di intestazione precedente non viene effettivamente letto dall'intestazione del file di registro, ma è visualizzato come se lo fosse. Eseutil.exe legge il valore Checkpoint direttamente da Enn.chk, quindi non è necessario immettere un comando separato per conoscere il percorso del file del checkpoint. Se il file del checkpoint è stato distrutto, il valore Checkpoint leggerà NOT AVAILABLE. In questo caso, il file del checkpoint si trova nel file di registro corrente (0xB) e i numeri 7DC e 6F indicano il punto in cui si trova nel file di registro. In ogni caso, accadrà raramente di dover mettere in pratica tali informazioni.

Se il file del checkpoint viene distrutto, Exchange è ancora in grado di ripristinare e rieseguire i file di registro in modo appropriato. Per farlo, tuttavia, Exchange inizia l'analisi dei file di registro, a partire dal file meno recente disponibile, anziché iniziare dal registro del checkpoint. Exchange ignora i dati già applicati al database e procede in sequenza attraverso i registri fino ad arrivare ai dati che devono essere applicati.

In genere, Exchange impiega solo uno o due secondi per analizzare un file di registro già applicato al database. Se il file di registro contiene delle operazioni che è necessario scrivere nel database, il tempo impiegato per applicarle può variare da 10 secondi a diversi minuti. In media, è possibile scrivere il contenuto di un file di registro nel database in 30 secondi o anche meno.

Quando un database di Exchange viene chiuso normalmente, tutti i dati in sospeso vengono scritti nei file di database. Dopo la normale chiusura, l'impostazione del file di database è considerata coerente ed Exchange scollega il database dal relativo flusso dei registri. Ciò significa che i file di database sono ora completi ovvero sono completamente aggiornati. I registri delle transazioni non sono necessari per avviare i file di database.

Per verificare che un database è stato arrestato correttamente, eseguire il comando Eseutil /mh ed esaminare le intestazioni dei file.

Se tutti i database sono disconnessi e in uno stato di chiusura normale, è possibile eliminare tutti i file di registro senza danneggiare i database. Se si è in procinto di eliminare tutti i file di registro, Exchange genererà una nuova sequenza di registri iniziando con Enn00000001.log. È anche possibile spostare i file di database su un server diverso con file di registro esistenti e i database verranno associati a un diverso flusso di registri.

Nota

Anche se è possibile eliminare i file di registro dopo l'arresto di tutti i database, in questo modo si compromette la possibilità di ripristinare i backup precedenti e di eseguire il roll forward. Per il database corrente non sono più necessari i file di registro esistenti, ma potrebbero essere necessari per ripristinare un database precedente.

Se un database si trova in uno stato di chiusura anomala, tutti i registri delle transazioni esistenti dal checkpoint in avanti devono essere disponibili prima di poter montare di nuovo il database. Se i registri non sono disponibili, è necessario riparare il database eseguendo il comando Eseutil /p per renderlo coerente e pronto all'avvio.

Avviso

Se è necessario riparare un database, alcuni dati potrebbero andare perduti. Anche se grave, la perdita di dati in genere è minima. Dopo aver eseguito Eseutil /p su un database, occorre eseguire Eseutil/ d per deframmentare il database. Questa operazione consente di eliminare e ricostruire tutti gli indici del database e le strutture di spazio.

Oltre a consentire ad Exchange di eseguire in modo affidabile il ripristino da un arresto imprevisto del database, anche la registrazione delle transazioni è indispensabile per eseguire e ripristinare i backup in linea. Per ulteriori informazioni sull'esecuzione e il ripristino di backup in linea, vedere Informazioni su backup, ripristino e ripristino di emergenza.

I database nelle edizioni di Exchange 2010

Registrazione circolare

È possibile configurare Exchange in modo da risparmiare spazio su disco abilitando la registrazione circolare. La registrazione circolare consente a Exchange di sovrascrivere i file di registro delle transazioni una volta che i dati di tali file sono stati salvati nel database. Tuttavia, quando la registrazione circolare è abilitata, è possibile recuperare solo i dati precedenti all'ultimo backup completo. Ad esempio, è possibile abilitare la registrazione circolare quando si utilizza la protezione dati nativa di Exchange che non prevede backup. Se si desidera impedire la crescita continua dei registri, è necessario abilitare la registrazione circolare.

Nella registrazione delle transazioni standard utilizzata da Exchange 2010, ciascuna transazione di database viene scritta in un file di registro e quindi nel database. Quando un file di registro raggiunge la dimensione di 1 MB, viene rinominato e viene creato un nuovo file di registro. Con il tempo, si otterrà un insieme di file di registro. Se Exchange si arresta inaspettatamente, è possibile ripristinare le transazioni rieseguendo i dati dai file di registro nel database. La registrazione circolare sovrascrive e riutilizza il primo file di registro dopo che i dati che contiene sono stati scritti nel database.

In Exchange 2010, la registrazione circolare è disabilitata per impostazione predefinita. Se si abilita la registrazione circolare, si riducono i requisiti di spazio di archiviazione nell'unità. Tuttavia, senza un insieme completo di file di registro delle transazioni, non è possibile ripristinare i dati successivi all'ultimo backup completo. In un normale ambiente di produzione, la registrazione circolare non è consigliata.

Per informazioni su come abilitare e disabilitare la registrazione circolare, vedere Configurazione delle proprietà del database delle cassette postali.

I database nelle edizioni di Exchange 2010

Extensible Storage Engine

I database delle cassette postali di Exchange e la coda sui server Trasporto Hub e Trasporto Edge utilizzano il database ESE (Extensible Storage Engine). ESE è un gestore di tabelle ISAM (Indexed Sequential Access Method, metodo di accesso sequenziale indicizzato) multiutente con funzionalità DML (Data Manipulation Language) e DDL (Data Definition Language) complete. Il motore ESE consente alle applicazioni di archiviare i record e creare indici per l'accesso ai record n vari modi. Per ulteriori informazioni su ESE, vedere Architettura ESE. Per i miglioramenti apportati a Exchange 2010 ESE, vedere Nuove funzionalità di base dell'archivio di Exchange.

I database nelle edizioni di Exchange 2010

Integrità dell'archivio

L'archivio di Exchange è in grado di rilevare e risolvere diversi problemi che potrebbero intaccarne l'integrità. L'archivio di Exchange è in grado di gestire le cassette postali non elaborabili e i timeout dei thread, utilizzare le funzionalità di segnalazione e avviso per riportare una condizione di errore dell'archivio di Exchange e rilevare nonché risolvere i problemi dei database delle cassette postali e dei database delle cartelle pubbliche.

Rilevazione e correzione delle cassette postali non elaborabili

Una singola cassetta postale contenente dati danneggiati (logici o fisici) potrebbe in alcuni casi determinare una condizione di errore dell'archivio di Exchange e di conseguenza bloccare il servizio a tutte le cassette postali ospitate sul server. Allo stesso modo, una cassetta postale non elaborabile potrebbe anche provocare una condizione di errore ripetitivo dell'archivio di Exchange. Questa sezione descrive le azioni intraprese dall'archivio di Exchange per rilevare e isolare le cassette postali non elaborabili.

Isolamento di una cassetta postale non elaborabile

Esistono vari tipi di eventi in conseguenza dei quali l'archivio di Exchange contrassegna una cassetta postale come potenzialmente pericolosa:

  • In caso di errore di un thread che sta lavorando per quella cassetta postale

  • Se più di cinque thread di quella cassetta postale non hanno registrato alcun avanzamento per un lungo periodo

Una cassetta postale potenzialmente pericolosa viene contrassegnata come tale e viene anche indicato il numero di volte in cui è stata contrassegnata. Queste informazioni vengono archiviate nel Registro di sistema. L'archivio di Exchange mantiene anche la registrazione della data e dell'ora in cui la cassetta postale è stata contrassegnata come potenzialmente pericolosa.

Durante il montaggio di un database, l'archivio di Exchange legge l'ora in cui le cassette postali sono state contrassegnate come potenzialmente pericolose. Se sono trascorse più di due ore, la chiave del Registro di sistema della cassetta postale interessata viene eliminata. Il vantaggio di mantenere queste informazioni nel Registro di sistema è che, in un ambiente ad alta disponibilità, esse vengono replicate dal database dei cluster. Anche durante il failover dell'archivio di Exchange, gli altri computer dispongono comunque di queste informazioni. La sottochiave del Registro di sistema utilizzata per isolare la cassetta postale non elaborabile è HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Nome Server>\Private-{guid db}\QuarantinedMailboxes\{guid cassetta postale}. Le chiavi di questo percorso sono CrashCount e LastCrashTime.

Le impostazioni per la quantità di errori che portano alla quarantena di una cassetta postale e quelle relative alla durata della quarantena vengono archiviate nelle chiavi MailboxQuarantineCrashThreshold e MailboxQuarantineDurationInSeconds nella sottochiave HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Nome Server>\Private-{guid db}.

I valori predefiniti di queste chiavi sono tre errori per MailboxQuarantineCrashThreshold e 21.600 secondi (sei ore) per MailboxQuarantineDurationInSeconds.

Azioni per la cassetta postale non elaborabile

Per impostazione predefinita, se una cassetta postale viene identificata come potenziale causa di errore o blocco per tre volte in due ore, l'archivio di Exchange la contrassegna come in quarantena nel Registro di sistema. Non è più possibile accedere a questa cassetta postale, a meno che non venga inserito il flag OPEN_AS_ADMIN. L'accesso non è permesso ad alcuno dei processi di Exchange (ad esempio, indicizzazione dei contenuti o assistenti delle cassette postali). Le chiavi del Registro di sistema QuarantineState e QuarantineTime tengono traccia dello stato di quarantena della cassetta postale. Se la cassetta postale non ha causato alcun errore nelle ultime due ore e non è in quarantena, il percorso del Registro di sistema per quella cassetta postale viene cancellato dall'archivio di Exchange . Se una cassetta postale è rimasta in quarantena per un periodo maggiore del valore di MailboxQuarantineDurationInSeconds a partire dal valore di LastCrashTime, la cassetta postale viene automaticamente rilasciata dalla quarantena.

Ripristino delle cassette postali messe in quarantena

Una volta identificata e rimossa la causa della non elaborabilità della cassetta postale messa in quarantena, la cassetta deve essere ripristinata eliminando manualmente la relativa chiave del Registro di sistema. Tuttavia, se questo passaggio manuale non viene effettuato, l'archivio di Exchange ripristina automaticamente le cassette postali in quarantena sei ore dopo l'impostazione del flag di quarantena. Se il problema non viene rilevato e risolto entro questo periodo di tempo, si potrebbe verificare un'altra serie di errori prima che la cassetta postale o il messaggio venga di nuovo messo in quarantena.

Nota

Il database che ospita la cassetta postale deve essere rimontato oppure l'archivio di Exchange deve essere riavviato prima che il ripristino della cassetta postale dalla quarantena possa avere effetto.

Il periodo di tempo per il ripristino delle cassette postali messe in quarantena può essere controllato tramite la chiave del Registro di sistema HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Nome Server>\Private-{guid db}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds.

Segnalazioni e avvisi

È possibile utilizzare il cmdlet Get-MailboxStatistics per segnalare lo stato di quarantena di una cassetta postale. L'archivio di Exchange dispone di un contatore di Performance Monitor che rileva il numero di cassette postali messe in quarantena. Il nome del contatore è MSExchangeIS Mailbox\Quarantined Mailbox Count.

Anche l'archivio di Exchange scrive un evento ogni volta che mette in quarantena una cassetta postale, indicando la cassetta postale e l'ora dell'evento. L'evento 10018 identifica una cassetta postale messa in quarantena.

I database nelle edizioni di Exchange 2010

Ripristino del database

In Exchange 2010 Service Pack 1 (SP1), è possibile utilizzare il cmdlet New-MailboxRepairRequest per rilevare e correggere gli errori delle cassette postali. È possibile eseguire questo cmdlet per una cassetta postale specifica o per uno specifico database delle cassette postali. Durante l'attività, non è consentito l'accesso alla cassetta postale in riparazione. Se si esegue questo cmdlet per un database delle cassette postali, non è consentito l'accesso solo alla cassetta postale in riparazione. Tutte le altre cassette postali nel database rimangono operative. Per ulteriori informazioni, vedere Creazione di una richiesta di riparazione di cassette postali.

Il cmdlet New-MailboxRepairRequest rileva e risolve i seguenti tipi di danneggiamenti della cassetta postale:

  • Danneggiamenti alla cartella di ricerca (utilizzando il valore SearchFolder del parametro CorruptionType)

  • Totali sulle cartelle che non riflettono i valori corretti (utilizzando il valore AggregateCounts del parametro CorruptionType)

  • Visualizzazione sulle cartelle che non restituiscono il contenuto corretto (utilizzando il valore FolderView del parametro CorruptionType)

  • Cartelle di provisioning che puntano in modo non corretto a cartelle principali non di provisioning (utilizzando il valore ProvisionedFolder del parametro CorruptionType)

Dopo aver eseguito il cmdlet New-MailboxRepairRequest, è possibile utilizzare il Visualizzatore eventi per visualizzare i dettagli della richiesta. Per ulteriori informazioni, vedere Visualizzazione delle voci della richiesta di riparazione di cassette postali nel Visualizzatore eventi.

È anche possibile utilizzare il cmdlet New-PublicFolderDatabaseRepairRequest per rilevare e correggere i problemi di replica nel database delle cartelle pubbliche. Le cartelle pubbliche nel database delle cartelle pubbliche sono ancora accessibili in fase di esecuzione della richiesta. Tuttavia, l'accesso alla cartella pubblica attualmente in fase di riparazione non è disponibile. Per ulteriori informazioni, vedere Creazione di una richiesta di ripristino di un database delle cartelle pubbliche.

I database nelle edizioni di Exchange 2010

Rilevamento e segnalazione dei timeout

Un ulteriore sintomo del danneggiamento dell'archivio di Exchange è il blocco o il mancato avanzamento dei thread. Se sono presenti più di cinque thread in una singola cassetta postale, dieci thread in un singolo database o venti thread su un singolo server per i quali non è stato segnalato alcun avanzamento nell'arco di un minuto, sul server viene segnalata un condizione di timeout. Il contatore delle prestazioni che riporta il numero dei timeout rilevati è MSExchangeIS\ RPC Request Timeout Detected.

Anche l'archivio di Exchange scrive i seguenti eventi sul server:

  • 10025, che segnala un timeout sul server Exchange

  • 10026, che segnala un timeout nel database

  • 10027, che segnala un timeout in una singola cassetta postale

Se il timeout viene rilevato in una singola cassetta postale, quest'ultima viene considerata potenzialmente pericolosa e trattata come in caso di errore, con conseguente incremento del numero nella chiave CrashCount. Ciò rende la cassetta postale suscettibile di quarantena.

I database nelle edizioni di Exchange 2010

Spazio su disco insufficiente per i registri o le unita del database

Quando l'archivio di Exchange rileva che lo spazio disponibile sull'unità che contiene un registro o un database è inferiore a 1 GB, esso interrompe ogni tipo di recapito a quel database. Ciò impedisce che venga completamente esaurito lo spazio su disco. Quando un disco viene completamente occupato, il database non può più essere né montato né corretto. Inoltre, non è possibile recuperare lo spazio del database. Si tratta di un meccanismo di autodifesa che viene attivato quando nessuno reagisce agli avvisi di spazio insufficiente inviati dall'infrastruttura di monitoraggio.

Quando lo spazio disponibile sul disco supera di nuovo 1,5 GB, l'archivio di Exchange permette di nuovo di effettuare i recapiti. I seguenti contatori di prestazioni indicano il seguente comportamento:

  • MSExchangeIS Mailbox\ Delivery Blocked: Spazio insufficiente per il database

  • MSExchangeIS Mailbox\ Delivery Blocked: Spazio insufficiente per i registri

Anche l'archivio di Exchange scrive i seguenti eventi sul server:

  • 10014, che indica insufficiente spazio su disco per il registro

  • 10015, che indica insufficiente spazio su disco per il database

In caso di problemi dovuti a spazio insufficiente sul disco, è possibile fare quanto segue per risolverli:

I database nelle edizioni di Exchange 2010

Limiti di archiviazione di Exchange

In Microsoft Exchange 2010 vengono applicati dei limiti di connessione e di utilizzo dell'archivio di Exchange per evitare che tutte le connessioni disponibili vengano utilizzate da una singola applicazione o un singolo utente. Se a una sola applicazione o utente venisse concesso l'uso di tutte le connessioni, le altre applicazioni ed utenti non potrebbero accedere all'archivio di Exchange e ciò determinerebbe un periodo di inattività.

Per ulteriori informazioni, vedere Limiti degli archivi di Exchange.

I database nelle edizioni di Exchange 2010

 ©2010 Microsoft Corporation. Tutti i diritti riservati.