Oracle

This document describes the Oracle functionality of PandoraFMS Discovery.

Introduction

This plugin is designed to monitor Oracle databases by executing queries that extract key information related to the performance and status of the databases. This information includes metrics such as the number of connections, query counts, restart status, fragmentation ratio, and cache. These data points will be reflected in PandoraFMS through modules that provide statistical value, within an agent representing each database.

It's important to note that this plugin is specifically developed for use with Pandora FMS Discovery. Unlike other plugins, it doesn't generate agents through XML; instead, all the discovered information is returned in the JSON output of the plugin.

Prerrequisites

This plugin establishes remote connections to the databases it monitors, so it's essential to ensure connectivity between the Pandora FMS server and these databases. Proper network and firewall configurations must be in place to allow communication between the server and the remote databases to ensure the plugin's effective operation.

EN — Connection

The plugin connects via oracledb (Python driver) using the format:

HOST:PORT/SID

Or using a full DSN string:

dsn=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales1-srv)(PORT=1521))(CONNECT_DATA=(SID=ORCL)))

The connection user must have at least CREATE SESSION privilege:

GRANT CREATE SESSION TO pandora;

EN — Grants per Module

All modules are opt-in via checkboxes in the Discovery configuration. Only enable the grants needed for the modules you actually use.

1. Connections (checkConnections)

-- v$session (active session count)
GRANT SELECT ON V_$SESSION TO pandora;

-- v$parameter (max sessions)
GRANT SELECT ON V_$PARAMETER TO pandora;

2. Uptime (checkUptime)

-- v$session (PMON process start time)
GRANT SELECT ON V_$SESSION TO pandora;

3. Query Stats (queryStats)

-- v$sqlstats (SQL execution counters)
GRANT SELECT ON V_$SQLSTATS TO pandora;

4. Tablespaces (checkTablespaces)

-- dba_tablespace_usage_metrics (Oracle 10g+)
GRANT SELECT ON DBA_TABLESPACE_USAGE_METRICS TO pandora;

-- dba_tablespaces (status)
GRANT SELECT ON DBA_TABLESPACES TO pandora;

-- dba_data_files (size calculation, Oracle < 10g fallback)
GRANT SELECT ON DBA_DATA_FILES TO pandora;

-- dba_free_space (size calculation, Oracle < 10g fallback)
GRANT SELECT ON DBA_FREE_SPACE TO pandora;

5. Fragmentation Ratio (checkFragmentation)

-- dba_tables (table stats for fragmentation)
GRANT SELECT ON DBA_TABLES TO pandora;

6. Cache Stats (checkCache)

-- v$librarycache
GRANT SELECT ON V_$LIBRARYCACHE TO pandora;

-- v$rowcache
GRANT SELECT ON V_$ROWCACHE TO pandora;

-- v$sysstat
GRANT SELECT ON V_$SYSSTAT TO pandora;

7. Multitenant / PDB Monitoring (multitenant)

-- v$pdbs (PDB discovery)
GRANT SELECT ON V_$PDBS TO pandora;

Additionally, the monitoring user must have CREATE SESSION on each PDB to be monitored. Connect to each PDB and run:

ALTER SESSION SET CONTAINER = <PDB_NAME>;
GRANT CREATE SESSION TO pandora;
-- Granular PDB-level grants (e.g. v$session, dba_tablespaces, etc.)
-- must also be granted inside each PDB.

Note: When multitenant is enabled, the plugin connects directly to each PDB using HOST:PORT/PDB_NAME, so the user must exist and have the necessary grants in every PDB.

8. Custom Queries (executeCustomQueries)

Permissions depend entirely on the user-defined queries. Grant SELECT on any additional tables/views the custom queries reference.

EN — Quick Setup (All Modules)

For convenience, grant SELECT_CATALOG_ROLE which covers most V$ and DBA_ views:

-- In CDB (container database)
CREATE USER pandora IDENTIFIED BY <password>;
GRANT CREATE SESSION TO pandora;
GRANT SELECT_CATALOG_ROLE TO pandora;

-- In each PDB (if using multitenant)
ALTER SESSION SET CONTAINER = <PDB_NAME>;
-- If user already exists via CDB common user:
GRANT CREATE SESSION TO pandora;
GRANT SELECT_CATALOG_ROLE TO pandora;

Minimal Granular Alternative

If SELECT_CATALOG_ROLE is too broad, use this block:

CREATE USER pandora IDENTIFIED BY <password>;
GRANT CREATE SESSION TO pandora;

-- Dynamic performance views
GRANT SELECT ON V_$SESSION TO pandora;
GRANT SELECT ON V_$SQLSTATS TO pandora;
GRANT SELECT ON V_$PARAMETER TO pandora;
GRANT SELECT ON V_$LIBRARYCACHE TO pandora;
GRANT SELECT ON V_$ROWCACHE TO pandora;
GRANT SELECT ON V_$SYSSTAT TO pandora;
GRANT SELECT ON V_$PDBS TO pandora;

-- DBA views
GRANT SELECT ON DBA_TABLESPACES TO pandora;
GRANT SELECT ON DBA_TABLESPACE_USAGE_METRICS TO pandora;
GRANT SELECT ON DBA_DATA_FILES TO pandora;
GRANT SELECT ON DBA_FREE_SPACE TO pandora;
GRANT SELECT ON DBA_TABLES TO pandora;

-- Version info
GRANT SELECT ON PRODUCT_COMPONENT_VERSION TO pandora;

EN — Summary Table

Module Token Oracle View/Table
checkConnections V$SESSION, V$PARAMETER
checkUptime V$SESSION
queryStats V$SQLSTATS
checkTablespaces DBA_TABLESPACE_USAGE_METRICS, DBA_TABLESPACES, DBA_DATA_FILES, DBA_FREE_SPACE
checkFragmentation DBA_TABLES
checkCache V$LIBRARYCACHE, V$ROWCACHE, V$SYSSTAT
multitenant V$PDBS + CREATE SESSION on each PDB
executeCustomQueries Depends on user queries

* Only needed for Oracle <= 10g fallback query. Oracle 11g+ uses DBA_TABLESPACE_USAGE_METRICS.

Parameters and configuration

Parameters

--confPath to the configuration file.
--target_databasesPath to the configuration file containing the database targets.
--target_agentsPath to the configuration file containing the agent targets.
--custom_queriesPath to the configuration file containing custom queries.

Configuration file (--conf)

[CONF]
agents_group_id: < The ID of the group where agents will be created. >
interval: < The agent monitoring interval in seconds. >
user: < The connection username. >
password: < The password for the user. >
threads: < The number of threads to be used for agent creation. >
modules_prefix: < The prefix for module names. >
execute_custom_queries: < Activate with 1 to enable the use of custom queries. >
analyze_connections: < Activate with 1 to enable connection monitoring. >
engine_uptime: < Activate with 1 to enable runtime monitoring. >
query_stats: < Activate with 1 to enable query statistics monitoring. >
check_tablespaces: < Activate with 1 to enable tablespace statistics monitoring. >
fragmentation_ratio: < Activate with 1 to enable fragmentation ratio statistics monitoring. >
cache_stats: < Activate with 1 to enable cache statistics monitoring. >
thick_mode = < Activate with 1 to enable thick mode connection >
multitenant = < Enable with 1 to enable multi-tenant monitoring. Only applicable to Oracle multi-tenant architectures (CDB/PDB); in non-CDB environments, it will simply issue a harmless warning >
agent_per_pdb = <Enable with 1 to enable agent creation for each PDB. Applicable only to Oracle multitenant (CDB/PDB) architectures. If this box is checked, an agent will be created for each PDB in the instance; otherwise, the modules for each PDB will be included in the instance's primary agent. >
client_path = < Client path. Only necessary in case of using the thick mode >
entities_list = < Path where the entity file will be generated>
enable_entities_interval = < Path to activate the entity file (multitenant mode only)>
entities_interval = < entity file rescan interval>

[THRESHOLDS]
< Regex pattern matching module names > = < Desired thresholds in the module, separated by “|” >

Example

[CONF]
agents_group_id = 10
interval = 300
user = sa 
password = HHgD85V@
threads = 1
modules_prefix = 
execute_custom_queries = 1
analyze_connections = 1
engine_uptime = 1
query_stats = 1
check_tablespaces = 1
fragmentation_ratio = 1
cache_stats = 1
thick_mode = 1
multitenant = 0
agent_per_pdb = 0
client_path = /usr/lib/oracle/21/client64/lib/
entities_list = /tmp/entities_oracle.txt
enable_entities_interval = 1
entities_interval = 48000

[THRESHOLDS]
^tablespace = min_warning 10|max_warning 20|min_critical 0|max_critical 10
fragmentation = min_warning 10

The standard installation of instant client 19.8 is done in the /usr/lib/oracle/19.8/client64/lib path.

List of target databases (--target_databases):

The content of the file should be a list of target databases, with each database separated by commas or lines. The format for a database can be any of the following:

ip/sid
ip:puerto/sid 
ip:puerto/service_name

If the port is not specified, the default TCP port 1521 will be used for connecting to the target.

Example:

172.17.0.3:1521/FREEPDB1

Each line in the file should represent a separate target database using one of these formats. This file is used to specify the databases that the plugin should monitor.

You can also specify a DNS string directly.

Standalone server example:

dsn=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales1-srv)(PORT=1521))(CONNECT_DATA=(SID=ORCL)))

Failover example with two servers

dsn=(DESCRIPTION=(FAILOVER=ON)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=sales1-srv)(PORT=1521) (CONNECT_TIMEOUT=5)(RETRY_COUNT=2))(ADDRESS=(PROTOCOL=TCP)(HOST=sales2-srv)(PORT=1521)(CONNECT_TIMEOUT=5)(RETRY_COUNT=2)))(CONNECT_DATA=(SID=ORCL)))

List of target agents (--target_agents):

The content of the file should be a list of agent names, with each agent separated by commas or lines. These agent names will be used to associate the information from each target database with the corresponding specified agent name, instead of letting the plugin generate agent names automatically.

The position of each agent name in the list should match the position of the target database in its own list. In other words, the name for the first target database should be the first name in this list, considering that blank lines are ignored.

Example:

agente1,,agente3
agente4
agente5,agente6,agente7,,agente9

Custom Queries (--custom_queries)

One module must be defined for each custom query to be monitored. Modules must follow this structure:

check_begin      --> Module opening tag
name             --> Module name
description      --> Module description.
operation        --> Operation type: value (returns a single value) | full (returns all rows as string).
datatype         --> Module type: generic_data | generic_data_string | generic_proc.
min_warning      --> Minimum warning threshold
max_warning      --> Maximum warning threshold
str_warning      --> Warning string threshold
warning_inverse  --> Set to 1 to invert the warning threshold interval
min_critical     --> Minimum critical threshold
max_critical     --> Maximum critical threshold
str_critical     --> Critical string threshold
critical_inverse --> Set to 1 to invert the critical threshold interval
module_interval  --> This interval is calculated as a multiplier of the agent interval.
crontab          --> 5-field cron expression (minute, hour, day of month, month, day of week).
                    The query only runs when the current date/time matches the expression.
                    If not specified, the query runs on every interval.
                    Format: crontab <minute> <hour> <day_of_month> <month> <day_of_week>
                    Examples:
                      * * * * *      → every minute (always)
                      0 9 * * 1-5    → Monday to Friday at 09:00
                      */15 * * * *   → every 15 minutes
                      * 12-15 * * 1  → Mondays between 12:00 and 15:59
target           --> Custom query (only SELECT statements are allowed).
target_scope     --> Execution scope: cdb, pdb or all (default: cdb).
                    - cdb: only on the CDB instance
                    - pdb: only on each discovered PDB (requires multitenant enabled)
                    - all: on both (CDB and PDBs)
target_databases --> Database agents where the module will be created.
                    To apply to all elements, specify "all" or leave it unspecified.
check_end        --> Module closing tag

Basic module (no crontab, runs on every interval)

check_begin
name Select 1
description Number of invalid objects
operation value
datatype generic_data
min_warning 5
target SELECT 1 FROM dual
target_databases all
check_end

Module against a specific database

check_begin
name ConnectionCount
description Number of connections
operation value
datatype generic_data
min_warning 5
target SELECT COUNT(*) AS ConnectionCount FROM v$session;
target_databases pandora
check_end

Full operation module

check_begin
name RecordCount.files_table
description Invalid objects (detail)
operation full
datatype generic_data
target SELECT COUNT(*) AS RecordCount FROM files;
target_databases pandora
check_end

Module with crontab (runs only Monday to Friday at 09:00)

check_begin
name daily_report
description Daily report query
operation value
datatype generic_data_string
target SELECT COUNT(*) AS records FROM daily_log WHERE date = TRUNC(SYSDATE);
target_databases all
crontab 0 9 * * 1-5
check_end

Module with crontab (only during office hours 8:00–18:00)

check_begin
name active_office_users
description Active users during office hours
operation value
datatype generic_data
target SELECT COUNT(*) FROM users WHERE active = 'Y';
target_databases all
crontab * 8-17 * * 1-5
check_end

Module with crontab every 30 minutes and PDB scope

check_begin
name pdb_sessions
description Active sessions per PDB
operation value
datatype generic_data
target SELECT COUNT(*) FROM v$session WHERE status = 'ACTIVE';
target_databases all
target_scope pdb
crontab */30 * * * *
check_end

Crontab filter behavior

  1. At the beginning of each plugin execution, all custom queries are evaluated.
  2. Queries without the crontab field always run (classic behavior, backward compatible).
  3. Queries with crontab are only included if the current date/time matches the cron expression.
  4. Queries rejected by crontab do not generate database connections or SQL queries.
  5. The filter runs once before spawning monitoring threads.

Cron expression format

The expression follows the standard 5-field format separated by spaces:

Field Allowed values
Minute 0-59
Hour 0-23
Day of month 1-31
Month 1-12
Day of week 0-7 (0 and 7 = Sunday, 1 = Monday)

Each field supports the following formats:

Manual execution

The plugin execution format is as follows:

./pandora_oracle \
--conf <path to the configuration file> \
--target_databases <path to the configuration file containing target databases> \
[ --target_agents <path to the agent configuration file> ] \
[ --custom_queries <path to the custom queries configuration file> ]

For example :

./pandora_oracle \
--conf /usr/share/pandora_server/util/plugin/oracle.conf \
--target_databases /usr/share/pandora_server/util/plugin/targets.conf \
--target_agents /usr/share/pandora_server/util/plugin/target_agents.conf \
--custom_queries /usr/share/pandora_server/util/plugin/custom_queries.conf

 

Discovery

This plugin can be integrated with Pandora FMS Discovery.

To do this, you must load the ".disco" package that you can download from the Pandora FMS library:

https://pandorafms.com/library/oracle-discovery/

image-1687944670019.png

Once loaded, Oracle environments can be monitored by creating Discovery tasks from the Management > Discovery > Applications.

image-1687944766442.png

For each task, the following minimum data will be requested:

Captura desde 2026-07-01 13-26-54.png

Task settings can also be adjusted to customize the desired monitoring:

Captura desde 2026-01-14 18-31-20.png

Captura desde 2026-01-14 18-27-30.png


Tasks that are successfully completed will have an execution summary with the following information:

image-1684831085871.png


The tasks that are not completed successfully will have an execution summary recording the errors produced.

Agents and modules generated by the plugin

The plugin will create an agent for each target database. That agent will contain the following modules

If engine_uptime is activated:

restart\_detectionIt will be 0 if an unexpected restart has been detected, and 1 if this is not the case. When a server restarts unexpectedly, there may be an interruption in access to the database and potentially lost transactions or data not saved correctly.

Si esta activado query_stats:

queries: select**Number of SELECT queries**. SELECT queries are used to retrieve data from the database. Monitoring SELECT queries allows you to assess query efficiency and index optimization. By identifying slow or inefficient SELECT queries, you can take steps to improve their performance, such as adding appropriate indexes, optimizing the queries, or adjusting server configuration.
queriers: update**Number of UPDATE queries**. UPDATE queries are used to modify existing data in the database. Monitoring UPDATE queries is important to assess the frequency and efficiency of data updates. You can identify UPDATE queries that affect a large number of rows or have a significant impact on server performance. This allows you to optimize queries, review table structure, or take steps to reduce the load generated by updates.
queries: delete **Number of DELETE queries**. DELETE queries are used to delete data from the database. Monitoring DELETE queries is useful for evaluating the frequency and efficiency of data deletions. You can identify DELETE queries that affect a large number of rows or that have a significant impact on server performance. This allows you to optimize queries, review table structure, or take steps to reduce the load generated by deletes.
queries: insert**Number of INSERT queries**. INSERT queries are used to insert new data into the database. Monitoring INSERT queries allows you to assess the frequency and efficiency of data inserts. You can identify INSERT queries that are placing a high load on the server or could be causing performance issues. This allows you to optimize queries, review table structure, or consider lazy insert strategies to improve performance in high-concurrency environments.

If analyze_connections is activated:

session usage**Number of current connections** with respect to the total of maximum connections. Monitoring session usage in SQL Server is important to optimize performance, identify blocking issues, improve security and auditing, and efficiently plan server resources.

If cache_stats is enabled:

cache hit ratio (dictionary)**The cache ratio of the dictionary.** "Cache Hit Ratio (Dictionary)" refers to the ratio of Oracle dictionary data access requests that are resolved using cached data compared to requests that require disk access. The Oracle dictionary contains information about the database structure, objects, metadata, and other important details. A high hit ratio indicates that most dictionary access requests are resolved using data in the cache, which improves system performance by avoiding disk access.
cache hit ratio (library)**The cache ratio of the library.** "Cache Hit Ratio (Library)" refers to the ratio of access requests to Oracle procedures, functions, and packages stored in the shared library cache. The shared library cache stores the compiled code of frequently executed programs and SQL queries. A high hit ratio indicates that most requests are resolved using cached code, which avoids the need for recompilation and improves performance by reducing execution time.
cache hit ratio (buffer)**The buffer cache ratio.** "Cache Hit Ratio (Buffer)" refers to the proportion of requests to access blocks of data stored in Oracle's buffer cache that are resolved using data in the cache compared to requests that require access to disk. The buffer cache stores blocks of data that are frequently read or modified. A high hit ratio indicates that most data access requests are resolved using blocks stored in the buffer cache, which reduces the need for disk access and improves overall system performance.

If check_tablespaces is enabled:

tablespace <table name> free**Percentage of usage in GB**. It is important to monitor "tablespace free" in Oracle to keep track of the amount of space available in the tablespaces. This allows you to proactively manage storage space growth and avoid insufficient space issues that could impact database functionality. By monitoring tablespace free, you can take actions such as adding more storage space or making adjustments to configurations to ensure there is enough space available.
tablespace <table name> status**Status of the table, 1 if it is online and 0 if not**. Monitoring tablespace status in Oracle is essential to evaluate the health and status of tablespaces. Provides information about the structural integrity of tablespaces, including the existence of errors or corruption issues. By monitoring tablespace status, you can detect problems early and take action to resolve them, such as restoring from backups or performing recovery tasks. This ensures database continuity and stability, preventing data loss or performance degradation due to tablespace issues.

If fragmentation_ratio is activated:

fragmentation ratio**The fragmentation ratio**. The Fragmentation Ratio in Oracle Database is a value that indicates the amount of space wasted due to fragmentation in a data structure. A high Fragmentation Ratio indicates greater fragmentation and wasted space, which can impact system performance.

The plugin will also create a module for each custom query defined in the configuration file.

Multitenant Monitoring (CDB/PDB)

If multitenant is enabled (1 — enabled, 0 — disabled; default: 0), the plugin discovers Pluggable Databases (PDBs) within the Container Database (CDB) and collects the same performance metrics for each PDB (uptime, query stats, cache hit ratio, tablespaces, connections, fragmentation). Only applicable to Oracle multitenant (CDB/PDB) architectures; in non-CDB environments it will simply emit a harmless warning.

Behavior depends on the agent_per_pdb token:

agent_per_pdb disabled (default)

All PDB modules are added to the main CDB instance agent. Module names are prefixed with PDB <name>, for example:

PDB APP1 restart_detectionRestart detection for PDB APP1.
PDB APP1 queries: selectSELECT queries on PDB APP1.
PDB APP1 cache hit ratio (buffer)Buffer cache hit ratio for PDB APP1.
PDB APP1 tablespace USERS freeFree space of tablespace USERS in PDB APP1.

agent_per_pdb enabled

The plugin creates an independent agent for each discovered PDB, named <main_agent> - PDB <name> with address host:port/pdb_name. Each PDB agent contains:

PDBs not in READ WRITE mode are skipped with a warning.

Note: agent_per_pdb only takes effect when multitenant enabled.