• 検索結果がありません。

ファイル・システムを使用してすべてのOracleデータを取り込むシステムの場合、データベー

ス管理はOracle Managed Filesを使用して簡単に行えます。表領域、テンポラリ・ファイル、

オンライン・ログおよび制御ファイルについては、Oracleは内部的に標準ファイル・システ ム・インタフェースを使用して、必要に応じてファイルを作成および削除します。管理者は、

特定のタイプのファイルに使用するファイル・システム・ディレクトリのみを指定します。

データファイルについてはデフォルトの場所を1つ、制御ファイルおよびオンラインREDOロ グ・ファイルについては複数の場所を最大5つ指定できます。

Oracleでは、一意のファイルが作成された後、そのファイルが不要になると削除されます。こ

のため、管理者が誤ったファイルを指定したことにより発生する破損、および廃止されたファ イルで消費される無駄なディスク領域が減り、テスト・データベースおよび開発データベース の作成が簡素化されます。また、オペレーティング・システム固有のファイル名をSQLスクリ プトに設定する必要がないため、ポータブルなサード・パーティのツールの開発を容易にしま す。

新しいファイルは管理ファイルとして作成できますが、古いファイルは古い方法で管理されま す。したがって、データベースにはOracle Managed Filesと手動管理ファイルの両方を配置で きます。

Oracle Managed Files のチューニング のチューニング のチューニング のチューニング

Oracle Managed Filesをチューニングする場合はいくつかの点に注意する必要があります。

Oracle Managed Filesではファイル・システムを使用する必要があるため、DBAはデータ

のレイアウト方法は管理しません。したがって、ファイル・システムを正しく構成するこ とが重要です。

Oracle Managed Filesシステムは、ストライプ化をサポートするLVM上に構築する必要が

あります。ロード・バランシングおよびスループットの向上のために、Oracle Managed

Filesシステム内のディスクをストライプ化する必要があります。

Oracle Managed Filesは、動的に拡張可能な論理ボリュームをサポートするLVM上で使用

するときに最高の機能を発揮します。それ以外の場合は、論理ボリュームをできるだけ大 きく構成する必要があります。

Oracle Managed Filesは、ファイル・システムに大きな拡張可能なファイルがある場合、

最高の機能を発揮します。

注意注意

注意注意: Oracle Managed Filesは、RAWデバイスでは使用できません。

関連項目 関連項目 関連項目

関連項目: Oracle Managed Filesの使用方法の詳細は、『Oracle Database

管理者ガイド』を参照してください。

データ・ブロック・サイズの選択 データ・ブロック・サイズの選択 データ・ブロック・サイズの選択 データ・ブロック・サイズの選択

8KBのブロック・サイズはほとんどのシステムにとって最適です。ただし、OLTPシステムで はより小さなブロック・サイズを、DSSシステムではより大きなブロック・サイズを使用する ことがあります。この項では、最適なパフォーマンスを得るためにデータベース・ブロック・

サイズを選択するときの考慮事項を説明します。

読込み 読込み 読込み 読込み

データのサイズとは関係なく、目標は必要なデータを取り出すために必要な読込み回数を最小 にすることです。

行が小さく、アクセスがきわめてランダムな場合は、小さなブロック・サイズを選択しま す。

行が小さく、アクセスがきわめて順次である場合は、大きなブロック・サイズを選択しま す。

行が小さく、アクセスがランダムかつ順次である場合は、大きなブロック・サイズを選択 するのが有効です。

行が大きい(たとえば、ラージ・オブジェクト(LOB)データが含まれている)場合は、

大きなブロック・サイズを選択します。

書込み 書込み 書込み 書込み

同時実行性の高いOLTPシステムで、大きなブロック・サイズを使用する場合は、INITRANS、 MAXTRANSおよびFREELISTSの適切な値について検討します。これらのパラメータは、ブ ロック内で許可されている更新の同時実行性の程度に影響を与えます。ただし、自動セグメン ト領域管理を使用する場合は、FREELISTSの値を指定する必要はありません。

選択する必要があるブロック・サイズが不明な場合、多数のトランザクションを処理するシス テムでは、8KBのデータベース・ブロック・サイズを試行してください。これは優れた妥協案 であり、通常は有効です。8KBを超えるサイズが必要なのはLOBデータを処理するシステムの みです。

注意注意

注意注意: 管理性の問題があるため、単一データベース・インスタンスでの 複数のブロック・サイズの使用はお薦めしません。

関連項目 関連項目 関連項目

関連項目: 使用しているプラットフォームの最小および最大のブロック・

サイズは、オペレーティング・システム固有のOracleマニュアルを参照 してください。

ブロック・サイズの長所と短所 ブロック・サイズの長所と短所 ブロック・サイズの長所と短所 ブロック・サイズの長所と短所

表8-3に、様々なブロック・サイズの長所と短所を示します。

表 表 表

表 8-3 ブロック・サイズの長所と短所ブロック・サイズの長所と短所ブロック・サイズの長所と短所ブロック・サイズの長所と短所 ブロック・サイズ

ブロック・サイズ ブロック・サイズ

ブロック・サイズ 長所長所長所長所 短所短所短所短所 小さい 行数が少なく大量のランダム・アクセス

に適しています。

ブロック競合が低減されます。

メタデータ(すなわち、ブロック・ヘッダー)によ る比較的大きな領域のオーバーヘッドがあります。

行が大きい場合にはお薦めできません。1行がブロッ クに収まらない場合、1ブロック当たりの格納行数が わずかになったり、さらには行の連鎖が発生する可 能性があります。

大きい オーバーヘッドが少ないため、データを 格納する空間が多くなります。

1回のI/Oでバッファ・キャッシュに多 数の行を読み込めます(行サイズおよび ブロック・サイズにより異なります)。

順次アクセスまたは非常に大きな行

(LOBデータなど)に適しています。

ブロック・サイズが大きい場合に少数の行にランダ ム・アクセスすると、バッファ・キャッシュ内の領 域が消費されます。たとえば、8KBのブロック・サ イズと50バイトの行サイズでは、ランダム・アクセ スを行うときにバッファ・キャッシュ内の7,950バイ トが消費されます。

OLTP環境で使用される索引ブロックには適しませ ん。これは、索引リーフ・ブロック上のブロック競 合が増えるためです。

9

オペレーティング・システム・リソース オペレーティング・システム・リソース オペレーティング・システム・リソース オペレーティング・システム・リソース

この章では、Oracleデータベース・サーバーのパフォーマンスを最適化するためにオペレー ティング・システムをチューニングする方法を説明します。

この章には次の項があります。

オペレーティング・システムのパフォーマンスの問題の理解

オペレーティング・システムの問題の解決

CPUについて

システムのCPU使用率の調査 関連項目

関連項目 関連項目 関連項目:

プラットフォーム固有のチューニング情報は、使用しているプラット フォーム固有のOracleのマニュアルを参照してください。また、使 用しているオペレーティング・システム・ベンダーのマニュアルも参 照してください。

オペレーティング・システム統計情報の重要性の詳細は、5-5ページ の「オペレーティング・システム統計」を参照してください。

オペレーティング・システムのパフォーマンスの問題の理解 オペレーティング・システムのパフォーマンスの問題の理解 オペレーティング・システムのパフォーマンスの問題の理解 オペレーティング・システムのパフォーマンスの問題の理解

オペレーティング・システムのパフォーマンスの問題は、一般にプロセス管理、メモリー管理 およびスケジューリングに関係します。Oracleインスタンスをチューニングした後で、さらに パフォーマンスを改善する必要がある場合は、作業方法を検証するか、システム時間の短縮を 試行してください。I/O帯域幅、CPU能力およびスワップ・スペースが十分にあることを確認 してください。ただし、オペレーティング・システムをさらにチューニングしても、それがア プリケーションのパフォーマンスに大きな効果を与えることは期待できません。単にオペレー ティング・システムをチューニングするよりも、Oracleの構成またはアプリケーションを変更 する方が、結果的にオペレーティング・システムの効率が大きく変わります。

たとえば、アプリケーションでbuffer busy waitsが非常に頻繁に発生する場合は、システム・

コールの回数が増加します。アプリケーションをチューニングすることでbuffer busy waitsを 削減すると、システム・コールの数が減少します。

この項では、オペレーティング・システムのパフォーマンスの問題に関する次の項目について 説明します。

オペレーティング・システムのキャッシュの使用

メモリー使用量

オペレーティング・システムのリソース・マネージャの使用

オペレーティング・システムのキャッシュの使用 オペレーティング・システムのキャッシュの使用 オペレーティング・システムのキャッシュの使用 オペレーティング・システムのキャッシュの使用

オペレーティング・システムとデバイス・コントローラが提供するデータ・キャッシュは、

Oracleのキャッシュ管理と直接は衝突しません。ただし、パフォーマンスにほとんど利益にな

らないですし、これらの構造ではリソースが消費されます。このことは、UNIXファイル・シ ステムにデータベース・ファイルがあるUNIXシステムで最も顕著です。デフォルトでは、す べてのデータベースI/Oはファイル・システム・キャッシュ内を通過します。一部のUNIXシ ステムでは、ファイル・システムへの直接I/Oが使用可能です。これによって、データベー ス・ファイルは、ファイル・システム・キャッシュをバイパスしてUNIXファイル・システム 内でアクセスできます。これによってCPUリソースを節約でき、ファイル・システム・キャッ シュを、プログラム・テキストやスプール・ファイルなどのデータベース以外のアクティビ ティ専用にできます。

この問題はWindowsでは発生しません。データベースから要求されたファイルは、すべて ファイル・システム内のキャッシュをバイパスします。

Oracleバッファ・キャッシュのバッファ・ブロックの存在により、オペレーティング・システ

ムのキャッシュは冗長になる場合がありますが、OracleがOracleバッファ・キャッシュを使用 しないこともよくあります。このような場合に、UNIXまたはオペレーティング・システムの キャッシュがバイパスされる直接I/O、またはオペレーティング・システムのキャッシュが使 用されないRAWデバイスを使用すると、オペレーティング・システムのバッファリングを使 用したときより、パフォーマンスが劣化することがあります。これには次のような例がありま す。

一時表領域での読込みまたは書込み

NOCACHE LOBに格納されるデータ

パラレル問合せスレーブで読み込まれるデータ

オペレーティング・システム・レベルでキャッシュするファイルと、キャッシュしないファイ ルを混在させる必要がある場合があります。

関連したドキュメント