2011-10-17 14 views
2

私はOracle11gで作業しており、dbms_redefinitionでテーブルを再定義しようとしています。それは正常に動作しますが、中間テーブルを削除しようとするとORA-02449: unique/primary keys in table referenced by foreign keysエラーがスローされます。ORACLE:dbms_redefinitionの後に中間テーブルを削除しました。

table_name |constraint_name   |status |owner 
--------------------------------------------------------- 
anotherTable|TMP$$_anotherTable_JOB_ID0|DISABLED|MYSCHEMA 

を与える

私は右ここSO内の参照を探すためにクエリを見つけ

select table_name, constraint_name, status, owner 
from all_constraints 
where r_owner = 'MYSCHEMA' 
and constraint_type = 'R' 
and r_constraint_name in 
(
    select constraint_name from all_constraints 
    where constraint_type in ('P', 'U') 
    and table_name = 'INTERIM_TABLE' 
    and owner = 'MYSCHEMA' 
) 
order by table_name, constraint_name 

が、私はこの制約を再定義プロセス中に作成されたと仮定し、それは大丈夫だが、私また、同じプロセスによって削除される必要があることも期待されます。これは間違っていますか?私は、この制約が削除されなかったという正常な動作の一部であると言います。

それだけでは、データを損失することなく

alter table anotherTable 
    drop constraint TMP$$_anotherTable_JOB_ID0 

で制約を削除しても安全ですか?

ありがとうございます。

- EDIT - これについて考えた後、暫定表を削除するように制約を削除することに決めました。

私はほとんど自動的に削除したいテーブルを指す他のテーブルの制約を削除するようにクエリを変更しました。

DECLARE 
    my_table varchar2(100); 
    my_constraint varchar2(100); 
BEGIN 
select table_name , constraint_name into my_table,my_constraint 
from all_constraints 
where r_owner = 'MYSCHEMA' 
and constraint_type = 'R' 
and r_constraint_name in 
(
    select constraint_name from all_constraints 
    where constraint_type in ('P', 'U') 
    and table_name = 'INTERIM_TABLE' 
    and owner = 'MYSCHEMA' 
) 
order by table_name, constraint_name; 
execute immediate 'ALTER TABLE '||my_table||' DROP CONSTRAINT '|| my_constraint; 
END; 
/
DROP TABLE MYSCHEMA.INTERIM_TABLE; 

これは私のために働いたが、私は私の場合には、そのクエリがちょうど1行(一つだけ従属テーブルを)投げることに注意しなければならないので、これはあなたの場合はループまたは他の方法で多くの制約をドロップするように変更する必要があります誰かを知っている。

誰かがその制約がプロセス自体によって削除されなかった理由(またはこれが通常の動作である場合)を把握して説明できるとよいでしょう。

答えて

7

それは、これを強制するのは簡単です:

drop table INTERIM_TABLE cascade constraints; 
+0

これは、一時的な中間テーブルを指すテーブルの行を削除しますか?いいえ。これらの行の外部キーは今も私の定義されたテーブルを指しているので、私が探しているものではありません。 – Keber

+1

いいえ。「CASCADE」は、interim_table –

+0

を参照している制約を破棄し、@ a_horse_with_no_nameに感謝します。 – Keber

2

次のようにSYNCとFINISH再定義の手順を実行している間、それはオリジナルと新しい制約のステータスが変化するのでです。無効モードでは、子テーブルから中間テーブルにfkeysを作成します。 redefを終えると、古いfキーを無効にし、ニュースを有効にします(検証する必要はありません)。以下を検討してください:

create table t NOLOGGING 
as 
select * from all_objects; 


alter table t add constraint t_pk primary key(object_id); 

create table t1(x references t); 
create table t2(y references t); 


insert into t1 select object_id from t where rownum <= 100; 

100 rows created. 


insert into t2 select object_id from t where rownum <= 100; 
100 rows created. 



create table t_interim similar to t table. 

alter table t1 add constraint t1_new_fk foreign key(x) references t_interim disable; 

alter table t2 add constraint t2_new_fk foreign key(y) references t_interim disable; 

select constraint_name, status from user_constraints where constraint_type = 'R'; 

CONSTRAINT_NAME    STATUS 
------------------------------ -------- 
SYS_C004733     ENABLED  <<<== original constraint 
T1_NEW_FK      DISABLED 
SYS_C004734     ENABLED 
T2_NEW_FK      DISABLED 


begin 
dbms_redefinition.sync_interim_table(user, 'T', 'T_INTERIM'); 
end; 
/

PL/SQL procedure successfully completed. 

begin 
dbms_redefinition.finish_redef_table(user, 'T', 'T_INTERIM'); 
end; 
/

PL/SQL procedure successfully completed. 


select constraint_name, status from user_constraints where constraint_type = 'R'; 

CONSTRAINT_NAME    STATUS 
------------------------------ -------- 
SYS_C004733     DISABLED  <<< flip flopped the status 
T1_NEW_FK      ENABLED 
SYS_C004734     DISABLED 
T2_NEW_FK      ENABLED 

drop table t_interim cascade constraints; 

select constraint_name, status from user_constraints where 
constraint_type = 'R'; 

CONSTRAINT_NAME    STATUS 
------------------------------ -------- 
T1_NEW_FK      ENABLED 
T2_NEW_FK      ENABLED 
関連する問題