An Exchange Information Store is a database. A Standard Exchange Server can host 3 Information Store databases. Each is a Jet database and can exist at its own file path and will have a .edb file extension.
You can manually defrag an Exchange database using a tool called eseutil. In this case, you’ll encounter from 5 to 20 minutes of downtime per gig of the Information Store. You can run eseutil, Eseutil can be run to scan a database to determine whether an offline defragmentation is necessary.
You can run eseutil to manually determine the space that could be saved with a defrag. To do so, run eseutil with the /m and /s options:
eseutil /MS "D:\database\primary.edb"
To run a defrag, specify that you are defragmenting a /d for database and /ds for the directory. You will need enough space on the drive with the edb files on it to make a copy of the database (double-click on an Information Store to see the path). In this example we’ll specify a temporary directory to use for defraging on another volume, as follows:
eseutil /d /ds /tc:D:\backup\eseutildefrag.edb /p
Note: To use a temporary volume, increase the amount of time per gig to defrag the database.
While defrag is something that eseutil can help with, I find that it’s also frequently used for performing recovery operations on a database. To check:
eseutil /r “D:\database\primary.edb”
To run, use the /P option:
eseutil /P "D:\database\primary.edb"
If you have a corrupt or missing .stm file (according to the version of Exchange, you can create one using the /CREATESTM flag:
eseutil /P /CREATESTM "D:\database\primary.edb"
There are tons of other options available in eseutil. But sometimes the tool cannot run because corruption extends beyond tables and indexes. To chase down corruption, you can also use isinteg. To test a folder on the exchange server called exchange.krypted.com, specify the server using the -s option and indicate -test to run tests as well as the specific test to run, which can be indicated with the alltests option:
isinteg -s exchange.krypted.com -test alltests
You can also specify specific tests, replacing alltests with folder, allacltests, allfoldertests, search, global, etc. These tests all have their own options. To run a repair also add the -fix option.
A lot of corruption can be caused by problems with the service, IO or corrupt volumes. To check volumes, use chkdsk. IO issues often correlate to Event IDs of 10025, 10026 and 10027. Problems with the Information Store service can be varied but should be tracked using the Event Logs and debugging options on a per-service basis.
Every now and then I see an Open Directory database that’s gotten corrupt for one reason or another. To be more specific, while I see Kerberos get wonky and password server issues from time to time, every now and then I see the actual LDAP database throw errors like this one, when checked with slapd:
Corruption usually looks a little something like this:
51890ba0 ldif_read_file: checksum error on "/var/db/openldap/openldap-data/cn.bdb"
51890ba0 bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
config file testing succeeded
If the bdb (Berkeley Database) files can’t be read in properly then you can do a sanity check with slaptest to see if there are other issues as well:
slaptest -f /private/etc/openldap/slapd.conf -v
Provided that your problems are with the bdb files and not ldif files, which can easily be grabbed from another OD box, you can then recover the database using db_recover, along with the -h option to define the directory your bdb files reside in (/var/db/openldap/openldap-data in OS X Server):
db_recover -h /var/db/openldap/openldap-data/
Note, always backup. If errors continue then you can also run with a -c option, which performs a “catastrophic” recovery. Also, before you do a db_recover OD will need to be stopped. Chances are, if you have corruption then the database will be stopped; however, check first:
serveradmin fullstatus dirserv
If it’s running, stop it:
serveradmin stop dirserv
Once you’re done, there’s no longer the need to reboot each time you do this kind of thing, which is actually a huge time saver, so just swap the stop with start and you’re good:
serveradmin start dirserv
If you see a lot of subdomains that are actually other people’s domain names in your DNS records for NetSol then you can either delete them or call and open a ticket with NetSol. This is zone file corruption on their side.
Xsan volumes can get fragmented. This can cause the performance to move to a grinding halt. Dropped frames, slow copy times, even volume corruption are common side effects. So, to defrag the volume you can use snfsdefrag. This command-line tool will defrag volumes or files. You can even specify what to do with the fragmented data, giving you a way to move data between storage pools…