(57)【特許請求の範囲】
【請求項１】
２つの磁気ディスクを備え、これらの磁気ディスクに複数領域ずつあるStateDBのうち、正常なStateDBが全体の１／２以下になった場合に次回のリブート時にシステムを立ち上がらなくするソフトウェアをデータベースの運用に採用しているデータベース管理システムにおいて、
所定周期ごとにSyslogをチェックし、当該Syslogにどちらかの磁気ディスクのＯＳ領域に対するエラーが含まれていればStateDB領域の障害の予兆有りと判断し、前記SyslogにStateDB領域に対するエラーが含まれていれば当該StateDB領域に障害有りと判断する障害監視手段と、
前記障害監視手段が前記障害又は障害の予兆を発見したときに、該当する磁気ディスクのすべてのStateDBを削除するStateDB削除手段とを備えて成るデータベース管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば、Sun社製のデータベースソフトウェアSolsticeDiskSiuteのように、２つの磁気ディスクを備え、これらの磁気ディスクにあるStateDBのうち、正常なStateDBが全体の１／２以下になった場合に次回のリブート時にシステムを立ち上がらなくするソフトウェアを利用するデータベース管理システム及びデータベースシステムの管理方法に関する。
【０００２】
【従来の技術】
Sun社のUNIXワークステーションの内蔵ディスクミラーリングの標準ソフトウェアであるSolsticeDiskSiuteは、StateDBを３個以上持ち、そのうちエラーとなったStateDBの数が１／２以上（１／２も含む）になると、次回のリブート時にシステムを立ち上がれなくする仕様となっている。
【０００３】
このデータベース管理ソフトウェアSolsticeDiskSuiteは、２台の大容量ハードディスクをミラーリングしながらデータベースを運用する場合、各ディスクに３つずつ、合計６つのStateDBを持たせるが、片方のディスクの全体に障害が発生するとStateDBの数が３つ減り、正常なStateDBは他方のディスクのStateDBの３つだけになり、正常なStateDBの割合は１／２以下となってしまうので、残りのディスク１台が健全であっても次回のリブート時にシステムが立ち上がらなくなってしまう。
【０００４】
そこで、このような障害が発生すれば、データベース管理者はシステムの設置場所に出向き、エラーの発見されたStateDBを削除し、正常なStateDBのみにして再起動するオペレーションを行うようにしている。
【０００５】
また、従来、ディスク障害が現行ブートディスクのブート領域に発生すれば、次回のリブート時に立ち上がらなくなるが、そのような場合にも、管理者がシステムの設置場所に出向き、ブート領域に障害の発生しているディスクから他方のディスクにブートディスクの指定を切り替え、再起動させるオペレーションを行うようにしている。
【０００６】
【発明が解決しようとする課題】
このように、従来のデータベース管理システムでは、一方のハードディスクに障害が発生して次回のリブートができなくなったときには、システム管理者がシステムの設置現場に出向き、必要なオペレーションを行ってシステムがリブートできるようにする。
【０００７】
Sun社製のSolsticeDiskSuiteによるデータベースシステムでは、上述したような片側のハードディスクの障害でシステムのリブートができなくなった場合、健全な他方のディスクをブートディスクにして次のハードウェアの定期点検の時期まで継続して運用するのが実情である。そのために、上述したようにシステム管理者がシステムの設置現場に出向いて作業する必要があった。
【０００８】
本発明は、このような従来の技術的課題に鑑みてなされたもので、例えばSun社のSolsticeDiskSiuteのように、２つの磁気ディスクを備え、これらの磁気ディスクにあるStateDBのうち、正常なStateDBが全体の１／２以下になった場合に次回のリブート時にシステムを立ち上がらなくするソフトウェアでデータベースシステムを運用するにおいて、片側のディスクのStateDBにエラーが発生しても、次回のリブートを可能にして管理者に求められる作業を極力減らすことができるデータベース管理技術を提供することを目的とする。
【００１０】
【課題を解決するための手段】
請求項１の発明は、２つの磁気ディスクを備え、これらの磁気ディスクに複数領域ずつあるStateDBのうち、正常なStateDBが全体の１／２以下になった場合に次回のリブート時にシステムを立ち上がらなくするソフトウェアをデータベースの運用に採用しているデータベース管理システムにおいて、所定周期ごとにSyslogをチェックし、当該Syslogにどちらかの磁気ディスクのＯＳ領域に対するエラーが含まれていればStateDB領域の障害の予兆有りと判断し、前記SyslogにStateDB領域に対するエラーが含まれていればStateDB領域の障害有りと判断する障害監視手段と、前記障害監視手段が前記障害又は障害の予兆を発見したときに、該当する磁気ディスクのすべてのStateDBを削除する StateDB削除手段とを備えたものである。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態を図に基づいて詳説する。図１は、２つの磁気ディスクを備え、これらの磁気ディスクにあるStateDBのうち、正常なStateDBが全体の１／２以下になった場合に次回のリブート時にシステムを立ち上がらなくするソフトウェアとしてSun社製のSolsticeDiskSuiteを運用ソフトとするデータベースのサーバを示している。
【００１７】
このサーバは、２台の磁気ディスクDISK#1とDISK#2を内蔵している。両ディスクそれぞれは、Boot領域（ブート領域）を含むＯＳ領域（オペレーティングシステム領域）、仕様上ディスク毎に３つのStateDB（DISK#1はDB1，DB2，DB3、DISK#2はDB4，DB5，DB6）が記録されるStateDB領域、そしてミドルウェア（MW）、データを記録するMW、データ領域を有している。
【００１８】
データベース管理ソフトであるSolsticeDiskSuiteは、２台の磁気ディスクでミラーリングを実施するが、正常なStateDBがシステム中で１／２以下になるとRAIDを維持できない仕様である。
【００１９】
そして本サーバのデータベース管理ソフトでは、C shellコマンドで所定周期、例えば、５分ごとにSyslogをチェックし、StateDB領域にエラーが発生する予兆がある場合、又はStateDB領域にエラーがある場合にStateDBを削除するコマンド（metadb -d 3 “デバイス名”）を該当する磁気ディスクのStateDB領域について実行するプログラムが追加されている。
【００２０】
これにより、第１の実施の形態のデータベース管理システムでは、片側の磁気ディスクのStateDB領域に障害が発生しても、次回のリブート時に起動できるように動作する。
【００２１】
まず、ＯＳ領域又はStateDB領域に障害が発生すれば、Syslogコマンドで、例えば、/var/adm/messageのファイルにwrite errorで、”errorlevel Fatal”のメッセージが書き込まれる。
【００２２】
そこで、図２に示すフローチャートに示すように、C shellコマンドを所定周期で実行させることにより（ステップＳ１１）、Syslogにエラーメッセージが書き込まれておれば（ステップＳ１２）、そのエラーメッセージにどちらかのディスクのＯＳ領域に対するエラーが含まれていれば（ステップＳ１３）、早晩、StateDBに障害が波及するものとし、またStateDB領域に対するエラーが含まれていれば直接に、該当するディスクのStateDB領域を削除するコマンド「metadb -d3 DISK#1」を実行することによって該当するディスクのStateDB領域を削除する（ステップＳ１４）。
【００２３】
これにより、第１の実施の形態のデータベース管理システム及びデータベースシステムの管理方法では、２つの磁気ディスクのStateDBの障害又は障害の予兆を監視し、その障害又は障害の予兆を発見したときに、該当する磁気ディスクの３つのStateDBを削除することにより、両ディスクDISK#1とDISK#2とで３つずつ、合計６つのStateDBが片方のディスクの３つのStateDBに減り、正常なStateDBは3/3、つまり１／２以上となるので、次回のリブート時にシステムは正常に立ち上がり、継続してデータベースのRAID運用が可能となる。
【００２４】
次に、本発明の第２の実施の形態のデータベース管理システム及びデータベースシステムの管理方法について、図１及び図３を用いて説明する。第２の実施の形態の特徴は、Sun社のSolsticeDiskSuiteをデータベース管理ソフトとして利用するデータベース管理システムにおいて、C shellコマンドでSyslogのエラーメッセージを定期的にチェックし、ブートディスク（例えば、DISK#1とする）のブート領域に障害が発生している場合に、自動的にブートディスクをDISK#2に切り替えることにより、次回のリブート時にもシステムが正常に立ち上がれるようにする点にある。
【００２５】
第２の実施の形態においても、ハードウェア構成は、第１の実施の形態と同様に図１に示したものであり、サーバの内蔵ディスクはDISK#1とDISK#2との２台であり、いまDISK#1をブートディスクとして稼働中であるとする。
【００２６】
このような状況で、図３のフローチャートに示す処理によって、C shellコマンドにより、Syslogのエラーチェックを周期的に行う（ステップＳ１１，Ｓ１２）。そして、第１の実施の形態と同様に、ブートディスクDISK#1にエラーが発生している場合（ステップＳ１３でYESに分岐）も非ブートディスクDISK#2にエラーが発生している場合（ステップＳ１３でNOに分岐）も、StateDB領域にエラーが発生し、あるいはエラーが及び予兆があるとき、つまり、ＯＳ領域又はStateDB領域にエラーが発生していることを発見すれば、該当するディスクのStateDB領域の３つのStateDBを強制的に削除し、他の障害がない場合に次回のリブートが正常に行えるようにする（ステップＳ１４，Ｓ１５又はＳ１８，Ｓ１９）。
【００２７】
しかしながら、ブートディスクDISK#1に発生したエラーがBoot領域を含むものである場合には、C shellのコマンドラインに書き加えた、「eeprom boot-device DISK#2」のブートディスクの切り替えコマンドによって自動的にブートディスクをDISK#2に切り替える（ステップＳ１６，Ｓ１７）。これにより、次回のリブート時には、DISK#2がブートディスクとなり、そのBoot領域の情報に基づいてDISK#2からリブートし、システムを立ち上げる。
【００２８】
このようにして、第２の実施の形態のデータベース管理システム及びデータベースシステムの管理方法では、２つの磁気ディスクのブート領域の障害を監視し、現行ブートディスクのブート領域の障害を発見したときに、ブートディスクを別の磁気ディスクに自動的に切り替えて継続してデータベースを運用することができるようになり、従来のようにブートディスクの切換のために管理者がシステムの設置場所に出向いて必要な切替操作を自ら行う手間を軽減することができる。
【００２９】
なお、第１の実施の形態、第２の実施の形態のいずれにおいても、磁気ディスクのいずれかの領域に障害が発生した場合、磁気ディスクの特性上、やがてそのディスクの全体に障害が波及する可能性が高いので、定期点検の際には障害の発生したディスクについては交換することになる。
【００３０】
【発明の効果】
以上のように本発明によれば、２つの磁気ディスクを備え、これらの磁気ディスクのうち正常なStateDBが全体の１／２以下になった場合に次回のリブート時にシステムを立ち上がらなくするソフトウェアでデータベースシステムを運用するにおいて、片側のディスクのStateDBにエラーが発生しても、次回のリブートを可能にして管理者に求められる作業を極力減らすことができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態のハードウェア構成を示すブロック図。
【図２】第１の実施の形態による処理のフローチャート。
【図３】本発明の第２の実施の形態による処理のフローチャート。
【符号の説明】
DISK#1  磁気ディスク
DISK#2  磁気ディスク
DB1〜DB6  StateDB
【図１】
0004141680.tif 000002
【図２】
0004141680.tif 000003
【図３】
0004141680.tif 000004