11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章の内容は、次のとおりです。
Recovery Managerのバックアップ・ジョブまたはリストア・ジョブは、別々のフェーズまたはコンポーネントに分けることができます。Recovery Managerジョブでのこれらのフェーズのうち、最も低速なものをボトルネックといいます。Recovery Managerのチューニングの目的は、ジョブのボトルネックを特定し、Recovery Managerコマンド、初期化パラメータまたは物理メディアの調整を利用して、パフォーマンスを向上することです。
Recovery Managerのパフォーマンスをチューニングするには、Recovery Managerがバックアップをどのように作成するかについて、詳細に理解しておく必要があります。「Recovery Managerチャネル」で説明されているように、バックアップの作業は、1つ以上のチャネルで実行されます。チャネルは、ストレージ・デバイスへのバイト・ストリームを表しています。
バイト・ストリームは、メモリー内の入力バッファからCPU経由で出力バッファに渡され、さらにそこからストレージ・デバイスに渡されます。2つのテープ・デバイスにバックアップするように指定するには、2つのテープ・チャネルを割り当て、各バイト・ストリームが別々のデバイスに渡されるようにします。
各チャネルの作業は、チャネルのタイプがディスクまたはSBTのいずれであるかにかかわらず、次のフェーズに細分化されます。
ディスクのブロックが入力バッファに読み取られます。
入力バッファから出力バッファにブロックがコピーされ、ブロックに対する追加処理が実行されます。
出力バッファのブロックがストレージ・メディアに書き込まれます。書込みフェーズは、バックアップ・メディアのタイプに応じて、次の相互排他的な形式のいずれかになります。
図21-1に、3つのディスクに格納されているデータをバックアップする2つのチャネルを示します。各チャネルはデータを入力バッファに読み取り、入力バッファから出力バッファへのコピー時にデータを処理し、出力バッファからのデータをディスクに書き込みます。
図21-2は、同様に、3つのディスクに格納されているデータをバックアップする2つのチャネルを示していますが、ディスクの1つがネットワーク上にリモートでマウントされています。各チャネルはデータを入力バッファに読み取り、入力バッファから出力バッファへのコピー時にデータを処理し、出力バッファからのデータをテープに書き込みます。チャネル1はローカル接続されたテープ・ドライブにデータを書き込み、チャネル2はネットワークを介してリモート・メディア・サーバーにデータを送信します。
データをリストアする場合、これらの手順が逆順で実行され、読取りと書込みの操作が逆になります。次の項では、Recovery Managerのチューニングの概念について、バックアップを例に説明します。
この項では、Recovery Managerチャネルがディスクのデータを読み取る場合に、パフォーマンスに影響する次の要因について説明します。
バックアップ中、Recovery Managerチャネルは、入力ファイルのブロックをI/Oディスク・バッファに読み取ります。ディスク・サブシステムのデータベース・ファイルは、自動ストレージ管理、他のボリューム・マネージャまたはファイル・システムで管理できます。バックアップのチューニングに関する考慮事項は、データベース・ファイルをASMで管理するかどうかによって異なります。
入力バッファの割当ては、ファイルをどのように多重化するかによって異なります。バックアップの多重化は、バックアップ内の多数のファイルを複数のソースから同時に読み取り、1つのバックアップ・ピースに書き込むRecovery Managerの機能です。同時に読み取られ、同じバックアップ・ピースに書き込まれる入力ファイルの数を表す多重化レベルを決定するアルゴリズムの詳細は、「多重バックアップ・セット」を参照してください。この章を読む前に、これらの項を参照してください。
Recovery Managerチャネルは、ディスクのファイルをバックアップするときに、次の表に示す規則を使用して、作成する入力ディスクのバッファのサイズを決定します。
図21-3に、1つのチャネルで4つのデータファイルをバックアップする例を示します。MAXOPENFILESは4に設定され、FILESPERSETは4に設定されています。したがって、多重化のレベルは4です。このため、各データファイル用の合計バッファ・サイズは4MBになります。すべてのバッファを組み合せたサイズは16MBになります。
ASMに格納されているファイルをチャネルがバックアップする場合、入力ディスクのバッファの数は、ASMディスク・グループの物理ディスクの数と等しくなります。たとえば、16個の物理ディスクを含むASMディスク・グループにデータファイルが格納されている場合、チャネルはデータファイルのバックアップ用に16個の入力バッファを割り当てます。
チャネルがディスクからバックアップをリストアする場合は、4つのバッファが割り当てられます。バッファのサイズは、オペレーティング・システムによって異なります。
チャネルによるディスクに対する読取りまたは書込みでは、I/Oは同期I/Oと非同期I/Oのいずれかです。ディスクI/Oが同期の場合、サーバー・プロセスは一度に1つのタスクのみを実行できます。ディスクI/Oが非同期の場合、サーバー・プロセスは1つのI/Oを開始し、そのI/Oが完了するまで待機している間に他の作業を実行できます。また、1つ目のI/Oの完了の待機に入る前に、複数のI/O操作を開始することもできます。
ASMディスク・グループから読み取るときには、可能な場合は非同期ディスクI/Oを使用してください。また、ボリューム・マネージャで管理されているRAWデバイスからチャネルが読み取る場合も、非同期ディスクI/Oが適切に動作します。一部のオペレーティング・システムでは、固有の非同期ディスクI/Oをサポートしています。データベースは、使用可能な場合はその機能を利用します。
固有の非同期I/Oをサポートしていないオペレーティング・システムの場合、データベースは、特別なI/Oスレーブ・プロセスを使用してその機能をシミュレートできます。このこようなプロセスは、別のプロセスのかわりにI/Oを実行する専用のプロセスです。
ディスクI/Oスレーブを制御するには、動的でないDBWR_IO_SLAVES初期化パラメータを設定します。このパラメータでは、データベース・ライター・プロセス（DBWR）で使用されるI/Oサーバー・プロセスの数を指定します。デフォルトでは、この値は0（ゼロ）であり、I/Oサーバー・プロセスは使用されません。DBWR_IO_SLAVESが0（ゼロ）以外の値である場合に、非同期I/Oが無効であると、4つのバックアップ・ディスクI/Oスレーブが割り当てられます。
データベースがI/Oスレーブ用の共有バッファを取得する際、次のことが行われます。
LARGE_POOL_SIZEが設定されていて、かつDBWR_IO_SLAVESパラメータの値が0（ゼロ）以外に設定されている場合、データベースでは、ラージ・プールからのメモリーの取得が試行されます。この値が十分大きくない場合、アラート・ログにエラーが記録されます。また、共有プールからのバッファの取得は試行されず、非同期I/Oは使用されません。
LARGE_POOL_SIZEが設定されていない場合、または0（ゼロ）に設定されている場合、データベースは、共有プールからのメモリーの取得を試行します。
alert.logファイルに書き込みます。
ラージ・プールのメモリーは、共有サーバー、パラレル問合せ、Recovery ManagerのI/Oスレーブ・バッファなどの多くの機能に使用されます。ラージ・プールを構成すると、Recovery Managerがメモリー取得のために他のサブシステムと競合することを防止できます。
共有プールからの連続メモリーの割当ての要求は、通常は小さいサイズ（5KB未満）の要求です。ただし、大きいサイズの連続メモリーの割当てが要求されると、割当てが失敗するか、または要求された量の連続メモリーを解放するための大量のクリーンアップが必要となる場合があります。このメモリー要求は、共有プールでは満たせない場合がありますが、ラージ・プールでは満たすことができます。ラージ・プールには最低使用頻度（LRU）リストが存在しないため、ラージ・プールからの古いメモリーの削除は試行されません。
ALLOCATEコマンドまたはCONFIGURE CHANNELコマンドでは、RATEパラメータで、チャネルで読み取られる速度（バイト/秒）を指定します。このパラメータを使用すると、Recovery Managerが過度のディスク帯域幅を使用してオンライン・パフォーマンスが低下することを防止するために、読取りバイト数の上限を設定できます。基本的に、RATEは、バックアップの制限として機能します。たとえば、RATE=1500Kと設定し、各ディスク・ドライブの速度が3MB/秒である場合、チャネルは、ディスク帯域幅の一部をオンライン・システム用に確保します。
このフェーズでは、入力バッファから出力バッファにブロックがコピーされ、追加処理が実行されます。たとえば、データがディスクから読み取られてテープにバックアップされる場合、データはディスク・バッファから出力テープ・バッファにコピーされます。
コピー・フェーズには、次の処理が含まれています。
ブロックの検証を実行すると、ブロックが破損していないかどうかが確認されます。検証につては、第15章「データベース・ファイルおよびバックアップの検証」を参照してください。通常、この処理ではCPUに負荷はかかりません。
バイナリ圧縮を実行すると、Recovery Managerで、バックアップ・セット内のデータに圧縮アルゴリズムが適用されます。バイナリ圧縮は、CPUに負荷がかかる場合があります。Recovery Managerでバックアップに使用する圧縮アルゴリズムを選択できます。デフォルトでは、Recovery Managerは、圧縮率に優れているBZIP2を使用します。ZLIB圧縮では、COMPATIBLEを11.0.0以上に設定する必要があり、高速ですが圧縮率は他のアルゴリズムより悪くなります。バイナリ圧縮については、「圧縮バックアップの作成」を参照してください。
バックアップの暗号化を実行すると、V$RMAN_ENCRYPTION_ALGORITHMSに表示されているアルゴリズムのいずれかを使用して、バックアップ・セットが暗号化されます。Recovery Managerには、透過モード、パスワード保護モードおよびデュアル・モードの3つの暗号化モードがある。バックアップの暗号化については、「Recovery Managerバックアップの暗号化」を参照してください。バックアップの暗号化は、CPUに負荷がかかる場合があります。
SBTへのバックアップ時、Recovery Managerは、メディア・マネージャにバイト・ストリームを渡し、そのストリームに一意の名前を関連付けます。ストリームの格納方法および格納場所の詳細は、メディア・マネージャによって管理されます。したがって、テープへのバックアップでは、Recovery Managerとメディア・マネージャの両方が相互に作用します。
SBTへの書込みフェーズに影響するRecovery Manager固有の要因は、ディスクの読取りに影響する要因と類似しています。いずれの場合も、バッファの割当て、スレーブ・プロセスおよび同期I/Oまたは非同期I/Oによってパフォーマンスが左右されます。
SBTデバイスにバックアップする場合、またはそこからリストアする場合、デフォルトでは、テープ書込み用（データをリストアする場合は読取り用）の各チャネルに4つのバッファが割り当てられます。テープI/Oバッファのサイズは、プラットフォームによって異なります。この値は、ALLOCATE CHANNELコマンドまたはCONFIGURE CHANNELコマンドのPARMSパラメータおよびBLKSIZEパラメータで変更できます。
Recovery Managerは、I/Oスレーブが使用されているかどうかに応じて、SGAまたはPGAにテープ・バッファを割り当てます。初期化パラメータBACKUP_TAPE_IO_SLAVES=trueを設定した場合、テープ・バッファはSGAから割り当てられます。テープ・デバイスにアクセスできるのは、一度に1つのプロセスだけです。そのため、テープ・デバイス数に対応する必要な数のスレーブが起動されます。LARGE_POOL_SIZE初期化パラメータも設定されている場合は、ラージ・プールからバッファが割り当てられます。BACKUP_TAPE_IO_SLAVES=falseを設定した場合、バッファはPGAから割り当てられます。
I/Oスレーブを使用する場合、LARGE_POOL_SIZE初期化パラメータを設定し、SGAメモリーをサイズの大きいメモリー割当ての保持専用に確保しておきます。このパラメータによって、SGAメモリーのためにRecovery ManagerのI/Oバッファとライブラリ・キャッシュが競合することを防止できます。テープI/OのI/Oスレーブが要求されたものの、そのために十分な領域がSGAに存在しない場合、スレーブは使用されず、アラート・ログにメッセージが書き込まれます。
BACKUP_TAPE_IO_SLAVESには、スレーブ・プロセスの数ではなく、スレーブ・プロセスを使用するかどうかを指定することに注意してください。テープ・デバイスにアクセスできるのは、一度に1つのプロセスだけであり、Recovery Managerでは、テープ・デバイス数に対応する必要な数のスレーブが使用されます。
SBTチャネルによるデータの読取りまたはテープへの書込みでは、I/Oは常に同期です。テープI/Oでは、（手動または自動で）割当て済の各チャネルは1つのサーバー・プロセスに対応しています。ここでは、このプロセスをチャネル・プロセスと呼びます。
次の図に、テープへのバックアップでの同期I/Oを示します。
次の手順が実行されます。
次の図に、テープへのバックアップでの非同期I/Oを示します。テープへの非同期I/Oは、テープ・スレーブを使用してシミュレートされます。この場合、各割当て済チャネルは1つのサーバー・プロセスに対応しています。この項の説明では、サーバー・プロセスをチャネル・プロセスと呼びます。各チャネル・プロセスに対して1つ（コピーが複数の場合は複数）のテープ・スレーブが起動されます。
次の手順が実行されます。
テープへのバックアップの速度に影響する要因を次に示します。
リモートのテープ・デバイスの場合、メディア・マネージャは、ネットワーク経由でデータを転送する必要があります。たとえば、Oracle Secure Backupの管理ドメインには、ネットワークで接続された複数のクライアント・ホスト、メディア・サーバーおよびテープ・デバイスが含まれていることがあります。あるホストにデータベースがあり、別のホストに出力用のテープ・ドライブが接続されている場合、Oracle Secure Backupがネットワーク経由のデータ転送を管理します。ネットワークのスループットが、バックアップのパフォーマンスの上限になります。
テープ固有の転送レートは、圧縮なしでテープに書き込む場合の速度です。この速度は、バックアップ・レートの上限を表します。バックアップのパフォーマンスの上限は、すべてのテープ・デバイスの転送レートの集計となります。バックアップ操作がすでにそのレートで実行されており、必要以上にCPUを使用していない場合、チューニングしてもRecovery Managerのパフォーマンスは変わりません。
テープの圧縮レベルは、バックアップのパフォーマンスに重大な影響を及ぼします。テープの圧縮レベルが高い場合、持続的なバックアップの転送レートは高くなります。たとえば、圧縮比が2:1で、テープ・ドライブ固有の転送レートが6MB/秒である場合、バックアップ速度は12MB/秒になります。この場合、Recovery Managerは、12MB/秒より高速なスループットでディスクを読み取ることができる必要があり、そうでない場合はこのディスクはバックアップのボトルネックになります。
書込み操作中のテープ・ストリームは、テープへのバックアップ・パフォーマンスに重大な影響を及ぼします。現行のほぼすべての商用テープ・ドライブは、固定速度のストリーム・テープ・ドライブです。そのようなドライブはデータの書込み速度を変更できないため、テープへ書き込むデータがなくなると、テープを減速して停止する必要があります。通常、ドライブのバッファが空になっても、テープの移動が速すぎて書込み終了位置を越えてしまいます。そのためドライブで書込みを継続するには、書込みが終了した位置までテープを巻き戻す必要があります。
物理テープ・ブロック・サイズは、バックアップのパフォーマンスに影響する場合があります。ブロック・サイズは、メディア管理ソフトウェアが、1回の書込み操作でテープに書き込むデータの量です。通常、テープ・ブロック・サイズが大きいほど、バックアップが高速になります。物理テープ・ブロック・サイズは、Recovery ManagerまたはOracle Databaseサーバーではなく、メディア管理ソフトウェアが制御します。詳細は、ご使用のメディア管理ソフトウェアのドキュメントを参照してください。
ディスクへの書込みフェーズに影響する主な要因は、バッファ・サイズです。バックアップの出力がディスクに存在する場合、各チャネルは、1MBずつの出力バッファを4つ割り当てます。ディスク・チャネルが、ディスク・サブシステムにブロックを書き込みます。ファイルをリストアするときの読取りフェーズは、ファイルをバックアップするときの書込みフェーズとほぼ同じです。ただし、ブロックの動く向きは逆です。
ディスクから非同期の読取りが行われる場合は、ディスクへの書込みも非同期になります。ディスクへの書込み時、読取り時と同様にディスクI/Oスレーブを利用できます。
Recovery Managerが、複数のディスクにストライプ化されたディスクベースの出力先にファイルをバックアップする場合は、複数のチャネルを割り当てることができます。チャネルの数は、出力先のストライプ化されたディスクの数に制限されます。ASMは、複数のディスクにストライプ化された出力先の一例です。
通常、チューニング・プロセスを開始する場合は、V$ビューを使用して、Recovery Managerのバックアップ操作およびリストア操作のどこで問題が発生しているかを特定します。
V$SESSION_LONGOPSビューを問い合せると、バックアップ・ジョブおよびリストア・ジョブの進捗状況を監視できます。Recovery Managerは、V$SESSION_LONGOPSで詳細行と集計行の2つのタイプの行を使用します。
詳細行には、1つのジョブ手順によって処理されているファイルの説明が表示され、集計行には、Recovery Managerコマンドのすべてのジョブ手順によって処理されたファイルの説明が表示されます。ジョブ手順とは、1つのバックアップ・セットまたはデータファイルのコピーの作成またはリストアです。詳細行は、バックアップ手順中、バッファに対する読取りまたは書込みが行われるたびに更新されるため、更新の粒度は小さくなります。集計行は、各ジョブ手順の完了時に更新されるため、更新の粒度は大きくなります。
表21-2に、Recovery Managerに最も関連するV$SESSION_LONGOPSの列を示します。通常、各バックアップ・セットの進捗状況を確認するには、集計行ではなく詳細行を表示します。
バックアップ・ジョブまたはリストア・ジョブを実行する各サーバー・セッションは、1つのジョブ手順で必要な処理の合計と比較して、進捗状況をレポートします。たとえば、2つのチャネルを使用してデータベースをリストアし、各チャネルが2つのバックアップ・セットをリストアする場合（合計4セットをリストアする場合）、各サーバー・セッションは、1つのバックアップ・セットにおける進捗状況をレポートします。あるセットのリストアが完了すると、Recovery Managerは、リストアする次のセットでの進捗状況のレポートを開始します。
longops）を作成します。
SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK, ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE" FROM V$SESSION_LONGOPS WHERE OPNAME LIKE 'RMAN%' AND OPNAME NOT LIKE '%aggregate%' AND TOTALWORK != 0 AND SOFAR <> TOTALWORK;
RMAN> RESTORE DATABASE;
longopsスクリプトを実行し、Recovery Managerジョブの進捗状況を確認します。Recovery Managerジョブの実行中に問合せを繰り返すと、次のような出力が表示されます。
SQL> @longops SID SERIAL# CONTEXT SOFAR TOTALWORK %_COMPLETE ---------- ---------- ---------- ---------- ---------- ---------- 8 19 1 10377 36617 28.34 SQL> @longops SID SERIAL# CONTEXT SOFAR TOTALWORK % COMPLETE ---------- ---------- ---------- ---------- ---------- ---------- 8 19 1 21513 36617 58.75 SQL> @longops SID SERIAL# CONTEXT SOFAR TOTALWORK % COMPLETE ---------- ---------- ---------- ---------- ---------- ---------- 8 19 1 29641 36617 80.95 SQL> @longops SID SERIAL# CONTEXT SOFAR TOTALWORK % COMPLETE ---------- ---------- ---------- ---------- ---------- ---------- 8 19 1 35849 36617 97.9 SQL> @longops no rows selected
longopsスクリプトを実行しているときに、%_COMPLETE列の値が増加しない場合は、Recovery Managerで問題が発生しています。詳細は、「Recovery Managerとメディア・マネージャの相互作用の監視」を参照してください。
長時間の作業の実行を頻繁に監視する場合、SQL*Plusを実行するホスト・オペレーティング・システムでシェル・スクリプトまたはバッチ・ファイルを作成して、この問合せを繰り返し実行できます。
バックアップまたはリストアのボトルネックの原因を特定し、バックアップ・ジョブの詳細な進捗を確認するには、V$BACKUP_SYNC_IOビューおよびV$BACKUP_ASYNC_IOビューを使用できます。
バックアップを実行中のプロセス（一部のプラットフォームではスレッド）にI/Oが同期している場合は、
V$BACKUP_SYNC_IOに行が表示されます。I/Oが非同期の場合は、V$BACKUP_ASYNC_IOに行が表示されます。非同期I/Oは、I/Oプロセスによって、または基礎となるオペレーティング・システムがサポートしている場合に実行されます。
データベース・インスタンスが停止するまで、バックアップ・ジョブまたはリストア・ジョブの結果はメモリーに残ります。このため、ジョブの完了後にビューを問い合せることができます。
V$BACKUP_SYNC_IOビューまたはV$BACKUP_ASYNC_IOビューのEFFECTIVE_BYTES_PER_SECOND列を問い合せます。EFFECTIVE_BYTES_PER_SECONDがハードウェアのロー・キャパシティ未満の場合、そのテープはストリーム化されていません。EFFECTIVE_BYTES_PER_SECONDがハードウェアのロー・キャパシティより大きい場合、そのテープはストリーム化されている場合とされていない場合があります。これは、圧縮によって、EFFECTIVE_BYTES_PER_SECONDが実際のI/O速度より高速になる場合があるためです。
同期I/Oでは、すべての同期I/Oがプロセスのボトルネックになるため、特定のボトルネックを識別することは困難です。同期I/Oをチューニングする唯一の方法は、I/Oレート（バイト/秒）をデバイスの最大スループット・レートと比較することです。I/Oレートが、デバイスで指定されているレートより低い場合、バックアップ・プロセスおよびリストア・プロセスのこの側面をチューニングすることを考慮します。
V$BACKUP_SYNC_IOビューのDISCRETE_BYTES_PER_SECOND列を問い合せて、I/Oレートを表示します。V$BACKUP_SYNC_IOにデータが表示されている場合は、非同期I/Oを有効にしていないか、またはディスクI/Oスレーブを使用していないことが問題となっています。
ロング・ウェイトは、バックアップ・プロセスまたはリストア・プロセスが、I/Oが完了するまで待機するようにオペレーティング・システムに通知した回数です。ショート・ウェイトは、バックアップ・プロセスまたはリストア・プロセスがオペレーティング・システム・コールを実行して、非ブロック化モードでI/Oの完了をポーリングした回数です。レディは、I/Oが使用可能な状態になっており、I/Oの完了をポーリングするためにオペレーティング・システム・コールを実行する必要がなかった回数です。
V$BACKUP_SYNC_IOビューのLONG_WAITS列およびIO_COUNT列を問い合せて、I/Oレートを表示します。ボトルネックを特定する最も簡単な方法は、LONG_WAITSをIO_COUNTで割った比率が最も大きいデータファイルを見つける方法です。たとえば、次の問合せを使用できます。
SELECT LONG_WAITS/IO_COUNT, FILENAME FROM V$BACKUP_ASYNC_IO WHERE LONG_WAITS/IO_COUNT > 0 ORDER BY LONG_WAITS/IO_COUNT DESC;
バックアップのパフォーマンスは、多くの要因に影響を受けます。多くの場合、低速なバックアップを改善するには、試行錯誤が伴います。この項では、バックアップで最高のパフォーマンスを得るための手順を順に示します。
この項の内容は、次のとおりです。
「チャネルのRATEパラメータ」で説明されているように、チャネルのRATEパラメータは、他のデータベース操作でより多くのディスク帯域幅を使用できるように、バックアップ・スループットを（増加ではなく）削減するためのパラメータです。バックアップがテープにストリーム配信されていない場合、RATEパラメータを設定していないことを確認してください。
SHOW ALLコマンドを実行して、現在構成されている設定を表示します。
CONFIGURE CHANNELコマンドにRATEパラメータが設定されている場合は削除します。
「同期ディスクI/Oと非同期ディスクI/O」に示されているように、一部のオペレーティング・システムでは、固有の非同期I/Oをサポートしています。ご使用のディスクが非同期I/Oをサポートしない場合にのみ、DBWR_IO_SLAVESを設定します。DBWR_IO_SLAVESに0（ゼロ）以外の値を設定すると、バックアップおよびリストアに固定数のディスクI/Oスレーブが使用され、非同期I/Oがシミュレートされます。
DBWR_IO_SLAVES初期化パラメータを0（ゼロ）以外の値に設定します。DBWR_IO_SLAVESを設定すると、データベース・ライター・プロセスがスレーブを使用します。したがって、PROCESSES初期化パラメータの値を増やす必要がある場合があります。
LARGE_POOL_SIZE初期化パラメータは、メモリー不足のためにI/Oスレーブを起動しないというエラーがアラート・ログに書き込まれた場合に設定します。メッセージの例を次に示します。
ksfqxcre: failure to allocate shared memory means sync I/O will be used whenever async I/O to file not supported natively
ラージ・プールは、Recovery Managerおよびその他の用途に使用されるため、すべてのユーザーに対応できる合計サイズにする必要があります。このことは特に、DBWR_IO_SLAVESが設定されており、DBWRプロセスにバッファが必要な場合に該当します。
V$SGASTAT.POOLを問い合せて、特定のオブジェクト用のメモリーが存在するプール（共有プールまたはラージ・プール）を確認します。
LARGE_POOL_SIZE初期化パラメータを設定します。ALTER SYSTEM SET文を実行して、パラメータを動的に設定します。LARGE_POOL_SIZEを設定するための計算式を次に示します。
LARGE_POOL_SIZE = number_of_allocated_channels *
(16 MB + ( 4 * size_of_tape_buffer ) )
次のいくつかのタスクを実行して、バックアップのパフォーマンスに影響を及ぼすボトルネックを特定および解消できます。
任意のバックアップ・ジョブで出力デバイスまたは入力ディスクI/Oのどちらがボトルネックになっているかを確実に確認する方法の1つは、あるバックアップ・タスクの実行時間と、同じタスクのBACKUP VALIDATEの実行時間を比較することです。バックアップのBACKUP VALIDATEは、実際のバックアップと同じディスク読取りを実行しますが、出力デバイスに対するI/Oは実行しません。
setenv NLS_LANG AMERICAN_AMERICA.WE8DEC; setenv NLS_DATE_FORMAT "MM/DD/YYYY HH24:MI:SS"
BACKUPコマンドでなくBACKUP VALIDATEコマンドを使用するようにバックアップ・スクリプトを編集します。
Starting backup atとFinished backup atに示された時間の差を計算します。
BACKUP VALIDATEコマンドでなくBACKUPコマンドを使用するようにバックアップ・スクリプトを編集します。
Starting backup atとFinished backup atに示された時間の差を計算します。
テープに対するBACKUP VALIDATEの時間が、テープへの実際のバックアップの時間とほとんど変わらない場合は、ディスクからの読取りがボトルネックになっている可能性があります。詳細は、「読取りフェーズのチューニング」を参照してください。
テープに対するBACKUP VALIDATEの時間が、テープへの実際のバックアップの時間より大幅に短い場合は、出力デバイスへの書込みがボトルネックになっている可能性があります。詳細は、「コピーおよび書込みのフェーズのチューニング」を参照してください。
Recovery Managerでは、出力デバイスの占有を継続するのに十分な速度で出力デバイスにデータ・ブロックを送信できないことがあります。たとえば、Recovery Managerは、増分バックアップ中、同じ計画の一環として以前にデータファイルをバックアップした後に変更されたブロックのみをバックアップします。ブロック・チェンジ・トラッキングを有効にしない場合、Recovery Managerは、変更されたブロックを検出するためにデータファイル全体をスキャンし、変更されたブロックを検出しながら出力バッファを一杯にする必要があります。変更されたブロックがほとんどなく、SBTバックアップを行っている場合、Recovery Managerは、テープ・ドライブへのストリームを継続するのに十分な速度で出力バッファを一杯にできないことがあります。
同時に読み取られ、Recovery Managerの同じバックアップ・ピースに書き込まれる入力ファイルの数を表す多重化レベルを調整すると、バックアップのパフォーマンスを向上させることができます。多重化のレベルは、チャネル上のMAXOPENFILES設定および各バックアップ・セット内の入力ファイル数の最小値です。次の表に、多重化のレベルを調整するときの推奨事項を示します。
|
参照:
|
読取りフェーズのパフォーマンスが良好な場合、ボトルネックとなっている可能性が高いのは、コピー・フェーズまたは書込みフェーズです。特に、Recovery Managerが、ストリームをサポートするのに十分な速度でテープ・ドライブにデータ・ブロックを送信しているときにテープがストリーム化されていない場合は、SBTへの書込みフェーズがボトルネックです。次のように、パフォーマンスを向上させます。
増分レベル1のバックアップでは、変更されたブロックのみがデータファイルからテープに書き込まれるため、テープへの書込みに関するボトルネックは、バックアップ計画全体にはあまり影響を及ぼしません。特に、バックアップするデータベースのノードにテープ・ドライブがローカルに接続されていない場合、増分バックアップはより高速になる場合があります。詳細は、「増分バックアップの作成および更新」を参照してください。
BZIP2をバックアップで使用している場合は、圧縮アルゴリズムをBZIP2からZLIBに変更します。ZLIBは、BZIP2ほどCPUに負荷がかかりません。詳細は、「バックアップ圧縮アルゴリズムの構成」を参照してください。
AES128に変更します。AES128アルゴリズムは、最もCPUに負荷がかからない処理です。詳細は、「バックアップ暗号化アルゴリズムの構成」を参照してください。
たとえば、Recovery Managerが、16個の物理ディスクを含む1つのディスク・グループにデータベースをバックアップしている場合は、ディスク・チャネルの数を4〜16の範囲で割り当てるか構成します。
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|