Hitachi

JP1 Version 12　JP1/Automatic Job Management System 3 設計ガイド（システム構築編）

付録F.1　データベースのバックアップの概要

JP1/AJS3のデータベース（組み込みDB）は，障害に備えてすべてのテーブルを対象にバックアップファイルを取得できます。スケジューラーデータベースに障害が発生した場合は，このバックアップファイルを使用することでバックアップファイル取得時点の状態に回復できます。

また，組み込みDBは，スケジューラーデータベースの更新履歴情報を持つシステムログファイルを作成します。このシステムログファイルの情報とバックアップファイルを使用することで，スケジューラーデータベースの内容を最新の状態に回復できます。

バックアップファイルの取得方法，および回復方法は運用方法によって異なります。運用方法ごとのバックアップファイルの取得方法および回復方法について次に示します。

運用方法の詳細については，マニュアル「JP1/Automatic Job Management System 3 構築ガイド　23.1.1 組み込みDB稼働環境と運用方法の検討」を参照してください。

バックアップ強化機能の概要については，「5.2.1(5) データベース（組み込みDB）のバックアップとリカバリー」を参照してください。

この項では，アンロードログ運用およびシステムログを使用しない運用について説明します。

〈この項の構成〉

(1)　アンロードログ運用

組み込みDBが自動的に取得するアンロードログファイルと，スケジューラーデータベースのバックアップファイルを使用して回復するアンロードログ運用について説明します。

アンロードログ運用での障害発生時の回復方法を次の図に示します。

図F‒1　障害発生時の回復方法（アンロードログ運用）

[図データ]

(a)　システムファイルの二重化について検討する

組み込みDBで使用するシステムファイルを二重化しない構成では，システムファイルに障害が発生すると組み込みDBは停止してしまいます。

システムファイルを二重化すると，片方のシステムファイルにディスク障害などが発生しても，ディスク障害時に障害時点まで復旧できます。ただし，システムファイルの容量は，二重化しない構成と比較すると増加します。

(b)　アンロードログファイルについて

■ 自動ログアンロード機能

組み込みDBは，次のどれかのタイミングで，使用できるシステムログファイルに出力先を切り替えます。

  • 使用中のシステムログファイルが満杯になった場合

  • ajsembdbbackupコマンドを実行した場合

  • ajsembdboplogコマンドに-wを指定して実行した場合

  • 組み込みDBを再起動した場合（前回の停止が正常停止している場合だけ）

今まで使用していたシステムログファイルは，アンロード待ち状態※1となり，この状態では，使用できるシステムログファイルとして，再度割り当てられません。このアンロード待ち状態のシステムログファイルを使用できる状態にするには，アンロード※2をする必要があります。組み込みDBは，このアンロード待ち状態のシステムログファイルを，指定されたディレクトリに自動でアンロードします。このアンロードして作成したファイルをアンロードログファイルと呼び，この自動的にアンロードする機能を自動ログアンロード機能と呼びます。回復時は，このアンロードログファイルをバックアップファイルとともに使用します。

注※1

回復に必要な更新履歴情報が格納されていて上書きできない状態です。この状態では，使用できるシステムログファイルとして再度割り当てられません。再度使用できる状態にするためには，アンロードをする必要があります。

注※2

システムログファイルの内容を退避することをいいます。

■ アンロードログファイルのサイズ

アンロードログファイルのサイズは，組み込みDB環境の構築時に指定した規模によって異なります。指定した規模の違いによる，1個当たりのアンロードログファイルのサイズを次の表に示します。保存するアンロードログファイルの容量を見積もる場合には，この表の値を参考にして，アンロードログファイルを格納するための必要な容量を事前に見積もってください。

表F‒1　出力されるアンロードログファイルのサイズ

組み込みDB環境の構築時に指定した規模

アンロードログファイル1個のサイズ

大規模

約1,200メガバイト

中規模

約230メガバイト

小規模

約30メガバイト

ajsembdbaddlogコマンドで，システムログファイルを拡張している場合は，ajsembdbaddlogコマンドの-sオプションに指定したサイズと，表F-1に示すサイズを比較して，大きい方のサイズがアンロードログファイルの最大サイズになります。また，システムログ自動増分機能を使用することでシステムログファイルが拡張される場合は，最大で表F-1に示すサイズの3倍になります。

このため，アンロードログファイルの容量は大きい方の値で見積もってください。

なお，出力されるアンロードログファイルのサイズは，出力されるタイミングによって異なる場合があります。

■ アンロードログファイル作成ディレクトリを含むディスクが満杯になる時期の目安

アンロードログファイルは，削除またはほかのディスクに移動しないかぎり，アンロードログファイル作成ディレクトリに作成され続けます。そのため，JP1/AJS3の運用を続けることで，アンロードログファイルが増加し，アンロードログファイル作成ディレクトリを含むディスクが満杯になります。ディスクが満杯になると自動ログアンロード機能が停止し，「自動ログアンロード機能が停止することによる問題」に示す問題が発生します。

このようなことから，ディスクが満杯になる時期を事前に見積もり，満杯になる前にバックアップファイルを取得して，バックアップファイル取得時点より前に作成されたアンロードログファイルを削除するか，ほかのディスクに移動する必要があります。バックアップファイルの取得ができない状況であれば，一時的にほかのディスクにアンロードログファイルを移動して，アンロードログファイル作成ディレクトリを含むディスクの空き容量を確保してください。アンロードログファイルの削除および移動方法については，マニュアル「JP1/Automatic Job Management System 3 運用ガイド　付録B.2(3) バックアップファイルおよびアンロードログファイルの管理」を参照してください。

ここでは，アンロードログファイル作成ディレクトリを含むディスクが満杯になる時期を見積もる方法について説明します。

1個のシステムログファイルに出力できる情報量の目安を次の表に示します。

表F‒2　1個のシステムログファイルに出力できる情報量

組み込みDB環境の構築時に指定した規模

1日当たりのジョブまたはジョブネットの実行数

大規模

約50,000

中規模

約9,600

小規模

約1,200
注

この数値はジョブやジョブネットに対する操作や，ユニットの新規作成・定義変更・削除などの回数によって変動するため，運用に合わせて見積もり値を変更する必要があります。

表F-1に示した1個当たりのアンロードログファイルサイズと，上記で示した数値を参考に，運用開始してから何日後にディスクが満杯になるかを見積もれます。

見積もり例を次に示します。

環境

組み込みDB環境規模：大規模

アンロードログファイル作成ディレクトリ：10ギガバイト

計算式

10ギガバイト / 1,200メガバイト = 8日

以上の条件では，運用を開始してから最短で約8日目の運用終了時に，ディスクが満杯になることが予想できます。

■ 自動ログアンロード機能が停止することによる問題

自動ログアンロード機能が停止すると，組み込みDBはシステムログファイルのアンロードを実行しません。アンロードをしないと，アンロード待ち状態のシステムログファイルが増加し，出力先のシステムログファイルを変更するタイミングで，使用できるシステムログファイルがないと組み込みDBは異常終了します。

自動ログアンロード機能が停止する要因については，表F-3を参照してください。

■ 自動ログアンロード機能の稼働状態の監視方法

自動ログアンロード機能が停止すると，「自動ログアンロード機能が停止することによる問題」に示した問題が発生するため，自動ログアンロード機能の稼働状態を，定期的に監視する必要があります。

自動ログアンロード機能の稼働状態を監視する方法は，次に示す2とおりの方法があります。

メッセージによる監視方法

自動ログアンロード機能が停止すると，メッセージKFPS01150-EがWindowsイベントログ（UNIXの場合はsyslog）に出力されます。このメッセージKFPS01150-Eの出力状態を監視して，自動ログアンロード機能の稼働状態を確認してください。

コマンドによる監視方法

自動ログアンロード機能の稼働状態は，ajsembdboplogコマンドに-sオプションを指定して実行することで確認できます。_JF0の組み込みDB識別子でセットアップした環境がすでに構築されている場合のajsembdboplogコマンドの実行例を次に示します。 

ajsembdboplog -s -id _JF0
 
HOSTNAME : host_name (180252)
SERVER_NAME:ajs2
AUTO_LOG_UNLOAD  NOW_UNLOAD_LOG_GROUP  CREATE_DIR
         ACTIVE                  ****  K:/logback
CURRENT LOG GENERATION INFO.
LOG_GROUP GEN_NO.  SERVER_RUN_ID RUN_ID   UNLOAD_FILE_NAME
     log1        1 43c4ad0d      43c4acf3 ajs2_43c4ad0d0001_log1

実行結果のうちAUTO_LOG_UNLOADに表示されている文字列（下線部分）が自動ログアンロード機能の稼働状態を示す情報です。表示内容が「ACTIVE」であれば自動ログアンロード機能は稼働しています。表示内容が「STOP」の場合，自動ログアンロード機能は停止しています。

自動ログアンロード機能が停止していると判断できた場合は，表F-3に示す対策を実施したあとで，ajsembdboplogコマンドに-rオプションを指定して実行してください。実行例を次に示します。

ajsembdboplog -r -id _JF0

このコマンドを実行すると，自動ログアンロード機能が開始されます。

■ 自動ログアンロード機能が停止する要因と対策

自動ログアンロード機能が停止する要因と，停止した場合の対処方法を次の表に示します。

表F‒3　自動ログアンロード機能が停止する要因と対処

停止要因

対策方法

アンロードログファイル作成ディレクトリを含むディスクに障害が発生した

アンロードログファイルがなくなるおそれがあるため，組み込みDBのバックアップファイルを取得してください。障害が発生したディスクを回復させたあと，ajsembdboplogコマンドに-rオプションを指定して実行してください。実行例を次に示します。

ajsembdboplog -r

このコマンドを実行すると，自動ログアンロード機能が開始されます。

アンロードログファイル作成ディレクトリを含むディスクの容量が満杯になった

ディスクが満杯になった場合の対処方法については，マニュアル「JP1/Automatic Job Management System 3 運用ガイド　付録B.2(3) バックアップファイルおよびアンロードログファイルの管理」を参照してください。そのあと，ajsembdboplogコマンドに-rオプションを指定して実行してください。実行例を次に示します。

ajsembdboplog -r

このコマンドを実行すると，自動ログアンロード機能が開始されます。

次のどちらかの要因でアンロードログファイル作成ディレクトリが使用できなくなった

・権限不正

・ディレクトリが存在しない

障害原因を取り除いたあと，ajsembdboplogコマンドに-rオプションを指定して実行してください。実行例を次に示します。

ajsembdboplog -r

このコマンドを実行すると，自動ログアンロード機能が開始されます。

ajsembdboplogコマンドに-tオプションを指定して実行した

ajsembdboplogコマンドに-rオプションを指定して実行してください。実行例を次に示します。

ajsembdboplog -r

このコマンドを実行すると，自動ログアンロード機能が開始されます。

■ 使用できるシステムログファイルがなくなったことが原因で組み込みDBが異常終了した場合の回復方法

使用できるシステムログファイルがなくなり，組み込みDBが異常終了した場合の対処方法を次に示します。

  1. 該当するスケジューラーデータベースを使用するスケジューラーサービス，およびスケジューラーデータベースにアクセスするサービスをすべて停止する。

  2. システムログのアンロードを実行する。

    ajsembdboplogコマンドを実行して，アンロード待ち状態のシステムログファイルをアンロードしてください。アンロードの際，出力される1個当たりのアンロードログファイルのサイズについては，表F-1を参照してください。

  3. 組み込みDBを起動する。

    ajsembdbstartコマンドを実行して，組み込みDBを起動してください。OS，または組み込みDBの状態によって実行方法が異なります。

    • Windowsの場合

      ajsembdbstartコマンドの実行時，-idオプション以外のオプションは指定しないで実行してください。

    • UNIXの場合

      組み込みDBの状態によって，ajsembdbstartコマンドの実行方法が異なります。組み込みDBの状態は，ajsembdbstatusコマンドを実行することで確認できます。_JF0の組み込みDB識別子でセットアップした環境がすでに構築されている場合のajsembdbstatusコマンドの実行例を次に示します。

      ajsembdbstatus -s ust -id _JF0

      HOSTNAME : host_name(144852)

      SYSTEMID : ajs2

      UNITID : unt1

      ENTRYHOST : host_name

      PAIRHOST :

      UNIT-STAT FES-STAT SETUP-STAT

      STOP ******** SETUP

      実行結果のうち，UNIT-STATに表示されている文字列（下線部分）が，組み込みDBの状態を示す情報です。この情報によってajsembdbstartコマンドの実行方法が異なります。表示内容が「STOP」の場合，-idオプション以外のオプションは指定しないで実行してください。「PAUSE」の場合，-idオプションのほかに-Rオプションを指定して実行してください。

  4. 手順1で停止したサービスを起動する。

    JP1/AJS3サービスをホットスタートまたはウォームスタートで起動してください。

    なお，ホットスタート，またはウォームスタートで起動する場合は，スケジューラーデータベースと実際のジョブの実行状況を調査してから運用してください。これは組み込みDBが異常終了した直前までしかスケジューラーデータベースの状態が保持されないで，ほかの制御情報と不整合が発生しているおそれがあるためです。スケジューラーデータベースと実際のジョブの実行状況に，不整合が発生しているかどうかの判断が難しい場合は，JP1/AJS3サービスをコールドスタートで起動して，ジョブネットを実行登録してください。

(c)　注意事項

アンロードログ運用についての注意事項を次に示します。

■ 環境構築時の注意事項

  • システムファイルを二重化すると，二重化していない場合に比べ，システムファイルの容量は増加します。必要なディスク容量については，マニュアル「JP1/Automatic Job Management System 3 構築ガイド　23.1 組み込みDBを使用するための準備」を参照してください。

  • アンロードログ運用は，バックアップ強化機能と併用できません。バックアップ強化機能の概要については，「5.2.5 バックアップ強化機能による組み込みDBのバックアップとリカバリー」を参照してください。

■ 運用時の注意事項

  • アンロードログファイルは，削除またはほかのディスクに移動しないかぎり，アンロードログファイル作成ディレクトリに作成され続けます。そのため，JP1/AJS3の運用を続けることで，アンロードログファイルが増加し，アンロードログファイル作成ディレクトリを含むディスクを圧迫します。アンロードログファイルは，バックアップファイルを取得することで，バックアップファイル取得時点より前に作成されたアンロードログファイルについては削除できます。アンロードログファイルの削除および移動については，マニュアル「JP1/Automatic Job Management System 3 運用ガイド　付録B.2(3) バックアップファイルおよびアンロードログファイルの管理」を参照してください。

  • 自動ログアンロード機能が停止すると，組み込みDBはシステムログファイルのアンロードを実行しないため，アンロード待ち状態のシステムログファイルが増加します。出力先のシステムログファイルを切り替えるタイミングで，使用できるシステムログファイルがないと組み込みDBは異常終了します。そのため，自動ログアンロード機能の稼働状態を監視してください。自動ログアンロード機能の稼働状態の監視方法については，「(b) アンロードログファイルについて」の「自動ログアンロード機能の稼働状態の監視方法」を参照してください。

  • JP1/AJS3サービス稼働中にバックアップファイルを取得する場合，ajsembdbbackupコマンドとジョブ実行処理が競合することによって，双方ともに実行性能が若干低下します。そのため，ジョブの実行数ができるだけ少ない時間帯に実施してください。

■ 回復時の注意事項

  • JP1/AJS3サービス稼働中にバックアップファイルを取得する場合は，回復時にバックアップファイルとバックアップファイル取得以降に出力されたアンロードログファイルが必要となります。アンロードログファイルを削除してしまった場合は，JP1/AJS3サービス稼働中に取得したバックアップファイルでは回復できなくなるため，バックアップファイルを取得し直してください。

  • アンロードログファイルを使用してスケジューラーデータベースを回復する場合，バックアップファイル取得以降に出力されたすべてのアンロードログファイルが必要になります。バックアップファイル取得以降のアンロードログファイルとは，ajsembdbbackupコマンドの実行時刻以降に作成されたアンロードログファイルのことです。

  • アンロードログファイルを使用してスケジューラーデータベースを回復する場合，ajsembdbrstrコマンドの-ldオプションを使用することを推奨します。-lオプションを使用する場合は，古いアンロードログファイルから順に，回復に必要なアンロードログファイルをすべて指定してください。指定した順序に誤りがある場合や指定したアンロードログファイルが足りない場合，ajsembdbrstrコマンドはエラーで終了します。ajsembdbrstrコマンドについては，マニュアル「JP1/Automatic Job Management System 3 コマンドリファレンス　3. 通常の運用で使用するコマンド　ajsembdbrstr」を参照してください。

ページの先頭へ

(2)　システムログを使用しない運用

ここでは，システムログを使用しないでバックアップファイルだけで回復する運用について説明します。この運用では，アンロードログファイルを使用しないため，最も運用が簡単です。システムログを使用しない運用での障害発生時の回復方法を次の図に示します。

図F‒2　障害発生時の回復方法（システムログを使用しない運用）

[図データ]

システムログファイルを監視しないで運用できます。ただし，回復時にシステムログを使用しないため，バックアップファイル取得以降の更新内容については回復できません。

(a)　注意事項

システムログを使用しない運用についての注意事項を次に示します。

■ 環境構築時の注意事項

システムログを使用しない運用では，システムログを使用した回復はできませんが，組み込みDBでシステムログを使用するため，システムログを格納する領域を用意する必要があります。必要なディスク容量については，マニュアル「JP1/Automatic Job Management System 3 構築ガイド　23.1 組み込みDBを使用するための準備」を参照してください。

■ 運用時の注意事項

JP1/AJS3サービスの稼働中には，スケジューラーデータベースのバックアップファイルを取得できません。JP1/AJS3サービスを停止できるタイミングで，バックアップファイルを取得してください。バックアップファイルの取得方法については，マニュアル「JP1/Automatic Job Management System 3 運用ガイド　付録B.1(3) バックアップファイルの取得手順」を参照してください。

■ 回復時の注意事項

スケジューラーデータベースに障害が発生した場合，障害直前の状態に回復できません。システムログを使用しない運用では，バックアップファイルの取得時点にだけ回復できます。回復方法については，マニュアル「JP1/Automatic Job Management System 3 運用ガイド　付録B.1(4) 障害発生時のデータベースの回復手順」を参照してください。

ページの先頭へ

Copyright (C) 2019, 2022, Hitachi, Ltd.

Copyright (C) 2019, 2022, Hitachi Solutions, Ltd.