You are here: Application protection > Application requirements > SQL protection requirements

SQL protection requirements

In addition to the general application requirements, you must also meet the following requirements to protect SQL.

SQL versions—Double-Take Availability can protect Microsoft SQL Server or Express 2000 with Service Pack 4 or later, Server or Express 2005, or Server or Express 2008 or 2008 R2, with the following requirements and limitations.

If you are using Windows 2008, you can protect SQL Server or Express 2005 or 2008. SQL Server or Express 2000 is not supported on Windows 2008.
You should use the same version, service pack, and architecture (32-bit or 64-bit) of SQL Server on both the source and target servers. The only exceptions is in database-only protection mode you. In this case, you can use a newer version of SQL Server on the target server, or you may have a 32-bit source and a 64-bit target. For example, you may want migrate from SQL Server 2000 on the source to SQL Server 2005 on the target, or migrate data from a 32-bit source to a 64-bit target. However, you cannot failback using different versions of SQL Server on the source and target.
If you are using SQL Express 2008, you will need to enable and start the SQL Browser Service. By default, this service is set to disabled. Additionally, you will need to enable TCP/IP to accept remote connections. To do this, launch the SQL Server Configuration Manager. Expand SQL Server Network Configuration, and under Protocols for MSSQLSERVER enable TCP/IP.
If you are using SQL Express 2005, you will need to enable named pipes and TCP/IP to accept remote connections. To do this, launch the SQL Server Configuration Manager. Expand SQL Server 2005 Network Configuration, and under Protocols for MSSQLSERVER enable Named Pipes and TCP/IP.
If you are using SQL Express 2000, you will need to enable named pipes and TCP/IP to accept remote connections. To do this, run svrnetcn.exe, which is located in the C:\Program Files\Microsoft SQL Server\80\Tools\Binn directory.
All Microsoft best practices should be used for all versions of SQL.

Server and network configuration—The following requirements and limitations apply to your SQL server and network configuration.

You can use a one-to-one configuration for SQL protection. You can also use a many-to-one configuration, however protection will be database mode only. You cannot use a one-to-many or chained configuration.
The source and target servers should be in the same domain. If they are not, the SQL Server service on both the source and target servers must be configured to start with the same domain user account.
If your source and target are in a workgroup, make sure the source server's NIC does not register the IP addresses with DNS.
In order to protect SQL named instances, both the source and target servers must have named instances with the same name installed prior to configuring protection.
If you are using SQL 2005 and are using a domain service account that is not in the domain or local Admins security group, the replicated databases will not mount on the target because of security restrictions at the file system level. You need to place the SQL 2005 service account in the local Admins group on the target.
If you are using SQL 2005 or later, you should use a domain user account as the Windows Service Account for SQL. See Setting Up Windows Service Accounts on the Microsoft web site for more information. You may also want to include this account in the local Administrators group on your source and target to ensure that the appropriate permissions for the replicated databases and log files will be available after failover and failback.
Double-Take Availability does not support a SQL default instance that is using non-default ports.
If you are protecting a cluster configuration, ideally you should have only one instance of SQL Server per owning node on your source and target cluster. This decreases the risk of problems when attempting to re-enable protection after failover and failback. The following problems may occur if multiple instances reside on the same owning node.
After failover and failback, you will be able to re-enable protection on the first instance, but when you try to protect subsequent instances, after selecting the source instance, Application Manager will erroneously show that the instance is already protected. Contact technical support to obtain instructions for fixing this issue.
If one instance is failed over, replication will stop on the other protected instances. On the other instances that are not failed over, you will need to perform a difference mirror in order to resume protection.

Application Manager Console—The following limitations apply to the Application Manager Console when protecting SQL.

If you are using a cluster configuration, you should run the console from a target node.
If you want to run the console from a Vista client to protect a cluster, you will need to install the Microsoft Remote Server Administration Tools (RSAT). Installing this package will allow you to install the Failover Cluster Manager component on a Vista client so it can communicate with and administer Windows 2008 clustered environments.