columnの削除に注意すべき問題
テーブルの1つ以上のカラムを削除するには、次の2つの方法があります.
1.直接削除
ALTER TABLE DROP COLUMN column_name; --//複数の列を削除するには、ALTER TABLE DROP(,);複数のカラムを削除する場合は、複数のカラムにカッコを付け、columnキーは必要ありません.
2.負荷の問題を考慮して、まず列をUNUSEDに設定し、負荷が空いているときに削除する
ALTER TABLE SET UNUSED (); --//そして、暇なときに列を削除する.ALTER TABLE DROP UNUSED COLUMNS CHECKPOINT ;
--CHECKPOINTキーワードはundo空間の消費をある程度減らすことができ、後に削除記録の数をつなぎ、何ペンのデータを削除した後にcheckpointを強制するかを指定します.
1.第1の方法でテストを行います.
この列を削除するのに7分かかり、2376 Mのredoデータが生成されたのは恐ろしい.
2.次に、2つ目の方法をテストします.
再構築テーブルT
まずcolumnsをunusedに設定し、生成されるredoは非常に少ない.
本当に削除すると大量のredoが発生し、予想通りになります.
3.ポイントですが、この2つの方法を一緒に使うときに注意しなければならない問題の一つです
表Tを再構築した後:
v 2をunusedに設定して空きを待ってから本当に削除し、column flagを新規作成しますが、flagが間違っていることに気づき、削除する必要があります.flagが新しいテーブルであることを考慮すると、このflagはあまりredoを生成しないので、直接削除します.
しかしdrop flagというcolumnを発見するのに待ち時間がかかりすぎて、状況が間違っているような気がします.
削除が終了すると、大量のredoが発生することが判明する.
もともとdrop flagの時、flagに対して削除するだけで、他のcolumnに影響しないと思っていましたが、データベースはdrop flagの時にunusedのcolumnを一緒に削除しました.これにより大量のredoが発生し,この操作は後で注意しなければならない.
Redoのスイッチング周波数からも大量のredoが発生していることがわかる.
1.直接削除
ALTER TABLE DROP COLUMN column_name; --//複数の列を削除するには、ALTER TABLE DROP(,);複数のカラムを削除する場合は、複数のカラムにカッコを付け、columnキーは必要ありません.
2.負荷の問題を考慮して、まず列をUNUSEDに設定し、負荷が空いているときに削除する
ALTER TABLE SET UNUSED (); --//そして、暇なときに列を削除する.ALTER TABLE DROP UNUSED COLUMNS CHECKPOINT ;
--CHECKPOINTキーワードはundo空間の消費をある程度減らすことができ、後に削除記録の数をつなぎ、何ペンのデータを削除した後にcheckpointを強制するかを指定します.
1.第1の方法でテストを行います.
SQL> @ver
BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
SQL> create table t (id number,v1 varchar2(10),v2 varchar2(20));
Table created.
SQL> insert into t select rownum,lpad('a',10,'a'),lpad('b',20,'b') from dual connect by rownum<10000000;
9999999 rows created.
SQL> commit;
Commit complete.
SQL> set timing on;
SQL> alter table t drop ( v2);
Table altered.
Elapsed: 00:07:08.30
SQL> @viewredo
NAME VALUE
------------------------------ ----------
user commits 1
redo size 2376261196
redo wastage 0
data blocks consistent reads - 1
undo records applied
この列を削除するのに7分かかり、2376 Mのredoデータが生成されたのは恐ろしい.
2.次に、2つ目の方法をテストします.
再構築テーブルT
SQL> drop table t purge;
Table dropped.
SQL> create table t (id number,v1 varchar2(10),v2 varchar2(20));
Table created.
SQL> insert into t select rownum,lpad('a',10,'a'),lpad('b',20,'b') from dual connect by rownum<10000000;
9999999 rows created.
SQL> commit;
Commit complete.
まずcolumnsをunusedに設定し、生成されるredoは非常に少ない.
SQL> alter table t SET UNUSED (v2);
Table altered.
SQL> @viewredo
NAME VALUE
------------------------------ ----------
user commits 1
redo size 3768
redo wastage 0
data blocks consistent reads - 1
undo records applied
本当に削除すると大量のredoが発生し、予想通りになります.
SQL> alter table t drop unused columns;
Table altered.
SQL> @viewredo
NAME VALUE
------------------------------ ----------
user commits 2
redo size 2379126024
redo wastage 0
data blocks consistent reads - 2
undo records applied
3.ポイントですが、この2つの方法を一緒に使うときに注意しなければならない問題の一つです
表Tを再構築した後:
v 2をunusedに設定して空きを待ってから本当に削除し、column flagを新規作成しますが、flagが間違っていることに気づき、削除する必要があります.flagが新しいテーブルであることを考慮すると、このflagはあまりredoを生成しないので、直接削除します.
SQL> alter table t SET UNUSED (v2);
Table altered.
SQL> alter table t add ( flag number(1,0));
Table altered.
SQL> @viewredo
NAME VALUE
------------------------------ ----------
user commits 1
redo size 6920
redo wastage 0
data blocks consistent reads - 2
undo records applied
SQL> alter table t drop (flag);
しかしdrop flagというcolumnを発見するのに待ち時間がかかりすぎて、状況が間違っているような気がします.
削除が終了すると、大量のredoが発生することが判明する.
SQL> @viewredo
NAME VALUE
------------------------------ ----------
user commits 2
redo size 2379294812
redo wastage 0
data blocks consistent reads - 3
undo records applied
もともとdrop flagの時、flagに対して削除するだけで、他のcolumnに影響しないと思っていましたが、データベースはdrop flagの時にunusedのcolumnを一緒に削除しました.これにより大量のredoが発生し,この操作は後で注意しなければならない.
SQL> SELECT col#, segcol#, name, intcol#, type# FROM sys.col$ WHERE obj# IN (SELECT object_id FROM
2 dba_objects WHERE object_name = 'T' AND owner = user);
COL# SEGCOL# NAME INTCOL# TYPE#
---------- ---------- ------------------------------ ---------- ----------
1 1 ID 1 2
2 2 V1 2 1
Redoのスイッチング周波数からも大量のredoが発生していることがわかる.
SQL> @log_history
Date Day Total h0 h1 h2 h3 h4 h5 h6 h7 h8 h9 h10 h11 h12 h13 h14 h15 h16 h17 h18 h19 h20 h21 h22 h23
--------- --- ----- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
09-APR-20 Thu 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 6 10 0 0 0 0 0 0 0
08-APR-20 Wed 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
01-APR-20 Wed 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0
26-MAR-20 Thu 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 8 4 0 0 0 0 0 0
23-MAR-20 Mon 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0
24-FEB-20 Mon 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
18-FEB-20 Tue 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
12-FEB-20 Wed 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
06-FEB-20 Thu 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
31-JAN-20 Fri 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
10 rows selected.