> ## Documentation Index
> Fetch the complete documentation index at: https://docs.germainux.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Oracle Database Troubleshooting

> Troubleshoot an Oracle database or APM_DATAMART tablespace nearing its storage limit, datafile growth, or GermainUX failing to insert monitoring data.

> [card] [Oracle Database Is Running Out of Space](#oracle-database-is-running-out-of-space)
>
> Fixing storage exhaustion

> [card] [Identify Partitioned Tables](#2-identify-partitioned-tables)
>
> Querying partition metadata

> [card] [Drop Expired Partitions](#5-drop-expired-partitions)
>
> DBA-only destructive step

> [card] [Prevent Recurrence](#prevent-recurrence)
>
> Keeping storage from refilling

## Oracle Database Is Running Out of Space

### Symptoms

The Oracle database or an `APM_DATAMART` tablespace is approaching its storage limit, datafiles are growing unexpectedly, or GermainUX can no longer insert monitoring data.

A common cause is that expired partitions have not been removed according to the configured GermainUX retention policy.

## 1. Confirm the Cause

Before deleting anything, determine whether storage is being consumed by:

| | Potential Cause |
| - | - |
| 1 | Active GermainUX data |
| 2 | Expired partitions |
| 3 | Indexes |
| 4 | Temporary tablespace |
| 5 | Archive logs |
| 6 | Materialized views |
| 7 | Failed retention or maintenance jobs |
| 8 | Insufficiently sized or non-extensible datafiles |

Do not assume that old partitions are the cause until database utilization has been reviewed.

## 2. Identify Partitioned Tables

List the partitioned tables available to the current account:

```sql theme={null}
SELECT
    OWNER,
    TABLE_NAME,
    PARTITIONING_TYPE,
    SUBPARTITIONING_TYPE,
    PARTITION_COUNT
FROM ALL_PART_TABLES
ORDER BY OWNER, TABLE_NAME;
```

Limit the query to the GermainUX datamart schema when appropriate:

```sql theme={null}
SELECT
    OWNER,
    TABLE_NAME,
    PARTITIONING_TYPE,
    PARTITION_COUNT
FROM ALL_PART_TABLES
WHERE OWNER = 'APM_DATAMART'
ORDER BY TABLE_NAME;
```

## 3. List the Partitions

To inspect the partitions of a specific table:

```sql theme={null}
SELECT
    TABLE_OWNER,
    TABLE_NAME,
    PARTITION_NAME,
    PARTITION_POSITION,
    HIGH_VALUE,
    TABLESPACE_NAME
FROM ALL_TAB_PARTITIONS
WHERE TABLE_OWNER = 'APM_DATAMART'
  AND TABLE_NAME = '<TARGET_TABLE_NAME>'
ORDER BY PARTITION_POSITION;
```

Replace `<TARGET_TABLE_NAME>` with the uppercase Oracle table name.

Review each partition’s boundary and confirm which dates it contains before considering removal.

## 4. Verify the Retention Policy

Before removing a partition, confirm:

* The applicable GermainUX retention period
* The partition’s date range
* Whether the data is still required for reporting, analysis, or compliance
* Whether aggregated data has been generated
* Whether a valid backup or snapshot exists
* Whether dependent indexes or materialized views will be affected
* Whether the partition is still receiving data

Never remove a partition based only on its name.

## 5. Drop Expired Partitions

Only a qualified Oracle DBA should remove partitions.

Partition deletion is destructive and may be difficult or impossible to reverse without a valid backup. Use the Oracle-supported `ALTER TABLE ... DROP PARTITION` procedure appropriate for the installed Oracle version and the table’s partitioning strategy.

Do not copy a generic drop command into production without verifying:

* Schema
* Table
* Partition
* Retention boundary
* Index-maintenance behavior
* Backup availability
* Application impact

Where supported and appropriate, include the required global-index maintenance option to avoid leaving indexes unusable.

## 6. Validate After Removal

After removing an expired partition:

**1. Confirm that the intended partition was removed**

**2. Verify the status of affected indexes**

**3. Confirm that GermainUX continues to insert data**

**4. Validate representative dashboards and analyses**

**5. Check materialized-view refresh jobs**

**6. Review tablespace utilization**

**7. Confirm that no required data was removed**

**8. Verify that the automated retention process will handle future partitions**

## Prevent Recurrence

To prevent future storage exhaustion:

* Monitor tablespace utilization.
* Alert before storage reaches a critical threshold.
* Review retention jobs regularly.
* Confirm that expired partitions are removed automatically.
* Monitor datafile auto-extension and maximum size.
* Track daily ingestion growth.
* Reassess storage when monitoring scope or retention increases.
* Periodically test backup and recovery procedures.

> [!NOTE]
>
> If old partitions are not being removed automatically, contact Germain Software before implementing a recurring manual deletion process.

## Get Help

> [card] [Contact GermainUX Support](https://docs.germainux.com/main/support.md)
>
> The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes.

> [card] Can't find what you need?
>
> Search all GermainUX docs with **Ctrl + K**, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.