3

現在、DB2 組み込みバックアップを使用して毎日のバックアップを行っている 200 GB 以上のデータベースがあります (復元しないことを願っています - 笑)。効用。バージョンは 8.2 FP 14 ですが、すぐに 9.1 に移行する予定で、バックアップと復元を行う 9.5 データベースもいくつかあります。この目的のために使用した最高のツールは何ですか?

ありがとう！

4

7 に答える 7

2

役立つことの 1 つは、DB2 バージョン 9 に移行して圧縮をオンにすることです。その後、バックアップのサイズが減少し (テーブル レベルで最大 70 ～ 80%)、バックアップ時間が短縮されます。もちろん、データベースが継続的に成長している場合は、すぐに再び問題が発生しますが、その場合はデータのアーカイブが必要になる場合があります。

于 2008-10-11T22:33:41.497 に答える
2

バックアップを作成し、より重要なリカバリをより高速に実行するには、2 つの方法しかありません。

バックアップするデータの量を減らす方法について、多くの提案があったと思います。基本的に、フル バックアップの頻度は比較的低く、変更された (前回のフル バックアップ以降) データのバックアップはより頻繁に行うバックアップ戦略を作成する必要があります。DB2 コントロール センターの [自動メンテナンスの構成] ウィザードを確認することをお勧めします。自動バックアップの作成や、 Antonioが提案したREORG などの他のユーティリティを使用するのに役立ちます。データの量がはるかに少ないため、圧縮などは明らかに役立ちます。ただし、すべての DB2 エディションで圧縮が提供されるわけではありません。たとえば、DB2 Express-Cにはありません。率直に言って、200GB のデータベースで圧縮を行うことは、いずれにせよ価値がないかもしれません。それこそが、 DB2 Express-C のような無料の DBMS を提供する理由です。圧縮を提供しないでください。

バックアップ用に大きなパイプを開く限り、最初にディスクにバックアップするか、テープにバックアップするかを決定する必要があります。速度に大きな違いがあります (明らかにディスクの方がはるかに高速です)。次に、DB2 はバックアップを並列化できます。そのため、バックアップするデバイスが複数ある場合は、それらすべてに同時にバックアップされます。つまり、問題に対処する必要があるデバイスの数に応じて、経過時間が大幅に短縮されます。繰り返しになりますが、DB2 コントロール センターはセットアップを支援します。

于 2008-10-14T19:11:46.237 に答える
2

あまり役に立たないサードパーティのツールを見る前に、いくつかの最適化を検討します。

1) テーブルとインデックスで REORG を使用したことがありますか? これにより、情報が圧縮され、使用されるページの量が最小限に抑えられます。

2) 可能であれば、同時に複数のディスクにバックアップします。これは、実行することで簡単に実現できますdb2 backup db mydb /mnt/disk1 /mnt/disk2 /mnt/disk3 ...

3) DB2 はそれ自体の微調整を適切に行う必要がありますが、いつでもWITH num_buffers BUFFERS,BUFFER buffer-sizeおよびPARALLELISM nオプションを試すことができます。しかし、繰り返しになりますが、通常、DB2 は単独でより優れた仕事をします。

4) 毎日の増分バックアップと、土曜日または日曜日に 1 回の完全バックアップの実行を検討してください。

5)通常のワークロードに影響UTIL_IMPACT_PRIORITYをUTIL_IMPACT_LIM与えすぎないように、バックアップ プロセスを調整できます。これは、主な関心事が時間自体ではなく、バックアップ中のデータサーバーのパフォーマンスである場合に役立ちます。

6) DB2 9 のデータ圧縮は、バックアップが必要なデータのサイズを縮小するという点で、驚くべき効果を発揮します。非常に印象的な結果が得られました。バージョン 9.1 または 9.5 に移行できる場合は、強くお勧めします。

于 2008-10-13T21:44:06.900 に答える
1

High Performance Unload (HPU) をお試しください - これは Infotel のスタンドアロン製品でしたが、Optim データ スタジオの一部として利用できるようになりました - ここに投稿https://www.ibm.com/developerworks/mydeveloperworks/blogs/idm/date/200910? lang=en

于 2010-06-02T12:42:37.533 に答える
0

サード パーティのバックアップ パッケージを使用しても、おそらく速度はあまり向上しません。2 時間ごとに完全バックアップを実行していないことを確認することが、おそらく最初のステップです。

その後、バックアップの書き込み先を確認します。ネットワークドライブではなく、ローカルドライブですか? スピンドルは他の用途に使用されていますか? バックアップには多くのシーク アクティビティは含まれませんが、大量の書き込みが必要になるため、おそらく RAID 5 を避け、大きなストライプ サイズを使用してスループットを最大化することをお勧めします。

当然のことながら、遅かれ早かれフル バックアップを実行する必要がありますが、負荷が軽い時間枠を見つけて、バックアップ間隔を長くとることができることを願っています。通常の増分がオフになっている 4 ～ 6 時間の間にフル バックアップを実行し、残りの時間はそれに基づいて増分を実行します。

また、バックアップを完全に別のシステムにコピーするまで、実際にはバックアップされません。送信前、送信中、または送信後に圧縮する方が良いかどうかを実験して判断する必要があります。

于 2008-10-13T20:34:49.050 に答える
0

別のバックアップ ツールを使用して高速化できるとは思えません。Mike が言及しているように、TSM をスタックに追加することはできますが、バックアップの実行速度はほとんど向上しません。

私があなたなら、バックアップ ファイルが保存されている場所を調べます。データベース自体と同じディスク スピンドルを使用していますか? 該当する場合: バックアップ ウィンドウ中にアクセスできないストレージ領域にバックアップ ファイルを保存できるかどうかを確認します。

また、毎日のバックアップには増分バックアップを使用し、土曜日には長い完全バックアップを使用することを検討してください。

(バックアップ中にデータが使用できなくなることがないように、既にオンライン バックアップを実行していると仮定します。)

于 2008-10-06T20:28:47.050 に答える
0

これは「サード・パーティー」製品ではありませんが、DB2 を使用しているのを見たことのある人は、Tivoli Storage Managerを使用してデータベースのバックアップを保管しています。

ほとんどのショップは TSM へのアーカイブ ロギングを設定するので、「大きな」バックアップを毎週程度取るだけで済みます。

これも IBM 製品であるため、お持ちのさまざまな種類の DB2 で動作することを心配する必要はありません。

欠点は、IBM 製品であることです。:)その（$）があなたに違いをもたらすかどうかはわかりません。

于 2008-10-06T20:15:07.953 に答える