JP3622047B2 - データベースバックアップ処理方法 - Google Patents
データベースバックアップ処理方法 Download PDFInfo
- Publication number
- JP3622047B2 JP3622047B2 JP22093998A JP22093998A JP3622047B2 JP 3622047 B2 JP3622047 B2 JP 3622047B2 JP 22093998 A JP22093998 A JP 22093998A JP 22093998 A JP22093998 A JP 22093998A JP 3622047 B2 JP3622047 B2 JP 3622047B2
- Authority
- JP
- Japan
- Prior art keywords
- database
- checkpoint
- calls
- storage device
- backup
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Techniques For Improving Reliability Of Storages (AREA)
- Retry When Errors Occur (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明の属する技術分野】
本発明は、一次記憶装置上にデータベースを格納する情報通信処理システムにおけるデータベースバックアップ処理方法に係り、特にデータベースのバックアップを周期的に収集する場合のデータベースバックアップ処理方法に関する。
【0002】
【従来の技術】
図2は、高度インテリジェントネットワーク(IN:Intelligent Network)の基本的構成を示す図である。同図において、1はサービス管理ノード(SMS)、2はパケット網、3はサービス制御ノード(SCP)、4は共通線信号網、5は交換機、6は端末、7は通話線であり、また、11および31は、フリーダイヤルや移動通信等のサービスの実現のためにサービス管理ノード(SMS)1およびサービス制御ノード(SCP)3に保持されているデータベース(DB)であり、51は交換機5が保持する新サービス機能である。
【0003】
これらのデータベース(DB)を保持する媒体としては、データベース(DB)の規模、アクセス頻度等を考慮し、一般的に一次記憶装置である主記憶装置(MM)が用いられる。データベース(DB)に格納したデータを高い確度で保証する必要のある高信頼情報通信処理システムにおいては、ソフトウェアの暴走やハードウェアの障害によって主記憶装置(MM)上のデータベース(DB)が破壊された場合に破壊直前のデータベース(DB)のデータを復元できるように、二次記憶装置すなわち主記憶装置(MM)とは別の記憶装置へバックアップが取られる。
【0004】
図3は、従来のデータベースバックアップ処理方法を説明するための図である。
同図に示した中央処理装置(CPU)201、主記憶装置(MM)202、半導体ディスク装置(SD)203は、例えば、図2におけるサービス制御ノード(SCP)3を構成する一部の装置である。本構成において、主記憶装置202に保持されているデータベース(DB)2021をバックアップするために、チェックポイント(CP)時点のデータベース(すなわちチェックポイントデータベース(CPDB)2031)とチェックポイント(CP)以降のデータベースの更新履歴(LOG)2032を収集して磁気ディスク装置または半導体ディスク装置などの外部記憶装置(図3は半導体ディスク装置SDの場合を示す)に格納する(図のa参照)。なお、チェックポイント(CP)は、一定周期毎(即ち、一定間隔毎)にとられているのが普通である。
【0005】
障害検出時には外部記憶装置からチェックポイントデータベース(CPDB)2031と該チェックポイント以降の更新履歴(LOG)2032を読み出し、チェックポイントデータベース(CPDB)2031に更新履歴(LOG)2032を上書きすることにより障害直前のデータベースを復元する。従来技術におけるデータベースバックアップ処理方法としては、例えば、文献「平野他:分散処理による高度IN用サービス制御ノードの構成、電子情報通信学会論文誌B−1 Vol.J79−B−1 No.8 PP.539−550 1996年8月」に開示されたものがある。
【0006】
【発明が解決しようとする課題】
上述したようなチェックポイントデータベース(CPDB)を周期的に収集する従来のデータベースバックアップ処理方法では、バックアップの周期を決定する際に、データベースを参照して接続されるINサービス呼の損失数への影響があるにも関わらず、それに対する考慮がなされていなかった。このため、採用された周期の値によっては、損失呼数を不当に大きくしてしまい、ユーザに迷惑をかける、という事態が生じる。
本発明の目的は、このような従来方法の欠点を解消し、呼の損失数を最小とする周期でバックアップを収集するようにし、システム運用中にユーザへ与える影響を最小とするデータベースバックアップ処理方法を提供することである。
【0007】
【課題を解決するための手段】
上記目的を達成するために、本発明のデータベースバックアップ処理方法は、主記憶装置MM上のデータベース(DB)をチェックポイントデータベース(CPDB)としてバックアップ収集する際のバックアップ周期を、データベース(DB)復元処理中に呼接続に必要な情報が得られず損失となる呼数(f1)とチェックポイント時点のデータベース(CPDB)のバックアップ処理中に最新の情報が得られず損失となる呼数のシステム運用開始時点からデータベース破壊発生時点までの総数(f2)との合計が最小となるように選んだことを特徴としている。この構成により、データベースのバックアップを損失呼数が最小となるような周期で収集できるため、システム運用中にユーザへ与える影響を最小とすることが可能になる。
【0008】
【発明の実施の形態】
以下、図1,および図4〜図6を用いて本発明の実施例を詳細に説明する。
図1は、本発明のデータベースバックアップ処理方法が実施される情報通信処理システムの一部の装置の構成例、およびデータベース(DB),チェックポイントデータベース(CPDB),更新履歴(LOG)の配置を示す図である。
同図において、100はシステムバス、101はサービスを実現するプログラムを主に実行する情報通信処理システムの中央処理装置(CPU)、102はプログラムやプログラムが参照するデータを保持するとともに、本発明におけるバックアップ対象であるデータベース(DB)1021を保持する主記憶装置(MM)である。
【0009】
103は、主記憶装置(MM)102上のデータベース(DB)1021のバックアップ用装置として設けられた半導体ディスク装置(SD)であり、チェックポイントデータベース(CPDB)1031を2面分と更新履歴(LOG)1032を1面分保持している。
【0010】
104は、システムバス100を介して中央処理装置(CPU)101と接続され、配下に半導体ディスク装置(SD)103を収容するSD制御装置であり、主記憶装置(MM)102上のデータベース(DB)1021を半導体ディスク装置(SD)103へバックアッする際、主記憶装置(MM)−半導体ディスク装置(SD)間のデータベース転送を制御するものである。
105は周辺装置である。
【0011】
図3に示した上記構成は、本発明を実現する上で特別に構成されたものではない。通常のプログラム実行機能を持つた中央処理装置/主記憶装置、システムバス、半導体メモリおよびアクセス制御回路から成る半導体メモリ装置、主記憶装置−半導体メモリ装置間のデータ転送制御装置を有するものであれば、本発明のデータベースバックアップ処理方法を実現するシステムとなり得る。
【0012】
図3の中央処理装置(CPU)101、主記憶装置(MM)102、半導体ディスク制御装置(SDC)104、半導体ディスク装置(SD)103、その他の装置(周辺装置105など)は一重化構成として示しているが、システムに要求された信頼度条件に応じて冗長構成がとられてもよいことはいうまでもない。冗長構成の形態によってバックアップ周期を決定する際のパラメータ値が変化し得る(例えば、後述のデータベース破壊発生間隔Tfi)が、損失呼数を最小とする周期を決定する方法を説明する上で、冗長構成は直接関連しないため、特に図示することはしない。
なお、主記憶装置(MM)上のデータベース(DB)を構成する項目は、実現するサービスに応じて各種のものが存在する。例えば、PHSのような移動通信サービスの場合、データベースには端末の電話番号、位置情報、認証キーなどの項目が含まれる。
【0013】
図4は、本発明における中央処理装置(CPU)/主記憶装置(MM)から半導体ディスク装置(SD)へのチェックポイントデータベース(CPDB)および更新履歴(LOG)の収集のタイムチャートを示す図である。
チェックポイントデータベース(CPDB)の収集は、周期τ毎(図中のX点,Y点,Z点)に起動される中央処理装置(CPU)上のプログラムによつて実行される。チェックポイントデータベース(CPDB)は半導体ディスク装置(SD)上に2面分保持している(注:1面しか保持しない場合、チェックポイントデータベース(CPDB)収集処理中に主記憶装置(MM)等に障害が発生した場合、データベース(DB)を完全に復元することができなくなる)。例えば、図に示すように、X点のチェックポイントデータベース(CPDB)は第1面に保持し、Y点のチェックポイントデータベース(CPDB)は第2面に保持し、Z点のチェックポイントデータベース(CPDB)は第1面に保持する。
【0014】
一方、更新履歴(LOG)の収集は、データベース(DB)の内容を変更するようなイベント(例えば、PHS端末の位置登録)が発生する都度、中央処理装置(CPU)上のプログラムによって実行される。なお、収集情報の更新履歴(LOG)のうち、不要になつたものは廃棄される。即ち、主記憶装置(MM)上のデータベース(DB)が破壊された時、チェックポイントデータベース(CPDB)とそのチェックポイント以降の更新履歴(LOG)があれば、破壊直前のデータベース(DB)内容を復元できるため、収集済みの更新履歴(LOG)は、チェックポイントデータベース(CPDB)が正常に収集できた時点で、そのチェックポイントまでの分は廃棄される。すなわち、図に示すように、X点,Y点,Z点のチェックポイントデータベース(CPDB)のバックアップが終了した時点で、それぞれX点,Y点,Z点までの更新履歴(LOG)を廃棄する。これにより、半導体ディスク装置(SD)上の更新履歴(LOG)用の領域を不当に大きくしないで済む。
【0015】
図5は、主記憶装置(MM)上のデータベース(DB)破壊が発生した時の復元方法を、データベース(DB)破壊発生ポイントの2つケースについて示した図である。
ケース1はチェックポイントデータベース(CPDB)収集中のC時点でデータベース(DB)破壊が発生したケース、ケース2はチェックポイントデータベース(CPDB)正常収集後、次のチェックポイントデータベース(CPDB)収集開始前のD時点でデータベース(DB)破壊が発生したケースである。
【0016】
ケース1では、1周期前に正常収集したチェックポイントデータベース(CPDB)(即ち、X点でのチェックポイントデータベース)と、そのチャックポイント以降の更新履歴(LOG)(即ち、図のx′区間の更新履歴)とからデータベース(DB)を復元する。
一方、ケース2では当該周期に正常収集されたチェックポイントデータベース(CPDB)(即ち、Y点でのチェックポイントデータベース)とそのチェックポイント以降の更新履歴(LOG)(即ち、図のy′区間の更新履歴)とからデータベース(DB)を復元する。
ケース1とケース2とを比較した場合、ケース1の方が更新履歴(LOG)収集区間が大きくなっているため、更新履歴(LOG)量が大きくなり、半導体ディスク装置(SD)から主記憶装置(MM)への転送およびチェックポイントデータベース(CPDB)への反映に時間がよりかかるため、データベース(DB)復元時間がより大きくなる。
【0017】
次に、本発明のデータベースバックアップ処理方法に係るバックアップ周期τの値について説明する。
ここでは、PHS等の移動通信サービスを例にとり、周期τの決定方法を説明する。
移動通信では呼の接続のためにデータベース(DB)上の端末位置情報を用いる。
(i)周期τを大きく選ぶと、更新履歴(LOG)量が増加して主記憶装置(MM)上データベース(DB)の破壊時のデータベース(DB)復元時間が増加する。このため、復元中に着信して損失となる呼が増えてくる。
(ii)逆に、周期τを小さく選ぶとCPU上でのバックアップ処理中に着信した呼がCPU処理待ちとなり、その間に着信先端末の位置が変更してしまって損失となるケースが起き易くなる。
本発明は、周期τに比例および反比例する上記2つの観点から損失呼数を求め、両者の合計値を最小とする周期τを決定することにより、ユーザに呼損という形で与える影響をより小さくするようにしたことを特徴とするものである。
【0018】
以下、上記(i)のデータベース(DB)復元中に発生する損失呼数f1(τ)、と上記(ii)のバックアップ処理との競合で発生する損失呼数f2(τ)、を求める方法を説明する。
1)データベース(DB)復元中の損失呼数:f1(τ)
データベース(DB)復元中の損失呼数f1(τ)はデータベース(DB)復元中に着信する呼数に等しい。Nをユーザ端末数、λicを着信呼の発生率、Tr(τ)をデータベース(DB)復元時間とすると、f1(τ)は次式(1)で与えられる。
f1(τ)=N*λic*Tr(τ) ・・・・・・・・・・・・・・・・(1)
ここで、式(1)のデータベース(DB)復元時間Tr(τ)は、図5に示されているように、▲1▼チェックポイントデータベース(CPDB)転送時間(注:周期τに関係しないためTdbとする)と、▲2▼チェックポイント以降の更新履歴(LOG)の転送時間(注:周期τに依存するのでTlog(τ)とする。なお、logはTの添字であり、対数関数でないことに注意)の合計、即ち、次式(2)で与えられる。
Tr(τ)=Tdb+Tlog(τ) ・・・・・・・・・・・・・・・・(2)
【0019】
▲1▼「Tdbの値」
式(2)のチェックポイントデータベース(CPDB)転送時間Tdbは、Sをユーザ当たりのデータベース(DB)サイズ、Rを主記憶装置(MM)−半導体ディスク装置(SD)間のデータ転送レートとすると、次式(3)で与えられる。
Tdb=S*N/R ・・・・・・・・・・・・・・・・・・(3)
【0020】
▲2▼「Tlog(τ)の値」
また、更新履歴(LOG)転送時間Tlog(τ)は、主記憶装置(MM)へ転送すべき更新履歴(LOG)量から決まり、更新履歴(LOG)量は更新履歴(LOG)収集区間中に発生する位置登録呼数から求まる。更新履歴(LOG)収集区間は、データベース(DB)破壊がバックアップ処理中に発生するか否かに応じて図5の2つのケース(即ち、x′区間とy′区間)が存在するため、期待値は次式(4)のようになる。
ここで、P(τ)=Tbk/τ(注:Tbkはデータベース(DB)バックアップ時間)はデータベース(DB)破壊がバックアップ処理中に発生する確率である。従つて、λlrを位置登録呼の発生率とすると、Tlog(τ)は次式(5)のようになる。
Tlog(τ)
=S*N*λlr*更新履歴(LOG)収集区間/R ・・・・・・・・・(5)
以上により、式(1)〜式(5)を用いてf1(τ)が求まる。
【0021】
2)バックアップ処理との競合による損失呼数:f2(τ)
次に、f2(τ)の求め方を説明する。
バックアップ処理中に着呼し、その処理がCPU上で待ちの間に着信先の端末位置がたまたま変わると、データベース(DB)上の端末位置情報が実態と異なってしまい正常に接続できず呼損が生じ得る。この呼損は、主記憶装置(MM)上のデータベース(DB)のチェックポイントデータベース(CPDB)収集処理、PHS等の端末への着信処理、その端末の登録位置変更処理が重なった場合に発生する。
【0022】
その確率Pct(τ)は、上記各処理のプロセッサ使用率をδbk(τ),δic,δlrとした時、これら3者の積にN/N2をかけたものに等しく、式(6)となる。
Pct(τ)
=δbk(τ)*δlr*δic*N/N2 ・・・・・・・・・・・・・・(6)
ここで、N/N2をかけているのは、N個のうちのある端末への着信処理とN個のうちのある端末の位置変更処理とが重なるケースがN2通りあり、そのうち両者の端末が一致するケースがN通りであるためである。
【0023】
バックアップ処理との競合による損失呼数f2(τ)は、システム運用開始からデータベース(DB)破壊発生時点までの損失呼の総和であり、データベース(DB)破壊発生間隔をTfiとすると式(7)のようになる。
f2(τ)
={Pct(τ)/着呼処理の呼当たりのCPU保留時間}*Tfi ・・(7)
以上より、式(6)および式(7)を用いてf2(τ)を求めることができる。
【0024】
3)本発明で適用するバックアップ周期の値:τ
本発明で適用するチェックポイントデータベース(CPDB)収集の周期τは、上記f1(τ)、f2(τ)の値を基に、それらの合計、即ち、
f(τ)=f1(τ)+f2(τ)を最小とするτの値として求めることができる。
【0025】
図6は、周期τと、データベース復元中に発生する損失呼数f1(τ),バックアップ処理との競合で発生する損失呼数f2(τ),および合計の損失呼数f(τ)との関係を、横軸に周期τ,縦軸に損失呼数をとって表したものである。同図では、データベース破壊発生間隔Tfi〔時間〕として3つのケースを示している。第1のケースは、Tfi=1.0*107、第2のケースはTfi=5.0*106、第3のケースはTfi=1.0*106の場合である。ここで、各パラメータ値は、一例として、N=25万ユーザ、S=0.3KB/ユーザ、R=0.5MB/秒、λic=0.04呼/時間、λlr=0.3呼/時間、δbk(τ)=0.02〔分〕/τ〔分〕、δlr=0.22、δic=0.029とした。
【0026】
図6から、損失呼数を少なくする最適周期は、f(τ)の最小値(極小値)であるτの値であり、Tfiが短くなる(即ち、データベース破壊が起き易いシステム)ほど小さい周期τになることがわかる(図6の最適周期点の位置を参照)。但し、方式成立条件「τ≧Tbk」が存在するので、最小でも、データベースバックアップ時間Tbk以上の値を選定しなければならない。
本発明では、上記のようにして決定した最適周期τを用いてチェックポイントデータベース(CPDB)のバックアップ収集を行うようにすることにより、従来のデータベースバックアップ処理方法に比較し、ユーザに呼損という形で与える影響をより小さくしたバックアップ処理方法を提供することが可能となる。
【0027】
ここで、本実施例に利用される上記各パラメータとその値の設定の仕方の一例をより詳しく説明しておく。
Nはユーザ端末数であり、図2のサービス制御ノード(SCP)が処理すべき(収容すべき)最大端末数でサービス制御ノード(SCP)の設計条件として与えられるものである。
Sは、ユーザ端末当たりのデータベースサイズであり、図1の説明において記載されている通り、主記憶装置(MM)上に保持されたデータベース(DB)上には、ユーザ端末ごとに、その電話番号,位置情報,認証キー等のサービス実現に必要なデータが保持されている。Sはこれらの情報を記憶するのに必要なメモリ量(バイト数)である。システムの設計内容が決まると、格納する項目当たりの所要メモリ量がきまるのでSの値も決まる。
【0028】
Rは、主記憶装置(MM)−半導体ディスク装置(SD)間のデータ転送レート(単位時間当たりの転送データ量;バイト数)であり、図1の半導体ディスク制御装置(SDC)の転送性能のことで、主記憶装置(MM)−半導体ディスク装置(SD)間で採用される転送方式と関連装置の性能から決定される。すなわちシステムの設計内容によって一義的に決定される値である。
λicは着信呼の発生率,λlrは位置登録呼の発生率であり、それぞれ、端末に着信する呼,端末位置が変更しそれを要求する呼の単位時間当たり・端末当たりの生起数である。サービス制御ノード(SCP)設計上のトラフィック条件で
設計に先立って上記ユーザ端末数Nと同様に外部条件として与えられる。
【0029】
Tbkは、データベース(DB)のバックアップ時間、すなわち、主記憶装置(MM)上のチェックポイントデータベース(CPDB)を半導体ディスク装置(SD)にバックアップするのに要する時間であり、式(3)のチェックポイントデータベース転送時間Tdbと同一の値であって、ユーザ端末当たりのデータベースサイズS,ユーザ端末数N,主記憶装置−半導体ディスク装置間のデータ転送レートRから計算で求めることができる。
【0030】
δbkはチェックポイントデータベース(CPDB)収集処理のプロセッサ使用率,δlrは端末の登録位置変更処理のプロセッサ使用率,δicは端末への着信処理のプロセッサ使用率であり、上記各処理を1回実行するのに走る命令数と中央処理装置(CPU)に用いられるプロセッサの性能(即ち、単位時間当たり実行できる命令数)との比率のことで、システムの設計内容(即ち、用いるプロセッサ種別とその上で走るプログラム内容)が決まると算出できる比率である。
【0031】
Tfiは、主記憶装置(MM)上のデータベース破壊の発生間隔、即ち、主記憶装置上に保持されたデータベースが破壊されるような事象の発生間隔で、サービス制御ノード(SCP)内の関連装置の故障発生率と関連装置の冗長構成などから決まる値である。この値もサービス制御ノード(SCP)というシステムの設計内容が決まると一義的に算出できる値である。
以上のように、各パラメータはシステム設計内容によって決定されるので、これらのパラメータを用いてf(τ)が最小値(極小値)を有するτの値を予め求めることができ、このτの周期でチェックポイントデータベースを収集することによって、損失呼数を最小にすることが可能になる。
【0032】
<実施例のバリエーション>
1)上記実施例では、インテリジェントネットワーク(IN)サービスを対象に、それを実現するシステムにおけるデータベースバックアップ処理方法について説明したが、サービスの種別、実現するシステムの構成は、上記実施例だけに限定されないことは言うまでもない。本発明は、サービス実現のために何らかのデータベースを保持し、ユーザへのサービス実現に当たつて逐次その内容の更新を伴い、かつ故障発生時のデータベース内容保証の観点から周期的にデータベースを保持する記憶装置とは別の記憶装置へバックアップを行うようにした全てのシステムに適用が可能であり、上記実施例と同様の効果が得られる。
【0033】
2)図3のシステム構成はほんの一例に過ぎない。データベース(DB)を保持する記憶装置とチェックポイントデータベース(CPDB)/更新履歴(LOG)を保持する記憶装置は、分離された別な装置であればよく、また記憶手段としては、半導体メモリ装置、ハード磁気ディスク装置、光磁気ディスク装置等、いずれでもよい。さらに、図3はシングルプロセッサ構成として示しているが、マルチプロセッサ構成における1つのプ口セッサシステムと考えてもよい。また、複数プロセッサが、共通メモリ装置(即ち、一次記憶装置)上にデータベース(DB)を共有し、そのバックアップを別な共通の二次記憶装置上にとるような構成であってもよい。なお、チェックポイントデータベース(CPDB)と更新履歴(LOG)は、上述したように同一の二次記憶装置上に収集格納するようにしてもよいが、それぞれを別々の二次記憶装置に格納するようにしてもよい。
【0034】
3)上記の実施例ではチェックポイントデータベース(CPDB)のバックアップ収集、更新履歴(LOG)収集をCPU上のプログラムで実行する場合を説明したが、処理効率化のために一部をハードウェアで実行するようにしてもよい。4)また、チェックポイントデータベース(CPDB)が正常に収集できた時点で、そのチェックポイントまでの更新履歴(LOG)を廃棄する方式を説明したが、そのまま継続して保持し別なタイミングで廃棄するようにした構成であってもよく、データベースを復元の際に対応するチェックポイント以降の更新履歴(LOG)が判別できるようになっている限り本発明の効果は失われない。
【0035】
5)また、上記実施例では、データベースのバックアップを損失呼数が最小となるような周期を予め求める場合を説明したが、上記各パラメータを記憶装置に保持しておき、このパラメータを用いてf(τ)を最小にするτを自動的に求めるようにしてもよい。またこの場合、記憶装置に格納するパラメータはシステム設計時に予め決められた値を設定してもよいが、パラメータが変更された場合またはシステムの動作条件によって時間的に変化するパラメータを定期的に取得して記憶装置に格納するようにしてもよい。例えば、データ転送レートや着信呼/位置登録呼の発生率,CPUの使用率などを測定する手段を内蔵し、該手段で測定して得た値を定期的に上記記憶装置に格納するようにしてもよい。この構成によれば、設計変更によりパラメータに変更を生じた場合や、システムの稼働状態が変わりパラメータの値に変更が生じたりした場合にも、その時点で、より最適なパラメータの値を用いて損失呼数が最小になる周期τを動的に求めることができる。
【0036】
【発明の効果】
以上説明したように、本発明のデータベースバックアップ処理方法によれば、データベースのバックアップを損失呼数が最小となるような周期で収集するようにしているため、システム運用中にユーザへ与える影響を最小とするデータベースバックアップ処理方法を提供することができる。
【図面の簡単な説明】
【図1】本発明が実施される情報通信処理システム(一部)の構成例を示す図である。
【図2】本発明が適用されるシステムを一部に有する高度インテリジェントネットワーク(IN)の基本的構成を示す図である。
【図3】従来のデータベースバックアップ処理方法を説明するための図である。
【図4】本発明の実施例におけるチェックポイントデータベースおよび更新履歴収集のタイムチャートを示す図である。
【図5】本発明の実施例におけるデータベース破壊発生ポイントの2つのケースとデータベース復元方法を示す図である。
【図6】本発明の実施例におけるデータベース(DB)バックアップ周期と損失呼数との関係の評価例を示す図である。
【符号の説明】
1:サービス管理ノード(SMS)
2:パケット網
3:サービス制御ノード(SCP)
4:共通線信号網
5:交換機
6:端末
7:通話線
101:中央処理装置(CPU)
102:主記憶装置(MM)
103:半導体ディスク装置(SD)
104:半導体ディスク制御装置(SDC)
105:周辺装置
11,31,1021,2021:データベース(DB)
1031,2031:チェックポイントデータベース(CPDB)
1032,2032:更新履歴(LOG)
Claims (2)
- 通信サービス実現のために情報通信処理システムの一次記憶装置上に格納された内容の更新もしくは参照を伴うデータベースを二次記憶装置へ周期的にバックアップするデータベースのバックアップ処理方法であって、二次記憶装置上にチェックポイント時点のデータベースとチェックポイント以降のデータベースの更新履歴を格納しておき、障害検出時に前記二次記憶装置から前記チェックポイント時点のデータベースと前記更新履歴を読み出し、前記チェックポイント時点のデータベースに更新履歴を上書きすることにより障害直前のデータベースを一次記憶装置上に復元するようにしたデータベースバックアップ処理方法において、
前記チェックポイント時点のデータベースの格納処理を、データベース復元処理中に呼接続に必要な情報が得られず損失となる呼数(f1)とチェックポイント時点のデータベースのバックアップ処理中に最新の情報が得られず損失となる呼数のシステム運用開始時点からデータベース破壊発生時点までの総数(f2)との合計が最小となる周期で行うようにしたことを特徴とするデータベースバックアップ処理方法。 - 請求項1記載のデータベースバックアップ処理方法において、前記データベース復元処理中に呼接続に必要な情報が得られず損失となる呼数(f1)とチェックポイント時点のデータベースのバックアップ処理中に最新の情報が得られず損失となる呼数のシステム運用開始時点からデータベース破壊発生時点までの総数(f2)との合計が最小となる周期は、前記情報通信処理システムの設計内容に基づいて予め算出されるか、あるいは、該設計内容および該情報通信システムの稼働状態に基づいて算出されることを特徴とするデータベースバックアップ処理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP22093998A JP3622047B2 (ja) | 1998-08-05 | 1998-08-05 | データベースバックアップ処理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP22093998A JP3622047B2 (ja) | 1998-08-05 | 1998-08-05 | データベースバックアップ処理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2000057031A JP2000057031A (ja) | 2000-02-25 |
JP3622047B2 true JP3622047B2 (ja) | 2005-02-23 |
Family
ID=16758934
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP22093998A Expired - Lifetime JP3622047B2 (ja) | 1998-08-05 | 1998-08-05 | データベースバックアップ処理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3622047B2 (ja) |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH03127141A (ja) * | 1989-10-13 | 1991-05-30 | Hitachi Ltd | バックアップ時期通報方法及び装置 |
JPH07175700A (ja) * | 1993-12-20 | 1995-07-14 | Fujitsu Ltd | データベース管理方式 |
JP2980310B2 (ja) * | 1996-12-05 | 1999-11-22 | 日本電気ソフトウェア株式会社 | 自動バックアップスケジュール方式 |
JP3428842B2 (ja) * | 1997-01-08 | 2003-07-22 | 株式会社日立製作所 | 情報処理システムおよびデータ多重化システム |
-
1998
- 1998-08-05 JP JP22093998A patent/JP3622047B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2000057031A (ja) | 2000-02-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3534596B2 (ja) | インテリジェントネットワーク内のデータベースの同期方法と装置 | |
EP0683942B1 (en) | Restoration of a home location register in a mobile radio system | |
US5937343A (en) | Method and system for updating replicated databases in a telecommunication network system | |
EP0702497B1 (en) | A method and system for updating replicated databases in telecommunication networks | |
EP0398987B1 (en) | Communications network state and topology monitor | |
EP1116115A2 (en) | Protocol for replicated servers | |
EP1001343B1 (en) | Highly available asynchronous I/O for clustered computer systems | |
WO2012171349A1 (zh) | 一种分布式自增计数的实现方法、装置及系统 | |
EP1131756B1 (en) | Protocol for synchronizing parallel processors in a mobile communications system | |
EP0409604A2 (en) | Processing method by which continuous operation of communication control program is obtained | |
JP3622047B2 (ja) | データベースバックアップ処理方法 | |
US7171410B1 (en) | Fault tolerant network element | |
JP3447347B2 (ja) | 障害検出方法 | |
US6085254A (en) | Dynamic size alteration of memory files | |
JP3627619B2 (ja) | 二相コミット回避方式およびそのプログラム記録媒体 | |
AU728567B2 (en) | Event recording in a service database system | |
KR19990076336A (ko) | 교환기에서 과금 데이터 유실 방지 방법 | |
JPH06311159A (ja) | パケット交換装置の課金収集方法 | |
JP2690171B2 (ja) | 蓄積交換機の再開処理方法 | |
JP2959467B2 (ja) | 疎結合多重計算機システムにおける障害復旧システム、障害復旧方法、および障害復旧プログラムを記憶する媒体 | |
KR100351488B1 (ko) | 교환기에서의 멀티링크를 이용한 과금 파일 관리방법 | |
JP2999024B2 (ja) | 子プロセスの終了待ち合わせ処理装置 | |
JP2507600B2 (ja) | 図面情報の仮更新制御方式 | |
JP2594761B2 (ja) | ジャーナルフアイル管理装置 | |
CN113515557A (zh) | 分布式短序列号生成方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040628 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040803 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040921 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20041026 |
|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7426 Effective date: 20041026 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041108 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071203 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081203 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091203 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101203 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101203 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111203 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111203 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121203 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121203 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131203 Year of fee payment: 9 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
EXPY | Cancellation because of completion of term |