Test Case 3 - Oracle RAC and Dataguard

Test Case 3

 1-      Objectives:

Purpose of this test is to verify high availability and active-active configuration of the RAC Nodes.

 2-      Test Diagram:

 3-      Procedure:

 Shut down / disconnect one node manually

Test Case 2 - Oracle RAC and Dataguard

 Test Case 2

   1-      Objectives:

Purpose of this test is to check the  active-    passive configuration of database with role transition.

   2-      Test Diagram:

   3-      Procedure:

      Perform a switch over command from data broker CLI for role transition.

  4-      Expected Result:

The Status and Role of primary and standby database will be interchanged.

Test Cases - Oracle RAC and Dataguard

As a tech guy no one like to write document for client or any one they just love to do work. same thing happened with when I need test cases for Oracle 12c RAC with Dataguard and Broker. I searched alot but didn't find the thing I want so, I have write those test cases for you guys to help you. Test Case is the criteria to check the configuration and with coming result. 

Test Cases 1 for Oracle Data Guard High Availability(HA)

      1-      Objectives:

Purpose of Data Guard test is to verify high availability and active-active configuration of the both standby and primary databases.

Problems which can be Occur in Switching Over to a Standby Database

 Below are some common problem arrives when we commit switch over the 

most common problems are as follows

Switchover Fails Because Redo Data Was Not Transmitted

If the switchover does not complete successfully, you can query the SEQUENCE# column in the V$ARCHIVED_LOG view to see if the last redo data transmitted from the original primary database was applied on the standby database. If the last redo data was not transmitted to the standby database, you can manually copy the archived redo log file containing the redo data from the original primary database to the old standby database and register it with the SQL ALTER DATABASE REGISTER LOGFILE file_specification statement. If you then start log apply services, the archived redo log file will be applied automatically. Query the

Handling Logical Standby Database Failures

An significant device for management ordered standby database flops is the  

DBMS_LOGSTDBY.SKIP_ERROR procedure. Depending on how significant a table is, 

you might desire to manage one of the following:

• Ignore flops for a table or exact DDL
• Associate a retained method with a filter so at runtime a conclusion can be                                        made about skipping the declaration, executing this declaration, or executing a                         replacement statement

Taking one of these activities stops SQL Apply from stopping. Later, you can query the DBA_LOGSTDBY_EVENTS outlook to find and correct any difficulties that exist.

Problem In LogFile DestinatioProblem In LogFile Reachability Oracle Databasen Oracle Database

If you stipulate REOPEN for an OPTIONAL location stayed at, it is probable for the Oracle database to reuse online redo log records even if there is an wrongdoing archiving to the location stayed at in question. If you stipulate REOPEN for a MANDATORY location stayed at, log transport services stall the main database when redo written knowledge not able to be productively transmitted.

The REOPEN assign is demanded when you use the MAX_FAILURE attribute

Transaction Management with LogMiner and Flashback Data Archive

LogMiner is an often dismissed yet very strong implement in the Oracle Database. It is employed to extract DML assertions from the redo log files—the primary SQL that produced the transaction and even the SQL that can change back the transactions. (For an introduction to LogMiner and how it works, cite to my Oracle Magazine portion "Mining for Clues.") Until now, this strong implement was ordinarily under-appreciated due to the deficiency of a more simple interface. In Oracle Database 11g, even so, Oracle Enterprise Manager has a graphical interface to extract transaction from the redo logs employing LogMiner,

Data Guard/Broker Configuration Oracle 10g

PRIMARY SITE: (Information)

•                      Machine IP: 192.168.1.10
•                      Database name (db_name): ORCL
•                      Database Unique Name (db_unique_name): primary
•                      TNS Service Name: to_standby (Through this service, the primary machine will be connected to   STANDBY machine)

STANDBY SITE: (Information)

•                      Machine IP: 192.168.1.20
•                      Database name (db_name): ORCL
•                      Database Unique Name (db_unique_name): standby
•                      TNS Service Name: to_primary (Through this service, the standby machine will be connected to PRIMARY machine)