11g リリース1（11.1）
E05764-01
 目次 |
 索引 |
| Oracle Database 2日でデータ・ウェアハウス・ガイド 11g リリース1（11.1） E05764-01 |
|
この項では、データ・ウェアハウスのパフォーマンスを最適化する方法を説明します。また次の項が含まれます。
この項では、システムのオーバーロードを識別して回避する方法を説明します。一般的に、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の説明に従って、自動診断機能である自動データベース診断モニター（ADDM）を使用してデータベースでのパフォーマンスの問題を識別する必要があります。この項では、システムにおけるパフォーマンスの問題を回避する別の方法を説明します。また次の項が含まれます。
この項では、重要なメトリックを定期的に監視することによりシステムのオーバーロードを回避する方法の詳細を提供します。Oracle Enterprise Managerの「データベース・パフォーマンス」ページを介してこれらのメトリックを監視できます。この項の内容は次のとおりです。
この項では、パラレル実行パフォーマンスを監視する方法を説明します。多くのパラレル文がダウングレードされているとします。これは、パフォーマンスの問題を示します。想定よりも低い並列度で文が実行されると大幅に時間がかかり、文がダウングレードされたかどうかによって実行時間が異なります。パラレル文がダウングレードする原因には次のようなものが考えられます。
「パフォーマンス」ページが表示されます。
「PQ」ページが表示されます。次の項目に対してパラレル問合せのパフォーマンス特性が表示されます。
この項では、I/Oパフォーマンスを監視する方法を説明します。システムのスループットがシステム構成に基づいて予想していたものより大幅に低く（第2章「データ・ウェアハウス・システムの設定」を参照）、ユーザーがパフォーマンスに関して不満がある場合は、パフォーマンスに問題があると考えられます。適切に構成されたシステムで通常のデータ・ウェアハウス・ワークロードを処理する場合、単一のI/Oブロックに対して、おおむね良好なI/Oと、待ち時間が比較的少ない（30分以下）が予想されます。
「パフォーマンス」ページが表示されます。
I/Oページが表示され、「ファンクションごとのI/O MB/秒」と「ファンクションごとのI/Oリクエスト数/秒」が表示されます。
次の項目に対してI/O詳細が表示されます。
データベース・リソース・マネージャには、Oracleシステム内の作業に優先度を設定する機能があります。たとえば、優先度の高いジョブのあるユーザーは、オンライン作業のレスポンス時間を最短に抑えるためにリソースを取得する一方、バッチ・ジョブやレポートなどの優先度の低いジョブのあるユーザーに対しては、レスポンス時間が遅くなります。このように優先度を割り当てることにより、リソースをより細かく制御できます。また、コンシューマ・グループに対して、コンシューマ・グループの自動切替え、最大アクティブ・セッションの制御、問合せ実行時間の見積りおよびUNDOプール割当て制限などの機能があります。
各コンシューマ・グループの同時にアクティブなセッションの最大数を指定できます。この制限に到達した場合、データベース・リソース・マネージャにより、すべての後続のリクエストが並べられ、既存のアクティブ・セッションが完了した後にのみそれらが実行されます。
データベース・リソース・マネージャはOracle Databaseの一部で、データベース内部の異なるプロセスを区別できます。結果として、データベース・リソース・マネージャにより、データベース内部で実行されている個別の操作に優先度を割り当てることができます。
データベース・リソース・マネージャを使用して、次のことを実行できます。
索引およびマテリアライズド・ビューを適切に使用することにより、データ・ウェアハウスのパフォーマンスを向上させることができます。SQLアクセス・アドバイザの主な利点は、現行のワークロードを推奨事項の基準として使用できることです。
この例では、特定の索引およびマテリアライズド・ビューを利用しているシステムで実行されているワークロードを所有すると仮定します。
「アドバイザ」ページが表示されます。
「SQLアクセス・アドバイザ」ページが表示されます。
「ワークロード・ソース」ページが表示されます。
「推奨オプション」ページが表示されます。
「スケジュール」ページが表示されます。
「推奨」ページが表示されます。
「確認」ページが表示されます。
「確認」ページが表示されます。
「タスクの結果」ページが表示されます。このページには、可能なコスト改善が表示されます。追加情報は、「推奨」、「SQL文」または「詳細」で表示できます。
データベース・ブロック内の重複値を排除してアーカイブされたデータを圧縮することにより、記憶域要件を削減できます。圧縮可能なデータベース・オブジェクトには、表およびマテリアライズド・ビューが含まれます。パーティション表では、パーティションの一部を圧縮するかまたはすべてのパーティションを圧縮するかを選択できます。圧縮属性は、表領域、表または表のパーティションに対して宣言できます。表領域レベルで宣言された場合、その表領域で作成されたすべての表はデフォルトで圧縮されます。表（またはパーティションまたは表領域）の圧縮属性は変更可能で、その変更はその表に移動する新規データのみに適用されます。この結果、単一の表またはパーティションにはいくつかの圧縮されたブロックといくつかの通常のブロックが含まれます。これにより、圧縮後もデータのサイズが増加しないことが保証されます。圧縮によってブロックのサイズが増加する場合は、圧縮はそのブロックには適用されません。
いくつかのパーティションを圧縮するか、またはパーティション化されたヒープ構成表を作成できます。これを実行するには、完全なパーティション化された表を圧縮対象の表として定義するか、またはパーティション・レベルごとに定義するか、いずれかの定義を行います。特定の宣言のないパーティションは表定義から属性を継承し、表レベルの指定がない場合は表領域定義から継承します。
パーティションを圧縮するかまたは未圧縮のままにするかについての決定は、パーティション化されていない表と同じルールに従います。ただし、範囲の権限およびデータを論理的に個別のパーティションに区切るコンポジット・パーティション化のため、パーティション表などは、主に読取り専用のデータ（パーティション）の圧縮する部分として適切な候補です。たとえばこれは、古いデータが使用不可になる前の中間の段階としてのすべてのローリング・ウィンドウ操作に役立ちます。データを圧縮することにより、より多くの古いデータをオンラインで保持でき、追加の記憶域の使用量の負荷を最小化できます。
また、既存の未圧縮の表パーティションを後で変更したり、新規の圧縮パーティションおよび未圧縮パーティションを追加したり、MERGE PARTITION、SPLIT PARTITIONまたはMOVE PARTITIONなどのデータ移動が必要なパーティション・メンテナンス操作の一部として圧縮属性を変更できます。パーティションにはデータを含めることができ、または空にすることもできます。
一部または完全に圧縮されたパーティション表のアクセスおよびメンテナンスは、完全に未圧縮のパーティション表と同じです。また、完全に未圧縮のパーティション表に適用されたすべてのルールも、一部または完全に圧縮されたパーティション表に対して有効です。
次の例では、1つの圧縮パーティション、costs_oldを使用してレンジ・パーティション化された表を作成します。表の圧縮属性および他のすべてのパーティションは表領域レベルから継承されます。
CREATE TABLE costs_demo ( prod_id NUMBER(6), time_id DATE, unit_cost NUMBER(10,2), unit_price NUMBER(10,2)) PARTITION BY RANGE (time_id) (PARTITION costs_old VALUES LESS THAN (TO_DATE('01-JAN-2003', 'DD-MON-YYYY')) COMPRESS, PARTITION costs_q1_2003 VALUES LESS THAN (TO_DATE('01-APR-2003', 'DD-MON-YYYY')), PARTITION costs_q2_2003 VALUES LESS THAN (TO_DATE('01-JUN-2003', 'DD-MON-YYYY')), PARTITION costs_recent VALUES LESS THAN (MAXVALUE));
|
 Copyright © 2007 Oracle Corporation. All Rights Reserved. |
|
