Update a partioned table dynamically

Question

Hi All,
Parameters:
MANDATORY input parameters, FROM_DATE and TO_DATE.
OPTIONAL input parameter REVENUE_ID
My requirement:
To update table "ABC" based on the MANDATORY input parameters, FROM_DATE and TO_DATE. If the optional parameter, REVENUE_ID is entered, then, the column dept in ABC should get updated for the particular REVENUE_ID.
Steps Taken:
1) Since ABC has 3million rows.. A simple Update will take a long time and affect performance. So, I am updating it PARTITION wise.
2) I am fetching the PARTITION name in the cursor.(Partition is done period Wise on the table).
Code Created:
CREATE OR REPLACE PROCEDURE apps.test_dept_upd_prc (
p_from_date IN VARCHAR2,
p_to_date IN VARCHAR2,
p_revenue_id IN NUMBER
AS
CURSOR c_period (l_from_date DATE, l_to_date DATE)
IS
SELECT DISTINCT REPLACE (period_name, '-', '_') period_name,
start_date,
'ABC_'
|| REPLACE (period_name, '-', '_') partition_name
FROM gl_period_statuses
WHERE start_date BETWEEN TRUNC (TO_DATE (l_from_date), 'MM')
AND TRUNC (TO_DATE (l_to_date), 'MM')
AND set_of_books_id = 1
AND application_id = 101
ORDER BY start_date ASC;
TYPE tbl_period IS TABLE OF c_period%ROWTYPE
INDEX BY BINARY_INTEGER;
rec_period tbl_period;
l_from_date DATE;
l_to_date DATE;
l_partition VARCHAR2 (100);
BEGIN
-- DBMS_OUTPUT.ENABLE (1000000);
l_from_date := TO_DATE (fnd_date.canonical_to_date (p_from_date));
l_to_date := TO_DATE (fnd_date.canonical_to_date (p_to_date));
OPEN c_period (l_from_date, l_to_date);
LOOP
FETCH c_period
BULK COLLECT INTO rec_period LIMIT 100;
EXIT WHEN c_period%NOTFOUND;
FORALL i IN 1 .. rec_period.COUNT
UPDATE ABC PARTITION (rec_period (i).partition_name) kr
SET kr.dept =
NVL ((SELECT rt.attribute1
FROM ra_territories rt, hz_cust_site_uses_all hc
WHERE rt.territory_id = hc.territory_id
AND kr.ship_to_site_use_id = hc.site_use_id),
kr.dept
WHERE kr.dept NOT IN (SELECT attribute1
FROM ra_territories)
AND TRUNC (kr.creation_date) BETWEEN TO_DATE (l_from_date)
AND TO_DATE (l_to_date)
AND kr.revenue_id =
NVL2 (p_revenue_id, p_revenue_id, kr.revenue_id);
END LOOP;
COMMIT;
CLOSE c_period;
END test_dept_upd_prc;
Issue:
When I compile the code, it gives me an error at line
UPDATE ABC PARTITION (rec_period (i).partition_name) kr
as below:
PL/SQL: ORA-00971: missing SET keyword
This is the 1st time, I am using the BULK Binding concept. But, I have not been able to debug.
Please help me in solving this issue.
Thanks!
Regards,
AB

Answer 1

Partitioning is a PHYSICAL database design feature. Similar to the physical storage clause for the table. The block size of the tablespace for that table. The name of the primary key constraint of that table. Etc.
Application code works with the LOGICAL database design. So the app code needs to know the name of the table, the columns, and what the relationships are (e.g. for correctly joining that table with others).
App code does this in order to satisfy business requirements. Like processing an invoice. Or processing a leave application.
Why should app code ever need to know physical features and characteristics of a table? What business requirement says that "+process the invoice+" and then "+oh yes, use index SYS_C102344 to verify the customer's id+"?
Application DOES NOT need to know ANYTHING about the physical database implementation. It does not need to know whether the table is a hash table or index organised table. It does not need to know whether or not the table is clustered.
And it does not need to know whether the table is partitioned.. nor what partitions should or should not be used.
If your application needs to know physical attributes of the table, like partition name, then your application code and design are flawed.
Oracle's CBO (Cost Based Optimiser) has all the data needed for it to make the decision of how to best use the physical features and attributes of the data objects used by your application SQL. It can perfectly well determine what partitions to use and not use.
It makes no sense at all for your application code to infringe on what the CBO does - and does very well. Your code does not have the same abilities. Your code lacks the intelligence. Your application code will never be able to compete with the CBO.