andreamonguzzi.it
Microsoft Windows Server, Exchange Server, Accesso ai dati e tecnologia di ogni tipo :)
  • Home
  • Chi sono
  • Collaborazioni
  • Contatti
  • Richiedi un articolo
Home  /  Exchange Server 2010 • Informatica  /  Exchange 2010: Deframmentare il database e ridurre lo spazio occupato sul disco
Exchange Server 2010
17 marzo 2014

Exchange 2010: Deframmentare il database e ridurre lo spazio occupato sul disco

Andrea Monguzzi Andrea Monguzzi, database, deframmentazione, ESEUTIL, Exchange Server, spazio disco 1 Comment

Il database della posta di un server Microsoft Exchange è destinato a crescere con il tempo e l’utilizzo. Quello che i non addetti ai lavori non sospettano è che cancellando dei contenuti questi non liberano spazio sul disco e non fanno diminuire la dimensione del file di database. Supponendo di avere un database di Exchange da 30GB e di eliminare o spostare dei contenuti per un complessivo di 5GB, lo spazio disco occupato rimarrà di 30GB. All’interno del file di database saranno disponibili 5GB di spazio bianco, dove verranno inseriti i futuri contenuti. Per esigere la liberazione dello spazio disco esistono due strade: creare un nuovo database e spostare tutte le mailbox dal DB esistente a quello appena creato, eliminando quindi il DB una volta conclusa la migrazione, oppure eseguire un defrag del DB esistente. In questo articolo vedremo come muoversi utilizzando l’opzione della deframmentazione, tenendo conto che l’operazione comporta la messa offline del DB e quindi la disconnessione di tutti gli utenti attivi su di esso.

Innanzitutto possiamo utilizzare un comando da shell che ci può indicare quanto spazio disco libereremmo eseguendo un defrag. Il comando è:

Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace

image

In questo caso vediamo un database con un’occupazione di 81GB di cui 20GB circa disponibili e liberabili tramite defrag.
Durante il processo di defrag dobbiamo tenere conto che avremo bisogno di spazio disco in quanto il DB verrà momentaneamente creato in un file di appoggio e quindi, ad un certo punto, avremo entrambi i file di DB presenti sul disco. Per sapere quanto spazio disco temporaneo servirà dobbiamo considerare la dimensione prevista del nuovo DB moltiplicata per 1,1.
Nel nostro caso avremmo quindi 81,76GB – 20,28GB = 61,46GB x 1,1 = 67,63GB. Per sicurezza quindi sarebbe consigliato disporre di almeno 70GB per avere un minimo di margine. Qualora non avessimo sufficiente spazio disco dovremmo specificare un percorso alternativo per far transitare il file DB temporaneo.
Il comando da utilizzare per l’operazione di deframmentazione è, neanche a dirlo, ESEUTIL.

Come anticipato, il comando va eseguito con il DB offline. Provvedo a smontarlo, con il comando Dismount-Database:

Dismount-Database ‘Mailbox Database 1666379196’

image

ora con ESEUTIL eseguiamo la deframmentazione. Nel mio caso ho previsto un percorso alternativo per il DB temporaneo, non disponendo di sufficiente spazio disco dove dovrà risiedere il DB di produzione.

eseutil /d ‘Mailbox Database 1666379196.edb’ /tt:\tempDBExchange\temp.edb

image

Nel mio caso l’unità T: è una risorsa mappata su un NAS, quindi non è necessario che la locazione temporanea sia un disco connesso direttamente al server.
Armiamoci di tanta pazienza o andiamo a fare un giro quando parliamo di DB così grandi. Nello specifico l’operazione ha richiesto quasi un’ora e mezza, come si vede dal risultato esposto a fine lavori:

image

Ora non resta che rimontare il DB per fare in modo che l’operatività del server venga ristabilita, con il comando

Mount-Database ‘Mailbox Database 1666379196’

image

Ora verifichiamo, per scrupolo, che la dimensione del DB si sia davvero ridotta rilasciando quella ventina di GB di whitespace, utilizzando nuovamente il comando

Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace

image

Circa 57GB di DB e un centinaio di MB di whitespace. Missione compiuta.

  

Previous Article Office 365: Creare una password provvisoria uguale per tutti gli utenti
Next Article Exchange 2003: Utilizzare EXMERGE per esportare tutti i dati in file PST

About Author

Andrea Monguzzi
Andrea Monguzzi

Sistemista da un ventennio, appassionato di informatica dalla nascita. Aiuto aziende e professionisti a cogliere i benefici e a districarsi dalle insidie dell'era digitale consigliando quale tecnologia adottare in base al tipo di esigenza specifica. Tendenzialmente pigro, caratteristica distintiva del vero nerd, da anni mi adopero affinché le macchine facciano quello che non voglio fare io. Posso quindi aiutarti a fare in modo che sia l'informatica a lavorare per te e non il contrario. :)

Related Posts

  • La vera storia di Marcello, del multifunzione e del rastrello rubato

    La vera storia di Marcello, del multifunzione e del rastrello rubato

  • Office 365: Le cartelle di OWA restano in lingua inglese

    Office 365: Le cartelle di OWA restano in lingua inglese

1 Comment

  1. Pingback: Exchange 2007: Ridurre lo spazio disco occupato dal database « andreamonguzzi.it

Leave a Reply

Annulla risposta


  
settembre 2024
L M M G V S D
« Mar    
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Gli ultimi commenti…

  • Arturo su Windows XP: Impossibile avviare una connessione RDP
  • Mauro su La vera storia di Marcello, del multifunzione e del rastrello rubato
  • Mauro su SBS 2003: backup falliti per errore imprevisto 80090016 (Keyset non esistente)
  • Luca Martinetti su Windows Server 2008: Installazione remota tramite DRAC
  • Francesco su Windows Server 2012: Installare e configurare il ruolo RDS
  • Giovanni su Windows Server 2012: Installare e configurare il ruolo RDS
  • Luca Ferrari su Informatica? Come fermare l’eterna lotta tra cliente e fornitore.
  • Luca Ferrari su La vera storia di Marcello, del multifunzione e del rastrello rubato
Cookie Policy - Privacy Policy - 2015|Lake Web