Blob列を含むテーブルに多くの行を書き込むアプリケーションがあります。 blobの平均サイズは3kバイトです。
どうも。
Oracleでは、LOB(BLOBを含む)は次のように格納されます。
メタリンクのノートID 66431.1はこれについて説明しており、アクセスできる場合は参考になることがあります。
LOBを含むテーブルのCreate table DDLで特定のオプションを指定することにより、LOBのパフォーマンスを調整できます。
例えば.
create table lob_data (id number not null, data lob)
LOB (data) STORE AS (
TABLESPACE lob
INDEX (TABLESPACE lob_indx)
PCTVERSION 0
DISABLE STORAGE IN ROW
CACHE READS NOLOGGING
CHUNK 8192
STORAGE (INITIAL 5M NEXT 5M)
);
ここでは、Lobとlob_indexに別々のテーブルスペースを割り当て、NOLOGGINGオプションも指定しています。また、チャンクサイズを8kに指定し、ストレージパラメータを調整しました。
=======================================編集-kubanczykからのコメントに基づく
おそらくもう少し詳しく説明する必要があったので、ここにいきます。
著者が彼のデータセットへの挿入に関するパフォーマンスの問題を見ているので、私は質問が特に尋ねられると思いました。したがって、デフォルトのチャンクサイズである「ストレージインロー」は、彼が最初に期待するパフォーマンスを提供していませんでした。
NOLOGGINGの提案について警告する必要があったことに同意します。しかし、もう一度言いますが、筆者はソリューションをコピーして貼り付ける前に、著者がもう少し調査することを想定していました。
通常、BLOB/CLOBは外部ソースから取得されるため、データベースは多くの場合、それらのストレージスペースですが、信頼できるソースではありません。つまり、LOBでNOLOGGINGがオンになっていても、データが失われた場合、外部ソースを再処理してデータを再入力できることが前提となっています。
繰り返しますが、これはアプリケーション/デザイン固有の問題です。データが失われた場合にデータを単純に再生成できない場合、NOLOGGINGは問題外です。しかし、「NOLOGGING」オプションを単純に却下するのは不注意なので、私の意見ではARCHIVELOGの長所/短所を認識していないためです。
チャンクサイズについては、平均のBLOBサイズは3Kであり、3Kをはるかに超える多くのBLOBが存在すると私は想定していたという質問です。平均が行内ストレージの上限(つまり4K)に近づいている場合、「行外」ストレージの方がパフォーマンスが向上すると想定するのは当然だと思います。これも考慮してください。今日の平均は3Kになる可能性があります。1年後の平均が5Kの場合、4Kの制限をバイパスし、「行外」のストレージと8Kのチャンクサイズを使用するほうがよいでしょう。 、データサイズの将来的な増加を予測します。
そのため、反対票を投じるのは非常に簡単ですが、これはパフォーマンスに関連する質問であり、「XYZを実行する方法」ではないという事実を踏まえると、私は依然として私の提案を支持します。質問のタイプ。パフォーマンスは簡単なものであり、すべてのオプションの長所/短所をすべて検討する必要があります。パフォーマンスに関連する問題に対して提供できるすべてのタイプの応答に対応できる1つのソリューションはありません。あなたはポインタを提案することができます、そして彼のセットアップに最もよく合うものを見るためにそれは元の作者に任されます。