(57)【要約】【課題】データベース管理システムのネットワーク接続環境が不安定な場合であっても、アプリケーションの都合に応じてクエリ結果のデータを再送信できるようにすること。【解決手段】実施形態のデータベース管理装置は、送受信管理部と、クエリ実行部と、バッファ管理部とを持つ。前記送受信管理部は、アプリケーション端末からクエリを受信するとともに、前記クエリの検索対象のデータであるクエリ結果をバッファメモリから読み出して前記アプリケーション端末に送信する。前記クエリ実行部は、前記クエリに基づく処理を実行することにより、前記クエリ結果を取得する。前記バッファ管理部は、前記アプリケーション端末との通信が切断された場合に、前記クエリ実行部によって取得された前記クエリ結果を前記バッファメモリに記憶させるか否かを、前記アプリケーションとの通信に関する評価値に基づいて判定する。【選択図】図２
2018206206.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションを実行するアプリケーション端末からクエリを受信するとともに、前記クエリの検索対象のデータであるクエリ結果をバッファメモリから読み出して前記アプリケーション端末に送信する送受信管理部と、
前記送受信管理部によって受信された前記クエリに基づく処理を実行することにより、前記クエリ結果を取得するクエリ実行部と、
前記アプリケーション端末との通信が切断された場合に、前記クエリ実行部によって取得された前記クエリ結果を前記バッファメモリに記憶させるか否かを、前記アプリケーションとの通信に関する評価値に基づいて判定するバッファ管理部と、
を備えるデータベース管理装置。
【請求項２】
前記評価値として、前記アプリケーションごとの通信品質を判定する通信品質判定部を更に備え、
前記バッファ管理部は、前記通信品質判定部によって判定された前記通信品質に基づいて、前記クエリ実行部によって取得された前記クエリ結果を前記バッファメモリに記憶させるか否かを判定する
請求項１記載のデータベース管理装置。
【請求項３】
前記通信品質判定部は、前記アプリケーションとの通信の平均切断間隔または平均再接続間隔に基づいて、前記通信品質を判定する
請求項２記載のデータベース管理装置。
【請求項４】
前記クエリ実行部は、前記評価値として、前記クエリ結果を表すデータのデータ量を予測し、
前記バッファ管理部は、前記クエリ実行部によって予測された前記データ量に基づいて、前記クエリ実行部によって取得された前記クエリ結果を前記バッファメモリに記憶させるか否かを判定する
請求項１記載のデータベース管理装置。
【請求項５】
前記クエリ実行部は、前記クエリの種類および前記クエリの検索条件に基づいて、前記データ量を予測する
請求項４記載のデータベース管理装置。
【請求項６】
前記バッファメモリは、前記バッファ管理部および前記送受信管理部が同時にアクセス可能なメモリであり、
前記バッファ管理部は、前記クエリ実行部によって取得された前記クエリ結果に対して通信に必要なヘッダ情報を付加し、前記ヘッダ情報が付加された前記クエリ結果を前記バッファメモリに記憶し、
前記送受信管理部は、前記バッファメモリから前記クエリ結果を読み出し、読み出した前記クエリ結果を前記アプリケーション端末に送信する
請求項１から５のいずれか一項に記載のデータベース管理装置。
【請求項７】
前記アプリケーション端末とネゴシエーションを行って、前記データベース管理装置と前記アプリケーション端末との間で使用可能な最大パケットサイズを決定するパケットサイズ決定部を更に備え、
前記バッファ管理部は、前記パケットサイズ決定部によって決定された前記最大パケットサイズに収まる範囲内で、前記クエリ結果の１以上のレコードに前記ヘッダ情報が付加されたパケットを生成し、生成した前記パケットを前記バッファメモリに記憶する
請求項６記載のデータベース管理装置。
【請求項８】
アプリケーションを実行するアプリケーション端末と、
前記アプリケーション端末に接続されたデータベース管理装置と、を備え、
前記データベース管理装置は、
前記アプリケーション端末からクエリを受信するとともに、前記クエリの検索対象のデータであるクエリ結果をバッファメモリから読み出して前記アプリケーション端末に送信する送受信管理部と、
前記送受信管理部によって受信された前記クエリに基づく処理を実行することにより、前記クエリ結果を取得するクエリ実行部と、
前記アプリケーション端末との通信が切断された場合に、前記クエリ実行部によって取得された前記クエリ結果を前記バッファメモリに記憶させるか否かを、前記アプリケーションとの通信に関する評価値に基づいて判定するバッファ管理部と、
を備えるデータベース管理システム。
【請求項９】
送受信管理部が、アプリケーションを実行するアプリケーション端末からクエリを受信するとともに、前記クエリの検索対象のデータであるクエリ結果をバッファメモリから読み出して前記アプリケーション端末に送信し、
クエリ実行部が、前記送受信管理部によって受信された前記クエリに基づく処理を実行することにより、前記クエリ結果を取得し、
バッファ管理部が、前記アプリケーション端末との通信が切断された場合に、前記クエリ実行部によって取得された前記クエリ結果を前記バッファメモリに記憶させるか否かを、前記アプリケーションとの通信に関する評価値に基づいて判定する
データベース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、データベース管理装置、データベース管理システム、およびデータベース管理方法に関する。
【背景技術】
【０００２】
フィールドＩｏＴ（Internet of Things）の分野においては、データベース管理装置とアプリケーション端末とが接続されたデータベース管理システムが知られている。データベース管理システムにおいて、アプリケーション端末は、アプリケーションを実行し、データを要求するためのクエリをデータベース管理装置に送信する。一方、データベース管理装置は、アプリケーション端末から受信したクエリに基づく処理を実行してデータ（クエリ結果）を取得し、取得したデータをアプリケーション端末に送信する。
【０００３】
データベース管理システムのネットワーク接続環境が不安定な場合、データベース管理装置とアプリケーション端末との間の通信が突然切断される場合がある。この場合、データベース管理装置は、アプリケーション端末に送信できなかったクエリ結果を、カーネルのネットワーク層におけるバッファメモリに一時的に蓄積し、データベース管理装置とアプリケーション端末との間の通信が復旧した後で、クエリ結果をアプリケーション端末に再送信していた。
【０００４】
しかしながら、データベース管理装置は、クエリ結果が取得された順にバッファメモリにクエリ結果を蓄積し、バッファメモリに蓄積されたクエリ結果のデータ量が所定量を超えると、データベース管理装置はバッファフルエラーとしてクエリに基づく処理を停止していた。このため、アプリケーションの都合に応じてクエリ結果を再送信できない場合があった。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１４−１４６２９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明が解決しようとする課題は、データベース管理システムのネットワーク接続環境が不安定な場合であっても、アプリケーションの都合に応じてクエリ結果のデータを再送信することができるデータベース管理装置、データベース管理システム、およびデータベース管理方法を提供することである。
【課題を解決するための手段】
【０００７】
実施形態のデータベース管理装置は、送受信管理部と、クエリ実行部と、バッファ管理部とを持つ。前記送受信管理部は、アプリケーションを実行するアプリケーション端末からクエリを受信するとともに、前記クエリの検索対象のデータであるクエリ結果をバッファメモリから読み出して前記アプリケーション端末に送信する。前記クエリ実行部は、前記送受信管理部によって受信された前記クエリに基づく処理を実行することにより、前記クエリ結果を取得する。前記バッファ管理部は、前記アプリケーション端末との通信が切断された場合に、前記クエリ実行部によって取得された前記クエリ結果を前記バッファメモリに記憶させるか否かを、前記アプリケーションとの通信に関する評価値に基づいて判定する。
【図面の簡単な説明】
【０００８】
【図１】第１実施形態に係るデータベース管理システム１０の全体構成を示すブロック図。
【図２】第１実施形態に係るアプリケーション端末１００とデータベース管理装置２００の動作を説明するためのブロック図。
【図３】第１実施形態に係るテーブルＴ１の一例を示す図。
【図４】第１実施形態に係るパケットの送信処理の一例を示す図。
【図５】第１実施形態に係るパケットの送信処理の一例を示す図。
【図６】第１実施形態に係るパケットの送信処理の一例を示す図。
【図７】第１実施形態に係るパケットの送信処理の一例を示す図。
【図８】第１実施形態に係るパケットの送信処理の一例を示す図。
【図９】第１実施形態に係る状態監視処理の詳細を示すフローチャート。
【図１０】第１実施形態に係る正常切断処理の詳細を示すフローチャート。
【図１１】第１実施形態に係るクエリ結果エントリ受取処理の詳細を示すフローチャート。
【図１２】第１実施形態に係るパケット作成処理の詳細を示すフローチャート。
【図１３】第１実施形態に係るエラー処理の詳細を示すフローチャート。
【図１４】第１実施形態に係る送信継続処理の詳細を示すフローチャート。
【図１５】第１実施形態に係るクエリ処理の詳細を示すフローチャート。
【図１６】第３実施形態に係るテーブルＴ２の一例を示す図。
【図１７】第３実施形態に係るクエリ結果エントリ受取処理の詳細を示すフローチャート。
【図１８】第３実施形態に係るクエリ処理の詳細を示すフローチャート。
【発明を実施するための形態】
【０００９】
以下、実施形態のデータベース管理装置、データベース管理システム、およびデータベース管理方法を、図面を参照して説明する。
【００１０】
（第１実施形態）
図１は、第１実施形態に係るデータベース管理システム１０の全体構成を示すブロック図である。データベース管理システム１０は、データベース管理装置２００と、複数のアプリケーション端末１００−１、１００−２、および１００−３とを備える。図１において、３つのアプリケーション端末１００−１、１００−２、および１００−３が示されているが、アプリケーション端末の数はこれに限られない。例えば、４つ以上のアプリケーション端末１００がデータベース管理装置２００に接続されてもよい。
【００１１】
アプリケーション端末１００−１、１００−２、および１００−３は、アプリケーションを実行し、データを要求するためのクエリをデータベース管理装置２００に送信する端末である。アプリケーション端末１００−１、１００−２、および１００−３は、デスクトップ型のコンピュータであるが、これに限られない。例えば、アプリケーション端末１００は、ノート型のコンピュータ、タブレット端末、またはＰＤＡ（Personal Digital Assistant）であってもよい。
【００１２】
データベース管理装置２００は、アプリケーション端末１００−１、１００−２、および１００−３からクエリを受信するとともに、クエリの検索対象のデータであるクエリ結果を、アプリケーション端末１００−１、１００−２、および１００−３に送信する装置である。例えば、データベース管理装置２００は、日々の消費電力データを蓄積するスマートメータであるが、これに限られない。データベース管理装置２００は、ネットワークＮＷを介して複数のアプリケーション端末１００−１、１００−２、および１００−３に接続されている。ネットワークＮＷは、例えば、ＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）、インターネット、プロバイダ装置、無線基地局、専用回線などのうち一部または全部を含む。
【００１３】
図２は、第１実施形態に係るアプリケーション端末１００とデータベース管理装置２００の動作を説明するためのブロック図である。アプリケーション端末１００−１、１００−２、および１００−３は同様の動作を行うため、図２においては、これらをまとめてアプリケーション端末１００として説明する。
【００１４】
アプリケーション端末１００は、アプリケーション実行部１１０と、パケットサイズ決定部１２０とを備える。アプリケーション実行部１１０およびパケットサイズ決定部１２０は、ＣＰＵ（Central Processing Unit）等のプロセッサが、プログラムメモリに記憶されたプログラムを実行することで実現される。なお、アプリケーション実行部１１０およびパケットサイズ決定部１２０は、プロセッサがプログラムを実行するのと同様の機能を有するＬＳＩ（Large Scale Integration）、ＡＳＩＣ（Application Specific Integrated Circuit）、およびＦＰＧＡ（Field-Programmable Gate Array）等のハードウェアにより実現されてもよい。
【００１５】
データベース管理装置２００は、送受信管理部２１０と、接続管理部２３０と、クエリ実行部２４０と、バッファ管理部２５０と、通信品質判定部２６０と、バッファメモリ２７０と、記憶部２８０とを備える。送受信管理部２１０、接続管理部２３０、クエリ実行部２４０、バッファ管理部２５０、および通信品質判定部２６０は、ＣＰＵ等のプロセッサが、プログラムメモリに記憶されたプログラムを実行することで実現される。なお、送受信管理部２１０、接続管理部２３０、クエリ実行部２４０、バッファ管理部２５０、および通信品質判定部２６０は、プロセッサがプログラムを実行するのと同様の機能を有するＬＳＩ、ＡＳＩＣ、およびＦＰＧＡ等のハードウェアにより実現されてもよい。
【００１６】
バッファメモリ２７０および記憶部２８０は、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ、またはこれらのうち複数が組み合わされたハイブリッド型記憶装置などにより実現される。また、バッファメモリ２７０および記憶部２８０の一部または全部は、ＮＡＳ（Network Attached Storage）や外部のストレージサーバなど、データベース管理装置２００がアクセス可能な外部装置であってもよい。
【００１７】
記憶部２８０には、様々なデータが蓄積される。例えば、スマートメータの場合、日々の消費電力データが記憶部２８０に蓄積される。記憶部２８０に記憶されるデータは、消費電力データに限られず、どのようなデータであってもよい。なお、記憶部２８０には、テーブル形式でデータが記憶されている。
【００１８】
接続管理部２３０は、アプリケーション端末１００とデータベース管理装置２００との間の接続を管理する。接続管理部２３０は、パケットサイズ決定部２３１を備える。パケットサイズ決定部２３１は、アプリケーション端末１００のパケットサイズ決定部１２０とネゴシエーションを行って、データベース管理装置２００とアプリケーション端末１００との間で使用可能な最大パケットサイズを決定する。例えば、最大パケットサイズは、Path MTU Discovery等の技術を利用して求められてもよいし、予め決定されてもよい。
【００１９】
アプリケーション端末１００のアプリケーション実行部１１０は、アプリケーションを実行し、データを要求するためのクエリをデータベース管理装置２００に送信する。データベース管理装置２００の送受信管理部２１０は、アプリケーション端末１００から受信したクエリを、接続管理部２３０に出力する。接続管理部２３０は、送受信管理部２１０から入力されたクエリを、クエリ実行部２４０に出力する。
【００２０】
クエリ実行部２４０は、接続管理部２３０から入力されたクエリに基づく処理を実行することにより、記憶部２８０からクエリ結果を取得する。クエリ実行部２４０が、取得したクエリ結果をバッファ管理部２５０に出力する。
【００２１】
一方、送受信管理部２１０は、クエリ結果をアプリケーション端末１００に送信するために必要なヘッダ情報を、バッファ管理部２５０に出力する。例えば、ヘッダ情報は、クエリ結果の送信先のアドレス情報である。バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果に対して、送受信管理部２１０から入力されたヘッダ情報を付加してパケットを生成する。
【００２２】
具体的に、バッファ管理部２５０は、パケットサイズ決定部２３１によって決定された最大パケットサイズに収まる範囲内で、クエリ結果の１以上のレコードにヘッダ情報が付加されたパケットを生成する。バッファ管理部２５０は、生成したパケットをバッファメモリ２７０に記憶する。また、バッファ管理部２５０は、パケットの送信要求を送受信管理部２１０に出力する。
【００２３】
送受信管理部２１０は、バッファ管理部２５０から入力されたパケットの送信要求に基づき、送信要求によって指定されるパケットを、バッファメモリ２７０から読み出す。その後、送受信管理部２１０は、バッファメモリ２７０から読み出したパケットをアプリケーション端末に送信する。
【００２４】
なお、アプリケーション端末１００とデータベース管理装置２００との間の通信が異常切断された場合、クエリ結果のパケットがアプリケーション端末１００に送信されず、バッファメモリ２７０に蓄積されることになる。このため、バッファ管理部２５０は、テーブルＴ１を用いてバッファメモリ２７０に記憶されるデータを管理する。
【００２５】
図３は、第１実施形態に係るテーブルＴ１の一例を示す図である。テーブルＴ１は、接続元ＩＤと、通信品質と、接続状態と、蓄積許可割合と、バッファ使用量と、カウント値とが対応付けられたテーブルである。
【００２６】
接続元ＩＤは、データベース管理装置２００に接続されたアプリケーション端末１００の識別情報である。例えば、接続元ＩＤは、ＩＰアドレスとポート番号とを含む情報である。通信品質は、データベース管理装置２００とアプリケーション端末１００との間の通信回線の品質を示す情報である。通信品質は、「０」から「３」のいずれかの値であり、値が小さいほど通信回線の品質が良いことを表す。例えば、「０」は、通信品質が最も良く、異常切断が発生し難いことを示す。一方、「３」は、通信品質が最も悪く、異常切断が発生し易いことを示す。詳細は後述するが、通信品質は、通信品質判定部２６０によって判定される。
【００２７】
接続状態は、データベース管理装置２００とアプリケーション端末１００との間の通信が、「接続中」であるのか、または「異常切断中」であるのかを示す情報である。蓄積許可割合は、バッファメモリ２７０への蓄積を許可されたデータ量の割合を示す情報である。なお、蓄積許可割合が「０％」であっても、パケットを送信するために、最低１パケット分のデータをバッファメモリ２７０に蓄積することは許可されている。
【００２８】
バッファ使用量は、実際に使用しているバッファメモリ２７０におけるデータ量を示す情報である。カウント値は、通信品質を算出するために用いられる値であり、詳細は後述する。
【００２９】
接続元ＩＤは６バイトであり、通信品質は２ビットであり、接続状態は１ビットであり、蓄積許可割合は６ビット（上限値：１００）であり、バッファ使用量は６ビット（上限値：１００）であり、カウント値は２バイトである。このため、テーブルＴ１における１つのエントリは、合計１０バイトで構成される。
【００３０】
データベース管理装置２００とアプリケーション端末１００と間の通信が切断された場合、バッファ管理部２５０は、クエリ実行部２４０によって取得されたクエリ結果のパケットをバッファメモリ２７０に記憶させるか否かを、テーブルＴ１を用いて判定する。以下、具体的な処理について説明する。
【００３１】
図４から図８は、第１実施形態に係るパケットの送信処理の一例を示す図である。図４から図８においては、一例として、データベース管理装置２００が３つのアプリケーションＡ１、Ａ２、およびＡ３にパケットを送信する場合が示されている。
【００３２】
図４から図８に示される例において、アプリケーションＡ１の通信品質は「１」であり、蓄積許可割合は「０％」である。アプリケーションＡ２の通信品質は「０」であり、蓄積許可割合は「０％」である。アプリケーションＡ３の通信品質は「２」であり、蓄積許可割合は「０％」である。
【００３３】
まず、図４において、データベース管理装置２００とアプリケーションＡ１、Ａ２、およびＡ３は、正常に接続されている。このため、バッファ管理部２５０によってバッファメモリ２７０に格納されたパケットは、直ちに送受信管理部２１０によってアプリケーションＡ１、Ａ２、およびＡ３の何れかに送信され、送信されたパケットはバッファメモリ２７０から消去される。前述したように、蓄積許可割合は「０％」となっているが、最低１パケット分はバッファメモリ２７０の使用が許可されている。したがって、バッファメモリ２７０にパケットが蓄積され続けることはない。
【００３４】
図５は、データベース管理装置２００とアプリケーションＡ２との間の通信が異常切断された場合を示す。この場合、送受信管理部２１０は、アプリケーションＡ２にパケットを送信することができない。
【００３５】
このため、バッファ管理部２５０は、Ｂ１に示されるように、テーブルＴ１におけるアプリケーションＡ２についての蓄積許可割合を「０％」から「１００％」に変更する。これによって、データベース管理装置２００とアプリケーションＡ２との間の通信が復旧するまで、アプリケーションＡ２についてのパケットがバッファメモリ２７０に蓄積され続ける。
【００３６】
図６は、図５に示される状態から更に、データベース管理装置２００とアプリケーションＡ３との間の通信が異常切断された場合を示す。この場合、送受信管理部２１０は、アプリケーションＡ２だけでなく、アプリケーションＡ３にもパケットを送信することができない。
【００３７】
このため、バッファ管理部２５０は、テーブルＴ１における蓄積許可割合を更新する。具体的には、バッファ管理部２５０は、各アプリケーションの通信品質を、通信が切断されているアプリケーションの通信品質の合計値で除算することによって、蓄積許可割合を算出する。
【００３８】
図６に示される例においては、アプリケーションＡ２の通信品質が「０」であり、アプリケーションＡ３の通信品質が「２」である。このため、バッファ管理部２５０は、Ｂ２に示されるように、テーブルＴ１におけるアプリケーションＡ２についての蓄積許可割合を「１００％」から「０％」に変更する。また、バッファ管理部２５０は、Ｂ３に示されるように、テーブルＴ１におけるアプリケーションＡ３についての蓄積許可割合を「０％」から「１００％」に変更する。
【００３９】
アプリケーションＡ２についての蓄積許可割合が「０％」に変更されたため、バッファ管理部２５０は、アプリケーションＡ２についてのパケットをバッファメモリ２７０に格納しない。また、アプリケーションＡ３についての蓄積許可割合が「１００％」に変更されたため、バッファ管理部２５０は、アプリケーションＡ３についてのパケットをバッファメモリ２７０に蓄積していく。
【００４０】
バッファメモリ２７０がフル状態になると、バッファ管理部２５０は、バッファメモリ２７０に格納されたアプリケーションＡ２についてのパケットを、アプリケーションＡ３についてのパケットで上書きする。
【００４１】
アプリケーションＡ２およびＡ３の何れの通信も復旧しない場合、バッファメモリ２７０に格納されたアプリケーションＡ２についてのパケットは、アプリケーションＡ３についてのパケットで上書きされていく。最終的には、バッファメモリ２７０に格納されたアプリケーションＡ２についての全てのパケットは、アプリケーションＡ３についてのパケットで上書きされることとなる。
【００４２】
図７は、図６に示される状態から更に、データベース管理装置２００とアプリケーションＡ１との間の通信が異常切断された場合を示す。この場合、送受信管理部２１０は、全てのアプリケーションＡ１からＡ３に対してパケットを送信することができない。
【００４３】
このため、バッファ管理部２５０は、テーブルＴ１における蓄積許可割合を更新する。ここでも、バッファ管理部２５０は、各アプリケーションの通信品質を、通信が切断されているアプリケーションの通信品質の合計値で除算することによって、蓄積許可割合を算出する。
【００４４】
図７に示される例においては、アプリケーションＡ１の通信品質が「１」であり、アプリケーションＡ２の通信品質が「０」であり、アプリケーションＡ３の通信品質が「２」である。このため、バッファ管理部２５０は、Ｂ４に示されるように、テーブルＴ１におけるアプリケーションＡ１についての蓄積許可割合を「０％」から「３３％」に変更する。また、バッファ管理部２５０は、Ｂ５に示されるように、テーブルＴ１におけるアプリケーションＡ３についての蓄積許可割合を「１００％」から「６６％」に変更する。
【００４５】
アプリケーションＡ１についての蓄積許可割合が「３３％」に変更されたため、バッファ管理部２５０は、アプリケーションＡ１についてのパケットをバッファメモリ２７０に蓄積していく。バッファ管理部２５０は、バッファメモリ２７０に格納されたアプリケーションＡ３についてのパケットを、アプリケーションＡ１についてのパケットで上書きする。最終的には、バッファメモリ２７０の記憶容量の３３％まで、アプリケーションＡ１についてのパケットがバッファメモリ２７０に蓄積される。
【００４６】
図８は、図７に示される状態から更に、データベース管理装置２００とアプリケーションＡ３との間の通信が復旧した場合を示す。この場合、送受信管理部２１０は、アプリケーションＡ１およびＡ２に対してパケットを送信することができないが、アプリケーションＡ３に対してパケットを送信することができる。
【００４７】
このため、バッファメモリ２７０に格納されたアプリケーションＡ３についてのパケットは、送受信管理部２１０によってアプリケーションＡ３に送信され、送信されたパケットはバッファメモリ２７０から消去される。
【００４８】
また、バッファ管理部２５０は、テーブルＴ１における蓄積許可割合を更新する。ここでも、バッファ管理部２５０は、各アプリケーションの通信品質を、通信が切断されているアプリケーションの通信品質の合計値で除算することによって、蓄積許可割合を算出する。
【００４９】
図８に示される例において、バッファ管理部２５０は、Ｂ６に示されるように、テーブルＴ１におけるアプリケーションＡ１についての蓄積許可割合を「３３％」から「１００％」に変更する。また、バッファ管理部２５０は、Ｂ７に示されるように、テーブルＴ１におけるアプリケーションＡ３についての蓄積許可割合を「６６％」から「０％」に変更する。
【００５０】
アプリケーションＡ３についてのパケットがアプリケーションＡ３に送信されることで、バッファメモリ２７０内のメモリ領域が解放される。このため、バッファ管理部２５０は、アプリケーションＡ１についてのパケットをバッファメモリ２７０に蓄積していく。これによって、データベース管理装置２００とアプリケーションＡ１との間の通信が復旧するまで、アプリケーションＡ１についてのパケットがバッファメモリ２７０に蓄積され続ける。
【００５１】
以上説明したように、１つのアプリケーションとの通信のみが切断された場合、バッファ管理部２５０は、通信が切断されたアプリケーションに関するクエリ結果をバッファメモリ２７０に蓄積する。また、２つ以上のアプリケーションとの通信が切断された場合、バッファ管理部２５０は、バッファメモリ２７０におけるアプリケーションごとの蓄積許可割合を調整する。具体的には、バッファ管理部２５０は、通信品質が悪いほど、蓄積許可割合を大きくする。これによって、送信の再試行が多くなるクエリ結果を多くバッファメモリ２７０に蓄積できるため、システム全体の可用性を向上することができる。
【００５２】
図９は、第１実施形態に係る状態監視処理の詳細を示すフローチャートである。図９に示される状態監視処理は、通信品質判定部２６０およびバッファ管理部２５０によって定期的に実行される。
【００５３】
まず、通信品質判定部２６０は、アプリケーション端末１００と通信可能か否かを判定する（Ｓ１０）。通信品質判定部２６０は、アプリケーション端末１００と通信可能であると判定した場合、テーブルＴ１（図３）における、このアプリケーション端末１００の接続元ＩＤに対応するカウント値から１を減算する（Ｓ１１）。
【００５４】
次に、通信品質判定部２６０は、カウント値が０であるか否かを判定する（Ｓ１２）。通信品質判定部２６０は、カウント値が０ではないと判定した場合、後述するＳ１５に処理を進める。一方、通信品質判定部２６０は、カウント値が０であると判定した場合、テーブルＴ１における通信品質から１を減算し（Ｓ１３）、テーブルＴ１におけるカウント値を最大値にする（Ｓ１４）。
【００５５】
その後、バッファ管理部２５０は、テーブルＴ１に示される通信品質に基づいて、蓄積許可割合を算出する（Ｓ１５）。前述したように、バッファ管理部２５０は、アプリケーションとの通信が切断されている場合、このアプリケーションの接続元ＩＤに対応する通信品質を、通信が切断されている全てのアプリケーションの通信品質の合計値で除算することによって、蓄積許可割合を算出する。バッファ管理部２５０は、算出した蓄積許可割合をテーブルＴ１に書き込み、本フローチャートによる処理を終了する。
【００５６】
一方、Ｓ１０において、通信品質判定部２６０は、アプリケーション端末１００と通信可能でないと判定した場合、テーブルＴ１（図３）における、このアプリケーション端末１００の接続元ＩＤに対応するカウント値に１を加算する（Ｓ１６）。
【００５７】
次に、通信品質判定部２６０は、カウント値が最大値であるか否かを判定する（Ｓ１７）。通信品質判定部２６０は、カウント値が最大値ではないと判定した場合、前述したＳ１５に処理を進める。一方、通信品質判定部２６０は、カウント値が最大値であると判定した場合、テーブルＴ１における通信品質に１を加算し（Ｓ１８）、テーブルＴ１におけるカウント値を０にする（Ｓ１９）。その後、通信品質判定部２６０は、前述したＳ１５に処理を進める。
【００５８】
以上の処理によって、通信品質判定部２６０は、アプリケーションごとの通信品質を判定することができる。なお、通信品質判定部２６０による通信品質の判定処理は、図９に示されるフローチャートに限定されない。例えば、通信品質判定部２６０は、アプリケーションとの通信の平均切断間隔または平均再接続間隔に基づいて、通信品質を判定してもよい。平均切断間隔は、アプリケーションとの通信が切断されてから、次にアプリケーションとの通信が切断されるまでの平均時間であるが、これに限られない。例えば、平均切断間隔は、単位時間におけるアプリケーションとの通信が切断される平均頻度であってもよい。また、平均再接続間隔は、アプリケーションとの通信が復旧してから、次にアプリケーションとの通信が復旧するまでの平均時間であるが、これに限られない。例えば、平均再接続間隔は、単位時間におけるアプリケーションとの通信が復旧した平均頻度であってもよい。
【００５９】
図１０は、第１実施形態に係る正常切断処理の詳細を示すフローチャートである。図１０に示される正常切断処理は、アプリケーション端末１００がアプリケーションを終了する場合に、バッファ管理部２５０および送受信管理部２１０によって実行される。
【００６０】
まず、バッファ管理部２５０は、終了するアプリケーションに対応するエントリを、バッファメモリ２７０から消去する（Ｓ２０）。このとき、バッファ管理部２５０は、テーブルＴ１からも、終了するアプリケーションに対応するエントリを消去する。次に、送受信管理部２１０は、アプリケーション端末１００との通信を切断し（Ｓ２１）、本フローチャートによる処理を終了する。
【００６１】
図１１は、第１実施形態に係るクエリ結果エントリ受取処理の詳細を示すフローチャートである。図１１に示されるクエリ結果エントリ受取処理は、クエリ結果エントリがクエリ実行部２４０からバッファ管理部２５０に入力されたときに実行される。クエリ結果エントリは、（ｘ，ｅ，ｒ）で表される。ｘは、クエリを識別するためのクエリ識別情報である。ｅは、レコード番号である。ｒは、クエリ結果のレコードである。
【００６２】
まず、バッファ管理部２５０は、テーブルＴ１の「接続状態」を参照し、クエリ実行部２４０から入力されたクエリ結果エントリに関するアプリケーション端末１００が「接続中」であるか否かを判定する（Ｓ３０）。バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関するアプリケーション端末１００が「接続中」であると判定した場合、クエリ結果エントリを用いてパケットを作成し、作成したパケットをバッファメモリ２７０に記憶する（Ｓ３１）。なお、パケットの作成処理の詳細については後述する。その後、バッファ管理部２５０は、本フローチャートによる処理を終了する。
【００６３】
一方、Ｓ３０において、バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関するアプリケーション端末１００が「接続中」でないと判定した場合、テーブルＴ１において「異常切断中」となっているエントリが複数あるか否かを判定する（Ｓ３２）。
【００６４】
バッファ管理部２５０は、テーブルＴ１において「異常切断中」となっているエントリが複数あると判定した場合、テーブルＴ１の「通信品質」を参照し、クエリ実行部２４０から入力されたクエリ結果エントリに関する「通信品質」が「２」以上であるか否かを判定する（Ｓ３３）。バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関する「通信品質」が「２」以上であると判定した場合、クエリ結果エントリを保持できないことを示す結果保持不可エラーをクエリ実行部２４０に出力し（Ｓ３４）、本フローチャートによる処理を終了する。
【００６５】
一方、Ｓ３２において、バッファ管理部２５０は、テーブルＴ１において「異常切断中」となっているエントリが複数あると判定しなかった場合、後述するＳ３５に処理を進める。また、Ｓ３３において、バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関する「通信品質」が「２」未満であると判定した場合も、後述するＳ３５に処理を進める。
【００６６】
Ｓ３５において、バッファ管理部２５０は、テーブルＴ１を参照し、クエリ実行部２４０から入力されたクエリ結果エントリに関する「バッファ使用量」が「蓄積許可割合」に到達しているか否かを判定する（Ｓ３５）。バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関する「バッファ使用量」が「蓄積許可割合」に到達していると判定した場合、バッファメモリ２７０がフル状態であることを示すバッファフルエラーをクエリ実行部２４０に出力し（Ｓ３６）、本フローチャートによる処理を終了する。
【００６７】
一方、Ｓ３５において、バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関する「バッファ使用量」が「蓄積許可割合」に到達していないと判定した場合、バッファメモリ２７０に空きがあるか否かを判定する（Ｓ３７）。バッファ管理部２５０は、バッファメモリ２７０に空きがあると判定した場合、クエリ結果エントリを用いてパケットを作成し、作成したパケットをバッファメモリ２７０に記憶する（Ｓ３８）。その後、バッファ管理部２５０は、テーブルＴ１における「バッファ使用量」を更新し（Ｓ３９）、本フローチャートによる処理を終了する。
【００６８】
一方、Ｓ３７において、バッファ管理部２５０は、バッファメモリ２７０に空きがないと判定した場合、クエリ結果エントリを用いてパケットを作成し、作成したパケットをバッファメモリ２７０に記憶された他のエントリに上書きする（Ｓ４０）。ただし、前述したように、テーブルＴ１に示される蓄積許可割合が「０％」の場合など、上書きできない場合もある。その後、バッファ管理部２５０は、テーブルＴ１における「バッファ使用量」を更新し（Ｓ３９）、本フローチャートによる処理を終了する。
【００６９】
図１２は、第１実施形態に係るパケット作成処理の詳細を示すフローチャートである。図１２に示されるパケット作成処理は、例えば、図１１のＳ３１、Ｓ３８、およびＳ４０において、バッファ管理部２５０によって実行される。
【００７０】
まず、バッファ管理部２５０は、クエリ実行部２４０から受け取ったクエリ結果エントリが、クエリの最後のエントリか否かを判定する（Ｓ５０）。バッファ管理部２５０は、クエリ実行部２４０から受け取ったクエリ結果エントリがクエリの最後のエントリであると判定した場合、クエリ実行部２４０から受け取ったクエリ結果エントリと、クエリ結果エントリ集合とに基づき、パケットを生成する（Ｓ５１）。クエリ結果エントリ集合は、クエリ実行部２４０から受け取ったクエリ結果エントリの集合である。なお、前述したように、バッファ管理部２５０によって生成されたパケットには、送受信管理部２１０から入力されたヘッダ情報が付加されている。その後、バッファ管理部２５０は、本フローチャートによる処理を終了する。
【００７１】
一方、Ｓ５０において、バッファ管理部２５０は、クエリ実行部２４０から受け取ったクエリ結果エントリがクエリの最後のエントリでないと判定した場合、生成するパケットのサイズが、パケットサイズ決定部２３１によって決定された最大パケットサイズを超えるか否かを判定する（Ｓ５２）。ここで、生成するパケットのサイズは、クエリ実行部２４０から受け取ったクエリ結果エントリのサイズと、クエリ結果エントリ集合のサイズと、ヘッダ情報のサイズの合計である。バッファ管理部２５０は、生成するパケットのサイズが最大パケットサイズを超えると判定した場合、クエリ結果エントリ集合に基づきパケットを生成する（Ｓ５３）。その後、バッファ管理部２５０は、本フローチャートによる処理を終了する。
【００７２】
一方、Ｓ５２において、バッファ管理部２５０は、生成するパケットのサイズが最大パケットサイズを超えないと判定した場合、クエリ実行部２４０から受け取ったクエリ結果エントリを、クエリ結果エントリ集合に追加し（Ｓ５４）、本フローチャートによる処理を終了する。
【００７３】
図１３は、第１実施形態に係るエラー処理の詳細を示すフローチャートである。図１３に示されるエラー処理は、バッファ消去要求がクエリ実行部２４０からバッファ管理部２５０に入力された場合に、バッファ管理部２５０および送受信管理部２１０によって実行される。バッファ消去要求は、クエリ実行部２４０でエラーが発生した場合に、クエリ実行部２４０からバッファ管理部２５０に入力される。バッファ消去要求は、（ｘ，ｚ）で表される。ｘは、クエリを識別するためのクエリ識別情報である。ｚは、エラー内容である。
【００７４】
まず、バッファ管理部２５０は、バッファ消去要求（ｘ，ｚ）からクエリ識別情報ｘを取得する（Ｓ６１）。次に、バッファ管理部２５０は、取得したクエリ識別情報ｘに関連する全てのエントリを、バッファメモリ２７０から消去する（Ｓ６２）。
【００７５】
その後、バッファ管理部２５０は、テーブルＴ１を参照し、エントリが消去されたクエリの接続元の接続状態が「接続中」であるか否かを判定する（Ｓ６３）。バッファ管理部２５０が、エントリが消去されたクエリの接続元の接続状態が「接続中」であると判定した場合、送受信管理部２１０は、エントリが消去されたクエリに関連するアプリケーション端末１００にエラー情報（ｘ，ｚ）を送信し（Ｓ６４）、本フローチャートによる処理を終了する。
【００７６】
一方、Ｓ６３において、バッファ管理部２５０は、エントリが消去されたクエリの接続元の接続状態が「接続中」ではないと判定した場合、エラー情報（ｘ，ｚ）をバッファメモリ２７０に格納し（Ｓ６５）、本フローチャートによる処理を終了する。
【００７７】
図１４は、第１実施形態に係る送信継続処理の詳細を示すフローチャートである。図１４に示される送信継続処理は、データベース管理装置２００が送信継続要求をアプリケーション端末１００から受信した場合に実行される。アプリケーション端末１００は、アプリケーション端末１００とデータベース管理装置２００との間の通信が復旧した場合に、送信を中断されたクエリ結果の再送信を要求するために、送信継続要求をデータベース管理装置２００に送信する。送信継続要求は、（ｘ，Ｅ）で表される。ｘは、クエリを識別するためのクエリ識別情報である。Ｅは、レコード番号である。
【００７８】
まず、バッファ管理部２５０は、送信継続要求（ｘ，Ｅ）に含まれるレコード番号Ｅより大きいエントリが、バッファメモリ２７０に格納されているか否かを判定する（Ｓ７０）。バッファ管理部２５０が、レコード番号Ｅより大きいエントリが、バッファメモリ２７０に格納されていると判定した場合、送受信管理部２１０は、レコード番号Ｅより大きいレコード番号の全てのエントリをバッファメモリ２７０から読み出し、アプリケーション端末１００に送信する（Ｓ７１）。その後、送受信管理部２１０は、送信されたエントリをバッファメモリ２７０から消去し、本フローチャートによる処理を終了する。
【００７９】
一方、Ｓ７０において、バッファ管理部２５０は、レコード番号Ｅより大きいエントリが、バッファメモリ２７０に格納されていないと判定した場合、クエリ識別情報ｘについてのエラー情報（ｘ，ｚ）がバッファメモリ２７０に格納されているか否かを判定する（Ｓ７２）。バッファ管理部２５０が、クエリ識別情報ｘについてのエラー情報（ｘ，ｚ）がバッファメモリ２７０に格納されていると判定した場合、送受信管理部２１０は、バッファメモリ２７０からエラー情報（ｘ，ｚ）を読み出して、アプリケーション端末１００に送信する（Ｓ７３）。その後、送受信管理部２１０は、送信されたエラー情報（ｘ，ｚ）をバッファメモリ２７０から消去し、本フローチャートによる処理を終了する。
【００８０】
一方、Ｓ７２において、バッファ管理部２５０が、クエリ識別情報ｘについてのエラー情報（ｘ，ｚ）がバッファメモリ２７０に格納されていないと判定した場合、送受信管理部２１０は、送信継続要求が受け付けられた旨をアプリケーション端末１００に通知し（Ｓ７４）、本フローチャートによる処理を終了する。
【００８１】
図１５は、第１実施形態に係るクエリ処理の詳細を示すフローチャートである。図１５に示されるクエリ処理は、データベース管理装置２００がアプリケーション端末１００からクエリを受信した場合に、クエリ実行部２４０によって実行される。クエリは、（ｘ，ｑ）で表される。ｘは、クエリを識別するためのクエリ識別情報である。ｑは、クエリ内容である。
【００８２】
まず、クエリ実行部２４０は、レコード番号ｅに０を設定する（Ｓ８１）。次に、クエリ実行部２４０は、クエリ内容ｑに基づき、クエリ結果の内容を示すレコードｒを生成し（Ｓ８２）、レコード番号ｅに１を加算する（Ｓ８３）。
【００８３】
その後、クエリ実行部２４０は、レコードｒが正常に生成されたか否かを判定する（Ｓ８４）。クエリ実行部２４０は、レコードｒが正常に生成されなかったと判定した場合、内部エラーによるバッファ消去要求を、バッファ管理部２５０に出力し（Ｓ８５）、本フローチャートによる処理を終了する。
【００８４】
一方、Ｓ８４において、クエリ実行部２４０は、レコードｒが正常に生成されたと判定した場合、クエリ結果エントリ（ｘ，ｅ，ｒ）をバッファ管理部２５０に出力する（Ｓ８６）。その後、クエリ実行部２４０は、バッファ管理部２５０からクエリ実行部２４０にエラーが出力された否かを判定する（Ｓ８７）。例えば、バッファ管理部２５０は、前述したように、図１１に示されるＳ３４およびＳ３６において、クエリ実行部２４０にエラーを出力する。
【００８５】
Ｓ８７において、クエリ実行部２４０は、バッファ管理部２５０からクエリ実行部２４０にエラーが出力されたと判定しなかった場合、クエリ内容ｑに基づく処理は完了したか否かを判定する（Ｓ８８）。クエリ実行部２４０は、クエリ内容ｑに基づく処理は完了したと判定した場合、本フローチャートによる処理を終了する。逆に、クエリ実行部２４０は、クエリ内容ｑに基づく処理は完了していないと判定した場合、前述のＳ８２に処理を戻す。
【００８６】
一方、Ｓ８７において、クエリ実行部２４０は、バッファ管理部２５０からクエリ実行部２４０にエラーが出力されたと判定した場合、エラーが出力されてから所定時間が経過したか否かを判定する（Ｓ８９）。クエリ実行部２４０は、エラーが出力されてから所定時間が経過したと判定した場合、タイムアウトエラーによるバッファ消去要求を、バッファ管理部２５０に出力し（Ｓ９０）、本フローチャートによる処理を終了する。
【００８７】
一方、Ｓ８９において、クエリ実行部２４０は、エラーが出力されてから所定時間が経過していないと判定した場合、バッファメモリ２７０において、クエリ識別情報ｘについてのエントリが他のクエリ結果のエントリによって上書きされたか否かを判定する（Ｓ９１）。クエリ実行部２４０は、クエリ識別情報ｘについてのエントリが他のクエリ結果のエントリによって上書きされたと判定した場合、上書きされていない点までレコード番号ｅを戻し（Ｓ９２）、前述のＳ８２に処理を戻す。
【００８８】
一方、Ｓ９１において、クエリ実行部２４０は、クエリ識別情報ｘについてのエントリが他のクエリ結果のエントリによって上書きされていないと判定した場合、前述のＳ８６に処理を戻す。
【００８９】
以上説明したように、第１実施形態に係るデータベース管理システム１０は、送受信管理部２１０と、クエリ実行部２４０と、バッファ管理部２５０と、通信品質判定部２６０とを持つ。送受信管理部２１０は、アプリケーションを実行するアプリケーション端末１００からクエリを受信するとともに、クエリの検索対象のデータであるクエリ結果をバッファメモリ２７０から読み出してアプリケーション端末１００に送信する。クエリ実行部２４０は、送受信管理部２１０によって受信されたクエリに基づく処理を実行することにより、クエリ結果を取得する。通信品質判定部２６０は、アプリケーションごとの通信品質（図３参照）を判定する。バッファ管理部２５０は、アプリケーション端末１００との通信が切断された場合に、クエリ実行部２４０によって取得されたクエリ結果をバッファメモリ２７０に記憶させるか否かを、通信品質判定部２６０によって判定された通信品質に基づいて判定する。これによって、データベース管理システム１０は、データベース管理システム１０のネットワーク接続環境が不安定な場合であっても、アプリケーションの都合に応じてクエリ結果のデータを再送信することができる。
【００９０】
なお、バッファメモリ２７０は、バッファ管理部２５０および送受信管理部２１０が同時にアクセス可能なメモリである。このため、データベース管理装置２００のカーネル空間に、送受信管理部２１０専用の送信バッファを別途設ける必要が無い。これによって、メモリを節約することができるとともに、バッファメモリ２７０におけるアプリケーションごとの蓄積許可割合を、柔軟に設定することができる。
【００９１】
また、バッファ管理部２５０は、クエリ実行部２４０によって取得されたクエリ結果に対して通信に必要なヘッダ情報を付加し、ヘッダ情報が付加されたクエリ結果のパケットをバッファメモリ２７０に記憶する。送受信管理部２１０は、バッファメモリ２７０からクエリ結果のパケットを読み出し、読み出したクエリ結果のパケットをアプリケーション端末１００に送信する。これによって、送受信管理部２１０は、クエリ結果のパケットを加工することなく、アプリケーション端末１００に送信することができる。
【００９２】
（第２実施形態）
次に、第２実施形態について説明する。第１実施形態において、バッファ管理部２５０は、通信品質が悪いほど蓄積許可割合を大きくすることとした。これに対し、第２実施形態において、バッファ管理部２５０は、通信品質が悪いほど蓄積許可割合を小さくする。これによって、不安定な通信回線のクエリ結果によって、バッファメモリ２７０が専有されることを防止することができる。以下、第２実施形態の詳細を説明する。
【００９３】
第２実施形態においては、１つのアプリケーションとの通信のみが切断された場合、バッファ管理部２５０は、通信が切断されたアプリケーションに関するクエリ結果をバッファメモリ２７０に蓄積する。一方、２つ以上のアプリケーションとの通信が切断された場合、バッファ管理部２５０は、バッファメモリ２７０におけるアプリケーションごとの蓄積許可割合を調整する。具体的には、バッファ管理部２５０は、通信品質が悪いほど、蓄積許可割合を小さくする。
【００９４】
通信品質は、「０」から「３」のいずれかの値であるが、第１実施形態とは異なり、値が大きいほど通信回線の品質が良いことを表す。例えば、「３」は、通信品質が最も良く、異常切断が発生し難いことを示す。一方、「０」は、通信品質が最も悪く、異常切断が発生し易いことを示す。通信品質は、通信品質判定部２６０によって判定される。
【００９５】
バッファ管理部２５０は、通信品質が「１」以上である接続元に対して、バッファメモリ２７０の蓄積許可割合を設定する。バッファ管理部２５０は、各アプリケーションの通信品質を、通信が切断されているアプリケーションの通信品質の合計値で除算することによって、蓄積許可割合を算出する。バッファ管理部２５０は、算出した蓄積許可割合を、テーブルＴ１に書き込む。
【００９６】
以上説明したように、第２実施形態において、バッファ管理部２５０は、通信品質が悪いほど蓄積許可割合を小さくする。これによって、不安定な通信回線のクエリ結果によって、バッファメモリ２７０が専有されることを防止することができる。
【００９７】
（第３実施形態）
次に、第３実施形態について説明する。第１実施形態および第２実施形態において、バッファ管理部２５０は、アプリケーションごとの通信品質に基づいて蓄積許可割合を算出することとした。これに対し、第３実施形態において、クエリ実行部２４０は、クエリ結果を表すデータのデータ量を予測し、予測されたデータ量に基づいて蓄積許可割合を算出する。具体的に、クエリ実行部２４０は、予測されたデータ量が大きいほど蓄積許可割合を小さくする。これによって、バッファメモリ２７０の平均消費量を削減することができる。以下、第３実施形態の詳細を説明する。
【００９８】
図１６は、第３実施形態に係るテーブルＴ２の一例を示す図である。第３実施形態において、バッファ管理部２５０は、図３に示されるテーブルＴ１に代えて、図１６に示されるテーブルＴ２を用いて蓄積許可割合を判定する。テーブルＴ２は、接続元ＩＤと、予測データ量と、接続状態と、蓄積許可割合と、バッファ使用量と、カウント値とが対応付けられたテーブルである。
【００９９】
予測データ量は、クエリ結果を表すデータのデータ量の予測値を示す情報である。予測データ量は、「０」から「３」のいずれかの値であり、値が小さいほど予測データ量が大きいことを表す。例えば、集約関数または分析関数のみのクエリの場合、予測データ量は「３」である。集約関数または分析関数に“GROUP BY”が付いているクエリの場合、予測データ量は「２」である。“WHERE”句が多いクエリの場合、予測データ量は「１」である。その他のクエリ（例えば、スキャン）の場合、予測データ量は「０」である。テーブルＴ２における予測データ量以外の項目は、テーブルＴ１と同様であるので、説明を省略する。
【０１００】
接続元ＩＤは６バイトであり、予測データ量は２ビットであり、接続状態は１ビットであり、蓄積許可割合は６ビット（上限値：１００）であり、バッファ使用量は６ビット（上限値：１００）であり、カウント値は２バイトである。このため、テーブルＴ２における１つのエントリは、合計１０バイトで構成される。
【０１０１】
図１７は、第３実施形態に係るクエリ結果エントリ受取処理の詳細を示すフローチャートである。図１７に示されるクエリ結果エントリ受取処理は、クエリ結果エントリがクエリ実行部２４０からバッファ管理部２５０に入力されたときに実行される。クエリ結果エントリは、（ｘ，ｅ，ｒ）で表される。ｘは、クエリを識別するためのクエリ識別情報である。ｅは、レコード番号である。ｒは、クエリ結果のレコードである。
【０１０２】
まず、バッファ管理部２５０は、テーブルＴ２の「接続状態」を参照し、クエリ実行部２４０から入力されたクエリ結果エントリに関するアプリケーション端末１００が「接続中」であるか否かを判定する（Ｓ１００）。バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関するアプリケーション端末１００が「接続中」であると判定した場合、クエリ結果エントリを用いてパケットを作成し、作成したパケットをバッファメモリ２７０に記憶する（Ｓ１０１）。その後、バッファ管理部２５０は、本フローチャートによる処理を終了する。
【０１０３】
一方、Ｓ１００において、バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関するアプリケーション端末１００が「接続中」でないと判定した場合、テーブルＴ２において「異常切断中」となっているエントリが複数あるか否かを判定する（Ｓ１０２）。
【０１０４】
バッファ管理部２５０は、テーブルＴ２において「異常切断中」となっているエントリが複数あると判定した場合、テーブルＴ２の「予測データ量」を参照し、クエリ実行部２４０から入力されたクエリ結果エントリに関する「予測データ量」が「０」であるか否かを判定する（Ｓ１０３）。バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関する「予測データ量」が「０」であると判定した場合、クエリ結果エントリを保持できないことを示す結果保持不可エラーをクエリ実行部２４０に出力し（Ｓ１０４）、本フローチャートによる処理を終了する。
【０１０５】
一方、Ｓ１０２において、バッファ管理部２５０は、テーブルＴ２において「異常切断中」となっているエントリが複数あると判定しなかった場合、後述するＳ１０５に処理を進める。また、Ｓ１０３において、バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関する「予測データ量」が「０」でないと判定した場合も、後述するＳ１０５に処理を進める。
【０１０６】
Ｓ１０５において、バッファ管理部２５０は、テーブルＴ２を参照し、クエリ実行部２４０から入力されたクエリ結果エントリに関する「バッファ使用量」が「蓄積許可割合」に到達しているか否かを判定する（Ｓ１０５）。バッファ管理部２５０は、クエリ実行部２４０から入力されたクエリ結果エントリに関する「バッファ使用量」が「蓄積許可割合」に到達していると判定した場合、バッファメモリ２７０がフル状態であることを示すバッファフルエラーをクエリ実行部２４０に出力し（Ｓ１０６）、本フローチャートによる処理を終了する。
【０１０７】
一方、Ｓ１０５において、バッファ管理部２５０は、「バッファ使用量」が「蓄積許可割合」に到達していないと判定した場合、バッファメモリ２７０に空きがあるか否かを判定する（Ｓ１０７）。バッファ管理部２５０は、バッファメモリ２７０に空きがあると判定した場合、クエリ結果エントリを用いてパケットを作成し、作成したパケットをバッファメモリ２７０に記憶する（Ｓ１０８）。その後、バッファ管理部２５０は、テーブルＴ２における「バッファ使用量」を更新し（Ｓ１０９）、本フローチャートによる処理を終了する。
【０１０８】
一方、Ｓ１０７において、バッファ管理部２５０は、バッファメモリ２７０に空きがないと判定した場合、クエリ結果エントリを用いてパケットを作成し、作成したパケットをバッファメモリ２７０に記憶された他のエントリに上書きする（Ｓ１１０）。ただし、前述したように、テーブルＴ２に示される蓄積許可割合が「０％」の場合など、上書きできない場合もある。その後、バッファ管理部２５０は、テーブルＴ２における「バッファ使用量」を更新し（Ｓ１０９）、本フローチャートによる処理を終了する。
【０１０９】
図１８は、第３実施形態に係るクエリ処理の詳細を示すフローチャートである。図１８に示されるクエリ処理は、データベース管理装置２００がアプリケーション端末１００からクエリを受信した場合に、クエリ実行部２４０によって実行される。クエリは、（ｘ，ｑ）で表される。ｘは、クエリを識別するためのクエリ識別情報である。ｑは、クエリ内容である。
【０１１０】
まず、クエリ実行部２４０は、クエリの種類およびクエリの検索条件に基づいて、蓄積許可割合を算出する（Ｓ１２０）。具体的に、クエリ実行部２４０は、クエリ結果の予測データ量が「０」から「３」の何れであるかを判定する。前述したように、集約関数または分析関数のみのクエリの場合、予測データ量は「３」である。集約関数または分析関数に“GROUP BY”が付いているクエリの場合、予測データ量は「２」である。“WHERE”句が多いクエリの場合、予測データ量は「１」である。その他のクエリ（例えば、スキャン）の場合、予測データ量は「０」である。
【０１１１】
また、クエリ実行部２４０は、予測データ量を、通信が切断されているアプリケーションの予測データ量の合計値で除算することによって、蓄積許可割合を算出する。クエリ実行部２４０は、算出した蓄積許可割合をテーブルＴ２に書き込む。
【０１１２】
図１８におけるＳ１２１からＳ１３２の処理は、図１５におけるＳ８１からＳ９２の処理と同様である。このため、Ｓ１２１からＳ１３２の処理の詳細については、説明を省略する。
【０１１３】
以上説明したように、第３実施形態において、クエリ実行部２４０は、クエリ結果を表すデータのデータ量を予測する。バッファ管理部２５０は、クエリ実行部２４０によって予測されたデータ量に基づいて、クエリ実行部２４０によって取得されたクエリ結果をバッファメモリ２７０に記憶させるか否かを判定する。これによって、バッファメモリ２７０の平均消費量を削減することができる。
【０１１４】
以上説明した少なくともひとつの実施形態によれば、データベース管理システム１０は、送受信管理部２１０と、クエリ実行部２４０と、バッファ管理部２５０とを持つ。送受信管理部２１０は、アプリケーションを実行するアプリケーション端末１００からクエリを受信するとともに、クエリの検索対象のデータであるクエリ結果をバッファメモリ２７０から読み出してアプリケーション端末１００に送信する。クエリ実行部２４０は、送受信管理部２１０によって受信されたクエリに基づく処理を実行することにより、クエリ結果を取得する。バッファ管理部２５０は、アプリケーション端末１００との通信が切断された場合に、クエリ実行部２４０によって取得されたクエリ結果をバッファメモリ２７０に記憶させるか否かを、アプリケーションとの通信に関する評価値に基づいて判定する。これによって、データベース管理システム１０は、データベース管理システム１０のネットワーク接続環境が不安定な場合であっても、アプリケーションの都合に応じてクエリ結果のデータを再送信することができる。
【０１１５】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【０１１６】
１０…データベース管理システム、１００…アプリケーション端末、１１０…アプリケーション実行部、１２０…パケットサイズ決定部、２００…データベース管理装置、２１０…送受信管理部、２３０…接続管理部、２３１…パケットサイズ決定部、２４０…クエリ実行部、２５０…バッファ管理部、２６０…通信品質判定部、２７０…バッファメモリ、２８０…記憶部
【図１】
2018206206.tif 000003
【図２】
2018206206.tif 000004
【図３】
2018206206.tif 000005
【図４】
2018206206.tif 000006
【図５】
2018206206.tif 000007
【図６】
2018206206.tif 000008
【図７】
2018206206.tif 000009
【図８】
2018206206.tif 000010
【図９】
2018206206.tif 000011
【図１０】
2018206206.tif 000012
【図１１】
2018206206.tif 000013
【図１２】
2018206206.tif 000014
【図１３】
2018206206.tif 000015
【図１４】
2018206206.tif 000016
【図１５】
2018206206.tif 000017
【図１６】
2018206206.tif 000018
【図１７】
2018206206.tif 000019
【図１８】
2018206206.tif 000020