かなめのロジック

フリーランスSEの雑記ブログ。ORACLEやPostgreSQL、金融、フリーの働き方について主に書いています。

ダイレクトパスインサート

time 2016/01/20

ダイレクトパスインサート

データ登録処理(INSERT)に時間に想定外の時間がかかることがあります。特に、インデックスが多くはられているテーブルに対して、大量のデータ登録を行うと時間がかかります。
本記事では、そのような状況下でのパフォーマンス解決策の一つ、ダイレクトパスインサートについて解説していきます。

sponsored link

ダイレクトパスインサートとは

ダイレクトパスインサートとは、バッファキャッシュを経由せずに、データファイルへ直接データ登録を反映する手法で、高速でデータ登録処理を行う事が出来ます。通常のデータ登録処理に比べて、処理時間が数分の1~10分の1程度に改善できます。
使い方は、対象のINSERT文にAPPENDヒントを付加するだけです。

以下具体的な使用例です。

パフォーマンス不足の解消に、便利そうなダイレクトパスインサートですが、相応のデメリットもあります。

デメリット

HWM以降のブロックにデータ登録される

通常のデータ登録処理では、データ削除処理(DELETE)で空いた領域があった場合、そこを優先的に格納先にします。

ダイレクトパスインサートでは、必ずハイウォーターマーク(HWM)以降のブロックにデータが格納されます。
日常的に使用する場合、セグメント領域が肥大化&断片化し検索効率の悪化します。
解消するためには、セグメント縮小(SHRINK等)が必要になります。

テーブルが表単位で排他ロックされる

ダイレクトパスインサートがコミット(もしくはロールバック)されるまでは、対象テーブルが表単位で排他ロックされます。つまり、他のトランザクションで同時に更新処理を行うことが出来ません。
日常的に使用する場合、並行する他の処理を考慮する必要があります。

トランザクション終了まで対象表にアクセス不可

ダイレクトパスインサートがコミット(もしくはロールバック)されるまでは、対象表にはトランザクション内ではアクセスが出来ません。注意する点は、更新系ではないデータ抽出(SELECT)も不可な点です。

その他デメリット

参照整合性制約・トリガーが定義されている表には、ダイレクトパスインサートを使用できません。暗黙的に通常のインサート処理が行われます。

また、通常のデータ登録処理に比べて、一時表領域を多く消費します。

まとめ

データ登録処理(INSERT)でパフォーマンス不足が発生した時に、最小の修正で済むダイレクトパスインサート、魅力的です。
しかし、相応のデメリットもあります。
デメリットを考慮し、使用できる場面では修正策の一つとして検討してみて下さい。
例えば、新規テーブルの初期登録では、問題なく使用できるかと思います。

sponsored link

管理人

かなめ

フリーランスになって5年目の業務系システムエンジニア。情報処理安全確保支援士。 ORACLEと金融と子育ての狭間で、元気に楽しくやってます。 [詳細]

管理人twitter

ブログ村

人気ブログランキング



sponsored link