Skip to Content
Author's profile photo Manuel Martins

SAP NetWeaver on SQL Server 2012 AlwaysON for HA and DR


Main Data center + DR

3 physical servers for SQL Server (2 on main DC + 1 DR) AlwaysON

SAP Application Servers hosted under a VMWARE cluster

SAP Netweaver 7.40 SR 2 ABAP, media list:

51047515        SQL Server 2012

51048524_1    NW 7.4 SR2 Installation Export

51048524_2    NW 7.4 SR2 Upgrade Export 1/2

51048524_3    NW 7.4 SR2 Upgrade Export 2/2

51048524_4    NW 7.4 SR2 Language 1/2

51048524_5    NW 7.4 SR2 Language 2/2

51049350_10  SAP Kernel 7.42 Windows Server on x64 64bit

51045590       NW AS ABAP for Suite/NW 7.4 – Enhancement Packages

Software minimum requisites are:

Windows 2008R2

SQL Server 2012

Also, a valid Active Directory Domain is mandatory because the Failover Cluster resources and the SAP distributed AS.

Server names:

SRVDB1 (SQL Server node 1 – main DC)

SRVDB2 (SQL Server node 2 – main DC)

SRVDB3 (SQL Server node 3 – DR)

SRVSAS1 (Central Instance)

SRVSAS2 (Primary Application Server)

SRVSAS3 (Additional Application Server installed on DR)

Relevant SAP notes:

The SAP High Availability is done inside the main DC using the HA features of the VMWARE cluster. Also the VM hosting the CI will be replicated to the DR site where another VMWARE cluster is running.

After OS installed and Failover Cluster nodes configured, install SQL Server.  On the main DC, the 2 SQL Server nodes can be pure AlwaysON AG or a FCI. On the first case you have independent storage; on the second one the storage is shared. The replication to the DR will be done with an Availability Group (AG). Microsoft support both scenarios: pure AlwaysON AG or a mix of FCI and AG. The differences between them are:

Nodes within an FCI

Replicas within an availability group

Uses WSFC cluster



Protection level



Storage type



Storage solutions

Direct attached, SAN, mount points, SMB

Depends on node type

Readable secondaries



Applicable failover policy settings

  • WSFC quorum
  • FCI-specific
  • Availability group settings3
  • WSFC quorum
  • Availability group settings

Failed-over resources

Server, instance, and database

Database only

1 While the replicas in an availability group do not share storage, a replica that is hosted by an FCI uses a shared storage solution as required by that FCI. The storage solution is shared only by nodes within the FCI and not between replicas of the availability group.

2 Whereas synchronous secondary replicas in an availability group are always running on their respective SQL Server instances, secondary nodes in an FCI actually have not started their respective SQL Server instances and are therefore not readable. In an FCI, a secondary node starts its SQL Server instance only when the resource group ownership is transferred to it during an FCI failover. However, on the active FCI node, when an FCI-hosted database belongs to an availability group, if the local availability replica is running as a readable secondary replica, the database is readable.

3 Failover policy settings for the availability group apply to all replicas, whether it is hosted in a standalone instance or an FCI instance.

Using SWPM, the CI is installed on the appropriate VM. No connection to DB is needed at this time. Once finished, the SAPMNT share will be visible as \\SRVSAS1\SAPMNT.

Then we should logon on the first SQL Server node and start SWPM to install the DB. On this step, the SWPM will only load the SAP DB (tables, views, SP, jobs) and will not create any extra folders or files. The SWPM will need the path to the SAPMNT share to read and update the DEFAULT profile. After the process is completed, the profile will point to the SQL Server node 1 physical name.

After the DB is created, then the AG can be created and the SAP DB replicated. After the listener created, the profile need to be adjusted accordingly (please see the SAP notes posted here). To help create the AG, please check this link:

The next process is the PAS installation and additional AS if needed. The AS installed on DR will be part of the logon group, but will be parametrized to have very low capabilities ensuring that will not be used on normal conditions.

In case of main DC failure, the VM with the CI is booted on the DR site, the IP address is changed and the DNS record reconfigured.

SCN relevant discussions:

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Alan Zarza
      Alan Zarza

      Hi Manuel,

      I just saw your answer in this thread ( because right now I am performing a SolMan 7.2 installartion in a MS SQL cluster, and I also have the doubt about how this should be installed. For what you wrote, I understand that  you used Distributed Option for the DB Instance right? In my case we have three nodes in MS SQL cluster, I am executing SWPM in node 3, so could you kindly answer if there is there anything else I have to do in the other nodes? and in the Application Server? How will the application server know where to connect if for any situation other node of the db cluster has to take-over?

      Thank you,


      Author's profile photo Mohammed Abunaja
      Mohammed Abunaja

      Hi Manuel Martins ,

      I want to setup DR for my current SAP Landscape please find attached my scenario and our current SAP Landscape diagram. I Would highly appreciate if you guide and propose best solution for my SAP Landscape.


      Author's profile photo Manuel Martins
      Manuel Martins
      Blog Post Author

      From your picture, I see that you are planning only a DR for the ERP.

      Because you haven't shared storage, the simple and cheap way to replicate the DB is to use AlwaysON with Availability Groups.

      Then you can install a new SAP Application Server on the DR server (Distributed mode on SAP language) and keep it turned off. Or keep it on, but modify the SMLG configuration in order to let the users connect to it only in last resort.