RMAN-06054 When Executing Active Duplicate

Today perform a duplicate from active database for standby I get the next error;

released channel: c1
released channel: c2
released channel: c3
released channel: c4
released channel: c5
released channel: c6
released channel: c7
released channel: c8
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '+CLOUD_DG/SETHDB/DATAFILE/system.260.1018714895'

released channel: aux1
released channel: aux2
released channel: aux3
released channel: aux4
released channel: aux5
released channel: aux6
released channel: aux7
released channel: aux8
released channel: aux9
released channel: aux10
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/10/2019 15:07:57
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 14345 and starting SCN of 428408006730

Recovery Manager complete.

It is dedicated to the fact that a backup of archives has been made during the duplication process and cannot find the archives that it needs for the recovery phase in the archives location. In me it was solved rerunning the script and ensuring that no backup entered the primary for the duration of the duplicate. Of course, you can continue manually applying the missing files by removing them from the average where they are.

 
HTH – Antonio NAVARRO

Advertisements

ORA-04067 When Generating AWR Reporting

Generating a AWR report, by using awrrpt.sql, I get the next error;

 
ORA-04067: not executed, package body "SYS.DBMS_ASH_INTERNAL" does not exist 
ORA-06508: PL/SQL: could not find program unit being called: "SYS.DBMS_ASH_INTERNAL" 
ORA-06512: at "SYS.DBMS_AWR_REPORT_LAYOUT", line 2228 
ORA-06512: at "SYS.DBMS_AWR_REPORT_LAYOUT", line 17899 
ORA-06512: at "SYS.DBMS_SWRF_REPORT_INTERNAL", line 1513 
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 944 

Recently I installed a PSU to this database engine. When the installation was done everything went well and no errors appeared. The solution is to copy the prvtash package from the patch to ORACLE_HOME and execute it. As it’s shown in the following;

 
cp /patchs/27338041/prvtash.plb $ORACLE_HOME/rdbms/admin 

sqlplus / as sysdba 
@prvtash.plb 

Generating the awr again, it works correctly
HTH – Antonio NAVARRO

HAS Don’t Start After Reboot

Today we have bounced a unix machine, and when checking the CRS after starting we have seen that it has not raised.

Making the basics checks

root# crsctl check cluster
CRS-4639: Could not contact Oracle High Availability Services
CRS-4000: Command Check failed, or completed with errors.

And

root# crsctl check has
CRS-4639: Could not contact Oracle High Availability Services

Checking if it is enabled, and in this case this is the problem;

root# crsctl config has
CRS-4621: Oracle High Availability Services autostart is disabled.

Other wayt to check this is by look into the ohasdstr file;

root# find / -name ohasdstr
/var/opt/oracle/scls_scr/machine_name/root/ohasdstr
root@# cat /var/opt/oracle/scls_scr/machine_name/root/ohasdstr
disable

Now the problem is as easy to fix as to activate it

root# crsctl enable crs
CRS-4622: Oracle High Availability Services autostart is enabled.

Take this opportunity to indicate that in the same path there is another crsstart file, which is what enables the CRS.

HTH – Antonio NAVARRO

 

 

Chmod Error Changing Permissions of extjob0

The other day I was installing the July 2019 PSU for version 12.1 when the following error appeared;

 
OPatch found the word "error" in the stderr of the make command.
Please look at this stderr. You can re-run this make command.
Stderr output:
chmod: changing permissions of ‘/oracle/product/12.1.0.2/db_1/bin/extjobO’: Operation not permitted
make: [iextjob] Error 1 (ignored)

For this error there are two solutions

#1 Run the root.sh, which will change the permissions from /oracle/product/12.1.0.2/db_1/bin/extjobO to root

#2 Ignore it directly

HTH – Antonio NAVARRO

Error ORA-01153

Yesterday when I was set up a standby database in recovery mode;

 
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT
ERROR at line 1:
ORA-01153: an incompatible media recovery is active

Prior to this operation I had put the database in read only and shutdown to return to mount state. I haven’t seen where exactly the problem was, but it’s as if it was recovering. We execute the cancellation operation

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

 
Execute again the recovery mode and it works fine now.

 
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Database altered.

HTH – Antonio NAVARRO

Java (1.6) could not be located

Executing the command opatch lsinventory I get the next error;

 
Java (1.6) could not be located. OPatch cannot proceed!
OPatch returns with error code = 1

Check the current Java version with java -version return the next output;

 
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)

It looks like don’t found the java 1.6, however 1.8 must work fine. In this case I haven’t time to investigate the problem. I solved it by using the java into the ORACLE_HOME. With flag -jdk you can set up the path to a specified java you want to use.

opatch lsinventory -jdk $ORACLE_HOME/jdk

HTH – Antonio NAVARRO

ORA-15260 Error Dropping Diskgroup

Today I was dropping an asm diskgroup, with the next command;

drop diskgroup CLOUD_DATA_DG;

When I got the next error;

ERROR at line 1:
ORA-15260: permission denied on ASM disk group

The problem here, really is very simple. It is because I have connected to the ASM instance as sysdba (whenever I connect to a database). And the solution is as simple as connecting as sysdba 😦

HTH – Antonio NAVARRO