ORA-14033: Attempt to Drop the Highest Partition of a Range-Partitioned Table
ORA-14033 is thrown by Oracle when you try to drop the highest (last) partition of a range-partitioned table using ALTER TABLE ... DROP PARTITION. Oracle enforces this restriction to preserve the structural integrity of range-partitioned tables, especially when the target partition is defined with MAXVALUE or holds the highest upper bound in the partition set. Understanding why this happens and how to work around it will save you significant troubleshooting time in production environments.
Top 3 Causes
1. Directly Dropping a MAXVALUE Partition
The most common cause is attempting to drop a partition defined with MAXVALUE as its upper boundary. Oracle simply does not allow it via a direct DROP command.
-- This will trigger ORA-14033
ALTER TABLE scott.sales DROP PARTITION p_maxvalue;
-- ORA-14033: attempt to drop the highest partition of a range-partitioned table
-- First, verify the partition structure
SELECT partition_name, partition_position, high_value
FROM dba_tab_partitions
WHERE table_name = 'SALES'
AND table_owner = 'SCOTT'
ORDER BY partition_position;
2. Dropping the Only Remaining Partition
If only one partition remains in a partitioned table and you try to drop it, ORA-14033 is raised because Oracle requires at least one partition to exist at all times.
-- Check how many partitions exist before dropping
SELECT COUNT(*) AS partition_count
FROM dba_tab_partitions
WHERE table_name = 'SALES';
-- If count = 1, this will fail with ORA-14033
ALTER TABLE scott.sales DROP PARTITION p_only_partition;
3. Misidentifying the Highest Partition by Name
DBAs sometimes confuse partition name ordering with the actual HIGH_VALUE ordering. The highest partition is determined by HIGH_VALUE, not alphabetical or creation order of the name.
-- Always check HIGH_VALUE to identify the true highest partition
SELECT partition_name,
partition_position,
high_value
FROM dba_tab_partitions
WHERE table_name = 'SALES'
ORDER BY partition_position DESC
FETCH FIRST 3 ROWS ONLY;
Quick Fix Solutions
Fix 1: SPLIT the Highest Partition Before Dropping
Split the MAXVALUE partition into two — one with a defined upper bound and a new MAXVALUE partition. Then drop the lower one safely.
-- Split MAXVALUE partition to isolate old data
ALTER TABLE scott.sales
SPLIT PARTITION p_maxvalue
AT (TO_DATE('2024-01-01', 'YYYY-MM-DD'))
INTO (
PARTITION p_2023,
PARTITION p_maxvalue
);
-- Now safely drop the non-highest partition
ALTER TABLE scott.sales DROP PARTITION p_2023;
Fix 2: TRUNCATE Instead of DROP
If your goal is to purge data rather than remove the partition structure, use TRUNCATE PARTITION. This is always safe regardless of partition position.
-- Truncate data without removing the partition
ALTER TABLE scott.sales TRUNCATE PARTITION p_maxvalue;
Fix 3: Use a Safe Drop Wrapper in PL/SQL
Use a guarded PL/SQL block in batch jobs to prevent accidentally targeting the highest partition.
DECLARE
v_max_pos NUMBER;
v_target_pos NUMBER;
v_part_name VARCHAR2(128) := 'P_2020';
BEGIN
SELECT MAX(partition_position)
INTO v_max_pos
FROM dba_tab_partitions
WHERE table_name = 'SALES';
SELECT partition_position
INTO v_target_pos
FROM dba_tab_partitions
WHERE table_name = 'SALES'
AND partition_name = v_part_name;
IF v_target_pos < v_max_pos THEN
EXECUTE IMMEDIATE
'ALTER TABLE scott.sales DROP PARTITION ' || v_part_name;
DBMS_OUTPUT.PUT_LINE('Dropped: ' || v_part_name);
ELSE
DBMS_OUTPUT.PUT_LINE('Cannot drop highest partition: ' || v_part_name);
END IF;
END;
/
Prevention Tips
Use INTERVAL Partitioning Instead of MAXVALUE
Switching from range partitioning with MAXVALUE to interval partitioning eliminates the fixed-highest-partition concept, significantly reducing the risk of ORA-14033.
-- Recommended: INTERVAL partitioning
CREATE TABLE sales_interval (
sale_id NUMBER,
sale_date DATE,
amount NUMBER(15,2)
)
PARTITION BY RANGE (sale_date)
INTERVAL (NUMTOYMINTERVAL(1, 'MONTH'))
(
PARTITION p_init VALUES LESS THAN (TO_DATE('2020-01-01','YYYY-MM-DD'))
);
Always Validate Before Dropping
Build partition position checks into every maintenance script or stored procedure. Query DBA_TAB_PARTITIONS to confirm the target partition is not the highest before executing any DROP command. This one habit can prevent ORA-14033 from ever appearing in your production logs.
Related Errors
- ORA-14074: Raised when adding a partition with a bound less than or equal to the last partition's bound — commonly seen alongside MAXVALUE partition tables.
- ORA-14006: Invalid partition name specified; occurs when referencing a non-existent partition.
-
ORA-14021: Raised when a value beyond
MAXVALUEis used as a partition boundary.
📖 Want a more detailed guide?
Check out the full in-depth version (Korean) on oraerror.com — includes detailed analysis, additional SQL examples, and prevention tips.
Top comments (0)