Friday, August 21, 2009

Exchange Server 2003 Data Storage and Management

Understanding Exchange Server 2003 Data Storage

Exchange Server 2003 uses the Extensible Storage Engine (ESE) database structure to store data. Data can be stored separately for messages and for transactions:
Messages are stored in.edb and .stm database files. Database files also contain a number of other components, including:

• Rules
• Folders

• Attachments

• Indexes

Transactions are stored in transaction log files.

A message that is created is first written to log files before it is written to the database files. From the log files, the transactions are sequentially written to a numbered file. Data in the log file is written to the database at a later stage. Transaction log files are written to in a sequential order. Database files are written to in a random manner. They are also read in a random manner. Exchange Server 2003 automatically creates a new transaction log file when the current log file reaches 5 megabytes (MB) in size. The transaction log files and database files should be located on disk systems that have the following characteristics:
The disk systems are optimized for the type of functions to be performed.
The disk systems do not compete.

The disk setup that you use for transaction log files and database files should provide the following:
• Best cost.

• Best data protection.

• Best performance.

Understanding How Transaction Logs Protect Data
When you store transaction log files separately to database files, the following benefits are achieved:
• Disk performance is improved.

• Protection from data loss.

Each storage groups has its own transaction log file. The Information Store is arranged into storage groups. A storage group is a group of separate databases which have a common set of transaction log files. It is these storage groups that contain the mailbox stores, public stores, or both of these stores
From the transaction log file, the information is saved to the database file of the storage group. A checkpoint file indicates which transaction log entries have since been written to the database file. The information is not deleted from the transaction log file at this stage. It is only deleted when a full online backup of all the databases in the storage group is performed.
The concept of a soft recovery and hard recovery is illustrated below:

Soft recovery: When the hard disk containing the storage group databases is lost, the damaged disk can be replaced. You can use the latest database backup for the restore. When the checkpoint file is deleted, an automatic log file replay of all transactions that took place since the backup, transfers the transactions from the log files to the databases. A soft recovery is also referred to a roll-forward recovery.

Hard recovery: A hard recovery can be performed when you have backed up transaction log files since the last full backup. With a hard recovery, transaction log files from the backup medium are replayed after the database is restored from an online backup. If Exchange 2003 detects that additional log files are available on the server, soft recovery is initiated to restore these log files to the database.

If the disk you are using for the transaction log files fails and the disk storing the databases are still online, no storage group data needs to be restored. You cannot though replay any transactions that are recorded to log files and not to the database files on disk.

Storage Technologies used with Exchange Server 2003
The different storage technologies that can be used with Exchange Server 2003 are listed below. The storage technology that you choose will be determined by the size of your Exchange Server 2003 organization

External storage array (ESA): The characteristics and features of an external storage array are listed here:
An external Small Computer System Interface (SCSI) drive cabinet hosts multiple SCSI disk drives that are typically set up as RAID sets.
SCSI cables connect the disk drives to an Exchange Server 2003 server.
External storage has to be managed on a per Exchange Server 2003 server basis.
External storage provides good performance.
Limited scalability is provided.
Recommended for small Exchange organizations.

Network Attached Storage (NAS): The characteristics and features of network attached storage are listed here:
SCSI or fiber channel connections can be used to connect the storage device to the Ethernet network.
Network attached storage has its own IP address and is not directly attached to the Exchange Serve 2003 server.
File requests are mapped by the Exchange Server 2003 server to the network attached storage server.
This is not the recommended storage technology for Exchange Server 2003, simply because Exchange Server 2003 has local data access and bandwidth requirements that are not compatible with network attached storage products.

Storage area network (SAN): The characteristics and features of a storage area network are listed here:

• For medium to large Exchange organizations, using a SAN as a storage technology is the recommended solution.

• A SAN uses fiber channel switching to provide fast and reliable connections between storage and applications.

• SANs optimize the performance and reliability of a server.

• SAN packages are supplied by hardware vendors such as IBM and Intel. The SAN package includes all hardware, software and support functions.

• The main components that make up a SAN are listed here:

• Fiber channel switching

• Storage arrays that store and protect data.

• Storage software and SAN management software

• The advantages of using a SAN technology in an Exchange Server 2003 organization are listed here:

• You can connect multiple Exchange Server 2003 servers to multiple storage arrays and share storage between the servers.

• The high I/O bandwidth needed by Exchange Server 2003 is supported by SAN solutions.

• The Exchange organization can be easy expanded by adding servers.

• SANs are highly scalable and disks can easily be added.

Managing Storage and Storage Groups
• A few best practices for configuring storage groups and databases are summarized here:

• You should never use circular logging.

• Use only four databases for each storage group.

• When creating additional storage groups, create the databases that are needed before you create the additional storage groups. This prevents overhead on the server for log file management.

• To ensure short maintenance and restore times, you should strive to keep the size of the databases small.

• When you configure your storage group limits, it is recommended that you do not enable the prohibit-send option.

• You should not change the online system maintenance default setting of enabled.

• It is recommended that you perform a full backup each day, if feasible.

• Verify that backups have occurred successfully.

• You should retain deleted mailboxes for a minimum of thirty days.

• You should retain deleted items for a minimum of seven days.

• Ensure that the logs are purged.

Additional Storage groups would need to be created under the following conditions:

• There is a need to utilize separate physical transaction log drives so that performance can be improved.

• There is a requirement that multiple databases need to be backed up simultaneously. If you use multiple storage groups, then each storage group can
be backed up at the same time.

• The existing storage group is already using the maximum number of databases supported, and you need another

1 comment:

ashwani said...

may i know how data is storage in log file as well as its structure.