Quantcast
Channel: Doyensys Allappsdba Blog..
Viewing all 1640 articles
Browse latest View live

Query To check Current Users Logged in EBS

$
0
0
select distinct fu.user_name User_Name,fr.RESPONSIBILITY_KEY Responsibility from fnd_user fu,
fnd_responsibility fr, icx_sessions ic
where fu.user_id = ic.user_id AND
fr.responsibility_id = ic.responsibility_id AND
ic.disabled_flag='N' AND
ic.responsibility_id is not null AND
ic.last_connect like sysdate;

EBS Output Post Processor Best Practices

$
0
0

Output Post Processor (OPP)

Concurrent Processing now uses the Output Post Processor (OPP) to enforce post-processing actions for concurrent requests. Post-processing actions are actions taken on concurrent request output.
An example of a post-processing action is that used in Concurrent Processing support of XML Publisher. If a request is submitted with an XML Publisher template specified as a layout for the concurrent request output, then after the concurrent manager finishes running the concurrent program, it will contact the OPP to apply the XML Publisher template and create the final output.

Monitor the workload of OPP

The OPP uses 'Advanced Queue' to find the pending requests that it needs to process, hence it becomes difficult to configure (or) do sizing of OPP without knowing the workload. When OPP begins to process a concurrent request, it will update the processor_id column of fnd_conc_pp_actions with its concurrent_process_id. 
We can use the following query to find pending requests against OPP:
 select REQUEST_ID,PHASE_CODE,STATUS_CODE from fnd_concurrent_requests
where request_id in (
select concurrent_request_id
from fnd_conc_pp_actions
where action_type >= 6
and processor_id is null)
and PHASE_CODE!='C';
Once we estimate the number incoming requests of the OPP, we can do the sizing appropriately

 Tuning OPP to Improve Performance

The parameter max_threads controls the maximum number of request threads. This number may be increased depending on the workload. Oracle recommendation is to keep the number of Threads per Process between 1 and 20.
The more threads that are set the more reports are processed simultaneously, but if all the reports being processed have large data files and complex templates, then this could impact performance, or cause the report creation to fail. If the reports are all very small reports then higher thread counts can be used safely.
There are many site specific factors that needs to be considered for optimum CP throughput: from machine hardware, to user request volume, to required Work Shifts, to programs run time characteristics (long / short running).

Tuning Heap Size to avoid OutOfMemoryError

The most common error in OPP is OutOfMemoryError.  One can increase the heap size to prevent this error. Ensure that one has sufficient free RAM before increasing heap size.
For example:  One is setting heapsize to 2 GB and assume you have 2 processes. Then one should have 4 GB free RAM. Otherwise increasing the heapsize of OPP, can prevent OPP from coming up.

 Monitor AQ$ tables

The AQ$_FND_CP_GSM_OPP_AQTBL_H is a history table.  We need to purge the AQ$ tables using the oracle provided method to ensure OPP running without any issues. Below are high level steps for the same.

  1. select count(*) from applsys.FND_CP_GSM_OPP_AQTBL ;
  2.  Run the below script as apps user

DECLARE
po dbms_aqadm.aq$_purge_options_t;
BEGIN
po.block := FALSE;
DBMS_AQADM.PURGE_QUEUE_TABLE(
queue_table => 'APPLSYS.FND_CP_GSM_OPP_AQTBL',
purge_condition => NULL,
purge_options => po);
END;
/
3.      select count(*) from applsys.FND_CP_GSM_OPP_AQTBL ;

 



 
 
 



To Find Index Fragmentation and Usage

$
0
0

To Find Index Fragmentation
~~~~~~~~~~~~~~~~~~~~~~~~~~~
analyze index <index_name> validate structure;
select round((del_lf_rows/lf_rows)*100,2) ratio, height, lf_blks, lf_rows   from index_stats;

We are comparing the ratio between no of leaf rows which have values with leaf rows which don't have any values, if it is above 20% then it index is fragmented. index_stats table can have only one row at a time so we need to query the table after each analyse index statement. The table exists the session where the analyze statement is executed.

analyze index APPS.ADS_INDUSTRY_NAME validate structure;

To find Index Usage
~~~~~~~~~~~~~~~~~~~
 alter index <index_name> monitoring usage;

Once Monitoring is enabled use the below query to find out the usage. We need to execute the command as the owner of the index to find the usage
 SELECT index_name,
       table_name,
       monitoring,
       used,
       start_monitoring,
       end_monitoring
FROM   v$object_usage
WHERE  index_name = 'MY_INDEX_I'
ORDER BY index_name;

Roll Forward Physical standby database in 12c

$
0
0
Step 1:

sqlplus / as sysdba
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Step 2:

rman target /
RECOVER DATABASE FROM SERVICE PRIM USING COMPRESSED BACKUPSET NOREDO SECTION SIZE 120M;

sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;

Step 3:

rman target /
RESTORE STANDBY CONTROLFILE FROM SERVICE PRIM;

Step 4:

sqlplus / as sysdba
ALTER DATABASE MOUNT STANDBY DATABASE;

Step 5:

rman target /
CATALOG START WITH '+ORA_DATA/DATAFILE/';
SWITCH DATABASE TO COPY;

Step 6:

sqlplus / as sysdba
set pages 0 verify off feed off term off echo off
spool /tmp/clear.sql
select distinct 'ALTER DATABASE CLEAR LOGFILE GROUP '||GROUP#||';' as cmd from v$logfile;
spool off
@/tmp/clear.sql
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

[FATAL] [INS-30024] Installer has detected that the location determined as Oracle Grid Infrastructure home is not a valid Oracle home

$
0
0
Issue:

[INS-30024] Installer has detected that the location determined as Oracle Grid Infrastructure home, is not a valid Oracle home.

Cause:

Due to failed previous grid installation.

Solution:

Rename olr.loc and ocr.loc and unset the oracle related variables and re-run the installation
mv /etc/oracle/olr.loc /etc/oracle/olr.loc_orig
mv /etc/oracle/ocr.loc /etc/oracle/ocr.loc_orig
$unset ORACLE_HOME
$unset ORACLE_BASE
$unset ORACLE_SID
$unset ORA_CRS_HOME

Error in invoking target 'agent nmhs' of make file ins_emagent.mk while installing Oracle 11.2.0.4 on RHEL 7

$
0
0
Issue:

Error in invoking target 'agent nmhs' of make file ins_emagent.mk while installing Oracle 11.2.0.4 on rhel 7

Cause:

New oracle 11.2.0.4 installation on RHEL 7 and the below error is reported during link stage

Solution:

Edit $ORACLE_HOME/sysman/lib/ins_emagent.mk, search for the line
$(MK_EMAGENT_NMECTL)

Then replace the line with
$(MK_EMAGENT_NMECTL) -lnnz11

Then click Retry to continue.

EM 13c Cloud Contorol Login Fails as SYSMAN with Error: oracle.sysman.emSDK.sec.auth.InvalidEMUserException: Failed to login using repository authentication for user: SYSMAN

$
0
0
Issue:

Failed to login using repository authentication for user: SYSMAN
oracle.sysman.emSDK.sec.auth.InvalidEMUserException: Failed to login using repository authentication for user: SYSMAN

Cause:

Unable to extend MGMT_TABLESPACE  tablespace.

Solution:

Add datafile or resize existing datafile in MGMT_TABLESPACE  tablespace.

RMAN is hung or it is very slow / Clearing RMAN repository / Troubleshoot RMAN-06214 error

$
0
0
RMAN is hung or it is very slow / Clearing RMAN repository / Troubleshoot RMAN-06214 error

RMAN> DELETE FORCE NOPROMPT OBSOLETE DEVICE TYPE DISK;

If error still occurs, then try the below

RMAN> CROSSCHECK COPY OF CONTROLFILE;

rman> DELETE FORCE NOPROMPT OBSOLETE DEVICE TYPE SBT;
or
DELETE FORCE NOPROMPT OBSOLETE DEVICE TYPE DISK;

1) Cancel any Delete obsolete command sessions

2) RMAN> CROSSCHECK COPY OF CONTROLFILE;

3) Start the delete obsolete command with debug enabled to check whether RMAN is hung or it is very slow :

rman target / debug trace=debug.trc log=rman.log

RMAN> execute the backup script here

Upload to oracle, the debug.trc and rman.log for review.
Also upload the output of the below command :

RMAN> show all;

Intermittent cellsrv crashes with ORA-07445 after upgrading to 12.2.1.1.7

$
0
0
Intermittent cellsrv crashes with ORA-07445 after upgrading to 12.2.1.1.7

Exadata X6-2 full and half racks were patched recently with 12.2.1.1.7 Aug/2018 quarterly patch set. An ORA-07445 started to observe and the cellsrv intermittently crashing with ORA-07445 error.

Following error is noticed in the cellsrv alert.log:

ORA-07445: exception encountered: core dump [0000000000000000+0] [11] [0x000000000] [] [] []

The above is registered as a bug whenever cell storage is patched with 12.2.1.1.7 or 12.2.1.1.8. Therefore, if you are planning to patch your cell storage software with one of the above versions, ensure you also apply patch 28181789 to avoid cellsrv intermittently crashing with ORA-07445 error. Otherwise, you need to upgrade the storage software with 18.1.5.

Symptom

Customer may experience intermittent cellsrv crashes with ORA-07445: [0000000000000000+0] [11] [0x000000000] after upgrading storage cell software version to 12.2.1.1.7 or 12.2.1.1.8

Change

Upgrade the Storage cell software to 12.2.1.1.7 or 12.2.1.1.8

Cause

Bug 28181789 - ORA-07445: [0000000000000000+0] AFTER UPGRADING CELL TO 12.2.1.1.7

Fix

Patch 28181789 is available for 12.2.1.1.7 and 12.2.1.1.8 Storage software releases. Follow the README to instructions to apply the patch.
~OR~
apply 18.1.5 and later which includes the fix of 28181789

Oracle E-Business Suite Learning Subscription Free Access Videos

$
0
0


Oracle has been publishing useful knowledge contents related to Oracle E-Business Suite as videos in their Oracle Learning Subscription portal, which are freely accessible. Some may know, many are not aware of such contents available. This post is to share and help everyone with such useful links.

You need Oracle.com login account to access those videos.

This is a useful information for everyone, Hence please do share this post with your friends and colleagues.

Module
Link
Operational efficiency => Monitoring , Maintenance , Upgrade , TLS Configuration, Online patching, cloning, Managing customization, 12.2 Upgrade best practices, Performance management
Technology Stack and Architecture
Information Discovery / Endeca
User interface
India Localization
Financial control and reporting
Credit to Cash
Financial Overview
HCM Overview
HCM Compensation and Benefits
HCM Payroll
Logistics
Optimize Fulfilment with Oracle EBS Logistics
Advanced Catch Weight
Manufacturing
Order Management
OM Solution Selling
Credit Checking
Procurement –
Advanced Procurement
Employee Driven Procurement
Operations Management
Service Management
Projects
Value Chain Planning
Advanced Supply Chain
Demantra / Demand Management
Inventory Optimization

ORA-20005: object statistics are locked (stattype = ALL)

$
0
0
ORA-20005: object statistics are locked (stattype = ALL) - Solution
ERROR

During tuning a query, I found one table has stale statistics. While running gather stats for that table, got below error. Let me demonstrate with a demo table:

SQL> execute dbms_stats.gather_table_stats(ownname => 'HR', tabname => 'EMPLOYEE', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO');

BEGIN dbms_stats.gather_table_stats(ownname => 'HR', tabname => 'EMPLOYEE', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO'); END;

ERROR at line 1:
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: at "SYS.DBMS_STATS", line 34634
ORA-06512: at line 1
SQL>

Analysis:
Verify whether statistics is locked for that table or not.
SQL> col OWNER for a12
SQL> col table_name for a30
SQL> col STATTYPE_LOCKED for a15
SQL> select owner,table_name,STATTYPE_LOCKED from dba_tab_statistics where table_name='EMPLOYEE' and owner='HR';

OWNER        TABLE_NAME                     STATTYPE_LOCKED
------------ ------------------------------ ---------------
HR           EMPLOYEE                           ALL
SQL>

So, the column "stattype_locked" value is showing "ALL", that means statistics is locked for that table.

Solution :

SQL> EXEC DBMS_STATS.unlock_table_stats('HR','EMPLOYEE');
PL/SQL procedure successfully completed.
SQL>

Now try to run stats again:

SQL> execute dbms_stats.gather_table_stats(ownname => 'HR', tabname => 'EMPLOYEE', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO');

PL/SQL procedure successfully completed.

SQL>

Similarly we can unlock stats for a schema also.

SQL> EXEC DBMS_STATS.unlock_schema_stats('HR');
PL/SQL procedure successfully completed.

Querying the amount of redo in Oracle Database Posted on December 13, 2018 Standard Reply When a database starts to churn more redo then normal, it is handy to be able to extract the amount of redo over time, to be able to plot this on a graph. The below query allows you to extract this info 🙂 Query for redo generation Query to obtain the amount of redo generation over time by hour and MB: set pages 999 lines 400 select to_char(trunc(first_time, 'HH24'), 'DD/MM/YYYY HH24:MI:SS') date_by_hour, sum(round(blocks*block_size/1024/1024)) CHURN_IN_MB from v$archived_log group by trunc(first_time, 'HH24') order by 1 /

$
0
0

Query to obtain the amount of redo generation over time by hour and MB:

set pages 999 lines 400
select to_char(trunc(first_time, 'HH24'), 'DD/MM/YYYY HH24:MI:SS') date_by_hour, sum(round(blocks*block_size/1024/1024)) CHURN_IN_MB
from v$archived_log
group by trunc(first_time, 'HH24')
order by 1
/

query to find segment name

$
0
0
Run below query to find segment name :

1) Query-1: Find segment name with owner
To find segment name from Corrupt Block
Find segment name from Corrupt Block:
SQL> select * from dba_extents where file_id = 80 and 1288987 between block_id and block_id + blocks -1 ;


2) Query-2: Find object details

SQL> select * from dba_objects where object_name='MLOG$_PATIENT' and object_type='TABLE'; 

FLUSH_DATABASE_MONITORING_INFO Procedure

$
0
0
FLUSH_DATABASE_MONITORING_INFO Procedure

SQL> exec dbms_stats.FLUSH_DATABASE_MONITORING_INFO;

PL/SQL procedure successfully completed.

after executing above package, then below query will give you updated data.

select table_owner,table_name,inserts,updates,deletes from DBA_TAB_MODIFICATIONS;

Query to shows Day wise,User wise,Process id of server wise- CPU and I/O consumption

$
0
0
shows Day wise,User wise,Process id of server wise- CPU and I/O consumption 

set linesize 140
col spid for a6
col program for a35 trunc
select p.spid SPID,to_char(s.LOGON_TIME,'DDMonYY HH24:MI') date_login,s.username,decode(nvl(p.background,0),1,bg.description, s.program ) program,
ss.value/100 CPU,physical_reads disk_io,(trunc(sysdate,'J')-trunc(logon_time,'J')) days,
round((ss.value/100)/(decode((trunc(sysdate,'J')-trunc(logon_time,'J')),0,1,(trunc(sysdate,'J')-trunc(logon_time,'J')))),2) cpu_per_day
from V$PROCESS p,V$SESSION s,V$SESSTAT ss,V$SESS_IO si,V$BGPROCESS bg
where s.paddr=p.addr and ss.sid=s.sid
and ss.statistic#=12 and si.sid=s.sid
and bg.paddr(+)=p.addr
and round((ss.value/100),0) > 10
order by 8;



Moving Audit trail objects to different table-space to gain performance:

$
0
0
Moving Audit trail objects to different table-space to gain performance:

Use the DBMS_AUDIT_MGMT package to move them to the SYSAUX tablespace:

BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
--this moves table AUD$
audit_trail_location_value => 'SYSAUX');
END;
/

BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD,
--this moves table FGA_LOG$
audit_trail_location_value => 'SYSAUX');
END;
/

PLS-00201: identifier 'DBMS_CRYPTO' must be declared issue - Fix

$
0
0
PLS-00201: identifier 'DBMS_CRYPTO' must be declared issue - Fix

ISSUE:

SQL> show error
Errors for FUNCTION "SCOTT"."DECRYPT_CHAR":

LINE/COL ERROR
-------- -----------------------------------------------------------------
6/19     PL/SQL: Item ignored
6/34     PLS-00201: identifier 'DBMS_CRYPTO' must be declared
17/1     PL/SQL: Statement ignored
17/24    PLS-00201: identifier 'DBMS_CRYPTO' must be declared
SQL>

SOLUTION:

You need to give access on dbms_crypto to your schema. Here your schema is "scott".
SQL>  grant execute on sys.dbms_crypto to SCOTT;

Grant succeeded.

ORA-14693: The MAX_STRING_SIZE parameter must be EXTENDED

$
0
0
ORA-14693: The MAX_STRING_SIZE parameter must be EXTENDED
ISSUE:
During cloning a database, I found below error:

ORA-14693: The MAX_STRING_SIZE parameter must be EXTENDED
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00601: fatal error in recovery manager
RMAN-03004: fatal error during execution of command
RMAN-10041: Could not re-create polling channel context following failure.
RMAN-10024: error setting up for rpc polling
RMAN-10005: error opening cursor
RMAN-10002: ORACLE error: ORA-03114: not connected to ORACLE
RMAN-03002: failure of Duplicate Db command at 07/20/2019 11:20:15
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-14693: The MAX_STRING_SIZE parameter must be EXTENDED.
.....
 I tried to start, but not able to open the database and same error came.
SQL> startup;
ORACLE instance started.
Total System Global Area 4294967296 bytes
Fixed Size                  2932632 bytes
Variable Size            2634023016 bytes
Database Buffers         1644167168 bytes
Redo Buffers               13844480 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-14693: The MAX_STRING_SIZE parameter must be EXTENDED.
Process ID: 85042
Session ID: 762 Serial number: 59546

SOLUTION

This parameter was introduced in Oracle 12c. MAX_STRING_SIZE controls the maximum size of string size in Oracle database. Either we can set it to STANDARD or.EXTENDED The default value is STANDARD
MAX_STRING_SIZE = STANDARD means the maximum size of strings is 4000 bytes for VARCHAR2 and NVARCHAR2
MAX_STRING_SIZE = EXTENDED means maximum size can be upto 32767 byte .
We can change the value of MAX_STRING_SIZE from STANDARD to EXTENDED. But not from EXTENDED to STANDARD.
With MAX_STRING_SIZE set to STANDARD , if we try to set the length of column more than 4000, then it will throw ORA-00910 error.
So here, I did below fixes to open the database:

SQL> startup mount;

SQL> alter system set MAX_STRING_SIZE='EXTENDED' scope=spfile;
System altered.

SQL> shut immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.

SQL> startup;
ORACLE instance started.
Total System Global Area 4294967296 bytes
Fixed Size                  2932632 bytes
Variable Size            2634023016 bytes
Database Buffers         1644167168 bytes
Redo Buffers               13844480 bytes
Database mounted.
Database opened.
SQL>

SQL> @?/rdbms/admin/utl32k.sql

ORA-01666: control file is for a standby database - failover over standby as primary

$
0
0
ORA-01666: control file is for a standby database - failover over standby as primary

SQL> select name,open_mode ,database_role from v$database;
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
PROD     READ ONLY            PHYSICAL STANDBY

SQL> shut immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount;
ORACLE instance started.
Total System Global Area 3.4206E+10 bytes
Fixed Size                  2238616 bytes
Variable Size            3422553960 bytes
Database Buffers         3.0736E+10 bytes
Redo Buffers               45682688 bytes
Database mounted.

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01666: control file is for a standby database

SQL> select name,open_mode,database_role from v$database;
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
PROD     MOUNTED              PHYSICAL STANDBY

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Database altered.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
*
ERROR at line 1:
ORA-16139: media recovery required

SOLUTION:

-- Fail-over
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
Database altered.

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
Database altered.

-- Now verify the database status

SQL> select name,open_mode ,database_role from v$database;
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
PROD      MOUNTED              PRIMARY

-- Now open the database

SQL> alter database open;
Database altered.

SQL> select name,open_mode ,database_role from v$database;
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
PROD      READ WRITE           PRIMARY

-- If you have flashback on, make it off if you want.

SQL> alter database flashback off;
Database altered.

ORA-19909: datafile 1 belongs to an orphan incarnation

$
0
0
ORA-19909: datafile 1 belongs to an orphan incarnation

When I tried to Flashback on in standby database then suddenly below message found in alert log and standby database not able to apply archive-logs also. So, here are messages from standby database alert log:

-- Message from alert log ( in standby database)
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/PROD/PROD/xxxx.dbf'
Recovery Slave PR00 previously exited with exception 19909

RCA:
Primary and standby have different incarnations:

-- in standby db

RMAN> list incarnation of database;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       PROD  3680942556       PARENT  5982315579513 30-MAY-2019 00:31:04
2       2       PROD  3680942556       PARENT  5982448719535 30-MAY-2019 22:31:15
4       4       PROD  3680942556       ORPHAN  5983354187673 09-JUN-2019 04:01:27
3       3       PROD  3680942556       CURRENT 5983354274164 10-JUN-2019 04:02:53

-- in primary db

RMAN> list incarnation of database;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       PROD  3680942556       PARENT  5982315579513 30-MAY-2019 00:31:04
2       2       PROD  3680942556       CURRENT 5982448719535 30-MAY-2019 22:31:15

-- Solution:

You need to reset the standby database's incarnation to match the primary's:

-- in standby

RMAN> list incarnation of database;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       PROD  3680942556       PARENT  5982315579513 30-MAY-2019 00:31:04
2       2       PROD  3680942556       PARENT  5982448719535 30-MAY-2019 22:31:15
4       4       PROD  3680942556       ORPHAN  5983354187673 09-JUN-2019 04:01:27
3       3       PROD  3680942556       CURRENT 5983354274164 10-JUN-2019 04:02:53

RMAN> reset database  to incarnation 2;
database reset to incarnation 2

RMAN> list incarnation of database;
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       PROD  3680942556       PARENT  5982315579513 30-MAY-2019 00:31:04
2       2       PROD  3680942556       CURRENT 5982448719535 30-MAY-2019 22:31:15
4       4       PROD  3680942556       ORPHAN  5983354187673 09-JUN-2019 04:01:27
3       3       PROD  3680942556       ORPHAN  5983354274164 10-JUN-2019 04:02:53

-- Verify MRP is active or not

$ ps -ef|grep mrp
oracle   23358 21699  0 12:56 pts/1    00:00:00 grep mrp
-- Verify standby database status and role
SQL> select name,open_mode ,database_role from v$database;
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
PROD      MOUNTED              PHYSICAL STANDBY

-- now start MRP in standby database

$ !sql
SQL> alter database recover managed standby database disconnect from session;
Database altered.

-- Verify the MRP process
$ ps -ef|grep mrp
oracle   23455     1  0 12:58 ?        00:00:00 ora_mrp0_PROD
oracle   24125 21699  0 13:11 pts/1    00:00:00 grep mrp

Now archive-logs are applying.
Viewing all 1640 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>