Files on system are patched but Inventory Update has failed

Scenario:

Patching an Oracle 10g AS environment using opatch utility.

Platform: Windows

Error:

Updating inventory...
OPATCH_JAVA_ERROR  : Wrong number of arguments
Files on system are patched but Inventory Update has failed.  Please run 'opatch
 lsinventory' to check if the patch has been recorded in Inventory.(1)


Verifying patch...
OPATCH_JAVA_ERROR: Wrong number of arguments.  VerifyPatch needs ORACLE_HOME, OUI location, patch location, patch ID and path to 'ar' command, no_inventory, OS_ID.

java.lang.Exception: Wrong number of arguments.  VerifyPatch needs ORACLE_HOME,OUI location, patch location, patch ID and path to 'ar' command, no_inventory, OS_ID.        at opatch.VerifyPatch.main(VerifyPatch.java:803)
Exception in thread "main" Verification of the patch failed.

ERROR: OPatch failed as verification of the patch failed.
OPatch returns with error code = 240

Verification:

The patch application was succesfull, but updating the inventory was not happening. 
opatch lsinventory command failed to report the new patch.

Fixing:

The directory  location at which the patch was placed had space(" ") in it. 
For eg: I staged the patche under "C:\Stage\AS Softwares".

It is advisable to keep patch in a directory with out any space in its name.

I later moved the patch to C:\Stage and extracted it.

Later the patch application was succesfull.

In-place upgrade OBIEE 11.1.1.6.0 to 11.1.1.7.0

Requirement:

Upgrade OBIEE 11.1.1.6.0 to 11.1.1.7.0 in Linux


High level Steps:

It includes 3 high level steps mainly

1. OBIEE S/W upgrade
2. Upgrade repository schemas
3. Upgrade domain


Steps in detail:

1. Pre-Upgrade Steps

Stop all the BI components (AdminServer, Managed Server, opmn components and Nodemanager)

Take a backup of MW Home and Inventory

2. OBIEE S/W Upgrade

Download OBIEE 11.1.1.7.0 for the platform

Invoke runInstaller

Intallation Type Screen: Choose Software Only Install

Intallation Location Screen:The installer would automatically choose the current MW and BI installation directories.

Click Intall

3. Upgrade MDS and BIPLATFORM schemas using Patch Set Assistant (psa)

psa is available in $MW_HOME/oracle_common/bin

Invoke psa (./psa)

Select Component Screen: Choose only "Oracle Bussiness Intelligence". Both BIPLATFORM and MDS schema would be selected by default

Prerequisites Screen: Select both prerequisite check boxes 1. backup completed and 2. DB version certified by FMW upgrade

MDS Schema Screen: Give DB connection information and DB user "SYS as sysdba" and press "Connect" button
Give MDS and BIPLATFORM username and password.

Examine Screen: The status of the examination process would be shown in next page. Both status should be of status "Succeeded".
Click Upgrade button

4. Start nodemanager and AdminServer

Start nodemanager and Admin server. This is mandatory since during domain updation both Admin server and bi server has to be retsrated by the configuration utility.


5. Domain Upgrade using config utility

Invoke configuration utility from $MW_HOME/Oracle_BI1/bin folder

./config.sh

Create, Scale out or Extend Screen: Choose Update BI Domain option
Provide the Adminserver hostname, port number and user details

Update BI Domain Details Screen: Verify that all the paths chosen by the installer are accurate.

Click configure and Press Finish button when done

The Configuration Assistant will restart AdminServer and start the managed server, and OPMN components.

Verify that all the URLs are reachable and all components are up.

Weblogic 10.3.5 to 10.3.6 in-place upgrade

Action:

Download and apply the upgrade patch

Steps

1. Download the upgrade patch from metalink. The patch number is 13529623. 

You can also search for the correct patch in metalink using the "Patches &   Updates" tab

In the "Patch Search" box provide the following details 

Oracle WebLogic Server as Product, 10.3.6 as Release, Linux X86 as Platform (Linux 64 bit was my platform) and  give Upgrade in the Description field to reduce the number of search results.

2. Unzip the downloaded file. 
The resultant file would be wls1036_upgrade_generic.jar file.

3. Backup MW folder and Inventory directory
Shutdown all the WLS services and backup the directories. Always good to     have the backup in place before a major upgrade.

4. Invoke the upgrade installer and follow the intrauctions in the installer
java -d64 -jar wls1036_upgrade_generic.jar

5. Choose "Use and existing middleware home" option and pick the current MW Home location for upgrade. All the screens are self explanatory.

6. Click complete.
Files will now be upgraded to 10.3.6.0 Maintenance level

7. Startup the Weblogic Admin server
The startup log will show the latest maintenance level of 10.3.6.0

Get user creation metadata and all roles/privileges granted to the user

Requirement:

Create a database user in another DB based on the user available in the source DB with the same object/DB level grants.

DB Version: 11.2.0.2.0

Steps

1. Find the User creation script from source database

Extract the DDL used for the user creation using dbms_metadata

SQL> select dbms_metadata.get_ddl('USER','MYUSER') from dual;

DBMS_METADATA.GET_DDL('USER','MYUSER')

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

   CREATE USER "MYUSER" IDENTIFIED BY VALUES 'S:2526C5A32BD6A196B2A

2F2CC6F5E88D4A5932593709E4CC838BFDC036C27;C84965A9EC7311F4'

      DEFAULT TABLESPACE "USERS"  TEMPORARY TABLESPACE "TEMP"

2. Get system privileges granted to the user using dba_sys_privs

SQL> select PRIVILEGE from dba_sys_privs where GRANTEE='MYUSER';

PRIVILEGE

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

UNLIMITED TABLESPACE

3. Get the roles granted to the user using dba_role_privs

SQL> select GRANTED_ROLE from dba_role_privs where GRANTEE='MYUSER';

GRANTED_ROLE

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

CONNECT

DBA

4. Get all object grants of the user using dba_tab_privs

SQL> select OWNER,TABLE_NAME,PRIVILEGE from dba_tab_privs where GRANTEE='MYUSER';

no rows selected

TNS-01106: Listener using listener name has already been started

Scenario:

DB version: 11.2.0.3.0

The following error was found on trying to start a newly created listener in a shared DB server with multiple Oracle Homes.

TNS-01106: Listener using listener name  has already been started

Verification:

From the error message it seem to happen because of a duplicate LISTENER name, but it was not the case to be. I tried to give different names to the listener but still was getting same error on listener start up

Solution:

A detailed analysis of the error helped me to find that it can happen if any other listener is already listening on one of the parameters in the ADDRESSes specified. In my case the port number I tried to give for the new listener was already in use. But since the error normally expected with a port number conflict is different (TNS-12542: TNS:address already in use), I was wasting my time concentrating on LISTENER name.

I changed the TCP port number in the listener.ora file and successfully started the listener.

ORA-27046: file size is not a multiple of logical block size with SPFILE

Scenario:

Creation of pfile from the existing spfile. The following error stack was seen.

ERROR at line 1:
ORA-01565: error in identifying file '?/dbs/spfile@.ora'
ORA-27046: file size is not a multiple of logical block size
Additional information: 1

Reason:

The SPFILE is corrupted. The corruption could have happened because of the manual editing of the binary SPFILE. There is no way the spfile can be repaired or modified manually because spfile is a binary file.

Solution:


1. Restore from backup (If we have a recent backup of spfile then can restore it)
2. Create pfile from alert log file. We can get the list of non-default parameters from the alert log at startup time and with that can create pfile.
3. Get the parameters from the corrupted spfile using utilities like strings. We can even try using tools like "vi" to open the spfile and get the parameters.
Eg: strings spfile$ORACLE_SID.ora init$ORACLE_SID.ora

Then create spfile from the pfile.

Enable archive log mode in RAC database

Case:

To enable archive log mode in an 11gR2 RAC database.


Steps:

Need to shutdown all instances of the RAC and then "MOUNT"  a single node to switch it to ARCHIVELOG mode. It is recommended to have more than one archive destination.

It is better to keep ArchiveLogs on shared storage because any node of the cluster can be used to backup the ArchiveLogs. If we are using FRA as backup location then it makes sense to keep the files there.


ALTER SYSTEM SET log_archive_dest_1='location=/app/db_backup/archive/ORCL/' SCOPE=spfile; 
ALTER SYSTEM SET log_archive_format='arch_%t_%s_%r.arc' SCOPE=spfile;

Set cluster_database parameter to false since we have to mount the database in exclusive mode. 
.
ALTER SYSTEM SET cluster_database=FALSE SCOPE=spfile;

srvctl stop database -d ORCL

STARTUP MOUNT;

Since the datafiles and spfile are shared between all instances this operation only has to be done from a single node.

ALTER DATABASE ARCHIVELOG;
ALTER SYSTEM SET cluster_database=TRUE SCOPE=spfile;
SHUTDOWN IMMEDIATE;

srvctl start database -d ORCL


Disabling:

Follow similar steps to disable archiving.

ALTER SYSTEM SET cluster_database=FALSE SCOPE=spfile;

srvctl stop database -d ORCL

STARTUP MOUNT;

alter database noarchivelog;

ALTER SYSTEM SET cluster_database=TRUE SCOPE=spfile;

SHUTDOWN IMMEDIATE;

srvctl start database -d ORCL