Open topic with navigation

Application optimizations

Review the following optimizations when you are protecting applications on your source.

General applications

• Application services on the target—Ensure that all application services on the target are stopped and set to manual.
• Connection mappings—When protecting an application server, select the One To One mapping in the files and folders workflow.
• File difference mirrors—When performing a file difference mirror (or file difference restoration), you may not want to use the Send data only if Source is newer than Target option, unless you know for certain that it is acceptable. This is particularly true for database applications since it is critical that all files, not just some of them that might be newer, are mirrored/restored.
• Mirror using write-through mode—You can set a Double-Take Availability driver option which allows mirroring to open files in write-through mode which is the same way many applications, such as Exchange and SQL, open files. This may improve performance on application servers. Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RepKap\Parameters, add a DWORD value called DisableKfaiCaching, and set it to 1.
• Application Notes—Vision Solutions provides Application Notes on the support site that provide implementation guidelines on how to protect many popular third-party applications. If there is no Application Note, contact the application's publisher and ask what files need to be replicated and what requirements must be met for the application to start on another server.

Exchange

• Exchange 2003, 2007, and 2010—Use the Double-Take Availability Application Manager for Exchange 2003, 2007, and 2010, 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.
• /3GB and /userva switches—The /3GB and /userva switches in the boot.ini on a Windows 2003 server can more precisely tune memory. Vision Solutions recommends using the /3GB switch and the /userva switch with a value of 2900. For more information on these options, see the Microsoft articles 823440 and 316739.
• 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 Double-Take Availability connection.) Make sure you configure your Exchange protection to remove orphan files.

SQL

• Application Manager—Use the Double-Take Availability 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.
• Memory—Typically, SQL uses all available memory. You may want to consider limiting SQL memory usage to allow the Double-Take service to function without running out of memory.
• 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.
• 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 SQL Service Principal Names (SPNs) during failover and failback. If you have to use different accounts, Kerberos authentication will require the Service Principal Names to be failed over. See the technical support article 3084 for details on failing over the Service Principal Names.
• Use block checksum for all files during a difference mirror—Configure each source for the block checksum all option. This setting is critical to ensure that block checksum difference mirrors will disregard the file time stamp and size and always perform a block checksum comparison of the files in the job. Since the time stamps and sizes of database files do not change often, it is important that block checksum comparisons be performed even if file time stamps and sizes on the target match those on the source. This option is available through the source server properties.