Starting Exchange Server with a blank Information Store

Starting Exchange Server with a blank Information Store

There are some situations where starting Microsoft Exchange with a blank database may be necessary. In my line of work, I run across a large amount of businesses that have had their Exchange Private Information Store corrupted and the whole organizations Email capabilities halted as well. Quite often, getting the users back up and running takes precedence over getting the data back. Don’t get me wrong; the data is still extremely important, however not having email capability can stop some businesses day to day operations dead in their tracks.

In a perfect world, there would and should be a backup Exchange server just waiting to take over in case of a catastrophic event. But in reality, that is rarely the case. Rather than wait a complete day or two, or even longer, for the systems administrator to get the Exchange database recovered, a viable alternative is to restart the information store with a blank database and import the data back in when it is recovered.

There may be other reasons for wanting to create a blank database as well. You may have an Exchange server that is years old, with tons of residual data from users no longer at the company. You may need to free up disk space on your server. You may have a database with minor corruption and decide to ExMerge your data out and import it back in to a clean corruption-free database. Whatever the reason, make sure you have a complete plan of action and be sure to backup your data in case you run into difficulties. The following article explains how to create a new database with Exchange Server.

To start Exchange Server with a blank Information Store:

1. Locate the Exchange database directory and transaction log directory
   1. Open Exchange System Manager
   2. Navigate to Administrative Groups->First Administrative Group->Servers->servername
   3. Underneath servername click First Storage Group and then Action->Properties
   4. Transaction Log location will be listed on the General tab. Note this location (Image 1d)
   5. Navigate under First Storage Group to your Mailbox Store and click Action->Properties
   6. Click the Database tab to note the Exchange Database and Exchange Streaming Database locations (Image 1f)
   7. Do the same for the Public Store

Image 1d	Image 1f

2. Stop the Exchange Information Store (IS) if it is currently running
   1. Click on Start->Programs->Administrative Tools and then on Services or you can go to Computer Management by Right-Clicking on My Computer and choosing “Manage”

      i. If using Computer Management, drill down to Services and Applications, and then Services underneath that

   2. In the right window of the Services or Computer Management console, locate Microsoft Exchange Information Store
   3. If it’s status is listed as “Started”, Right-Click it and choose “Stop” (Image 2c)
   4. It may give you a message stating that dependency services such as Microsoft Exchange Event will need to stop as well. Choose “Yes” to continue stopping the IS

Image 2c

3. Rename database and transaction log directories and create new ones
   1. Rename the database location MDBDATA directory to MDBDATA-old (Image 3a)
   2. Create a new MDBDATA directory
   3. Rename the transaction log MDBDATA directory to MDBDATA-old (if location is different from the database location)
   4. Create a new MDBDATA directory for the transaction logs (Image 3d)

Image 3a	Image 3d

4. Start the Exchange Information Store service
5. Create new data files
   1. From Exchange System Manager navigate to Administrative Groups->First Administrative Group->Servers->servername->First Storage Group
   2. Click on the Mailbox Store and then on Action->Mount Store (Image 5b)
   3. You will receive a message stating that mounting this store will force the creation of an empty database, choose “Yes” to continue (Image 5c)
   4. The Store should mount, give you a message stating it successfully mounted and the data files should be created in the MDBDATA directory. (Images 5d1 & 5d2)
   5. Follow the same steps for the Public database

 

 

Image 5b
Image 5c
Image 5d1	Image 5d2

6. Test and Verify
   1. Verify the data files were created in the MDBDATA directory
   2. Check the Event Log for any errors
   3. Test connection to the Exchange server from Outlook

Database Design Solutions: RAID 0

Database design and RAID 0

This article is presented by Dick Correa, DTI Data Recovery’s head programmer and RAID Data Recovery engineer.

Databases, by design, are probably one of the single most demanding applications in regards to I/O throughput. This article will take a look at this fact and offer a solution using RAID 0 technologies. In order to do that, let’s first take a look at a standard database and dissect its functioning.

Databases are comprised of two basic elements. A flat file, and an index into that flat file. For example, one may have a database of patients. Each patient should have basic information, such as name, address, phone, insurance carrier, etc, etc. Each one of the patients, and their information is called a record. There is one record for each patient and a record is stored in a file, a ‘flat file’. Flat file meaning a file which is not sorted. For illustration lets say that each record, will take approximately 300 bytes of storage. As each new patient is added, the new patients record is appended to the end of the file. I have personally worked with many hospitals and doctors and I can safely say that there can be millions of patients in one hospital over a period of 2-3 years.

We now have a flat file, with millions of patients, and in walks Mr. Johnson. Now we need to look up Mr Johnsons record. Are we going to look at EVERY record to find Mr Johnsons record? How long would that take? How much pressure on the server would that transfer? Compound this with the fact that there may be several clerks querying the database simultaneously. How do we, as database administrators, stop the I/O bottle neck, and ultimately a long wait between queries?

First of all, we use indexing. ISAM is one method, B+tree is another. We design indexes into the flat file. The key here is that all indexes are sorted and therefore search engines can be designed to use that fact. ISAM uses ascending ascii as a parameter, B+Tree uses a modified ISAM and a balanced search engine. The point here is that the indexes are usually very small, and sorted. For example, an index may only contain the last name of a patient. So, we enter Johnson, we use the index to search for Johnson, then we look at the index pointer which tells us where in the flat file Mr. Johnsons record is. Now, there may be many Johnsons in the index, so we may have another index of just social security numbers. So, the key to indexes is the sorting methodology used, and index design. How does RAID 0 figure into all of this?

RAID 0 uses several drives across separate I/O ports to perform as a single drive. The RAID is striped using a user defined size and the data is stored using the stripe as a basis. For example, lets take a four drive RAID 0, with a stripe size of 8K. We have a 256k block of data that we are trying to save. The procedure executes like this, 8K to drive 0, 8K to drive 1, 8K to drive 2, 8K to drive 3. 32k written. Then the procedure starts again and continues until all 256K is written. The RAID card that controls the array does not wait for each write to finish until it goes to the next drive, it notifies all 4 drives simultaneously and instead of one 8K block being written, a 32K stripe is written, in the same amount of time. For purposes of illustration lets say that it takes 1 second to write an 8K block to a single drive. With 256K of data to write it would take 32 seconds to write the data to a single drive. With a four drive RAID 0 it would take one quarter of the time, or 8 seconds. The data is the same, the data size is the same, but having a RAID 0 makes your throughput four times faster.

Now we can take our example one step further. When writing to the drive it is the head positioning and notification that takes all the time, the actual write is theoretically instantaneous. With that in mind it is better to write as much data as possible once the head is in position. How do we accomplish that with RAID 0? Instead of a stripe size of 8K, lets increase the size to 32K. We can use the same write speed in our example since we understand that it is head positioning, and not the actual write that takes the time. So, using the same math we can speed up throughput from 32 seconds to a single drive, to 8 seconds for a RAID 0 with an 8K stripe, to 2 seconds with an increase in the stripe size to 32K. Ultimately you can take this and change the stripe size to 64K and take only one second to write a 256K block of data.

Although this is very simplified in order to make a point it is easily seen that a RAID 0 configured properly will in fact increase throughput and ultimately speed up database access.

When designing a storage system for a database look at record size, cache sizes on the RAID card as well as the drives. How well does the firmware handle look ahead, on the RAID card as well as the drives themselves? Does the database cache in chunks that can be optimized to work well with your RAID caching schema? These are only a few factors that must be taken into consideration when designing your database.

Lastly, although RAID 0 may seem to be the end all and be all to database design, it has one drawback. It contains no native recovery functions. In other words, it is not like RAID 1 which is mirrored, or like RAID 5 which uses XOR math and single drive parity. However, with RAID 1 capacity is diminished and I/O speed is severely throttled. With RAID 5 you may have the same capacity, but the firmware still must calculate parity, and that parity has to be written to the drive. In other words for every write there is a calculation and an extra write. With a large and active database the I/O bottleneck could be significant.

So with RAID 0, institute a well planned backup system that takes all possibilities into account include restoration drills. Design your database so that it works well with your I/O system. Do those things and you will find that RAID 0 can be the answer to all of your storage requirements.

If ever you require RAID 0 Data Recovery please call DTI at (866) 438-6932