(57)【要約】【課題】ａｃｔｉｖｅ／ａｃｔｉｖｅ型かつシェアードエブリシング型のクラスタ構成データベースにおいて片系障害が発生した場合に、トランザクションを異常終了させずに処理を継続し、かつ無駄なリトライ処理を行わない。【解決手段】業務処理サーバ１は、業務端末３から受信した業務電文を退避データ格納部１２に格納する業務処理制御部１１と、業務処理制御部１１から業務電文を受信し、処理を実行する業務ロジック部１３と、業務ロジック部１３からデータベースアクセス要求を受信し、接続中のデータベースインスタンスに対してＳＱＬを発行し、ＳＱＬエラーの場合には、リトライ可否の判定処理を行うデータベースアクセス制御部１４とを備え、業務処理制御部１１は、リトライ可能であった場合には退避データ格納部１２に格納されたトランザクション要求を業務ロジック部１３に通知することによりリトライを実行する。【選択図】図１
2011086067.tif 000002
【特許請求の範囲】
【請求項１】
ａｃｔｉｖｅ／ａｃｔｉｖｅ型かつシェアードエブリシング型のクラスタ構成データベースに対してトランザクション処理を実行するデータベース処理装置であって、
前記データベースに対するトランザクション要求を退避データ格納部に格納する業務処理制御部と、
前記業務処理制御部から前記トランザクション要求を受信し、前記トランザクション要求にしたがって前記データベースにアクセスし、処理を実行する業務ロジック部と、
前記業務ロジック部からデータベースアクセス要求を受信したら、前記データベースの接続中のデータベースインスタンスに対してＳＱＬを発行し、前記データベースインスタンスから送信されたＳＱＬ実行結果が異常終了の場合には、リトライ可否の判定処理を行うデータベースアクセス制御部と、を備え、
前記業務処理制御部は、前記リトライ可否の判定処理の結果がリトライ可能であった場合には、前記退避データ格納部から前記トランザクション要求を取得し、前記業務ロジック部に前記トランザクション要求を通知することによりリトライを実行する、データベース処理装置。
【請求項２】
請求項１に記載のデータベース処理装置であって、
前記データベースアクセス制御部は、
前記ＳＱＬ実行結果が異常終了の場合にロールバック処理を実行し、
前記ロールバック処理が成功した場合にはリトライ不可と判定し、
前記ロールバック処理が正常終了の場合には、他のデータベースインスタンスへ接続を切り替え、切り替えが成功した場合にはリトライ可能と判定し、切り替えが失敗した場合にはリトライ不可と判定する、データベース処理装置。
【請求項３】
ａｃｔｉｖｅ／ａｃｔｉｖｅ型かつシェアードエブリシング型のクラスタ構成データベースに対してトランザクション処理を実行するデータベース処理方法であって、
業務処理制御部が、前記データベースに対するトランザクション要求を退避データ格納部に格納し、業務ロジック部にトランザクション要求を通知する工程と、
前記業務ロジック部が、前記トランザクション要求にしたがって処理を実行し、データベースアクセス制御部にデータベースアクセス要求を通知する工程と、
前記データベースアクセス制御部が、前記データベースアクセス要求にしたがって、前記データベースの接続中のデータベースインスタンスに対してＳＱＬを発行し、前記データベースインスタンスから送信されたＳＱＬ実行結果が異常終了の場合には、リトライ可否の判定処理を行う工程と、
前記業務処理制御部が、前記リトライ可否の判定処理の結果がリトライ可能であった場合に、前記退避データ格納部から前記トランザクション要求を取得し、前記業務ロジック部に前記トランザクション要求を通知することによりリトライを実行する工程と、備えたデータベース処理方法。
【請求項４】
コンピュータを、
ａｃｔｉｖｅ／ａｃｔｉｖｅ型かつシェアードエブリシング型のクラスタ構成データベースに対してトランザクション処理を実行するデータベース処理装置として機能させるプログラムであって、
前記データベースに対するトランザクション要求を退避データ格納部に格納する業務処理制御部と、
前記業務処理制御部から前記トランザクション要求を受信し、前記トランザクション要求にしたがって前記データベースにアクセスし、処理を実行する業務ロジック部と、
前記業務ロジック部からデータベースアクセス要求を受信したら、前記データベースの接続中のデータベースインスタンスに対してＳＱＬを発行し、前記データベースインスタンスから送信されたＳＱＬ実行結果が異常終了の場合には、リトライ可否の判定処理を行うデータベースアクセス制御部として機能させ、
前記業務処理制御部は、前記リトライ可否の判定処理の結果がリトライ可能であった場合には、前記退避データ格納部から前記トランザクション要求を取得し、前記業務ロジック部に前記トランザクション要求を通知することによりリトライを実行する、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース処理装置、データベース処理方法、及びプログラムに関する。
【背景技術】
【０００２】
ａｃｔｉｖｅ／ａｃｔｉｖｅ型かつシェアードエブリシング型のクラスタ構成データベースは、複数のデータベースインスタンスが共有データベースへアクセスする。このため、一部のインスタンスの障害、すなわち片系障害が発生しても処理を継続できるメリットがある。
【０００３】
データベースインスタンスの障害が発生した時にコミットされたトランザクションは、通常リカバリ又はロールフォワードされ、その時点で処理中のすべてのトランザクションはロールバックされる。例えば特許文献１には、データベースインスタンスの障害時のリカバリのためのログレコードを用いてリカバリを行う方法が記載されている。
【０００４】
ａｃｔｉｖｅ／ａｃｔｉｖｅ型かつシェアードエブリシング型のクラスタ構成データベースにおいて片系障害が発生した場合、障害が発生したデータベースインスタンスへ接続していたトランザクションで実行していたＳＱＬは異常終了する。しかし、ＳＱＬが異常終了した際のエラーコードからは、エラーの原因が片系障害であるのか、アプリケーションに依存するＳＱＬエラーなのかを判断することは出来ない。アプリケーションに依存するＳＱＬエラーであった場合、接続するインスタンスを切り替えてリトライ処理を行っても成功しないため無駄な処理となる。このため、従来はＳＱＬエラーが生じると、トランザクションを異常終了させてオペレータがエラーの原因を分析し、分析結果に応じてリトライの実行可否を決定していた。そのため片系障害が発生した場合でも、トランザクションを再処理するためにはオペレータの介入が必要であった。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１５５６２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
そこで、本発明の目的は、ａｃｔｉｖｅ／ａｃｔｉｖｅ型かつシェアードエブリシング型のクラスタ構成データベースにおいて片系障害が発生した場合に、トランザクションを異常終了させずに処理を継続し、かつ無駄なリトライ処理を行わないことである。
【課題を解決するための手段】
【０００７】
本発明に係るデータベース処理装置は、ａｃｔｉｖｅ／ａｃｔｉｖｅ型かつシェアードエブリシング型のクラスタ構成データベースに対してトランザクション処理を実行するデータベース処理装置であって、データベースに対するトランザクション要求を退避データ格納部に格納する業務処理制御部と、業務処理制御部からトランザクション要求を受信し、トランザクション要求にしたがってデータベースにアクセスし、処理を実行する業務ロジック部と、業務ロジック部からデータベースアクセス要求を受信したら、データベースの接続中のデータベースインスタンスに対してＳＱＬを発行し、データベースインスタンスから送信されたＳＱＬ実行結果が異常終了の場合には、リトライ可否の判定処理を行うデータベースアクセス制御部と、を備え、業務処理制御部は、リトライ可否の判定処理の結果がリトライ可能であった場合には、退避データ格納部からトランザクション要求を取得し、業務ロジック部にトランザクション要求を通知することによりリトライを実行するものである。
【発明の効果】
【０００８】
本発明によれば、データベースインスタンスから送信されたＳＱＬ実行結果が異常終了の場合にはリトライ判定処理を行い、リトライ可能であった場合にのみリトライを行うようにしたので、トランザクション自体に問題がある場合に無駄なリトライ処理を行うことを防ぐことができる。また、片系障害の場合は、異常終了させずに処理を継続することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態による業務処理サーバの構成を示すブロック図である。
【図２】本発明の実施形態による業務処理サーバの動作を示すチャート図である。
【発明を実施するための形態】
【００１０】
次に、本発明を実施するための最良の形態について、図面を参照して詳細に説明する。
図１は、本発明の実施形態による業務処理サーバ（データベース処理装置）１の構成を示すブロック図である。図に示すように、業務処理サーバ１は、業務処理制御部１１、退避データ格納部１２、業務ロジック部１３、データベースアクセス制御部１４を備えている。また、データベースアクセス制御部１４は、リトライ可否判断部１５を備えている。業務処理制御部１１、業務ロジック部１３、データベースアクセス制御部１４は、プログラムに従ってコンピュータのプロセッサが行う動作のモジュールを表しており、これらは一体として業務処理サーバ１のプロセッサの機能を構成する。退避データ格納部１２は、メモリ、ハードディスク等の記憶装置である。
【００１１】
業務処理サーバ１は、通信回線を介してデータベースシステム５と接続されている。データベースシステム５は、ａｃｔｉｖｅ／ａｃｔｉｖｅ型かつシェアードエブリシング型のクラスタ構成データベースであり、データベース５０と、２つのデータベースインスタンス５１ａ，５１ｂが含まれ、データベースインスタンス５１ａ，５１ｂは、それぞれデータベース５０に対する操作を行う。
【００１２】
また、業務処理サーバ１は、通信回線を介して業務端末３と接続されており、業務端末３から業務電文（トランザクション要求）を受信し、処理結果を業務端末３へ送信する。なお、図１の例では業務端末３は１つであるが、業務端末３は複数接続されていてもよい。
【００１３】
業務処理サーバ１の構成について詳しく説明する。
業務処理制御部１１は、業務端末３から業務電文を受信し、受信した業務電文を退避データ格納部１２に格納する。また、業務処理制御部１１は、受信した業務電文を業務ロジック部１３に通知する。
【００１４】
業務ロジック部１３は、業務処理制御部１１から受信した業務電文にしたがって業務ロジック処理を実行する。業務ロジック部１３は、業務ロジック処理においてデータベースシステム５にアクセスする場合は、データベースアクセス制御部１４にデータベースアクセス要求を通知する。
【００１５】
データベースアクセス制御部１４は、業務ロジック部１３よりデータベースアクセス要求を受信したら、データベースシステム５に対してＳＱＬを発行する。データベースシステム５から送信されたＳＱＬ実行結果が異常終了の場合には、リトライ可否判断部１５においてリトライ可否の判定処理を行う。
【００１６】
次に、本実施形態による業務処理サーバ１の動作について図２を用いて説明する。
まず、業務処理制御部１１は、業務端末３より業務電文を受信する（ステップＳ１）。
【００１７】
次に、業務処理制御部１１は、退避データ格納部１２に受信した業務電文を格納する（ステップＳ２）。さらに、業務処理制御部１１は、業務ロジック部１３に業務電文を通知する（ステップＳ３）。
【００１８】
業務ロジック部１３は、業務電文に基づいて業務ロジック処理のトランザクションを工程順に実行する（ステップＳ４）。業務ロジック部１３は、データベースシステム５へのアクセス処理があるか否かを判断する（ステップＳ５）。データベースシステム５へのアクセス処理がある場合は、ステップＳ６へ進み、データベースアクセス制御部１４にデータベースアクセス要求を通知する。一方、データベースシステム５へのアクセス処理がない場合は、ステップＳ７へ進む。ステップＳ７では、業務ロジック部１３は、業務ロジック処理のトランザクションが全て終了したか否かを判定し、終了した場合にはステップＳ１５へ進む。終了していない場合にはステップＳ４へ移行し、業務ロジック部１３は次のトランザクションを実行する。
【００１９】
ステップＳ１５では、業務処理制御部１１が、退避データ格納部１２に格納した業務電文を削除する。さらに、ステップＳ１６において、業務処理制御部１１は、業務端末３へ正常終了の応答を送信する。これで、業務端末３からの業務電文に対応した業務ロジック処理が完了する。
【００２０】
データベースアクセス制御部１４は、データベースアクセス要求に基づいて、データベースシステム５に対してＳＱＬを発行する（ステップＳ８）。このとき、データベースアクセス制御部１４は、データベースインスタンス５１ａ、またはデータベースインスタンス５１ｂのどちらか接続されている方のデータベースインスタンスに対してＳＱＬを発行する。
【００２１】
次に、データベースアクセス制御部１４は、データベースシステム５からＳＱＬ実行結果を受信し、結果が正常終了の場合にはステップＳ４に戻る（ステップＳ９）。業務ロジック部１３は、次のトランザクションを実行し、データベースシステム５へのアクセス処理がある場合には、引き続きデータベースアクセス制御部１４にデータベースアクセス要求を通知する。
【００２２】
ステップＳ９で、ＳＱＬ実行結果が異常終了だった場合には、ステップＳ１０へ進む。
ステップＳ１０では、リトライ可否判断部１５がロールバック処理を実行する。次に、ステップＳ１１で、リトライ可否判断部１５はロールバックが成功したか否か判定する。ロールバックが成功した場合には、ＳＱＬを発行したデータベースインスタンス（データベースインスタンス５１ａまたはデータベースインスタンス５１ｂ）の障害による問題ではなく、業務ロジック部１３が実行するアプリケーションに依存するＳＱＬエラーであると考えられることから、リトライ可否判断部１５はリトライ不可と判断し、ステップＳ１７へ進む。
【００２３】
ステップＳ１７では、業務処理制御部１１が、退避データ格納部１２に格納した業務電文を削除する。さらに、ステップＳ１８において、業務処理制御部１１は、業務端末３へ異常終了の応答を送信する。これで、業務端末３からの業務電文に対応した業務ロジック処理が完了する。
【００２４】
一方、ステップＳ１１でロールバック処理が失敗した場合、リトライ可否判断部１５は、ＳＱＬを発行したデータベースインスタンスの障害であると判断し、ステップＳ１２へ進む。ステップＳ１２では、データベースアクセス制御部１４は、他方のデータベースインスタンスへ接続を切り替える。
【００２５】
次に、ステップＳ１３において、リトライ可否判断部１５は、他方のデータベースインスタンスへの切り替えが成功したか否かを判定する。切り替えが失敗した場合には、両方のデータベースインスタンス５１ａ，５１ｂに障害があると考えられることから、リトライ可否判断部１５はリトライ不可と判断し、ステップＳ１７へ進む。
【００２６】
ステップＳ１３で、データベースインスタンスの切り替えが成功した場合には、リトライ可否判断部１５はリトライ可能と判断し、ステップＳ１４へ進む。
【００２７】
ステップＳ１４では、業務処理制御部１１は退避データ格納部１２から格納しておいた業務電文を取得する。さらにステップＳ３へ移行し、業務処理制御部１１は業務ロジック部１３に業務電文を通知する。
【００２８】
業務ロジック部１３は、業務電文に基づいてトランザクションを実行し、データベースシステム５へのアクセス処理が必要な場合は、データベースアクセス制御部１４にデータベースアクセス要求を通知する（ステップＳ４、５）。
【００２９】
以上のように、本実施形態によれば、データベースシステム５から送信されたＳＱＬ実行結果が異常終了の場合には、リトライ可否判断部１５においてリトライ判定処理を行い、接続中のデータベースインスタンスに障害があり、かつ他方のデータベースインスタンスは正常に稼動していると判断された場合、すなわち片系障害であると判断された場合に、他方のデータベースインスタンスに対してリトライを行うようにした。これにより、片系障害の場合に、トランザクションを異常終了させてオペレータが介入しなくてもリトライ処理を行うことができ、また、業務アプリケーション自体に問題がある場合、または両方のデータベースインスタンスに障害がある場合には、無駄なリトライ処理を行ってしまうことを防ぐことができる。
【００３０】
また、リトライ可否の判定はデータベースアクセス制御部１４に含まれるリトライ可否判断部１５で行い、リトライ可能と判断した場合には業務処理制御部１１から再度、業務ロジック部１３に業務電文が通知されるようにしたので、業務ロジック部１３において実行されるアプリケーションは、リトライ処理を考慮せずに開発することができる。
【符号の説明】
【００３１】
１  業務処理サーバ、３  業務端末、５  データベースシステム、１１  業務処理制御部、１２  退避データ格納部、１３  業務ロジック部、１４  データベースアクセス制御部、１５  リトライ可否判断部、５０  データベース、５１ａ，５１ｂ  データベースインスタンス
【図１】
2011086067.tif 000003
【図２】
2011086067.tif 000004