Use Cases of Oracle Grid Control 

Oracle Grid Control was designed for centralized management of on‑premise Oracle IT infrastructure, especially when organizations had many databases, middleware servers, and hosts.

1. Centralized Monitoring of Large On‑Prem Environments

Grid Control provides a single-window solution for monitoring multiple Oracle databases, WebLogic servers, hosts, and even some non-Oracle technologies (IBM WebSphere, SQL Server, etc.) in one place.

2. End-to-End Application & Service Monitoring

It includes service-level management, real user monitoring, and deep diagnostics for multi-tier applications—ideal for environments needing SLA visibility.

3. Database Performance Diagnostics (11g Features)

For Oracle Database 11g Release 2, Grid Control provides:

• Enhanced performance pages
• ADDM integration
• Real-time SQL monitoring
• Parallel SQL tuning
  
  

4. Real Application Clusters (RAC) & High Availability Management

Use cases include:

• Managing policy-managed RAC databases
• Auto-discovery of RAC nodes
• Monitoring Oracle Clusterware and Grid Infrastructure
  
  

5. Configuration, Provisioning, and Lifecycle Management

Grid Control supports configuration management, provisioning, and patching in on‑prem environments.

6. Modeling IT Environment & Service-Level Management

Advanced use cases include:

• Modeling composite services
• Service-level agreements (SLAs)
• Root-cause analysis for service failures
  
  

Ideal For:

✔ Large on‑prem Oracle estates
✔ Mixed orchestration environments (DB + WebLogic + Hosts)
✔ Traditional data centers without cloud
✔ RAC-heavy deployments
✔ Organizations needing SLA and service monitoring

---

✅ Use Cases of Oracle Cloud Control (OEM 12c/13c)

Oracle Cloud Control expands on Grid Control by adding cloud, engineered systems, automation, and lifecycle capabilities.

1. Managing Entire Enterprise + Cloud Infrastructure

Cloud Control is Oracle’s integrated platform for monitoring databases, engineered systems, applications, middleware, hardware, and cloud environments centrally.

2. Hybrid & Cloud Management

It provides capabilities for:

• Oracle Cloud (OCI) monitoring
• Hybrid deployments (on‑prem + cloud)
• Cloud automation, configuration, and provisioning
  
  

3. Full Lifecycle Management & Automation

Cloud Control offers automated:

• Configuration management
• Provisioning
• Patch automation
• Compliance assessment
  
  

4. Engineered Systems (Exadata, ZDLRA) Management

Cloud Control supports Oracle engineered systems for:

• Hardware health monitoring
• Exadata cell and storage metrics
• Database machine-level performance
  (Engineered systems management is explicitly part of Cloud Control’s scope.)
  
  

5. Deep Diagnostics & Tuning via Licensed Packs

Cloud Control integrates advanced features when packs are enabled:

• Diagnostics Pack (AWR/ASH integration)
• Tuning Pack
• Lifecycle Management Pack
  
  

6. Compliance & Security Monitoring

Cloud Control supports compliance frameworks and access control management for enterprise governance—e.g., SOX, security baselines.

7. Managing Large Fleets at Scale

Includes support for:

• Fleet Maintenance
• Mass agent deployment
• Drift analysis
• Enterprise-wide policy enforcement

Ideal For:

✔ Multi-datacenter enterprises
✔ Cloud + on‑prem hybrid environments
✔ Exadata and engineered systems
✔ Large fleet automation & compliance
✔ Organizations needing advanced diagnostics and tuning

---

🆚 Summary: When to Use What

Requirement	Grid Control	Cloud Control
Large on‑prem infrastructure	✔	✔
Hybrid / Cloud environments	❌	✔
Engineered systems (Exadata)	Limited	✔ Full support
Advanced automation & provisioning	Moderate	✔ Extensive
SLA, service modeling	✔	✔ Enhanced
Diagnostics, Tuning Packs	Available	✔ Fully integrated
Modern UI, plugin architecture	Legacy	✔ Modern extensible

---

🎯 Short Answer

• Grid Control → Best for older, fully on‑premises Oracle environments needing centralized monitoring and basic lifecycle management.
• Cloud Control → Best for modern enterprises requiring cloud integration, engineered systems support, automation at scale, and advanced diagnostics/compliance.

 

🚀 Database Control vs Grid Control vs Cloud Control (OEM)

1. Database Control (DB Control)

Scope: Single database / single host

What it is:

• A lightweight management console installed automatically with an Oracle database.
• Uses the local DB Control Agent and stores configuration in the database’s own repository.

Best for:
✔ Managing one database
✔ Basic monitoring
✔ Single-server environments

Limitations:
❌ Cannot manage multiple databases centrally
❌ No enterprise monitoring
❌ Feature deprecated since Oracle 12c
❌ Not suitable for HA/DR, Exadata, RAC monitoring at scale

Think of it as:

A local-only admin console for one Oracle DB instance.

---

2. Grid Control (OEM 10g / 11g)

Scope: Enterprise-level monitoring across multiple servers

What it is:

• First enterprise-grade OEM version that gave you central management.
• Came with:
  • OMS (Oracle Management Server)
  • OMR (Oracle Management Repository)
  • Agent on each monitored host

Best for:
✔ Monitoring multiple DBs
✔ Managing RAC, ASM
✔ Host & application monitoring
✔ Patch management (PSUs)
✔ SLA dashboards

Limitations:
❌ Older architecture
❌ Not cloud-ready
❌ No plugin-based extensibility (limited compared to Cloud Control)

Think of it as:

Enterprise monitoring 1.0 — centralized, but still traditional.

---

3. Cloud Control (OEM 12c → 13c)

Scope: Enterprise + Cloud + Engineered systems

What it is:

• Successor to Grid Control.
• Plugin-based architecture to support:
  • Oracle DB (all versions)
  • Middleware (WebLogic)
  • Engineered systems (Exadata, ZDLRA)
  • Oracle Cloud, OCI
  • Non-Oracle technologies (SQL Server, VMware, etc.)

Key capabilities added:

• Lifecycle Management
• Patching & Provisioning Automation
• Fleet Maintenance
• Compliance Management (e.g., STIG, CIS)
• Cloud & hybrid monitoring
• Advanced diagnostics (AWR, ASH, ADDM integrated)

Best for:
✔ Large enterprises
✔ Multi-datacenter environments
✔ Exadata-heavy setups
✔ CI/CD for DB patching (Fleet Maintenance)
✔ Compliance & audit-driven organizations

Think of it as:

Enterprise monitoring 2.0 — scalable, cloud-aware, and automation‑focused.

---

📌 Quick Comparison Table

Feature	Database Control	Grid Control	Cloud Control
Scope	Single DB	Multi-DB Enterprise	Hybrid Cloud + Enterprise
Repository	Local DB	Central OMR	Central OMR (Enhanced)
Cloud support	❌	❌	✔ OCI, Hybrid
Engineered systems (Exadata)	❌	Limited	✔ Full support
Patch automation	Basic	Better	Best (Fleet Maintenance)
Plugins	❌	Limited	✔ Full plugin system
Status	Deprecated	Legacy	Current (OEM 13c)

---

🧠 In Simple Terms

• Database Control → Local tool for one database
• Grid Control → Central tool for many databases
• Cloud Control → Enterprise+Cloud management with automation & plugins

https://www.softwareone.com/en/blog/articles/2021/05/31/oracle-enterprise-manager-how-to-avoid-unexpected-licensing-challenges

https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html#GUID-B6113390-9586-46D7-9008-DCC9EDA45AB4

How to Monitor When Oracle Management Packs Are Activated or Used in Oracle database ?

 

How to Monitor When Oracle Management Packs Are Activated or Used

Oracle provides multiple internal views, advisor logs, and AWR/ADDM activity indicators that reveal accidental or unauthorized use of:

• Diagnostics Pack
• Tuning Pack

Below is a complete monitoring framework.

---

✅ 1. Check if Diagnostic/Tuning Features Were Used (Primary Indicator)

Oracle logs all usage in DBA_FEATURE_USAGE_STATISTICS.

Run:

SELECT name, detected_usages, total_samples, last_usage_date

FROM dba_feature_usage_statistics

WHERE name IN (

'Automatic Workload Repository',

'ADDM',

'SQL Tuning Advisor',

'SQL Access Advisor',

'ASH',

'AWR Baseline',

'Real-Time SQL Monitoring'

)

ORDER BY last_usage_date DESC;

What to look for:

• DETECTED_USAGES > 0 → feature was used
• LAST_USAGE_DATE not null → pack was accessed
• If you disabled packs but this still updates → OEM or some script is still invoking features

This is the most authoritative licensing indicator.

---

✅ 2. Monitor the Management Pack Parameter (Active Status)

Run:

SHOW PARAMETER control_management_pack_access;

Expected safe value:

NONE

If it changes to:

• DIAGNOSTIC
• DIAGNOSTIC+TUNING

➡️ Packs are active and billable.

For automated monitoring, query:

SELECT value

FROM v$parameter

WHERE name='control_management_pack_access';

---

✅ 3. Check if AWR Snapshots Are Being Generated (Diagnostics Pack Usage)

If snapshots exist, AWR is active → Diagnostic Pack is considered used.

SELECT snap_id, begin_interval_time, end_interval_time

FROM dba_hist_snapshot

ORDER BY snap_id DESC

FETCH FIRST 10 ROWS ONLY;

If you see new snapshots after disabling:

➡️ Something is still collecting AWR data.

---

✅ 4. Monitor ADDM Execution (Diagnostics Pack)

SELECT task_name, created, status

FROM dba_advisor_tasks

WHERE advisor_name='ADDM';

If any task appears → Diagnostics Pack used.

---

✅ 5. Monitor SQL Tuning Advisor Activity (Tuning Pack)

SELECT task_name, created, status

FROM dba_advisor_tasks

WHERE advisor_name='SQL TUNING ADVISOR';

If tasks ran → Tuning Pack usage triggered.

Also check:

SELECT COUNT(*) FROM DBA_ADVISOR_LOG WHERE advisor_name='SQL TUNING ADVISOR';

---

✅ 6. Monitor SQL Access Advisor Activity (Tuning Pack)

SELECT task_name, created, execution_start

FROM dba_advisor_tasks

WHERE advisor_name='SQL ACCESS ADVISOR';

Any appearance = Tuning Pack usage.

---

✅ 7. Detect Automatic SQL Monitoring (Diagnostics + Tuning Pack)

SQL Monitoring is part of Tuning Pack.

Check ASH/SQL Monitor usage:

SELECT sql_id, status, sid, username, elapsed_time

FROM v$sql_monitor;

If rows appear → Tuning Pack active.

---

✅ 8. OEM Activity Monitoring (Common Source of Accidental Usage)

OEM may trigger pack usage even if DBAs don't run anything manually.

Check OEM repository:

For AWR/ASH report generation:

SELECT * FROM mgmt$awr_reports ORDER BY time_start DESC;

For SQL Tuning Advisor tasks created by OEM:

SELECT task_name, created

FROM dba_advisor_tasks

WHERE task_name LIKE 'SYS_AUTO_SQL%';

If OEM is generating:

• AWR Reports
• ADDM Reports
• SQL Tuning tasks

➡️ Packs are being used even if parameter says NONE.

---

✅ 9. Enable Audit Monitoring for Parameter Changes

Track if someone re-enabled packs:

AUDIT ALTER SYSTEM;

Then check:

SELECT username, timestamp, sql_text

FROM dba_audit_trail

WHERE sql_text LIKE '%control_management_pack_access%';

This is extremely valuable during SOX audits.

---

📈 10. Recommended Scheduled Monitoring Script

Run daily/weekly through OEM/cron.

SELECT 'FEATURE_USAGE', name, detected_usages, last_usage_date

FROM dba_feature_usage_statistics

WHERE detected_usages > 0

UNION ALL

SELECT 'AWR_SNAP', snap_id, begin_interval_time, end_interval_time

FROM dba_hist_snapshot

WHERE begin_interval_time > SYSDATE-1;

Generate alerts if ANY usage is detected.

---

🎯 Summary – What You Must Monitor

Check Area	What It Detects	Indicates Usage
DBA_FEATURE_USAGE_STATISTICS	Core features	Primary licensing indicator
DBA_HIST_SNAPSHOT	AWR snapshots	Diagnostics Pack
ADDM Tasks	Diagnostics Pack	Yes
SQL Tuning Advisor	Tuning Pack	Yes
SQL Access Advisor	Tuning Pack	Yes
SQL Monitoring	Tuning Pack	Yes
OEM Activity	Auto usage triggers	Very common
Audit of parameter change	Re-enabling packs	Compliance breach

---

Disable Diagnostics Pack & Tuning Pack in Oracle

 These packs are controlled by the Oracle parameter control_management_pack_access.

🎯 Step 1 — Check Current Status

SHOW PARAMETER control_management_pack_access;

You’ll see one of the following:

• DIAGNOSTIC+TUNING (both packs enabled)
• DIAGNOSTIC (Diagnostics only)
• NONE (all packs disabled → fully license‑safe)

---

🎯 Step 2 — Disable Both Packs

You must set the parameter to NONE at the instance level:

For RAC or Single Instance (spfile):

ALTER SYSTEM SET control_management_pack_access = NONE SCOPE=BOTH;

For pfile:

Edit the pfile and add:

control_management_pack_access = NONE

Restart the database.

---

🎯 Step 3 — Restart (Required for Some Versions)

Some Oracle versions apply the change immediately; others require a bounce.

To be safe:

SHUTDOWN IMMEDIATE;

STARTUP;

---

⚠️ Important Notes for Compliance

Disabling these packs automatically disables:

• AWR (Automatic Workload Repository)
• ADDM (Automatic Database Diagnostic Monitor)
• SQL Tuning Advisor
• SQL Access Advisor
• Database Monitoring pages in OEM that use diagnostic data

If you're using OEM, make sure:

• AWR snapshots are not scheduled
• OEM does not trigger diagnostics-related jobs

---

🎯 Optional — Disable AWR Snapshot Collection (prevents accidental usage)

EXEC dbms_workload_repository.modify_snapshot_settings(interval => 0);

---

✔️ Good Practice Checklist for SOX & Licensing

Since you’re running DB architecture at NXP and focusing heavily on audit readiness, here’s a quick compliance checklist:

Check	Status
control_management_pack_access = NONE	✅
AWR snapshots disabled	☐
OEM monitoring avoids diag/tuning features	☐
No use of SQL Tuning Advisor	☐
No manual AWR report generation	☐

1. Purpose

This SOP defines the detailed steps required to disable Oracle Diagnostics Pack and Tuning Pack across Oracle databases to ensure license compliance, prevent unintended usage, and support SOX / ITGC audit requirements.

---

2. Scope

This procedure applies to:

• All Oracle Enterprise Edition databases.
• All environments: Production, Non‑Prod, DR, QA, Dev.
• Both single-instance and Oracle RAC deployments.
• Systems integrated with Oracle Enterprise Manager (OEM).

---

3. Responsibilities

Role	Responsibility
Database Architect	Approve the requirement & design compliance controls
DBA Team	Execute the SOP across environments
OEM Administrator	Ensure OEM jobs do not trigger Diagnostic/Tuning features
Internal Audit / SOX Team	Periodic validation

---

4. Prerequisites

1. SYSDBA access to the database.
2. Approval from Application Owners (if restart is required).
3. Confirm no features dependent on AWR/ADDM are needed.
4. Recent database backup.

---

5. Background

Oracle Diagnostics & Tuning Packs are separately licensed. When enabled, Oracle automatically collects & stores performance data through:

• AWR (Automatic Workload Repository)
• ADDM (Automatic Database Diagnostic Monitor)
• SQL Tuning Advisor
• SQL Access Advisor
• OEM performance pages

To prevent unintentional usage, Oracle provides a parameter:

control_management_pack_access

Valid values:

• DIAGNOSTIC+TUNING
• DIAGNOSTIC
• NONE ← Fully disables both packs

---

6. Procedure

---

6.1 Step 1 — Verify Current License Pack Status

Execute as SYS:

SHOW PARAMETER control_management_pack_access;

Expected output will show the current value.

---

6.2 Step 2 — Disable Diagnostics & Tuning Packs

If using SPFILE (Recommended for most environments):

ALTER SYSTEM SET control_management_pack_access = NONE SCOPE=BOTH;

If using PFILE:

1. Edit the pfile:

control_management_pack_access = NONE

2. Recreate the spfile (if required):

CREATE SPFILE FROM PFILE;

---

6.3 Step 3 — Restart Database (Required in Some Versions)

Some Oracle versions apply immediately, but restart ensures full enforcement:

SHUTDOWN IMMEDIATE;

STARTUP;

---

6.4 Step 4 — Validate the Change

SHOW PARAMETER control_management_pack_access;

Expected:

NAME                                 VALUE
------------------------------------ -----
control_management_pack_access       NONE

---

6.5 Step 5 — Disable AWR Snapshots (Optional but Recommended)

This prevents accidental AWR collection:

EXEC dbms_workload_repository.modify_snapshot_settings(interval => 0);

To verify:

SELECT interval FROM dba_hist_wr_control;

---

6.6 Step 6 — Adjust OEM Monitoring

If OEM is configured, ensure:

• AWR-based reports are disabled
• ASH Analytics not accessed
• Performance pages using Diagnostic data are not used
• No SQL Tuning Advisor jobs scheduled

Deactivate OEM jobs:

-- Disable SQL Tuning Advisor tasks

EXEC dbms_sqltune.drop_tuning_task(task_name => '<task_name>');

-- Disable ADDM tasks

EXEC dbms_addm.delete_db_advisor_run(run_name => '<run_name>');

---

7. Post‑Implementation Checks

Check	Validation Query / Step
Parameter set to NONE	SHOW PARAMETER control_management_pack_access
AWR snapshots disabled	SELECT interval FROM dba_hist_wr_control
No ADDM reports generated	Check OEM & DBA_ADVISOR_LOG
No SQL Tuning Advisor usage	SELECT * FROM dba_advisor_log WHERE advisor_name='SQL TUNING ADVISOR';
OEM Performance pages do not show diagnostic data	Manual check

---

8. Rollback Procedure

If the packs need re-enabling:

ALTER SYSTEM SET control_management_pack_access = 'DIAGNOSTIC+TUNING' SCOPE=BOTH;

Restart database if required.

---

9. Compliance & Audit Evidence

DBA team must retain the following evidence:

• Screenshot or spool log of parameter:

  control_management_pack_access = NONE
  

• AWR snapshot interval set to 0.
• OEM tuning/diagnostic jobs disabled.
• Monthly validation logs.

---

10. Risks & Mitigations

Risk	Mitigation
Loss of AWR data	Use Statspack instead
OEM features unavailable	Monitor via OS tools or Statspack
Application performance troubleshooting impact	Build custom scripts or enable temporarily with approval