すべての行を更新

単一の列の非常に大きなOracleテーブルのすべての行を更新する最も効率的な方法を知りたいです。例えば：

update mytable set mycolumn=null;

または：

update mytable set mycolumn=42;

私の知識は非常に古いかもしれません。テーブルを変更して列を削除します。次に、テーブルを変更して、使用する新しい値のデフォルト値を持つ列を追加します。次に、テーブルを変更して、列のデフォルト値を削除します。これは更新を実行するよりもはるかに高速であることがわかりましたが、より良い方法があると感じています。

この一括更新を行っている間、このテーブルに対して行われている他のアクティビティに大きく依存します。あなたがしたいことのサンプルをいくつか実行して、どの方法が最適であるかのアイデアを得ることができる、ある種のテスト環境があることを願っています。私が試してみます：

1. シングルを実行しupdate table set column_name = blahます;
2. plSqlループを作成して、テーブル内のすべての主キーを選択してループし、すべてのupdating the column=blahX更新（おそらく10000）をコミットします。このコードをコピーして、プライマリキーの別のセクションにコピーさせることにより、このコードを並列化できます。

OLTPシステムで非常にアクティブに使用されているテーブルで非常によく似た問題があり、5倍に並列化でき、10000ごとにコミットする100以上のMM行テーブルでユーザーロックの影響なしで実行できました。テーブルが大きいか、実行しているアプリケーションの種類が異なりますが、この種のソリューションが適している場合があります。

高速の場合、UPDATE起動しているトリガーがないことを確認してください。

SELECT trigger_name, status FROM user_triggers WHERE table_name = 'MYTABLE';

ALTER TABLE mytable DISABLE ALL TRIGGERS;

完了したら、必要なものだけを再度有効にしてください。

ALTER TRIGGER mytrigger ENABLE;

また、インデックスメンテナンスのオーバーヘッドが発生する場合があります。インデックスを個別に再構築してください。これを行うには、pappesによるここの答えが役立つはずです：https ://stackoverflow.com/questions/129046/disable-and-later-enable-all-table-indexes-in-oracle

参考のために、ここでpappesの回答を繰り返します。（このSPOOLコマンドは、プラットフォームと環境に関する仮定を行うことに注意してください。）

set pagesize 0    
alter session set skip_unusable_indexes = true;
spool c:\temp\disable_indexes.sql
select 'alter index ' || u.index_name || ' unusable;' from user_indexes u;
spool off
@c:\temp\disable_indexes.sql

インポートする...

select 'alter index ' || u.index_name || ' rebuild online;'
  from user_indexes u;

インデックスを削除します。列を更新します。インデックスを返します。ただし、列のすべての行に同じ値が含まれている場合は、インデックスを削除できます。

スペースに制限がない場合は、テーブルに新しい列を追加したテーブルと同じ新しいテーブルを作成し、古いテーブルを削除できます。

create new_table as
select old_table.*, (with or without default_Value) as new_column
from old_table;

複数の更新/コミットシーケンスを試してください。コミットせずに行を挿入/更新/削除しすぎると、IOの負荷が高くなります。ブロックサイズやレコードサイズなどを知って、かなり最適化できます。

テーブルのデータ全体を削除するにtruncate table xは、の方が優れていdelete from xます。また、パージによって別のプロセスのワークロードが発生します。

編集：inmemoryオプションを使用して、表を列形式でメモリにロードしてから更新を実行できます。DBの関係と構造に本当に依存します。こちらの記事をご覧ください。