We recently changed from a 12.1 Single Instance to a 12.2 Version running in a RAC environment with two nodes.
Wa are now facing the problem that a PL/SQL procedure nearly takes factor 3 longer to run than on the single instance.
Our Administrators already identified that each Statment executes in the same time. We already tried to connect directly to a single node in hope that the procedure behaves like on the single instance but it does not.
The second issue is, that the uncahnged procedure (it does it job withaout any issue for the past 3 years) comes up with the following error.
Caused by: java.sql.SQLException: ORA-20000: ORA-02297: Constraint (SCHEMA.SPIL_PK) kann nicht deaktiviert werden - Abhängigkeiten sind vorhanden: Fehlgeschlagen => ALTER TABLE SPIEL DISABLE CONSTRAINT SPIL_PK
ORA-06512: in "<SCHEMA>.PR_CLEAR_DATABASE", Zeile 59
ORA-06512: in "<SCHEMA>.PR_CLEAR_DATABASE", Zeile 59
ORA-06512: in Zeile 1
The procedure:CREATE OR REPLACE PROCEDURE pr_CLEAR_DATABASE
AS
CURSOR lc_select_table
IS
SELECT TABLE_NAME
FROM USER_TABLES
WHERE TABLE_NAME NOT IN ('SCHEMA_VERSION', 'KMS')
AND TABLE_NAME NOT LIKE 'QRTZ_%'
ORDER BY 1;
CURSOR lc_enable_constraints
IS
SELECT
CONSTRAINT_NAME,
TABLE_NAME
FROM
USER_CONSTRAINTS
WHERE
STATUS = 'DISABLED'
AND CONSTRAINT_TYPE IN ('P','R')
AND TABLE_NAME NOT IN ('SCHEMA_VERSION')
AND TABLE_NAME NOT LIKE 'QRTZ_%'
ORDER BY R_CONSTRAINT_NAME DESC;
CURSOR lc_disable_constraints
IS
SELECT
CONSTRAINT_NAME,
TABLE_NAME
FROM
USER_CONSTRAINTS
WHERE
STATUS = 'ENABLED'
AND CONSTRAINT_TYPE IN ('P','R')
AND TABLE_NAME NOT IN ('SCHEMA_VERSION')
AND TABLE_NAME NOT LIKE 'QRTZ_%'
ORDER BY R_CONSTRAINT_NAME ASC;
lv_user VARCHAR2(128);
lv_sql VARCHAR2(512);
BEGIN
SELECT USER INTO lv_user FROM DUAL;
IF ((lv_user='SYSTEM') OR (lv_user='SYS')) THEN
RETURN;
END IF;
EXECUTE IMMEDIATE 'PURGE RECYCLEBIN';
-- DISABLE table's constraints
FOR lv_constraint IN lc_disable_constraints
LOOP
lv_sql := 'ALTER TABLE ' || lv_constraint.TABLE_NAME || ' DISABLE CONSTRAINT ' || lv_constraint.CONSTRAINT_NAME;
BEGIN
EXECUTE IMMEDIATE lv_sql ;
EXCEPTION
WHEN OTHERS THEN
raise_application_error ( -20000, SQLERRM || ': Fehlgeschlagen => ' || lv_sql);
END;
END LOOP;
-- TRUNCATE tables
FOR lv_table IN lc_select_table
LOOP
--get table name
lv_sql := 'TRUNCATE TABLE ' || lv_table.TABLE_NAME;
BEGIN
EXECUTE IMMEDIATE lv_sql ;
EXCEPTION
WHEN OTHERS THEN
raise_application_error ( -20000, SQLERRM || ': Fehlgeschlagen => ' || lv_sql);
END;
END LOOP;
-- ENABLE table's constraints
FOR lv_constraint IN lc_enable_constraints
LOOP
lv_sql := 'ALTER TABLE ' || lv_constraint.TABLE_NAME || ' ENABLE CONSTRAINT ' || lv_constraint.CONSTRAINT_NAME;
BEGIN
EXECUTE IMMEDIATE lv_sql ;
EXCEPTION
WHEN OTHERS THEN
raise_application_error ( -20000, SQLERRM || ': Fehlgeschlagen => ' || lv_sql);
END;
END LOOP;
END;
/
You get an ORA-02297 when you try and disable a PK which has an enabled FK pointing to it:
create table t1 (
x int not null primary key
);
create table t2 (
x int references t1 (x)
);
alter table t1 modify primary key disable ;
ORA-02297: cannot disable constraint (CHRIS.SYS_C0010760) - dependencies exist
Which means either:
- Someone added a new FK after the migration
- The constraint names changed during the migration
You're only sorting the constraints by name. So really you lucky this hasn't happened before. So either you need to change the cursor to get the FKs first:
ORDER BY CONSTRAINT_TYPE DESC, R_CONSTRAINT_NAME ASC
Or only select the PKs and use the cascade option:
alter table t1 modify primary key disable cascade;
Table T1 altered.
select status from user_constraints
where constraint_type in ( 'P', 'R' )
and table_name like 'T_';
STATUS
DISABLED
DISABLED
When it comes to the performance change, there's only one answer I can give:
Trace your session to see what it's doing!
Ideally do the same on the original system so you can see what's taking longer.
Anything else is a wild guess (=> probably wrong). For details on how to do this, see:
https://blogs.oracle.com/sql/how-to-create-an-execution-plan#tkprof If you're struggling to interpret the results, post your findings and we'll help out.