Friday, May 30, 2014

How to discover new PDB targets in EM12c

I just created a new Pluggable database in my container, PDB2. I want to discover it in EM12c Rel 3.

Go to Setup -> Add Target -> Add Targets Manually





Choose "Add Targets Using Guided Process", for Targets type choose Oracle Database, Listener and ASM




Specify host, then click next





Input the pass and then Next


Review the findings and click save


The confirmation window appears


Going to Targets -> Databases, you can find the pluggable database in the list.





Thursday, May 8, 2014

EM12c: Job Step Scheduler is shown as down – EM jobs remain in scheduling indefinitely

Problem:
EM12c: Job Step Scheduler is shown as down – EM jobs remain in scheduling indefinitely and don't run

Change made:
Upgrade to Rel 3 12.1.0.3 and apply DB Plugin 12.1.0.5


The repository job called “Job Step Scheduler” is shown as down on Management Services and Repository Page.

Go to Setup > Manage Cloud Control > Repository

In Repository Scheduler Jobs Status section, the "Job Step Scheduler" job is shown as down with a red arrow.

All the other jobs look good and are running successfully.


So, found this metalink note, and applied the same logic
EM 12c : After Upgrade to R2 12.1.0.2 Repository Job Purge Is Shown As Down on Management Services And Repository Page (Doc ID 1496431.1)

SQL>  select dbms_jobname from mgmt_performance_names where display_name = 'Job Step Scheduler';
 EM_JOB_OBSERVER.run_cycle

SQL>  select job from all_jobs where what='EM_JOB_OBSERVER.run_cycle'
 no rows selected

 SQL>  select count(*) from all_jobs
 0

SQL> select owner, job_name, job_action, enabled, state, failure_count, last_start_date, last_run_duration
from dba_scheduler_jobs where job_name LIKE 'EM_JOB%'

SYSMAN              EM_JOB_PURGE_POLICIES         EM_JOB_PURGE.APPLY_PURGE_POLICIES();      TRUE     SCHEDULED        0                08-MAY-14 05.07.11.883712000 AM -05:00            0 0:0:17.949089
SYSMAN              EM_JOBS_STEP_SCHED                EM_JOB_OBSERVER.run_cycle  FALSE    DISABLED            0              24-JAN-14 06.29.08.570318000 PM EST5EDT               0 0:0:0.013817

I can see the job is disabled.
I will enable it

SQL>  BEGIN
      sys.dbms_scheduler.enable(name=>'"SYSMAN"."EM_JOBS_STEP_SCHED"');
END;

SQL>  select owner, job_name, job_action, enabled, state, failure_count, last_start_date, last_run_duration
from dba_scheduler_jobs where job_name LIKE 'EM_JOB%'

SYSMAN              EM_JOBS_STEP_SCHED                EM_JOB_OBSERVER.run_cycle  TRUE     SCHEDULED        0              24-JAN-14 06.29.08.570318000 PM EST5EDT               0 0:0:0.013817
SYSMAN              EM_JOB_PURGE_POLICIES         EM_JOB_PURGE.APPLY_PURGE_POLICIES();      TRUE     SCHEDULED        0                08-MAY-14 05.07.11.883712000 AM -05:00            0 0:0:17.949089

The job is now scheduled.

Will also update mgmt._performance_names

SQL>  UPDATE MGMT_PERFORMANCE_NAMES
 SET display_name = NULL,dbms_jobname = NULL, is_dbmsjob = 'N', is_deleted = 'Y'
 WHERE UPPER(DBMS_JOBNAME) LIKE 'EM_JOB_OBSERVER.RUN_CYCLE';
1 row updated
SQL>  COMMIT;


Now checking the status of the job shows to be up.



The jobs run successfully again.



References
EM 12c : After Upgrade to R2 12.1.0.2 Repository Job Purge Is Shown As Down on Management Services And Repository Page (Doc ID 1496431.1)

EM 12c: The EM Jobs Service Target is Shown with Down Status in the Enterprise Manager 12.1.0.2 Cloud Control Console (Doc ID 1589084.1)



Monday, May 5, 2014

Compliance policies - DBLM

Recently had to retrieve the list of all Compliance Standard Rules in EM12c Rel 3.
I had to build a script to do this as Compliance Standard Rules cannot be exported within the Cloud Control interface (or at least was not able to do it after selecting all rules).

The script I come up with is the following:

SELECT rule_dname,description,rationale,
       target_type,
       decode(SEVERITY,20,'Warning',25,'Critical',18,'Minor Warning') as Severity
FROM EM_RULE
WHERE target_type in ('oracle_database','oracle_listener','rac_database','oracle_pdb','oracle_dbmachine')
order by target_type, rule_dname;

A sample of the output (unformatted) looks like the below:

RULE_NAME
"Domain Users" Group Member of local "Users" Group
$ORACLE_HOME/network/admin Directory Owner
$ORACLE_HOME/network/admin File Permission
$ORACLE_HOME/network/admin File Permission(Windows)
Access to *_CATALOG_* Roles
Access to ALL_SOURCE View

DESCRIPTION
Ensures domain server local Users group does not have Domain Users group
Ensures $ORACLE_HOME/network/admin ownership is restricted to the Oracle software set and DBA group
Ensures the files in $ORACLE_HOME/network/admin ownership is restricted to the Oracle software set, group is restricted to DBA group and  Public does not have write permission
Ensures the files in $ORACLE_HOME/network/admin ownership is restricted to the Oracle software set, group is restricted to DBA group and  Public does not have write permission
Ensure grant of *_CATALOG_* is restricted
Ensures restricted access to ALL_SOURCE view

RATIONALE
Including Domain Users group in local Users group of a domain server can cause serious security issues.
Not restricting ownership of network/admin to the Oracle software set and DBA group may cause security issues by exposing net configuration data to malicious users
Not restricting ownership of network/admin to the Oracle software set and DBA group may cause security issues by exposing net configuration data to malicious users
Not restricting ownership of network/admin to the Oracle software set and DBA group may cause security issues by exposing net configuration data to malicious users
TARGET_TYPE SEVERITY
oracle_database Warning
oracle_database Warning
oracle_database Warning
oracle_database Warning
oracle_database Critical