1

I have a requirement where we need to drop historical partitions which are not dropped . Requirement is dropping multiple partitions in one step instead of dropping one by one.

like

ALTER TABLE sales DROP PARTITION sales_q1_2008, sales_q2_2008,
sales_q3_2008, sales_q4_2008 update global indexes;

instead of

ALTER TABLE sales DROP PARTITION sales_q1_2008 update global indexes;
ALTER TABLE sales DROP PARTITION sales_q2_2008 update global indexes;
ALTER TABLE sales DROP PARTITION sales_q3_2008 update global indexes;

and so on...

app team has this code:-

CREATE OR REPLACE PROCEDURE Test_user.DROP_PARTITIONS (p_table_name in varchar2, p_partition_key in number)
is
  pragma autonomous_transaction;
begin
  for cur in (
    select partition_name from user_tab_partitions
      where table_name = p_table_name
      and substr(partition_name,1,8) <= 'P_'||trim(to_char(p_partition_key,'000000'))
      order by partition_position desc
  ) loop
    -- wait for processes which might have a lock on the partition to drop (max 10min)
    execute immediate 'lock table '||p_table_name||' partition ('||cur.partition_name||') in exclusive mode wait 600';
 
    execute immediate 'alter table '||p_table_name||' drop partition '||cur.partition_name || ' UPDATE GLOBAL INDEXES';
  end loop;
end;
/

But I guess this is doing serial drop for each partitions thereby creating many alter statements instead of 1 step command where all the necessary partitions are dropped.

How can we adapt this ?

5
  • You can't. Per the documentation, each drop must be a separate alter table command: docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/…
    – pmdba
    Commented Mar 23, 2023 at 15:17
  • 1
    What is your reason for not wanting to do separate ALTER statements?
    – Paul W
    Commented Mar 23, 2023 at 22:29
  • @pmdba Check the documentation you referenced again. The syntax OP wants to use was introduced 9 years ago, in version 12.1. Commented Mar 24, 2023 at 6:56
  • @BalazsPapp Ah! you are correct! That said, the OP hasn't identified which version of Oracle they are using.
    – pmdba
    Commented Mar 24, 2023 at 11:32
  • Hi, we use 19.16. Reason to have 1 statement is to reduce library cache lock and it's a suggestion from SR as the more DDL we do the more we have contentions as there are some parallel DML which we can't avoid as we are 24*7 and even though we do partition maintenance in night. Job expects to drop 20-40 partition and we want to have 1 drop command. Currently we are experiencing library cache lock,cursor validation and mutex Commented Mar 24, 2023 at 20:27

1 Answer 1

-1

Something like this:

create or replace procedure test_user.drop_partitions (p_table_name in varchar2, p_partition_key in number)
is
  l_partition_list varchar2(32767);
begin
  select listagg(partition_name, ',') within group (order by partition_position) into l_partition_list
  from user_tab_partitions
  where table_name = p_table_name
  and substr(partition_name,1,8) <= 'P_'||trim(to_char(p_partition_key,'000000'));
  
  execute immediate 'alter session set ddl_lock_timeout=600';
  execute immediate 'alter table '||p_table_name||' drop partition '|| l_partition_list || ' UPDATE GLOBAL INDEXES';
end;
/
3
  • What kind of lock should be good ? should it be done on session or for each partition ? Also any tips on index management in 19.16 ? Like should we do first truncate partition snd then drop partition to make it faster and then later cleanup indexes ? Problem statement is "How can we do partition maintenance with minimal impact as we have concurrent DML's (even though in midnight) due to 24*7 payment application? Commented Mar 25, 2023 at 9:46
  • @DhirenSingh None. Why bother with explicit locking? The DDL will implicitly lock whatever is needed. Why would you truncate then drop the partition if you can just drop it? Deferred index cleanup will do the same work, just later. If it is this important, you should have locally partitioned indexes so partitions could be dropped in a matter of seconds without worrying about non-partitioned or globally partitioned indexes. Commented Mar 26, 2023 at 19:08
  • So resource wise is truncate + drop and direct drop is same? Like even the elapsed time? Idea is to minimize the timeouts and make drop partition Job run shorter with all indexes remain usable as we also have local partitioned indexes. I want to test both scenarios to see what works best .Any suggestions? Can this pl/SQL code be adapted for truncate and drop as well ? Commented Mar 27, 2023 at 20:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.