删除表中的记录在Oracle中包含1.8亿

Question

Friends,

I have order tables which have minimum 100 Million records in each table. We have a job running which invokes a stored procedure which deletes atleast 50K (MIN) and 200K (MAX) records per day.

I'm currently using SQL BULK COLLECT to delete records from the table. Currently it is taking more than 4 hours for deleting 50K which is dead slow.

After searching in google, Figured out CTAS method ,i,e Creating table and keeping the records which we want and drop the existing one and rename the temp table. I CANNOT DO THIS AS THIS OPTION WAS NOT ACCEPTED AS THE TABLES ARE MORE CRITICAL.

Could you please suggest some solution to improve the performance of the same?

Thanks in advance!!

Answer 1

Assuming you have enough physical disk space to duplicate your data, you could use the following approach (I assume your table is called ORDERS):

• create a copy ORDER_B of your order table with CREATE TABLE orders_b AS SELECT * FROM orders
• rename your original table to ORDERS_A: ALTER TABLE orders RENAME TO orders_a
• create a synonym called ORDERS pointing to ORDERS_A: CREATE SYNONYM orders FOR order_a

So far, so good. Your client code now uses the synonym ORDERS instead of the physical table. Now comes the fun part (the daily refresh routine):

• truncate ORDERS_B
• fill ORDERS_B with INSERT /*+APPEND+*/ (you might also want to try the PARALLEL hint)
• switch the synonym ORDERS to point to ORDERS_B
• next day: repeat with ORDERS_A instead of ORDERS_B
• repeat ad infinitum

Alternatively, instead of using TRUNCATE/INSERT, you could DROP the table and re-CREATE it. This requires more work, since you'll also have to recreate indices and grants.

This technique is called synonym switching - you might want to read Tyler Muth's article about synonym switching to get a more complete explanation of it.

Answer 2

What is the condition for deleting the records?

Maybe you can create a function based index on this table. Then you may delete the records with a single and simple delete statement. Or think about table partitioning. If your partition key is smart and covers the delete condition you can drop or purge the old partition within a few seconds.

Btw, with package DBMS_REDEFINITION you can change a "normal" table to a partitized table even without interruption of service.