8 DBAのためのチューニング・ヒント

この章では、Oracle DBAがOracle Multimediaを使用する場合に、マルチメディア・データをデータベースに効率的に格納して管理するための情報およびアドバイスについて説明します。

Oracle Multimediaアプリケーションの目的によって、必要なリソースがどのように割り当てられるかが決まります。アプリケーション開発および設計上の決定事項はパフォーマンスに大きく影響するため、プロジェクトのシステム計画、設計および開発フェーズに標準的なチューニング方法を適用して、本番環境においてOracle Multimediaアプリケーションが最適の結果を得るようにしてください。

マルチメディア・データは、イメージ、オーディオ・クリップ、ビデオ・クリップ、線画など様々なメディア・タイプで構成されます。通常、これらのメディア・タイプはすべてLOBに格納されます。LOBには、内部BLOB（内部データベース表領域内に格納）またはBFILE（データベース表領域外のオペレーティング・システム・ファイル内の外部LOB）のどちらも使用できます。この章では、BLOBに格納されているオーディオ、イメージおよびビデオ・データの管理について説明します。

次の共通事項によって、Oracle Multimedia LOBデータをより効果的に管理することができます。

Oracle Multimedia操作のパフォーマンス・プロファイルの理解（8.1項を参照）
Oracle MultimediaオブジェクトのLOB記憶域パラメータ（8.2項を参照）
データベース初期化パラメータの設定（8.3項を参照）

Oracle Database内のLOBの使用については、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

8.1 Oracle Multimedia操作のパフォーマンス・プロファイルの理解

マルチメディア・データは、データに対して実行可能な操作も含めて、リレーショナル・データベースに一般的に格納されている従来のデータ型とかなり異なります。Oracle Multimedia操作のパフォーマンス・プロファイルに関する基本的な知識は、メディア・パフォーマンス用のデータベースをチューニングする際に、より良い決定を行うのに役立ちます。

次の表に、一般的に実行される一連の操作の一般的なパフォーマンス・プロファイルを示します。各プロファイルには、2つの主要コンポーネントがあります。I/Oパターンは、プライマリ・タイプのI/Oアクセスの一般的な特性、および読取りまたは書込み操作を行うメディア・データ量の一般的な特性です。一部の操作では2つのメディア・オブジェクトを含むため、I/Oパターンをソースのメディア・オブジェクトおよび宛先のメディア・オブジェクトの両方について説明します。2つ目のコンポーネントは、操作のためのCPU使用率のレベルの一般的な特性です。

注意:

これらの表の内容は、一般的な特性およびI/Oパターンについて示します。そのため、CPU使用率は、メディアのフォーマットによって大幅に異なる場合があります。

表8-1に、すべてのOracle Multimediaメディア・タイプに適用される、データのロードおよび取得のプロファイルを示します。

表8-1 すべてのマルチメディア・タイプ用のパフォーマンス・プロファイル

操作	I/Oパターン（ソース）	I/Oパターン（宛先）	I/Oパターン（量）	CPU使用率
新しいメディア・データをデータベースにロードする	なし	順次書込み	すべて	低
メディアをデータベースから取得する	順次読取り	なし	すべて	低

表8-2に、ORDImage型の一般的に使用されるメソッドのプロファイルを示します。

表8-2 ORDImageメソッドのパフォーマンス・プロファイル

オブジェクト・メソッド	I/Oパターン（ソース）	I/Oパターン（宛先）	I/Oパターン（量）	CPU使用率
setProperties( )	順次読取り	なし	メディア・ヘッダー	低から中
getMetadata( )	順次読取り	なし	メディア・ヘッダー	低から中
putMetadata( )	順次読取り	順次書込み	すべて	低から中
process( )	順次読取り	順次書込み	すべて	高
processCopy( )	順次読取り	順次書込み	すべて	高

表8-3に、ORDDicom型の一般的に使用されるメソッドのプロファイルを示します。

表8-3 ORDDicomメソッドのパフォーマンス・プロファイル

オブジェクト・メソッド	I/Oパターン（ソース）	I/Oパターン（宛先）	I/Oパターン（量）	CPU使用率
setProperties( )	順次読取り	なし	メディア・ヘッダー	低から中
extractMetadata( )	順次読取り	なし	メディア・ヘッダー	低から中
writeMetadata( )	順次読取り	順次書込み	すべて	低から中
makeAnonymous( )	順次読取り	順次書込み	すべて	低から中
process( )	順次読取り	順次書込み	すべて	高
processCopy( )	順次読取り	順次書込み	すべて	高

表8-4に、ORDAudio型およびORDVideo型の一般的に使用されるメソッドのプロファイルを示します。

表8-4 ORDAudioメソッドおよびORDVideoメソッドのパフォーマンス・プロファイル

オブジェクト・メソッド	I/Oパターン（ソース）	I/Oパターン（宛先）	I/Oパターン（量）	CPU使用率
setProperties( )	順次読取り	なし	メディア・ヘッダー	低
getProperties( )	順次読取り	なし	メディア・ヘッダー	低

8.2 Oracle MultimediaオブジェクトのLOB記憶域パラメータの選択

表の作成中にLOB記憶域属性を指定するための選択は、メディアのロード、取得および処理操作のパフォーマンスに大きな影響を与えます。この項では、考慮すべき最も重要なオプションについて説明し、Oracle Multimedia操作のパフォーマンス・プロファイルがどのようにLOB記憶域パラメータの選択に影響するかを示します。LOBの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

8.2.1 SecureFile LOBおよびBasicFile LOB

SecureFile LOB（SecureFiles）は、SQLパラメータのBASICFILEで識別される元のBasicFile LOBの実装を補完するために、Oracle Database 11g リリース1（11.1）で導入されました。SecureFile LOBのパフォーマンスは、特に大規模なメディア・データの場合に、BasicFile LOBのパフォーマンスより大幅に優れています。可能であれば、メディア・データを格納するためにSecureFile LOBを使用することをお薦めします。SecureFile LOBは、SQLパラメータのSECUREFILEを指定することで識別されます。

8.2.2 表領域

LOBを含む表に使用される表領域ではなく、異なる表領域でLOB記憶域を指定することによって、LOBの最適なパフォーマンスを実現できます。多くの異なるLOBが頻繁にアクセスされる場合も、デバイスでの競合を避けるために、各LOB列または属性に個別の表領域を指定します。

8.2.3 CACHE、NOCACHEおよびCACHE READS

CACHEオプションは、STORE AS句の一部であり、LOBページがバッファ・キャッシュに格納されているかどうかを決定します。

オプションに値CACHEがあると、複数のユーザー間で共有可能なバッファ・キャッシュにLOBページが格納されます。時間が経過し、LOBページがアクセスされなくなった場合、最終的にLOBページはバッファ・キャッシュから削除されます。
値NOCACHEの場合、LOBページはバッファ・キャッシュに格納されません。
値CACHE READSの場合、LOBページは読取り操作用のキャッシュにのみ格納されます。

アプリケーションがメディア・オブジェクトに対して複数の読取り操作を実行する場合（setProperties( )メソッドを起動し、縮小イメージを生成する場合など）は、ソース・メディア・オブジェクトの読取りキャッシュを有効にしてください。

8.2.4 LOGGINGおよびNOLOGGING

ロギング・オプションは、STORE AS句の一部であり、LOBの更新時にREDOデータがログされるかどうかを決定します。NOLOGGING（またはLOGGING）句が省略されると、NOLOGGINGおよびLOGGINGが指定されず、表または表パーティションのロギング属性は、デフォルトで表または表パーティションが存在する表領域のロギング属性に設定されます。

CACHEオプションの指定方法によって異なる別のロギング属性があります。

CACHEが指定され、NOLOGGING（またはLOGGING）が省略されると、自動的にLOGGINGが付けられます（CACHE NOLOGGINGを指定できないため）。
CACHEが指定されず、NOLOGGING（またはLOGGING）が省略されると、NOLOGGING（またはLOGGING）値はLOBセグメントが存在する表領域から取得されます。

メディア・リカバリを必要としない場合にのみ、NOLOGGINGを使用してください。ただし、ディスク、テープまたはストレージ・メディアに障害が発生した場合、変更は記録されないため、ログから変更をリカバリすることはできません。

NOLOGGINGは、メディア・データのバルク・ロードに役立ちます。たとえば、LOBにデータをロードするときに、REDO操作を必要とせず、ロードに失敗した場合にロードを簡単に再開できる場合は、LOBデータ・セグメントの記憶特性をNOCACHE NOLOGGINGに設定します。このオプションによって、データの初期ロードのパフォーマンスが向上します。

データのロードが完了すると、必要に応じて、ALTER TABLE文を使用して、LOBデータ・セグメントのLOB記憶特性を、通常のLOB操作（CACHE、NOCACHE LOGGINGなど）に変更できます。

注意:

Oracle Data Guard Redo Applyテクノロジでは、ロギングを使用してスタンバイ・データベースに移入します。このため、Data GuardテクノロジでNOLOGGINGを指定しないでください。

8.2.5 CHUNK

CHUNKオプションは、BasicFile LOBにのみ適用します。CHUNKオプションは、STORE AS句の一部であり、LOBデータ記憶域の最小単位のサイズを示します。CHUNKは、ブロック・サイズの整数倍の値であり、最大値が32KBである必要があります。

大きいチャンクを使用すると、LOBへのアクセスをより効果的に行うことができます。ほとんどの場合32KBより大きいメディア・オブジェクトを最も効率的に格納するには、最大値の32KBを選択します。

8.2.6 LOB記憶域オプションの設定例

この項では、Oracle Multimedia操作のパフォーマンス・プロファイル（8.1項の表8-1から8-4を参照）を使用したLOB記憶域オプションの使用方法を示す簡単な例について説明します。

この例では、企業Xがデジタル・イメージのアーカイブを作成するとします。アーカイブでは、元のイメージの最大解像度のコピーを格納します。また、インターネットに対応し、元のイメージのスケールが縮小されたJPEGフォーマットのものを2つ格納します。1つは元のサイズの50%、もう1つは元のサイズの25%です。データベース・チームは、SQL*Loaderユーティリティを使用して、すべての初期イメージをバルク・ロードすることを計画します。その後、PL/SQLプログラムを使用して、イメージ・データを初期化します。初期化は、元のイメージのプロパティ設定およびスケール変更されたイメージの生成で構成されます。初期化後、表は主要なアプリケーション用に準備されます。これは、Webベースのユーザーのためにイメージを取得します。

次に、イメージを格納するための表定義を示します。表では、表領域tbs2のSecureFilesを使用して、バイナリ・イメージ・データが格納されます。他のすべての表データは、表領域tbs1に格納されます。

create table images(id        integer primary key,
                    original  ordsys.ordimage,
                    scale50   ordsys.ordimage,
                    scale25   ordsys.ordimage)
tablespace tbs1
lob(original.source.localdata)store as secureFile (tablespace tbs2)
lob(scale50.source.localdata)store as secureFile (tablespace tbs2)
lob(scale25.source.localdata)store as secureFile (tablespace tbs2);

表が作成されると、イメージ・データをロードすることができます。イメージ・データをロードすると、順次書込みのパターンがLOBに生成されます。ロード操作中にアプリケーションはデータを読み込まないため、データをキャッシュする必要はありません。また、ロードされる列のロギングを無効にすることによって、ロード・パフォーマンスを向上させることもできます。次のコマンドでは、表を動的に変更して、ロードするために元のイメージ列LOBを準備します。

alter table images modify lob(original.source.localdata) (nocache nologging);

ロードした後、次に、original列のイメージのプロパティを設定し、scale50列およびscale25列に格納されるスケール変更されたイメージ・データを生成します。この手順では、ソース・イメージを完全に2回読み込み、スケール変更されたソース・イメージを生成します。生成されたスケール変更されたイメージは、書き込まれますが、読み込まれません。次のコマンドでは、表を動的に変更して、ソース・イメージの読込みキャッシュを有効にし、宛先イメージのキャッシュおよびロギングを無効にします。

alter table images modify lob(original.source.localdata) (cache reads);
alter table images modify lob(scale50.source.localdata) (nocache nologging);
alter table images modify lob(scale25.source.localdata) (nocache nologging);

originalイメージのプロパティを設定し、スケール変更されたイメージを生成するプログラムを実行した後、Webブラウザでイメージを表示するユーザーのためにイメージを取得する主要アプリケーション用にLOB記憶域属性を最適化できます。アーカイブには数百万のイメージが含まれているため、ユーザーが同時に同じイメージを表示するとは考えられません。このため、イメージ・データをキャッシュするメリットはほとんどありません。次のコマンドでは、LOBのロギングを再度有効にし、キャッシュを無効にします。

alter table images modify lob(original.source.localdata) (nocache logging);
alter table images modify lob(scale50.source.localdata) (nocache logging);
alter table images modify lob(scale25.source.localdata) (nocache logging);

8.3 データベース初期化パラメータの設定

8.2項では、列レベルでLOBデータのロギングを無効にし、REDOログへのI/Oの量を削減できることをできることを示します。ただし、ロギングを無効にできない場合、追加のデータベース・チューニングが必要になる場合があります。具体的には、ロード・プロセスが待機状態になることを防ぐために、REDOログ・バッファのサイズを増やす必要がある場合があります。

初期化パラメータLOG_BUFFERには、REDOエントリをREDOログ・ファイルにバッファリングするときに使用されるメモリー容量を、バイト単位で指定します。REDOログ・エントリには、データベース・ブロック・バッファに対する変更の記録が含まれています。LGWRプロセスは、ログ・バッファからREDOログ・ファイルにREDOログ・エントリを書き込みます。

REDOログ・データが、LGWRプロセスがREDOログ・データをディスクに書き込むより高速にREDOログ・バッファに書き込まれると、バッファは一杯になり、領域が利用できるまでユーザー・セッションは強制的に待機させられます。待機イベント「log buffer space」は、セッションがREDOログ・バッファ内の領域を待機した回数を示します。V$SYSTEM_EVENT動的ビューでこのイベントを監視して、セッションがログ・バッファの領域を待機した回数を把握します。セッションがログ・バッファの領域を頻繁に待機する場合、LOG_BUFFER初期化パラメータの値を大きくすることを考慮します。

データベース初期化パラメータの設定に関する包括的な情報は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Databaseリファレンス』を参照してください