Patching fails during relink , with error code 102 :: Fatal error: Command failed for target `javavm_refresh'

Patching fails during relink , with error code 102 :: Fatal error: Command failed for target `javavm_refresh' 


REFER DOC ID (Doc ID 2002334.1) for the details


ERRORS like

Caused by: java.lang.Error: Re-link fails on target "javavm_refresh".

Patching fails during relink , with error code 102 :: Fatal error: Command failed for target `javavm_refresh' 

Stack Description: java.lang.RuntimeException: Re-link fails on target "javavm_refresh".

Symptoms
Patch Apply fails with below error:

Symptom 1:

Make failed to invoke "/usr/ccs/bin/make -f ins_rdbms.mk javavm_refresh ioracle ORACLE_HOME=/u01/app/oracle/product/db/12.1.0.2"....'Can't locate File/Copy.pm in @INC (@INC contains: ../lib/site_perl/5.14.1/sun4-solaris-thread-multi-64 ../lib/site_perl/5.14.1 ../lib/5.14.1/sun4-solaris-thread-multi-64 ../lib/5.14.1 .) at /u01/app/oracle/product/db/12.1.0.2/javavm/install/update_javavm_binaries.pl line 62.
BEGIN failed--compilation aborted at /u01/app/oracle/product/db/12.1.0.2/javavm/install/update_javavm_binaries.pl line 62.
make: Fatal error: Command failed for target `javavm_refresh'

The following make actions have failed :

Re-link fails on target "javavm_refresh ioracle".



Symptom 2:

 Make failed to invoke "/usr/bin/make -f ins_rdbms.mk javavm_refresh patchset_opt_all ioracle
ORACLE_HOME=/u01/app/oracle/pro
duct/12.1.0/db_1"....'make: perl: Command not found
make: *** [javavm_refresh] Error 127
 

Cause
PERL5LIB environment variable is not set
 

Solution
Oracle provided Perl needs to be referenced at the beginning of the PATH and PERL5LIB for Patch apply or rollback.

Set PATH and PERL5LIB environment variable and apply patch again.

export PATH=$ORACLE_HOME/perl/bin:$PATH
export PERL5LIB=$ORACLE_HOME/perl/lib

ORA-19751: could not create the change tracking file ORA-19750: change tracking file: ORA-17502: ksfdcre:4 Failed to create file

ISSUE

SQL> alter database open resetlogs;

alter database open resetlogs
*
ERROR at line 1:
ORA-19751: could not create the change tracking file
ORA-19750: change tracking file:
'+DATA/DB_NAME/CHANGETRACKING/ctf.281.1234567789'
ORA-17502: ksfdcre:4 Failed to create file
+DATA/DB_NAME/CHANGETRACKING/ctf.281.1234567789
ORA-15046: ASM file name
'+DATA/DB_NAME/CHANGETRACKING/ctf.281.1234567789' is not in
single-file creation form
ORA-17503: ksfdopn:2 Failed to open file
+DATA/DB_NAME/CHANGETRACKING/ctf.281.1234567789
ORA-15012: ASM file '+DATA/DB_NAME/CHANGETRACKING/ctf.281.1234567789'

does not exist

ACTIONS PERFORMED

Database was restored and recovered using rman and attempted to open with resetlogs.

Source Database using a 'block change tracking' file stored in ASM. Controlfile and Database is restored and recovered successfully but the open resetlogs fails with above errors.

ISSUE IS DUE TO

The change tracking file is originally created like this:
.
SQL> alter database enable block change tracking using file '+<DGNAME>';

Because the change tracking file is created by only specifying the ASM Diskgroup, a fully qualified ASM name is used for this file and stored in the DataDictionary.
When this file is not found during the open phase, the same filename will be used to recreate the file automatically by using the fully qualified ASM name which is not allowed, hence the error.

Bug 5362418 is opened for this has been closed as a duplicate of 11744544.

SOLUTION

- Disable  the block change tracking 

- try OPEN RESTLOGS again, if any error, open normally.

- And enable block chnage tracking again, Use an ASM alias in the diskgroup. This way, the alias will be recreated successfully (which in turn will be linked to a new ASM fully qualified name behind the scenes)

SQL> alter database disable BLOCK CHANGE TRACKING;

Database altered.

SQL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01139: RESETLOGS option only valid after an incomplete database recovery

SQL>  alter database open;

Database altered.

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '+DATA';

Database altered.

ORA-04063: package body "SYS.DBMS_RCVMAN" has errors

 

ISSUE DESCRIPTION

rman target /

Recovery Manager: Release 12.2.0.1.0 - Production on Fri Feb 9 19:26:23 2024

Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.

ORACLE error from target database:
ORA-04063: package body "SYS.DBMS_RCVMAN" has errors
ORA-06508: PL/SQL: could not find program unit being called: "SYS.DBMS_RCVMAN"

error executing package DBMS_RCVMAN in TARGET database
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-06429: TARGET database is not compatible with this version of RMAN

COMPILE the objects

rman target /

Recovery Manager: Release 12.2.0.1.0 - Production on Fri Feb 9 19:26:23 2024

STATUS of the OBJECTS 

select owner,object_name,object_type,status from dba_objects where status='INVALID'
OWNER OBJECT_NAME OBJECT_TYPE STATUS
-------------------- ------------------------------ ----------------------- -------
SYS DBMS_RCVMAN PACKAGE BODY INVALID

SOLUTION

SQL> alter PACKAGE SYS.DBMS_RCVMAN compile BODY;

Warning: Package Body altered with compilation errors.

SQL>
SQL>
SQL>
SQL> sho error
Errors for PACKAGE BODY SYS.DBMS_RCVMAN:

LINE/COL ERROR
-------- -----------------------------------------------------------------
462/1    PL/SQL: Item ignored
463/8    PLS-00400: different number of columns between cursor SELECT
         statement and return value

8247/1   PL/SQL: Item ignored
8248/8   PLS-00400: different number of columns between cursor SELECT
         statement and return value

SQL>

SQL> @?/rdbms/admin/prvtrmns.plb

Session altered.

Package body created.

Session altered.

SQL>

SQL>

SQL> !

rman target /

Recovery Manager: Release 12.2.0.1.0 - Production on Fri Feb 9 21:07:36 2024

Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.

connected to target database: DBNAME (DBID=123456789)

RMAN> exit

Recovery Manager complete.

GATHER STATS for TABLE/SCHEMA/DATABASE/SYSTEM and LOCK STATS scripts

GATHER STATS for TABLE/SCHEMA/DATABASE/SYSTEM and LOCK STATS scripts

 TABLE STATS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

EXEC DBMS_STATS.gather_table_stats('HR','EMPLOYEES');

EXEC DBMS_STATS.gather_table_stats('HR','EMPLOYEES',cascade=>TRUE);

EXEC DBMS_STATS.gather_table_stats('SCOTT', 'EMPLOYEES', estimate_percent => 15, cascade => TRUE);

exec dbms_stats.gather_table_stats(ownname=>'&Schema_name',tabname=>'&Table_name',estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE,cascade=>TRUE,degree =>4);

exec DBMS_STATS.GATHER_TABLE_STATS (ownname => '&OWNER' , tabname => '&TAB_NAME',cascade => true, estimate_percent => 10,method_opt=>'for all indexed columns size 1',granularity => 'ALL', degree => 1);

INDEX STATS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

EXEC DBMS_STATS.gather_index_stats('HR','EMPLOYEES_PK');

exec DBMS_STATS.GATHER_INDEX_STATS(ownname => '&OWNER',indname =>'&INDEX_NAME',estimate_percent =>DBMS_STATS.AUTO_SAMPLE_SIZE);

SCHEMA STATS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

EXEC DBMS_STATS.gather_schema_stats('SCOTT');

EXEC DBMS_STATS.gather_schema_stats('SCOTT', estimate_percent => 15, cascade => TRUE);

exec dbms_stats.gather_schema_stats(ownname=>'&schema_name',ESTIMATE_PERCENT=>dbms_stats.auto_sample_size,degree =>4);

exec dbms_stats.gather_schema_stats(ownname=>'&schema_name', CASCADE=>TRUE,ESTIMATE_PERCENT=>dbms_stats.auto_sample_size,degree =>4);

DATABASE STATS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

EXEC DBMS_STATS.gather_database_stats;

EXEC DBMS_STATS.gather_database_stats(estimate_percent => 15, cascade => TRUE);

exec dbms_stats.gather_database_stats(cascade=>TRUE,method_opt =>'FOR ALL COLUMNS SIZE AUTO');

EXEC DBMS_STATS.GATHER_DATABASE_STATS(ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE,degree=>6);

EXEC DBMS_STATS.GATHER_DATABASE_STATS(ESTIMATE_PERCENT=>dbms_stats.auto_sample_size,CASCADE => TRUE,degree => 4);

DICTIONARY STATS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

EXEC DBMS_STATS.gather_dictionary_stats;

EXEC DBMS_STATS.gather_system_stats;

EXEC DBMS_STATS.gather_fixed_objects_stats;

lock/unlock statistics on table

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

exec dbms_stats.lock_table_stats('&OWNER', '&TAB_NAME');

exec dbms_stats.unlock_table_stats('&OWNER', '&TAB_NAME');

SELECT stattype_locked FROM dba_tab_statistics WHERE table_name='RAJ' and owner='SH';

CHECK STALE STATS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SELECT owner, table_name, last_analyzed, stale_stats

FROM dba_tab_statistics

WHERE table_name='EMPLOYEES'

and owner='HR';

SELECT owner, table_name, index_name last_analyzed, stale_stats FROM dba_ind_statistics 

WHERE table_name='EMPLOYEES'

and owner = 'HR';

Linux Script to Gather Stats

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#!/bin/bash

. /home/oracle/.bash_profile

export ORACLE_HOME=/u01/app/oracle/product/19.3/db_home

export ORACLE_BASE=/u01/app/oracle

export ORACLE_SID=orcl

export DATE=$(date +%y-%m-%d_%H%M%S)

#### Gather HR schema stats ####

sqlplus / as sysdba << EOF > /tmp/HR_stats_gather_$DATE.log

EXEC DBMS_STATS.gather_schema_stats('HR');

EOF

echo "Stats gathered succeeded"

to CHECK & Pause/Resume/Kill a Running RMAN Backup

TO VIEW BACKUP STATUS for RMAN BACKUP Processes    

 SELECT b.opname,b.SID, b.SERIAL#, a.status,b.CONTEXT, b.SOFAR, b.TOTALWORK,

ROUND (b.SOFAR/b.TOTALWORK*100, 2) "% COMPLETE"

FROM gV$SESSION_LONGOPS b, gv$session a

WHERE b.OPNAME LIKE 'RMAN%' 

AND b.OPNAME NOT LIKE '%aggregate%' 

and a.sid=b.sid 

AND b.TOTALWORK! = 0 AND b.SOFAR <> b.TOTALWORK;

    

TO GENERATE KILL SESSION scripts for RMAN  BACKUP Processes    

select 'alter system kill session '''||sid||'',''||serial#||''' immediate;' FROM V$SESSION_LONGOPS

WHERE OPNAME LIKE 'RMAN%' AND OPNAME NOT LIKE '%aggregate%'

AND TOTALWORK! = 0 AND SOFAR <> TOTALWORK;

1. Pause/Resume/Kill a Running RMAN Backup

To Check if there is an RMAN backup is currently running:

col START_TIME for a15

col END_TIME for a15

col TIME_TAKEN_DISPLAY for a10

col INPUT_BYTES_DISPLAY heading "DATA SIZE" for a10

col OUTPUT_BYTES_DISPLAY heading "Backup Size" for a11

col OUTPUT_BYTES_PER_SEC_DISPLAY heading "Speed/s" for a10

col output_device_type heading "Device_TYPE" for a11

SELECT to_char (start_time,'DD-MON-YY HH24:MI') START_TIME,to_char(end_time,'DD-MON-YY HH24:MI') END_TIME, time_taken_display, status,input_type, output_device_type,input_bytes_display, output_bytes_display,output_bytes_per_sec_display,COMPRESSION_RATIO COMPRESS_RATIO FROM v$rman_backup_job_details WHERE status like 'RUNNING%';

2. To Pause an already running RMAN backup: [This is only applicable for Linux OS]

set pages 0 feedback off 

select 'TO PAUSE THE RUNNING RMAN BACKUP RUN THIS OS COMMAND:=>    kill -STOP '||listagg (p.spid, ' ')  WITHIN GROUP (ORDER BY p.spid) from v$session s, v$process p where s.program like 'rman@%' and p.addr=s.paddr;

3. To Resume an already "Paused" RMAN backup: [This is only applicable for Linux OS]

set pages 0 feedback off 

select 'TO RESUME A "PAUSED" RMAN BACKUP RUN THIS OS COMMAND:=>  kill -CONT '||listagg (p.spid, ' ')  WITHIN GROUP (ORDER BY p.spid) from v$session s, v$process p where s.program like 'rman@%' and p.addr=s.paddr;

4. To Terminate an already running RMAN backup: [This is only applicable for Linux OS]

set pages 0 feedback off 

select 'TO KILL  THE RUNNING RMAN BACKUP RUN THIS OS COMMAND:=>  kill -9 '||listagg (p.spid, ' ')  WITHIN GROUP (ORDER BY p.spid) from v$session s, v$process p where s.program like 'rman@%' and p.addr=s.paddr;

 

Java (1.6) could not be located. OPatch cannot proceed!

We get below java error, when we try to query opatch utility like lsinventory, version, apply, rollback ...etc

follow below steps/workaround for the issue

Java (1.6) could not be located

Details of error are as follows.

[SERVER1]/u01/app$ OPatch/opatch version
Java (1.6) could not be located. OPatch cannot proceed!
OPatch returns with error code = 1
[SERVER1]/u01/app$ 
[SERVER1]/u01/app/OPatch $

 

OPatch cannot proceed!

This errors are related with the Opatch version or opatch utility was downloaded for a wrong platform or using older version of opatch.

Install the latest opatch

OR

Use the JDK option like following.

Use the JDK option like following.

which java

copy the java path and go to jdk location inside java home 

opatch apply -jdk <<FULL_PATH_OF_JDK>

example output as below.

Use the JDK option like following.

[SERVER1]/u01/app$ 
[SERVER1]/u01/app$ OPatch/opatch version
Java (1.6) could not be located. OPatch cannot proceed!
OPatch returns with error code = 1
[SERVER1]/u01/app$ 
[SERVER1]/u01/app/OPatch $ 


[SERVER1]/u01/app/OPatch $ ./opatch lsinventory -jdk /export2/jdk/ -oh /u01/app/
Oracle Interim Patch Installer version 13.9.4.2.4
Copyright (c) 2021, Oracle Corporation. All rights reserved.


Oracle Home : /u01/app
Central Inventory : /u01/app/18c/oraInventory
from : /u01/app//oraInst.loc

OPatch version    : 12.2.0.1.33
OUI version       : 12.2.0.1.4

Log file location : /u01/app/cfgtoollogs/opatch/opatch2021-06-21_14-11-18PM_1.log

Lsinventory Output file location : /u01/app/cfgtoollogs/opatch/lsinv/lsinventory2021-06-21_14-11-18PM.txt

--------------------------------------------------------------------------------
ARU platform id: 226
ARU platform description:: Linux x86-64

Installed Top-level Products (1):

Oracle Database 12c                                                  12.2.0.1.0
There are 1 products installed in this Oracle Home.


There are no Interim patches installed in this Oracle Home.


--------------------------------------------------------------------------------

OPatch succeeded.
[SERVER1]/u01/app/OPatch $ 

Create file system in LINUX system which is Larger than 2TB

Create file system in LINUX system which is Larger than 2TB



###########################################################################
###########################################################################
Run the following command to install the e2fsprogs and parted :

yum install -y parted
yum install -y e2fsprogs


Perform the following operations to partition and format a data disk larger than 2 TiB in size and mount the file system.


Check whether a data disk exists.

Run the following command:
fdisk -l

A command output similar to the following one is returned. The command output includes information about the data disk. If no data disk information is returned, the instance does not have data disks attached.

Disk /dev/vdb: 3221.2 GB, 3221225472000 bytes, 6291456000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Use the Parted tool to partition the data disk.

Run the following command to start partitioning:
parted /dev/sdb

Run the following command to convert the partition format from MBR to GPT:
mklabel gpt

Run the following command to create a primary partition and specify the start and end sectors for the partition:
mkpart primary 1 100%

where the 100% is total size of the disk allocated, you can choose as required.

Run the following command to check whether the partition is aligned:
align-check optimal 1

A command output similar to the following one is returned:
1 aligned


Note: -  

If 1 not aligned is returned, the partition is not aligned. 

We recommend that you run the following commands 

and use the (<optimal_io_size> + <alignment_offset>)/<physical_block_size> formula to obtain the start sector number to align the partition for optimal performance. 

For example, if the start sector number is 1024, you can then run the mkpart primary 1024s 100% command to create another primary partition.

cat /sys/block/vdb/queue/optimal_io_size
cat /sys/block/vdb/queue/minimum_io_size
cat /sys/block/vdb/alignment_offset
cat /sys/block/vdb/queue/physical_block_size


Run the following command to view the partition table:
print


Run the following command to exit the Parted tool:
quit

The following figure shows the result of partitioning by using the Parted tool.Partitioning by using Parted


Run the following command to enable the system to re-read the partition table:
partprobe


Run one of the following commands to create a file system for the /dev/vdb1 partition.
Run one of the following commands to create a file system based on your needs:

Create an ext4 file system.
mkfs -t ext4 /dev/vdb1



Run the following command to create a mount point named /test:
mkdir /test

Run the following command to mount the /dev/vdb1 partition to /test:
mount /dev/vdb1 /test

Run the following command to view the current disk space and usage:
df -h

If the command output shows the information of the new file system, the mount operation is successful. You can use the new file system.df output

(Recommended) Write the information of the new partition to /etc/fstab to enable this partition to be automatically mounted on system startup.


Run the cp /etc/fstab /etc/fstab.bak command to back up etc/fstab:

Run the following command to write information of the new partition to /etc/fstab:
echo `blkid /dev/vdb1 | awk '{print $2}' | sed 's/\"//g'` /test ext4 defaults 0 0 >> /etc/fstab



Note
You must run the command as the root user. If you are a common user, 
you can run the su - command to switch to the root user, and then run this command. 

Alternatively, you can run the sudo vi /etc/fstab command to edit /etc/fstab.
We recommend that you use a universally unique identifier (UUID) to reference the new partition in /etc/fstab. 
You can run the blkid command to obtain the UUID of the new partition.



Run the following command to check the information of /etc/fstab:
cat /etc/fstab



###########################################################################

###########################################################################

Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

 Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

Solution

~~~~~~~~~~~~~~~~~~~~

FROM centos
execute below

cd /etc/yum.repos.d/

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*

sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*

now try to update or install

yum -y install java

Oracle GoldenGate extract recovery (Missing archivelogs)

Oracle GoldenGate extract recovery (Missing archivelogs)

Issue description: 

    The issue occurs when archive logs that are needed by Oracle GoldenGate extract gets deleted. For example this can happen when purging old archive logs using RMAN with “force” option. 

RMAN is integrated with OGG so under normal circumstances RMAN never deletes an archive log that is required by OGG extract. 

But with “force” option it does delete archive logs required by OGG extract. Although it is certainly not the best practice to use “force” option while purging old archive logs, 

however accident do happen. This post illustrates the steps needed to recover from such situation.

Example:

The error in the Oracle GoldenGate extract report file looks similar to the following example

ERROR   OGG-00868  Error code 1291, error message: ORA-01291: missing logfile

(Missing Log File WAITING FOR DICTIONARY REDO. Read Position SCN: 0.46921993 (46921993)).

            

1) Find out the archive logs (and the range) that the extract is complaining about. Let’s say the extract is complaining about SCN number 46921993.

Find out which archive log that SCN number belongs to.

SQL> Select sequence# from v$archived_log where 46921993 is between first_change# and next_change#;     Sequence#     ==========     100

SQL> Select sequence# from v$archived_log where sequence# >100 and name is NULL;

(Say the query came back with 10 archive logs (101 through 110)).

Sequence#     ==========      100      101      102      103      104      105      106      107      108      109      110

2) Restore the archive log using RMAN.

RMAN> Restore archive logs from logseq 100 until logseq 110;

3) Register the archive logs for the capture process.

SQL> Alter database register logical logfile “/<path to logfile>/logfilename> for "OGG Capture Name";

4) Restart the OGG extract.

GGSCI> Start extract <OGG extract name>

Note: This solution is generic and applies to both Oracle cloud and on-premise customers

Oracle 19c Restore Point Replication From Primary To Standby

Oracle 19c Restore Point Replication From Primary To Standby

Primary Side:-

~~~~~~~~~~~~

SQL> SELECT database_role, open_mode FROM v$database;

DATABASE_ROLE        OPEN_MODE
—————-               ——————–

PRIMARY                      READ WRITE

SQL> create restore point FB_Restore_poiint  guarantee flashback database;
Restore point created.

SQL> select SCN, GUARANTEE_FLASHBACK_DATABASE, TIME, NAME, REPLICATED from v$restore_point;

SCN     GUARANTEE_FLASHBACK_DATABASE  TIME NAME  REPLICATED
———- —————————— —————————————- ————————-
2443446     YES  20-OCT-19 04.15.22.000000000 PM FB_Restore_poiint NO

PRIMARY - Alertlog
~~~~~~~~~~

2022-11-20T16:15:22.184171+05:30
Created guaranteed restore point FB_Restore_poiint

Standby Side:-

~~~~~~~~~~~~~

SQL> SELECT database_role, open_mode FROM v$database;

DATABASE_ROLE                 OPEN_MODE
—————-                        ——————–
PHYSICAL STANDBY      READ ONLY WITH APPLY

SQL> select SCN, GUARANTEE_FLASHBACK_DATABASE, TIME, NAME, REPLICATED from v$restore_point;

SCN     GUARANTEE_FLASHBACK_DATABASE  TIME NAME  REPLICATED
———- —————————— —————————————- ————————-
2443446 NO  20-OCT-19 04.15.22.000000000 PM FB_Restore_poiint_PRIMARY YES

SQL> select status,instance_name,database_role,protection_mode ,flashback_on from v$database,v$instance;

STATUS INSTANCE_NAME DATABASE_ROLE PROTECTION_MODE  FLASHBACK_ON
———— —————- —————- —————————————————————————-
OPEN               delhi       PHYSICAL STANDBY                         MAXIMUM AVAILABILITY  YES
 
    

        The naming convention for a replicated restore point uses the name of the restore point on the primary database suffixed with _PRIMARY. 

        If a replicated restore point with the same name exists on the standby database, then a replicated restore point is not created. 

    For example, when you create a restore point named PRE_MYTBS on the primary database, the replicated restore point is named FB_Restore_poiint_PRIMARY. 

    When you delete a restore point on the primary, the corresponding replicated restore point on the standby is also deleted.

 

Automatic Flashback of a Mounted Standby After a Primary RESETLOGS Operation

 

Automatic Flashback of a Mounted Standby After a Primary RESETLOGS Operation

A standby database that is in a mounted state can automatically follow the primary database after a RESETLOGS operation on the primary. 

This simplifies standby management after a RESETLOGS operation on the primary.

When flashback or point-in-time recovery is performed either on a primary database or a PDB in the primary database, the primary database or PDB is moved to a previous point in time and the primary is then opened with the RESETLOGS option.

 A new incarnation of the primary or the PDB in the primary is created. For the standby to automatically follow the primary, the MRP performs the following actions:

• detects the new incarnation

• flashes back the standby or the PDB on the standby to the same point in time as that of the primary or the PDB on the primary

• restarts the standby recovery and moves the standby to the new branch of redo

The flashback operation will succeed only when the standby database has sufficient flashback data.

If you do not want the standby to automatically follow the primary, either keep the standby database in OPEN mode or stop the MRP process on the standby.

If the standby database is open in read only mode, the corresponding error messages are recorded in the alert log. When you restart the MRP after closing the physical standby, the recovery process automatically flashes back the standby database and continues to apply the new branch of redo.

REFER:-

https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-physical-standby-databases.html#GUID-252097AC-3070-43B6-88D8-919AE27F97AD

Oracle 19c Restore Point Replication From Primary To Standby

Oracle 19c Restore Point Replication From Primary To Standby   

Oracle Database Release 19c New Feature

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

• The process of flashing back a physical standby to a point in time that was captured on the primary is simplified by automatically replicating restore points from primary to the standby.
• These restore points are called replicated restore points.
• Irrespective of whether a restore point on the primary database is a guaranteed restore point or a normal restore point, the corresponding replicated restore point is
  always a normal restore point.

NOTE: Starting from 19c, be aware that standby can automatically perform flashback in response to similar operation on primary. Refer:

Automatic Flashback of a Mounted Standby After a Primary RESETLOGS Operation

Automatically replicates restore points from a primary database to the standby database Conditions:-

• COMPATIBLE initialization parameter for both the primary database and the standby database is set to 19.0.0 or higher
• Primary database is open
• A restore point that is created on a primary database when the primary is in mount mode is not replicated. This restriction is because the restore point information is replicated though the redo.

 

CREATE GUARANTEED RESTORE POINT

1. Stop redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='defer'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database cancel;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-OFF';
DGMGRL> edit database boston set state = 'APPLY-OFF';

2. Set GRP in standby database

On standby database:
SQL> CREATE RESTORE POINT grp_dg GUARANTEE FLASHBACK DATABASE;

3. Set GRP in primary database

On primary database:
SQL> CREATE RESTORE POINT grp_dg GUARANTEE FLASHBACK DATABASE;

4. Enable redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='enable'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database using current logfile disconnect;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-ON';
DGMGRL> edit database boston set state = 'APPLY-ON';

 

FLASHBACK DATABASE TO GUARANTEED RESTORE POINT

1. Stop redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='defer'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database cancel;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-OFF';
DGMGRL> edit database boston set state = 'APPLY-OFF';

2. Shutdown Primary Database and start one instance in mount stage

3. Flashback primary database to restore point

On primary database:
SQL> flashback database to RESTORE POINT grp_dg;
SQL> alter database open resetlogs;

4. Shutdown Standby database and start one instance in mount stage

5. Flashback standby database

On standby database:
SQL> flashback database to RESTORE POINT grp_dg;

6. Enable redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='enable'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database using current logfile disconnect;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-ON';
DGMGRL> edit database boston set state = 'APPLY-ON';

7. If Active Data Guard licence is used, open read only the standby database

 

DROP GUARANTEED RESTORE POINT

1. Stop redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='defer'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database cancel;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-OFF';
DGMGRL> edit database boston set state = 'APPLY-OFF';

2. Drop GRP in primary database

On primary database:
SQL> drop RESTORE POINT grp_dg;

3. Drop GRP in standby database

Ensure the standby database is in mount stage and drop GRP:

SQL> drop restore point grp_dg;

If Active Data Guard licence is used, open read only the standby database after dropping the GRP

4. Enable redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='enable'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database using current logfile disconnect;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-ON';
DGMGRL> edit database boston set state = 'APPLY-ON';

https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-physical-standby-databases.html#GUID-252097AC-3070-43B6-88D8-919AE27F97AD