JP2021533495A

JP2021533495A - データリカバリー方法、装置、サーバ及びコンピュータ・プログラム

Info

Publication number: JP2021533495A
Application number: JP2021506468A
Authority: JP
Inventors: リ，ハイシアン
Original assignee: テンセント・テクノロジー・（シェンジェン）・カンパニー・リミテッド
Priority date: 2018-11-30
Filing date: 2019-11-29
Publication date: 2021-12-02
Anticipated expiration: 2039-11-29
Also published as: WO2020108604A1; EP3822793A4; US20210165716A1; US11531594B2; CN110209527A; CN110209527B; JP7108782B2; EP3822793A1

Abstract

本開示は、データリカバリー方法、装置、サーバ及び記憶媒体を提供し、データベース技術の分野に属する。前記方法は、バックアップデータパケットのバックアップタイプを認識するステップと、認識したバックアップタイプがハイブリッドバックアップである場合に、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うステップと、前記物理バックアップのデータに基づいてデータリカバリーを完了した後に、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うステップとを含み、前記ハイブリッドバックアップとは、バックアッププロセスに物理バックアップと論理バックアップとを含むことを指す。

Description

本出願は２０１８年１１月３０日に中国専利局に提出した、出願番号が２０１８１１４５７１９６１であり、発明の名称が「データリカバリー方法、装置、サーバ及び記憶媒体」である中国特許出願の優先権を主張し、その全ての内容は援用により本出願に結合される。

本出願は、データベース技術の分野に関し、特に、データリカバリー方法、装置、サーバ及びコンピュータ読み取り可能な記憶媒体に関する。

データ処理システムにおいて、特に、ＯＬＡＰ(ＯｎｌｉｎｅＡｎａｌｙｔｉｃａｌＰｒｏｃｅｓｓｉｎｇ、オンライン分析処理)システム、データウェアハウス、ビッグデータ分析などのシナリオにおいて、データベースに大量のデータを保存することに係る。サービスは常に更新される可能性があるため、一つのデータ項目には複数の状態に対応するバージョンデータを論理的に含む。このように、一つのデータ項目の全状態（現在状態、遷移状態及び履歴状態）のデータが保存されることで、システムが履歴データを追跡し、データの価値（いずれのデータも価値があるため、履歴状態のデータが紛失不可）を十分に発掘することに寄与する。ただし、データベースは、バックアップデータに基づくリカバリープロセスにも係る可能性があり、前記複数の状態データを含むバックアップデータ間の関係が複雑であるため、全状態データをリカバリーすることは大きな挑戦である。

本出願の各実施例によれば、データリカバリー方法、装置、サーバ及び記憶媒体を提供する。

データリカバリー方法であって、サーバによって実行され、
バックアップデータパケットのバックアップタイプを認識するステップと、
認識したバックアップタイプがハイブリッドバックアップである場合に、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うステップと、
前記物理バックアップのデータに基づいてデータリカバリーを完了した後に、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うステップとを含み、
前記ハイブリッドバックアップとは、バックアッププロセスに物理バックアップと論理バックアップとを含むことを指す。

好ましく、前記バックアップデータパケットのバックアップタイプを認識するステップは、
前記バックアップデータパケットにおけるファイル名に基づいて、前記ファイル名に対応するバックアップタイプを取得するサブステップと、又は、
前記バックアップデータパケットに担持されているタイプ識別子に基づいて、前記タイプ識別子に対応するバックアップタイプを取得するサブステップとを含む。

データリカバリー装置であって、
バックアップデータパケットのバックアップタイプを認識するための認識モジュールと、
認識したバックアップタイプがハイブリッドバックアップである場合に、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うデータリカバリーモジュールとを含み、
前記ハイブリッドバックアップとは、バックアッププロセスに物理バックアップと論理バックアップとを含むことを指し、
前記データリカバリーモジュールは、さらに、前記物理バックアップのデータに基づいてデータリカバリーを完了した後に、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うために用いられる。

サーバであって、プロセッサー及びメモリを含み、当該メモリに少なくとも一つのコマンドが記憶され、前記したようなデータリカバリー方法による操作が実現されるように当該少なくとも一つのコマンドが当該プロセッサーによってロードされて実行される。

コンピュータ読み取り可能な記憶媒体であって、当該記憶媒体に少なくとも一つのコマンドが記憶され、前記したようなデータリカバリー方法による操作が実現されるように当該少なくとも一つのコマンドが当該プロセッサーによってロードされて実行される。

本出願の一つ又は複数の実施例の詳細は、以下の添付の図面及び説明において提供される。本出願の他の特徴、目的、及び利点は、明細書、添付図面、及び特許請求の範囲の記載により明瞭にする。

本出願の実施例に係るデータリカバリー方法の応用環境の模式図である。本出願の実施例に係るデータリカバリー方法のフローチャートである。本出願の実施例に係るページ比較図である。本出願の実施例に係るデータリカバリー装置の構成模式図である。本出願の実施例に係るサーバの構成模式図である。

本出願の目的、技術案及び利点をより明確にするために、以下は、添付の図面に基づいて、本出願の実施形態をより詳細に説明する。

本出願の実施例に係るデータベースには、データ項目を記憶するための複数のデータテーブルが記憶され、データ項目は１つ又は複数のバージョンを有してもよい。なお、当該データベースは、ＭＶＣＣ(Ｍｕｌｔｉ-ＶｅｒｓｉｏｎＣｏｎｃｕｒｒｅｎｃｙＣｏｎｔｒｏｌ、マルチバージョン同時並行性制御)に基づく任意のタイプのデータベースであってもよい。本出願の実施例において、当該データベースのタイプは具体的に限定していない。なお、前記のデータベースにおけるデータは、状態属性に応じて、現在状態、遷移状態及び履歴状態の３つの状態を含み、当該３つの状態をまとめて「データの全状態」と称し、全状態データと略称し、全状態データにおける異なる状態属性のそれぞれはデータのライフサイクルの軌跡における状態を表記することに使用できる。

現在状態(ＣｕｒｒｅｎｔＳｔａｔｅ)は、データ項目の最新バージョンのデータであって、現段階にあるデータである。現段階にあるデータの状態は、現在状態と呼ばれる。

遷移状態(ＴｒａｎｓｉｔｉｏｎａｌＳｔａｔｅ)は、データ項目の最新バージョンでもなければ、履歴状態バージョンでもなく、現在状態から履歴状態への遷移過程にあり、遷移状態にあるデータは、半減データと呼ばれる。

履歴状態(Ｈｉｓｔｏｒｉｃａｌｓｔａｔｅ)は、履歴におけるデータ項目の１つの状態であり、その値は現在値ではなく、古い値である。履歴段階にあるデータの状態は、履歴状態と呼ばれる。１つのデータ項目の履歴状態は複数を有してもよく、データの状態の遷移過程が反映される。履歴状態にあるデータは、読み取りのみが可能であり、変更又は削除は許容されない。

なお、データは、ＭＶＣＣメカニズムにおいて、前記３つの状態が存在し、非ＭＶＣＣメカニズムにおいて、履歴状態及び現在状態のみ存在してもよい。ＭＶＣＣ又はロック同時アクセス制御メカニズムにおいて、トランザクションが提出されたデータの新値は現在状態にある。ＭＶＣＣメカニズムを例として、現在アクティブなトランザクションリストにおける最小のトランザクションの前のトランザクションによって生成されたデータは、その状態が履歴状態にある。ロック同時アクセス制御メカニズムにおいては、トランザクションが提出されると、その提出前のデータの値が履歴状態の値になり、即ち、データ項目の古い値が履歴状態にある。読み取られたバージョンにおいてまだアクティブなトランザクション(最新の関連トランザクションではない)が使用されるが、最新の関連トランザクションはデータ項目の値が変更され、その最新の値が既に現在状態にあり、読み取られた値が現在状態に対して履歴状態にある。よって、そのデータ状態は現在状態と履歴状態との間にあるため、遷移状態と称される。

例えば、ＭＶＣＣメカニズムにおいて、ＵｓｅｒテーブルのＡアカウントの残高は、１０元から２０元にチャージされ、そして、１５元が消費されて５元になる。この場合、金融機関Ｂは、データを読み取ってトランザクションをチェックすることを常に行っている。その後、Ａはさらに２０元をチャージして２５元になる。この２５元は、現在状態データであり、Ｂにより読み取られた５元は遷移状態にあり、残りの２つの値である２０、１０のそれぞれは、過去に存在していた状態であり、履歴状態データである。

好ましくは、本実施例において、前記データリカバリー方法は、図１に示される複数のサーバ１０１を含むハードウェア環境に適用され得る。図１に示すように、複数のサーバ１０１はネットワークを介して接続したり、データが分離されたりすることができる。前記ネットワークは、広域ネットワーク、メトロポリタンエリアネットワーク又はローカルエリアネットワークを含むが、これらに限定されない。本出願の実施例に係るデータリカバリー方法は、いずれかのサーバ１０１又は複数のサーバ１０１によって実行され得る。サーバ１０１においては、データベースシステムが動作することができる。これにより、例えば、データ記憶、データ照合などのデータサービスを提供することができる。当該データベースシステムは、サーバにおいて動作させられるデータベースエンジンにより作動することができる。

本出願の実施例にかかるデータリカバリー方法のフローチャートは、図２に示すように、当該実施例は、具体的に以下のステップを含む。

２０１において、バックアップデータパケットにおけるファイル名に応じて、バックアップタイプを認識する。

バックアップタイプによって、生成されたバックアップデータパケットにおけるファイルのファイル名が異なるため、バックアップデータパケットにおけるファイル名に基づいて当該バックアップデータパケットのバックアップタイプを認識することができ、その後、当該バックアップタイプに基づいて、異なったバックアップタイプにより、対応するデータリカバリーフローを行うことができる。他の実施形態においては、バックアップタイプの認識は、バックアップデータパケットに含まれるタイプ識別子を認識することにより行われる。即ち、当該バックアップデータパケットに担持されているタイプ識別子により、対応するバックアップタイプを取得する。当該タイプ識別子は、バックアップデータパケットにおける１つの指定ファイルに含まれてもよく、バックアップデータパケットのパケット名に担持されてもよい。本出願の実施例において、それを具体的に限定しない。なお、前記のタイプ識別子は、例えば、番号、文字列などのバックアップタイプを示すためのフィールドであってもよい。

ファイル名に基づくタイプ認識の例として、異なったバックアップタイプのバックアッププロセスによってそれぞれ得られたバックアップデータパケットに含まれるデータやファイル名が異なった。その例示、以下通りである。

物理バックアップにより得られたバックアップデータパケットには、現在状態データのみがあり、履歴状態データ又は遷移状態データがない。物理的にバックアップにより得られたバックアップデータパケットにおけるファイルのファイル名は、物理的バックアップにより得られたバックアップデータパケットにおけるファイルのファイル名には、物理的バックアップを示すためのフィールドが担持され得る。例えば、ファイル名は、ＰｈＭｅｔａ_０００００００１、ＰｈＤａｔａ_０００００００１、Ｌｏｇ_０００００００１などであってもよい。

論理バックアップにより得られたバックアップデータパケットは、現在状態データ、履歴状態データ及び遷移状態データを含む全状態データを含んでも良い。論理バックアップにより得られたバックアップデータパケットにおけるファイルのファイル名には、論理バックアップを示すためのフィールドが担持され得る。例えば、ファイル名は、ＬｏＭｅｔａ_０００００００１、ＬｏＤａｔａ_０００００００１、ＨＭｅｔａ_０００００００１、ＨＤａｔａ_０００００００１などであってもよい。

ハイブリッドバックアップは、論理バックアップ及び物理バックアップの混合によって得られたバックアップデータパケットであり、全状態データ（即ち、現在の状態データ、履歴状態データ及び遷移状態データを含む）であっても良い。ハイブリッドバックアップによって得られたバックアップデータパケットにおけるファイルのファイル名には、ハイブリッドバックアップを示すためのフィールドが担持され得、例えば、ファイル名は、Ｍｅｔａ_０００００００１、Ｄａｔａ_０００００００１、Ｌｏｇ_０００００００１、ＨＭｅｔａ_０００００００１、ＨＤａｔａ_０００００００１などであってもよい。

２０２において、認識されたバックアップタイプが論理バックアップである場合には、当該バックアップデータパケットのメタ情報ファイルに基づいて、ターゲットライブラリにおいてテーブルを作成するようにデータリカバリーを行う。

論理バックアップの場合には、バックアップデータパケットにおけるデータは、現在状態時点の値、履歴状態時点の値及び全状態時間帯の値であってもよく、これらの値のそれぞれは、異なったスナップショットのバックアッププロセスにより得られたものである。

第１のリカバリープロセスでは、バックアップデータパケットはノーマルトランザクションスナップショットに基づいて論理バックアップを行うことで得られたものであり、このようなタイプのバックアップのリカバリーについては、そのリカバリープロセスは以下のことを含む。即ち、バックアップデータパケットのメタ情報ファイルから、テーブルファイルのメタ情報を読み取り、当該テーブルファイルのメタ情報に基づいてターゲットライブラリにテーブルを作成し、ターゲットライブラリに同名のテーブルが存在する場合、リカバリーに失敗し、その後、挿入操作(例えば、ＩＮＳＥＲＴ操作)を実行してデータリカバリーを行う。なお、このようなデータリカバリーは、「運行状態論理リカバリー」のみをサポートする。

第２のリカバリープロセスでは、バックアップデータパケットは、履歴トランザクションスナップショットに基づいて論理バックアップを行うことで得られたものであり、バックアップデータパケットに履歴状態及び遷移状態のバックアップデータを含む。このようなバックアップのリカバリーについては、リカバリーのプロセスは以下のことを含む。即ち、バックアップデータパケットのメタ情報ファイルから、テーブルファイルのメタ情報を読み取り、ターゲットライブラリに同名のテーブルが存在しない場合、当該テーブルファイルのメタ情報に基づいてターゲットライブラリにおいてテーブルを作成し、その後、挿入操作(例えば、ＩＮＳＥＲＴ操作)を実行してデータリカバリーを行う。一方、ターゲットライブラリに同名のテーブルが存在する場合、テーブルの作成を行わず、データリカバリーのみを行う。好ましい実施形態において、当該ターゲットライブラリにおいて当該同名のテーブルにリカバリーすべきデータと同じデータが存在する場合、リカバリーに失敗し、当該ターゲットライブラリにおいて当該同名のテーブルにリカバリーすべきデータと同じデータが存在しない場合、当該リカバリーすべきデータに基づいてリカバリーする(例えば、リカバリーを強制的に実行する)。なお、主キーインデックスにより当該ターゲットライブラリにおいて同名のテーブルにリカバリーすべきデータと同じデータが存在するか否かをチェックし、リカバリーすべきデータの主キーインデックスと同じ主キーインデックスが存在する場合、リカバリーすべきデータと同じデータが存在していることを意味し、リカバリーに失敗した。一方、ターゲットライブラリにおいて同名のテーブルに当該主キーインデックスが存在しない場合、当該リカバリーすべきデータに基づいてリカバリーする。なお、このようなデータリカバリーは、「運行状態論理リカバリー」のみをサポートする。さらに、権限を区分するデータベースシステムにおいて、当該データリカバリーは、スーパーユーザー(ＳｕｐｅｒＵｓｅｒ、最も権限のあるローカルユーザー)に限って行われる。

第３のリカバリープロセスであって、バックアップデータパケットは、履歴トランザクションスナップショット及びノーマルトランザクションスナップショットに基づいて論理バックアップを行うことで得られたものであり、バックアップデータパケットには現在状態、履歴状態及び遷移状態のバックアップデータを含む。このようなバックアップのリカバリーは、そのリカバリープロセスに前記の第１のリカバリープロセスと第２のリカバリープロセスを含むことができ、即ち、当該ノーマルトランザクションスナップショット及び当該履歴トランザクションスナップショットに対応するデータリカバリー方式を組み合わせてデータリカバリーを行い、データリカバリーを行う場合、リカバリー効率を向上するために、同名のテーブルのチェックを繰り返す必要がなく、同名のテーブルを１回チェックするだけで済む。

前記の当該ノーマルトランザクションスナップショット及び当該履歴トランザクションスナップショットに対応するデータリカバリー方式を組み合わせてデータリカバリーを行うことは、
バックアップデータパケットのメタ情報ファイルから、テーブルファイルのメタ情報を読み取り、テーブルファイルのメタ情報に基づいてターゲットライブラリにおいてテーブルを作成し、テーブルに対して挿入操作を実行して、バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うこと、又は、
バックアップデータパケットのメタ情報ファイルから、テーブルファイルのメタ情報を読み取り、ターゲットライブラリに同名のテーブルが存在しない場合、テーブルファイルのメタ情報に基づいてターゲットライブラリにおいてテーブルを作成し、挿入操作を実行してデータリカバリーを行い、ターゲットライブラリに同名のテーブルが存在する場合、同名のテーブル挿入操作を実行してデータリカバリーを行うことを含む。

なお、前記プロセスにおいて、テーブルの作成はオプションのステップであり、リカバリーコマンドにおいてパラメータにてテーブルの作成ステップを行うか否かを指定可能、例えば、ＲＥＣＯＶＥＲＹコマンドにおいて、パラメータ「ＣＲＥＡＴＥＴＡＢＬＥ＝Ｙ/Ｎ」により指定し、Ｙは、作成を示し、Ｎは、非作成を示す。

単に論理バックアップによって得られたバックアップデータパケットは、前記の技術的プロセスを利用してリカバリーを個別に行うことができる。ただし、ハイブリッドバックアップのバックアップデータパケットには、論理バックアップを利用してバックアップしたデータも含み、このようなデータのリカバリーは、潜んでいる論理データリカバリーであり、そのリカバリー原理は同様である。

好ましく、データリカバリーの効率を向上するために、複数のテーブルに対してデータリカバリーを行う場合に、マルチスレッドで並行して行ってもよく、具体的に、バックアップデータパケットにおけるファイルを複数のスレッドで並行して読み取り、読み取られたリカバリーコマンドを並行して実行する。例えば、データファイルＬｏＤａｔａ_０００００００１、ＬｏＤａｔａ_０００００００２などを並行して読み取り、各データファイル内のＳＱＬコマンドを並行して実行してもよい。

好ましく、データリカバリーの効率を向上するために、履歴状態データについて、リカバリーを行う過程において、サーバはトランザクションに係る様々の一致性チェック操作を禁止する一方、直接にデータを履歴テーブルのデータページに格納する。

一例では、論理バックアップのリカバリーコマンドは１つのＳＱＬステートメントであってもよく、１つのＣＬＩフォーマットのコマンドであってもよい。例えば、‘/ｕｓｒ/ｂａｋ/ｍｙ_ｆｉｒｓｔ_ｂａｃｋｕｐ_０２’バックアップデータパケットから‘/ｄａｔａ/ｍｙ_ｄａｔａ_０２’にデータをリカバリーする場合に、以下のコマンドを利用することができる。

即ち、ＲＥＣＯＶＥＲＹＦＲＯＭ‘/ｕｓｒ/ｂａｋ/ｍｙ_ｆｉｒｓｔ_ｂａｃｋｕｐ_０２’ＴＯ‘/ｄａｔａ/ｍｙ_ｄａｔａ_０２’；//物理バックアップのリカバリーは、ＣＬＩのＲＥＣＯＶＥＲＹコマンドを使用して空きディレクトリへリカバリーする。

ＲＥＣＯＶＥＲＹＦＲＯＭ‘/ｕｓｒ/ｂａｋ/ｍｙ_ｆｉｒｓｔ_ｂａｃｋｕｐ_０２’ＩＮＣＬＵＤＥｍｙ_ｔａｂｌｅ０１,ｍｙ_ｔａｂｌｅ０２；//論理バックアップのリカバリーは、１つの運行中のシステムからリカバリーする。

２０３において、サーバはＣＨＥＣＫＰＯＩＮＴ操作を実行して、リカバリーされたデータをメモリからフラッシュし、データリカバリー操作を完了する。

なお、バックアップデータパケットが単に論理方式により得られたものであれば、データベースエンジンの運行中にリカバリーを行うことを許可することができ、「運行状態論理リカバリー」と称され、即ち、データベースエンジンの運行中に前記論理バックアップのリカバリーを行うことができ、リカバリーが完了した後に、データベースエンジンを起動する必要がないが、運行速度を向上するためにデータベースエンジンを再起動してもよいことが言うまでもない。つまり、サーバは、論理バックアップに対してリカバリー操作を行うことで得られたターゲットライブラリに基づいて、データベースシステムを再起動してデータサービスを提供することができ、本出願の実施例では、それを限定しない。一方、物理バックアップ方式のバックアップは、通常、データベースエンジンが非運行状態にある場合にのみ実行され、「非運行状態物理リカバリー」と称される。また、ハイブリッド方式に基づくバックアップデータは、運行状態においてリカバリーされたり、セミオフラインの場合にリカバリーされたりしてもよく。セミオフラインの場合とは、物理バックアップのデータがオフライン状態においてリカバリーされ済み、その後、サーバが起動して、ログ、及び論理バックアップにより得られたデータを引き続きリカバリーすることを指す。

２０４において、認識したバックアップタイプが物理バックアップである場合に、当該バックアップデータパケットを新しいデータディレクトリにリカバリーする。

一例において、物理バックアップのリカバリーコマンドは、１つのＣＬＩ(ｃｏｍｍａｎｄ-ｌｉｎｅｉｎｔｅｒｆａｃｅ、コマンドラインインターフェース)フォーマットのコマンドであってもよい。

２０５において、データがリカバリーされると、サーバは、バックアップデータパケットにおけるログファイルを実行する。

バックアップされた現在状態データは、データの一致性を保証するために、さらに、ログファイルをバックアップする必要があり、即ち、データをリカバリーする場合に、ログファイルに基づいてリカバリーする必要がある。一つの好ましい実施形態において、当該ログファイルを実行するプロセスは、バックアップ時点のデータの一致性を実現するように、ＡＲＩＥＳアルゴリズム原理を使用して、ログファイル(例えばＲＥＤＯログ)に基づくリカバリー作業を行ってもよい。

２０６において、サーバはログファイルの実行を完了した後に、ＣＨＥＣＫＰＯＩＮＴ操作を実行して、リカバリーされたデータをメモリからフラッシュし、データリカバリー操作を完了する。

２０７において、サーバは、新しいデータディレクトリに基づいてデータベースエンジンを起動して、データサービスの提供を開始し、終了する。

前記のステップ２０４ないし２０７までのリカバリープロセスは、バックアップデータパケットを空きデータディレクトリにリカバリーし、サーバは、物理バックアップをリカバリー操作を行うことで得られた新しいデータディレクトリに基づいてデータベースエンジンを起動し、データサービスの提供を開始することができる。

２０８において、認識したバックアップタイプがハイブリッドバックアップである場合に、サーバは当該バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行う。

データリカバリーを開始する前に、サーバは、ターゲットディレクトリが空きであるか否かをチェックし、空きではない場合、エラーを報告して終了する。好ましく、幾つかのデータベースシステムは、さらに、バックアップするときの環境にリカバリーするように、先にバックアップデータパケットにおける制御ファイルに基づいてデータリカバリーを行う必要がある。例えば、ＡＲＩＥＳアルゴリズム原理を使用して、制御ファイルなどの必要なデータのリカバリーを行ってもよい。

物理バックアップのデータは、ファイルコピー方式が利用される。このような物理バックアップのデータは、バックアップの際にブロックコピー方式で行われたため、バックアップされると、独立したデータファイルが形成されている。従って、リカバリーを行う場合、ファイルコピー方式を直接利用することにより実現される。具体的に、当該ファイルコピーに基づくデータリカバリープロセスは、ファイルコピー方式により、当該バックアップデータパケットにおける物理バックアップのデータを、ファイル名及びテーブル名に従ってターゲットディレクトリにおける対応する位置にコピーすることを含む。例えば、１つのデータファイルが、元のシステムにおけるサブディレクトリｍｙｄａｔａにある場合、ターゲットディレクトリにおいて対応するサブディレクトリｍｙｄａｔａを作成し、そして、対応するデータファイルをこのサブディレクトリにコピーする必要があり、ファイル名はＭｅｔａ系、即ち、バックアップするとき元のシステムにおける名称で命名されるため、リカバリーするときにデータの一致性が保証される。

データリカバリーの効率を向上するために、バックアップデータパケットにおける物理バックアップのデータに対して、並行方式により、複数のデータファイルを同時に指定のリカバリーターゲットディレクトリにおける対応する位置にコピーする。このような物理バックアップのデータは、バックアップされると、それぞれ独立したデータファイルが形成されるため、リカバリーするときに、直接に並行コピーの方式によりデータリカバリーを行うことができる。

２０９において、データがリカバリーされると、サーバはバックアップデータパケットにおけるログファイルを実行する。

２１０において、サーバはログファイルの実行を完了した後に、ＣＨＥＣＫＰＯＩＮＴ操作を実行し、リカバリーされたデータをメモリからフラッシュし、データリカバリー操作を完了する。

２１１において、サーバは、物理バックアップに対してリカバリー操作を行うことで得られたターゲットディレクトリに基づいてデータベースエンジンを起動し、データサービスの提供を開始する。

なお、サーバがデータベースエンジンを起動している過程に、「システム故障のリカバリー」プロセスの実行を禁止することができる。

前記ステップ２０８〜２１１における物理バックアップのリカバリープロセスは、さらに、前記の実施例に係る物理バックアップのリカバリーに関して記載された技術内容を参考することができ、ここで、重複な説明を省略する。

２１２において、サーバは、ターゲットディレクトリにおいてデータベースエンジンを起動すると、当該バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行う。

当該物理バックアップのデータに基づいてデータリカバリーを完了した後に、論理リカバリーコマンドを作成し、当該論理リカバリーコマンドを実行し、当該バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うことをトリガーする。例えば、潜んでいる論理リカバリーＳＱＬステートメントＲＥＣＯＶＥＲＹを作成してもよく、前記論理バックアップのリカバリーと同様な原理を利用しているため、ここで重複な説明を省略する。

バックアップデータパケットは、複数のｔａｒパケットからなる１つのバックアップデータパケットであってもよく、この場合、先に当該複数のｔａｒパケットを同一の一時ディレクトリに展開し、そして、一時ディレクトリに基づいてデータリカバリーを行う。一実施形態において、一時ディレクトリを、リカバリーコマンドにおけるリカバリーデータソースサブステートメントのコンテンツ、例えば、一時ディレクトリをＲＥＣＯＶＥＲＹコマンドにおけるＦＲＯＭサブステートメントのコンテンツとして、当該ＲＥＣＯＶＥＲＹコマンドを実行してデータリカバリーを行う。

２１３において、サーバは、論理バックアップのデータに対してデータリカバリーを完了した後に、ＣＨＥＣＫＰＯＩＮＴ操作を再実行する。

なお、データベースシステムにおけるトータルデータのリカバリーは、一般的に、オフラインリカバリーによって行われることができる。従って、ＣＬＩのＢＡＣＫＵＰコマンドのみを利用してリカバリーを実行することができる一方、非トータルデータのリカバリーは、オフライン場合におけるリカバリー及びオンライン場合におけるリカバリーの両方をサポートすることができる。

また、幾つかの可能な実施形態において、幾つかのデータベースエンジンのオペレーティングシステムは、ユーザーによって権限の違いがあるため、リカバリー操作を行うユーザー権限を制限してもよい。例えば、リカバリーコマンドを実行させるユーザーはデータベースエンジンのオペレーティングシステム起動権限を有しなければならい。一方、幾つかの好ましい実施形態において、データベース内部に権限の違いがあり、リカバリーデータの網羅性のために、論理データをリカバリーする場合、ユーザー権限のチェックを行わず、リカバリー操作を行うことを許可する。

好ましく、データの一致性を保証するために、データリカバリーを行った後に、さらに、データの可視性を判断することにより、読み取られてユーザーに表示可能なデータを特定する。例えば、ブロック方式によりバックアップされたデータの場合、１つのページには、一部のデータが有効データ(バックアップするときに指定されたバックアップ条件、例えば、ＷＨＥＲＥ条件を満たす)であり、残りの無効データ(バックアップするときに指定されたバックアップ条件を満たさないが、ブロックバックアップ方式によって冗長にバックアップされる)は、読み取られるべきではない。

前記の要素に基づいて、データリカバリーを行う場合に、相応的にデータファイルのコピープロセスは、簡単にブロックコピーを行うことではなく、幾つかの場合に分けて処理する。

１、バックアップするときにバックアップ条件が無い(例えば、バックアップするときにＷＨＥＲＥ条件なし)場合、バックアップデータパケットのバックアップオブジェクトは、全テーブル空間であり、追加の操作が無く、直接にファイルコピー及び/又はデータブロックコピーを行うことができる。

２、バックアップするときにバックアップ条件付き(例えば、バックアップするときにＷＨＥＲＥ条件付き)、且つバックアップ条件が全てのデータファイルをカバーすることができる場合、追加の操作がなく、直接にファイルコピー及び/又はデータブロックコピーを行うことができる。

３、バックアップするときにバックアップ条件付き(例えば、バックアップするときにＷＨＥＲＥ条件付き)、且つバックアップ条件が全てのデータファイルをカバーすることができず、バックアップするときにファイルコピー又はブロックコピー方式によりバックアップが行われたとともに、図３に示すようにクロスページ識別ビットが設置されている。この場合、データリカバリーを行う場合に、バックアップ条件に応じて(ハイブリッドバックアップを例として、ＷＨＥＲＥ条件はメタ情報ファイル、ＨＭｅｔａ_０００００００１ファイルに記憶されてもよい)、データブロック毎に認識及びフィルタリングし、バックアップ条件を満たさない場合、バージョンのそれぞれは、「データ有効ビット」において対応する１つのビットが１である。データリカバリーが完了した後に、データ読み取り操作により読み取られたバージョンのそれぞれは、そのデータ有効ビットが当該バージョンが視認不可であることを示す場合、当該バージョンを返さず、データ有効ビットが当該バージョンが視認可能であることを示す場合、当該バージョンを返し、例えば、それに対応する「データ有効ビット」のビットの値が１である場合、当該バージョンを上へ返さず、それに対応する「データ有効ビット」のビットの値が１ではない場合、当該バージョンを上へ返して、当該バージョンがユーザーに視認される。データブロックの間に直接関連関係がないため、データをリカバリーする場合に、リカバリー効率を向上するために、ブロックを単位として、データ識別ビットを並行して設置してもよい。通常、データバックアップは、バックアップテーブルの全体をメインにして、リカバリーするときに認識及びフィルタリングプロセスによって引き起こされ易い効率課題を回避することができる。

データリカバリーが完了した後に、前記のデータを読み取る過程において、図３に示すように、データ有効ビットは２つの部分に分けられる。一実施形態において、当該データ有効ビットは、２つのビットで示してもよく、そのうちの一方の部分はデータ識別ビットであり、当該バージョンの表示可否を示すために用いられ、１つのビットで示すことができる。他方の部分はクロスページ識別ビットであり、本ベージデータがクロスページであるか否かを示し、残りの一つのビットであり、１でクロスページを示し、０がクロスページではないことを示す。クロスページ識別ビットが存在する場合、データ捜索する時に停止することができず、次のページを継続して読み込んでページ解析を行う。

本出願の実施例は、時制データベースを基に、時制データバックアップに基づくリカバリー方法を提案し、全状態データにおける任意の状態のデータをバックアップした後に、例えば、論理方式又は物理方式及びハイブリッドでバックアップした後に、データリカバリーを実現し、時制データの有効記憶及び安全信頼性を保証し、有効な保障を提供することができる。

図２のフローチャートにおける各ステップは、矢印の指示に従って順に表示されているが、これらのステップは必ずしも矢印で指示した順に実行されるわけではない。本明細書に明確な記載があることを除外、これらのステップの実行は、厳格に順に行われるものではなく、これらのステップは他の順に従って実行されてもよい。そして、図２における少なくとも一部のステップは複数のサブステップ又は複数の段階を含んでもよく、これらのサブステップ又は段階は、必ずしも同じタイミングで実行されて完了するわけではなく、異なったタイミングで実行されてもよく、これらのサブステップ又は段階の実行順序も必ず順に行われるわけではなく、他のステップ又は他のステップのサブステップ又は段階における少なくとも一部に対して、順番にまたは交替に実行されてもよい。

図４は、本出願の実施例にかかるデータリカバリー装置の構成模式図である。図４を参照して、当該装置は、
バックアップデータパケットのバックアップタイプを認識するための認識モジュール４０１と、
認識したバックアップタイプがハイブリッドバックアップである場合に、当該バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うためのデータリカバリーモジュール４０２と、を含み、
当該ハイブリッドバックアップとは、バックアッププロセスに物理バックアップと論理バックアップとを含むことを指し、
当該データリカバリーモジュール４０２は、当該物理バックアップのデータに基づいてデータリカバリーを完了した後に、当該バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うために用いられる。

一つの好ましい実施形態において、データリカバリーモジュール４０２は、ファイルコピー方式により、当該バックアップデータパケットにおける物理バックアップのデータを、ファイル名及びテーブル名に従ってターゲットディレクトリにおける対応する位置にコピーするために用いられる。

一つの好ましい実施形態において、当該バックアップデータパケットにおける物理バックアップのデータをコピーする場合、並行の方式により行う。

一つの好ましい実施形態において、当該装置は、
当該物理バックアップのデータに基づいてデータリカバリーを完了した後に、論理リカバリーコマンドを作成し、当該論理リカバリーコマンドを実行し、当該バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うことをトリガーするトリガーモジュールをさらに含む。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、認識したバックアップタイプが論理バックアップである場合に、当該バックアップデータパケットのメタ情報ファイルに基づいて、ターゲットライブラリにおいてテーブルを作成し、データリカバリーを行う。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、当該バックアップデータパケットがノーマルトランザクションスナップショットに基づいて得られたものである場合、当該バックアップデータパケットのメタ情報ファイルからテーブルファイルのメタ情報を読み取り、当該テーブルファイルのメタ情報に基づいてターゲットライブラリにおいてテーブルを作成し、挿入操作を実行してデータリカバリーを行い、当該ターゲットライブラリに同名のテーブルが存在する場合、リカバリーに失敗した。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、当該バックアップデータパケットが履歴トランザクションスナップショットに基づいて得られたものである場合、当該バックアップデータパケットのメタ情報ファイルから、テーブルファイルのメタ情報を読み取り、前記ターゲットライブラリに同名のテーブルが存在しない場合、当該テーブルファイルのメタ情報に基づいてターゲットライブラリにテーブルを作成し、挿入操作を実行してデータリカバリーを行い、当該ターゲットライブラリに同名のテーブルが存在する場合、テーブルの作成を行わず、データリカバリーのみを行う。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、当該バックアップデータパケットがノーマルトランザクションスナップショット及び履歴トランザクションスナップショットに基づいて得られたものである場合、当該ノーマルトランザクションスナップショット及び当該履歴トランザクションスナップショットに対応するデータリカバリー方式を組み合わせてデータリカバリーを行う。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、当該ターゲットライブラリにおいて当該同名のテーブルにリカバリーすべきデータと同じデータが存在する場合、リカバリーに失敗し、当該ターゲットライブラリにおいて当該同名のテーブルにリカバリーすべきデータと同じデータが存在しない場合、当該リカバリーすべきデータに基づいてリカバリーを行う。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、主キーインデックスにより当該ターゲットライブラリにおいて当該同名のテーブルに当該リカバリーすべきデータと同じデータが存在するか否かをチェックする。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、認識したバックアップタイプが物理バックアップである場合、当該バックアップデータパケット及び新しく作成されたデータディレクトリに基づいて、データリカバリーを行う。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、マルチスレッド並行の方式により、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行う。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、マルチスレッド並行の方式により、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行う。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、データリカバリーを行う過程において、バックアップするときにバックアップ条件がない場合、ファイルコピー又はブロックコピーを行い、
バックアップするときにバックアップ条件付き、且つ当該バックアップ条件が全てのデータファイルをカバーすることができる場合、ファイルコピー又はブロックコピーを行う。

一つの好ましい実施形態において、当該データリカバリーモジュール４０２は、さらに以下のことに用いる。即ち、データリカバリーを行う過程において、バックアップするときにファイルコピー又はブロックコピー方式により行い、且つバックアップするときにバックアップ条件付き、当該バックアップ条件が全てのデータファイルをカバーすることができない場合、バックアップデータパケットのメタ情報ファイルにマークされている無効データに基づいてデータリカバリーを行う。

一つの好ましい実施形態において、当該認識モジュール４０１は、さらに以下のことに用いる。即ち、当該バックアップデータパケットにおけるファイル名に基づいて、当該ファイル名に対応するバックアップタイプを取得し、又は、当該バックアップデータパケットに担持されているタイプ識別子に基づいて、当該タイプ識別子に対応するバックアップタイプを取得する。

一つの好ましい実施形態において、当該装置は、
データリカバリーが完了した後に、データ読み取り操作によりいずれかのバージョンを読み取った場合に、当該バージョンのデータ有効ビットが当該バージョンが視認不可であることを示す場合、当該バージョンを返さず、当該バージョンのデータ有効ビットが当該バージョンが視認可能であることを示す場合、当該バージョンを返すための読み取りモジュールをさらに含む。

なお、前記の実施例にかかるデータリカバリー装置は、データをリカバリーする場合に、前記各機能モジュールに対する区分を例にして説明したが、実際の適用において、必要に応じて、前記機能を異なった機能モジュールに割り当てて完了させることができる。即ち、装置の内部構成を異なった機能モジュールに分割して、上記した全て又は一部の機能を完了させる。また、前記の実施例にかかるデータリカバリー装置は、データリカバリー方法実施例と同一技術思想に属し、具体的な実現プロセスの詳細は、方法実施例を参照することができ、ここで重複な説明を省略する。

図５は、本出願の実施例にかかるサーバの構成模式図であり、当該サーバ５００は、配置又は性能によっては大きい相違が生じる可能性があり、１つ又は１つ以上のプロセッサー(ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔｓ、ＣＰＵ)５０１及び１つ又は１つ以上のメモリ５０２を含み、その中、前記メモリ５０２に少なくとも一つのコマンドが記憶され、前記少なくとも一つのコマンドが前記プロセッサー５０１によってロードされて実行されると、前記の各方法実施例にかかる方法が実現される。勿論、当該サーバは、入出力を行うように、有線又は無線ネットワークインターフェース、キーボード及び入出力インターフェースなどの部品をさらに有してもよく、当該サーバは、他の機器機能を実現するための構成要素をさらに含んでもよく、ここで重複な説明を省略する。

本出願の実施例において、さらに、コンピュータ読み取り可能な記憶媒体を提供し、当該コンピュータ読み取り可能な記憶媒体はサーバに適用され、当該コンピュータ読み取り可能な記憶媒体に少なくとも一つのコマンド、少なくとも一つのプログラム、コードセット又はコマンドセットが記憶され、当該コマンド、当該プログラム、当該コードセット又は当該コマンドセットはプロセッサーによってロードされて実行されると、前記の実施例に係るデータリカバリー方法においてサーバにより実行される操作が実現される。

なお、本出願の実施例に係るバージョンの表示可否とは、バックアップタスクにおける当該バージョンに対応するトランザクションスナップショットのタイミングがトランザクションにより読み取られ得るか否かを指す。データテーブル内の任意のタプルのいずれかのバージョンについて、トランザクションスナップショット及び前記バージョンの作成タイミング、削除タイミング及び前記バージョンの提出タイミングに基づいて、前記バージョンの表示可否を特定する。サーバは、データテーブルから一つのタプルを読み取る度に、当該タプルのライフサイクル情報、即ち、当該バージョンの作成タイミング、削除タイミング及び前記バージョンの提出タイミングなどの情報を読み取ることができ、履歴時間帯の可視性に基づいて判断することを例とする。即ち
(一)：当該バージョンが挿入操作生成である場合、且つ当該作成タイミングが当該履歴時間帯の開始タイミングの前にあり、当該提出タイミングが当該履歴時間帯の間にある場合、当該バージョンが視認可能であると特定し、又は、当該作成タイミング及び当該提出タイミングの両方が当該履歴時間帯の間にある場合、当該バージョンが視認可能であると特定する。
(二)：当該バージョンが削除操作生成である場合、当該削除タイミングが当該履歴時間帯の開始時点の前にあり、当該提出タイミングが当該履歴時間帯の間にある場合、当該バージョンが視認可能であると特定し、又は、当該削除タイミング及び当該提出タイミングの両方が当該履歴時間帯の間にある場合、当該バージョンが視認可能であると特定する。
(三)：当該バージョンが更新操作生成である場合、当該作成タイミングが当該履歴時間帯の開始タイミングの前にあり、当該提出タイミングが当該履歴時間帯の間にある場合、当該バージョンが視認可能であると特定し、又は、当該作成タイミングが当該履歴時間帯の開始時点の後にあり、当該提出タイミングが当該履歴時間帯の間にある場合、当該バージョンが視認可能であると特定する。

当業者が理解できるように、前記実施例の全てまたは一部のステップを実現することは、ハードウェアにより完成されてもよく、プログラムにより、関するハードウェアに命令するように完成されてもよく、前記プログラムはコンピュータ可読記憶媒体に記憶され、前記言及された記憶媒体は、読み取り専用メモリ、磁気ディスクまたは光ディスクなどであってもよい。

以上の実施例の各技術特徴に対して、任意の組み合わせを行ってもよく、記載を簡潔にするために、前記実施例の各技術特徴の全ての可能な組み合わせを記載していないが、これらの技術特徴の組み合わせはいずれも、矛盾が存在しない限り、本明細書の記載範囲であると認められる。

以上の実施例は、本出願のいくつかの実施形態のみを表現し、その記載は具体的且つ詳しいが、そのため、発明の特許範囲に対する限定と理解されることができない。指摘すべきこととして、当業者にとって、本出願の構想から逸脱しない前提で、さらに、若干の変形及び改良を行ってもよく、これらはいずれも本出願の保護範囲に当該当すべきである。従って、本出願特許の保護範囲は、添付の請求項を基準とする。

Claims

サーバによって実行されるデータリカバリー方法であって、
バックアップデータパケットのバックアップタイプを認識するステップと、
認識したバックアップタイプがハイブリッドバックアップである場合に、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うステップと、
前記物理バックアップのデータに基づいてデータリカバリーを行うステップを完了した後に、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うステップとを含み、
前記ハイブリッドバックアップとは、バックアッププロセスに物理バックアップと論理バックアップとを含むこと指す
ことを特徴とする方法。
前記認識したバックアップタイプがハイブリッドバックアップである場合に、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うステップは、
ファイルコピー方式により、前記バックアップデータパケットにおける物理バックアップのデータを、ファイル名及びテーブル名に従ってターゲットディレクトリにおける対応する位置にコピーすることを含むことを特徴とする請求項１に記載の方法。
並行方式により、前記バックアップデータパケットにおける物理バックアップのデータをターゲットディレクトリにおける対応する位置にコピーするステップをさらに含むことを特徴とする請求項１に記載の方法。
前記の物理バックアップのデータに基づいてデータリカバリーを行うステップを完了した後、
論理リカバリーコマンドを作成するステップと、
前記論理リカバリーコマンドを実行して、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うステップをトリガーするステップとをさらに含むことを特徴とする請求項１〜３の何れか1項に記載の方法。
認識したバックアップタイプが論理バックアップである場合に、前記バックアップデータパケットのメタ情報ファイルに基づいて、ターゲットライブラリにおいてテーブルを作成し、データリカバリーを行うステップをさらに含むことを特徴とする請求項１に記載の方法。
前記バックアップデータパケットのメタ情報ファイルに基づいて、ターゲットライブラリにおいてテーブルを作成し、データリカバリーを行うステップは、
前記バックアップデータパケットがノーマルトランザクションスナップショットに基づいて得られたものである場合に、前記バックアップデータパケットのメタ情報ファイルから、テーブルファイルのメタ情報を読み取るサブステップと、
前記テーブルファイルのメタ情報に基づいて前記ターゲットライブラリにおいて前記テーブルを作成するサブステップと、
前記テーブルに対して挿入操作を実行して、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うサブステップとを含むことを特徴とする請求項５に記載の方法。
前記バックアップデータパケットのメタ情報ファイルに基づいて、ターゲットライブラリにおいてテーブルを作成し、データリカバリーを行うステップは、
前記バックアップデータパケットが履歴トランザクションスナップショットに基づいて得られたものである場合に、前記バックアップデータパケットのメタ情報ファイルから、テーブルファイルのメタ情報を読み取るサブステップと、
前記ターゲットライブラリに同名のテーブルが存在しない場合、前記テーブルファイルのメタ情報に基づいてターゲットライブラリにおいてテーブルを作成し、挿入操作を実行してデータリカバリーを行うサブステップと、
前記ターゲットライブラリに同名のテーブルが存在する場合、前記同名のテーブルに対して挿入操作を実行してデータリカバリーを行うサブステップとを含むことを特徴とする請求項５に記載の方法。
前記バックアップデータパケットのメタ情報ファイルに基づいて、ターゲットライブラリにおいてテーブルを作成し、データリカバリーを行うステップは、
前記バックアップデータパケットがノーマルトランザクションスナップショット及び履歴トランザクションスナップショットに基づいて得られたものである場合は、
前記バックアップデータパケットのメタ情報ファイルから、テーブルファイルのメタ情報を読み取り、前記テーブルファイルのメタ情報に基づいて前記ターゲットライブラリにおいて前記テーブルを作成し、前記テーブルに対して挿入操作を実行して、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うサブステップ、又は
前記バックアップデータパケットのメタ情報ファイルから、テーブルファイルのメタ情報を読み取り、前記ターゲットライブラリに同名のテーブルが存在しない場合、前記テーブルファイルのメタ情報に基づいてターゲットライブラリにおいてテーブルを作成し、挿入操作を実行してデータリカバリーを行い、前記ターゲットライブラリに同名のテーブルが存在する場合、前記同名のテーブルに対して挿入操作を実行してデータリカバリーを行うサブステップを含むことを特徴とする請求項５に記載の方法。
前記ターゲットライブラリに同名のテーブルが存在する場合、前記同名のテーブルに対して挿入操作を実行してデータリカバリーを行うサブステップは、
前記ターゲットライブラリにおいて前記同名のテーブルにリカバリーすべきデータと同じデータが存在しない場合、前記リカバリーすべきデータに基づいてリカバリーすることを含むことを特徴とする請求項７に記載の方法。
認識したバックアップタイプが物理バックアップである場合に、前記バックアップデータパケット及び新しく作成されたデータディレクトリに基づいて、データリカバリーを行うステップをさらに含むことを特徴とする請求項１に記載の方法。
前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うステップは、
マルチスレッド並行の方式により、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うサブステップを含むことを特徴とする請求項１に記載の方法。
前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うステップは、
マルチスレッド並行の方式により、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うサブステップを含むことを特徴とする請求項１に記載の方法。
データリカバリーを行う過程において、バックアップする場合にバックアップ条件がない場合、ファイルコピー又はブロックコピーを行うステップと、
バックアップする場合にバックアップ条件があり、且つ前記バックアップ条件が全てのデータファイルをカバーすることができる場合、ファイルコピー又はブロックコピーを行うステップとをさらに含むことを特徴とする請求項１に記載の方法。
データリカバリーを行う過程において、バックアップする場合にファイルコピー又はブロックコピー方式により行われ、且つ、バックアップする場合にバックアップ条件があり、前記バックアップ条件が全てのデータファイルをカバーすることができない場合、バックアップデータパケットにおけるメタ情報ファイル中にマークされた無効データに基づいて、データリカバリーを行うステップをさらに含むことを特徴とする請求項１に記載の方法。
データリカバリーを行った後、データ読み取り操作によりいずれかのバージョンが読み取られる場合は、
前記バージョンのデータ有効ビットが前記バージョンが視認不可であることを示すと、前記バージョンを返さず、
前記バージョンのデータ有効ビットが前記バージョンが視認可能であることを示すと、前記バージョンを返すステップをさらに含むことを特徴とする請求項１に記載の方法。
データリカバリー装置であって、
バックアップデータパケットのバックアップタイプを認識するための認識モジュールと、
認識したバックアップタイプがハイブリッドバックアップである場合に、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うデータリカバリーモジュールとを含み、
前記ハイブリッドバックアップとは、バックアッププロセスに物理バックアップと論理バックアップとを含むことを指し、
前記データリカバリーモジュールは、さらに、前記物理バックアップのデータに基づいてデータリカバリーを完了した後に、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うために用いられることを特徴とする装置。
サーバであって、プロセッサー及びメモリを含み、
前記メモリに少なくとも一つのコマンドが記憶され、前記少なくとも一つのコマンドが当該プロセッサーによってロードされて実行されると、前記サーバに以下のステップを実行させ、即ち、
バックアップデータパケットのバックアップタイプを認識するステップと、
認識したバックアップタイプがハイブリッドバックアップである場合に、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うステップと、
前記物理バックアップのデータに基づいてデータリカバリーを完了した後に、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うステップとを含み、
前記ハイブリッドバックアップとは、バックアッププロセスに物理バックアップと論理バックアップとを含むことを指すことを特徴とするサーバ。
前記少なくとも一つのコマンドが当該プロセッサーによってロードされて実行されると、前記サーバに以下のステップをさらに、実行させ、即ち、
ファイルコピー方式により、前記バックアップデータパケットにおける物理バックアップのデータをファイル名及びテーブル名に従ってターゲットディレクトリにおける対応する位置にコピーするステップを含むことを特徴とする請求項１７に記載のサーバ。
コンピュータ・プログラムであって、
少なくとも一つのコマンドが含まれ、前記少なくとも一つのコマンドがプロセッサーによってロードされて実行されると、前記プロセッサーに以下のステップを実行させ、即ち、
バックアップデータパケットのバックアップタイプを認識するステップと、
認識したバックアップタイプがハイブリッドバックアップである場合に、前記バックアップデータパケットにおける物理バックアップのデータに基づいてデータリカバリーを行うステップと、
前記物理バックアップのデータに基づいてデータリカバリーを完了した後、前記バックアップデータパケットにおける論理バックアップのデータに対してデータリカバリーを行うステップとを含み、
前記ハイブリッドバックアップとは、バックアッププロセスに物理バックアップと論理バックアップとを含むことを指すことを特徴とするコンピュータ・プログラム。
前記少なくとも一つのコマンドが当該プロセッサーによってロードされて実行されると、前記プロセッサーに以下のステップをさらに、実行させ、即ち、
ファイルコピー方式により、前記バックアップデータパケットにおける物理バックアップのデータをファイル名及びテーブル名に従ってターゲットディレクトリにおける対応する位置にコピーするステップを含むことを特徴とする請求項１９に記載のコンピュータ・プログラム。