Hitachi

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


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

〈この項の構成〉

(1) オペランドの形式

■set形式

〔set lockrange = transaction|cursorupdate〕

■コマンド形式

〔{{subschema -s SDBデータベース名
              〔-t ルートレコードのレコード型名
              〔-e {shared|protected|exclusive|nonprotected}
                -a retrieve|update〕〕
              〔-p occupyroot|shareroot〕
              〔-r レコード格納用RDエリア名
                   〔,レコード格納用RDエリア名〕…〕
  }}〕

(2) オペランドの説明

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

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

(a) set形式

lockrange = transaction|cursorupdate

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

transaction:

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

cursorupdate:

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

《利点》

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

《適用基準》

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

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

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

《注意事項》

cursorupdateを指定した場合,子レコードのレコード型内検索を実行できません。

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

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

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

《見積もり式への影響》

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

(b) コマンド形式

subschema

subschema -s SDBデータベース名
        〔-t ルートレコードのレコード型名
        〔-e {shared|protected|exclusive|nonprotected}
          -a retrieve|update〕〕
        〔-p occupyroot|shareroot〕
        〔-r レコード格納用RDエリア名〔,レコード格納用RDエリア名〕…〕

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|nonprotected}

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

shared:

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

protected:

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

exclusive:

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

nonprotected:

ほかのUAPからの参照および更新を許します(ページ(サブページ分割をする場合はサブページ)に対する排他制御を行いません)。

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

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

  • ルートレコードのレコード型(NOWAIT検索時)

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

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

《オペランドの規則》

SD排他モードにnonprotectedを指定する場合は,アクセス目的にretrieveを指定してください。

《利点》

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

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

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

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

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

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

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

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

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

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

《適用基準》

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

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

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

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

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

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

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

オンラインの参照業務の同時実行性を向上させたり,デッドロックを回避したりするために,無排他検索機能(SD排他モードがnonprotectedで,アクセス目的が retrieve)を選択することもできます。無排他検索機能の適用基準については,「2.9.8 SDB用UAP環境定義の指定による無排他検索機能【SD FMB】」を参照してください。

《注意事項》

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オプション)の指定によって,ページに対する排他制御を行うかどうかと,次に示す排他資源に掛かる排他の排他制御モードが決まります。

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

  • ルートレコードのレコード型(NOWAIT検索時)

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

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

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

  • 利点

  • 適用基準

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

  • 各見積もり式への影響

-p occupyroot|shareroot

SDBデータベースの階層数が2以上のSDBデータベースに対して,ルートレコード検索時の,ルートレコード格納ページの排他制御方式を指定します。

occupyroot:

ルートレコード格納ページに,排他制御モードEXで排他制御を行います。

shareroot:

ルートレコード格納ページに,排他制御モードSRまたはPUで排他制御を行います(SDBデータベースの階層数が1のSDBデータベースのときと同じ排他制御モードで,排他制御を行います)。

排他制御モードの詳細については,「表2-37 排他制御のモードの組み合わせの例(SD FMBのSDBデータベースの場合)」を参照してください。このオプションは,SD排他モードとアクセス目的の組み合わせがshared updateまたはprotected updateの場合に有効となります。

《利点》

デフォルト値では,複数のUAPから同一ファミリを検索すると,後続のUAPが排他待ちとなります。

-pオプションにsharerootを指定すると,後続のUAPが排他待ちすることなく,同一ファミリを検索できるようになります。

ただし,-pオプションにsharerootを指定しても,DMLにFOR UPDATEを指定したUAP同士を同時実行した場合は,複数のUAPから同一レコードを同時に更新することを抑止するため,後続のUAPが排他待ちをします。

《適用基準》

通常は-pオプションにoccupyroot(省略値)を指定してください。

UAPの運用上,ルートレコード格納ページの排他待ちが問題となる場合は,-pオプションにsharerootを指定することを検討してください。

-pオプションにsharerootを指定すると,複数のUAPから同時に子レコードにアクセスできるようになります。

そのため,次に該当するようなSDBデータベースの操作をしない,またはその操作の際のデッドロックを許容できることを確認してください。

  • 子レコードを対象に,レコードの更新(MODIFY),レコードの格納(STORE),またはレコードの削除(ERASE)を実行する。

  • 複数のUAP間で,ファミリ内の子レコードのアクセス順序を統一していない。

子レコードを対象に,レコードの更新(MODIFY),レコードの格納(STORE),またはレコードの削除(ERASE)を実行する場合は,レコードのアクセス順序を統一していても,デッドロックが発生することがあります。デッドロックの例については,「2.9.9(4) ルートレコードを格納しているページと子レコードを格納しているページ間のデッドロックの例【4V FMB,SD FMB】」を参照してください。

最終的に,業務の際には,同時実行性能向上とデッドロック防止のどちらを優先するか判断した上で,-pオプションの指定値を決定してください。

《注意事項》

-pオプションにsharerootを指定した場合,子レコードのレコード型内検索を実行できません。

《備考》

-pオプションにoccupyrootを指定しているときに,ルートレコード格納ページに,排他制御モードEXで排他制御を行うのは,子レコード更新時のデッドロックを防止するためです。

次のどちらかの場合は,-pオプションの指定に関係なく,ルートレコード格納ページに,排他制御モードSRまたはPUで排他制御を行います。

  • SDBデータベースの階層数が1のSDBデータベースの場合

  • アクセス目的がretrieveの場合

-r レコード格納用RDエリア名〔,レコード格納用RDエリア名〕…

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

横分割しているSDBデータベースに対して,アクセスするRDエリアを限定したい場合,レコード格納用RDエリア名を指定します。

subschemaオペランド,または-rオプションを省略すると,SDBデータベースを格納しているすべてのRDエリアをアクセス対象として排他制御を行います。

横分割していないSDBデータベースに-rオプションを指定した場合,エラーとなります。

《利点》

DMLを実行する際,記述されたレコード格納用RDエリアだけをアクセス対象として排他制御を行います。

バッチ業務(SD排他モードにexclusvieを指定)の場合,-rオプションを省略すると,SDBデータベースを格納しているすべてのRDエリアに排他制御モードEXで排他制御を行います。このため,そのSDBデータベースをほかの業務からアクセスできません。

-rオプションを指定して,アクセスするRDエリアを限定すると,-rオプションに記述していないレコード格納用RDエリアの排他制御を行わないので,ほかの業務からアクセスできます。

《オペランドの規則》
  • レコード格納用RDエリア名の記述規則については,「11.4.1(1) 名前の規則」を参照してください。

  • レコード格納用RDエリア名を複数記述する場合,重複したレコード格納用RDエリア名は指定できません。

  • 最大1,024個のレコード格納用RDエリア名を指定できます。

《留意事項》
  • -rオプションを指定した環境で,レコードの格納(STORE)を実行する場合,該当するRDエリアを指定していないと,エラーとなります。

  • -rオプションを指定した環境で,レコードの検索(FETCH)または位置指示子の位置づけ(FIND)を実行する場合,キーの条件に該当するRDエリアを指定していないと,NOT FOUNDとなります。NOT FOUNDの例については,次の図を参照してください。

    図9‒1 NOT FOUNDの例

    [図データ]

[説明]

SDBデータベース格納定義では,3つのRDエリアに境界値分割しています。

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

    ルートレコードのデータベースキー100以下のレコードを格納

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

    ルートレコードのデータベースキー101〜200のレコードを格納

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

    ルートレコードのデータベースキー201以上のレコードを格納

SDB用UAP環境定義では,-rオプションに,レコード格納用RDエリア1と2を指定しています。

レコードの検索(FETCH)のキーの条件に,「ルートレコードのデータベースキーが250より大きい」を指定して実行すると,該当するRDエリアがないので,NOT FOUNDとなります。