JP2008198153A - オンライン処理を継続させながらバッチ処理を行う連続運用システム - Google Patents

Abstract

【課題】オンライン処理とバッチ処理を並行して行う連続運用システムの運用スケジュールの自由度を高める。
【解決手段】複数の運用グループに分類された複数のテーブルを記憶するマスタボリューム３７と、バックアップボリューム４７と、運用グループごとに複数のテーブルをマスタボリューム３７からバックアップボリューム４７へコピーするコピー処理部３５と、バックアップボリュームにコピーされたバックアップテーブル一覧を抽出するＤＢ管理部４１と、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を定めるシノニム１３１と、テーブル一覧に含まれるテーブルについて、シノニム１３１が定めるアクセス先をバックアップボリューム４７に設定するシノニム管理部１５と、マスタボリューム３７に記憶されているテーブルを利用したバッチ処理を行うバッチ処理装置５とを備える。
【選択図】図１

Description

本発明は、オンライン処理を継続させながらバッチ処理を行う連続運用システムの技術に関する。

長時間、連続でオンラインシステムを動作させるために、所定のタイミングでオンライントランザクションのアクセス先を待機系へ切り換える連続運用システムがある（例えば、特許文献１）。
特開２００４−２９５６０５号公報

連続運用システムの一態様として、主に日中の時間帯を中心に、オンラインシステムとして種々のトランザクションを処理し、夜間バッチ処理においてその集計処理などを行うシステムがある。このようなシステムでは、翌日のオンライン処理の開始時刻までにバッチ処理を終了させるために、バッチ処理の開始時刻を早め、オンライン終了時刻になる前にオンライン処理と並行してバッチ処理を開始することがある。

このとき、オンライン処理及びバッチ処理の双方を安全に行うためには、バッチ処理でアクセスするデータとオンライン処理でアクセスするデータを分離する必要がある。そこで、現用系のデータを待機系へコピーして、現用系でバッチ処理を実行し、待機系でオンライン処理を行うようにして、オンライン処理とバッチ処理で利用するデータを分離することが行われる。

ところで、システムの運用スケジュールは、ユーザの要望に応じて自在に決められることが好ましい。例えば、上記のような連続運用システムでは、バッチ処理に長時間を要するものほど開始時刻を早めたいという要望がある。

そこで、本発明の目的は、オンライン処理とバッチ処理を並行して行う連続運用システムの運用スケジュールの自由度を高めることである。

本発明の別の目的は、オンライン処理とバッチ処理を並行して行う連続運用システムにおいて、個別のバッチ処理ごとに開始時刻を定めることができるようにすることである。

本発明の一実施態様に従うオンライン処理を継続させながらバッチ処理を行う連続運用システムは、それぞれが複数の運用グループのいずれかに属している複数のテーブルを記憶するマスタボリュームと、前記マスタボリュームのバックアップボリュームと、所定の運用スケジュールに従って、前記運用グループごとに、それぞれの運用グループに属する複数のテーブルを前記マスタボリュームから前記バックアップボリュームへコピーする手段と、前記バックアップボリュームにコピーされたバックアップテーブルの、前記運用グループごとのバックアップテーブル一覧を抽出する手段と、前記複数のテーブルのそれぞれについて、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を、前記マスタボリュームまたは前記バックアップボリュームのいずれか一方に定めるシノニムと、前記バックアップテーブル一覧に含まれるテーブルについて、前記シノニムが定めるアクセス先を前記バックアップボリュームに設定するシノニム管理手段と、前記コピー手段によるコピー終了後、前記マスタボリュームに記憶されている当該コピーに係る運用グループに属するテーブルを利用したバッチ処理を行う手段と、を備える。

好適な実施形態では、前記マスタボリュームに記憶されているテーブルについて、前記運用グループごとのテーブル一覧であるマスタテーブル一覧を抽出する手段をさらに備え、前記シノニム設定手段は、前記マスタテーブル一覧に含まれるテーブルについて、前記シノニムのアクセス先をマスタボリュームに設定するようにしてもよい。

好適な実施形態では、前記シノニム管理手段は、前記マスタテーブル一覧に含まれるテーブルのシノニムが存在しないときは、当該テーブルのシノニムを生成し、生成したシノニムのアクセス先をマスタボリュームに設定するようにしてもよい。

好適な実施形態では、前記複数の運用グループのいずれかに対して、新規テーブルの登録及び既存テーブルの削除を行うテーブル管理手段をさらに備えてもよい。

以下、本発明の一実施形態に係る連続運用システムについて、図面を参照して説明する。

図１は、本実施形態に係る連続運用システムの構成図である。

本システムは、同図に示すように、ＢＬサーバ１と、ＤＢサーバ３、４と、バッチ処理装置５とを備える。本実施形態では、ＤＢサーバ（マスタ）３は、主に日中のオンライン時間帯に動作する現用系のＤＢサーバであり、ＤＢサーバ（バックアップ）４は、夜間バッチの時間帯に動作する待機系のＤＢサーバである。ＢＬサーバ１は、図１では一台だけ示しているが、複数台であってもよい。

本システムの動作概要は以下の通りである。すなわち、ＢＬサーバ１は、所定のユーザリクエストを受け付けて、所定のオンライン処理を実行する。そのオンライン処理において、ＢＬサーバ１は、データが記憶されているＤＢサーバ３または４に対してリクエストを送る。ＤＢサーバ３及び４は、ＢＬサーバ１からのリクエストを受け付けると、そのリクエストに応じた所定の処理を行う。これによりオンラインシステムとして動作する。一方、バッチ処理装置５は、ＤＢサーバ３に記憶されているデータを用いてバッチ処理を行う。

ＢＬサーバ１と、ＤＢサーバ３、４と、バッチ処理装置５は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ等１，３，４，５内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。

以下、本システムの各構成要件について詳細に説明する。

ＢＬサーバ１は、図１に示すように、ＡＰ１１と、仮想データベース１３と、シノニム管理部１５とを備える。

ＡＰ（ＡＰ＃１，ＡＰ＃２）１１は、ユーザリクエストに応じて、所定の業務処理を実行するアプリケーションソフトウェアである。ＡＰ１１が各業務処理の中で、データにアクセスするときに、仮想データベース１３に対してリクエストを送る。そして、ＡＰ１１は、以下に説明するように、仮想データベース１３経由でＤＢサーバ３、４へアクセスする。

仮想データベース１３は、シノニム１３１と、ＤＢリンク１３３とを備える。仮想データベース１３は、ＡＰ１１に対しては、自らがデータを管理するデータベースのごとく振る舞いつつ、ＤＢサーバ３，４に対してＡＰ１１からのリクエストを送り、その処理結果を受け取る。

シノニム１３１は、ＡＰ１１からのデータアクセスのリクエストを受け付けたときのアクセス先を定義する。つまり、シノニム１３１は、データが記憶されたテーブル単位に設けられていて、各テーブルに対するリクエストをＤＢサーバ３またはＤＢサーバ４のいずれへ送るかを定義する。

ＤＢリンク１３３は、それぞれ、ＤＢサーバ３とのインタフェースとなるＤＢリンク＃１と、ＤＢサーバ４とのインタフェースとなるＤＢリンク＃２とがある。

各シノニム１３１は、アクセス先としてＤＢサーバ３が定義されているときは、ＤＢリンク＃１へリクエストを送り、アクセス先としてＤＢサーバ４のテーブルが定義されているときは、ＤＢリンク＃２へリクエストを送る。

シノニム管理部１５は、ＤＢサーバ３または４から送られてくるテーブル一覧に基づいて、このテーブル一覧に含まれるテーブルに対応するシノニム１３１のアクセス先を設定する。例えば、シノニム管理部１５は、ＤＢサーバ３送られてきたテーブル一覧に含まれるテーブルに対応するシノニム１３１のアクセス先を、テーブル一覧の送信元であるＤＢサーバ３が保持するテーブルへと切り換える。同様に、ＤＢサーバ４送られてきたテーブル一覧については、そのテーブル一覧に含まれるテーブルに対応するシノニム１３１のアクセス先を、ＤＢサーバ４が保持するテーブルへと切り換える。ここで、テーブル一覧に含まれるテーブルに対応するシノニム１３１が存在しないときは、シノニム管理部１５がそのシノニム１３１を新たに生成して、テーブル一覧の送信元のＤＢサーバをアクセス先として設定する。

ＤＢサーバ３は、データベース管理部３１と、運用管理部３３と、コピー処理部３５と、マスタボリューム３７とを備える。

マスタボリューム３７には、複数のテーブルが記憶されている。本実施形態では、複数の運用グループが設けられていて、各テーブルは複数の運用グループのうちのいずれかに属している。例えば、図１の例では、テーブルＡ１，Ａ２が運用グループＡ、テーブルＢ１，Ｂ２が運用グループＢにそれぞれ属している。

本実施形態では、それぞれの運用グループごとに予め運用スケジュールが定められている。例えば、運用スケジュールでは、バッチ処理の開始時刻や、運用日付を１日進めて、ＤＢサーバ３のデータを利用してオンライン処理を開始する時刻などが定められている。

データベース管理部３１は、マスタボリューム３７に記憶されているデータを管理する。例えば、データベース管理部３１は、ＢＬサーバ１からのリクエストに応じて、マスタボリューム３７に記憶されているテーブル内のデータの読み出し及び書き込みを行う。また、データベース管理部３１は、運用グループ単位に、各運用グループに属するテーブルのテーブル名一覧を生成して、ＢＬサーバ１へ送信する。

また、データベース管理部３１は、新規テーブルの登録及び既存テーブルの削除を行うことができる。データベース管理部３１が新規テーブルを登録する際は、いずれかの運用グループに属するようにする。

運用管理部３３は、運用グループごとの運用スケジュールを記憶し、その運用スケジュールに従ってテーブルの管理などを行う。例えば、運用管理部３３は、運用スケジュールに従って、運用グループごとにデータをバックアップするようコピー処理部３５へ指示したり、バッチ処理装置５へバッチ処理の開始を指示したりする。

コピー処理部３５は、マスタボリューム３７のデータをバックアップボリューム４７へコピーする。例えば、コピー処理部３５は、運用管理部３３からの指示に従って、指定された運用グループのテーブルを、マスタボリューム３７からバックアップボリューム４７へコピーする。

ＤＢサーバ４は、データベース管理部４１と、バックアップボリューム４７とを備える。

データベース管理部４１は、バックアップボリューム４７に記憶されているデータを管理する。例えば、データベース管理部４１は、ＢＬサーバ１からのリクエストに応じて、バックアップボリューム４７に記憶されているテーブル内のデータの読み出し及び書き込みを行う。また、運用グループ単位でのマスタボリューム３７からバックアップボリューム４７へのデータコピーが終了すると、データベース管理部４１は、そのコピーの終了後に、コピーされた運用グループに属するテーブルのテーブル名一覧を生成して、ＢＬサーバ１へ送付する。

バッチ処理装置５は、バッチ処理部５１，５３を備える。例えば、バッチ処理部（Ａ）５１は、運用グループＡのテーブルを更新するバッチ処理を行う。バッチ処理部（Ｂ）５３は、運用グループＢのテーブルを更新するバッチ処理を行う。

次に、バッチ処理を開始するときに、オンライン処理でアクセスするデータをマスタボリューム３７からバックアップボリューム４７への切り換え処理について説明する。

図２は、このバッチ処理のための切り換え手順を示すフローチャートである。

まず、ＤＢサーバ３の運用管理部３３が、運用スケジュールに従ってバッチ処理開始時刻が到来した運用グループの有無を判定する（Ｓ１１）。バッチ開始時刻が到来した運用グループがあれば（Ｓ１１：Ｙｅｓ）、コピー処理部３５がその運用グループのテーブルを、マスタボリューム３７からバックアップボリューム４７へバックアップする（Ｓ１２）。

バックアップが完了すると、ＤＢサーバ４のデータベース管理部４１がバックアップボリューム４７にコピーされた運用グループについて、その運用グループに属するテーブルのテーブル名一覧を抽出して、ＢＬサーバ１へ通知する（Ｓ１３）。

テーブル名一覧の通知を受けたＢＬサーバ１のシノニム管理部１５は、そのテーブル名一覧に含まれているテーブルに対応するシノニム１３１のアクセス先が、バックアップボリューム４７になるように設定する（Ｓ１４）。このとき、テーブル名一覧にテーブル名が含まれているが、対応するシノニム１３１が存在しないテーブルについて、シノニム管理部１５が新たにシノニム１３１を生成する。

この後、この運用グループに対応するバッチ処理部が、マスタボリューム３７を利用してバッチ処理を行う（Ｓ１５）。

上記のようにしてバッチ処理開始時刻が到来した運用グループのシノニム１３１を切り換えることにより、この運用グループに属するテーブルについては、オンラインアプリケーションからのリクエストは、バックアップボリューム４７にバックアップしたテーブルへアクセスされるようになる。これにより、マスタボリューム３７のテーブルに対して、オンラインアプリケーションからのリクエストによるアクセスはなされないので、安全にバッチ処理を行うことができる。

次に、オンラインアプリケーションからアクセスするデータをマスタボリューム３７に切り換えて、ＤＢサーバ３がオンラインアプリケーションの処理を再開する手順について説明する。

図３は、オンライン処理のための切り換え手順を示すフローチャートである。

まず、ＤＢサーバ３の運用管理部３３が、オンライン開始時刻が到来した運用グループの有無を判定する（Ｓ２１）。オンライン開始時刻が到来した運用グループがあれば（Ｓ２１：Ｙｅｓ）、データベース管理部３１がマスタボリューム３７に記憶されているその運用グループから、その運用グループに属するテーブルのテーブル名一覧を抽出して、ＢＬサーバ１へ通知する（Ｓ２２）。

テーブル名一覧の通知を受けたＢＬサーバ１のシノニム管理部１５は、そのテーブル名一覧に含まれているテーブルと対応するシノニム１３１のアクセス先がマスタボリューム３７になるように設定する（Ｓ２３）。このとき、テーブル名一覧にテーブル名が含まれているが、対応するシノニム１３１が存在しないテーブルについては、シノニム管理部１３１が新たにシノニム１３１を生成する。

上記のようにしてシノニム１３１のアクセス先をマスタボリューム３７へ切り換えた後、オンライン開始時刻が到来した運用グループに属するテーブルを利用するオンライン処理を行う（Ｓ２４）。

次に、図４は、上記のような構成を備えたシステムを用いた運用の一例を示す。

本システムは、運用日付“Ｎ”として所定の時刻からオンライン処理が開始される。このオンライン処理には、例えば、図４に示すようにサブシステムＡ及びＢが含まれる。主に日中のオンライン時間帯では、サブシステムＡ及びＢからのデータアクセスのリクエストは、ＤＢサーバ３へ送られて、マスタボリューム３７のデータが利用される。

ここで、サブシステムＡは、ＡＰ＃１を利用したオンライン処理Ａを行って、運用グループＡに属するテーブルＡ１，Ａ２のデータを更新し、サブシステムＢは、ＡＰ＃２を利用したオンライン処理Ｂを行って、運用グループＢに属するテーブルＢ１，Ｂ２のデータを更新する。

オンラインのトランザクション量が減ってきて、バッチ処理Ｂの開始時刻（例えば午後９時）になると、運用グループＢに属するテーブルは、上述の要領でマスタボリューム３７からバックアップボリューム４７へコピーされ、オンライン処理Ｂのアクセス先がバックアップボリューム４７へ切り換えられる。その結果、オンライン処理ＢのリクエストはＤＢサーバ４へ送られ、バックアップボリューム４７のデータが利用される。これにより、バッチ処理ＢはＤＢサーバ３のマスタボリューム３７を利用した処理が可能となり、その処理を開始する。

つぎに、バッチ処理Ａの開始時刻（例えば午後１１時）になると、運用グループＡについて、上述の要領でマスタボリューム３７からバックアップボリューム４７へのコピーが行われ、オンライン処理Ａのアクセス先もバックアップボリューム４７へ切り換えられる。この結果、オンライン処理Ａについても、そのリクエストはＤＢサーバ４へ送られ、バックアップボリューム４７のデータが利用される。これにより、バッチ処理ＡもＤＢサーバ３のマスタボリューム３７を利用した処理が可能となり、その処理を開始する。

この後、バッチ処理Ａ，Ｂのそれぞれの処理が終了し、所定の時刻になると、翌運用日付“Ｎ＋１”のオンライン処理が開始される。

ここで、バッチ処理Ｂの開始時刻後、バッチ処理Ａの開始時刻前の時間帯におけるシステムの動作イメージを図５に示す。

まず、運用グループＢに属するテーブルＢ１，Ｂ２のデータは、マスタボリューム３７からバックアップボリューム４７へ既にバックアップ済みである。また、テーブルＡ１，Ａ２のシノニム１３１は、アクセス先としてＤＢサーバ３が定義され、テーブルＢ１，Ｂ２のシノニム１３１は、アクセス先としてＤＢサーバ４が定義されている。

このときに、オンライン処理Ａに係るＡＰ＃１が、テーブルＡ１，Ａ２に対するリクエストを発行する。このリクエストは、テーブルＡ１，Ａ２に対応するシノニム１３１によってＤＢリンク＃１へ割り当てられて、ＤＢサーバ３へ送られる。

また、オンライン処理Ｂに係るＡＰ＃２が、テーブルＢ１，Ｂ２に対するリクエストを発行する。このリクエストは、テーブルＢ１，Ｂ２に対応するシノニム１３１によってＤＢリンク＃２へ割り当てられて、ＤＢサーバ４へ送られる。

この結果、マスタボリューム３７の運用グループＢに属するテーブルＢ１，Ｂ２に対しては、オンラインアクセスがない。従って、バッチ処理Ｂは、テーブルＢ１，Ｂ２の更新を含む処理を安全に実行することができる。

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

本発明の一実施形態に係る連続運用システムの構成図である。 バッチ処理を行うためのＤＢサーバ切り換え処理のフローチャートである。 バッチ処理終了後のＤＢサーバ切り換え処理のフローチャートである。 本システムを用いた運用の一例を示す。 一部のデータのアクセス先を切り換えたときのシステムの動作イメージを示す。

符号の説明

１…ＢＬサーバ、３，４…ＤＢサーバ、５…バッチ処理装置、１３…仮想データベース、１５…シノニム管理部、３１，４１…データベース管理部、３３…運用管理部、３５…コピー処理部、３７…マスタボリューム、４７…バックアップボリューム。

Claims (6)

1. オンライン処理を継続させながらバッチ処理を行う連続運用システムであって、
   それぞれが複数の運用グループのいずれかに属している複数のテーブルを記憶するマスタボリュームと、
   前記マスタボリュームのバックアップボリュームと、
   所定の運用スケジュールに従って、前記運用グループごとに、それぞれの運用グループに属する複数のテーブルを前記マスタボリュームから前記バックアップボリュームへコピーする手段と、
   前記バックアップボリュームにコピーされたバックアップテーブルの、前記運用グループごとのバックアップテーブル一覧を抽出する手段と、
   前記複数のテーブルのそれぞれについて、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を、前記マスタボリュームまたは前記バックアップボリュームのいずれか一方に定めるシノニムと、
   前記バックアップテーブル一覧に含まれるテーブルについて、前記シノニムが定めるアクセス先を前記バックアップボリュームに設定するシノニム管理手段と、
   前記コピー手段によるコピー終了後、前記マスタボリュームに記憶されている当該コピーに係る運用グループに属するテーブルを利用したバッチ処理を行う手段と、を備える連続運用システム。
2. 前記マスタボリュームに記憶されているテーブルについて、前記運用グループごとのテーブル一覧であるマスタテーブル一覧を抽出する手段をさらに備え、
   前記シノニム設定手段は、前記マスタテーブル一覧に含まれるテーブルについて、前記シノニムのアクセス先をマスタボリュームに設定することを特徴とする請求項１記載の連続運用システム。
3. 前記シノニム管理手段は、前記マスタテーブル一覧に含まれるテーブルのシノニムが存在しないときは、当該テーブルのシノニムを生成し、生成したシノニムのアクセス先をマスタボリュームに設定することを特徴とする請求項２記載の連続運用システム。
4. 前記複数の運用グループのいずれかに対して、新規テーブルの登録及び既存テーブルの削除を行うテーブル管理手段をさらに備えることを特徴とする請求項１記載の連続運用システム。
5. それぞれが複数の運用グループのいずれかに属している複数のテーブルを記憶するマスタボリュームから、所定の運用スケジュールに従って、前記運用グループごとに、それぞれの運用グループに属する複数のテーブルを、バックアップボリュームへコピーするステップと、
   前記バックアップボリュームにコピーされた前記運用グループのバックアップテーブルのテーブル一覧を抽出するステップと、
   前記複数のテーブルのそれぞれについて、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を、前記マスタボリュームまたは前記バックアップボリュームのいずれか一方に定めるシノニムに対して、前記テーブル一覧に含まれるテーブルと対応するシノニムが定めるアクセス先を前記バックアップボリュームに設定するステップと、
   前記マスタボリュームに記憶されている前記コピーに係る運用グループに属するテーブルを利用したバッチ処理を行うステップと、を有するオンライン処理を継続させながらバッチ処理を行うためのオンラインアプリケーションのアクセス先の切り換え方法。
6. オンライン処理を継続させながらバッチ処理を行うために、オンラインアプリケーションのアクセス先の切り換えるためのコンピュータプログラムであって、
   それぞれが複数の運用グループのいずれかに属している複数のテーブルを記憶するマスタボリュームから、所定の運用スケジュールに従って、前記運用グループごとに、それぞれの運用グループに属する複数のテーブルを、バックアップボリュームへコピーするステップと、
   前記バックアップボリュームにコピーされた前記運用グループのバックアップテーブルのテーブル一覧を抽出するステップと、
   前記複数のテーブルのそれぞれについて、オンラインアプリケーションからのアクセス要求を受けたときのアクセス先を、前記マスタボリュームまたは前記バックアップボリュームのいずれか一方に定めるシノニムに対して、前記テーブル一覧に含まれるテーブルと対応するシノニムが定めるアクセス先を前記バックアップボリュームに設定するステップと、
   前記マスタボリュームに記憶されている前記コピーに係る運用グループに属するテーブルを利用したバッチ処理を行うステップと、をコンピュータに実行させるためのコンピュータプログラム。

Images