(57)【要約】【課題】データベースのコールドバック時間を短縮し、またバックアップ退避場所の容量を低減する。【解決手段】本発明に係るデータベースシステムは、第１のデータベースのファイルデータ群を第２のデータベースにバックアップ処理を制御する制御手段とを備え、制御手段が、第２のデータベースのファイル種類毎の最小のデータ格納領域サイズを指定して、第２のデータベースの初期サイズを設定する初期サイズ設定部と、第１のデータベースに存在するファイルデータ群を第２のデータベースにコールドバックアップするコールドバックアップ処理部と、コールドバックアップ実施後に、第２のデータベースのファイルデータ群のデータ格納領域サイズを拡張する格納領域サイズ拡張部とを有する。【選択図】      図１
2016212480.tif 000002
【特許請求の範囲】
【請求項１】
第１のデータベースと、
上記第１のデータベースに物理的に存在するファイルデータ群のバックアップ先である第２のデータベースと、
上記第１のデータベースの上記ファイルデータ群を上記第２のデータベースにバックアップ処理を制御する制御手段と
を備えたデータベースシステムにおいて、
上記制御手段が、
上記ファイルデータ群をバックアップする上記第２のデータベースのファイル種類毎の最小のデータ格納領域サイズを指定して、上記第２のデータベースの初期サイズを設定する初期サイズ設定部と、
上記第１のデータベースに存在する上記ファイルデータ群を上記第２のデータベースにコールドバックアップするコールドバックアップ処理部と、
コールドバックアップ実施後に、上記第２のデータベースの上記ファイルデータ群のデータ格納領域サイズを拡張する格納領域サイズ拡張部と
を有することを特徴とするデータベースシステム。
【請求項２】
上記格納領域サイズ拡張部が、バックアップ元である上記第１のデータベースにおけるファイル種類の格納領域サイズと一致するように、上記第２のデータベースの各ファイル種類の格納領域サイズを拡張することを特徴とする請求項１に記載のデータベースシステム。
【請求項３】
第１のデータベースに物理的に存在するファイルデータ群のバックアップ先である第２のデータベースにバックアップ処理を行うデータベースバックアップシステムにおいて、
上記ファイルデータ群をバックアップする上記第２のデータベースのファイル種類毎の最小のデータ格納領域サイズを指定して、上記第２のデータベースの初期サイズを設定する初期サイズ設定手段と、
上記第１のデータベースに存在する上記ファイルデータ群を上記第２のデータベースにコールドバックアップするコールドバックアップ処理手段と、
コールドバックアップ実施後に、上記第２のデータベースの上記ファイルデータ群のデータ格納領域サイズを拡張する格納領域サイズ拡張手段と
を備えることを特徴とするデータベースバックアップシステム。
【請求項４】
第１のデータベースに物理的に存在するファイルデータ群のバックアップ先である第２のデータベースにバックアップ処理を行うデータベースバックアッププログラムにおいて、
コンピュータ
上記ファイルデータ群をバックアップする上記第２のデータベースのファイル種類毎の最小のデータ格納領域サイズを指定して、上記第２のデータベースの初期サイズを設定する初期サイズ設定手段と、
上記第１のデータベースに存在する上記ファイルデータ群を上記第２のデータベースにコールドバックアップするコールドバックアップ処理手段と、
コールドバックアップ実施後に、上記第２のデータベースの上記ファイルデータ群のデータ格納領域サイズを拡張する格納領域サイズ拡張手段と
を備えることを特徴とするデータベースバックアッププログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースシステム、データベースバックアップシステム及びデータベースバックアッププログラムに関し、例えば、データベースのコールドバックアップ方式でデータベースのバックアップ処理を行うシステムに適用し得るものである。
【背景技術】
【０００２】
図２は、従来のデータベースのコールドバックアップを説明する説明図である。
【０００３】
一般的に、データベースのコールドバックアップとは、データベースの構成のバックアップであり、データベースのサービス、つまりデータベースサーバのＲＤＢＭＳ（Relational  database  management  system）を停止した状態で、データベースファイルシステム（データベース）２−１を構成する物理ファイル一式を、ファイルコピーし、コールドバックアップ退避ファイルシステム２−２に物理ファイル一式のファイルを退避することをいう。
【０００４】
ここで、物理ファイ一式は、図３に例示するように、ＲＤＢＭＳがデータベースを制御するための制御ファイル２１や、データベースのコンフィグレーションを記録したパラメータファイル２２、データベースのデータを格納するデータファイル２３、データ更新時のログを記録するログファイル２４、更新をロールバックするための情報を記録するロールバックファイル２５、一時作業ファイル２６等がある。
【０００５】
ＲＤＢＭＳ１１は、コールドバックアップとは対照的にデータベースのデータ、つまり、データファイルに蓄積されるデータ群をファイルにダンプする機能を有している。例えば、ＯＲＡＣＬＥ（登録商標）データベースの場合は、エクスポート機能が、このデータのダンプ機能に該当する。
【０００６】
データのダンプは、データベースの運用を停止することなく実施可能であり、ファイル出力に要する時間も、コールドバックアップと比べて短時間で済む。
【０００７】
バックアップからのデータベースリカバリは、これら、コールドバックアップとエクスポートされたダンプファイルとにより、完全な復旧が可能となっている。
【０００８】
通常、データベースのコールドバックアップは、図４に例示すように、データベースの本格運用前に取得し（Ｓ５０１）、サービス開始後は、定期的にエクスポートによるダンプを行っている（Ｓ５０２〜Ｓ５０４）。定期的なダンプの実施は、それまでに更新されたデータをバックアップできることから、障害復旧時に有効なものとされている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１１−１８６９０２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、従来のデータベースバックアップシステムは、例えば、大規模データベースの場合、データベース設計時に収容データ量を見積もった上でデータベースを構築する。そのため、そのデータベースのコールドバックアップを取得する場合、バックアップに要する時間は、物理ファイルサイズに比例して、実施時間が非常に長くなるおそれが生じ得る。
【００１１】
特に、データファイルやログファイルは、複数のファイルから構成される場合があり、これもコールドバックアップの時間が長くなる要因の１つにもなっている。
【００１２】
そこで、構築するデータベースの初期サイズを極小化することで、データベースのコールドバック時間を短縮し、また、バックアップ退避場所の容量を低減することができるデータベースシステム、データベースバックアップシステム及びデータベースバックアッププログラムが求められている。
【課題を解決するための手段】
【００１３】
かかる課題を解決するために、第１の本発明に係るデータベースシステムは、第１のデータベースと、第１のデータベースに物理的に存在するファイルデータ群のバックアップ先である第２のデータベースと、第１のデータベースのファイルデータ群を第２のデータベースにバックアップ処理を制御する制御手段とを備えたデータベースシステムにおいて、制御手段が、（１）ファイルデータ群をバックアップする第２のデータベースのファイル種類毎の最小のデータ格納領域サイズを指定して、第２のデータベースの初期サイズを設定する初期サイズ設定部と、（２）第１のデータベースに存在するファイルデータ群を第２のデータベースにコールドバックアップするコールドバックアップ処理部と、（３）コールドバックアップ実施後に、第２のデータベースのファイルデータ群のデータ格納領域サイズを拡張する格納領域サイズ拡張部とを有することを特徴とする。
【００１４】
第２の本発明に係るデータベースシステムは、第１のデータベースに物理的に存在するファイルデータ群のバックアップ先である第２のデータベースにバックアップ処理を行うデータベースバックアップシステムにおいて、（１）ファイルデータ群をバックアップする第２のデータベースのファイル種類毎の最小のデータ格納領域サイズを指定して、第２のデータベースの初期サイズを設定する初期サイズ設定手段と、（２）第１のデータベースに存在するファイルデータ群を第２のデータベースにコールドバックアップするコールドバックアップ処理手段と、（３）コールドバックアップ実施後に、第２のデータベースのファイルデータ群のデータ格納領域サイズを拡張する格納領域サイズ拡張手段とを備えることを特徴とする。
【００１５】
第３の本発明に係るデータベースバックアッププログラムは、第１のデータベースに物理的に存在するファイルデータ群のバックアップ先である第２のデータベースにバックアップ処理を行うデータベースバックアッププログラムにおいて、コンピュータ、（１）ファイルデータ群をバックアップする第２のデータベースのファイル種類毎の最小のデータ格納領域サイズを指定して、第２のデータベースの初期サイズを設定する初期サイズ設定手段と、（２）第１のデータベースに存在するファイルデータ群を第２のデータベースにコールドバックアップするコールドバックアップ処理手段と、（３）コールドバックアップ実施後に、第２のデータベースのファイルデータ群のデータ格納領域サイズを拡張する格納領域サイズ拡張手段とを備えることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、構築するデータベースの初期サイズを極小化することで、データベースのコールドバック時間を短縮し、また、バックアップ退避場所の容量を低減することができる。
【図面の簡単な説明】
【００１７】
【図１】第１の実施形態に係るデータベースシステムの全体構成を示すブロック図である。
【図２】従来のデータベースのコールドバックアップを説明する説明図である。
【図３】物理ファイル一式のファイル群を説明する説明図である。
【図４】データベースのコールドバックアップ及びエクスポートによるダンプを説明する説明図である。
【図５】第１の実施形態に係るデータベース構築サイズの比較を説明する説明図である。
【図６】第１の実施形態に係るＤＢシステムにおけるデータベースバックアップを実施するまでの処理手順を示すフローチャートである。
【図７】第１の実施形態に係るＤＢファイルシステムの運用データベースサイズを示す図である。
【図８】第１の実施形態に係るデータベース構築コマンドの例を説明する説明図である。
【図９】第１の実施形態に係るコールドバックアップで構築されるＤＢファイルシステムのファイルサイズを説明する説明図である。
【図１０】第１の実施形態に係るコールドバックアップコマンドの例を説明する説明図である。
【図１１】第１の実施形態に係るコールドバックアップに係るファイル圧縮コマンドの例を説明する説明図である。
【図１２】第１の実施形態に係るコールドバックアップ後のデータベースのサイズ拡張コマンドの例を説明する説明図である。
【図１３】第１の実施形態に係るコールドバックアップ後のログファイルグループを削除するＳＱＬコマンドの例を説明する説明図である。
【図１４】第１の実施形態に係るコールドバックアップ後のログファイルを削除するＯＳコマンドの例を説明する説明図である。
【発明を実施するための形態】
【００１８】
（Ａ）第１の実施形態
以下では、本発明に係るデータベースシステム、データベースバックアップシステム及びデータベースバックアッププログラムの第１の実施形態を、図面を参照しながら詳細に説明する。
【００１９】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態に係るデータベースシステム（以下、ＤＢシステムとも呼ぶ。）１０の全体構成を示すブロック図である。図１において、ＤＢシステム１０は、データベースサーバ（以下、ＤＢサーバとも呼ぶ。）１、データベースファイルシステム（以下、ＤＢファイルシステムとも呼ぶ。）２（２−１及び２−２）を有する。なお、ＤＢシステム１０におけるＤＢファイルシステム２の数は特に限定されるものではない。
【００２０】
ＤＢサーバ１は、データベースのデータを記憶するためのＤＢファイルシステム２−１及び２−２と接続している。また、ＤＢサーバ１は、図示しないＤＢクライアントにＤＢファイルシステム２に記憶させたデータベースを利用したサービスを提供（トランザクションの処理を実行）するサーバプロセス１１を有する。
【００２１】
サーバプロセス１１は、例えばＲＤＢＭＳ等のデータベースのミドルウェアを用いて構築することができる。この実施形態では、ＤＢファイルシステム２−１及び２−２に、データベースを管理するためのテーブル（表）が格納されており、サーバプロセス１１は、図示しないＤＢクライアントの要求に応じて、テーブル（表）のデータを更新する。
【００２２】
サーバプロセス１１は、ＤＢファイルシステム２−１に格納されている物理ファイル一式を、ＤＢファイルシステム２−２にコールドバック方式でバックアップ処理を行う。なお、ＤＢファイルシステム２−１は、運用データベースであり、ＤＢファイルシステム２−２は、初期データベースである。
【００２３】
ここで、サーバプロセス１１は、物理ファイル一式を、初期データベースであるＤＢファイルシステム２−２にコールドバックアップ方式でバックアップする際、初期データベース（ＤＢファイルシステム２−２）をスモールサイズで構築する。
【００２４】
また、サーバプロセス１１は、コールドバックアップ実施後、データベース設計時の見積りサイズ（すなわち、運用条件のデータベースサイズ）に拡張する。これにより、バックアップ作業時間を短縮することができ、且つ、バックアップファイル容量の低減を可能とするものである。
【００２５】
初期データベースであるＤＢファイルシステム２−２をスモールサイズで構築する点については、データベース構築時、サーバプロセス１１がデータベース作成コマンドにて、データベースを定義する上でのデータ格納領域を、最低限まで小さくしたサイズを指定することで実現可能である。
【００２６】
図５は、第１の実施形態に係るデータベース構築サイズの比較を説明する説明図である。例えば、図５に示すように、構築するＤＢファイルシステム２−１において、データファイル２３Ａのサイズが１０Ｇｂｙｔｅ必要な場合（この設計時見積りの算出値）でも、本格運用開始前のデータベースの使用率は、極小なはずである（または、データベース構築直後は、データ件数は０件であると言える）。そのため、初期データベースのＤＢファイルシステム２−２のデータファイル２３Ｂのデータ格納領域サイズは、２５６Ｍｂｙｔｅ、または、それ以下のサイズでも作成可能といえる。
【００２７】
また、ログファイル２４Ａ及び２４Ｂ、ロールバックファイル２５Ａ及び２５Ｂ、一時作業ファイル２６Ａ及び２６Ｂについても、データファイル２３Ａ及び２３Ｂと同様に、ＤＢファイルシステム２−２の初期データベースのデータ格納領域サイズを小さく作成することができる。
【００２８】
さらに、コールドバックアップ実施後は、バックアップファイルのサイズを低減するため、ファイルの圧縮処理を行うのが一般的である。これについても、初期データベースのサイズを小さくし、また、登録される物理ファイル一式のデータがほとんど無い状態でのファイル圧縮は、圧縮効率を高め、バックアップ保存するファイルサイズを極力小さくすることが可能になる。
【００２９】
なお、例えばＯＲＡＣＬＥ（登録商標）データベースの場合、制御ファイル２１Ａ及び２１Ｂ、パラメータファイル２２Ａ及び２２Ｂについては、データベース作成時にサイズを指定するものでなく、また、ファイルサイズ自体小さいものなので、コールドバックアップの実施時間全体に含む割合は小さいもとといえる。
【００３０】
ＤＢファイルシステム２−１のコールドバックアップは、図５に示した通り、データベース構築後、サービス本格運用前にＤＢファイルシステム２−２が物理ファイル一式を取得する。コールドバックアップ方式による物理ファイル一式の取得後は、ＤＢシステムの要件にあわせたサイズに拡張する。このサイズ拡張についても、サービスプロセス１１が提供するコマンドにより実行することで可能である。
【００３１】
第１の実施形態のコールドバックアップ方式の手順によれば、データベースのコールドバックアップ方式の実施に係る所要時間を極力短くことができ、また、バックアップ保存するファイルサイズを極力小さくすることができる。
【００３２】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態に係るデータベースバックアップ処理の動作を、図面を参照しながら詳細に説明する。
【００３３】
図６は、第１の実施形態に係るＤＢシステム１０におけるデータベースバックアップを実施するまでの処理手順を示すフローチャートである。
【００３４】
まず、ＤＢシステム１０の要件として必要なサイズ条件を満たすＤＢファイルシステム２−１（運用データベース）が、図７に示す運用データベースサイズであるとする。このとき、サービスプロセス１１は、図８に示すＳＱＬコマンドにより、初期データベースであるＤＢファイルシステム２−２を構築する（Ｓ１０１）。この処理をデータベース構築段階とも呼ぶ。
【００３５】
例えば、図７において、データファイル２３Ａのサイズが１０ＧＢｙｔｅ、ログファイル２４Ａのサイズが１０Ｇｂｙｔｅ、ロールバックファイル２５Ａのサイズが１０Ｇｂｙｔｅ、一時作業ファイル２６Ａのサイズ１０Ｇｂｙｔｅであるとする。
【００３６】
図８に示すＳＱＬコマンドは、ＤＢファイルシステム２−２のデータベース構築コマンドであり、データファイルサイズの指定（サイズ：２５６Ｍｂｙｔｅ）、ログファイルサイズの指定（サイズ：２５６Ｍｂｙｔｅ）、ロールバックファイルサイズの指定（サイズ：２５６Ｍｂｙｔｅ）、一時作業ファイルの指定（サイズ：２５６Ｍｂｙｔｅ）を含むものである。このように、サービスプロセス１１は、データファイル２３Ｂ、ログファイルサイズ２４Ｂ、ロールバックファイル２５Ｂ、一時作業ファイル２５Ｂの初期サイズ等を指定することで、初期サイズのデータベースを構築する。
【００３７】
なお、実際に完全なデータベースを構築するまでには、このコマンドの他にも実行すべきものがあるが、ここでは省略する。
【００３８】
次に、初期サイズのデータベースが構築されると、コールドバックアップの対象となる図９に示すファイルが生成されるので、これらファイルをコールドバックアップする。
【００３９】
つまり、サービスプロセス１１は、データベースを停止後（Ｓ１０２）、ファイルをコピーするコマンドを実行する。これにより、コールドバックアップが実施する（Ｓ１０３）。例えば、ＯＳ環境がＬｉｎｕｘ(登録商標)である場合には、ｃｐコマンドを実行すればよい。また、ファイル圧縮を実施するなら、ｇｚｉｐコマンドを実行すればよい。
【００４０】
ＤＢファイルシステム２−２は、データファイルを、「／ｂａｃｋｕｐ」ディレクトリにバックアップファイルとしてコピーし、また、バックアップファイルを圧縮するには、図１０に示すＯＳコマンド「ｃｐ／ｖａｒ／ｔｅｓｔ／ｄａｔａ／ｓｙｓｔｅｍ０１．ｄｂｆ／ｂａｃｋｕｐ／」、「ｇｚｉｐ／ｂａｃｋｕｐ／ｔｅｓｔ／ｓｙｓｔｅｍ０１．ｄｂｆ」となる。
【００４１】
ｄｂファイルシステム２−２は、コールドバックアップの対象となるファイルに対して、順番にコピーと圧縮を繰り返せば、コールドバックアップが完了する。
【００４２】
このとき、データベースを停止する理由は、ファイルのコピー中に、データベースへのアクセスが発生して、ファイルの内容が書き換えられることで、データベースの状態を管理する情報が、バックアップされたファイルの状態を不一致になることを防ぐためである。
【００４３】
一連のコールドバックアップ終了後、ＤＢファイルシステム２−２のデータベースを起動し（Ｓ１０４）、サービスプロセス１１は、ＤＢファイルシステム２−２を運用データベースに向けたサイズに拡張する（Ｓ１０５）。
【００４４】
ＤＢファイルシステム２−２のデータベースのサイズ拡張は、サービスプロセス１１が、図１１に示すＳＱＬコマンドを命令することにより実行する。図１１に示すように、サービスプロセス１１のＳＱＬコマンドは、例えば、データファイル２３Ｂ、ロールバックファイル２４Ｂ及び一時作業ファイル２６Ｂのデータ格納領域サイズを１０Ｇｂｙｔｅに拡張する。
【００４５】
なお、ログファイル２４Ｂのサイズ拡張については、上記コマンドとは異なる。具体的には、初期データベース構築時に作成したログファイルとは別のログファイルを追加し、初期データベース構築時のログファイルを削除する手順となる。
【００４６】
実施例としては、まず、新たなログファイルグループを追加するため、サービスプロセス１１は、図１２に示すＳＱＬコマンド「ＡＬＴＥＲ  ＤＡＴＡＢＡＳＥ  ＡＤＤ  ＬＯＧＦＩＬＥ  ＧＲＯＵＰ２’／ｖａｒ／ｔｅｓｔ／ｒｅｄｏ／ｒｅｄｏＡ０２０１．ｌｏｇ’，’／ｕ０１／ｏｒａｓｉｄ／ｒｅｄｏ／ｒｅｄｏＡ０２０２．ｌｏｇ’）ＳＩＺＥ  １０２４０Ｍ；」を実行する。
【００４７】
次に、サービスプロセス１１は、ログファイルグループ１を削除するため、図１３に示すＳＱＬコマンド「ＡＬＴＥＲ  ＤＡＴＡＢＡＳＥ  ＤＲＯＰ  ＬＯＧＦＩＬＥ  ＧＲＯＵＰ１；」を実行する。
【００４８】
そして、最後にログファイルを削除するため、サービスプロセス１１は、図１４に示すＯＳコマンド「ｒｍ／ｖａｒ／ｔｅｓｔ／ｒｅｄｏ／ｒｅｄｏＡ０１０１．ｌｏｇ」、「ｒｍ／ｖａｒ／ｔｅｓｔ／ｒｅｄｏ／ｒｅｄｏＡ０１０１．ｌｏｇ」を実行する。
【００４９】
なお、実際のログファイルグループの追加、削除については、状態の確認や、ログ切替作業等が必要となるが、これは第１の実施形態の処理に関係しない部分であるため、ここでの詳細な説明は省略する。
【００５０】
ここで、ログファイル（ＧＲＯＵＰ２）は新たなファイルとして生成されるため、コールドバックアップされたものとは異なることになるが、これについては、仮に、コールドバックアップのファイルを使ってデータベースを復旧させた場合は、復旧後に、上記手順によって、ファイルを再生成すればよいことを意味している。
【００５１】
もし、最初からログファイルを１０Ｇｂｙｔｅで作成した場合は、コールドバックアップ実施時も、復旧時も１０Ｇｂｙｔｅのログファイルをコピー、コピーバックが必要となってしまうが、本方式であれば、復旧時のみ、新たなログファイル（１０ＧｂｙｔｅのＧＲＯＵＰ２のファイル）の作成時間のみで済むことになる。
【００５２】
以上、初期データベース構築から、コールドバックアップを実施し、運用データベースへのサイズ拡張の手順を述べた。
【００５３】
この手順により、当初の要件通りのデータベースが完成したことになり、実運用、つまり、サービスを開始することができる。
【００５４】
（Ａ−３）第１の実施形態の効果
以上のように、第１の実施例によれば、データベース構築時のサイズを最小単位とすることで、データベースのコールドバックアップの実施時間を短縮することができる。
【００５５】
（Ｂ）他の実施形態
第１の実施形態では、本発明の方式がRDBMSを構成するサーバプロセス１１内に実装されているが、例えば、市販ミドルウェアのRDBMSとは別のプロセスとして本方式を実装し、RDBMSが提供するコマンドを制御してもよい。
【００５６】
例えば、ORACLEデータベースの場合、本方式によるデータベース構築において必要となるコマンド一式は既に実装された機能であり、そのコマンドの実行条件、実行契機、パラメータが、本方式のポイントとなるからである。
【符号の説明】
【００５７】
１０…データベースシステム、１…データベースサーバ、１１…サービスプロセス、２−１…データベースファイルシステム、２−２…データベースシステム。
【図１】
2016212480.tif 000003
【図２】
2016212480.tif 000004
【図３】
2016212480.tif 000005
【図４】
2016212480.tif 000006
【図５】
2016212480.tif 000007
【図６】
2016212480.tif 000008
【図７】
2016212480.tif 000009
【図８】
2016212480.tif 000010
【図９】
2016212480.tif 000011
【図１０】
2016212480.tif 000012
【図１１】
2016212480.tif 000013
【図１２】
2016212480.tif 000014
【図１３】
2016212480.tif 000015
【図１４】
2016212480.tif 000016