Normally, when we have this error, we are trying to adapt the retention parameters or to tune our queries.

SQL> show parameter undo;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
temp_undo_enabled                    boolean     FALSE
undo_management                      string      AUTO
undo_retention                       integer     3600 --extended from 900,
undo_tablespace                      string      UNDOTBS1

But, are some scenarios where the above rule is not working .

We got from the alert log file of the DB the sql id which caused the issue : pmrbk5fdfd665

But, when you want to search for it, in V$SQL/V$SQLAREA  is not there

SQL> select sql_fulltext from v$sql where sql_id like '%pmrbk5fdfd665%';

no rows selected

Why?

Seems that, sql_id is present in V$OPEN_CURSOR, with an input into the sqltext column.
The issue is coming from the fact that the statement is accessing a LOB column, which causes to Oracle to generate a new sql id.
The execution part related to the LOBs will not appear into V$SQL/V$SQLAREA and is not captured into the AWR reports.

SQL>  select distinct * from v$open_cursor
  2     where rownum < 25
  3     and sql_id like '%pmrbk5fdfd665%';

SADDR                   SID USER_NAME                      ADDRESS          HASH_VALUE SQL_ID        SQL_TEXT                                                     LAST_SQL SQL_EXEC_ID CURSOR_TYPE
---------------- ---------- ------------------------------ ---------------- ---------- ------------- ------------------------------------------------------------ -------- ----------- ---------------
0000000670A19780         74 my_user                   00000002EB91F1F0 3831220380 pmrbk5fdfd665 table_104_11_XYZT_0_0_0
00000006747F0478        131 my_user                   00000002EB91F1F0 3831220380 pmrbk5fdfd665 table_104_11_XYZT_0_0_0

Apparently, the string into the sql_text column is  a  HEX representation of the object_id that is being accessed.
In our case is :XYZT

SQL>    select owner, object_name, object_type
  2    from dba_objects
  3    where object_id = (select to_number('&hex_value','XXXXXX') from dual);
Enter value for hex_value: XYZT
old   3:   where object_id = (select to_number('&hex_value','XXXXXX') from dual)
new   3:   where object_id = (select to_number('XYZT','XXXXXX') from dual)

                                                                                                                    
OWNER                  OBJECT_TYPE                                               OBJECT_NAME
---------------------- --------------------------------------------------------------------------
my_user                TABLE                                                     my_table


SQL> desc my_user.my_table;
 Name                  Type
 -------------------   ----------------
 EXPERIMENT_ID          VARCHAR2(20)
 DOCUMENT               BLOB
............….

If we are looking for the retention on the ” DOCUMENT ” column, we will see :

SQL> select table_name, pctversion, retention,segment_name from dba_lobs where table_name in ('my_table');

TABLE_NAME                                                                               
                                                  PCTVERSION  RETENTION                  SEGMENT_NAME
---------------------------------------------------------------------------------------- ------------------------------------
my_table                                                       900                       SYS_LOB0000027039C00002$$

In order to fix it , try to run this column to adapt the retention of the blob column, related to the new value of the UNDO_RETENTION parameter,

ALTER TABLE my_table MODIFY LOB (DOCUMENT) (3600);

L’article When you change the UNDO_RETENTION parameter, the LOB segment’s retention value is not modified est apparu en premier sur dbi Blog.

At the beginning we have to ensure that we applied the latest PSU on the repository database.

It is mandatory to apply the following patch before upgrading to Enterprise Manager Cloud Control 13.2.0.0:

DATABASE PATCH SET UPDATE 12.1.0.2.160419

To install the patch you have to check the following point:

– you have to use Oracle Interim Patch Installer version 12.2.0.1.8

Once you have downloaded the patch and unzipped it, you can check for potential conflicts:

oracle@vmCC13c:/u01/app/oracle/ [EMREP13C] opatch prereq 
CheckConflictAgainstOHWithDetail 
-phBaseDir /oracle/u01/app/oracle/software/22899531/22806133
Oracle Interim Patch Installer version 12.2.0.1.8
Copyright (c) 2016, Oracle Corporation.  All rights reserved.
PREREQ session
Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0/dbhome_1/oraInst.loc
OPatch version    : 12.2.0.1.8
OUI version       : 12.1.0.2.0
Invoking prereq "checkconflictagainstohwithdetail"
Prereq "checkConflictAgainstOHWithDetail" passed. 
OPatch succeeded.

oracle@vmCC13c:/u01/app/oracle/ [EMREP13C] opatch prereq 
CheckConflictAgainstOHWithDetail -phBaseDir 
/oracle/u01/app/oracle/software/22899531/23006522
Oracle Interim Patch Installer version 12.2.0.1.8
Copyright (c) 2016, Oracle Corporation.  All rights reserved.
PREREQ session
Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0/dbhome_1/oraInst.loc
OPatch version    : 12.2.0.1.8
OUI version       : 12.1.0.2.0
Invoking prereq "checkconflictagainstohwithdetail"
Prereq "checkConflictAgainstOHWithDetail" passed.
OPatch succeeded.

And finally, you check for the system space available:

oracle@vmCC13c:/u01/app/oracle/ [EMREP13C] $ORACLE_HOME/OPatch/opatch prereq 
CheckSystemSpace -phBaseFile /oracle/u01/app/oracle/software/patch_list_dbhome.txt
Oracle Interim Patch Installer version 12.2.0.1.8
Copyright (c) 2016, Oracle Corporation.  All rights reserved.
PREREQ session
Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0/dbhome_1/oraInst.loc
OPatch version    : 12.2.0.1.8
OUI version       : 12.1.0.2.0
Invoking prereq "checksystemspace"
Prereq "checkSystemSpace" passed.
OPatch succeeded.

Then once the pre requisites are ok, you stop the repository database, and you run the classical opatch apply command from the directory where you have unzipped the PSU.

You finally check the Oracle inventory:

oracle@vmtestoraCC13c:/home/oracle/ [EMREP13C] opatch lsinventory
Oracle Interim Patch Installer version 12.2.0.1.8
Copyright (c) 2016, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0/dbhome_1/oraInst.loc
OPatch version    : 12.2.0.1.8
OUI version       : 12.1.0.2.0
--------------------------------------------------------------------------------
Local Machine Information:
ARU platform id: 226
ARU platform description:: Linux x86-64
Installed Top-level Products (1):
Oracle Database 12c                                      12.1.0.2.0
There are 1 products installed in this Oracle Home. 
Interim patches (1) : 
Patch  22806133     : applied on Tue Nov 22 11:19:55 CET 2016
Unique Patch ID:  19983161
Patch description:  "DATABASE BUNDLE PATCH: 12.1.0.2.160419 (22806133)"

Secondly you have to disable the optimizer_adaptive_features parameter in the repository database:

SQL> alter system set optimizer_adaptive_features=false scope=both;

System altered.

Then we have to ensure that the tables in the Management Repository do not have any snapshots created:

SQL> select master , log_table from all_mview_logs where log_owner='SYSMAN';

no rows selected

Then we have to ensure that the tables in the Management Repository do not have any snapshots created:

SQL> select master , log_table from all_mview_logs where log_owner='SYSMAN';

no rows selected

We verify if any login triggers are set:

SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers 
WHERE TRIGGERING_EVENT LIKE 'LOGON%' AND status='ENABLED';
SQL> SELECT trigger_name FROM sys.dba_triggers 
WHERE TRIGGERING_EVENT LIKE 'LOGON%' AND status='ENABLED';

We verify if any logoff triggers are set:

SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers
WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';
SQL> SELECT trigger_name FROM sys.dba_triggers
WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';

If we find a trigger enabled, we disable it:

SQL> SELECT trigger_name, owner from sys.dba_triggers 
WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';
 
TRIGGER_NAME         OWNER
GSMLOGOFF            GSMADMIN_INTERNAL
 
SQL> alter trigger gsmadmin_internal.gsmlogoff disable;

Then you have to copy the EMKEY to the repository database:

oracle@vmCC13c:/u03/app/oracle/oms13c/bin/ [oms13c] emctl config emkey 
-copy_to_repos -sysman_pwd dbi05manager
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
The EMKey has been copied to the Management Repository. 
This operation will cause the EMKey to become unsecure.
After the required operation has been completed, 
secure the EMKey by running "emctl config emkey -remove_from_repos".

Concerning the OMS shutdown we follow the following procedure:

We stop the JVMD and ADP engines explicitly:

oracle@vmCC13c:/u03/app/oracle/oms13c/bin/ [oms13c] emctl extended oms jvmd stop -all
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
No verb found to be registered with emctl extensibles framework
 
oracle@vmCC13c:/u03/app/oracle/oms13c/bin/ [oms13c] emctl extended oms adp stop -all
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
No verb found to be registered with emctl extensibles framework

Then we shut down completely the OMS:

oracle@v333:/home/oracle/ [oms13c] emctl stop oms -all
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Stopping Oracle Management Server...
WebTier Successfully Stopped
Oracle Management Server Successfully Stopped
Oracle Management Server is Down
JVMD Engine is Down
Stopping BI Publisher Server...
BI Publisher Server Successfully Stopped
AdminServer Successfully Stopped
BI Publisher Server is Down

It is mandatory to stop the management agent in order to avoid errors during the migration phase:

oracle@vmtestoraCC13c:/home/oracle/ [agent13c] emctl stop agent
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Stopping agent ... stopped.

WATCH OUT: before running the installer unset PERLLIB and PERL5LIB variables (if for example you have environment variables defined for your oracle user) otherwise you will get the following error:

/opt/oracle/Middleware13c/perl/lib/5.10.0/x86_64-linux-thread-multi/auto/Cwd/Cwd.so: 
undefined symbol: Perl_Gthr_key_ptr
ERROR: Unable to continue with the installation 
because some one-off patches could not be applied successfully.

Then once the oms and the management agent are stopped you can run:

oracle@v333:/opt/software/ [oms13c] ./em13200_linux64.bin
Checking monitor: must be configured to display at least 256 colors.   
Actual 16777216    Passed
Checking swap space: must be greater than 512 MB.   Actual 7999 MB    Passed
Checking if this platform requires a 64-bit JVM.   Actual 64    
Passed (64-bit not required)
Preparing to launch the Oracle Universal Installer 
from /tmp/OraInstall2016-11-18_10-07-45AM
====Prereq Config Location main===
/tmp/OraInstall2016-11-18_10-07-45AM/stage/prereq
EMGCInstaller args -scratchPath
EMGCInstaller args /tmp/OraInstall2016-11-18_10-07-45AM
EMGCInstaller args -sourceType
EMGCInstaller args network
EMGCInstaller args -timestamp
EMGCInstaller args 2016-11-18_10-07-45AM
EMGCInstaller args -paramFile
EMGCInstaller args /tmp/sfx_f8wrWz/Disk1/install/linux64/oraparam.ini
EMGCInstaller args -nocleanUpOnExit
DiskLoc inside SourceLoc/opt/software
EMFileLoc:/tmp/OraInstall2016-11-18_10-07-45AM/oui/em/
ScratchPathValue :/tmp/OraInstall2016-11-18_10-07-45AM

The first installer screen appears:

I choosed not to receive Security alerts then I Select Next:

I select Next, I skip the software Updates

We check the prerequisites are ok

We choose to upgrade an existing Enterprise Manager system, we enter the old Middleware home, and we select Next

We enter the new Middleware home, and we select Next

We enter the repository connection details, the sys and sysman passords, we confirm we have a correct repository backupm we disable the DDMP jobs and we select Next

We select Yes to fix the issues

We review the plugins and we select Next

We have the possibility to add plugins we want to deploy while upgrading to EM 13.2

We enter the weblogic username and password and we select Next

I choosed not to configure a shared location for Oracle BI publisher

We choose the default ports and we select Next

We select Upgrade:

The upgrade is running fine:=)

At the end of the upgrade, you have to run connected as root from the new OMS home the shell root.sh:

root@vmCC13c oms13cr2]# . root.sh
/etc exist
/u03/app/oracle/oms13cr2

Finally you have successfully upgraded to EM 13.2:

Once the OMs is upgraded, you have to upgrade the management agents with the classical procedure. From the EM console you select upgrade agent as follows:

You add the management agent, and you select Submit

You can follow the upgrade phase, finally you have to run the root.sh script on the management agent and cleanup the old agent environment with the EM console as follows:

You select the Post Agent Upgrade Tasks, you select the agent previously migrated:

And you select Submit

The old agent home will be removed; you will just have to adapt your /etc/oratab file to give the new ORACLE_HOME for your agent 13.2

The last phase consists in deleting the old OMS home. As we were in 13.1 version, we only have to check nothing is running with the old environment, then delete the old home.

oracle@vmCC13c:/u03/app/oracle/oms13cr2/ [oms13c] ps -ef | grep oms | grep -v 13cr2
oracle   28463 27736  0 15:52 pts/5    00:00:00 grep --color=auto oms
 
oracle@vmCC13c:/u03/app/oracle/ [oms13c] ls
agent13c  CC13c_setupinfo.txt  gc_inst  gc_inst1  oms13c  oms13cr2  swlib
oracle@vmCC13c:/u03/app/oracle/ [oms13c] rm -rf oms13c

The new features are listed in the following URL and mainly concern the virtualization, the Middleware and Cloud Management, and some new features about incident management (always on monitoring installed on a different host for example).

http://docs.oracle.com/cd/E73210_01/EMCON/GUID-503991BC-D1CD-46EC-8373-8423B2D43437.htm#EMCON-GUID-503991BC-D1CD-46EC-8373-8423B2D43437

Finally the upgrade phase to EM 13.2 is finished in a couple of hours and did not present any errors.

L’article Upgrade to Enterprise Manager 13.2 est apparu en premier sur dbi Blog.

Sometimes it is necessary to rename targets in Enterprise Manager Cloud Control 12c. In my case I have listener targets discovered by EM12c with the hostname at the end of the target name: TESTDBA_LSN_dbserver1

As I work in a Veritas clustered environment, when the target switches to the other node (dbserver2) the listener target is relocated, but its name is always TESTDBA_LSN_dbserver1.

How to rename a listener target in EM Cloud Control 12c?

We use emcli to list the agent’s targets:

oracle@dbserver1:/opt/oracle/agent12c/core/12.1.0.4.0/bin/ [agent12c] ./emctl config agent 
listtargets | grep TESTDBA

[TESTDBA_SITE1.domain.com, oracle_database]

[TESTDBA_LSN_dbserver1, oracle_listener]

From the Oracle Management Repository, we can also run the query:

SQL>SELECT ENTITY_TYPE,ENTITY_NAME,DISPLAY_NAME
FROM SYSMAN.EM_MANAGEABLE_ENTITIES
WHERE MANAGE_STATUS = 2
and DISPLAY_NAME like '%TESTDBA%'
ORDER BY 1;

ENTITY_TYPE           ENTITY_NAME                          DISPLAY_NAME
oracle_database    TESTDBA_SITE1.domain.com             TESTDBA_SITE1.domain.com
oracle_dbsys       TESTDBA_SITE1.domain.com_sys         TESTDBA_SITE1.domain.com_sys
oracle_listener    TESTDBA_LSN_dbserver1                TESTDBA_LSN_dbserver1

Then from OMS server you can change the display_name:

oracle@omsserver:/home/oracle/[oms12c] emcli modify_target 
-name="TESTDBA_LSN_dbserver1" -type="oracle_listener" -display_name="TESTDBA_LSN"

Target "TESTDBA_LSN_dbserver1:oracle_listener" modified successfully

If we run again the previous query the display name is modified in the repository, and the Cloud 12c console display the name correctly:

SQL>SELECT ENTITY_TYPE,ENTITY_NAME,DISPLAY_NAME
FROM SYSMAN.EM_MANAGEABLE_ENTITIES
WHERE MANAGE_STATUS = 2
and DISPLAY_NAME like '%TESTDBA%'
ORDER BY 1;

ENTITY_TYPE           ENTITY_NAME                       DISPLAY_NAME 
oracle_database    TESTDBA_SITE1.domain.com          TESTDBA_SITE1.domain.com 
oracle_dbsys       TESTDBA_SITE1.domain.com_sys      TESTDBA_SITE1.domain.com_sys 
oracle_listener    TESTDBA_LSN_dbserver1             TESTDBA_LSN

By the way, we need now to change the target name, we use emcli to rename the target from the OMS server but what a surprise the operation is not allowed and we get the following error message:

oracle@omsserver:/home/oracle/ [oms12c] emcli rename_target -target_type="oracle_listener"
 -target_name="TESTDBA_LSN_dbserver1" -new_target_name="TESTDBA_LSN"

Rename not supported for the given Target Type.

If we try to run the procedure from the Oracle Management Repository, we notice we have more details in the error message:

SQL> exec em_target.rename_target('oracle_listener','TESTDBA_LSN_dbserver1','TESTDBA_LSN', 'TESTBA_LSN');
BEGIN 
em_target.rename_target('oracle_listener','TESTDBA_LSN_dbserver1','TESTDBA_LSN', 'TESTBA_LSN'); 
END;
*ERROR at line 1:
ORA-20233: -20233 Not allowed
ORA-06512: at "SYSMAN.EM_TARGET", line 8033
ORA-06512: at line 1

I we look more precisely in the sysman em_target package body source code:

-- we will implement rename of agent side targets when it is fully
-- supported by agent
IF ( l_trec.manage_status = MANAGE_STATUS_MANAGED AND
l_trec.emd_url IS NOT NULL)
THEN
raise_application_error(MGMT_GLOBAL.INVALID_PARAMS_ERR,
MGMT_GLOBAL.INVALID_PARAMS_ERR||' Not allowed') ;
END IF ;

I decided to test the following modification; I put the code in comment and recreate and recompile the em_target package body:

-- we will implement rename of agent side targets when it is fully     
-- supported by agent  
-- IF ( l_trec.manage_status = MANAGE_STATUS_MANAGED AND   
--     l_trec.emd_url IS NOT NULL)   
-- THEN     
-- raise_application_error(MGMT_GLOBAL.INVALID_PARAMS_ERR,       
--   MGMT_GLOBAL.INVALID_PARAMS_ERR||' Not allowed') ;   
-- END IF ;

And now the target entity rename is working fine:

Oracle@omsserver:/home/oracle/ [oms12c] emcli rename_target 
-target_type="oracle_listener" -target_name="TESTDBA_LSN_dbserver1" 
-new_target_name="TESTDBA_LSN"

Target TESTDBA_LSN_dbserver1 successfully renamed to TESTDBA_LSN.

Finally my listener target has now a correct name:

SQL>SELECT ENTITY_TYPE,ENTITY_NAME,DISPLAY_NAME
FROM SYSMAN.EM_MANAGEABLE_ENTITIES
WHERE MANAGE_STATUS = 2
and DISPLAY_NAME like '%TESTDBA%'
ORDER BY 1;

ENTITY_TYPE          ENTITY_NAME                         DISPLAY_NAME
oracle_database   TESTDBA_SITE1.domain.com            TESTDBA_SITE1.domain.com
oracle_dbsys      TESTDBA_SITE1.domain.com_sys        TESTDBA_SITE1.domain.com_sys
oracle_listener   TESTDBA_LSN                         TESTDBA_LSN

Conclusion:

Don’t forget to back up your Oracle Management Repository database before any modifications in the EM_TARGET package, and once you have done your target name modification, uncomment the code you have modified to return to the original situation.

L’article How to rename listener target in EM Cloud 12c ? est apparu en premier sur dbi Blog.

The Enterprise Manager Cloud Control 12c is an amazing tool allowing the DBA to display a lot of informations from the console . But there are also a lot of repository views that may be consulted by the DBA to build a lot of various reports.

The Oracle Management Service collects a huge amount of raw data from the agents installed on each managed host you administer with EM 12c.

Those raw data are inserted in various tables like EM_METRIC_VALUES for example. Enterprise Manager aggregates those management data by hour and by day. Those raw data are kept 7 days; the one hour aggregated data are kept 31 days, while one day aggregated data are kept one year.

A good way to get information in the Oracle Management Repository is to build queries against the GC%METRIC% views. The GC_METRIC% views are built from EM_METRIC_VALUES. EM_METRIC_ITEMS and EM_METRIC_KEYS tables and the GC$METRIC% views are built from the GC_METRIC% views. There are a lot of GC%METRIC% views :

SQL> select distinct view_name from user_views where view_name like 'GC%METRIC%' order by 1;

GC$METRIC_CATEGORIES
GC$METRIC_COLUMNS
GC$METRIC_COLUMNS_TARGET 
GC$METRIC_ERROR_CURRENT
GC$METRIC_ERROR_HISTORY
GC$METRIC_GROUPS
GC$METRIC_GROUPS_TARGET
$METRIC_KEYS
GC$METRIC_LATEST
GC$METRIC_STR_VALUES
GC$METRIC_STR_VALUES_LATEST
GC$METRIC_VALUES
GC$METRIC_VALUES_DAILY
GC$METRIC_VALUES_HOURLY
GC$METRIC_VALUES_LATEST
GC$TARGET_METRIC_COLLECTIONS
GC_METRIC_COLLECTIONS
GC_METRIC_COLUMNS
GC_METRIC_COLUMNS_TARGET
GC_METRIC_COMPOSITE_KEYS
GC_METRIC_GROUPS
GC_METRIC_GROUPS_TARGET
GC_METRIC_KEYS
GC_METRIC_LATEST
GC_METRIC_LATEST_WO_TGT
GC_METRIC_STATS_METRIC
GC_METRIC_STATS_METRIC_DAILY
GC_METRIC_STATS_TARGET
GC_METRIC_STATS_TARGET_DAILY
GC_METRIC_STR_VALUES
GC_METRIC_STR_VALUES_LATEST
GC_METRIC_STR_VALUES_WO_TGT
GC_METRIC_THRESHOLDS
GC_METRIC_VALUES
GC_METRIC_VALUES_DAILY
GC_METRIC_VALUES_HOURLY
GC_METRIC_VALUES_LATEST
GC_METRIC_VAL_HOURLY_WO_TGT
GC_RAT_TRIAL_METRIC_VALUES
GC_RAT_TRIAL_TARGET_METRICS

For example if we are interested by the load for a host, you can use the console:

You can also find this information by querying the OMR in the view gc$metric_columns for an entity of type host and a metric_group_label of type Load:

SQL> select entity_type,metric_column_label,metric_group_label
from gc$metric_columns
where entity_type = 'host'
and metric_group_label = 'Load';

host       Active Logical Memory, Kilobytes              Load
host       Active Memory, Kilobytes                      Load
host       CPU Interrupt Time (%)                        Load
host       CPU Queue Length                              Load
host       CPU Utilization (%)                           Load
host       CPU in I/O Wait (%)                           Load
host       CPU in System Mode (%)                        Load
host       CPU in User Mode (%)                          Load
host       Free Memory (%)                               Load
host       Free Memory, Kilobytes                        Load
host       Logical Free Memory (%)                       Load
host       Memory Page Scan Rate (per second)            Load
host       Memory Utilization (%)                        Load
host       Page Transfers Rate                           Load
host       Run Queue Length (1 minute average,per core)  Load
host       Run Queue Length (15 minute average,per core) Load
host       Run Queue Length (5 minute average,per core)  Load
host       Swap Free (KB)                                Load
host       Swap Utilization (%)                          Load
host       Swap Utilization, Kilobytes                   Load
host       Total Processes                               Load
host       Total Users                                   Load

We can sort the metrics collected by entity type for example host :

SQL> select entity_type,metric_group_label
from gc$metric_columns
where entity_type = 'host'
group by entity_type,metric_group_label
order by 1,2;

host                                     All Processes
host                                     Battery details
host                                     Buffer Activity
host                                     CCCAppFileParser
host                                     CCCData_base
host                                     CCCData_group
host                                     CCCData_mapping
host                                     CCCData_obs
host                                     CCCData_queue
host                                     CCCData_warning
host                                     CCCWatchdog
host                                     CPU Usage
host                                     CPU Usage Internal
host                                     CPUs Details
host                                     Compute Node Temperature
host                                     DiscoverNow
….

Or an oracle database:

SQL> select entity_type,metric_group_label
from gc$metric_columns
where entity_type = 'oracle_database'
group by entity_type,metric_group_label
order by 1,2;

oracle_database                         ADDM Report - Global
oracle_database                         ALL Privileges
oracle_database                         ANY Privileges
oracle_database                         Access To Important Tables And Views
oracle_database                         Active Sessions by CPU and Wait Classes
oracle_database                         Alert Log
oracle_database                         Alert Log Content
oracle_database                         Alert Log Error Status
oracle_database                         Archive Area
oracle_database                         Archive Area - RAC Instance
oracle_database                         Audit Settings
oracle_database                         Audit Syslog Level
oracle_database                         AutoTask Client
oracle_database                         CPU Usage
oracle_database                         Collect SQL Response Time
oracle_database                         Connect Role
oracle_database                         Control files
oracle_database                         DB Alert Log
oracle_database                         DB Audit Files Permissions
oracle_database                         DB Control Files Permission
oracle_database                         DB Data Files Permissions
oracle_database                         DB InitParameter File Permissions
oracle_database                         DB Link Usage
oracle_database                         DB Password Setting
oracle_database                         DB Profile Setting
oracle_database                         DB Scheduler Jobs
oracle_database                         DBA Group Assignment
oracle_database                         DGPrimaryDBName
oracle_database                         Data Base parameter collection
oracle_database                         Data Failure
oracle_database                         Data Guard - 10.1 Database
oracle_database                         Data Guard - 9.2 Database
oracle_database                         Data Guard Failover
oracle_database                         Data Guard Fast-Start Failover
oracle_database                         Data Guard Fast-Start Failover Observer

So the main interest is to collect data from those views, for example we can look more precisely in the CPU consumption for a host:

SQL> select entity_name ,collection_time,min_value as min,avg_value as avg,max_value as max
from gc$metric_values_daily
where metric_group_name = 'Load'
and metric_column_name = 'cpuUtil'
and (entity_name like '%dbserver1%' )
order by 2,1 asc;

Entity_name                 collection_time         min         avg              max
dbserver1.localdomain         01-JUN-15            3.782      17.4089931       72.284
dbserver1.localdomain         02-JUN-15            2.788      11.3085764       38.61
dbserver1.localdomain         03-JUN-15            4.16       11.7149271       28.975
dbserver1.localdomain         04-JUN-15            5.526      11.6824271       29.451
dbserver1.localdomain         05-JUN-1             5.337      10.9915486       27.319
dbserver1.localdomain         06-JUN-15            5.664      16.7499653       45.798
dbserver1.localdomain         07-JUN-15            5.021      15.4098958       84.75
dbserver1.localdomain         08-JUN-15            4.664       9.7744375       28.159
dbserver1.localdomain         09-JUN-15            4.79        9.4026805       21.113
dbserver1.localdomain         10-JUN-15            5.17        9.5937881       31.238
dbserver1.localdomain         11-JUN-15            5.162       8.8185104       16.562
dbserver1.localdomain         12-JUN-15            5.666      11.0074132       33.058
dbserver1.localdomain         13-JUN-15            6.412      15.4432917       42.709
dbserver1.localdomain         14-JUN-15            5.897       9.6474548       40.575
dbserver1.localdomain         15-JUN-15            5.675      14.5982083       34.483

For a more precise measure you can select on gc$metric_values_hourly:

SQL> select entity_name,collection_time,min_value as min,avg_value as avg,max_value as max
from gc$metric_values_hourly
where metric_group_name = 'Load'
and metric_column_name = 'cpuUtil'
and (entity_name like 'dbserver1%' )
order by 1,2
/

Entity_name              collection_time                min            avg        max
….
dbserver1.localdomain   15-JUN-15 14:00:00            15.23            18.65     22.025
dbserver1.localdomain   15-JUN-15 15:00:00             7.844            9.17     11.406
dbserver1.localdomain   15-JUN-15 16:00:00             8.635           10.76     13.625
dbserver1.localdomain   15-JUN-15 17:00:00             7.928            9.57     16.607
dbserver1.localdomain   15-JUN-15 18:00:00             8.439           13.39     21.518
dbserver1.localdomain   15-JUN-15 19:00:00             7.722           10.56     14.767
dbserver1.localdomain   15-JUN-15 20:00:00             7.993            9.09     12.934
dbserver1.localdomain   15-JUN-15 21:00:00             7.449            9.20     12.2
dbserver1.localdomain   15-JUN-15 22:00:00             8.001           10.47     16.328
dbserver1.localdomain   15-JUN-15 23:00:00             7.366            8.77     14.51
….

We can also display those values in the EM12c console:

Thus there are great possibilities to query the gc$metric_values% views in order to build reports. For example if we look at the different metric_group_label for an oracle database entity:

SQL> select distinct metric_group_label from gc$metric_values_daily
2   where entity_type = 'oracle_database' order by 1;

Alert Log Error Status
Archive Area
CPU Usage
Database Job Status
Database Limits
Database Size
Deferred Transactions
Dump Area
Efficiency
Flash Recovery
Global Cache Statistics
Interconnect Traffic
Invalid Objects by Schema
Memory Usage
Messages per buffered queue
Messages per buffered queue per subscriber
Messages per persistent queue
Messages per persistent queue per subscriber
OCM Instrumentation
Optimal SGA
PGA Allocated
Recovery Area
Response
SCN Growth Statistics
SCN Instance Statistics
SCN Max Statistics
SGA Pool Wastage
Segment Advisor Recommendations
Space usage by buffered queues
System Response Time Per Call
Tablespace Allocation
Tablespaces Full
Throughput
User Audit
User Block
User Locks
Wait Bottlenecks
Waits by Wait Class
backup_archive_log_age
datafile_backup
flashback available
incident_meter
max number of datafiles

Then we can ask for more precise measures:

SQL> select distinct key_part_1 from gc$metric_values_daily 
where metric_group_name = 'wait_sess_cls' 
order by 1;

Administrative
Application
Cluster
Commit
Concurrency
Configuration
Idle
Network
Other
Queueing
Scheduler
System I/O
User I/O

And we can write a SQL request to analyse the User I/O wait:

SQL> select collection_time,
min_value as min_wait ,
avg_value as avg_wait ,
max_value as max_wait
from gc$metric_values_daily
where metric_group_name = 'wait_sess_cls'
and metric_column_name = 'dbtime_waitclass_pct'
and (entity_name like 'dbserver1%' )
and key_part_1 = 'User I/O'
order by 1,2 asc;

Collection_time       min_wait          avg_wait          max_wait
01-JUN-15            .190094016        45.7777238        86.9431254
02-JUN-15            .026723742        49.4623178        98.6886502
03-JUN-15            .09020789          32.6063701        98.7430495
04-JUN-15            .066328202        26.342438          97.1319971
05-JUN-15            .032959651        22.7424382        96.1533236
06-JUN-15            .574570414        22.2140084        93.9315499
07-JUN-15            .022970399        20.6773665        88.9020253
08-JUN-15            .058117038        17.5328715        98.5629756
09-JUN-15            .080441214        20.5507072        98.4615166
10-JUN-15            .057529812        19.1080933        97.4292408
11-JUN-15            .038726475        21.6932703        96.48269
12-JUN-15            .106343267        25.0541945        89.5404451
13-JUN-15            .257816863        13.5371153        80.1841142
14-JUN-15            .004258955        16.5949771        84.7824337
15-JUN-15            .020058791        19.1270265        89.8952919

Naturally we find back those I/O values in the EM12c console:

Conclusion: querying the OMR views might allow Oracle DBA to build interesting reports on Hosts and Databases activities.

L’article Querying the Oracle Management Repository est apparu en premier sur dbi Blog.

From the 12.1.0.3 version, a new column named ‘Required Data Available’ appeared in the Compliance Standard Result screen. This column defines if the data for the compliance evaluation rules for each target are in the repository or not.

If the value is ‘YES’, it means that the data necessary for the compliance rule has been collected. If the value is ‘NO’, it means that nothing has been collected nor evaluated. Thus we can consider that for this target the compliance rule is not OK.

Let’s have a look on my EM12c configuration. I added the OMSREP database in order to apply on the target the High Security Configuration for Oracle Database. Apparently everything is fine, except the required data available:

The requested configuration data is not available, and we do not have any violations available for this target’s security compliance.

EM 12c provides many compliance standards for various targets, in our case High Security Configuration for Oracle Database. But by default the configuration is not collected. We can notice that when we associate a target to a compliance standard, we receive the following message:

We have to enable those collections by applying an Oracle Certified Template to the target, in our case it will be Oracle Certified – Enable Database Security Configuration Metrics, because those configuration metrics are not enabled by default in order not to overload the OMR (Oracle Management Repository):

You choose the Oracle Certified Database Security Configuration Metrics, you select Apply, you select your target database, and then select OK:

Now the target has its collections enabled.

At the beginning of our test we did not have any schedule about oracle security. Using emctl staus agent scheduler combined with a grep on the instance name and another grep with the metric collection gived no result:

oracle@em12c:> emctl status agent scheduler | grep OMSREP | grep oracle_security
oracle@em12c:>

Now the collection for the certified template has been applied, but we have to start the schedule:

oracle@em12c:> emctl startschedule agent -type oracle_database
Oracle Enterprise Manager Cloud Control 12c Release 5
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
Start Schedule TargetType succeeded

And the agent status agent scheduler command shows the oracle_security collections and their scheduled time:

oracle@em12c:>emctl status agent scheduler | grep OMSREP | grep oracle_security

2015-11-23 10:33:59.854 : oracle_database:OMSREP:oracle_security_inst2
2015-11-23 10:34:50.068 : oracle_database:OMSREP:oracle_security

We can run a collection from the agent12c with emctl:

oracle@em12c:>emctl control agent runCollection 
OMSREP:oracle_database oracle_security 
Oracle Enterprise Manager Cloud Control 12c Release 5 
Copyright (c) 1996, 2015 Oracle Corporation. 
All rights reserved. 
--------------------------------------------------------------- 
EMD runCollection completed successfully

Finally now we can visualize the violations and target evaluations:

Conclusion

If you use the compliance standard, be careful with the column ‘Required Data Available’, you won’t be sure you will have correct compliance results. Don’t forget that some configuration metrics are not enabled by default.

L’article Oracle Compliance Standard est apparu en premier sur dbi Blog.

In your EM installation, CC12c will notify your different administrators when specific incidents, events, or problems occurs.
But from standard configuration, you will receive only one warning or critical notification/alert … until the Clear or an Acknowledge of the alert.
Some times and for different reasons (human error, email was deleted, Mail server issues, …) you can lost or forgot this alert.
Hummm this is not good … especially for a critical alert on a productive environment!
To avoid such incomfortable case, you can configure Repeat of Notification in your Incident Rules.

Description:
Repeat notifications allow administrators to be notified repeatedly until an incident is either acknowledged or the number of Maximum Repeat Notifications has been reached.
CC12c supports repeat notification for all different notification methods (e-mail, OS command, PL/SQL procedure, and SNMP trap).
To enable this feature for a notification method, select the Send Repeat Notifications option.
In addition to setting the maximum number of repeat notifications, you can also set the time interval at which the notifications are sent.

Very important: Repeat notifications for rules will only be sent if the Send Repeat Notifications option is enabled in the Global Notification Methods page.

Here an example how to configure the Global Notification Methods in the Notification Methods page:

Configuring Repeat Notifications in Incident Rules:

Setting repeat notifications globally at the notification method level may not be provide sufficient flexibility. For example, you may want to have different repeat notification settings based on event type. Enterprise Manager accomplishes this by allowing you to set repeat notifications for individual incident rule sets or individual rules within a rule set. Repeat notifications set at the rule level take precedence over those defined at the notification method level.

Here an example how to configure a Repeat Notifications in an individual incident Rule:

Edit one of your individual Incident Rule (within one of your Rule).

Choose Next in your individual Incident Rule.

On next page, “Add” or “Edit” an Action.

In the Action pages, configure your Repeat Notification.

You can choice to select the Global Notification Methods or to create your own method for this rule. Click Continue.

In the Review page, control your settings. Click Continue.

Click “Save” to enable your settings. !!! Do not forget to save !!!

Now you can simulate an incident or event to test that your Repeat settings are working correctly.

Visit our partner’s Oracle Website for more informations about Repeat Notification.

Ref: Oracle® Enterprise Manager Cloud Control Administrator’s Guide:
– Chapter 3. Notifications –> http://docs.oracle.com/cd/E25054_01/doc.1111/e24473/notification.htm
– Chapter 4. Using Notifications –> https://docs.oracle.com/cd/E24628_01/doc.121/e24473/notification.htm#EMADM9066
4.1.5 Setting Up Repeat Notifications –> https://docs.oracle.com/cd/E24628_01/doc.121/e24473/notification.htm#EMADM9072

That’s it.

L’article Oracle EM Cloud Control 12c (CC12c)- Repeat alert notification est apparu en premier sur dbi Blog.

The configuration Best Practice for Oracle Database discovered the statistics_level parameter was set to the value ALL.

By selecting the Violation in the Configuration Best Practice for Oracle Database, we can display the message:

By the way Oracle recommends setting this value to TYPICAL in place of ALL, because of possible additional overhead on the system. If we look at the different statistics collected in TYPICAL or ALL modes, we can see that the difference concerns Plan Execution Statistics and Timed OS Statistics:

SQL> SELECT statistics_name,session_status,system_status,
activation_level,session_settable
FROM   v$statistics_level
ORDER BY statistics_name;

Typical:
STATISTICS_NAME                                        SESSION_ SYSTEM_S ACTIVAT SES
Active Session History                                    ENABLED ENABLED TYPICAL NO
Adaptive Thresholds Enabled                               ENABLED ENABLED TYPICAL NO
Automated Maintenance Tasks                               ENABLED ENABLED TYPICAL NO
Bind Data Capture                                         ENABLED ENABLED TYPICAL NO
Buffer Cache Advice                                       ENABLED ENABLED TYPICAL NO
Global Cache Statistics                                   ENABLED ENABLED TYPICAL NO
Longops Statistics                                        ENABLED ENABLED TYPICAL NO
MTTR Advice                                               ENABLED ENABLED TYPICAL NO
Modification Monitoring                                   ENABLED ENABLED TYPICAL NO
PGA Advice                                                ENABLED ENABLED TYPICAL NO
Plan Execution Sampling                                   ENABLED ENABLED TYPICAL YES
Plan Execution Statistics                                 DISABLED DISABLED ALL   YES
SQL Monitoring                                            ENABLED ENABLED TYPICAL YES
Segment Level Statistics                                  ENABLED ENABLED TYPICAL NO
Shared Pool Advice                                        ENABLED ENABLED TYPICAL NO
Streams Pool Advice                                       ENABLED ENABLED TYPICAL NO
Threshold-based Alerts                                    ENABLED ENABLED TYPICAL NO
Time Model Events                                         ENABLED ENABLED TYPICAL YES
Timed OS Statistics                                       DISABLED DISABLED ALL   YES
Timed Statistics                                          ENABLED ENABLED TYPICAL YES
Ultrafast Latch Statistics                                ENABLED ENABLED TYPICAL NO
Undo Advisor, Alerts and Fast Ramp up                     ENABLED ENABLED TYPICAL NO
V$IOSTAT_* statistics                                     ENABLED ENABLED TYPICAL NO

ALL:

STATISTICS_NAME                                        SESSION_ SYSTEM_S ACTIVAT SES
Active Session History                                    ENABLED ENABLED TYPICAL NO
Adaptive Thresholds Enabled                               ENABLED ENABLED TYPICAL NO
Automated Maintenance Tasks                               ENABLED ENABLED TYPICAL NO
Bind Data Capture                                         ENABLED ENABLED TYPICAL NO
Buffer Cache Advice                                       ENABLED ENABLED TYPICAL NO
Global Cache Statistics                                   ENABLED ENABLED TYPICAL NO
Longops Statistics                                        ENABLED ENABLED TYPICAL NO
MTTR Advice                                               ENABLED ENABLED TYPICAL NO
Modification Monitoring                                   ENABLED ENABLED TYPICAL NO
PGA Advice                                                ENABLED ENABLED TYPICAL NO
Plan Execution Sampling                                   ENABLED ENABLED TYPICAL YES
Plan Execution Statistics                                 ENABLED ENABLED ALL     YES
SQL Monitoring                                            ENABLED ENABLED TYPICAL YES
Segment Level Statistics                                  ENABLED ENABLED TYPICAL NO
Shared Pool Advice                                        ENABLED ENABLED TYPICAL NO
Streams Pool Advice                                       ENABLED ENABLED TYPICAL NO
Threshold-based Alerts                                    ENABLED ENABLED TYPICAL NO
Time Model Events                                         ENABLED ENABLED TYPICAL YES
Timed OS Statistics                                       ENABLED ENABLED ALL     YES
Timed Statistics                                          ENABLED ENABLED TYPICAL YES
Ultrafast Latch Statistics                                ENABLED ENABLED TYPICAL NO
Undo Advisor, Alerts and Fast Ramp up                     ENABLED ENABLED TYPICAL NO
V$IOSTAT_* statistics                                     ENABLED ENABLED TYPICAL NO

Another side effect is documented in the 874518.1 Oracle Metalink note. The statistics_level parameter initiated to ALL records a lot of additional information in the AWR repository, the table wrh$_latch_chidren might grow to a huge size.

For example in a database with statistics_level set to ALL:

SQL> SELECT sum(bytes)from dba_segments
where SEGMENT_NAME ='WRH$_LATCH_CHILDREN';

SUM(BYTES)
1985085440

And with statistics_level set to for TYPICAL:

SQL> SELECT sum(bytes)from dba_segments
where SEGMENT_NAME ='WRH$_LATCH_CHILDREN';

SUM(BYTES)  
262144

Another proof consists at looking the object occupying most of the place in the SYSAUX tablespace:

With statistics_level set to TYPICAL:

SQL> select * from
2   (select owner,segment_name,bytes/(1024*1024) size
3   from dba_segments
4   where tablespace_name = 'SYSAUX'
5   ORDER BY BLOCKS desc);

OWNER              SEGMENT_NAME                         SIZE

SYS              WRH$_ACTIVE_SESSION_HISTORY            1242

SYS              WRM$_SNAPSHOT_DETAILS_INDEX             629

SYS              WRH$_EVENT_HISTOGRAM_PK                 596

….

With statistics_level set to ALL:

OWNER             SEGMENT_NAME                          SIZE

SYS              WRH$_LATCH_CHILDREN                    1893

SYS              WRH$_LATCH_CHILDREN_PK                 1368

SYS              SYS_LOB0000006298C00004$$               580

…

We can obviously see that the two segments WRH$_LATCH_CHILDREN and WRH$_LATCH_CHILDREN_PK are the biggest objects in the SYSAUX tablespace where statistics_level is set to ALL.

Conclusion:

I would recommend to always let the default value for statistics_level (i.e TYPICAL), but if you need to set statistics_level to ALL in order to diagnose SQL plan performance issues, you can do it at session level:

SQL> alter session set statistics_level='ALL';
Session altered.

L’article statistics_level parameter est apparu en premier sur dbi Blog.

.
A question that I had several times: in Enterprise Manager, in the screen about one SQL statement, the ‘statistics’ tab shows the number of executions, elapsed time, etc. Question is: which time window does it cover? There is a one hour chart above, and two timestamps displayed as ‘First Load Time’ and ‘Last load Time’, and we don’t know which one is related with the execution statistics numbers. I’ll explain it clearly on an example.

I’ll check a query I have on my system which has several cursors, with two different execution plans. And I check from V$SQL because here is where is the most detailed information, and columns are well documented.

From the documentation:

• FIRST_LOAD_TIME is the Timestamp of the parent creation time
• LAST_LOAD_TIME is the Time at which the query plan was loaded into the library cache

It’s clear that because V$SQL show information about child cursors, the FIRST_LOAD_TIME will be the same for all children.

SQL> select sql_id,plan_hash_value,executions,first_load_time,last_load_time,last_active_time from v$sql where sql_id='dcstr36r0vz0d' order by child_number

SQL_ID        PLAN_HASH_VALUE EXECUTIONS FIRST_LOAD_TIME     LAST_LOAD_TIME      LAST_ACTIVE_TIME
------------- --------------- ---------- ------------------- ------------------- -------------------
dcstr36r0vz0d        17720163         60 2014-10-29/07:01:59 2014-10-29/07:01:59 2014-10-29/13:01:25
dcstr36r0vz0d      3798950322        102 2014-10-29/07:01:59 2014-10-29/07:03:49 2014-10-29/13:05:54
dcstr36r0vz0d      3798950322         24 2014-10-29/07:01:59 2014-10-29/07:05:55 2014-10-29/13:05:54
dcstr36r0vz0d      3798950322          1 2014-10-29/07:01:59 2014-10-29/08:11:19 2014-10-29/08:11:19
dcstr36r0vz0d      3798950322          1 2014-10-29/07:01:59 2014-10-29/08:29:34 2014-10-29/08:29:34

The plan with hash value 17720163 has been executed 60 times since 07:01:59. It was the first child cursor (child_number=0) for that parent, so this is why FIRST_LOAD_TIME=LAST_LOAD_TIME

And, the plan with hash value 3798950322 has been executed 128 times since 07:03:49 by cursors that are not shared but have come to the same plan anyway

Two remarks:

• FIRST_LOAD_TIME is the same for all children because it is a parent information
• LAST_LOAD_TIME is different for each child and that’s important because Enterprise Manager don’t show that detail, aggregating together the children with same execution plan.

L’article Oracle cloud control / SQL Details / Statistics est apparu en premier sur dbi Blog.

From the agent menu, you select the new feature Agent Decommission:

The agent must be in stopped status to be decommissioned:

It shows the targets which will be removed.

In a very short time, the targets are delete, and the agent is removed.

The agent decommissioning feature is just a little new feature, but this will greatly simplify the agent emoval procedure :=)

L’article Oracle Cloud Control 12c: removing an agent is much easier in OEM 12.1.0.4 est apparu en premier sur dbi Blog.

First, we should explicitly stop the OMS jvmd and adp engines:

oracle@vmtestoraem12c:/home/oracle/ [oms12c] emctl extended oms jvmd stop -allOracle Enterprise Manager Cloud Control 12c Release 3Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved.Please enter the SYSMAN password:Stopping all Engines{}
No engines found for this operation
oracle@vmtestoraem12c:/home/oracle/ [oms12c] emctl extended oms adp stop -a
Oracle Enterprise Manager Cloud Control 12c Release 3
Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved.
No valid registry entry found for verb jv

Then we stop the OMS:

oracle@vmtestoraem12c:/home/oracle/ [oms12c] emctl stop oms -all
Oracle Enterprise Manager Cloud Control 12c Release 3
Copyright (c) 1996, 2013 Oracle Corporation.
All rights reserved.Stopping WebTier...
WebTier Successfully Stopped
Stopping Oracle Management Server...
Oracle Management Server Successfully Stopped
AdminServer Successfully Stopped
Oracle Management Server is Down

We stop the management agent:

oracle@vmtestoraem12c:/home/oracle/ [agent12c] emctl stop agent
Oracle Enterprise Manager Cloud Control 12c Release 3
Copyright (c) 1996, 2013 Oracle Corporation.
All rights reserved.
Stopping agent ..... stopped.

Finally after unzipping the 12.1.0.4 binary files, we can run the installer:

We choose not to receive security updates:

We choose to skip the updates:

All the prerequisites checks have succeeded :=)

We select a One System Upgrade and the Oracle_Home where the 12.1.0.3 version is installed:

We select the new Middleware Home:

We enter the administration passwords:

The installer reminds you that you have correctly patched the repository database. Let’s check if it is correct:

Interim patches (1) :
Patch 11061801 : applied on Mon Aug 04 16:52:51 CEST 2014
Unique Patch ID: 16493357
Created on 24 Jun 2013, 23:28:20 hrs PST8PDT
Bugs fixed: 11061801

We did not copy the emkey to the repository, so we have to run:

oracle@vmtestoraem12c:/u01/app/oracle/MiddleWare_12103/oms/bin/ [oms12c] emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=vmtestoraem12c.it.dbi-services.com)(PORT=1521)))(CONNECT_DATA=(SID=OMSREP)))"' -repos_user sysman -emkey_file /u01/app/oracle/MiddleWare_12103/oms/sysman/config/emkey.ora
Oracle Enterprise Manager Cloud Control 12c Release 3
Copyright (c) 1996, 2013 Oracle Corporation.
All rights reserved.
Enter Admin User's Password :
Enter Enterprise Manager Root (SYSMAN) Password :
The EMKey has been copied to the Management Repository.
This operation will cause the EMKey to become unsecure.

After the required operation has been completed, secure the EMKey by running “emctl config emkey -remove_from_repos”:

We select Yes to let the installer fix the isssue automatically:

We select Next:

We can select additionnal plugins:

We enter the weblogic password:

We select install:

And finally we run the allroot.sh script connected as root:

The upgrade is successfull! Let’s check the OMs status:

oracle@vmtestoraem12c:/u01/app/oracle/MiddleWare_12cR4/oms/ [oms12c] emctl status oms -details
Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2014 Oracle Corporation.
All rights reserved.
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host : vmtestoraem12c.it.dbi-services.com
HTTP Console Port : 7789
HTTPS Console Port : 7801
HTTP Upload Port : 4890
HTTPS Upload Port : 4901
EM Instance Home : /u01/app/oracle/gc_inst/em/EMGC_OMS1
OMS Log Directory Location : /u01/app/oracle/gc_inst/em/EMGC_OMS1/sysman/log
OMS is not configured with SLB or virtual hostname
Agent Upload is locked.
OMS Console is locked.
Active CA ID: 1
Console URL: https://vmtestoraem12c.it.dbi-services.com:7801/em
Upload URL: https://vmtestoraem12c.it.dbi-services.com:4901/empbs/upload
WLS Domain InformationDomain Name : GCDomain
Admin Server Host : vmtestoraem12c.it.dbi-services.com
Admin Server HTTPS Port: 7102
Admin Server is RUNNING
Oracle Management Server Information
Managed Server Instance Name: EMGC_OMS1
Oracle Management Server Instance Host: vmtestoraem12c.it.dbi-services.com
WebTier is Up
Oracle Management Server is Up
BI Publisher is not configured to run on this host.

Now we have access to the Enterprise Manager Cloud Control 12.1.0.4:

The next step consists in upgrading the management agents. From the Setup menu, we select Upgrade Agents:

The management agent is detected:

The operation is successfull:

The update to 12.1.0.4 Enterprise Manager version did not cause any problem and has a new feature which checks the correct patching of the Enterprise Manager repository database.

L’article Oracle OEM Cloud Control 12c upgrade to 12.1.0.4 est apparu en premier sur dbi Blog.