Connect Oracle to Mini DBA

Start Here

Manual Home Installation Windows Installation Linux Engine Container Linux Console Container Getting Started Licensing Servers Connect Database Servers Troubleshoot Connectivity Host OS Login Enable WMI Multi-Engine Mode Multi-Engine Settings

Console

Console Overview Enterprise View AI Assistant Execution Plans Alerts Custom Alerts Reports Performance History Settings Service Log Connectivity Log Web Log About

PostgreSQL

Overview Connection and Permissions Activity Databases Queries Waits Memory I/O Indexes Deadlocks Server Log Settings Permissions Health Checks Alerts Performance Tuning

MySQL/MariaDB

Overview Connection and Permissions Activity Databases Queries Memory I/O InnoDB Permissions Deadlocks Health Checks Alerts Performance Tuning

Oracle

Overview Connection and Permissions Activity Databases Queries Waits Memory Health Checks Alerts Performance Tuning

Settings And Integrations

Security SQL Options Email Server Alert Recipients Recipient Groups Server Groups Cloud Providers Web Proxy Slack Microsoft Teams PagerDuty Jira Performance Logging AI Provider MCP Server

Use the Oracle connection workflow to add an Oracle server to Mini DBA monitoring. Oracle monitoring uses database privileges for V$ views, GV$ views, DBA dictionary views, and multitenant container information, plus optional host OS login for CPU and drive metrics.

Add server fields

In Servers, select Add Server and choose Oracle.

Field	What to enter
Type	Oracle
Instance / Host	Oracle host name
Username	Oracle monitoring user
Password	Password for the monitoring user
Service Name	Oracle service name, such as `ORCL`. For self-managed multitenant Oracle, use the CDB/root service when Mini DBA should discover PDBs from one connection.
Port	Oracle listener port, normally `1521`

The Mini DBA Engine must be able to reach the Oracle listener and service name.

Mini DBA builds an Oracle service-name connection descriptor from the host, port, and service name fields. For self-managed Oracle 12c+ multitenant systems, connect to the CDB service with a common monitoring user so Mini DBA can discover and monitor visible PDBs. For managed platforms where the CDB is not accessible, such as many Amazon RDS Oracle deployments, add each PDB service separately.

Recommended login scope for Oracle 12c+ multitenant

For self-managed Oracle 12c+ multitenant databases, the recommended Mini DBA monitoring login is a common CDB user, normally named with Oracle's C## prefix, connected to the CDB/root service. This gives Mini DBA one connection that can see instance-level operational evidence and the visible PDB estate.

This is usually better than a PDB-local login because several Mini DBA Oracle pages use CDB/root-level or instance-level views. Examples include RMAN backup history, backup sets, redo log switch history, Flash Recovery Area information, container/PDB discovery, and cross-container dictionary metadata. A PDB-local user can be useful when you intentionally want to monitor only one PDB, or when a managed platform does not allow CDB/root access, but it may leave some Operations, backup, and container data empty.

For example, on Oracle XE/Free-style demo systems:

Monitoring goal	Service	User style
Full instance/CDB monitoring	`xe`, `free`, or the root/CDB service	Common user such as `C##MINIDBA_MONITOR`
One PDB only	`xepdb1`, `freepdb1`, or another PDB service	Local user such as `MINIDBA_MONITOR`

What Mini DBA monitors after connection

With the required Oracle privileges, Mini DBA can monitor:

Oracle activity, sessions, waits, and query workload.
V$ and GV$ performance views for instance and global diagnostics.
DBA dictionary views for database inventory and configuration.
CDB and PDB information in multitenant environments when a common user has container access.
Oracle memory, health checks, alerts, and performance tuning evidence.
Host CPU and drive metrics when Host OS Login or cloud host access is configured.

Required Oracle permissions

The Oracle permissions modal checks:

CREATE SESSION: essential, allows the monitoring user to connect.
SELECT ANY DICTIONARY: essential, grants access to V$ performance views, GV$ global views, DBA_ dictionary views, and CDB_ views for multitenant systems.
Common User (C##): recommended for Oracle 12c+ multitenant environments when monitoring containers.
Container Access: recommended for Oracle 12c+ multitenant environments.
DBA Role: not essential and powerful; useful for testing only.
Feature-specific capability checks: query intelligence, plans, activity/waits, lock detail, containers/objects, Data Guard, alert log, backup/jobs, Resource Manager, and ASM views.
OS Login or Cloud Host: optional, enables host-level metrics where available.

Query intelligence, plan history, and operations permissions

The newer Oracle Query Analysis and Plan History features need access to base dynamic performance views such as GV$SQLSTATS, GV$SQL, and GV$SQL_PLAN, plus the ability to call DBMS_XPLAN.DISPLAY_CURSOR where allowed. Mini DBA can fall back to structured GV$SQL_PLAN rows when DBMS_XPLAN output is unavailable.

Operations, backup, and storage views need access to the relevant recovery, Scheduler, archive, redo, tablespace, and multitenant dictionary views. This is why a CDB/root common monitoring user is the recommended setup for self-managed Oracle multitenant systems.

By default, Mini DBA's Oracle monitoring avoids Oracle Diagnostics Pack and Tuning Pack views such as AWR, ASH, ADDM, and SQL Tuning Advisor APIs. If your organization enables those workflows separately, confirm your Oracle licensing position before using them.

SQL example: Oracle 12c+ multitenant common user

Run this as an Oracle administrator. Change the password first.

ALTER SESSION SET CONTAINER = CDB$ROOT;

CREATE USER C##MINIDBA_MONITOR IDENTIFIED BY "UseASecretPasswordHere" CONTAINER = ALL;

ALTER USER C##MINIDBA_MONITOR SET CONTAINER_DATA=ALL CONTAINER=CURRENT;

GRANT CREATE SESSION TO C##MINIDBA_MONITOR CONTAINER = ALL;
GRANT SELECT ANY DICTIONARY TO C##MINIDBA_MONITOR CONTAINER = ALL;

Use a common user when Mini DBA needs container and pluggable database visibility from a single connection.

For the broadest Mini DBA monitoring coverage, connect this common user to the CDB/root service rather than to an individual PDB service. PDB-local users can connect and monitor a single PDB, but CDB/root users can also expose instance-level operational data such as RMAN backup history, redo log switch history, and recovery-area information.

SQL example: non-CDB or single database user

For non-multitenant Oracle or a single database scope, use a local user:

CREATE USER MINIDBA_MONITOR IDENTIFIED BY "UseASecretPasswordHere";

GRANT CREATE SESSION TO MINIDBA_MONITOR;
GRANT SELECT ANY DICTIONARY TO MINIDBA_MONITOR;

For short-lived testing only, the modal notes that the DBA role can provide broader access:

GRANT DBA TO MINIDBA_MONITOR;

Do not use the DBA role for routine production monitoring unless your security policy explicitly permits it.

Verify permissions in Mini DBA

After adding Oracle, open the Oracle server and use the Oracle Connectivity Permissions modal. Select Refresh to probe current privileges, common user status, container access, DBA role status, and host login status.

Use the modal when:

The Oracle server connects but monitoring pages are incomplete.
A multitenant database does not show expected PDB/container information.
Activity, waits, query, or health check data is missing.
Host CPU or drive metrics are missing.

Host OS login and metrics

Oracle host OS login is configured from the Oracle permissions modal after the server is added. On Linux, use SSH with password or private key authentication. On Windows, use an account with suitable local performance access.

Host OS login can add:

Host CPU percentage.
Drive capacity and free space.
Disk reads and writes per second where available.
Disk utilization and queue metrics where available.

For cloud-hosted Oracle platforms where direct OS access is unavailable, configure cloud provider credentials in Cloud Provider Settings.

For detailed setup, see Host OS Login.

Oracle connection troubleshooting

If connection fails, confirm listener host, port, service name, username, and password.
If the login cannot connect, grant CREATE SESSION.
If performance views are empty, grant SELECT ANY DICTIONARY or the equivalent approved dictionary privileges.
If CDB/PDB data is incomplete, use a common user with container access in Oracle 12c+ multitenant environments.
If host metrics are missing, configure OS Login or cloud host credentials.
Right-click the Oracle server in the tree and open Connectivity Log for listener, service name, authentication, timeout, dictionary privilege, and data-access errors captured by the engine.

Oracle monitoring permissions FAQ

Is the DBA role required?

No. The DBA role is powerful and should usually be avoided for routine monitoring. The core recommended privileges are CREATE SESSION and SELECT ANY DICTIONARY, adjusted for your security policy.

Should I use a common user?

Use a common C## user for Oracle 12c+ multitenant environments when Mini DBA should monitor containers and pluggable databases from one connection.

For self-managed Oracle, this is the recommended default. Use a PDB-local user only when you deliberately want Mini DBA scoped to one PDB or the platform does not expose the CDB/root service.

Does Mini DBA require Oracle diagnostics pack?

The basic connection and permission examples do not grant or imply license rights for Oracle optional packs. If your environment uses AWR, ASH, or Diagnostics Pack related views, confirm your Oracle licensing position separately.