Forum Stats

  • 3,853,774 Users
  • 2,264,266 Discussions
  • 7,905,444 Comments

Discussions

RMANの差分バックアップが遅い

835327
835327 Member Posts: 3
Oracle10gR2 StandardEditionのRMANを使ってバックアップしています。

以下のスクリプトで差分バックアップを実行していますが、完全バックアップと同じくらいの時間がかかります。
RUN
{
crosscheck archivelog all;
configure channel device type disk format='daily_db_%U';
backup
incremental level = 1
as compressed backupset database
plus archivelog format='daily_db_arc_%U' delete all input;
delete noprompt obsolete recovery window of 7 days;
}

EnterpriseEditionでは、ブロックチェンジトラッキング機能が使えるのですが、StandardEditionでは使えません。
改善する方法があれば教えてください。

Answers

  • hottate
    hottate Member Posts: 43 Blue Ribbon
    RMAN の差分バックアップはパフォーマンスの向上を目的にしたものではないですから
    処理時間が完全バックアップと変わらなくても別におかしくはないかと。

    一回の処理時間を何とかしたいのであれば、データベース単位ではなく表領域単位とか
    データファイル単位にすればよいのでは。
  • weyk
    weyk Member Posts: 82
     変更したかどうかを調べるには、結局は全部見てみるしかないですからね。あなた自身でよい方法が無さそう(=他に手段が無さそう)なら、やっぱりどうにもならないです(私にもEEで既に採用している方法以外は思いつきません)。「更新するたびに別途メモを取っておいて、増分バックアップの際はメモを元にして、全使用中ブロックについて変更したかどうかのチェックをするのを省く」というのが、EEの機能ですね。
     バックアップ先となるデバイスが著しく遅い(書き込む容量の差が時間に大きく影響する)とかではないかぎり、大差は無くても仕方ないかと思います。
    また、時間がかかるからこそ、EEには更新のあったブロックをマークするという機能が存在するわけですし・・・

    増分バックアップの目的は、「リカバリの際の」時間の短縮です(と、多数保持する際の総バックアップ容量の削減?)。また、その時間が取れないなら、(連続した全ての)アーカイブREDOログの適用でもリカバリ可能です。通常は、(計画を立てて)バックアップのために確保する時間と、(突然に)リカバリが必要になって復旧されセルまでの時間とでは、後者のほうは可能な限り短時間で実施する必要がありますから。
    -- CMN v0.61β --
  • hottate
    hottate Member Posts: 43 Blue Ribbon
    「リカバリの際の」時間の短縮
    ですが、フルバックアップ+差分+差分+...+アーカイブみたいなバックアップ計画だと、
    返って時間がかかってしまわないでしょうかねぇ...?
    まあスケジュール次第かとは思いますが。


    (Standard でパフォーマンスは期待しない。裏切られるとつらいから)
  • weyk
    weyk Member Posts: 82
    edited Mar 9, 2011 9:36PM
     こんにちは。
    「リカバリの際の」時間の短縮
    ですが、フルバックアップ+差分+差分+...+アーカイブみたいなバックアップ計画だと、
    返って時間がかかってしまわないでしょうかねぇ...?
     個々の差分となる期間に、同じブロックへの更新が多数回あるなら、その分は、REDOログの情報に比べると「圧縮」されますし、また、増分にも、
    ・前回のフルバックアップからの増分。
    ・前回のフルもしくは(いずれかの)増分バックアップからの増分。
    と選ぶこともできますし、そもそもの、フルバックアップの周期の選択も含めて、必要な容量とリカバリの際にかかる時間でバランスを取ることになるかと思います。

    例えば、
    毎月1回フルバックアップ
    2週に1回フルバックアップからの増分バックアップ
    上記が飛ぶ週に直前の増分バックアップからの増分バックアップ
    とか。

    REDOログと比較したデータが無いと判断が難しそうな感じはありますが・・・REDOログはかなり遅いんですかね・・・?
    -- CMN v0.61β --

    Edited by: weyk on 2011/03/10 11:35 週2回→2週に1回 の誤記修正
  • hottate
    hottate Member Posts: 43 Blue Ribbon
    個々の差分となる期間に、同じブロックへの更新が多数回あるなら、その分は、REDOログの情報に比べると「圧縮」されますし、
    そっか、確かに同じブロックに複数回更新が行われる場合に、更新された回数分 REDO 情報を読むのと
    最終的に更新されたブロックを 1 回適用するのとでは、ブロックを適用したほうが早いですね。

    あとは実運用で想定される更新の仕方を基にバックアップのスケジューリングと処理時間の
    すり合わせを十分テストしてね、というところですかね。
  • 835327
    835327 Member Posts: 3
    回答ありがとうございます。

    差分バックアップの処理時間は短縮できなさそうですね。
    差分バックアップのファイルサイズは小さいのに時間がかかっているのでオプションが間違っているのかと思っていましたが、
    そういうものなのですね。

    マシンの構成、スペック、媒体などにもよりますが、6TBのDBをバックアップするのに12時間程かかります。(完全も差分も同じくらい)
    1週間毎に完全バックアップ、週2回差分バックアップをとっていますが、完全バックアップのリストアに2日間かかる(リカバリはすぐ終わる)
    ので、1日ぐらいに速度向上したいところです。

    新たな機器を購入せずにバックアップ、リカバリ処理速度を向上させるのは難しそうですね。
This discussion has been closed.