Using UNICOM Intelligence Interviewer with a SQL Server cluster

Interviewer - Server > Architecture > Data Service tier > Using UNICOM Intelligence Interviewer with a SQL Server cluster

UNICOM Intelligence Interviewer can be used with an Active-Passive SQL Server cluster configuration. This is an SQL Server cluster in which only one instance of SQL Server is running on one of the physical servers in the cluster. The other physical servers do nothing apart from waiting to take over should the primary node fail.

Active-passive SQL Server cluster configuration

UNICOM Intelligence Interviewer cannot be used with an Active-Active SQL Server cluster configuration (that is, where SQL Server is running on both nodes of a two-way cluster, with each copy of SQL Server acting independently).

Each SQL Server in the cluster has its own virtual name and virtual TCP/IP address. The name and address is shared by both servers in the cluster, so when UNICOM Intelligence Interviewer is configured to write to a clustered SQL Server it uses the virtual name as the SQL Server name. If the primary server fails, a failover procedure is initiated which transfers control to the secondary SQL Server. The effect on respondents is as follows:

▪Interviews running when failover occurs continue as normal, and respondents should not be aware of the failover. Data for these respondents continues to be written to the interview cache file in the shared cache directory. The data in the cache file is automatically written to the database when the connection to SQL Server is restored.

▪Respondents attempting to start a new interview will be issued with the 'Unable to service request' message.

When the failover procedure finishes and the server connections are reestablished, then new interviews can start and data is written directly to the project's database on the second SQL Server computer.

The failover procedure may last several minutes (the exact amount of time depends on the number and sizes of the databases on SQL Server, and how active they are), and during this time clients and applications will be unable to access the SQL Server so there will probably be a small amount of downtime.