Unable to lock Central Inventory Error

When YOU encounter OPATCH error "Unable to lock Central Inventory. 

Opatch usually throw below error

"

Oracle Home : /u01/app/oraprd/product/10.2.0/db_1
Central Inventory : /u01/app/oraInventory
from : /var/opt/oracle/oraInst.loc
OPatch version : 10.2.0.3.2
OUI version : 10.2.0.3.0
OUI location : /u01/app/oraprd/product/10.2.0/db_1/oui
Log file location : /u01/app/oraprd/product/10.2.0/db_1/cfgtoollogs/opatch/opatch2007-09-22_09-50-02AM.log

Unable to lock Central Inventory. OPatch will attempt to re-lock.
Do you want to proceed? [y|n]
n
User Responded with: N
Unable to lock Central Inventory. Stop trying per user-request?
OPatchSession cannot load inventory for the given Oracle Home /u01/app/oraprd/product/10.2.0/db_1. Possible causes are:
No read or write permission to ORACLE_HOME/.patch_storage
Central Inventory is locked by another OUI instance
No read permission to Central Inventory
The lock file exists in ORACLE_HOME/.patch_storage
The Oracle Home does not exist in Central Inventory

So how do i fix this ?

You can do the follwing to fix this error.

Go to $ORACLE_HOME/.patch_stage directory see if you can directory name called 'lock' if yes remove that direcoty and re-run opatch apply command , else go to oracle central inventory directory (ex:/u01/app/oraInventory)  and see if you can find out lock directory , if yes remove this and re-rin opatch apply command.

Else

export OPATCH_DEBUG=TRUE
and then run opatch apply.

this will give you the exact phase where your patch is failing

ORA-02024: database link not found

If you are trying to drop a database link after changing the global_name of the database , you usually end up with ora-02024: database link not found

 

But when you query user_db_links  view you found DB link exists .

 

 

Possible root cause would be

 

Initially when we create a database without domain in the global name, a null value will be used from domain as opposed to .world in Oracle releases 9i and before.

Later on when the global_name is altered to contain the domain part that is “world”,   this domain remains even when the global_name is altered back a name without domain name.

 

 

In order to drop the desired database link 

 

I would recommend to try this solution in Development DB then in Test  

And with a cold backup in production. 

 

 

1)Conn sys as sysdba

 

 

2) find out current global_name value using below sql

 

SQL> select * from global_name;

GLOBAL_NAME
---------------------------------------------------------
THESIMPLEORACLE.WORLD

 

Find out the value  of  GLOBAL_NAME FROM props$ TABLE

 

Select name, value$ from  props$ where name = 'GLOBAL_DB_NAME';

 

NAME

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

VALUE$

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

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

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

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

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

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

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

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

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

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

GLOBAL_DB_NAME

THESIMPLEORACLE.WORLD

 

 

Step 3) Update global name value to desired name with our domain name

 

Syntax :

update props$ set value$ = '' where name ='GLOBAL_DB_NAME';

 

 

Example :

 

update props$ set value$='THESIMPLEORACLE’  where name like 'GLOBAL_DB_NAME';

 

SQL>commit;

 

 

3)Then connect as the schema user that owns the DBLINK and try to drop it.

4) Once the database link is dropped, the global_name can be changed back to the
desired name containing domain part using the alter database rename global_name statement

Checking Operating System Version Must be B.11.23 Actual B.11.31

The installer attempts to make sure that you are using a certified combination of product and OS.I have encourted this error while installing Oracle 10g on HP-itanium Server.

If you want to override this, try using:

./runInstaller -ignoreSysPrereqs

ORA-04043: object XDB_DATASTORE_PROC does not ...

When you upgrade(manual/DBUA) the DB to 10.2.0.2 or 10.2.0.3  you might encounter

 

ERROR at line 1:
ORA-04043: object XDB_DATASTORE_PROC does not exist

 

In order to fix this, it is necessary to install Oracle Text and run dbmsxdbt.sql 

Size of a Table

To find out a size of a table in Megabytes use below SQL

select segment_name,(bytes)/1024/1024 MB
  2    from user_segments where
  3    segment_type = 'TABLE'
  4*   and SEGMENT_NAME='TABLE_NAME'

V$DataFile

 V$DATAFILE , V_$DATAFILE , GV$DATAFILE

V_$Datafile  The actual underlaying Dynamic View .V$datafile is a public synonym name of V$_Datafile.

You can use V$datafile to view information about data file related to NON-RAC Environment Use GV$Datafile to view information about datafile related to RAC Environment ,

the difference between V$ and GV$ view is INST_ID column which stores Instance ID information in RAC Environment.

V$DATAFILE reads the data file information from control file, some important information you can obtain from V$DATAFILE are  Data file status( OFFLINE, ONLINE, SYSTEM, RECOVE ), SCN at last checkpoint , Size when created (in bytes)  , weather this data file is enabled for DML operations or Not (see  ENABLED column status)

Weirdness of v$datafile on a standby db.

V$DATAFILE and Standby Database.

On a standby database "STATUS" column wouldn't get updated in some scenarios. All data files created after the standby control file creation timestamp would get "RECOVER" status as they get pushed to the standby database. Solution to this problem is to query V$datafile_header . Whenever we query v$datafile_header, Oracle retrieve the all data file header blocks, and it gives us the right "STATUS" of data files.

Related Tables or Dynamic views

file$

ts$

x$ktfbhc

dba_data_files

dba_temp_files

gv$dbfile

dba_free_space

v$datafile_header

To know the view definition V$DATAFILE you can simple query

OPatch failed with error code 104 when using OPATCH

Possible reasons for this error could be either a  missing oraInst.loc file or permission issues with oraInst.loc file, oraInst.loc located in in /var/opt/oracle  directory on unix platform. Ensure Oracle user have  read/write priviligies on orainst.loc file as well as on the actual path of orainventory location.

 if you could not fix the issue and if you know the inventory location you may want try following solution

"You would hardcode the orainventory location in Opatch apply command "

ex :opatch apply -invPtrLoc /full/path/oraInst.loc

 Here  invPtrLoc is a Opatch Switch .