(57)【要約】【課題】例えば制御キューという新たなコンポーネント、およびデータのブロッキングとパッケージングを採用することで、大量のデータを高速に処理する並列処理の実現と共に、データベースのコンテンションを回避する。【解決手段】更新対象ＤＢ２６を更新する更新データをデータメッセージとして保管するデータキュー２１と、このデータキュー２１に格納される複数の更新データを関連付けてパッケージ単位とし、このパッケージの内容を記述した制御メッセージを保管する制御キュー２２と、制御キュー２２から制御メッセージを読み取り、パッケージにより関連付けられているデータメッセージをデータキュー２１から取り出してデータベース更新処理を行うデータ処理部５０とを備えた。【選択図】        図１
2004287932.tif 000002
【特許請求の範囲】
【請求項１】
データベースを更新する複数の更新データをブロックとして保管するデータキューと、
前記データキューに格納される複数の前記ブロックを関連付けてパッケージ単位とし、当該パッケージの内容を記述したパッケージ情報を保管する制御キューと、
前記制御キューから前記パッケージ情報を読み取り、前記パッケージにより関連付けられている前記ブロックを前記データキューから取り出してデータベース更新処理を行う処理タスクと
を含むデータベース更新処理システム。
【請求項２】
前記処理タスクを複数設け、
前記複数の処理タスクは、前記制御キューを共用して並列処理を行うことを特徴とする請求項１記載のデータベース更新処理システム。
【請求項３】
前記制御キューは、前記データベース更新処理の順序を守る必要があるデータに関しては、一つの前記パッケージ内に収納されるようにパッケージングがなされることを特徴とする請求項１記載のデータベース更新処理システム。
【請求項４】
データベース更新業務の障害時に、当該データベース更新業務で処理していたブロックに関するパッケージ情報を一時保留する保留キューを更に含む請求項１記載のデータベース更新処理システム。
【請求項５】
データベースに対する更新処理を行うためのデータベース更新処理システムであって、
ソート済み更新データファイルから更新データを読み込み、所定の更新データ単位に独立したバッファを用いてブロッキングを行う手段と、
メッセージＩＤと、複数の更新データを含むブロックをデータキューに書き出す手段と、
所定数のブロックが前記データキューに書き出された後に、当該ブロックの処理単位を特定するパッケージ情報を制御キューに書き出す手段と
を含むデータベース更新処理システム。
【請求項６】
前記制御キューに書き込まれる前記パッケージ情報は、前記データキューに書き出された前記ブロックに含まれる前記メッセージＩＤと同一のメッセージＩＤによって、当該データキューと関連付けがなされていることを特徴とする請求項５記載のデータベース更新処理システム。
【請求項７】
データベースに対する更新処理を行うためのデータベース更新処理システムであって、
更新データのブロックを複数まとめたパッケージ情報を保有する制御キューから当該パッケージ情報を取得するパッケージ情報取得手段と、
前記制御キューに保有される前記パッケージ情報から、前記ブロックを保有するデータキューを特定し、特定された当該データキューから当該ブロックを取得するブロック取得手段と、
前記データベースに対して更新処理を行う更新業務部に、前記ブロック取得手段により取得された前記ブロックを出力する出力手段と
を含むデータベース更新処理システム。
【請求項８】
前記出力手段は、前記ブロック取得手段により取得された前記ブロックに含まれる更新データの内容ごとに決められたデータベース更新業務を呼び出して、当該ブロックを当該データベース更新業務に提供することを特徴とする請求項７記載のデータベース更新処理システム。
【請求項９】
前記制御キューは、複数の前記パッケージ情報を保有すると共に、
前記ブロック取得手段は、特定の前記パッケージ情報に対して関連付けされたデータキューから前記ブロックを取得することを特徴とする請求項７記載のデータベース更新処理システム。
【請求項１０】
前記更新業務部にて障害があった場合に、障害が発生したデータベース更新業務で処理していたブロックに対する前記パッケージ情報を保留キューに出力する保留キュー出力手段を更に含む請求項７記載のデータベース更新処理システム。
【請求項１１】
データベースに対する更新データをソート済み更新データファイルから読み込むステップと、
読み込まれた前記更新データから、所定の更新データ単位にてブロッキングを行うステップと、
前記ブロッキングにより形成されたブロックをデータキューに書き出すステップと、
所定数のブロックが前記データキューに書き出された後に、当該ブロックをまとめて処理するためのパッケージ情報を制御キューに書き出すステップと
を含むデータベース更新のための更新データ入力方法。
【請求項１２】
前記制御キューには複数の前記パッケージ情報が書き込まれると共に、書き込まれた複数の前記パッケージ情報の中の特定のパッケージ情報は、複数の前記ブロックが保管される前記データキューと関連付けがなされていることを特徴とする請求項１１記載のデータベース更新のための更新データ入力方法。
【請求項１３】
更新データのブロックを複数まとめたパッケージ情報を保有する制御キューから当該パッケージ情報を取得するステップと、
前記制御キューに保有される前記パッケージ情報から、前記ブロックを保有するデータキューを特定するステップと、
特定された前記データキューから前記ブロックを取得するステップと、
データベースに対して更新処理を行う更新業務部に、取得された前記ブロックを出力するステップと
を含むデータベース更新のための更新データ処理方法。
【請求項１４】
前記更新業務部にて障害があった場合に、障害が発生したデータベース更新業務で処理していた前記ブロックに対する前記パッケージ情報を保留キューに出力するステップを更に含む請求項１３記載のデータベース更新のための更新データ処理方法。
【請求項１５】
コンピュータに、
データベースに対する更新データをソート済み更新データファイルから読み込む機能と、
読み込まれた前記更新データから、所定の更新データ単位にてブロッキングを行う機能と、
前記ブロッキングにより形成されたブロックをデータキューに書き出す機能と、
所定数のブロックが前記データキューに書き出された後に、当該ブロックをまとめて処理するためのパッケージ情報を制御キューに書き出す機能と
を実現させるプログラム。
【請求項１６】
コンピュータに、
更新データのブロックを複数まとめたパッケージ情報を保有する制御キューから当該パッケージ情報を取得する機能と、
前記制御キューに保有される前記パッケージ情報から、前記ブロックを保有するデータキューを特定する機能と、
特定された前記データキューから前記ブロックを取得する機能と、
データベースに対して更新処理を行う更新業務部に、取得された前記ブロックを出力する機能と
を実現させるプログラム。
【請求項１７】
コンピュータに
前記更新業務部にて障害があった場合に、障害が発生したデータベース更新業務で処理していた前記ブロックに対する前記パッケージ情報を保留キューに出力する機能を更に実現させる請求項１６記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、限られた時間内に大量の更新データを効率良く、かつ、高速に処理するデータベース更新処理システム等に関する。
【０００２】
【従来の技術】
近年、コンピュータと端末装置あるいはコンピュータ同士が通信回線を介して接続されるオンラインシステムでは、ユーザから送信されたメッセージに応答して、所定のデータ処理が施された後、所定の結果を通知するトランザクション処理が広く実施されている。従来のトランザクション処理システムでは、システム内に一つまたは複数のキューを持ち、そのキュー内に蓄えられたトランザクションデータを、シングルタスクまたはマルチタスクで、順次または独立して処理する構成が採用されている。
【０００３】
シングルタスクでトランザクションデータを順次に処理する従来のシステムでは、単位時間あたりにおけるトランザクションデータ処理件数の向上には限界があった。そのために、マルチタスクによる並列処理が検討されてきたが、一つのキューに蓄積された多数トランザクションデータをマルチタスクで効率良く処理することは非常に難しい。そこで、独立に処理可能な複数のトランザクションデータを蓄積するキューと、このキューの制御情報を含む制御テーブルと、キューに蓄積されたトランザクションデータに対して同じ処理を行う複数のタスクを稼動する手段とを備えることで、複数タスクの効率的な並列処理により処理速度を向上することができる並列トランザクション処理システムが提案されている（例えば、特許文献１参照。）。
【０００４】
【特許文献１】
特開平１１−５３２０２号公報（第３−４頁、図１）
【０００５】
【発明が解決しようとする課題】
ここで、例えば、金融機関の情報システムにおけるデータベースを例に挙げると、これらの情報システムでは、（ｉ）一日に数千万件以上の大量データを取り扱う。（ｉｉ）例えば勘定系のログ以外の他業務システムから渡されるファイルにも対応する。（ｉｉｉ）多種多様なデータベース更新を行う。（ｉｖ）データ量の増加に柔軟的に対応する。といった数々の複雑な条件が、データベースの構築に際して前提とされている。
【０００６】
例えば、情報系システムでのデータベースの構築では、これらの条件のもとで所定のデータベース更新処理を行うことが必要となる。しかしながら、データは一定時間間隔で大量に受け渡されるために、限られた時間内にデータベース更新処理を完了させる仕組みが必要となる。また、データ処理中にデータベースを更新するプログラムなどで障害が発生した場合には、障害データを回避させ、後続のデータを処理することが必要となる。上記特許文献１の技術だけでは、例えば、上記金融機関の情報システムが有する各種条件に対して充分に対処することができない。
【０００７】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的とするところは、例えば制御キューという新たなコンポーネント、およびデータのブロッキングとパッケージングを採用することで、大量のデータを高速に処理する並列処理の実現と共に、データベースのコンテンションを回避することにある。
また他の目的は、例えば個々のパッケージ単位で並列処理を行うことで、データベース更新の処理効率を向上させることにある。
更に他の目的は、例えばパッケージングする更新データのキーを事前にソートすることで、データベースのコンテンション（端末同士の使用権の奪い合い）を極小化することにある。
また更に他の目的は、例えばプログラム障害などの起因となったデータを含むパッケージ単位にデータ処理を保留することで、データ量が大量であった場合でも障害時に適切に対処することにある。
【０００８】
【課題を解決するための手段】
かかる目的のもと、本発明では、データベースを更新するｎ個の更新データを一つのブロックとして物理的にブロッキングし、この複数ブロックを一つのまとまりとして、論理的にパッケージングした。そして、このパッケージ単位にパッケージ情報を作成し、制御キューに格納（保管）している。制御キューに格納（保管）されたパッケージ情報は、データ処理部（ストリーマ）によって読み込まれ、読み込んだデータ処理部（ストリーマ）がパッケージ情報に対応するパッケージを処理するように構成した。これによって、複数パッケージ間での並列処理が可能になると共に、一つのパッケージ内のブロックを順次処理することが可能となる。
【０００９】
即ち、本発明が適用されるデータベース更新処理システムは、データベースを更新する複数の更新データをブロックとして保管するデータキューと、このデータキューに格納される複数のブロックを関連付けてパッケージ単位とし、このパッケージの内容を記述したパッケージ情報を保管する制御キューと、制御キューからパッケージ情報を読み取り、パッケージにより関連付けられているブロックをデータキューから取り出してデータベース更新処理を行う処理タスクとを含む。
【００１０】
ここで、この処理タスクを複数設け、複数の処理タスクは、制御キューを共用して並列処理を行うことを特徴とすれば、データベースのコンテンションを回避し、処理効率を向上させることができる点で好ましい。また、この制御キューは、データベース更新処理の順序を守る必要があるデータに関しては、一つのパッケージ内に収納されるようにパッケージングがなされることを特徴とすれば、連続した処理を行う場合などに、順序処理を可能とする点で優れている。
【００１１】
また、データベース更新業務の障害時に、データベース更新業務で処理していたブロックに関するパッケージ情報を一時保留する保留キューを更に含むことを特徴とすれば、障害があった更新データをデータキューより移動させることなく、処理をバイパスさせることができる点で好ましい。
【００１２】
一方、本発明は、データベースに対する更新処理を行うためのデータベース更新処理システムであって、ソート済み更新データファイルから更新データを読み込み、所定の更新データ単位に独立したバッファを用いてブロッキングを行う手段と、メッセージＩＤと複数の更新データを含むブロックをデータキューに書き出す手段と、所定数のブロックがデータキューに書き出された後に、ブロックの処理単位を特定するパッケージ情報を制御キューに書き出す手段とを含む。
【００１３】
ここで、この制御キューに書き込まれるパッケージ情報は、データキューに書き出されたブロックに含まれるメッセージＩＤと同一のメッセージＩＤによって、データキューと関連付けがなされていることを特徴とすることができる。
【００１４】
他方、本発明が適用されるデータベース更新処理システムは、パッケージ情報取得手段により、更新データのブロックを複数まとめたパッケージ情報を保有する制御キューからパッケージ情報を取得し、ブロック取得手段により、制御キューに保有されるパッケージ情報から、ブロックを保有するデータキューを特定し、特定されたデータキューからブロックを取得する。また、出力手段により、データベースに対して更新処理を行う更新業務部に、ブロック取得手段により取得されたブロックを出力している。
【００１５】
ここで、この出力手段は、ブロック取得手段により取得されたブロックに含まれる更新データの内容ごとに決められたデータベース更新業務を呼び出して、ブロックをデータベース更新業務に提供することを特徴としている。尚、この制御キューは、複数のパッケージ情報を保有すると共に、ブロック取得手段は、特定のパッケージ情報に対して関連付けされたデータキューからブロックを取得することを特徴としている。更に、この更新業務部にて障害があった場合に、障害が発生したデータベース更新業務で処理していたブロックに対するパッケージ情報を保留キューに出力する保留キュー出力手段を含むことを特徴とすれば、処理タスクでの再処理を自動的に防止することが可能となる点で優れている。
【００１６】
他の観点から把えると、本発明が適用されるデータベース更新のための更新データ入力方法は、データベースに対する更新データをソート済み更新データファイルから読み込むステップと、読み込まれた更新データから、所定の更新データ単位にてブロッキングを行うステップと、ブロッキングにより形成されたブロックをデータキューに書き出すステップと、所定数のブロックがデータキューに書き出された後に、ブロックをまとめて処理するためのパッケージ情報を制御キューに書き出すステップとを含む。ここで、この制御キューには複数のパッケージ情報が書き込まれると共に、書き込まれた複数のパッケージ情報の中の特定のパッケージ情報は、複数のブロックが保管されるデータキューと関連付けがなされていることを特徴とすることができる。
【００１７】
また、他の観点から把えると、本発明が適用されるデータベース更新のための更新データ処理方法は、更新データのブロックを複数まとめたパッケージ情報を保有する制御キューからパッケージ情報を取得するステップと、制御キューに保有されるパッケージ情報から、ブロックを保有するデータキューを特定するステップと、特定されたデータキューからブロックを取得するステップと、データベースに対して更新処理を行う更新業務部に、取得されたブロックを出力するステップと、更新業務部にて障害があった場合に、障害が発生したデータベース更新業務で処理していたブロックに対するパッケージ情報を保留キューに出力するステップとを含む。
【００１８】
ここで、本発明は、コンピュータに所定の機能を実現させるプログラムとして把握することができる。即ち、本発明が適用されるプログラムは、コンピュータに、データベースに対する更新データをソート済み更新データファイルから読み込む機能と、読み込まれた更新データから、所定の更新データ単位にてブロッキングを行う機能と、ブロッキングにより形成されたブロックをデータキューに書き出す機能と、所定数のブロックがデータキューに書き出された後に、ブロックをまとめて処理するためのパッケージ情報を制御キューに書き出す機能とを実現させる。
【００１９】
また、本発明が適用されるプログラムは、コンピュータに更新データのブロックを複数まとめたパッケージ情報を保有する制御キューからパッケージ情報を取得する機能と、制御キューに保有されるパッケージ情報から、ブロックを保有するデータキューを特定する機能と、特定されたデータキューからブロックを取得する機能と、データベースに対して更新処理を行う更新業務部に、取得されたブロックを出力する機能と、更新業務部にて障害があった場合に、障害が発生したデータベース更新業務で処理していたブロックに対するパッケージ情報を保留キューに出力する機能とを実現させる。
【００２０】
尚、これらのプログラムとしては、コンピュータを顧客に対して提供する際に、装置の中にインストールされた状態にて提供される場合の他、コンピュータに実行させるプログラムをコンピュータが読取可能に記憶した記憶媒体にて提供する形態が考えられる。この記憶媒体としては、例えばＣＤ−ＲＯＭ媒体や磁気テープ等が該当し、ＣＤ−ＲＯＭ読取装置や磁気テープ装置等によってプログラムが読み取られて実行される。また、これらのプログラムは、例えば、プログラム伝送装置によってネットワークを介して提供される形態がある。このプログラム伝送装置は、例えば、ホスト側のサーバに設けられ、プログラムを格納するメモリと、ネットワークを介してプログラムを提供するプログラム伝送手段とを備えている。
【００２１】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて本発明を詳細に説明する。
図９は、本実施の形態において使用可能であるコンピュータシステムの代表的なハードウェア構成の一例を示したものである。コンピュータシステム１００は、中央処理装置（ＣＰＵ）１０１とメインメモリ１０４を含んでいる。ＣＰＵ１０１とメインメモリ１０４は、バス１０２を介して、補助記憶装置としてのハードディスク装置１１３、１３０と接続されている。また、フレキシブルディスク装置１２０、ＭＯ装置１２８、ＣＲ−ＲＯＭ装置１２６、１２９などのリムーバブルストレージ（記録メディアを交換可能な外部記憶システム）が関連するフレキシブルディスクコントローラ１１９、ＩＤＥコントローラ１２５、ＳＣＳＩコントローラ１２７などを介してバス１０２へ接続されている。
【００２２】
フレキシブルディスク装置１２０、ＭＯ装置１２８、ＣＲ−ＲＯＭ装置１２６、１２９などのリムーバブルストレージには、それぞれフレキシブルディスク、ＭＯ、ＣＤ−ＲＯＭなどの記憶媒体が挿入され、このフレキシブルディスク等やハードディスク装置１１３、１３０、ＲＯＭ１１４には、オペレーティングシステム（ＯＳ）と協働して中央処理装置（ＣＰＵ）１０１等に命令を与え、本実施の形態を実現するためのコンピュータプログラムのコードを記録することができる。メインメモリ１０４にロードされることによってコンピュータプログラムは実行される。コンピュータプログラムは圧縮し、また複数に分割して複数の媒体に記録することもできる。
【００２３】
コンピュータシステム１００は、更に、ユーザインターフェイスハードウェアとして、マウス等のポインティングデバイス１０７、キーボード１０６や視覚データをユーザに提示するためのディスプレイ１１２を有することができる。ポインティングデバイス１０７やキーボード１０６は、キーボードマウスコントローラ１０５によって制御される。また、ディスプレイ１１２は、グラフィックス制御チップ（ＶＧＡ）１０８によりＶＲＡＭ１０９を用いてグラフィックス展開された画像が表示される。更に、パラレルポート１１６を介してプリンタ（図示せず）と接続することや、シリアルポート１１５を介してモデム（図示せず）を接続することが可能である。また、シリアルポート１１５及びモデムを介し、また、通信アダプタ１１８（イーサネット（米ゼロックス社登録商標）カードやトークンリングカード）等を介してネットワークに接続し、他のコンピュータ等と通信を行うことが可能である。
【００２４】
スピーカ１２３は、オーディオコントローラ１２１によってＤ／Ａ変換（デジタル／アナログ変換）された音声信号をアンプ１２２を介して受け取り、音声として出力する。また、オーディオコントローラ１２１は、マイクロフォン１２４から受け取った音声情報をＡ／Ｄ変換（アナログ／デジタル変換）し、システム外部の音声情報をシステムに取り込むことを可能にしている。
【００２５】
以上の説明により、本発明の実施の形態におけるコンピュータシステム１００は、メインフレーム、ワークステーション、通常のパーソナルコンピュータ（ＰＣ）、ラップトップＰＣ、ノートブックＰＣ、パームトップＰＣ、ネットワークコンピュータ等の情報処理装置、または、これらの組み合わせによって実現されることが容易に理解されるであろう。ただし、これらの構成要素は例示であり、そのすべての構成要素が本実施の形態における必須構成要素となるわけではない。
【００２６】
本実施の形態に使用されるコンピュータシステム１００の各ハードウェア構成要素を、複数のマシンを組み合わせ、それらに機能を配分し実施する等の種々の変更は、当業者によって容易に想定され得るものであり、それらの変更は、当然に本発明の思想に包含される概念である。
【００２７】
本発明は、ハードウェア、ソフトウェア、またはハードウェア及びソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実行において、所定のプログラムを有するコンピュータシステム１００における実行が典型的な例として挙げられる。かかる場合、所定のプログラムがコンピュータシステム１００にロードされ実行されることにより、所定のプログラムは、コンピュータシステム１００を制御し、本発明にかかる処理を実行させる。このプログラムは、任意の言語・コード・表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接、または１．他の言語・コード・表記への変換、２．他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記録した媒体もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フロッピーディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハードディスク装置１１３、１３０、ＲＯＭ１１４、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ読み取り可能な記録媒体に格納することができる。かかるプログラムは、記録媒体への格納のために、通信回線で接続する他のコンピュータシステムからダウンロードしたり、他の記録媒体から複製したりすることができる。また、かかるプログラムは、圧縮し、または複数に分割して、単一または複数の記録媒体に格納することもできる。
【００２８】
本実施の形態のシステムにおいては、図９の各機能ブロックは図１に示すハードウェア構成を持つコンピュータシステムのハードウェア資源と各ハードウェア資源において実行されるオペレーティングシステム、ミドルウェア、アプリケーションプログラムなどのソフトウェアが協働することによって実現される。
【００２９】
次に、本実施の形態における特徴的な構成について詳述する。
図１は、本実施の形態におけるデータベース更新処理システムの全体構成を示した図である。図１に示すデータベース更新処理システムは、ログ選別処理部１１、更新データファイル１２、ソート部１３、ソート済み更新データファイル１４、および入力処理部３０を備えている。ログ選別処理部１１は、記帳系からのトランザクションログ（トランザクション処理にて各種ＤＢ等を更新した記録）を入力してログを分割し、ログ選別処理を施している。更新データファイル１２では、記帳系での処理順に更新データが蓄積されている。、ソート部１３では、更新データファイル１２の内容が主キー順およびＤＢ（データベース）更新通番により並び替えられる。ソート済み更新データファイル１４は、ソート部１３により主キー順およびＤＢ更新通番にて昇順ソートされた順次ファイルである。また、入力処理部３０では、ソート済み更新データファイル１４に格納されているデータに基づいて、ログ読み込み・振り分け処理が行われる。
【００３０】
また、データベース更新処理システムは、本実施の形態における特徴的な構成として、データキュー２１、制御キュー２２、保留キュー２３、およびデータ処理部（ストリーマ）５０を備えている。データキュー２１は、更新データをｎ個まとめたブロック（更新データメッセージ）を保管（蓄積）するキューである。制御キュー２２は、複数のブロック（更新データメッセージ）をまとめたパッケージ情報（パッケージ数、データキュー２１の名前など）を保管（蓄積）するキューである。保留キュー２３は、データ処理部５０にてプログラム障害などが発生した場合に、処理中に退避させる制御メッセージを保管（蓄積）するキューである。処理タスクであるデータ処理部（ストリーマ）５０は、データキュー２１より更新データメッセージを取得してデータベース更新処理を実行している。
【００３１】
更に、データベース更新処理システムは、データ処理部５０から更新データメッセージを受け取る更新業務プログラムからなる更新業務部２０を有し、この更新業務部２０は、更新処理振分部２４、ＤＢ更新プログラムであるＤＢ更新部２５を有している。また、更新業務部２０による更新処理対象である更新対象ＤＢ２６を備えている。この更新処理振分部２４は、データ処理部５０から渡されたブロックの内容を確認し、内容ごとに決められているＤＢ更新部２５にブロックを渡している。また、ＤＢ更新部２５は、複数のＤＢ更新業務プログラムによって構成されており、受け取ったブロックをデブロック（ブロック解除）し、業務処理の必要なものには処理を施し、対応する各種更新対象ＤＢ２６に対して更新を実行している。
【００３２】
ここで、本実施の形態におけるパッケージとブロッキングについて説明する。
図２（ａ），（ｂ）は、複数のデータ処理部（ストリーマ）５０が同一キーを持ってデータベースの更新を行う場合の並列処理の例を示した図である。図２（ａ）に示すように、同一キー（ここでは、ＣＩＦ＃１）を持つ複数レコードを、データ処理部（ストリーマ）５０でそのまま並列処理しようとすると、複数のデータ処理部（ストリーマ）５０が同一キーを持ってデータベースの更新を行うことから、遅延が発生し、結果的には並列処理ができなくなる。そこで、解決策の一つとして、図２（ｂ）のようにデータをブロッキングする方法が考えられる。しかしながら、例えば、ブロック長を数十Ｋバイト以内で構築する等、ブロック長には限界があることから、更新するものを限定することができない。ここで、同一キーが最大ブロック長を超えて続く場合について説明する。例えば、最大ブロック長が３０件で、同一キー（ここでは、ＣＩＦ＃１）のものが１００件あった場合を考える。この場合は、この１００件を全てまとめて１つのブロックにすることができない。かかる場合には、例えば、同一キーを有する４個のブロック（３０件×３ブロック＋１０件×１ブロック）が作成される。そのために、同一キーを持つ４個のブロックをデータ処理部（ストリーマ）５０で並列処理すると、データベースのコンテンションが生じるおそれがある。即ち、ブロックだけの観点では、図２（ａ）と同様に、遅延が発生し、結果的に並列処理ができない状況が生じ得る。
【００３３】
そこで、本実施の形態では、図３に示すように、ブロックをパッケージ化（グループ化）することで、各データ処理部（ストリーマ）５０は、異なったキーを持つデータを更新することが可能となり、遅延の発生を防止することができる。ここで、「パッケージ」とは、データ処理部５０がデータ順序処理を保証する単位である。例えば、同一キーのものが１００件あった場合に、ブロック化することのできる、例えば、３０件のブロックを３つ作り、残り１０件で１つのブロックを作り、これらを１つの単位としてパッケージングする。このように、並列処理が可能な論理的な単位であるパッケージという概念を用い、並列処理を実行している。
【００３４】
次に、これらの特徴的な機能を実現するために、各構成要素にて実行される各処理について詳述する。
図４は、入力処理部３０にて実行される処理を示したフローチャートである。入力処理部３０の出力は、データキュー２１および制御キュー２２に書き出されるが、大量データを効率良く処理するために、入力側の処理を「メインタスク」、出力側の処理を「サブタスク」にて実行している。入力処理部３０では、まず、入力側の処理を受け持つ「メインタスク」が開始され、ソート済み更新データファイル１４が「メインタスク」にて読み込まれる（ステップ１０１）。ここで、入力ファイルが終了したか否かが判断される（ステップ１０２）。入力ファイルが終了した場合には、後述するステップ１０８へ移行する。入力ファイルが終了していない場合に、「メインタスク」では、読み込まれた更新データタイプ毎に、出力側の処理を受け持つ「サブタスク」に対して開始を指示する（ステップ１０３）。
【００３５】
読み込まれた更新データは、更新データタイプが判断されて、該当する更新データを処理する「サブタスク」に渡される（ステップ１０４）。その後、更新データの処理を行う「サブタスク」では、各々の更新データのタイプ毎に独立したバッファを使用して、更新データのブロッキングが実行される（ステップ１０５）。「サブタスク」からは、更新データメッセージとして、完成したブロックがデータキューに出力される（ステップ１０６）。ここで、ブロッキングが実行される「バッファ」は、入力処理部３０のアドレススペース内に獲得された記憶域を指している。
【００３６】
決められた数のブロック（更新データメッセージ）が書き出された後には、それらのブロックと関連付けるためのパッケージ情報として制御メッセージが作成され、「サブタスク」から制御キュー２２に書き出されて、同期点が取られる（ステップ１０７）。この複数ブロックのまとまりがパッケージである。その後、ステップ１０１に戻り、同様の処理が繰り返される。ステップ１０２にて、入力ファイルが終了すると、各更新データを処理している「サブタスク」に対して終了が指示される（ステップ１０８）。更新データを処理する「サブタスク」は、バッファにあるブロックをデータキュー２１に書き出し、加えて対応する制御メッセージも制御キュー２２に書き出して、同期点をとり（ステップ１０９）、入力処理が終了する。尚、「同期点」では、１つの作業単位（ある一組の変更が開始されてから、それらが完了するまでの期間）内で、データベースの更新やメッセ−ジングの更新が確定される。
【００３７】
以上のようにして、入力処理部３０から出力されたデータキュー２１の更新データメッセージと、制御キュー２２の制御メッセージとは、所定の関連付けがなされている。また、制御キュー２２およびデータキュー２１も、所定の関連付けがなされている。
図５（ａ），（ｂ）は、メッセージの関連付け、およびキューの関連付けを説明するための図である。図５（ａ）は、制御キュー２２の制御メッセージとデータキュー２１の更新データメッセージとの関連を示しており、図５（ｂ）は、制御キュー２２とデータキュー２１との関連を示している。
【００３８】
図５（ａ）に示すように、同一パッケージ内の全ての更新データメッセージは、同一のメッセージＩＤで関連付けられている。即ち、制御メッセージが有するメッセージＩＤと同じメッセージＩＤを、同一パッケージ内の全ての更新データメッセージが有している。更新データメッセージには、このメッセージＩＤと共に、更新データ数や複数の更新データ等、データベースを更新する情報が格納されている。尚、メッセージＩＤは、例えば、入力処理部３０によって設定される。
【００３９】
図５（ｂ）では、第１〜第３の３つのデータキュー２１（２１−１〜２１−３）が制御キュー２２に関連付けられている。制御キュー２２とデータキュー２１とは、１：ｎ（ｎ≧１）の関係にある。ここで同一パッケージの全ての更新データメッセージは、同一のデータキュー２１に収納される。
【００４０】
このようにして、複数のブロックデータは、論理的に関連付けられてパッケージ単位とされ、その内容が記述された制御メッセージが作成される。そして、制御キュー２２にこの制御メッセージが保管されている。また、データベースを更新するブロックデータは、更新データメッセージとしてデータキュー２１に保管される。
【００４１】
次に、データ処理部（ストリーマ）５０について説明する。
図６は、データ処理部（ストリーマ）５０の機能構成を説明するためのブロック図である。処理タスクとして機能するデータ処理部５０は、全体制御部５１、ストリーム開始部５２、ユーザメッセージ取り出し部５３、ブロック終了部５４、ストリーム終了部５５、およびバックアウト部５６を備えている。全体制御部５１では、データ処理部５０の全体制御が実行される。ストリーム開始部５２では、起動時にキューのオープンとデータ処理部５０の制御情報（ストリーマ制御情報）の初期化が行われる。ユーザメッセージ取り出し部５３では、制御キュー２２に対して制御メッセージの待受けが行われる。出力手段として機能するブロック終了部５４は、更新データメッセージの処理が終了したことを確認し、制御キュー２２に制御メッセージを出力している。また、ストリーム終了部５５では、データ処理部５０の終了時にキューのクローズ処理が行われる。更に、バックアウト部５６は、障害が発生した場合に、該当する制御メッセージを保留キュー２３に出力している。尚、更新業務部２０のＤＢ更新部２５では、複数のＤＢ更新業務が実行される。
【００４２】
図７および図８は、主にデータ処理部（ストリーマ）５０にて実行される処理を示したフローチャートである。図６を参照しながら説明すると、ストリーム開始部５２は、データ処理部（ストリーマ）５０の起動時に、ストリーマ制御情報域（データ処理部５０ごとに獲得され管理された記憶領域）に対して初期値化を行い、入力対象のキュー名を設定する（ステップ２０１）。ストリーム開始部５２は、ストリーマ制御情報より入力対象のキュー名を取得し、制御キュー２２、データキュー２１、および保留キュー２３をオープンする（ステップ２０２）。
【００４３】
パッケージ情報取得手段およびブロック取得手段の一つとして機能するユーザメッセージ取り出し部５３は、制御キュー２２に対して制御メッセージの待受けを行う（ステップ２０３）。ここで、制御キュー２２に対して制御メッセージがあるか否かが判断される（ステップ２０４）。制御キュー２２に制御メッセージがない場合には、所定の時間待機し、その所定時間が経過すると、更新データがない旨を全体制御部５１へ通知し、全体制御部５１へ制御を戻す（ステップ２０５）。その後、停止指示があるか否かが判断され（ステップ２０６）、停止指示がない場合には、ステップ２０３へ戻り、停止指示がある場合には、データ処理部（ストリーマ）５０の停止時に、制御キュー２２、データキュー２１、および保留キュー２３のクローズ処理が行われて（ステップ２０７）、処理が終了する。
【００４４】
ステップ２０４にて、制御キュー２２に制御メッセージがある場合には、データキュー２１の名前とパッケージ数、更新データタイプなどからなるパッケージ情報を取得する（ステップ２０８）。そして、パッケージ情報より、対応するデータキュー２１を特定し、特定されたデータキュー２１から更新データメッセージを読み込み（ステップ２０９）、更新データメッセージを全体制御部５１へ渡す。このとき、全体制御部５１へは、処理する更新データが存在する旨が知らされる。
【００４５】
全体制御部５１では、ユーザメッセージ取り出し部５３からの情報に基づき、更新データがあるか否かで  異なる作業が実行される（ステップ２１０）。更新データがない場合には、前述したステップ２０５へ移行する。更新データがある場合には、全体制御部５１は、更新処理振分プログラムである更新処理振分部２４に更新データメッセージを渡す（ステップ２１１）。更新処理振分部２４では、渡された更新データメッセージの内容が確認され、ＤＢ更新部２５の中の、更新データの内容ごとに決められたＤＢ更新業務が呼び出されて、更新データメッセージが渡される（ステップ２１２）。
【００４６】
次に、図８を用いて説明すると、ＤＢ更新部２５の中の、ステップ２１１で更新データメッセージが渡されたＤＢ更新業務では、渡された更新データメッセージをもとに業務処理が行われ、更新対象ＤＢ２６に対してＤＢの更新が実行される（ステップ２１３）。ＤＢ更新業務では、ＤＢ更新の実行結果の状況が確認され、リターンコードが更新処理振分部２４に返される（ステップ２１４）。更新処理振分部２４では、戻されたリターンコードの判定がなされ、必要な後処理が行われて、データ処理部５０にリターンコードが返される（ステップ２１５）。
【００４７】
データ処理部５０のブロック終了部５４は、受け取ったリターンコードが正常である場合には、更新データメッセージの処理が終了したことを確認し、制御キュー２２に、制御メッセージを出力する（ステップ２１６）。その後、データ処理部５０における同期点処理として、全体制御部５１にて同期点が取られ、更新データメッセージによるデータベース更新処理が確定し（ステップ２１７）、図７に示すステップ２０５に戻る。
【００４８】
尚、ＤＢ更新部２５の所定のＤＢ更新業務にて、プログラム障害が発生した場合には、データ処理部５０は、更新したＤＢおよび更新データメッセージの戻し時のロールバック処理が行われる。即ち、障害の発生したＤＢ更新業務にて処理されていた更新データメッセージを処理保留にするために、バックアウト部５６は、該当する制御メッセージを保留キュー２３に出力する。このとき、出力される制御メッセージは、ユーザメッセージ取り出し部５３で取得したオリジナルの制御メッセージが使用される。
【００４９】
このように、本実施の形態では、入力処理部３０にて、複数のブロックデータを論理的に関連付けてパッケージ単位とし、その内容を記述した制御メッセージを作成し、制御キュー２２に対して保管するように構成した。また、データベースを更新するブロックデータは、更新データメッセージとして、データキュー２１に保管するように構成した。即ち、本実施の形態では、大量データを高速に処理するための工夫として、並列処理の実現と、データベースコンテンションの回避を行うために、制御キュー２２という新しいコンポーネントおよびデータのブロッキングとパッケージングを提案した。一方、データ処理部５０では、制御キュー２２から制御メッセージを読み取り、関連付けられている更新データメッセージをデータキュー２１から取り出して、ＤＢ更新処理を行わせている。このように、一つの制御キュー２２を複数のデータ処理部５０（ストリーマ）で共用することにより、個々のパッケージ単位でデータ処理部５０（ストリーマ）による並列処理が可能となり、データベース更新処理のパフォーマンス（処理効率）を向上させることができる。また、パッケージングする更新データのキーを事前にソートしておくことにより、データベースのコンテンションを極小化することができる。更に、ＤＢ更新する順序を守る必要があるデータに関しては、一つのパッケージ内に収納されるようにパッケージングすることにより、順次処理が可能となり、特に、銀行系のような連続した入出金データ処理を行う場合に非常に有効である。
【００５０】
また、障害時は、データ量が大量なため、プログラム障害時の起因となったデータを含むパッケージ単位にデータ処理が保留される。即ち、ＤＢ更新部２５（ＤＢ更新業務）の障害時には、パッケージ情報を保有する制御メッセージを一時保留するための保留キュー２３を設け、制御メッセージを退避した。この仕組みによって、障害データをデータキュー２１より移動させることなく処理をバイパスすることが可能となり、後続の別パッケージを処理することが可能となる。これによって、大量処理を行う際に、障害対応を短時間に、かつ自動的に行うことができる。
【００５１】
【発明の効果】
このように、本発明によれば、大量のデータを高速に処理する並列処理の実現と共に、データベースのコンテンションを回避することが可能となる。
【図面の簡単な説明】
【図１】本実施の形態におけるデータベース更新処理システムの全体構成を示した図である。
【図２】（ａ），（ｂ）は、複数のデータ処理部（ストリーマ）が同一キーを持ってデータベースの更新を行う場合の並列処理の例を示した図である。
【図３】ブロックをパッケージ化（グループ化）する本実施の形態の特徴的な構成を説明するための図である。
【図４】入力処理部にて実行される処理を示したフローチャートである。
【図５】（ａ），（ｂ）は、メッセージの関連付け、およびキューの関連付けを説明するための図である。
【図６】データ処理部（ストリーマ）の機能構成を説明するためのブロック図である。
【図７】主にデータ処理部（ストリーマ）にて実行される処理を示したフローチャートである。
【図８】主にデータ処理部（ストリーマ）にて実行される処理を示したフローチャートである。
【図９】本実施の形態において使用可能であるコンピュータシステムの代表的なハードウェア構成の一例を示したものである。
【符号の説明】
１１…ログ選別処理部、１２…更新データファイル、１３…ソート部、１４…ソート済み更新データファイル、２０…更新業務部、２１…データキュー、２２…制御キュー、２３…保留キュー、２４…更新処理振分部、２５…ＤＢ更新部、２６…更新対象ＤＢ、３０…入力処理部、５０…データ処理部（ストリーマ、データ処理タスク）、５１…全体制御部、５２…ストリーム開始部、５３…ユーザメッセージ取り出し部、５４…ブロック終了部、５５…ストリーム終了部、５６…バックアウト部
【図１】
2004287932.tif 000003
【図２】
2004287932.tif 000004
【図３】
2004287932.tif 000005
【図４】
2004287932.tif 000006
【図５】
2004287932.tif 000007
【図６】
2004287932.tif 000008
【図７】
2004287932.tif 000009
【図８】
2004287932.tif 000010
【図９】
2004287932.tif 000011