Deploying Oracle E-Business Suite plug-in or Oracle Application Management Pack into ORACLE OEM 12C

This post will provide u steps to deploy Oracle E-Business Suite plug-in into ORACLE OEM 12C which is also known as Oracle Application Management Pack for Oracle E-Business Suite.

The Oracle Application Management Pack for Oracle E-Business Suite extends Oracle Enterprise Manager 12c Cloud Control to help monitor and manage Oracle E-Business Suite systems more effectively. The pack integrates Oracle Applications Manager with Cloud Control to provide a consolidated, end-to-end Oracle E-Business Suite management solution. The pack can be used to manage both Oracle E-Business Suite Release 11i systems and Release 12 systems.

Before proceeding with deployment u first need to download “Oracle Application Management Suite for Oracle E-Business Suite 12.1.0.3.0” from https://edelivery.oracle.com. This will be a zip file named :V46070-01.zip & with size 433MB.

Now u r ready for OAM suite deployment:


oracle@rmb-zdr-oem01:$export EMCLI_STATE_DIR=/export/home/oracle/plugins
oracle@rmb-zdr-oem01:$export PATH=$PATH:$EMCLI_STATE_DIR
oracle@rmb-zdr-oem01:$ /u01/oracle/12C/middleware/oms/bin/emcli setup -dir=$EMCLI_STATE_DIR -url=https://oracle@rmb-zdr-oem01:7799 -user=sysman
Oracle Enterprise Manager 12c Release 4.
Copyright (c) 1996, 2014 Oracle Corporation and/or its affiliates. All rights reserved.
The configuration directory "/export/home/oracle/plugins" may not be local. See the "dir" option in the help for the setup command.
Do you want to continue using this directory? [yes/no] yes
Enter password:

This process should successfully complete giving status : Emcli setup successful.

Extract V46070-01.zip which will give u this file : ~/software/EBS-PlugIn/12.1.0.3.0/12.1.0.3.0_oracle.apps.ebs_2000_0.opar. Now update this plugin into OEM.


oracle@zbx-oem01:$ /u01/oracle/12C/middleware/oms/bin/emcli import_update -file="/export/home/oracle/plugins/software/EBS-PlugIn/12.1.0.3.0/12.1.0.3.0_oracle.apps.ebs_2000_0.opar" -omslocal
Processing update: Plug-in - Enterprise Manager for Oracle E-Business Suite consists of System Management and Change Management Feature Sets
Successfully uploaded the update to Enterprise Manager. Use the Self Update Console to manage this update.

Now U need to use OEM/OMS console to deploy plugin. PFB screenshots for the same: Go to Setup => Extensibility => Plug-ins:

ebiz pluggin

 

ebiz pluggin

ebiz pluggin2

ebiz pluggin3

ebiz pluggin4

ebiz pluggin5

ebiz pluggin7

After this U need to monitor progress using command : emctl status oms -details:

Once everything is back up & running, U can log out and login to OEM console to have deployed Oracle E-Business Suite plug-in πŸ™‚

ebiz plugin screenshots status

ebiz pluggin9

ebiz pluggin10

Hope so u will find this post very useful πŸ™‚

Cheers

Regards,

Adityanath

Advertisements

RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

Today one of our developer accidently dropped some of apllication base tables from devlopment instance instead of uat environment. So there was a request re-clone devlopment database from one month old backup which was used for cloning earlier.

Simple!! everything was in proper place including datafile backups, archivelog backups, controlfile backups & cloning scripts too πŸ™‚

I was using following clause for point in time recovery:

SET UNTIL TIME “to_date(’22-07-2014 02:10:00′,’DD-MM-YYYY HH24:MI:SS’)”;

While restoring backup I got following error:

RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time 😦

As error suggests until time was definitely before last resetlogs which was done on 24th July. But from where its getting that information , as I restored controlfile which was definitely before last resetlog.

So definitely database incarnation is the issue:


RMAN> list incarnation;
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 FIN1 3024510604 PARENT 2704716842 07-JUL-14
2 2 FIN1 3024510604 PARENT 2704717919 07-JUL-14
3 3 FIN1 3024510604 CURRENT 6007342103534 24-JUL-14

So we need to set earlier incarnation in my case ‘2’ to proceed with the restore πŸ™‚


RMAN> reset database to incarnation 2;
database reset to incarnation 2
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 FIN1 3024510604 PARENT 2704716842 07-JUL-14
2 2 FIN1 3024510604 CURRENT 2704717919 07-JUL-14
3 3 FIN1 3024510604 ORPHAN 6007342103534 24-JUL-14

So here restore proceeded without any issues.

Hope so u will find this post very useful πŸ™‚

Cheers

Regards,

Adityanath

Flashback truncate table Using Oracle Total Recall OR Flashback Data Archive

From version 11g Oracle has come with new enhancement – Flashback Data Archive also known as Oracle Total Recall.

With the “Oracle Total Recall” option, Oracle database 11g has been specifically enhanced to track history with minimal performance impact and to store historical data in compressed form to minimize storage requirements, completely transparent to applications, easy to setup. It is a logical container for storing historical information. It is stored in one or more tablespaces and tracks the history for one or more tables.You specify retention duration for each flashback data archive (could be # of years).

Normally traditional flashback table has its own limitation as it cannot flashback table on which any DDL performed including truncate. Look at example given below:


13:40:10 SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
 YES
13:40:38 SQL> create table test as select * from dba_users;
Table created.
13:41:20 SQL> select count(0) from test;
COUNT(0)
----------
 10
13:41:29 SQL> insert into test select * from test;
10 rows created.
13:42:00 SQL> commit;
Commit complete.
13:42:03 SQL> select count (0) from test;
COUNT(0)
----------
 20
13:45:06 SQL> alter table test enable row movement;
Table altered.
13:45:20 SQL> FLASHBACK TABLE test TO TIMESTAMP TO_TIMESTAMP('2014-08-21 13:41:29', 'YYYY-MM-DD HH24:MI:SS');
Flashback complete.
13:45:30 SQL> select count(0) from test;
COUNT(0)
----------
 10
13:46:08 SQL> truncate table test;
Table truncated.
13:46:28 SQL> select count(0) from test;
COUNT(0)
----------
 0
13:46:40 SQL> FLASHBACK TABLE test TO TIMESTAMP TO_TIMESTAMP('2014-08-21 13:41:29', 'YYYY-MM-DD HH24:MI:SS');
FLASHBACK TABLE test
 *
ERROR at line 1:
ORA-01466: unable to read data - table definition has changed
14:04:26 SQL> select count(*) from test as of timestamp TO_TIMESTAMP('2014-08-21 13:41:29', 'YYYY-MM-DD HH24:MI:SS');
select count(*) from test as of timestamp TO_TIMESTAMP('2014-08-21 13:41:29', 'YYYY-MM-DD HH24:MI:SS')
 *
ERROR at line 1:
ORA-01466: unable to read data - table definition has changed

Here we can conclude that we can not flashback table which has been truncated. We can overcome with this limitation using Oracle Total Recall. Please find below steps to use this feature :

14:31:33 SQL> create flashback archive flash_test tablespace FATBS retention 10 year;
Flashback archive created.
14:32:15 SQL> alter table test flashback archive flash_test;
Table altered.
14:32:56 SQL> insert into test select * from dba_users;
10 rows created.
14:33:24 SQL> commit;
Commit complete.
14:33:28 SQL> select count(0) from test;
COUNT(0)
----------
 20
14:33:37 SQL> truncate table test;
Table truncated.
14:34:05 SQL> FLASHBACK TABLE test TO TIMESTAMP TO_TIMESTAMP('2014-08-21 14:33:36', 'YYYY-MM-DD HH24:MI:SS');
FLASHBACK TABLE test TO TIMESTAMP TO_TIMESTAMP('2014-08-21 14:33:36', 'YYYY-MM-DD HH24:MI:SS')
 *
ERROR at line 1:
ORA-01466: unable to read data - table definition has changed
14:34:25 SQL> select count(*) from test as of timestamp TO_TIMESTAMP('2014-08-21 14:33:36', 'YYYY-MM-DD HH24:MI:SS');
COUNT(*)
----------
 20
14:34:56 SQL> insert into test select * from test as of timestamp TO_TIMESTAMP('2014-08-21 14:33:36', 'YYYY-MM-DD HH24:MI:SS');
20 rows created.
14:35:59 SQL> commit;
Commit complete.
14:36:05 SQL> select count(0) from test;
COUNT(0)
----------
 20

I got my data back even though table was truncated. πŸ™‚

Flashback archive restrictions:

  • If flashback archive is enabled some DDL operations can cause ORA-55610 – Invalid DDL statement on history-tracked table like drop table, alter table etc.
  • You can’t enable Flashback Data Archive for temporary, external tables & tables containing long datatype

Reference Note : 11g feature: Flashback Data Archive Guide. (Doc ID 470199.1)

Hope so u will find this post very useful πŸ™‚

Cheers

Regards,

Adityanath

DBCA failing with ora-19870 ora-19504 ora-17502 ora-15081

Today while creating database on ASM using DBCA I got following error exactly after reaching 4%.

issue

After searching on net I found, a workaround of using “custom database” tempalate instead of “general purpos or transaction processing” in dbca.

template

I was not sure about this workaround, and as expected it failed at same point with same error.

DBCA was failing to create datafile in +DATA diskgroup. ASM database was up & running with +DATA in MOUNTED state.

Was it due to file permission issue on raw disks under ASM??

We have separate OS users for grid & rdbms home which belong to same primary group “oinstall”.

root@rmb-zdr-odb01# pwd
/dev/rdsk
root@rmb-zdr-odb01# ls -lrt
crw-r----- 1 grid oinstall 206, 69 Aug 16 10:39 c0t5000CCA01D2EC43Cd0s5
crw-r----- 1 grid oinstall 206, 68 Aug 16 10:39 c0t5000CCA01D2EC43Cd0s4
crw-r----- 1 grid oinstall 206, 66 Aug 17 17:24 c0t5000CCA01D2EC43Cd0s2
crw-r----- 1 grid oinstall 206, 64 Aug 17 17:24 c0t5000CCA01D2EC43Cd0s0
crw-r----- 1 grid oinstall 206, 67 Aug 17 17:26 c0t5000CCA01D2EC43Cd0s3
crw-r----- 1 grid oinstall 206, 65 Aug 17 17:36 c0t5000CCA01D2EC43Cd0s1

So here’s the culprit πŸ™‚ . Changed permissions to 660 instead of 640

 

root@rmb-zdr-odb01# ls -lrt
crw-rw---- 1 grid oinstall 206, 69 Aug 16 10:39 c0t5000CCA01D2EC43Cd0s5
crw-rw---- 1 grid oinstall 206, 68 Aug 16 10:39 c0t5000CCA01D2EC43Cd0s4
crw-rw---- 1 grid oinstall 206, 66 Aug 17 17:24 c0t5000CCA01D2EC43Cd0s2
crw-rw---- 1 grid oinstall 206, 64 Aug 17 17:24 c0t5000CCA01D2EC43Cd0s0
crw-rw---- 1 grid oinstall 206, 67 Aug 17 17:26 c0t5000CCA01D2EC43Cd0s3
crw-rw---- 1 grid oinstall 206, 65 Aug 17 17:36 c0t5000CCA01D2EC43Cd0s1

This time DBCA worked successfully without any issue!!

Hope so u will find this post very useful πŸ™‚

Cheers

Regards,

Adityanath

Configuring FRA – Flash Recovery Area

Today I faced very funny issue related to FRA – Flash Recovery Area.

Linux guys informed us to clear old files as one of the mount point on database server had reached to its threshold free space.

After investigating we found that one of database ORACLE_HOME was 192GB is size. Definately something was wrong with it.

I found that archivelogs are getting created under $ORACLE_HOME/dbs location though we were using FRA under ASM diskgroup.


SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination db_recovery_file_dest
Oldest online log sequence 421
Next log sequence to archive 425
Current log sequence 425

SQL> sho parameter db_recovery_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string +T_ARCHIVING
db_recovery_file_dest_size big integer 80G

SQL> sho parameter log_archive_dest_1
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1 string LOCATION=DB_RECOVERY_FILE_DEST

I was thinking everything is proper but still y archives are getting generated on filesystem instead of FRA 😦

Definately somewhere there was mistake but where… I followed simple approach to go through Oracle docs related to FRA.

Here I found following :

If a fast recovery area is configured, then you can add the fast recovery area as an archiving destination by setting any LOG_ARCHIVE_DEST_n parameter to LOCATION=USE_DB_RECOVERY_FILE_DEST.

So here is the culprit, parameter log_archive_dest_1 was set to “LOCATION=DB_RECOVERY_FILE_DEST” instead of “LOCATION=USE_DB_RECOVERY_FILE_DEST” πŸ˜€

Making necessary changes in said parameter resolved issue.


SQL> sho parameter log_archive_dest_1
NAME TYPE VALUE
------------------------------------ ----------- ----------------------------------
log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_DEST

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 423
Next log sequence to archive 427
Current log sequence 427

ASMCMD [+T_ARCHIVING/DATAMIG/ARCHIVELOG/2014_08_12] > ls
thread_1_seq_426.319.855411089
thread_1_seq_427.3475.855411181

Hope so u will find this post very usefulΒ πŸ™‚

Cheers

Regards,

Adityanath