Contents
Supporting MS SQL Server Failover
Using Database Mirroring
with Mertech Flex2SQL for MS SQL Server

Overview

How Does it Work?

SQL Server Setup

Using Mirroring Support

Contact Information
© 2006 - 2013 Mertech Data Systems, Inc. All rights reserved. This document is for informational purposes only.
Mertech makes no warranties, expressed or implied, in this document.
Microsoft, Windows, and SQL Server are registered trademarks of Microsoft Corporation
DataFlex is a trademark of Data Access Worldwide, Inc.
Other trademarks and trade names mentioned herein are the property of their respective owners.
Overview
Microsoft introduced database mirroring in SQL Server 2005 to increase database availability.
Database mirroring maintains two copies of a single database on different server instances. One
instance is the primary or principal server, the other instance is the standby or mirror server. If the
principal server goes down the mirror server can take over with no loss of committed data.
Fast failover with minimal data loss has traditionally involved higher hardware cost and greater
software complexity. Database mirroring, however, can fail over quickly with no loss of committed
data, does not require proprietary hardware, and is easy to set up and manage.
 SQL Server 2005 SP1 or above is required to use mirroring.
How Does it Work?
All SQL Server databases record data changes in a transaction log before any changes are made to
the actual database. In database mirroring, the principal server writes the transaction log buffer to
disk and simultaneously sends it to a mirror server. The transaction log records are then replayed on
the mirror server to keep the two database instances in sync. A third (optional) server witnesses the
health of the principal and mirror servers to enable automatic failover.
tn
Wi
n
Pri
ci p
es
s
al
Optional
Mi
rro
r
Data Flow
Server Roles
Principal
The originating server, the one that sends the transaction log to the standby SQL Server instance.
The principal database is available to an SQL client during normal operation.
Mirror
The standby SQL Server instance, the one that receives the transaction log from the principal server.
The mirror database is not available to an SQL client unless the principal server is down and the
mirror server has taken over.
Partner
The principal and mirror servers are considered partners in maintaining the mirrored database.
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
-1-
Witness
The witness server's role is to allow the mirror server to recognize that the principal server is down
and to take over. The witness server does not have a database of its own.
The principal, mirror, and witness servers all send heartbeat messages to each other to monitor their
connection status. If the partners become disconnected from each other, they rely on the witness to
make sure that only one of them is currently serving the database. If a mirror server loses its
connection to the principal server, the mirror server contacts the witness to determine whether the
witness has lost its connection to the principal server:
•
If the principal server is still connected to the witness, the principal server continues to serve the
database while accumulating log records to send the mirror server when the partners reconnect.
•
If the witness is also disconnected from the principal server, the mirror server initiates an
automatic failover.
tn
Wi
n
Pri
ci p
es
s
al
tn
Wi
Mi
All Servers Alive
rro
r
n
Pri
ci p
es
al
s
tn
Wi
Mi
rro
r
n
Pri
ci p
es
s
al
Principal Remains in Charge
Mi
rro
r
Mirror Takes Over
The requirement that at least two of the server instances be connected is known as quorum. Quorum
makes sure that the database can only be served by one partner at a time.
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
-2-
Operational Modes
There are three operational modes in SQL Server mirroring:
High Availability
The High Availability operating mode supports maximum database availability with automatic failover
to the mirror database if the principal database fails. It requires that you set safety to FULL and
define a witness server as part of the database mirroring session. The database mirroring operation is
synchronous, a transaction is not completed on the principal server until the principal server receives
an acknowledgement from the mirror server that the transaction log record has been recorded. Once
this occurs, the client application gets confirmation that the transaction was committed. A witness
server is used to monitor the status of the principal and mirror servers. If the principal server
becomes unavailable, and the mirror server and witness are connected, the mirror server can initiate
take over.
tn
Wi
n
Pri
ci p
es
s
al
Mi
rro
r
2. Log
3. ACK
1. Update
4. Comitted
High Protection
The High Protection operating mode also has transactional safety set to FULL and the database
mirroring operation is synchronous. However, there is no witness server as part of the mirroring
session. In this mode only a manual failover is possible because the partners have no way to
determine each other’s status.
n
Pri
ci p
al
Mi
rro
r
2. Log
3. ACK
1. Update
4. Comitted
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
-3-
High Performance
In the High Performance operating mode, transactional safety is OFF and the transfer of log records is
asynchronous. The principal server does not wait for an acknowledgement from the mirror that all
transaction log records have been recorded on the mirror. The mirror does its best to keep up with
the principal, but it is not guaranteed at any point in time that all the most recent transactions from
the principal will have been hardened in the mirror's transaction log.
n
Pri
ci p
al
Mi
rro
r
3. Log
1. Update
2. Comitted
Database Mirroring Feature Support by SQL Server 2012
Enterprise
Yes
Business
Intelligence
Yes
(Safety Full
Only)
Standard
Web
Yes (Safety
Full Only)
Witness
only
Express
with
Advanced
Services
Express
with Tools
Express
Witness
only
Witness
only
Witness
only
 Refer to Microsoft documentation for additional information and a description
of feature support by server addition.
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
-4-
SQL Server Setup
Create the Databases
The principal server, mirror server, and (optional) witness must be hosted by separate server
instances.
•
The principal and mirror server instances must be running on the same version and edition of
SQL Server.
•
The mirror database must have the same name as the principal database.
•
All the database users should have logins on the mirror server.
 Our example uses SQL server instances, LEIA\MAIN and LEIA\MIRROR
running SQL Server 2008.
Enable FULL Recovery Mode
Both databases must use the FULL recovery model. Log records that result from bulk-logged
operations cannot be sent to the mirror database.
Check to see if FULL recovery mode is enabled:
Select name, recovery_model_desc
FROM sys.databases
WHERE name = 'main';
GO
If not, set FULL recovery mode:
USE master;
GO
ALTER DATABASE main SET RECOVERY FULL;
GO
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
-5-
You can also use SQL Server Management Studio:
1.
2.
In Object Explorer, click the server name to expand the server tree.
Right-click the database.
3.
Select Properties.
4.
Select Options in the Select a page pane.
5.
Select Full Recovery model using the drop-down arrow.
6.
Click OK.
Create Endpoints
Configure endpoints (port listeners) where the principal and mirror are going to establish
communication.
Principal Endpoint:
USE main;
GO
CREATE ENDPOINT MirroringEndPoint_ Principal
STATE=STARTED
AS TCP (LISTENER_PORT=10111)
FOR DATABASE_MIRRORING (ROLE=PARTNER) -- Enabled as Partner only
GO
Mirror Endpoint:
USE main;
GO
CREATE ENDPOINT MirroringEndPoint_Mirror
STATE=STARTED
AS TCP (LISTENER_PORT=10112)
FOR DATABASE_MIRRORING (ROLE=ALL) -- enabled as Witness or
Partner
GO
To inspect your created endpoints:
SELECT name, role_desc, state_desc
FROM sys.database_mirroring_endpoints;
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
-6-
Backup the Principal Database
 Important: The principal and mirror backup (log and data) should be
located in the same exact location (e.g. C:\backup\data.bak).
Issue a full backup of the database and transaction log:
USE main
GO
BACKUP DATABASE main
TO DISK = 'C: \main_Data.bak'
WITH FORMAT
GO
BACKUP LOG main
TO DISK =
'C:\main_Log.bak'
WITH FORMAT
You can also use SQL Server Management Studio:
1.
In Object Explorer, click the server name to expand the server tree.
2.
Right-click the database.
3.
Select Tasks | Back Up.
4.
In the Backup type list box, select Full.
5.
Click Add, enter the backup file name, then click OK.
Restore the Backup to the Mirror
Restore the backup to the mirror server using the WITH NORECOVERY option.
RESTORE DATABASE main
FROM DISK='C:/main_data.bak' WITH REPLACE,NORECOVERY
Also restore the log WITH NORECOVERY option.
RESTORE LOG main
FROM DISK='C:/main_Log.BAK' WITH N ORECOVERY
You can also use SQL Server Management Studio:
1.
2.
In Object Explorer, click the server name to expand the server tree.
Right-click the database.
3.
Select Tasks | Restore | Database.
4.
On the General page, use the Source section to specify the source and location of the
backup sets to restore.
5.
On the Options page, select Recovery state RESTORE with NORECOVERY.
 This mirror database is no longer available to open or make changes; it
is now a mirror database and can only be used for mirroring.
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
-7-
Enable the Mirroring Session
Setting up a database mirroring session requires a server network address for each of the server
instances.
 Before you can specify a port in a server network address, the database
mirroring endpoint must exist on the server instance
To identify the port currently associated with database mirroring endpoint of a server instance:
SELECT type_desc, port FROM sys.tcp_endpoints
Start the database mirroring session on the mirror:
ALTER DATABASE main
SET PARTNER = 'TCP://127.0.0.1:10111'
GO
Start the database mirroring session on the principal:
ALTER DATABASE main
SET PARTNER = 'TCP://127.0.0.1:10112'
GO
Obtain general information:
SELECT
DB_NAME(database_id) AS 'DatabaseName'
, mirroring_role_ desc
, mirroring_safety_level_desc
, mirroring_state_desc
, mirroring_safety_sequence
, mirroring_role_sequence
, mirroring_partner_instance
, mirroring_witness_name
, mirroring_witness_state_desc
, mirroring_failover_lsn
FROM sys.database_mirroring
WHERE mirroring_guid IS NOT NULL;
 Refer to Microsoft documentation for additional details.
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
-8-
Using Mirroring Support in Mertech Flex2SQL
DataFlex developers using Mertech’s Flex2SQL can take advantage of the SQL Server Database
Mirroring feature to develop high-availability applications. To use this feature, the developers need to
use a new command, SET_MIRROR_SERVER in their login module. This identifies the mirrored
server to the driver which in turns negotiates the communication with the server. If the principal
server fails, the driver automatically connects to the mirror server and continues operation. This does
not require any additional code in DataFlex to check for a lost connection.
 Note: Any non-committed transactions need to be retried by the application.
A VDF application normally retries the transaction, but please consult the VDF
manual for details.
Syntax
SET_MIRROR_SERVER to < Server name> <Main server >
Example
To make DataFlex work with mirroring and Mertech's driver, you can create a program that logs in,
sets the mirror, and then executes your application.
loginchain.src
use mertech.inc
string p1 p2
Load_Driver "SQL_DRV"
// Set the Mirror Server
SET_MIRROR_SERVER to "MACHINE \MIRROR" "main"
If (Err) showln "Error setting failover Server"
// Login into the main server
login "MACHINE\MAIN" "user" "password" "sql_drv"
cmdline p1
cmdline p2
chain (p1 + " " + p2)
Compile the login program and run it:
dfcomp loginchain.src
dfrun logchain your_application_executable
 Note: The GET_MIRROR_SERVER command is also available. Syntax:
GET_MIRROR_SERVER to <VAR>.
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
-9-
The Flex2SQL automatic login dialog also has an option to set the mirror server and database:
If you have a personalized login dialog, using the SET_MIRROR_SERVER command is
the best option.
 Note: The mirror server and mirror database can also be provided as
settings in the Mertech INI file.
Testing Your Mirrored Environment
To verify that your Visual DataFlex application is running in a mirrored environment:
1.
Shutdown the main server.
2.
Start your application.
 A driver trace will show that your application logged into the mirror server.
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
- 10 -
3.
Examine stored data.
4.
Make changes to stored data.
5.
Restart the principal server.
6.
Fail over to the principal server.
ALTER DATABASE main
SET PARTNER FAILOVER
GO
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
- 11 -
7.
Examine the changes in SQL Server Manager.
Conclusion
Using SQL Server Mirroring, you can ensure that your application is up 24/7. If your principal server
goes down, failover to a standby server can occur automatically without any loss of data and
transparently to your users.
Mertech’s Flex2SQL for MS SQL Server takes advantage of the MS SQL mirroring support and enables
a DataFlex application to be used in a high-availability environment.
Contact Information
If you would like to know more about Mertech’s products, please visit our website
www.mertechdata.com or contact us at:
Corporate Head Office
Mertech Data Systems, Inc.
18503 Pines Boulevard, Suite 312
Pembroke Pines, FL 33029
USA
Tel: +1 (954) 585 9016
Fax: +1 (866) 228 1213
California Office
Mertech Data Systems, Inc.
114 East Shaw Avenue, Suite 100
Fresno, CA 93710
USA
Copyright © 2013 Mertech Data Systems, Inc. All Rights Reserved.
- 12 -