![[目次]](FIGURE/CONTENT.GIF)
![[用語]](FIGURE/GLOSS.GIF)
![[索引]](FIGURE/INDEX.GIF)
![[前へ]](FIGURE/FRONT.GIF)
![[次へ]](FIGURE/AFTER.GIF)
uCosminexus DocumentBroker Version 3 システム導入・運用ガイド
DocumentBrokerで使用する表のバックアップと回復は，データベースシステムの機能を利用してください。なお，使用できるデータベースシステムはHiRDBのため，データのバックアップと回復はHiRDBの機能を利用してください。HiRDBでのバックアップの取得方法と回復方法の詳細については，マニュアル「HiRDB システム運用ガイド」を参照してください。
また，ハードウェア障害の発生に備えて，DocumentBrokerがインストールされているシステムのレジストリ情報などの環境情報のバックアップも取得するようにしてください。
- ＜この項の構成＞
- (1) バックアップと回復について
- (2) バックアップと回復の方法
- (3) データベース運用上の注意事項
- (4) バックアップの取得
- (5) リストアの方法
DocumentBrokerは，データベース上のレコードを組み合わせることで，アプリケーションで扱う論理的なオブジェクトや，オブジェクト間の関連を実現しています。したがって，障害時の回復には，これらの関連の整合性を保持するようにバックアップおよび回復を行う必要があります。
DocumentBrokerでは，オブジェクト間の関連を，文書空間単位に管理しています。また，文書空間はデータベースのスキーマに対応しており，文書空間単位で運用できます。
DocumentBrokerでは，アプリケーションで扱うすべてのデータをデータベース上に格納しています。格納しているデータの障害回復には，データベースの機能を利用してください。
オブジェクト間の関連の整合性を保持したバックアップと回復の方法としては，文書空間単位でバックアップと回復を行う方法とRDエリア単位のバックアップと回復を行う方法があります。次に，これらの方法を説明します。
(a) 文書空間単位のバックアップと回復
文書空間単位でのバックアップの取得の概念を次の図に示します。
図6-1 文書空間単位でのバックアップの取得
文書空間（スキーマ）に属する全データのバックアップを，同期を取って取得します。障害が発生した場合は，全データをバックアップしたデータを基に回復します。ただし，同期を取って全データのバックアップを取得する運用では，文書空間に属するデータ量が多い場合，バックアップおよび回復に必要とする時間の増大や，障害回復までに，停止する業務範囲が大きいなどの問題が発生します。
この運用の場合，更新ログの取得方法として次に示す方法のどちらかを選択してください。
- ロールバックおよびロールフォワードに必要なログを取得する。
この方法の場合，バックアップから取得したデータに対して，更新ログでの任意の同期点までの論理的な整合性を保って回復します。
- ロールバックに必要なログだけを取得する。
この方法の場合，最後に全データのバックアップを取得した時点まで回復します。
(b) RDエリア単位のバックアップと最新同期点までの回復
RDエリア単位でのバックアップの取得の概念図を次の図に示します。
図6-2 RDエリア単位でのバックアップ取得
文書空間を構成する個々のRDエリアまたはディスクのパーティション単位にバックアップします。障害が発生した場合は，バックアップしたデータを基に，障害の発生したRDエリアのデータを回復します。この時，ほかのRDエリアのデータとの関連の整合性を保証するため，データベースの更新ログから最新の同期点まで回復します。このため，更新ログの取得方法は，ロールバックおよびロールフォワードに必要なログを取得する設定にしてください。
この方式では，バックアップした時にRDエリア相互の同期を取る必要がないため，対象データが多い場合にも，日々のバックアップ対象を全体の一部ずつとするなど，柔軟なバックアップの運用ができます。
LOB列格納用RDエリアの更新ログの取得方法は，データベース定義文を作成するコマンド（EDMCrtSqlおよびEDMAddMeta）の-uオプションで指定します。この-uオプションの引数によって，更新ログの取得方法を指定します。取得方法には，ログ取得モード，更新前ログ取得モード，およびログレスモードがあります。
なお，ログ取得モード（ロールバックおよびロールフォワードに必要なログを取得）を指定した場合は，更新前ログ取得モード（ロールバックに必要なログを取得）を指定した場合と比べて，次の注意が必要です。
(a) ログファイル容量
当該LOB列に対する追加・更新のデータ量の分だけログが増加するため，ログ容量（特にアンロードログファイルのディスク容量）が不足しないようにファイルサイズ（バイト）を見積もってください。1文書当たりの見積もりの概算を次に示します。
（文書ファイル数 ＋ 4） × 平均ファイルサイズ（バイト）
システムファイルの容量見積もりの詳細については，マニュアル「HiRDB システム導入・設計ガイド」を参照してください。
(b) ログ取得性能
ログの出力量の増加による性能劣化を抑えるため，次の2点を検討してください。
- LOB列格納用RDエリアへのグローバルバッファの割り当て
- グローバルバッファが指定されていない場合は，データの追加および更新ごとにログがファイルに出力されるため入出力が増加します。しかし，グローバルバッファが指定されている場合は，コミット時にログのファイルをバッファリングして出力するため，前者と比べて入出力の増加を抑えた運用ができます。グローバルバッファのオペランドの設定の詳細については，マニュアル「HiRDB システム定義」を参照してください。
- HiRDBのログ入出力バッファ長の拡大
- ログ量の増加に伴ってログ用バッファの使用量が増え，ログバッファの空き待ちになる場合が想定されます。このため，ログ入出力バッファ長の拡大を検討してください。サーバ共通定義の詳細については，マニュアル「HiRDB システム定義」を参照してください。
データベースシステムの機能を利用して，同期を取って，DocumentBrokerが使用している表一式のバックアップを取得してください。バックアップ対象になる表やエリアなどの情報は，データベースの初期設定で使用したデータベース定義文を基に事前に用意してください。
また，ハードウェア障害の発生に備えて，DocumentBrokerがインストールされているシステムのレジストリ情報などの環境情報のバックアップも取得するようにしてください。
取得したバックアップのリストアは，データベースシステムの機能を利用して実行してください。リストアを実行する前には，必ずDocumentBrokerを停止させてください。
All Rights Reserved. Copyright (C) 2012, Hitachi, Ltd.
All Rights Reserved. Copyright (C) 2012, Hitachi Solutions, Ltd.
![[図データ]](FIGURE/ZU610100.GIF)
![[図データ]](FIGURE/ZU610200.GIF)