SAP ASE DR Drill without impacting High Availability

[AnilKumar0610]

ABSTRACT

Disasters are inevitable but mostly unpredictable, and they vary in type and magnitude. To minimize disaster losses, it is very important to have a good disaster recovery plan for every business subsystem and operation within an enterprise. Though both concepts are related to business continuity, high availability is about providing undisrupted continuity of operations whereas disaster recovery involves some amount of downtime, typically measured in days. This paper discusses an approach for creating a good disaster recovery plan for a business enterprise.

What is the benefit of setting DR node as Standalone DB while performing DR Drill?

As we know that High availability systems ensure critical applications and services remain operational even during hardware or software failures, power outages, or other disruptions. It guarantees the business continuity and prevents costly downtime. Hence, in the below activity, we have removed the DR Node from HADR system without even impacting the Primary/Secondary Node (HA) which leads to increased Scalability of the systems.

                                                          Figure 1: HA Replication Status

Steps to Disable replication on Sybase DR DB node:

Removing the DR node from the HADR system removes the replication system that is used for replicating data from the HADR system to the DR node. This action drops subscriptions, replication definitions, and connections, and removes the SAP Replication Server instances from the DR node.

Note: Do not use ‘‘sap_teardown’’ or the ‘removehadr’ utility to remove the DR node from the HADR system, because ‘sap_teardown’ teardown the whole HADR system, and ‘removehadr’ invokes ‘sap_teardown’ when executing. 

Remove DR node:

sap_update_replication remove <DRNode-Site3>
go

Clean up replication definition on DR host:

sap_drop_host site3

Drop SAP Replication Server system objects from the master and participating databases: -- Site3.

drop procedure rs_get_lastcommit
go
drop procedure rs_syncup_lastcommit
go
drop procedure rs_update_threads
go
drop procedure rs_initialize_threads
go
drop procedure rs_marker
go
drop procedure rs_check_repl_stat
go
drop procedure rs_ticket
go
drop procedure rs_ticket_v1
go
drop procedure rs_ticket_report
go
drop procedure rs_send_repserver_cmd
go
drop procedure rs_update_lastcommit
go
drop procedure rs_update_threads
go
drop procedure rs_get_thread_seq
go
drop table rs_lastcommit
go
drop table rs_threads
go
drop table rs_ticket_history
go
drop table rs_dbversion
go
drop table rs_mat_status
go

Remove ‘DR_admin’ and ‘DR_maint’ from SAP ASE on the DR host.
Execute following commands on all participated databases:

sp_dropalias <SID>_maint
go

Execute following commands on the master database:
use master
go
drop login <SID>_maint
go
use master
go
sp_droplogin DR_admin
go

                                         Figure 2: Represents the procedure of Dropping DR

Once the Replication Breaks, add host files entries with DR IP Address, FQDN and hostname for VMs and ILBs provided by Linux Team in all Applications. Same entries must maintained under /etc/hosts/ path followed by ‘vi’ command as below:

more /etc/hosts/
vi /etc/hosts
(enter the data and saved it via- Esc:wq!)

                                        Figure 3: Hosts Entries maintained with complete DNS name

Login to the Additional Server and set the Background WPs parameter to ‘Zero’. Also, inside ‘DEFAULT.PFL’ files, change host
name of ‘j2ee/dbhost’, SAPDBHOST and ‘dbs/syb/server’ parameter from Secondary to DR host.
[Note: Do replace the primary/secondary Host name with DR Hostname, nothing should be communicated to our HA servers]

                                            Figure 4: Background WPs parameter changes to 0

Env parameter and R3trans check:

Before Starting Database, we need to take of two Environment variable which needs to be updated with the DR host name i.e., dbenv.csh and sapenv.csh which is located inside ‘/home/<sidadm>’. Below are the parameter name maintained inside above ‘.csh’ file:

/home/<sidadm> → dbenv.csh → dbs_syb_server= (DR Hostname)

                                           Figure 5.1: DR Hostname updated inside dbenv.csh file

/home/ → sapenv.csh → setenv dbs_syb_server (DR Hostname)

                                          Figure 5.2: DR Hostname updated inside sapenv.csh file

Now, start the Database and check the R3trans connectivity whether the connection is working or not from Application to Database

                                                   Figure 6: R3trans -d connectivity check

CONCLUSIONS

This blog discusses an approach for creating a good disaster recovery plan for a business enterprise without even impacting the connection between HA servers.