スケーラブルデータベースサーバ　HiRDB Version 8 UAP開発ガイド

[目次][索引][前へ][次へ]

3.4.8　UAPでできる排他制御

排他制御は，HiRDBシステムが自動的に制御していますが，処理形態によってはUAPで排他制御の単位を変更すると，オーバヘッドが削減できるので処理効率が向上します。UAPを作成するとき次に示す点を考慮してください。

＜この項の構成＞
(1)　検索の場合
(2)　更新の場合
(3)　削除の場合
(4)　注意事項

(1)　検索の場合

  1. 検索結果を一度参照するだけで，COMMITするまでデータを占有する必要がないときはSELECT文にWITHOUT LOCKを指定します。
    WITHOUT LOCKを指定すると，トランザクションの終了を待たないで排他が解除されるので，同時実行性が向上します。
    なお，WITHOUT LOCK NOWAITを指定しても，データベース作成ユティリティ（option文のnowait=yesを指定した場合を除く），又はデータベース再編成ユティリティ（-k unldの場合を除く）でデータ処理中の表は検索できません。
  2. 1以外の場合は，検索する前に，対象の表にLOCK文でSHAREモードの排他を掛けます。
    LOCK文であらかじめ表に排他を掛けると，ページ単位，又は行単位の排他をしないため，オーバヘッドが大幅に削減できます。また，排他制御用のバッファ不足を防止することもできます。
  3. 共用表を検索する場合，WITHOUT LOCK，又はWITH ROLLBACKを指定することをお勧めします。

(2)　更新の場合

  1. 更新する前に，対象の表にLOCK文でEXCLUSIVEモードの排他を掛けます。
    LOCK文であらかじめ表に排他を掛けると，行単位の排他をしないため，オーバヘッドが大幅に削減できます。また，排他制御用のバッファ不足を防止することもできます。
  2. 共用表に対して，インデクスのキー値の変更を伴う更新（追加，削除も含む）をする場合，及び大量の更新をする場合，必ずEXCLUSIVE指定のLOCK文で排他を掛けてください。なお，共用表にEXCLUSIVE指定のLOCK文で排他を掛けた場合，共用表に定義されているインデクスのインデクス格納用RDエリア（共用RDエリア）にも排他が掛かります。

(3)　削除の場合

  1. 表の削除，インデクスの削除，又は全行削除をする場合，対象となる表のすべての使用中セグメントに対してEXモードの排他を掛けます。
    なお，表の使用中セグメント数が多い場合，すべてのセグメントに対してEXモードの排他を掛けるため，COMMITするまでこれらすべてのセグメントを占有することになり，排他制御用バッファ内で多量の排他制御用資源管理テーブルを必要とするので注意する必要があります。特に，次に示す四つの文を使用して表の削除，インデクスの削除，又は全行削除をする場合は，注意してください。
    • DROP SCHEMA
    • DROP TABLE
    • DROP INDEX
    • PURGE TABLE
  2. 複数の表を所有するスキーマを削除する場合，各々の表を削除してからスキーマを削除します。
    各表を削除した後にスキーマを削除すると，使用するメモリが軽減できます。

(4)　注意事項

  1. LOCK文で表に排他を掛けると，ほかのトランザクションが長時間待ち状態になるため，オンライン業務との同時実行は避けてください。ただし，非共用表のNOWAIT検索については，待ち状態にはなりません。
  2. 共用表に対してNOWAIT検索をする場合，アクセスするRDエリアに対して，ほかのユーザがEXCLUSIVE指定のLOCK文を実行しているときはアクセスできません。

[目次][前へ][次へ]

[商品名称に関する表示]

All Rights Reserved. Copyright (C) 2006, 2016, Hitachi, Ltd.