Exchange – HP Storage Mirroring Software User Manual
Page 623
Recommended optimizations
Page 622 of 677
Exchange
l
Exchange 2003 and 2007—Use the Storage Mirroring Recover Application
Manager for Exchange 2003 and 2007, which will automatically identify all of the
relevant Exchange items that are needed for protection and includes numerous
checks to ensure the source and target are configured correctly.
l
Exchange 2010—Use the full-server protection if you are using Exchange 2010.
l
/3GB and /userva switches—The /3GB and /userva switches in the boot.ini on a
Windows 2003 server can more precisely tune memory. HP recommends using the
/3GB switch and the /userva switch with a value of 2900. For more information on
these options, see the Microsoft articles
and
l
Orphan log files—Exchange database and log files should be synchronized
between the source and target, including the removal of any orphan log files on the
target. Exchange may not recover the databases correctly if orphan log files are
present on the target. (Orphan files are files that exist in the copy of the source data
on the target, but are not on the source. This usually occurs when a file is deleted
on the source when there is no Storage Mirroring Recover connection.) Make sure
you configure your Exchange protection to remove orphan files.
SQL
l
Application Manager—Use the Storage Mirroring Recover Application Manager,
which will automatically identify all of the relevant SQL items that are needed for
protection and includes numerous checks to ensure the source and target are
configured correctly.
l
Memory—Typically, SQL uses all available memory. You may want to consider
limiting SQL memory usage to allow the Storage Mirroring Recover memory queue
and Storage Mirroring service to function without running out of memory. Keep in
mind that Storage Mirroring Recover memory queue and Storage Mirroring service
can be as high as 1 GB each.
l
Temp database—Check with your application vendor to determine if the temp
database is used and needed. If it is not needed, you can exclude it from
replication. For example, SQL Server re-creates the tempdb database file each
time it starts, so any tempdb data that gets replicated to the target will never get
used. Writes to the tempdb database may account for a significant percentage of
writes to all SQL Server files, so excluding the tempdb files may result in much less
replication traffic. If the database application you are using uses the temp database
file (for example in Prophecy, PeopleSoft, and BizTalk) or if you are uncertain, do
not exclude it from replication.
l
SQL service account—Configure the source and target to use the same domain
account to start the SQL services, if possible. This eliminates the need to move