(57)【要約】【課題】オンライン処理とバッチ処理を並行して行う連続運用システムの運用スケジュールの自由度を高める。【解決手段】複数の運用グループに分類された複数のテーブルを記憶するマスタボリューム３７と、バックアップボリューム４７と、運用グループごとに複数のテーブルをマスタボリューム３７からバックアップボリューム４７へコピーするコピー処理部３５と、バックアップボリュームにコピーされたバックアップテーブル一覧を抽出するＤＢ管理部４１と、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を定めるシノニム１３１と、テーブル一覧に含まれるテーブルについて、シノニム１３１が定めるアクセス先をバックアップボリューム４７に設定するシノニム管理部１５と、マスタボリューム３７に記憶されているテーブルを利用したバッチ処理を行うバッチ処理装置５とを備える。【選択図】図１
2008198153.tif 000002
【特許請求の範囲】
【請求項１】
オンライン処理を継続させながらバッチ処理を行う連続運用システムであって、
それぞれが複数の運用グループのいずれかに属している複数のテーブルを記憶するマスタボリュームと、
前記マスタボリュームのバックアップボリュームと、
所定の運用スケジュールに従って、前記運用グループごとに、それぞれの運用グループに属する複数のテーブルを前記マスタボリュームから前記バックアップボリュームへコピーする手段と、
前記バックアップボリュームにコピーされたバックアップテーブルの、前記運用グループごとのバックアップテーブル一覧を抽出する手段と、
前記複数のテーブルのそれぞれについて、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を、前記マスタボリュームまたは前記バックアップボリュームのいずれか一方に定めるシノニムと、
前記バックアップテーブル一覧に含まれるテーブルについて、前記シノニムが定めるアクセス先を前記バックアップボリュームに設定するシノニム管理手段と、
前記コピー手段によるコピー終了後、前記マスタボリュームに記憶されている当該コピーに係る運用グループに属するテーブルを利用したバッチ処理を行う手段と、を備える連続運用システム。
【請求項２】
前記マスタボリュームに記憶されているテーブルについて、前記運用グループごとのテーブル一覧であるマスタテーブル一覧を抽出する手段をさらに備え、
前記シノニム設定手段は、前記マスタテーブル一覧に含まれるテーブルについて、前記シノニムのアクセス先をマスタボリュームに設定することを特徴とする請求項１記載の連続運用システム。
【請求項３】
前記シノニム管理手段は、前記マスタテーブル一覧に含まれるテーブルのシノニムが存在しないときは、当該テーブルのシノニムを生成し、生成したシノニムのアクセス先をマスタボリュームに設定することを特徴とする請求項２記載の連続運用システム。
【請求項４】
前記複数の運用グループのいずれかに対して、新規テーブルの登録及び既存テーブルの削除を行うテーブル管理手段をさらに備えることを特徴とする請求項１記載の連続運用システム。
【請求項５】
それぞれが複数の運用グループのいずれかに属している複数のテーブルを記憶するマスタボリュームから、所定の運用スケジュールに従って、前記運用グループごとに、それぞれの運用グループに属する複数のテーブルを、バックアップボリュームへコピーするステップと、
前記バックアップボリュームにコピーされた前記運用グループのバックアップテーブルのテーブル一覧を抽出するステップと、
前記複数のテーブルのそれぞれについて、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を、前記マスタボリュームまたは前記バックアップボリュームのいずれか一方に定めるシノニムに対して、前記テーブル一覧に含まれるテーブルと対応するシノニムが定めるアクセス先を前記バックアップボリュームに設定するステップと、
前記マスタボリュームに記憶されている前記コピーに係る運用グループに属するテーブルを利用したバッチ処理を行うステップと、を有するオンライン処理を継続させながらバッチ処理を行うためのオンラインアプリケーションのアクセス先の切り換え方法。
【請求項６】
オンライン処理を継続させながらバッチ処理を行うために、オンラインアプリケーションのアクセス先の切り換えるためのコンピュータプログラムであって、
それぞれが複数の運用グループのいずれかに属している複数のテーブルを記憶するマスタボリュームから、所定の運用スケジュールに従って、前記運用グループごとに、それぞれの運用グループに属する複数のテーブルを、バックアップボリュームへコピーするステップと、
前記バックアップボリュームにコピーされた前記運用グループのバックアップテーブルのテーブル一覧を抽出するステップと、
前記複数のテーブルのそれぞれについて、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を、前記マスタボリュームまたは前記バックアップボリュームのいずれか一方に定めるシノニムに対して、前記テーブル一覧に含まれるテーブルと対応するシノニムが定めるアクセス先を前記バックアップボリュームに設定するステップと、
前記マスタボリュームに記憶されている前記コピーに係る運用グループに属するテーブルを利用したバッチ処理を行うステップと、をコンピュータに実行させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンライン処理を継続させながらバッチ処理を行う連続運用システムの技術に関する。
【背景技術】
【０００２】
長時間、連続でオンラインシステムを動作させるために、所定のタイミングでオンライントランザクションのアクセス先を待機系へ切り換える連続運用システムがある（例えば、特許文献１）。
【特許文献１】特開２００４−２９５６０５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
連続運用システムの一態様として、主に日中の時間帯を中心に、オンラインシステムとして種々のトランザクションを処理し、夜間バッチ処理においてその集計処理などを行うシステムがある。このようなシステムでは、翌日のオンライン処理の開始時刻までにバッチ処理を終了させるために、バッチ処理の開始時刻を早め、オンライン終了時刻になる前にオンライン処理と並行してバッチ処理を開始することがある。
【０００４】
このとき、オンライン処理及びバッチ処理の双方を安全に行うためには、バッチ処理でアクセスするデータとオンライン処理でアクセスするデータを分離する必要がある。そこで、現用系のデータを待機系へコピーして、現用系でバッチ処理を実行し、待機系でオンライン処理を行うようにして、オンライン処理とバッチ処理で利用するデータを分離することが行われる。
【０００５】
ところで、システムの運用スケジュールは、ユーザの要望に応じて自在に決められることが好ましい。例えば、上記のような連続運用システムでは、バッチ処理に長時間を要するものほど開始時刻を早めたいという要望がある。
【０００６】
そこで、本発明の目的は、オンライン処理とバッチ処理を並行して行う連続運用システムの運用スケジュールの自由度を高めることである。
【０００７】
本発明の別の目的は、オンライン処理とバッチ処理を並行して行う連続運用システムにおいて、個別のバッチ処理ごとに開始時刻を定めることができるようにすることである。
【課題を解決するための手段】
【０００８】
本発明の一実施態様に従うオンライン処理を継続させながらバッチ処理を行う連続運用システムは、それぞれが複数の運用グループのいずれかに属している複数のテーブルを記憶するマスタボリュームと、前記マスタボリュームのバックアップボリュームと、所定の運用スケジュールに従って、前記運用グループごとに、それぞれの運用グループに属する複数のテーブルを前記マスタボリュームから前記バックアップボリュームへコピーする手段と、前記バックアップボリュームにコピーされたバックアップテーブルの、前記運用グループごとのバックアップテーブル一覧を抽出する手段と、前記複数のテーブルのそれぞれについて、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を、前記マスタボリュームまたは前記バックアップボリュームのいずれか一方に定めるシノニムと、前記バックアップテーブル一覧に含まれるテーブルについて、前記シノニムが定めるアクセス先を前記バックアップボリュームに設定するシノニム管理手段と、前記コピー手段によるコピー終了後、前記マスタボリュームに記憶されている当該コピーに係る運用グループに属するテーブルを利用したバッチ処理を行う手段と、を備える。
【０００９】
好適な実施形態では、前記マスタボリュームに記憶されているテーブルについて、前記運用グループごとのテーブル一覧であるマスタテーブル一覧を抽出する手段をさらに備え、前記シノニム設定手段は、前記マスタテーブル一覧に含まれるテーブルについて、前記シノニムのアクセス先をマスタボリュームに設定するようにしてもよい。
【００１０】
好適な実施形態では、前記シノニム管理手段は、前記マスタテーブル一覧に含まれるテーブルのシノニムが存在しないときは、当該テーブルのシノニムを生成し、生成したシノニムのアクセス先をマスタボリュームに設定するようにしてもよい。
【００１１】
好適な実施形態では、前記複数の運用グループのいずれかに対して、新規テーブルの登録及び既存テーブルの削除を行うテーブル管理手段をさらに備えてもよい。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の一実施形態に係る連続運用システムについて、図面を参照して説明する。
【００１３】
図１は、本実施形態に係る連続運用システムの構成図である。
【００１４】
本システムは、同図に示すように、ＢＬサーバ１と、ＤＢサーバ３、４と、バッチ処理装置５とを備える。本実施形態では、ＤＢサーバ（マスタ）３は、主に日中のオンライン時間帯に動作する現用系のＤＢサーバであり、ＤＢサーバ（バックアップ）４は、夜間バッチの時間帯に動作する待機系のＤＢサーバである。ＢＬサーバ１は、図１では一台だけ示しているが、複数台であってもよい。
【００１５】
本システムの動作概要は以下の通りである。すなわち、ＢＬサーバ１は、所定のユーザリクエストを受け付けて、所定のオンライン処理を実行する。そのオンライン処理において、ＢＬサーバ１は、データが記憶されているＤＢサーバ３または４に対してリクエストを送る。ＤＢサーバ３及び４は、ＢＬサーバ１からのリクエストを受け付けると、そのリクエストに応じた所定の処理を行う。これによりオンラインシステムとして動作する。一方、バッチ処理装置５は、ＤＢサーバ３に記憶されているデータを用いてバッチ処理を行う。
【００１６】
ＢＬサーバ１と、ＤＢサーバ３、４と、バッチ処理装置５は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ等１，３，４，５内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００１７】
以下、本システムの各構成要件について詳細に説明する。
【００１８】
ＢＬサーバ１は、図１に示すように、ＡＰ１１と、仮想データベース１３と、シノニム管理部１５とを備える。
【００１９】
ＡＰ（ＡＰ＃１，ＡＰ＃２）１１は、ユーザリクエストに応じて、所定の業務処理を実行するアプリケーションソフトウェアである。ＡＰ１１が各業務処理の中で、データにアクセスするときに、仮想データベース１３に対してリクエストを送る。そして、ＡＰ１１は、以下に説明するように、仮想データベース１３経由でＤＢサーバ３、４へアクセスする。
【００２０】
仮想データベース１３は、シノニム１３１と、ＤＢリンク１３３とを備える。仮想データベース１３は、ＡＰ１１に対しては、自らがデータを管理するデータベースのごとく振る舞いつつ、ＤＢサーバ３，４に対してＡＰ１１からのリクエストを送り、その処理結果を受け取る。
【００２１】
シノニム１３１は、ＡＰ１１からのデータアクセスのリクエストを受け付けたときのアクセス先を定義する。つまり、シノニム１３１は、データが記憶されたテーブル単位に設けられていて、各テーブルに対するリクエストをＤＢサーバ３またはＤＢサーバ４のいずれへ送るかを定義する。
【００２２】
ＤＢリンク１３３は、それぞれ、ＤＢサーバ３とのインタフェースとなるＤＢリンク＃１と、ＤＢサーバ４とのインタフェースとなるＤＢリンク＃２とがある。
【００２３】
各シノニム１３１は、アクセス先としてＤＢサーバ３が定義されているときは、ＤＢリンク＃１へリクエストを送り、アクセス先としてＤＢサーバ４のテーブルが定義されているときは、ＤＢリンク＃２へリクエストを送る。
【００２４】
シノニム管理部１５は、ＤＢサーバ３または４から送られてくるテーブル一覧に基づいて、このテーブル一覧に含まれるテーブルに対応するシノニム１３１のアクセス先を設定する。例えば、シノニム管理部１５は、ＤＢサーバ３送られてきたテーブル一覧に含まれるテーブルに対応するシノニム１３１のアクセス先を、テーブル一覧の送信元であるＤＢサーバ３が保持するテーブルへと切り換える。同様に、ＤＢサーバ４送られてきたテーブル一覧については、そのテーブル一覧に含まれるテーブルに対応するシノニム１３１のアクセス先を、ＤＢサーバ４が保持するテーブルへと切り換える。ここで、テーブル一覧に含まれるテーブルに対応するシノニム１３１が存在しないときは、シノニム管理部１５がそのシノニム１３１を新たに生成して、テーブル一覧の送信元のＤＢサーバをアクセス先として設定する。
【００２５】
ＤＢサーバ３は、データベース管理部３１と、運用管理部３３と、コピー処理部３５と、マスタボリューム３７とを備える。
【００２６】
マスタボリューム３７には、複数のテーブルが記憶されている。本実施形態では、複数の運用グループが設けられていて、各テーブルは複数の運用グループのうちのいずれかに属している。例えば、図１の例では、テーブルＡ１，Ａ２が運用グループＡ、テーブルＢ１，Ｂ２が運用グループＢにそれぞれ属している。
【００２７】
本実施形態では、それぞれの運用グループごとに予め運用スケジュールが定められている。例えば、運用スケジュールでは、バッチ処理の開始時刻や、運用日付を１日進めて、ＤＢサーバ３のデータを利用してオンライン処理を開始する時刻などが定められている。
【００２８】
データベース管理部３１は、マスタボリューム３７に記憶されているデータを管理する。例えば、データベース管理部３１は、ＢＬサーバ１からのリクエストに応じて、マスタボリューム３７に記憶されているテーブル内のデータの読み出し及び書き込みを行う。また、データベース管理部３１は、運用グループ単位に、各運用グループに属するテーブルのテーブル名一覧を生成して、ＢＬサーバ１へ送信する。
【００２９】
また、データベース管理部３１は、新規テーブルの登録及び既存テーブルの削除を行うことができる。データベース管理部３１が新規テーブルを登録する際は、いずれかの運用グループに属するようにする。
【００３０】
運用管理部３３は、運用グループごとの運用スケジュールを記憶し、その運用スケジュールに従ってテーブルの管理などを行う。例えば、運用管理部３３は、運用スケジュールに従って、運用グループごとにデータをバックアップするようコピー処理部３５へ指示したり、バッチ処理装置５へバッチ処理の開始を指示したりする。
【００３１】
コピー処理部３５は、マスタボリューム３７のデータをバックアップボリューム４７へコピーする。例えば、コピー処理部３５は、運用管理部３３からの指示に従って、指定された運用グループのテーブルを、マスタボリューム３７からバックアップボリューム４７へコピーする。
【００３２】
ＤＢサーバ４は、データベース管理部４１と、バックアップボリューム４７とを備える。
【００３３】
データベース管理部４１は、バックアップボリューム４７に記憶されているデータを管理する。例えば、データベース管理部４１は、ＢＬサーバ１からのリクエストに応じて、バックアップボリューム４７に記憶されているテーブル内のデータの読み出し及び書き込みを行う。また、運用グループ単位でのマスタボリューム３７からバックアップボリューム４７へのデータコピーが終了すると、データベース管理部４１は、そのコピーの終了後に、コピーされた運用グループに属するテーブルのテーブル名一覧を生成して、ＢＬサーバ１へ送付する。
【００３４】
バッチ処理装置５は、バッチ処理部５１，５３を備える。例えば、バッチ処理部（Ａ）５１は、運用グループＡのテーブルを更新するバッチ処理を行う。バッチ処理部（Ｂ）５３は、運用グループＢのテーブルを更新するバッチ処理を行う。
【００３５】
次に、バッチ処理を開始するときに、オンライン処理でアクセスするデータをマスタボリューム３７からバックアップボリューム４７への切り換え処理について説明する。
【００３６】
図２は、このバッチ処理のための切り換え手順を示すフローチャートである。
【００３７】
まず、ＤＢサーバ３の運用管理部３３が、運用スケジュールに従ってバッチ処理開始時刻が到来した運用グループの有無を判定する（Ｓ１１）。バッチ開始時刻が到来した運用グループがあれば（Ｓ１１：Ｙｅｓ）、コピー処理部３５がその運用グループのテーブルを、マスタボリューム３７からバックアップボリューム４７へバックアップする（Ｓ１２）。
【００３８】
バックアップが完了すると、ＤＢサーバ４のデータベース管理部４１がバックアップボリューム４７にコピーされた運用グループについて、その運用グループに属するテーブルのテーブル名一覧を抽出して、ＢＬサーバ１へ通知する（Ｓ１３）。
【００３９】
テーブル名一覧の通知を受けたＢＬサーバ１のシノニム管理部１５は、そのテーブル名一覧に含まれているテーブルに対応するシノニム１３１のアクセス先が、バックアップボリューム４７になるように設定する（Ｓ１４）。このとき、テーブル名一覧にテーブル名が含まれているが、対応するシノニム１３１が存在しないテーブルについて、シノニム管理部１５が新たにシノニム１３１を生成する。
【００４０】
この後、この運用グループに対応するバッチ処理部が、マスタボリューム３７を利用してバッチ処理を行う（Ｓ１５）。
【００４１】
上記のようにしてバッチ処理開始時刻が到来した運用グループのシノニム１３１を切り換えることにより、この運用グループに属するテーブルについては、オンラインアプリケーションからのリクエストは、バックアップボリューム４７にバックアップしたテーブルへアクセスされるようになる。これにより、マスタボリューム３７のテーブルに対して、オンラインアプリケーションからのリクエストによるアクセスはなされないので、安全にバッチ処理を行うことができる。
【００４２】
次に、オンラインアプリケーションからアクセスするデータをマスタボリューム３７に切り換えて、ＤＢサーバ３がオンラインアプリケーションの処理を再開する手順について説明する。
【００４３】
図３は、オンライン処理のための切り換え手順を示すフローチャートである。
【００４４】
まず、ＤＢサーバ３の運用管理部３３が、オンライン開始時刻が到来した運用グループの有無を判定する（Ｓ２１）。オンライン開始時刻が到来した運用グループがあれば（Ｓ２１：Ｙｅｓ）、データベース管理部３１がマスタボリューム３７に記憶されているその運用グループから、その運用グループに属するテーブルのテーブル名一覧を抽出して、ＢＬサーバ１へ通知する（Ｓ２２）。
【００４５】
テーブル名一覧の通知を受けたＢＬサーバ１のシノニム管理部１５は、そのテーブル名一覧に含まれているテーブルと対応するシノニム１３１のアクセス先がマスタボリューム３７になるように設定する（Ｓ２３）。このとき、テーブル名一覧にテーブル名が含まれているが、対応するシノニム１３１が存在しないテーブルについては、シノニム管理部１３１が新たにシノニム１３１を生成する。
【００４６】
上記のようにしてシノニム１３１のアクセス先をマスタボリューム３７へ切り換えた後、オンライン開始時刻が到来した運用グループに属するテーブルを利用するオンライン処理を行う（Ｓ２４）。
【００４７】
次に、図４は、上記のような構成を備えたシステムを用いた運用の一例を示す。
【００４８】
本システムは、運用日付“Ｎ”として所定の時刻からオンライン処理が開始される。このオンライン処理には、例えば、図４に示すようにサブシステムＡ及びＢが含まれる。主に日中のオンライン時間帯では、サブシステムＡ及びＢからのデータアクセスのリクエストは、ＤＢサーバ３へ送られて、マスタボリューム３７のデータが利用される。
【００４９】
ここで、サブシステムＡは、ＡＰ＃１を利用したオンライン処理Ａを行って、運用グループＡに属するテーブルＡ１，Ａ２のデータを更新し、サブシステムＢは、ＡＰ＃２を利用したオンライン処理Ｂを行って、運用グループＢに属するテーブルＢ１，Ｂ２のデータを更新する。
【００５０】
オンラインのトランザクション量が減ってきて、バッチ処理Ｂの開始時刻（例えば午後９時）になると、運用グループＢに属するテーブルは、上述の要領でマスタボリューム３７からバックアップボリューム４７へコピーされ、オンライン処理Ｂのアクセス先がバックアップボリューム４７へ切り換えられる。その結果、オンライン処理ＢのリクエストはＤＢサーバ４へ送られ、バックアップボリューム４７のデータが利用される。これにより、バッチ処理ＢはＤＢサーバ３のマスタボリューム３７を利用した処理が可能となり、その処理を開始する。
【００５１】
つぎに、バッチ処理Ａの開始時刻（例えば午後１１時）になると、運用グループＡについて、上述の要領でマスタボリューム３７からバックアップボリューム４７へのコピーが行われ、オンライン処理Ａのアクセス先もバックアップボリューム４７へ切り換えられる。この結果、オンライン処理Ａについても、そのリクエストはＤＢサーバ４へ送られ、バックアップボリューム４７のデータが利用される。これにより、バッチ処理ＡもＤＢサーバ３のマスタボリューム３７を利用した処理が可能となり、その処理を開始する。
【００５２】
この後、バッチ処理Ａ，Ｂのそれぞれの処理が終了し、所定の時刻になると、翌運用日付“Ｎ＋１”のオンライン処理が開始される。
【００５３】
ここで、バッチ処理Ｂの開始時刻後、バッチ処理Ａの開始時刻前の時間帯におけるシステムの動作イメージを図５に示す。
【００５４】
まず、運用グループＢに属するテーブルＢ１，Ｂ２のデータは、マスタボリューム３７からバックアップボリューム４７へ既にバックアップ済みである。また、テーブルＡ１，Ａ２のシノニム１３１は、アクセス先としてＤＢサーバ３が定義され、テーブルＢ１，Ｂ２のシノニム１３１は、アクセス先としてＤＢサーバ４が定義されている。
【００５５】
このときに、オンライン処理Ａに係るＡＰ＃１が、テーブルＡ１，Ａ２に対するリクエストを発行する。このリクエストは、テーブルＡ１，Ａ２に対応するシノニム１３１によってＤＢリンク＃１へ割り当てられて、ＤＢサーバ３へ送られる。
【００５６】
また、オンライン処理Ｂに係るＡＰ＃２が、テーブルＢ１，Ｂ２に対するリクエストを発行する。このリクエストは、テーブルＢ１，Ｂ２に対応するシノニム１３１によってＤＢリンク＃２へ割り当てられて、ＤＢサーバ４へ送られる。
【００５７】
この結果、マスタボリューム３７の運用グループＢに属するテーブルＢ１，Ｂ２に対しては、オンラインアクセスがない。従って、バッチ処理Ｂは、テーブルＢ１，Ｂ２の更新を含む処理を安全に実行することができる。
【００５８】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【図面の簡単な説明】
【００５９】
【図１】本発明の一実施形態に係る連続運用システムの構成図である。
【図２】バッチ処理を行うためのＤＢサーバ切り換え処理のフローチャートである。
【図３】バッチ処理終了後のＤＢサーバ切り換え処理のフローチャートである。
【図４】本システムを用いた運用の一例を示す。
【図５】一部のデータのアクセス先を切り換えたときのシステムの動作イメージを示す。
【符号の説明】
【００６０】
１…ＢＬサーバ、３，４…ＤＢサーバ、５…バッチ処理装置、１３…仮想データベース、１５…シノニム管理部、３１，４１…データベース管理部、３３…運用管理部、３５…コピー処理部、３７…マスタボリューム、４７…バックアップボリューム。
【図１】
2008198153.tif 000003
【図２】
2008198153.tif 000004
【図３】
2008198153.tif 000005
【図４】
2008198153.tif 000006
【図５】
2008198153.tif 000007