Hitachi

ノンストップデータベース HiRDB Version 9 構造型データベース機能


9.3.1 オペランドの形式と説明

〈この項の構成〉

(1) オペランドの形式

■set形式

〔set lockrange = transaction|cursorupdate〕

■コマンド形式

〔{{subschema -s SDBデータベース名
              〔-t ルートレコードのレコード型名
              〔-e {shared|protected|exclusive}
                -a retrieve|update〕〕
  }}〕

(2) オペランドの説明

SDB用UAP環境定義のオペランドについて説明します。

なお,サブページ分割をしている場合は,ページをサブページに読み替えてください。

(a) set形式

lockrange = transaction|cursorupdate

DMLでSDBデータベースを操作した結果,レコード位置指示子が指さなくなったレコード実現値を格納するページに対する排他の解除時期を指定します。

transaction:

トランザクション終了時に,ページに対する排他を解除します。

cursorupdate:

DML終了時に,ページに対する排他を解除します。これを排他自動解除機能といいいます。排他自動解除機能については,「2.9.4 排他自動解除機能」を参照してください。

《利点》

このオペランドにcursorupdateを指定すると,ページの排他解除時期が早くなるため,ほかのトランザクションとの同時実行性能が向上します。

《適用基準》

通常はtransaction(省略値)を指定してください。次のような場合にcursorupdateを指定してください。

  • トランザクション内でデータの一貫性を保証する必要がなく,検索したレコード実現値を更新するほかのトランザクションとの同時実行性能を優先したい場合

  • 更新を前提とする検索の結果,検索したレコード実現値に対する更新が不要となることがあり,そのレコード実現値を操作するほかのトランザクションとの同時実行性能を優先したい場合

《ほかのオペランドとの関連》

このオペランドの指定値を変更した場合,次に示すオペランドの指定値を見積もり直してください。

  • サーバ共通定義またはバックエンドサーバ定義のpd_lck_pool_sizeオペランド

《見積もり式への影響》

このオペランドの指定値を変更した場合,「3.8.2(1) レコードの検索(FETCH),または位置指示子の位置づけ(FIND)」の見積もり式を再計算してください。

(b) コマンド形式

subschema

subschema -s SDBデータベース名
        〔-t ルートレコードのレコード型名
        〔-e {shared|protected|exclusive}
          -a retrieve|update〕〕

UAPを実行してSDBデータベースにアクセスするときの動作オプションを指定します。

《オペランドの規則》

1つのSDB用UAP環境定義ファイルに,subschemaオペランドを最大1,600個指定できます。

-s SDBデータベース名

〜<識別子>((1〜30バイト))

subschemaオペランドで指定するオプションの対象とするSDBデータベースの名称を指定します。

《オペランドの規則》
  • SDBデータベース名の記述規則については,「11.4.1(1) 名前の規則」を参照してください。

  • subschemaオペランドを複数個指定する場合,同じSDBデータベース名は指定できません。

-t ルートレコードのレコード型名

〜<識別子>((1〜30バイト))

-sオプションに指定したSDBデータベースのルートレコードのレコード型名を指定します。

《オペランドの規則》
  • -eオプションおよび-aオプションを指定する場合に,-tオプションを指定してください。

  • ルートレコードのレコード型名の記述規則については,「11.4.1(1) 名前の規則」を参照してください。

-e {shared|protected|exclusive}

SD排他モードを指定します。

shared:

ほかのUAPからの参照および更新を許します。

protected:

ほかのUAPからの更新を許しません。

exclusive:

ほかのUAPからの参照および更新を許しません。

SD排他モード(-eオプション)の指定と,アクセス目的(-aオプション)の指定によって,ページに対する排他制御を行うかどうかと,次に示す排他資源に掛かる排他の排他制御モードが決まります。

  • ルートレコードのレコード型

  • レコード格納用RDエリア

排他制御モードの詳細については,「表2-38 排他制御のモードの組み合わせの例(SD FMBのSDBデータベースの場合)」を参照してください。

《利点》

SD排他モードとアクセス目的の組み合わせによって,UAPの目的に応じて排他の粒度と強さを制御できます。

また,SD排他モードとアクセス目的の組み合わせが次の場合,ページに対する排他制御を行いません。

  • SD排他モードがprotectedで,アクセス目的がretrieveの場合

  • SD排他モードがexclusiveで,アクセス目的がretrieveの場合

  • SD排他モードがexclusiveで,アクセス目的がupdateの場合

上記の組み合わせの場合,次の利点があります。

  • 排他資源数を削減できます。

  • 排他制御の処理時間を短縮できます。

  • ページのアクセス順序によって発生するデッドロックを回避できます。

《適用基準》

SD排他モードとアクセス目的の組み合わせ例を説明します。

オンライン業務の場合は,SD排他モードとアクセス目的を次のように指定します。

  • 参照業務の場合は,SD排他モードにsharedを,アクセス目的にretrieveを指定します。

  • 更新業務の場合は,SD排他モードにsharedを,アクセス目的にupdateを指定します。

バッチ業務の場合は,SD排他モードとアクセス目的を次のように指定します。

  • 参照業務で,参照オンライン業務からのアクセスだけを許す場合は,SD排他モードにprotectedを,アクセス目的にretrieveを指定します。

  • 更新業務で,ほかの業務からのアクセスを許さない場合は,SD排他モードにexclusiveを,アクセス目的にupdateを指定します。

《注意事項》

SD排他モードにexclusiveまたはprotectedを指定した場合,UAPの同時実行性が低下します。そのため,exclusiveまたはprotectedを指定する場合は,同時に実行できなくなっても問題となるUAPがないことを確認してください。

《ほかのオペランドとの関連》

-eオプションと-aオプションの指定値の組み合わせを変更したことによって,ページに対する排他制御が変わった場合,次に示すオペランドの指定値を見積もり直してください。

  • サーバ共通定義またはバックエンドサーバ定義のpd_lck_pool_sizeオペランド

《各見積もり式への影響》

-eオプションと-aオプションの指定値の組み合わせを変更したことによって,ページに対する排他制御が変わった場合,「3.8.2 SDBデータベースを操作するAPIまたはDMLの実行時の排他資源数」の見積もり式を再計算してください。

-a retrieve|update

アクセス目的を指定します。

retrieve:

レコードの参照だけを行います。次のDMLを実行するとエラーになります。

  • FETCH(FOR UPDATEオペランドの指定あり)

  • FIND(FOR UPDATEオペランドの指定あり)

  • STORE

  • MODIFY

  • ERASE

update:

レコードの参照および更新を行います。

SD排他モード(-eオプション)の指定と,アクセス目的(-aオプション)の指定によって,ページに対する排他制御を行うかどうかと,次に示す排他資源に掛かる排他の排他制御モードが決まります。

  • ルートレコードのレコード型

  • レコード格納用RD エリア

排他制御モードの詳細については,「表2-38 排他制御のモードの組み合わせの例(SD FMBのSDBデータベースの場合)」を参照してください。

なお,次の項目については,-eオプションの説明を参照してください。

  • 利点

  • 適用基準

  • ほかのオペランドとの関連

  • 各見積もり式への影響