Reconsider your Exchange storage group issues

Exchange 2000 has the ability to create multiple storage groups, including various mailbox or public folder stores. Unfortunately, to make up for the memory fragmentation problem, it is necessary to use as few storage groups as possible to better sustain the Exchange version 2000.

In Exchange 2000, most Exchange machine experts agree that you should completely populate a storage group before creating any new repositories. Obviously, if you use 20 different storage, you can either use more than one store group or copy the contents of some storage to another server. If your Exchange 2000 servers have very little storage, you'd better put them in an ordinary storage group.

On the surface, the memory group presents the same principle as Exchange Version 2003. But they are actually not the same. Store all of your storage in a separate storage group. Like the Exchange 2000 version we recommended--it's not the best way. For example, if you have four storage content in the Exchange 2003 release, it is best to put them in their respective storage groups instead of putting them all in the same storage group.

Memory fragmentation

Microsoft has largely taken into account the Exchange 2003 version of memory fragmentation issues. and measures have been taken to reduce damage to the system's memory.

In Exchange 2000, each storage group is allocated 250 megabytes of memory. This allocated memory is used for replication storage, scheduling of cache memory, and various Jet database functions. In the Exchange SP3 version, Microsoft developed a memory allocator.

The POST-SP3 version of Exchange 2003 may still be sensitive to memory fragmentation issues, but as long as the server has enough resources to provide exchange for the memory it needs, the storage cannot run at low speeds.

Share Run Log

Microsoft has identified some of the pieces and storage for Exchange 2003, though you can't put your storage in a storage group. The underlying reason is that these storage contents are not completely independent of each other.

For Exchange 2003, all storage in a storage group shares a common set of run-time logs. This has a detrimental effect on exchange operations. For example, the drive, disk input/output process encountered in the situation.

Microsoft often recommends that the run log be stored in a higher performance disk or disk array, rather than its own database. The faster the Exchange reads and writes to run logs, the better the server will run.

Suppose you have four Exchange 2003 databases, and each database receives an equal amount of storage content. If these databases are grouped together into the same storage group, the hard drive on which the log is run will run hard four times to transmit the same kind of operation. If the hard drive does not have this capability, the operation will be blocked.

Shared run logs also have a negative impact on recovery. When you save an Exchange 2003 database, part of the process is to reset the run Log update database. If the various databases are using these run logs, this will take more time to complete than the databases that have recovered and have their own running logs.

Storing all of your Exchange 2003 files in an Exchange group is also a problem. If the storage is divided into various storage groups (each storage group has a dedicated drive for the run log, the partition containing the running log affects only a single memory.) Other memory is also functional.

Conclusion

As you know, there are a number of issues to consider when you store your Exchange 2000 memory in a storage group.