ORA-10458 when opening Oracle physical standby read only after duplicating (restoring from another physical standby)

You might get the following errors stack when trying to open physical standby database read only. In my case it was duplicated (restored from service from different active physical standby), and I got the errors :

SQL> alter database open read only                   
*                                                                                              
ERROR at line 1:                                
ORA-10458: standby database requires recovery                                                  
ORA-01194: file 1 needs more recovery to be consistent                                         
ORA-01110: data file 1: '+DATAC8/BARS12_TST/DATAFILE/system.266.1089980259' 

Actually, all files was consistent, all checkpoints was equal etc., but some datafiles was fuzzy (fhsta=64) :

SQL> select count(*) ,fhsta from x$kcvfh group by fhsta;                                                                                              
      COUNT(*)|          FHSTA                                                                                                                                                               
===============|=============== 

            28|              0                                                                
           103|             64                                                                                                                                                               
             1|           8256                 

What did not help :

- register/catalog next not applied archived log and run 'recover database' from rman ;

- register/catalog next not applied archived log and run 'recover standby database' from sqlplus.

What really helped :

- register next not applied archived log and run 'alter database recover managed standby database disconnect' from sqlplus (equals to run 'recover managed standby database disconnect' sqlplus command); next wait while last archived log is implemented, then cancel media recovery and finally open standby database read only without issues.

Good Luck !

ERROR: The home is not clean. This home cannot be used since there was a failed OPatch execution in this home. Use a different home to proceed.

Everyone knows how to install the software for Oracle 19c database or grid infrastructure - Oracle ships preinstalled OH as a base release and a customer is performing runInstaller which is actually applying appropriate Release Update and one-off patches first and then linking libraries, executables and perform another stuff.

First you need to unpack the base release. Then, after running ./runInstaller script, something can potentially go wrong during applying the patches, for example, you might forget to renew opatch beforehand. To resolve the issue consult opatch logfiles located in ORACLE_HOME/cfgtoollogs directory. If the error is correctable, you fix it and rerun the installation, but you may get the following error :

ERROR: The home is not clean. This home cannot be used since there was a failed OPatch execution in this home. Use a different home to proceed.

You can go on by removing the new OH first, unzip a base home and rerun theinstallation, and it's actually the way the Oracle advises to follow on. In my case the opatch was older then required to install RU; it was not so much convenient to unpack or to copy over the network the installation files again.

So running truss (it was Oracle Solaris) I figured out the empty file is created when opatch starting its job during installation and this file is removed after successful all opatch operations. The file is :

$ORACLE_HOME/install/patch

I just removed it and rerun installation without unzipping base home again. All patches was applied successfully and the software was configured OK as well. That's it ! :)

P.S. You might with to clone ORACLE_HOME to avoid long installation and applying patches time.

Good Luck !

Another way to create VIP resource in Grid Infrastructure

1. Create additional type based on 'cluster_resource' type (starting with cluster)

# crsctl add type app.appviptypex2.type -basetype ora.cluster_resource.type -file /u01/app/19.13/grid/crs/template/appvipx.type

2. Create VIP resource :

# crsctl add resource vip-resource-name -type app.appviptypex2.type -attr "USR_ORA_VIP=vip_ip_address,NETWORK_RESOURCE=,START_DEPENDENCIES=hard(ora.net1.network) pullup(ora.net1.network),STOP_DEPENDENCIES=hard(intermediate:ora.net1.network),ACL='owner:root:rwx,pgrp:root:r-x,other::r--,user:root:r-x',APPSVIP_FAILBACK="

Carefully check newly created resource parameters and change it if needed :

# crsctl stat res vip-resource-name -p

3. Use it ! :-)

Enabling automatic mounting of nfs shares on Oracle Solaris

1. Edit /etc/vfstab. Example :

nfs_server:/nfs_share - /mnt/nfs_share_mount_point  nfs - yes rw,bg,hard,nointr,rsize=1048576,wsize=1048576,vers=3,proto=tcp,forcedirectio,nocto

Here 'yes' means to mount during operating system start.

2. Enable Solaris nfs services (if disabled, check with 'svcs' command) :

# svcadm enable svc:/network/nfs/client:default svc:/network/nfs/status:default svc:/network/nfs/nlockmgr:default

3. Check it during reboot (if possible). Diagnose failed services with 'svcs | grep -v online' and 'svcs -x' commands.

Good Luck !

ORA-15040 when duplicating or creating database on Exadata (db_unique_name is the same)

I got stuck into the situation when I needed to move the database between RACs. I decided to do it via RMAN : duplicate first and then remove database on the source. After some preparations, when I started to check how the restoration over the network works, I got the error :

Recovery Manager: Release 12.1.0.2.0 - Production on Thu Nov 4 17:03:05 2021
                                                  
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.     
                                                 
connected to target database: CDBM02 (not mounted)
                
RMAN> restore controlfile from service "hostname/service_dev" ;
               
Starting restore at 04.11.2021 17:03:30        
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1                 
channel ORA_DISK_1: SID=292 device type=DISK
                                            
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service hostname/service_dev
channel ORA_DISK_1: restoring control file
dbms_backup_restore.restoreCancel() failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 11/04/2021 17:03:44
ORA-19660: some files in the backup set could not be verified
ORA-19661: datafile 0 could not be verified
ORA-19849: error while reading backup piece from service hostname/service_dev
ORA-19504: failed to create file "+RECOC9"
ORA-17502: ksfdcre:4 Failed to create file +RECOC9
ORA-15001: diskgroup "RECOC9" does not exist or is not mounted
ORA-15040: diskgroup is incomplete
                                  
RMAN>

I started to check compatibility attributes for asm diskgroup (it was set to compatible.rdbms=12.1 and compatible.asm=19.0), permissions of $ORACLE_HOME/bin/oracle binary, alert logs (ASM and database), trace files etc. The trace files shown me the following for the every exadata grid disk :

WARNING: disk locally closed resulting in I/O error [0xf4]

I started to suspect that the cause was inside the storage cells. So consulting with alert log files on the cells gave me the clue :

Warning:  Two databases from different clusters have the same DB_UNIQUE_NAME parameter value of "SERVICE_DEV".
Rejecting open request from host ...

Changing db_unique_name parameter on the source resolved the issue.

P.S. Later I found MOS Note "Exadata: Warning Cellsrv Rejecting Open Request from Host Due to DB Name Conflict (Doc ID 2060753.1)" describing the same issue and giving some additional advice regarding it.