Wednesday, 12 May 2021

𝘿𝙖𝙩𝙖 𝙂𝙪𝙖𝙧𝙙 𝙎𝙮𝙣𝙘𝙝𝙧𝙤𝙣𝙞𝙯𝙖𝙩𝙞𝙤𝙣 𝙘𝙝𝙖𝙣𝙜𝙚𝙨 𝙞𝙣 𝙙𝙞𝙛𝙛𝙚𝙧𝙚𝙣𝙩 𝙋𝙧𝙤𝙩𝙚𝙘𝙩𝙞𝙤𝙣 𝙈𝙤𝙙𝙚: 𝘾𝙤𝙢𝙥𝙡𝙚𝙩𝙚 𝙜𝙪𝙞𝙙𝙚 !!

                                ░D░a░t░a░ ░G░u░a░r░d░























Data Guard:  It is a setup in which you can have one or more standby database available for a production database. Data guard ensures that another database is available as a copy of production database at almost real time. As a result, we have higher protection for enterprise data and the new database is available very quickly without the need to actually restore and recover from backup. Therefore, data guard offers an excellent disaster recovery solution.

 

§  Architecture:- 

Ø  Primary database – It refers to the production database.

Ø  Standby database – It refers to a copy of primary/Production database. Data guard architecture must have at least one or more than one standby database.


Ø  Log transport service –It manages transfer of archive log files from primary to standby database.


Ø  Network configuration – It refers to the network connection between primary and standby database. This connection is based on Oracle Net.


Ø  Log apply services – It applies archived logs to the standby database.


Ø  Role management services – It manages the role change between primary and standby database.


Ø  Data guard broker – It manages data guard creation process and monitors the data guard.




  §  Data Guard Protection Modes:-

Ø  Maximum Protection Mode:

It specifies that a data change on primary Database is acknowledged only when it is available to standby database at least in the form of redo log information.In this mode, primary database shuts down if at least one standby database cannot be updated.So in MAXIMUM PROTECTION mode, user don't get a commit acknowledgment until transactions are successfully written to at least one standby destination.

Redo Archival Process: LGWR

Network Transmission mode: SYNC

Disk Write Option: AFFIRM

Standby Redo Logs: Yes

Standby Database Type: Physical standby database And Logical standby database.

Ø  Maximum Availability Mode:

 It Specifies that a transaction cannot be committed unless redo logs of at least one standby database are completely synchronized with primary database. However, this mode is more tolerant in terms of fault in updating standby database. It allows the primary database to function temporary in maximum performance mode until such error is resolved and gaps are analysed.


Unlike maximum protection mode, the primary database

will not shut down if a fault prevents it from writing its redo stream to a synchronized standby database. Instead, the primary

database will operate in RESYNCHRONIZATION until the fault is corrected and all log gaps have been resolved. When all log gaps

have been resolved, the primary database automatically resumes operating in maximum availability mode.


Redo Archival Process: LGWR

Network Transmission mode: SYNC

Disk Write Option: AFFIRM / NO AFFIRM

Standby Redo Logs: Yes

Standby Database Type: Physical standby database, Logical standby database and Snapshot standby database.

 

Ø  Maximum Performance Mode:

 It allows slight delay in updating standby database and therefore, it offers certain performance gain. In this mode, transaction can be committed as long as the change is written to an online redo log of the primary database without waiting to transfer the redo log to the standby database.


Redo Archival Process: LGWR or ARCH (ARCH is not recommended)

Network Transmission mode: ASYNC

Disk Write Option: NO AFFIRM

Standby Redo Logs: NO (But it is recommended for Real-Time Apply)

Standby Database Type: Physical standby database, Logical standby database and Snapshot standby database.

 




 §  Services Required on Standby database:

Ø  Fetch Archive Log (FAL) – Standby database requires Fetch Archive Log (FAL) client to request and fetch archive log files from primary database.

Ø  Remote File Server (RFS) – RFS to receive archived log files   from primary database,

Ø  Archiver process – It is used to archive redo logs applied to standby database.

Ø  Managed Recovery Process (MRP) – MRP is used to apply redo logs to the standby database.




§  Role Transition:

v  Role Transition is the change of role between primary and standby database.

It can happen in the following two cases:

Ø  Switchover – When primary database is switched to standby database and standby database is switched to primary database (Vice-Versa).

 

Ø  Failover – Where Standby database can be used as a disaster recover solution in case of a failure in the primary database.



§  Changing the Data Guard Protection Mode:

By default protection mode is MAXIMUM PERFORMANCE. So we will change it to MAXIMUM PROTECTION Mode. But we have to make Primary database in mount stage to change the existing protection mode.

The data protection mode can be set to MAXIMUM PROTECTION on an open database only if the current data protection mode is MAXIMUM AVAILABILITY and if there is at least one synchronized standby database. 

[oracle@PRODDB~]$ sqlplus / as sysdba

SQL*Plus:

Release 19.0.0.0.0 - Production on Wed May 12 01:05:27 2021

Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Version 19.3.0.0.0

SQL> select name,db_unique_name,open_mode,database_role,protection_mode from v$database;

SQL> show pdbs
 
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
 
         3 PRODDB_PDB                     READ WRITE NO
 
SQL> show parameter log_archive_dest_2 

NAME

TYPE

VALUE

log_archive_dest_2

string

service=PRODDR NOAFFIRM LGWR ASYNC VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRODDR

SQL> shut immediate;

 Database closed.

Database dismounted.

ORACLE instance shut down.


SQL> startup mount;

 ORACLE instance started.

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY | PERFORMANCE | PROTECTION};

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

 Database altered.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=PRODDR AFFIRM LGWR SYNC VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE)  DB_UNIQUE_NAME=PRODDR' scope=both;

SQL> show parameter log_archive_dest_2

NAME

TYPE

VALUE

log_archive_dest_2

string

service=PRODDR AFFIRM LGWR SYNC VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRODDR

SQL> alter database open;

Database altered.


SQL> select

name,db_unique_name,open_mode,database_role,protection_mode from v$database.

NAME

DB_UNIQUE_NAME

OPEN_MODE

DATABASE_ROLE

PROTECTION_MODE

PRODDB

PRODDB

READ WRITE

PRIMARY

MAXIMUM PERFORMANCE


Tuesday, 4 May 2021

𝙀𝙍𝙍𝙊𝙍: 𝘾𝙤𝙣𝙩𝙚𝙭𝙩 𝙘𝙧𝙚𝙖𝙩𝙞𝙤𝙣 𝙣𝙤𝙩 𝙘𝙤𝙢𝙥𝙡𝙚𝙩𝙚𝙙 𝙨𝙪𝙘𝙘𝙚𝙨𝙨𝙛𝙪𝙡𝙡𝙮(../𝙟𝙧𝙚/𝙗𝙞𝙣/𝙟𝙖𝙫𝙖: /𝙡𝙞𝙗/𝙡𝙙-𝙡𝙞𝙣𝙪𝙭.𝙨𝙤.2) 𝙬𝙝𝙚𝙣 𝙧𝙪𝙣𝙣𝙞𝙣𝙜 𝙖𝙙𝙘𝙛𝙜𝙘𝙡𝙤𝙣𝙚.𝙥𝙡 𝙤𝙣 𝘼𝙥𝙥𝙨𝙏𝙞𝙚𝙧

    


Solution:

Step 1: Check java

[applprod@apps]$ which java

/usr/bin/java

 

Now, Go to java directory:

[applprod@apps]$ cd $COMMON_TOP/clone/jre/bin

 

[applprod@apps bin]$  ls

ControlPanel  java  java_vm  javaws  jcontrol  keytool  orbd  pack200  policytool  rmid  rmiregistry  servertool  tnameserv  unpack200

 

[applprod@ndrapps ~]$ mv java java_old

 

[applprod@apps bin]$ ln -s /usr/bin/java java



Step 2:  Now,  Check Again->  Run perl adcfgclone.pl appsTier 


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Issue Resolved...!!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~