(57)【要約】【課題】  データ処理部が冗長化されたデータベースクライアントで異常に伴う系切替が発生した場合の影響を低減する。【解決手段】  本発明は、データベースサーバと、冗長構成が形成されているデータベースクライアントとを備えるデータベースシステムに関する。そしてデータベースシステムは、現用系として動作する第１のデータ処理部の異常を検知する手段と、第１のデータ処理部の異常を検知した場合に、待機系として動作する第２のデータ処理部を現用系に切替える処理を行う手段と、接続状態セッションに係るセッション情報を収集する手段と、収集したセッション情報に基づいて接続状態セッションを特定し、データベースサーバに接続状態セッションの切断を実行させる手段と、接続状態セッションを切断する際に当該接続状態セッション係るデータのロールバックを実行する手段とを有することを特徴とする。【選択図】      図１
2014137798.tif 000002
【特許請求の範囲】
【請求項１】
データベースサーバと、複数のデータ処理部で冗長構成が形成されているデータベースクライアントとを備えるデータベースシステムにおいて、
第１のデータ処理部が現用系として動作しているときに、上記第１のデータ処理部で異常が発生したことを検知する異常検知手段と、
上記異常検知手段が上記第１のデータ処理部の異常を検知した場合に、待機系として動作している第２のデータ処理部を現用系に切替える処理を行う系切替手段と、
上記第１のデータ処理部が異常発生時に、上記データベースサーバと接続状態であった接続状態セッションに係るセッション情報を収集するセッション情報収集手段と、
上記セッション情報収集手段が収集したセッション情報に基づいて、上記データベースサーバ上の上記第１のデータ処理部に係る接続状態セッションを特定し、上記データベースサーバに、上記第１のデータ処理部に係る接続状態セッションの切断を実行させるセッション切断手段と、
上記セッション切断手段が接続状態セッションを切断する際に、上記データベースサーバ上で、当該接続状態セッションで更新されたデータについて、当該接続状態セッションによる更新前の状態にロールバックさせるロールバック手段と
を有することを特徴とするデータベースシステム。
【請求項２】
上記セッション切断手段及び上記ロールバック手段の処理は、上記系切替手段による系切替処理の前に実行されることを特徴とする請求項１に記載のデータベースシステム。
【請求項３】
データベースサーバと、複数のデータ処理部で冗長構成が形成されているデータベースクライアントとを備えるデータベースシステムの制御方法において、
異常検知手段、系切替手段、セッション情報収集手段、セッション切断手段及びロールバック手段を備え、
上記異常検知手段は、第１のデータ処理部が現用系として動作しているときに、上記第１のデータ処理部で異常が発生したことを検知し、
上記系切替手段は、上記異常検知手段が上記第１のデータ処理部の異常を検知した場合に、待機系として動作している第２のデータ処理部を現用系に切替える処理を行い、
上記セッション情報収集手段は、上記第１のデータ処理部が異常発生時に、上記データベースサーバと接続状態であった接続状態セッションに係るセッション情報を収集し、
上記セッション切断手段は、上記セッション情報収集手段が収集したセッション情報に基づいて、上記データベースサーバ上の上記第１のデータ処理部に係る接続状態セッションを特定し、上記データベースサーバに、上記第１のデータ処理部に係る接続状態セッションの切断を実行させ、
上記ロールバック手段は、上記セッション切断手段が接続状態セッションを切断する際に、上記データベースサーバ上で、当該接続状態セッションで更新されたデータについて、当該接続状態セッションによる更新前の状態にロールバックさせる
ことを特徴とするデータベースシステムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データベースシステム及びデータベースシステムの制御方法に関し、例えば、冗長構成のデータベースクライアントを備えるデータベースシステムに適用し得る。
【背景技術】
【０００２】
データベースシステムには、データベースサーバと、データベースサーバのデータ利用を行うデータベースクライアントとが配置されている。そして、従来のデータベースクライアントがデータベースサーバ上のデータ更新を行う場合は、通常、データベースサーバに対してデータ更新を要求し、更新データをコミットする手続きを１つのトランザクションとして実行することにより、データ更新を行う。なお、本明細書では、データベースサーバ上のデータ更新は、新たなデータの登録、データベースに記録された任意のデータの更新、データベースに記録された任意のデータの削除等を含む用語であるものとする。
【０００３】
そして、従来のデータベースシステムでは、データベースサーバ又はデータベースクライアントで異常が発生した場合には、データベースサーバは、必要に応じて更新後コミットされていないデータについて、ロールバックする処理を行うことにより、データの整合性を保つものがある。
【０００４】
ロールバック機能に対応した従来のデータベースシステムとしては、特許文献１の記載技術がある。特許文献１に記載のシステムでは、システムの再起動等が必要となった場合に、効率的にデータの整合性を回復するロールバック処理を実行するために、回復ログ（動作履歴のログ）について複数種類のデータ記録媒体（低速不揮発性記憶域及び高速揮発性記憶域）を利用して記録しておくことについて記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平０７−０８４８１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、従来のデータベースシステムでは、データベースサーバを利用するデータベースクライアント側でも、データ処理を行うデータ処理部（サーバ等のコンピュータ）を冗長化したものがある。そして、そのような冗長化されたデータベースクライアントで、データ処理部についてクラスタリングの冗長構成が組まれている場合、現用系（以下、「ＡＣＴ系」とも呼ぶ）の第１のデータ処理部で障害（異常）が発生すると、系切替により待機系（以下、「スタンバイ系」又は「ＳＢＹ系」とも呼ぶ）の第２のデータ処理部がＡＣＴ系として動作する。
【０００７】
しかし、旧ＡＣＴ系のコンピュータで異常が発生したときに保持していたセッションで、データベース上の更新中のデータ（更新後コミットされていないデータ）が保持された状態（他のセッションにデータ更新が解放されていない状態）だった場合、当該データが保持された状態を継続することになる。その結果、新たにＡＣＴ系として動作する第２のデータ処理部では、第１のデータ処理部に保持された状態のデータの更新をすぐに行うことができず、系切替直後の動作に支障を生じることになる。
【０００８】
そこで、上述のような問題点に鑑み、データベースサーバのデータにアクセスするデータ処理部が冗長化されたデータベースクライアントで、異常に伴う系切替が発生した場合の影響を低減することができるデータベースシステム及びデータベースシステムの制御方法が望まれている。
【課題を解決するための手段】
【０００９】
第１の本発明は、データベースサーバと、複数のデータ処理部で冗長構成が形成されているデータベースクライアントとを備えるデータベースシステムにおいて、（１）第１のデータ処理部が現用系として動作しているときに、上記第１のデータ処理部で異常が発生したことを検知する異常検知手段と、（２）上記異常検知手段が上記第１のデータ処理部の異常を検知した場合に、待機系として動作している第２のデータ処理部を現用系に切替える処理を行う系切替手段と、（３）上記第１のデータ処理部が異常発生時に、上記データベースサーバと接続状態であった接続状態セッションに係るセッション情報を収集するセッション情報収集手段と、（４）上記セッション情報収集手段が収集したセッション情報に基づいて、上記データベースサーバ上の上記第１のデータ処理部に係る接続状態セッションを特定し、上記データベースサーバに、上記第１のデータ処理部に係る接続状態セッションの切断を実行させるセッション切断手段と、（５）上記セッション切断手段が接続状態セッションを切断する際に、上記データベースサーバ上で、当該接続状態セッションで更新されたデータについて、当該接続状態セッションによる更新前の状態にロールバックさせるロールバック手段とを有することを特徴とする。
【００１０】
第２の本発明は、データベースサーバと、複数のデータ処理部で冗長構成が形成されているデータベースクライアントとを備えるデータベースシステムの制御方法において、（１）異常検知手段、系切替手段、セッション情報収集手段、セッション切断手段及びロールバック手段を備え、（２）上記異常検知手段は、第１のデータ処理部が現用系として動作しているときに、上記第１のデータ処理部で異常が発生したことを検知し、（３）上記系切替手段は、上記異常検知手段が上記第１のデータ処理部の異常を検知した場合に、待機系として動作している第２のデータ処理部を現用系に切替える処理を行い、（４）上記セッション情報収集手段は、上記第１のデータ処理部が異常発生時に、上記データベースサーバと接続状態であった接続状態セッションに係るセッション情報を収集し、（５）上記セッション切断手段は、上記セッション情報収集手段が収集したセッション情報に基づいて、上記データベースサーバ上の上記第１のデータ処理部に係る接続状態セッションを特定し、上記データベースサーバに、上記第１のデータ処理部に係る接続状態セッションの切断を実行させ、（６）上記ロールバック手段は、上記セッション切断手段が接続状態セッションを切断する際に、上記データベースサーバ上で、当該接続状態セッションで更新されたデータについて、当該接続状態セッションによる更新前の状態にロールバックさせることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、データベースサーバのデータにアクセスするデータ処理部が冗長化されたデータベースクライアントで、系切替が発生した場合の影響を低減することができるデータベースシステムを提供することができる。
【図面の簡単な説明】
【００１２】
【図１】実施形態に係るデータベースシステムの全体構成について示したブロック図である。
【図２】実施形態に係るデータベースシステムにおけるレコード更新の基本動作について示したシーケンス図である。
【図３】実施形態に係るデータベースシステムにおいて、ＡＣＴ系のアプリケーションプロセスに異常が発生した場合の状態の遷移について示した説明図である。
【図４】実施形態に係るデータベースクライアントで系切替が発生した場合の動作について示したフローチャートである。
【図５】実施形態に係るデータベースクライアントで系切替に伴うセッション切断（強制ロールバック処理を含む）が発生した場合の動作について示したフローチャートである。
【図６】実施形態に係るデータベースシステムにおいて、系切替が発生した場合の状態の遷移について示した説明図（その１）である。
【図７】実施形態に係るデータベースシステムにおいて、系切替が発生した場合の状態の遷移について示した説明図（その２）である。
【発明を実施するための形態】
【００１３】
（Ａ）主たる実施形態
以下、本発明によるデータベースシステム及びデータベースシステムの制御方法の一実施形態を、図面を参照しながら詳述する。
【００１４】
（Ａ−１）実施形態の構成
図１は、この実施形態のデータベースシステム１の全体構成を示すブロック図である。
【００１５】
データベースシステム１には、データベースサーバ１０、及びデータベースクライアント２０が配置されているものとする。なお、データベースサーバ１０とデータベースクライアント２０との間は、ネットワーク接続Ｎ１（接続手段は限定されない）が設定されているまた、データベースクライアント２０の数は限定されないものである。
【００１６】
データベースサーバ１０は、サーバ１１及びファイルシステム１２を有している。
【００１７】
ファイルシステム１２は、データファイルを格納するためのストレージである。図１では、ファイルシステム１２は独立した装置として図示しているが、サーバ１１と一体の装置として構築（内臓ストレージ上に構成）してもよい。
【００１８】
サーバ１１は、ファイルシステム１２に格納されたデータを処理して、データベースクライアント２０に対してデータベースサービスを提供する装置（コンピュータ）である。サーバ１１上では、データベースサービスのアプリケーションとしてサーバプロセス１１１が動作している。すなわち、サーバ１１には、データベースサービスのプログラムがインストールされており、サーバ１１上でそのプログラムを実行することにより、サーバプロセス１１１が起動する。
【００１９】
ファイルシステム１２には、管理対象となるデータ自体を格納するためのデータ記憶領域１２１と、データ更新のロールバック等を実現するためのログ記憶領域１２２とが確保されているものとする。サーバプロセス１１１は、データ記憶領域１２１の各データを処理単位（以下では、この処理単位を「レコード」と呼ぶ）ごとに、状態管理する、また、サーバプロセス１１１は、データ記憶領域１２１の各レコードについて、更新を行った場合には、その更新に係る履歴情報を、ロールバック可能な形式で、ログ記憶領域１２２に記憶する処理も行うものとする。
【００２０】
データベースクライアント２０は、データベースサーバ１０からデータベースサービスの提供を受ける装置（コンピュータ）である。なお、データベースクライアント２０は、単純にデータベースを利用するクライアント端末ではなく、データベースを利用したアプリケーションサービス（例えば、ウェブサーバやコールセンタサーバの機能等）を他の端末等に提供するものとしても良いことは当然である。また、データベースクライアント２０では、複数のサーバ３０（コンピュータ）による冗長構成が組まれているものとする。
【００２１】
この実施形態では、データベースクライアント２０は、２台のサーバ３０（３０−１、３０−２）による冗長構成となっているものとする。なお、データベースクライアント２０内の冗長系（サーバ３０）の数は限定されないものである。
【００２２】
そして、データベースクライアント２０では、複数のサーバ３０のうち、いずれかがＡＣＴ系として動作し、他のサーバ３０がＳＢＹ系として動作する冗長構成（クラスタリング構成）となっているものとする。
【００２３】
すなわち、データベースクライアント２０では、複数のハードウェア（サーバ３０−１、３０−２）を論理的に１つのサーバとして動作するようなクラスタリング構成となっている。そして、サーバ３０間では、クラスタリング構成を実現するために相互通信可能なネットワーク接続Ｎ２（通信路）が設定されている。各サーバ３０間のネットワーク接続Ｎ２の通信方式は限定されないものであり、例えば、各種イーサネット（登録商標）やファイバーチャネル等の種々の通信方式（インタフェース）を適用することができる。また、この実施形態では、ネットワーク接続Ｎ１、Ｎ２は別個の通信路として説明しているが、同じ通信路（通信媒体）を共用するようにしてもよい。
【００２４】
次に、各サーバ３０の内部構成について説明する。この実施形態では、各サーバ３０は全て同じ構成であるものとして説明する。
【００２５】
各サーバ３０は、ハードウェア３１（コンピュータ）上に、ＯＳ及び各種ソフトウェアがインストールされた構成となっており、起動した状態の機能的構成としては図１のように示すことができる。図１では、各サーバ３０には、ＯＳの機能により起動するカーネル３２上で、冗長構成系等の管理を行うためのミドルウェアとして障害管理３３、及び系構成管理３４が動作している。そして、各サーバ３０において、上述のミドルウェア上では、データベースクライアントとしてアプリケーションプロセス３５が動作している。
【００２６】
上述の通り、データベースクライアント２０は、１台以上在っても良く、提供するサービス毎にサーバを分けたり、負荷分散で同一サービスの提供をすることが可能である。
【００２７】
データベースクライアント２０では、通常、サービスを提供するアプリケーションプロセス３５はＡＣＴ系側のプロセスであり、ＳＢＹ系のアプリケーションプロセス３５は、空転（または、未起動）状態となる。データベースクライアント２０において、このような、クラスタリング構成の制御（例えば、系切り替えやアプリケーションプロセス３５の起動／停止制御等）については、サーバ３０のミドルウェア（障害管理３３及び系構成管理３４）の相互通信により行われる。
【００２８】
なお、図１では、データベースクライアント２０とデータベースサーバ１０との間のネットワーク接続Ｎ１として、１本の線により論理的構成を図示している。しかし、実際には、ネットワーク接続Ｎ１は、各サーバ３０が他のサーバ３０の動作に拘わらずデータベースサーバ１０と通信可能な接続構成となっている必要がある。例えば、それぞれのサーバ３０がネットワークインタフェースを備え、それぞれネットワーク接続する構成（例えば、ＶＲＲＰ（Ｖｉｒｔｕａｌ  Ｒｏｕｔｅｒ  Ｒｅｄｕｎｄａｎｃｙ  Ｐｒｏｔｏｃｏｌ）の構成）としても良いし、データベースクライアント２０内で図示しない通信制御装置（例えば、レイヤ２スイッチ等のスイッチ装置）を備えて、各サーバ３０をネットワーク接続する構成としてもよい。さらに、図１では、データベースサーバ１０側は冗長構成として図示していないが、冗長構成としてもよいことは当然である。
【００２９】
次に、データベースクライアント２０（アプリケーションプロセス３５）とデータベースサーバ１０（サーバプロセス１１１）とが協働して行うデータ処理について説明する。
【００３０】
アプリケーションプロセス３５とサーバプロセス１１１との間のデータ処理は、トランザクション単位で実行されるものとする。そして、アプリケーションプロセス３５とサーバプロセス１１１との間では、１つのセッション開始から終了までに行われる処理を１つのトランザクションとして管理されるものとして説明する。例えば、アプリケーションプロセス３５とサーバプロセス１１１との間で、１つのセッション（トランザクション）について、ユニークなＩＤが付与される。
【００３１】
また、サーバプロセス１１１は、各データの整合性等を保つために、各レコードの状態を管理（アクセス管理）しながらトランザクション処理を実行する。この実施形態では、例として、サーバプロセス１１１は、各レコードについて、現在処理中のセッション（トランザクション）以外からのアクセスを禁止する「競合ロック状態」、又は、いずれのセッション（トランザクション）からもアクセス可能な「解放状態」のいずれかの状態で管理されるものとする。サーバプロセス１１１は、データベースクライアント２０からの要求に応じて、データ記憶領域１２１のレコードのレコードを更新すると、当該レコードについて「競合ロック状態」として管理する。そして、その後、サーバプロセス１１１は、データベースクライアント２０（更新したアプリケーションプロセス３５）からの要求に応じて、当該レコードのコミットを行った後、当該レコードを解放状態として管理する。サーバプロセス１１１は、競合ロック状態のレコードについては、他のトランザクションからのデータ更新を待ち合わせ状態として管理し、解放状態となった後に更新を行う。
【００３２】
（Ａ−２）実施形態の動作
次に、以上のような構成を有するこの実施形態のデータベースシステム１の動作（実施形態のデータベースシステムの制御方法）を説明する。
【００３３】
（Ａ−２−１）データ更新の基本シーケンス
図２は、データベースサーバ１０（ファイルシステム１２のデータ記憶領域１２１）上で任意のデータ（以下、「レコードＡ」と呼ぶ）を更新する場合のトランザクション処理の例について示したシーケンス図である。
【００３４】
ここでは、データベースクライアント２０は、初期において、サーバ３０−１がＡＣＴ系、サーバ３０−２がＳＢＹ系として動作しているものとして説明する。
【００３５】
まず、データベースクライアント２０におけるＡＣＴ系（サーバ３０−１）のアプリケーションプロセス３５が、データベースサーバ１０（サーバ１１のサーバプロセス１１１）にセッション接続要求（データベース処理に係るセッション接続要求）を送信し（Ｓ１０１）、データベースサーバ１０（サーバプロセス１１１）が、その送信要求について応答（接続ＯＫ）したものとする（Ｓ１０２）。
【００３６】
なお、ＡＣＴ系のアプリケーションプロセス３５は、データベースサーバ１０ヘのアクセスが必要となる都度セッション生成するようにしてもよいし、予め用意された接続セッションを排他的に確保して利用しても良い。
【００３７】
そして、ＡＣＴ系のアプリケーションプロセス３５は、データベースサーバ１０（サーバプロセス１１１）とのセッションを保持（生成又は確保）した後、任意のレコードＡについて内容を変更する更新要求を送信したものとする（Ｓ１０３）。
【００３８】
そして、レコードＡの更新要求を受けたデータベースサーバ１０（サーバプロセス１１１）は、ファイルシステム１２（データ記憶領域１２１）のレコードＡについて更新処理を行ったものとする（Ｓ１０４）。ここでは、レコードＡの初期状態は解放状態で、データベースサーバ１０（サーバプロセス１１１）によるレコードＡの更新は成功したものとする。そして、データベースサーバ１０（サーバプロセス１１１）は、レコードＡを、競合ロック状態として管理する。以後、データベースサーバ１０（サーバプロセス１１１）は、レコードＡについて、コミットによる更新確定までの間は、他接続セッション（トランザクション）からの更新要求は、待ち合わせ状態として管理する。また、データベースサーバ１０（サーバプロセス１１１）は、データ記憶領域１２１のレコードＡについて、更新前の状態へロールバック可能とするためのログ情報をログ記憶領域１２２に記憶する。
【００３９】
そして、データベースサーバ１０（サーバプロセス１１１）は、レコードＡの更新結果（更新成功）を、ＡＣＴ系のアプリケーションプロセス３５に応答する（Ｓ１０５）。
【００４０】
そして、更新成功の更新結果を受けたＡＣＴ系のアプリケーションプロセス３５は、データベースサーバ１０（サーバプロセス１１１）に、レコードＡのコミット要求を送信する（Ｓ１０６）。
【００４１】
そして、レコードＡのコミット要求を受けたデータベースサーバ１０（サーバプロセス１１１）は、レコードＡのコミット処理（競合ロック状態を解除して解放状態とする処理）を実行し（Ｓ１０７）、コミット処理の結果（コミット成功）をＡＣＴ系のアプリケーションプロセス３５に応答する（Ｓ１０８）。
【００４２】
上述のように、データベースサーバ１０（サーバプロセス１１１）は、コミットによる更新レコードの確定について、トランザクション単位に実行する。また、データベースサーバ１０（サーバプロセス１１１）では、このコミット処理が実施されたことを契機として、レコードＡの競合ロック状態が解除され、他トランザクションからレコードＡへのデータ更新（待ち合わせ状態のトランザクション等）が可能となる。これにより、データベースサーバ１０（サーバプロセス１１１）では、関連性のあるレコードの更新において、内容の矛盾が発生しない（整合性を保つ）ことを保障する。
【００４３】
そして、ＡＣＴ系のアプリケーションプロセス３５は、データベースサーバ１０（サーバプロセス１１１）に対してセッションの切断を要求し（Ｓ１０９）、一連のトランザクション（セッション）の処理が終了する。
【００４４】
なお、ＡＣＴ系のアプリケーションプロセス３５では、図１に示す一連の処理（接続セッション生成から、切断まで）の詳細を、メモリ上で管理する必要がある（この手続き単位を、以下では、「コンテキスト」、又は「ハンドラ」と呼ぶ）。
【００４５】
（Ａ−２−２）レコード更新後、コミット処理前に異常が発生した場合
次に、上述の図２のシーケンスにおいて、データベースシステム１（サーバプロセス１１１）がレコードＡの更新を実行した後、コミット処理前（ステップＳ１０３の処理後から、ステップＳ１０７の処理前までの間）に、ＡＣＴ系のアプリケーションプロセス３５が異常状態（例えば、コアダンプを出力した状態）となった場合の動作について説明する。  
図３では、上述の図２のシーケンスにおいて、ステップＳ１０３の処理後から、ステップＳ１０７の処理前までの間に、ＡＣＴ系のアプリケーションプロセス３５が異常となった状態について示している。すなわち、この時点では、レコードＡに対するコミット処理が未実施であるため、レコードＡは競合ロック状態となっている。
【００４６】
そして、図３では、この時点で、ＡＣＴ系のアプリケーションプロセス３５（サーバ３０−１のアプリケーションプロセス３５）が異常状態となり、障害管理３３でその異常状態が検知され、系構成管理３４により系切替が開始されたものとする。そして、このとき、データベースクライアント２０で系切替が実行される場合の動作について図４、図５のフローチャートを用いて説明する。
【００４７】
図４、図５では、ＡＣＴ系として動作していたサーバ３０−１がＳＢＹ系に切り替わり、ＳＢＹ系として動作していたサーバ３０−２がＡＣＴ系に切り替わる動作について示している。そして、図４、図５では、ＡＣＴ系として動作していたサーバ３０−１を「旧ＡＣＴ系」又は「新ＳＢＹ系」と図示している。また、図４、図５では、ＳＢＹ系として動作していたサーバ３０−２を、「新ＡＣＴ系」又は「旧ＳＢＹ系」と図示している。
【００４８】
まず、旧ＡＣＴ系（サーバ３０−１）の系構成管理３４で、系切替が決定され、通信により、旧ＳＢＹ系（サーバ３０−２）の系構成管理３４に、系切替の要求が通知されたものとする。そして、旧ＳＢＹ系（サーバ３０−２）では、系構成管理３４からアプリケーションプロセス３５に、新ＡＣＴ系として起動することの要求（再開起動要求）があったものとする。そして、旧ＳＢＹ系（サーバ３０−２）のアプリケーションプロセス３５が、その再開起動要求を受付けたものとする（Ｓ２０１）。
【００４９】
そして、サーバ３０−２のアプリケーションプロセス３５は、再開起動要求を受付けると、旧ＳＢＹ系から新ＡＣＴ系に遷移する処理を開始する。具体的には、サーバ３０−２のアプリケーションプロセス３５は、旧ＳＢＹ系から新ＡＣＴ系に遷移する際、データベースサーバ１０と協働して、旧ＡＣＴ系のアプリケーションプロセス３５で未完結となっているセッション（接続状態となっているセッション）について、強制的に切断するセッション切断処理を行う。そして、このセッション切断処理に伴って、データベースサーバ１０では、旧ＡＣＴ系のアプリケーションプロセス３５で未完結となっているセッションに係る競合ロック状態のレコードを、強制的にロールバックする処理（以下、「強制ロールバック処理」と呼ぶ）が行われる（Ｓ２０２）。
【００５０】
旧ＡＣＴ系のアプリケーションプロセス３５で未完結となっているトランザクションに係るセッションは、データベースサーバ１０側では継続しており、レコードＡの状態も競合ロック状態のままである。そこで、サーバ３０−２のアプリケーションプロセス３５は、旧ＳＢＹ系から新ＡＣＴ系に遷移する際に、セッション切断処理（強制ロールバック処理を含む）を実行することにより、データベースサーバ１０側の状態を、旧ＡＣＴ系のアプリケーションプロセス３５がセッション（トランザクション）を開始する前の状態に復帰させる。すなわち、セッション切断処理（強制ロールバック処理を含む）により、レコードＡは更新前の状態にロールバックされ、さらに競合ロック状態から解放されて解放状態に復帰し、他セッション（トランザクション）によるデータ更新も可能となる。
【００５１】
セッション切断処理が終了すると、サーバ３０−２のアプリケーションプロセス３５は、旧ＳＢＹ系から新ＡＣＴ系に遷移する初期設定処理を実行し（Ｓ２０３）、サービスを再開し（Ｓ２０４）、データベースサーバ１０に対して新たな更新要求を送信可能な状態となる。
【００５２】
次に、サーバ３０−２のアプリケーションプロセス３５によるセッション切断処理（強制ロールバック処理を含む）の詳細について図５のフローチャートを用いて説明する。
【００５３】
サーバ３０−２のアプリケーションプロセス３５は、セッション切断処理を開始すると、データベースサーバ１０（サーバプロセス１１１）とのセッションを接続し（Ｓ３０１）、旧ＡＣＴ系アプリケーションプロセス３５に係る継続中のセッション情報（トランザクション情報）の収集を試みる（Ｓ３０２）。
【００５４】
ここで、サーバ３０−２のアプリケーションプロセス３５が収集するセッション情報の形式は限定されないものであるが、例えば、現在サーバプロセス１１１で接続中のセッションのＩＤの一覧としてもよい。
【００５５】
そして、サーバ３０−２のアプリケーションプロセス３５は、収集したセッション情報から、旧ＡＣＴ系アプリケーションプロセス３５に係る継続中のセッションの有無を確認する（Ｓ３０３）。そして、サーバ３０−２のアプリケーションプロセス３５は、該当するセッションを検出した場合には、後述するステップＳ３０４の処理から動作し、該当するセッションが検出できない場合にはセッション切断処理を終了する。
【００５６】
サーバ３０−２のアプリケーションプロセス３５が、収集したセッション情報から、旧ＡＣＴ系アプリケーションプロセス３５に係る継続中のセッションの有無を確認する方法については限定されないものである。サーバ３０−２のアプリケーションプロセス３５は、例えば、旧ＡＣＴ系のサーバ３０−１から、アプリケーションプロセス３５が出力したコアダンプを、系構成管理３４経由で取得して、そのコアダンプから、旧ＡＣＴ系アプリケーションプロセス３５のセッション（セッションＩＤ）を特定し、収集したセッション情報と照合するようにしてもよい。
【００５７】
そして、該当するセッションを検出した場合、サーバ３０−２のアプリケーションプロセス３５は、そのセッションを指定して、データベースサーバ１０（サーバプロセス１１１）に切断を要求する。そして、データベースサーバ１０（サーバプロセス１１１）側で要求されたセッションの処理が実行される。そして、データベースサーバ１０（サーバプロセス１１１）から、サーバ３０−２のアプリケーションプロセス３５に、セッション切断の結果（切断の成功又は失敗）が通知されることになる（Ｓ３０４）。
【００５８】
この場合、サーバ３０−２のアプリケーションプロセス３５には、データベースサーバ１０上で、他のアプリケーションプロセス３５からのセッションであっても切断が可能な権限が付与されている必要がある。また、このとき、サーバ３０−２のアプリケーションプロセス３５は、複数のセッション切断を要求することもありえる。例えば、アプリケーションプロセス３５がマルチスレッド構成で、各スレッドが接続セッションを生成している場合は、旧ＡＣＴ系から複数の接続セッションが存在することとなるためである。
【００５９】
図６は、系切り替え時の新ＡＣＴ系のアプリケーションプロセス３５が再開起動処理時に旧ＡＣＴ系からの接続セッションを強制切断する際のデータベースシステム１の状態について示した説明図である。
【００６０】
図６に示すように、データベースサーバ１０（サーバプロセス１１１）は、要求に基づくセッション切断に伴い、切断されたセッションに係るトランザクションについては、もはや完結することは無いと判断し、当該トランザクションが保持しているレコード（競合ロック状態を維持し、コミット待ちの状態のレコード）のロールバック処理を実施する。言い換えると、データベースサーバ１０は、コミットされていない更新中のレコードに対しては、データベースクライアント２０との疎通が破棄された場合は、コミットではなく、ロールバックを選択し、データを更新前の状態に書き戻す。尚、セッション切断処理開始の条件となる、旧ＡＣＴ系での異常状態検出時（アプリケーションプロセス３５の異常検出時）において、当該アプリケーションプロセス３５は、実行中トランザクションを完結することはできないため、上述の接続セッション切断及びロールバックの処理は、期待される動作といえる。
【００６１】
そして、サーバ３０−２のアプリケーションプロセス３５は、切断要求した全てのセッション切断（強制ロールバック処理を含む）が成功したか否かを確認する（Ｓ３０５）。サーバ３０−２のアプリケーションプロセス３５は、切断要求した全てのセッション切断が成功した場合には、強制ロールバック処理を終了し、そうでない場合（未完了）の場合には、上述のステップＳ３０２に戻り、再度セッション切断の処理を実行する。
【００６２】
図７は、系切り替え時の新ＡＣＴ系のアプリケーションプロセス３５が再開起動処理した後（系切替後）のデータベースシステム１の状態について示した説明図である。
【００６３】
図７の状態では、新ＡＣＴ系のアプリケーションプロセス３５により、旧ＡＣＴ系の接続セッション切断処理（強制ロールバック処理を含む）が完了している。したがって、図７の状態では、データベースサーバ１０では、レコードＡに係るデータ更新要求の阻害要因は無く、データ更新を実施することが可能となっている。
【００６４】
（Ａ−３）実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。
【００６５】
データベースクライアント２０では、ＡＣＴ系のアプリケーションプロセス３５が異常状態となった場合には、系切替時に新ＡＣＴ系のアプリケーションプロセス３５が、データベースサーバ１０に、旧ＡＣＴ系に係るセッション切断及び強制ロールバック処理を要求する。これにより、新ＡＣＴ系のアプリケーションプロセス３５では、系切替直後であっても、ＡＣＴ系のアプリケーションプロセス３５が異常状態となったことに伴う系切替時の影響（例えば、旧ＡＣＴ系の障害の影響を受け、レコードの競合待ち合わせとなること等）を低減することができる。
【００６６】
（Ｂ）他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【００６７】
（Ｂ−１）上記の実施形態では、図５に示すセッション切断処理について、新ＡＣＴ系のサーバ３０−１が行う場合について説明したが、旧ＡＣＴ系のサーバ３０−１側で、アプリケーションプロセス３５の障害（コアダンプ出力）を、障害管理３３で検出した段階で実行するようにしても良い。また、旧ＡＣＴ系及び新ＡＣＴ系の両方で実行し、より確実にセッション切断処理（強制ロールバック処理を含む）を実行するようにしてもよい。
【００６８】
また、上述の図５に示す処理では、データベースサーバ１０（サーバプロセス１１１）側で、セッション切断に伴って対応するレコードをロールバックするが、データベースクライアント２０側（サーバ３０−２のアプリケーションプロセス３５側）から、セッション又はレコードを指定してロールバックを要求するようにしてもよい。
【００６９】
（Ｂ−２）新ＡＣＴ系のサーバ３０−１で、上述の図５のフローチャートの処理が行われている間、旧ＡＣＴ系アプリケーションプロセス３５では、異常状態（コアダンプ出力の状態）を継続するようにしてもよいし、系構成管理３４により、強制的に終了するようにしてもよい。新ＡＣＴ系からの接続セッション切断要求よりも先に、コアダンプ終了によりアプリケーションプロセス３５が消滅した場合も、最終的には期待通り、ロールバックが実施されるはずだからである。
【符号の説明】
【００７０】
１…データベースシステム、１０…データベースサーバ、１１…サーバ装置、１１１…サーバプロセス、１２…ファイルシステム、１２１…データ記憶領域、１２２…ログ記憶領域、２０…データベースクライアント、３０、３０−１、３０−２…サーバ、３１…ハードウェア、３２…カーネル、３３…障害管理、３４…系構成管理、３５…アプリケーションプロセス。
【図１】
2014137798.tif 000003
【図２】
2014137798.tif 000004
【図３】
2014137798.tif 000005
【図４】
2014137798.tif 000006
【図５】
2014137798.tif 000007
【図６】
2014137798.tif 000008
【図７】
2014137798.tif 000009