DISABLE

DISABLEは、MUPIP SETの-NOJOURNAL修飾子に相当する機能です。ジャーナリングは、名前のある領域(Region)またはファイルのオプションではないものを指定します。もしDISABLEが指定された場合、他のオプションはjournal-option-listで許可されます。

ENABLE

ENABLEは、データベースファイルまたは領域がジャーナリングで利用できることを、指定します。デフォルトでは、、もしOFFが同じオプションをリストで指定されない限りは、ENABLEの指定もまたジャーナリングONになり、BEFORE_IMAGESまたはNOBEFORE_IMAGESもまた指定する必要があります。

OFF

OFFは、GT.Mが記録を停止し、引き続き、ジャーナルファイルの中でデータベースへの更新を停止することを、指定します。OFFもまた、ジャーナルファイル、または、ジャーナリングの開始を作成せずに、ジャーナリング特性を確立するために使用されることがあります。データベースがSET -JOURNAL=OFF をされている時には、それはジャーナル特性をONにする準備が確立さているが、GT.Mは、そのファイルへジャーナル更新を書き込みません。

	デフォルトは SET -JOURNAL= は ON です。

ON

ONは、新しいジャーナルファイルを作成するようにMUPIPへ指示し、そして、そのジャーナルファイル内で後続してデータベースの更新を記録するようにGT.Mに指示します。SET -JOURNAL=ONは、journal-option-listに付属するBEFORE_IMAGESまたはNOBEFORE_IMAGESのどちらか一方を含める必要があります。

すでにENABLE'dなジャーナリングでファイルまたは領域だけをONに指定できます。または、ENABLEが同じ時間で指定されるならば、ONに指定できます。もしジャーナリングがデータベースの現在のDISABLE'dならば、ONは無視されます。

例：

MUPIP SET -JOURNAL=
"ON,BEFORE_IMAGES
"
-REGION "*"

このコマンドは、すでにENABLE'dなジャーナリングを使用して、領域でのみジャーナルを変化させます。

	デフォルトは SET -JOURNAL= は ON です。

ALI[GNSIZE]=blocks

ALIGNSIZE=blocksは 512バイトブロック数で指定します。これはジャーナルファイルのアライメントサイズです。

ジャーナルファイルが、いろいろなサイズのそれぞれのジャーナルレコードのシーケンシャルストリームから成り立ってから、異常終了したジャーナルファイル（例えば、システムクラッシュ）で、最後の有効なジャーナルレコードの始まりを検出するため、通常はそれは容易ではない。このような状況でジャーナルリカバリーを促進するには、（ジャーナルファイルヘッダを収容するオフセット0を除いた）ALIGNSIZEが複数あるジャーナルファイル内のオフセットは、いつも有効なジャーナルレコードの始まりになることを、GT.Mのランタイムシステムは確実にします。これを保証するために、GT.Mランタイムシステムは、ALIGNSIZE境界の直前にALIGNジャーナルレコードの形式でパディング・データを（必要に応じて）書き込みます。これらALIGNレコードもまた、可能な限り破損ジャーナルファイルの多くのデータを抽出するために、MUPIP JOURNAL -EXTRACT -FORWARD -FULL を可能にしつつジャーナルファイルの中央に過去の不正なレコードをスキップするのに役立ちます。

もし指定されたALIGNSIZEが2のべき乗で無いなら、2のべき乗の近似値に切り上げます。

デフォルトALIGNSIZE値は128ブロック（= 64KB）、最小値は32ブロック（= 16KB）です。最大値は4194304（= 2GB）です。

	サポートされている最小ALIGNSIZEは、最大のデータベースブロックサイズに順番に依存している、最大のジャーナルレコードサイズより、常に大きいか等しい。

ALIGNSIZEの大きな値が、回復のために使用するより小さい整列境界を暗示し、したがって、4194304の値がバックワードリカバリ（クラッシュの場合）の原因となるそのジャーナルファイル上でフォワードリカバリと同じくらい多くの時間がかかるほどバックワードリカバリは極端に遅くなることに、注意してください。

ALL[OCATION]=blocks

GT.Mが最初にジャーナルファイル用に利用可能なディスク領域を確認する時、ALLOCATION=blocksを指定します。作成時のジャーナルファイルのサイズは不変ですが、（GT.Mのバージョンに依存）、しかし、一度ジャーナルファイルがALLOCATIONで指定されたサイズに達すると、すべての拡張は、ジャーナルファイルを使用するデバイスの上で利用可能なフリースペースのチェックを引き起こします。

利用可能な空きスペースが拡大サイズより多くないときはいつも、GT.Mはシステムログへの情報メッセージを発行します。GT.Mは、スペースがなくなる前に、ジャーナル・ファイルを保持しているファイル・システムの容量が少ないことを識別するための操作補助として、これらの拡張の検査を提供します。ジャーナル・ファイルを保持しているファイル・システム上に使用可能な空き領域がなくなると、GT.Mは対応するデータベース・ファイルのジャーナリングを停止します。

デフォルトのALLOCATION 値は100ブロックです。許される最小値は10です。最大値は8,388,607（4GB-512バイト、最大ジャーナル・ファイル・サイズ）です。

AU[TOSWITCHLIMIT]=blocks

AUTOSWITCHLIMIT=blocksはジャーナルファイルのサイズを制限を512バイトのブロックに指定します。ジャーナルファイルのサイズが制限に達すると、GT.Mは自動的に新しいジャーナルファイルへ暗黙的にオンラインスイッチを実行します。

	AUTOSWITCHLIMITをファイルシステムの最大ファイルサイズ（ブロック単位）よりも大きな値に設定することは可能です。現在、GT.Mは指定時刻にこの条件をチェックしようとしません。ファイルシステムのサイズの最大に達した時、これは深刻なランタイムエラーが発生することがあります。したがって、AUTOSWITCHLIMITがファイルシステムの制限を超えないようにしてください。

AUTOSWITCHLIMITのデフォルト値は、8388600 & 最大値8388607ブロック（4GB-512バイト）です。AUTOSWITCHLIMITのための最小値は2048です。（ それぞれ16KBの境界で区切られた64個のALIGNSIZEが持つために必要なブロック数、それが最小のALIGNSIZEです）場合は、AUTOSWITCHLIMITの値が割当と拡張値の合計よりも小さい場合は、エラーが発行されます。もしAUTOSWITCHLIMITとアロケーション値との差が、拡張する値の倍数でない場合は、MUPIPは、拡張する値の倍数になるように値を切り捨てます。この効果の情報メッセージが発行されます。万が一、AUTOSWITCHLIMITの丸め値が最小値より小さい場合、エラーが発行されます。

[NO]BEFORE_IMAGES

更新について変更することがあるGDSブロックのBEFORE_IMAGESをジャーナルがキャプチャすべきかどうかでなく、[NO]BE[FORE_IMAGES] はコントロールします。SET -JOURNAL=ONは、journal-option-listに付属するBEFORE_IMAGESまたはNOBEFORE_IMAGESのどちらか一方を含める必要があります。

	NOBEFORE_IMAGESとBEFORE_IMAGESの両方が、同じjournal-option-listで指定されるならば、これらの仕様の最後は任意の一つ前をオーバーライドします。

BEFORE_IMAGESジャーナルは、データベースに関連付けられたロールバックリカバリ（つまり、バックワードリカバリー）を実行するオプションを提供します。BEFORE_IMAGESはI/OとCPUリソースの負荷が増加し、それゆえパフォーマンスに影響を与えるでしょう。

	新しいジャーナルファイルはONオプションで作成されて以来、そして、ON仕様のすべてがBEFORE_IMAGESまたはNOBEFORE_IMAGESのいづれかを含む必要がある以来、OFFオプションと共に指定する[NO]BEFORE_IMAGESは、BEFORE_IMAGESオプションの値を確立し、そのオプションは常に、ONオプション仕様の後によってオーバーライドを取得します。

ただし、NOBEFORE-IMAGE ジャーナリングから(へ) BEFORE-IMAGEジャーナリングへ(から)データベースのオンラインスイッチを実行することが可能ですが、もしBEFORE-IMAGESのないデータベースのためにジャーナルファイルセットの1つでも遭遇するならば、逆方向のリカバリーが決して成功しないことを理解することが重要です。

BU[FFER_SIZE]=blocks

BUFFER_SIZE=blocksは、512バイトのブロックで、ジャーナルファイルに出力するバッファのために使用するメモリの量を指定します。

MUPIPは、実際にBUFFER_SIZEを変更するために、データベースへスタンドアロンのアクセスが必要です。したがって、このオプションは、ジャーナルファイルのオンラインスイッチの一部として、現在のjournal-buffer-sizeを変更するために使用することはできません。

最小のBUFFER_SIZE は、1個のGDSデータベースブロックを保持するために必要な512バイトブロックの数より大きい１個です。最大2000ブロックです。デフォルト値は128ブロックです。

EP[OCH_INTERVAL]=seconds

EPOCH_INTERVAL=seconds は、2つの連続するEPOCHsの間の経過時間の間隔を指定します。EPOCHはチェックポイントで、データベースファイルに対するすべての更新がディスクにコミットされます。

より小さなEPOCH_INTERVALは、（より頻繁なチェックポイントのために）ラン・タイム・システム上のI/O負荷の増加のコストに対して、クラッシュ後の回復時間を短縮します。より大きなEPOCH_INTERVALは逆の効果を持ちます。

デフォルトのEPOCH_INTERVAL値は300秒（5分）です。最小値は1秒です。最大値は32,767秒（32K未満）、つまり約9.1時間です。

EX[TENSION]=blocks

ファイルが満杯にになるとひろげる時に、EXTENSION=blocksは拡張を実行されるジャーナルファイルのサイズを指定します。

EXTENSION=blocksは、ALLOCATIONが使用されていた後にGT.Mがジャーナルファイルのために利用可能なディスク領域を再調査すべき時に指定します。また、各再調査時で利用できるスペースの量も指定します。

UNIXのファイルシステムが怠惰なアロケーションスキームを使う理由から、ジャーナルファイルの物理ディスクのブロックアロケーションの中で、割り当てと拡張の値の結果はありません。

もしジャーナルデータの価値ある拡張を保持するのに十分な空き領域があるならば、見えているファイルシステム上でチェックが完了された時に、値が決定されます。ジャーナルファイルが、ALLOCATIONとEXTENSIONの任意の倍数との合計により指定されたサイズに達する時には、GT.Mはファイルシステムの余裕をチェックし、そして、もし使用可能な領域がEXTENSIONの3倍より少ないならば、オペレータログに警告を書き込みます。GT.Mは、スペースがなくなる前に、ジャーナル・ファイルを保持しているファイル・システムの容量が少ないことを識別するための操作補助として、これらの拡張の検査を提供します。ジャーナル・ファイルを保持しているファイル・システム上に使用可能な空き領域がなくなると、GT.Mは対応するデータベース・ファイルのジャーナリングを停止します。

デフォルトのEXTENSION 値は100ブロックです。最小EXTENSIONは、 0（ゼロ）ブロックで、最大値は65,535ブロックです（64K未満の）。

F[ILENAME]=journal filename

F[ILENAME]=journal filenameは、ジャーナルファイルの名前を指定します。もし複数の領域が指定されたならば、FILENAMEは、SET -REGIONSETとは両立しません。

次の説明は注意してください。ファイル名を2つのコンポーネント、ベース名.拡張子(basename.extension)に分けられ、どこに拡張子が任意のピリオド(.)が含まれていないかを、しかし、もしファイル名が複数のピリオド(.)が含むならば、ベース名はすべてがしかし最後のピリオド(.)も含みます。また、これらも注意してください。ファイル名にピリオド(.)が含んでないならば、"拡張子"は空の文字列("")です。

journal-optionのデフォルト値は、次の習慣に基づいています：

もしデータベースが dat 拡張子を持つならば、データベースファイル名のベース名は、mjlの拡張子でジャーナルファイルのためのベース名として解釈されます。たとえば、データベース名mumps.datの場合は、デフォルト名はm​​umps.mjlになります。もしデータベースファイル名が dat拡張子を持たないならば、完全なデータベースファイル名は、mjl 拡張子を持ち、アンダースコア(_)を持ち、ピリオド(.)の発生するすべてに置換されます。たとえば、データベース名mumps.acnの場合は、デフォルト名はm​​umps_acn.mjlになります。

したがって、ジャーナルファイルは常に mjl拡張子を持ちます。新しいジャーナルファイル名が既に存在するならば（ FILENAMEオプションまたはデフォルトで指定された１つ）、既存のファイルは既存のファイル拡張子を付加した文字列 "_YYYYJJJHHMMSS" にリネームされ、その文字列が既存のジャーナルファイルが作られた時を示します。以下がそのフォーマットです：

YYYY           4-digit-year                                    such as 2001
JJ             3-digit-Julian-day (between 1 and 366)          such as 199
HH             2-digit-hour in 24 hr format                    such as 14
MM             2-digit minute                                  such as 40
SS             2-digit seconds                                 such as 30

文字列の値を上記の例と仮定すると、ジャーナルファイルmumps.mjl は、mumps.mjl_2001199144030 にリネームされるかもしれません。

もしGT.Mが名前を変更するロジックにより既に存在するファイル名を産生しようとすることを検出するならば、文字列 "_N[N[N[N...]]]" に名前を変更した数字のシーケンスを示す"N[N[N...]]"をファイル名に追加されます。

0,1,2,3,4,5,6,7,8,9,90,91,92,93,94,95,96,97,98,99,990,991,...

上記のようなシーケンスによる番号で、存在しない名前に変更するファイル名の文字列が見つかるまで順番に試行されます。

上記と同じ例では、mumps.mjl_2001199144030 と mumps.mjl_2001119144030_0 が既に存在する場合、名前が変更される文字列は、mumps.mjl_2001199144030_1 です。

上記で説明されているように、もし既存しているファイルの名前変更のスキーム、または、デフォルトのジャーナルファイルの命名スキームが、255文字より長いファイル名の結果を生じる場合（接尾語を作成するルールのために）、GT.MはエラーとジャーナリングのOFFを発行します（および、もしレプリケーションがアクティブなら、レプリケーションもOFFを発行します）。

ジャーナルリカバリーの目的のために、フィールドはすべてのジャーナルファイルヘッダの中で保持されます。そのヘッダは同じデータベースファイルのために前世代のジャーナルファイルの名前を格納します。MUPIP SETがジャーナル状態をDISABLEDまたはOFFからONに変更すると、GT.Mは以前の世代のジャーナル・ファイル名の無い新しいジャーナルファイルを作成します。これは、特定のデータベースの新しいジャーナリングの開始であることを示します。既にジャーナリングがONの時、およびGT.Mが暗黙的に（AUTOSWITCHLIMITに到達したために）または明示的に（MUPIP SET JOURNALMUPIPのために）新しいジャーナルファイルを作成する必要とされる時は、GT.Mは、新しいジャーナルファイルのヘッダの中で、前世代のジャーナルファイル名を保持します（いくつかの適切なリネーム後に）。

ジャーナルファイルスイッチの前後のどこでジャーナリングがONになろうと、前世代のジャーナルファイル名は新しいジャーナルファイルのヘッダの中で保持されます。以下の場合のように、どこでクリアされているかを除いて：

以前の世代のジャーナル・ファイル名は、現在の世代のジャーナルからのバック・リンクです。

もし、FILENAMEがMUPIP SET -JOURNALコマンドで指定され明示的にあるならば、そして、指定されたFILENAMEが既存のファイルと一致するならば、（既存のファイルとは、指定されたデータベースの現在アクティブなジャーナルファイルでは無く、データベースが現在ENABLEDかつONとなっているジャーナリングを持つこと）、GT.Mはエラーステータスを返し、そして、データベースのジャーナリングステータスには変更を加えません。これはback-links(バックリンク)で可能なサイクルを避けるためにします（例えば、a3.mjlはa2.mjlへバックリンクを持ち、戻ってへa1.mjlにバックリンクを持ち、さらに戻ってa3.mjlへバックリンクを持ちます。これによりサイクルを作成します）。サイクルがジャーナル回復を妨げる可能性があります。データベースからまたはデフォルトのFILENAMEを使用によって、明示的なFILENAME仕様のために、そして、既存のファイル名の特徴を決して拾得しないために、バックリンクの中のサイクルが可能であることも注意してください。

[NO]S[YNC_IO]

SYNC_IOの仕様では、ディスクへ直接コミットされるジャーナルファイルをすべて書き込みことが発生します。ハイエンドなディスクサブシステム上では、（例えば、それがこのキャッシュに到達する時に、不揮発性キャッシュを含み、そして、コミットされたデータとみなすシステム）、NOSYNC_IOオプションよりもパフォーマンスが向上する可能性があります。

デフォルトのオプションは、NOSYNC_IOです。

	NOSYNC_IO と SYNC_IOの両方が、同じjournal-option-list（可能なら複数回）で指定されるならば、これらの仕様の最後は任意の一つ前をオーバーライドします。

Y[IELD_LIMIT]=yieldcount

そのタイムスライスをディスクのyieldsへジャーナルバッファの内容をフラッシュしようと試み、、同時にアクティブなプロセスによっていっぱいになる追加のジャーナルバッファの内容のために待ち、最適なI/O操作をより少なく開始する前に、YIELD_LIMIT = yieldcount はプロセスの回数を指定します。

以来、ディスクコントローラ上の書き込みヘッド(write head)は、データのブロック全体を書き込みのみできることから、書き込まれるデータがブロック全体にシンプルに書かれたこととは反対に部分的にブロックがある時に、多くのI/OサブシステムはREAD-MODIFY-WRITE 操作を実行します。YIELD_LIMIT 修飾子は、可能な限り多く書き込むことを延期しようとして、最適以下な部分的な書き込みブロックをしばしば削減しようl試み、一方で、ジャーナルバッファはより多くの内容を蓄積し書き込みブロック全体を最適に修飾するでしょう。

軽い負荷状態には小さいYIELD_LIMITが適していますが、負荷が増加するにつれて大きな値が適切です。

	一方、大規模なYIELD_LIMIT（多くの生産性ため）は、重要なアイドル時間のためにパフォーマンスが低下する原因があるでしょう。小さなYIELD_LIMITは、部分的なページ書き込みのためパフォーマンスが低下する原因があるでしょう。

最小のYIELD_LIMITは 0（ゼロ）で、最大のYIELD_LIMITは 2048 で、デフォルトYIELD_LIMITは8です。