Journal of Global Research in Computer Sciences
MenuISSN: 2229-371X
ISSN: 2229-371X
| Gurpreet Singh*1, Sikander Singh2 University College OF Engineering, Punjabi University, Patiala, Punjab, India |
| Corresponding Author: Gurpreet Singh, E-mail: ggurpreetsinghh658@gmail.com |
| Related article at Pubmed, Scholar Google |
Visit for more related articles at Journal of Global Research in Computer Sciences
The Data Guard is best management monitoring tool provided by ORACLE to reduce the failover time when Primary system goes down. Data Guard helps in transferring the redo data files to the Standby site. Data Guard maintains Standby databases as transactional consistent copies of production database. When the Primary system fails due to some error the Data Guard can switch to any Standby database. The tight integration of Oracle Data Guard with Oracle Database provides a unique level of data protection that is impossible to achieve with any other solution. In this paper we try to achieve zero down time and maintain user connectivity to Primary system active by using Data Guard Observer. Our approach is based on changing the parameters of TNS file and prevent the users to reconnect to Primary database again and again after Primary system failure. Keywords: Switchover, Failover, Logical Standby Database, Data Guard Broker, Log Shipping.
Keywords |
| Switchover, Failover, Logical Standby Database, Data Guard Broker, Log Shipping. |
INTRODUCTION |
| Data Guard provides an extensive set of data protection and disaster recovery features to help you to survive disasters, human errors, and corruptions that can incapacitate a database. Based on business requirements, these features can be advantageously combined with other Oracle9i high availability and disaster recovery features for enhanced levels of high availability and disaster protection. The primary database is the production database, and the standby database is the remote, Secondary database[1]. Oracle Data Guard is an option to the Oracle RDBMS. It maintains a standby database as an alternative database to primary database. In the event of failure, the standby database can be activated and assume the primary database role. Oracle physical standby protects from user and logical errors by maintaining consistent copies of redo data of the primary database at the standby database. The Oracle physical standby database is kept synchronized with the primary database by using media recovery to apply redo data that was generated on the primary database Redo Apply[2]. The logical standby database is kept synchronized with the primary database by applying redo data into SQL statements. After that, those SQL statements are executed against the standby database [16]. |
| Overview of Oracle Data Guard |
| In a Data Guard configuration, a production database is referred to as a primary database. Using a backup copy of the primary database, you can create from one to nine physical and logical standby databases and incorporate them in a Data Guard configuration. Primary and standby databases can be running on a single node or in a Real Application Clusters environment [1]. Fig 1 depicts the architecture of Data Guard. |
 |
| Every standby database is associated with only one primary database. A single primary database can support multiple physical standby databases, logical standby databases, or a mix of both in the same configuration. Data Guard facilitates Switchover and Failover operations between two sites[10]. |
| Benefits of Data Guard |
| Data Guard provide following benefits: |
| 1. Maximum Data Availability |
| 2. Complete Data Protection |
| 3. Efficient Utilization of system resources |
| 4. Flexibility in data protection |
| 5. Automatic Gap detection and resolution |
| 6. Centralized management scheme` |
| 7. Integrated with Oracle database |
| Data guard ensures maximum availability by performing Switchover and Failover Operations. Standby database provide complete data protection by backup operation and efficiently utilization by performing backup, restoration tasks. Number of available standby databases allows flexibility in system protection[3]. |
| Features of Data Guard |
| Logical standby database |
| Until now, there has been only the physical standby database implementation, in which the standby database can be in either recovery mode or in read-only mode. A physical standby database is physically equivalent to the primary database, and, while the database is applying logs it cannot be opened for reporting and vice versa. With logical standby databases, you can have the database available for reporting and applying the logs to the standby log at the same time[9]. |
| Database protection mode |
| The database administrator (DBA) can place the database into one of the following modes: |
| a. Maximum protection |
| b. Maximum availability |
| c. Maximum performance |
| Cascading standby databases |
| A cascading standby is a standby database that receives its redo information from another standby database and not from the original primary database. A physical or logical standby database can be set up to send the incoming redo information to other remote destinations in the same manner as the primary database, with up to one level of redirection[12]. |
| Data Guard Broker |
| The broker now supports: |
| a. Up to nine physical or logical standby destinations |
| b. Failover and switchover operations[1] |
| Data Guard Broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations. All management operations can be performed locally or remotely through the Broker's easy-to-use interfaces: Oracle Data Guard Manager, which is the Broker's graphical user interface (GUI) and the Data Guard command-line interface (CLI)[3]. With these new features Data Guard enhances maximum availability of data scheme and it also decrease the workload of primary database by using cascading standby database by not indulging it in sending more redo data files. Data files are fetched from other standby system and primary will have lesser workload so primary can handle complex queries easily and hence reduce the network traffic from primary to standby. The easy to use interface makes it enhanced data protection system. |
RELATED WORK |
| Rab Nawaz[4] on his scrutiny gives the insight of high availability of data by using Data Guard. Rab and his companion Tariq Rahim shows how Data Guard is providing high availability with offloading workload to one or more standby databases and providing the opportunity to query real time data in standby databases. Related research was also done by Xiaochunn woo[5]. Woo with his companions show how Research and Implementation done on High-Availability Spatial Database Based on Oracle. The above researches show the maximum availability of database. Our research will show enhancement by coding the observer parameters and retains the Client connectivity and zero Failover by using the concept of Observer. |
DATA GUARD WORKING METHODOLOGY |
| A Data Guard configuration includes a production database, referred to as the primary database, and up to 30 standby databases. Primary and standby databases connect over TCP/IP using Oracle Net Services. Data Guard automatically synchronizes the primary database and all of its standby databases by transmitting primary database redo the information used by Oracle to recover transactions and applying it to the standby database[6]. The three main operations performed by Dataguard are: |
| 1. Failover: A fast-start failover occurs when the Observer and the Standby Database both lose contact with the production database for a period of time that exceeds the value set for Fast Start Failover Threshold, and when both parties agree that the state of the configuration is synchronized. An optimum value for Fast Start Failover Threshold weighs the trade-off between the fastest possible failover (thus minimizing downtime), and unnecessarily triggering failover due to fleeting network irregularities or other short-lived events that do not have material impact on availability[7]. |
| 2. Switchover: In some cases, a switchover operation requires that you reconfigure the original primary database as a standby database to the new primary database[11]. However, it is possible to eliminate this requirement in configurations with multiple standby databases without violating the database protection mode. Steps to perform Switchover are: |
| i) Modify the SAT (standby) databaseâÃâ¬ÃŸs initialization parameter file, sat_init.ora, to ensure that the SAT database can function as a primary database. |
| ii) Modify the initialization parameter file, hq_init.ora, for the HQ database to ensure that the HQ database can function as a logical standby database. |
| iii) Switch over the HQ (primary) database to the logical standby role by querying that database is currently primary database with V$DATABASE view. |
| iv) Alter database commit to switchover to logical standby. |
| v) Switch over the SAT database to the primary[2]. |
| 3. Log Shipping and Apply Services Options: |
| i) Delayed Apply: |
| When a primary database is open and active transactions are in progress, redo log data is generated and shipped to standby sites. It is possible to delay the application of redo data already received at one or more standby databases. The ability to delay the application of changes to standby databases enables not only the protection of production data from data center disasters, but also provides a window of protection from user errors or corruption[13]. |
| ii) Automatic Resynchronization : |
| Oracle Data Guard can smoothly handle network connectivity problems that temporarily disconnect the standby database from the primary database. In this case transactions are captured locally at the primary database until a standby is available. When connectivity to the standby is re-established, the accumulated logs are automatically shipped to the standby, until the standby has resynchronized with the primary and all archive gaps are resolved[3]. |
| Observer Configuration |
| 1) On the Observer site make 3 entries of primary, standby and observer site in the host entries. |
| 2) Using Oracle network configuration assistant make 2 services, one for primary site and other for standby site: primary and standby. |
| 3) Enable the flashback on Primary and Standby sites. To enable the flashback, the databases should be in open stage. SQL>alter database flashback on; |
| 4) On the standby site bring the database to mount stage and alter system with set log archive destination. |
| 5) On the primary site bring the database to mount stage and write: |
| SQL>alter database set standby database to maximize availability; |
| 6) Restart both the Primary and Standby databases to open stage and check their protection mode: |
| SQL>select protection_mode from v$database; |
| PRIMARY: MAXIMUM AVAILABILITY |
| STANDBY: MAXIMUM PERFORMANCE |
| 7) Now on site 3 execute the command in the DGMGRL prompt: oracle@server3>dgmgrl |
| 8) Connect to primary service |
| DGMGRL>connect sys/sys@primary; |
| 9) Execute the following commands in the Data Guard Prompt: |
| DGMGRL>edit database „standbyâÃâ¬ÃŸ set property „logxptmodeâÃâ¬ÃŸ=âÃâ¬ÃŸsyncâÃâ¬ÃŸ; DGMGRL>edit database „primaryâÃâ¬ÃŸ set property „logxptmodeâÃâ¬ÃŸ=âÃâ¬ÃŸsyncâÃâ¬ÃŸ; |
| DGMGRL>edit configuration set protection mode as maxavailability;DGMGRL>edit database „primaryâÃâ¬ÃŸ set property set faststartfailovertarget=âÃâ¬ÃŸstandbyâÃâ¬ÃŸ; |
| DGMGRL>enable fast_start failover; |
| 10) To check the database configurations, write on observer: DGMGRL>show database primary. |
| DGMGRL>show database standby |
| 11) To start Observer |
| DGMGRL>start observer |
| 12) Power off the Primary database after starting the observer. This is considered as failover of the Primary Database. The Observer takes some time and detects this failure. On detecting the failure of the Primary database, it automatically makes the standby database as primary and makes it available for the users[2]. |
IMPLEMENTING OBSERVER CONFIGURATION AND CHANGING PARAMETERS OF CLIENT TNS |
| The Observer configuration is done on the separate system from Primary and Standby database systems. When we create the database and net service between all the systems and Observer configuration are done then we just need to start the server when both primary and standby are in transmission or receiving mode so when the power loss or failure of primary system occurs, Observer will start performing its role. |
 |
| On Primary and Standby sites Data Guard uses DMON process (Data Guard Broker Monitor Process). The DMON process work cooperatively to manage the primary and standby databases as a unified configuration. The DMON processes work together to execute switchover and failover operations, monitor the status of the databases, and manage log transport services and log apply services[8]. |
| Client TNS parameter file |
 |
| After changing the parameters of client TNS file we are ready to backup the database with client connectivity activation. By adding balancing the load and changing other parameters we can handle any kind of failure. |
FINAL RESULTS |
| Performing failover |
| To check whether our Standby databases are working properly and to verify that switchover to Standby databases or new Primary databases is actually betided or not, we intentionally power off our Primary database and Observer will start initiating switchover and Standby will be new Primary. |
 |
| Initiating Standby system |
 |
| After the failure of Primary database the Clients which are connected to the old primary system do not need to reinitiate the connection manually again, the transactions which they have started will not be rollback. The transaction will pause for a while, depending upon the system memory and will start from that point at which failure occurred. The motive of our research is to retain the client connectivity active with zero Failover is achieved. Because there is no data loss and neither the connectivity of Client is lost. So Data Guard Broker improves the system performance maintaining zero Failover[15]. |
DISCUSSION AND CONCLUSION |
| After watching performance of Oracle Dataguard with Observer we have experienced that with the help of Observer the management of data is very easy and to overcome any failure of primary data can be done by less human interaction. Data Guard is more efficient than any Data management tool exist till now because other tools require much more manual interaction. Before Dataguard the manual management of data is done, Then Recovery Manager and Restore options came to minimize the data loss. After that Oracle Dataguard proves to be a boon for Data Management but some manual work still requires in it. Then Observer improves the performance by monitoring the available standby and choosing standby appropriately and also decreases human interaction. And it is considered the best tool to utilize data and retrieve transactions but as technology is developing new tools each day, it is possible to enhance Dataguard Observer technique of switchover and Failover, Still after so many efforts it require human coding and modification of parameters by manager to function correctly. The further enhancement can be done by minimizing the connection establishment time. While synchronizing the Primary, Standby, Observer site is quite complex process. We need to create data services and start the listener then we can start the observer after that. So scripts can be used to reduce this work and Observer performance will be improved also. So we can expect in coming years a much improved and less complex version of Dataguard Observer which will minimize the human efforts and have stronger impact on Dataguard techniques. |
References |
|