Db2での XML パフォーマンスのベスト・プラクティス
特定のベストプラクティスを実践することで、 Db2 for z/OS® に保存されているXMLデータのパフォーマンスを向上させることができます。
XML 文書の細分度の慎重な選択
XML アプリケーション、特に XML 文書の構造を設計する場合、1 つの XML 文書にまとめて保持するビジネス・データを選択できる場合があります。
例えば、サンプルの部門データの各 XML 文書には、1 つの部門の情報が含まれています。
CREATE TABLE DEPT(UNITID CHAR(8), DEPTDOC XML);| unitID | deptdoc |
|---|---|
| WWPR | |
| WWPR | |
| S-USE | ... |
| ... | ... |
この中間的な細分度を選択することは、アプリケーションによるデータのアクセスおよび処理の細分度が、ほとんど部門単位である場合に適切です。 また、複合的な部門 (1 つの組織単位に複数の部門が所属する場合など) を 1 つの XML 文書に結合するように決める場合もあります。 ただし、このように細分度を粗くすることは、アプリケーションが通常一度に 1 つの部門のみを処理する場合は、次善策となります。
各従業員に「部門」属性を加えてその従業員が所属する部門を示し、従業員別に 1 つの XML 文書にすることも 選択できます。 このような精細な細分度は、従業員が重要なビジネス目標を使用し、その目標を同じ部門内の他の従業員が自由にアクセスおよび処理する頻度が高い場合、非常に適切な選択になります。 ただし、アプリケーションが、通常 1 つの部門の全従業員を処理する場合は、部門ごとに 1 つの XML 文書にするのが、より適切な選択になります。
XML での属性と要素の適切な使用方法
XML 文書の設計でよくある質問は、 どのような場合に要素の代わりに属性を使用するのか、またその選択がパフォーマンスにどのように影響するかです。
これは、パフォーマンスより、データのモデリングに非常に強く関わる質問です。 ただし、原則として、XML 要素は繰り返しとネストが可能なため、属性より柔軟性があります。
例えば、 前述の例の部門文書では、要素「phone」を使用することによって、複数の電話番号を持つ 1 人の従業員について、複数の「phone」のオカレンスが可能になります。 この設計は、後で電話番号を、例えば国別コード、市外局番、内線などの子要素に小さく分割することが必要になった場合にも、拡張が可能です。
対照的に「phone」を要素でなく従業員要素の属性にすると、 1 人の従業員に付加できるのは 1 つだけで、子要素は追加できません。 このような制約によって、将来スキーマを展開できなくなる場合があります。
多くの場合、すべてのデータは属性を使用しなくても モデル化できますが、1 つの要素に対して繰り返しがなく、サブフィールドもないことがわかっているデータ項目に対して属性を使用することは、非常にわかりやすい選択です。 要素には開始タグと終了タグの両方がありますが、それに対して属性は 1 対の名前と値だけで 済むため、XML データのサイズを若干縮小することができます。
Db2では、エレメントと同じように、照会、述部および索引定義の属性を使用することができます。 属性はエレメントよりも拡張性が低いため、Db2は特定のストレージを適用し、最適化にアクセスできます。 ただし、これらの利点は、パフォーマンスのために要素を属性に変換することを促すものではなく、データ・モデリングを検討すると要素が必要になる場合は特に、パフォーマンス向上という予期せぬメリットとみなすべきものです。
XML スキーマ検証のオーバーヘッドの認識
XML スキーマ検証は、 XML 構文解析でオプションのアクティビティーです。 パフォーマンスの検討を行った結果、スキーマ検証を使用可能にすると、 一般的に XML 構文解析時にはスキーマ検証の未使用時よりも CPU を著しく集中的に使用することが示されています。
このオーバーヘッドは、 XML 文書の構造とサイズ、特に使用する XML スキーマのサイズと複雑さによって大幅に変動します。 例えば、中程度に複雑なスキーマでスキーマ検証すると、CPU 使用量が 50% 増加する場合もあります。 XML の挿入が入出力に大きく制約されていない限り、通常 CPU 使用量が増加することによって 挿入のスループットは減少します。
XML スキーマは、XML 文書のセットで許容される、構造、 要素と属性、データ・タイプ、および値の範囲を定義します。 Db2 XML文書をXMLスキーマに対して検証することができます。 文書の検証を選択すると、検証は通常挿入時に行われます。 検証を行うと、データベースに挿入されるデータは確実にスキーマ定義に準拠するため、表に入力されるデータの保全性が向上します。
XML 照会と XML スキーマの準拠を確認するための型検査をさらに厳密に行うことがアプリケーションで必要かどうかを判断する場合、パフォーマンスへの影響を考慮してください。 例えば、XML文書がデータベースに保管される前に、XML文書を受信、検証および処理するアプリケーション・サーバーを使用している場合、おそらくDb2で文書を再度検証する必要はありません。 その時点で、文書が有効なことは既に認識されているからです。 同様に、データベースが、信頼できるアプリケーション、例えばユーザーが制御するアプリケーションから XML 文書を受け取り、その XML データは常に有効なことがわかっている場合、スキーマ検証を回避して、挿入のパフォーマンス向上という効果を得ることができます。 ただし、Db2データベースが信頼されていないソースからXMLデータを受信し、Db2レベルでスキーマの準拠性を確保する必要がある場合、それに対して余分なCPUサイクルを費やす必要があります。
詳しくは、以下を参照してください。
可能な場合の XPath 式での絶対パスの指定
要素が XML 文書の構造のどこにあるかわかっている場合、パスを完全に指定したフォームで情報を提供し、不要なオーバーヘッドを回避します。
次の SQL ステートメントによって作成された表を検討してください。
CREATE TABLE customer(info XML);次の図に、情報列のサンプル・データを示します。
<customerinfo Cid="1004">
<name>Matt Foreman</name>
<addr country="Canada">
<street>1596 Baseline</street>
<city>Toronto</city>
<state/>Ontario
<pcode>M3Z-5H9</pcode>
</addr>
<phone type="work">905-555-4789</phone>
<phone type="home">416-555-3376</phone>
</customerinfo>顧客の電話番号または所在する市を検索する場合、 データを取得するために使用できるパス式は複数あり、その中から選択できます。
/customerinfo/phone および //phone のいずれでも電話番号を取得できます。 同様に、/customerinfo/addr/city および /customerinfo/*/city のいずれも市を戻します。 最高のパフォーマンスを得るには、 * または // を使用するよりも、完全なパスを指定することが推奨されます。完全なパスを指定することで、 Db2 が直接要素に移動し、ドキュメントの関連性のない部分をスキップすることができるからです。 /customerinfo/phone でなく //phone と要求すると、
文書内のすべての場所から電話番号を要求することになります。 そのため、 Db2 は、ドキュメントの任意のレベルにあるphone要素を探すために、ドキュメントの「addr」サブツリーに移動する必要があります。
* および // を使用すると、予期しない照会結果になる場合があります (例えば、次の図に示すように、「customerinfo」文書の中に「assistant」情報も含む文書がある場合)。 パス //phone では、顧客の電話番号とアシスタントの電話番号が、区別されずに戻されます。 照会結果から、アシスタントの電話番号を顧客の電話番号として誤って処理するおそれがあります。
<customerinfo Cid="1004">
<name>Matt Foreman</name>
<addr country="Canada">
<street>1596 Baseline</street>
<city>Toronto</city>
<state/>Ontario
<pcode>M3Z-5H9</pcode>
</addr>
<phone type="work">905-555-4789</phone>
<phone type="home">416-555-3376</phone>
<assistant>
<name>Peter Smith</name>
<phone type="home">416-555-3426</phone>
</assistant>
</customerinfo>XML データに対する無駄のない索引定義による余分なオーバーヘッドの回避
"customerinfo" XML 文書を顧客名で検索する照会が多いと想定します。 次のステートメントに示すように、顧客名要素に索引があれば、 このような照会のパフォーマンスを大幅に改善できます。
CREATE TABLE CUSTOMER (info XML);
CREATE INDEX custname1 ON customer(info)
GENERATE KEY USING XMLPATTERN '/customerinfo/name' as sql varchar(20);
CREATE INDEX custname2 ON customer(info)
GENERATE KEY USING XMLPATTERN '//name' as sql varchar(20);
SELECT * FROM customer
WHERE XMLEXISTS('$i/customerinfo[name = "Matt Foreman"]' passing info as $i);上に定義された索引は両方とも、顧客名で XMLEXISTS 述部を評価する場合の対象になります。 ただし、custname2 索引は顧客名の索引エントリーだけでなく、アシスタント名の索引エントリーも含むため、
custname1 索引より大幅に大きくなる可能性があります。 これは、XML パターン //name は、文書内のどこでも
名前要素に一致するからです。 ただし、アシスタント名で検索することがまったくなければ、
その名前に索引を付ける必要はありません。
読み取り操作の場合、custname1 索引のほうが小さく、したがって早く実行できる可能性があります。 挿入、更新および削除操作の場合、 custname1 索引は顧客名についてのみ保守のオーバーヘッドがかかりますが、 custname2 索引は顧客名とアシスタント名について索引の保守が必要です。 挿入、更新、および削除のパフォーマンスを最大にする必要があり、アシスタント名に基づいて索引によるアクセスは必要ない場合に、余計なコストをかけたくないことは明らかです。
詳しくは、以下を参照してください。
文書レベルでフィルター操作する 述部用 XMLEXISTS の使用
次の表とサンプル・データを検討します。
CREATE TABLE customer(info XML);<customerinfo>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
<customerinfo>
<name>Peter Jones</name>
<phone>905-123-9065</phone>
</customerinfo>
<customerinfo>
<name>Mary Clark</name>
<phone>905-890-0763</phone>
</customerinfo>例えば、電話番号が "905-555-4789" の顧客名を戻したいとします。 多くの場合、次のような照会を作成してしまいます。
SELECT XMLQUERY('$i/customerinfo[phone = "905-555-4789"]/name' passing info as "i")
FROM customer;しかしながら、次のようにいくつかの理由で、この照会ではお客様が求める結果は得られません。
- 次のように、表に含まれる行と同数の行の結果セットが戻されます。 これは、SQL ステートメントに WHERE 文節がなく、したがって
行を全く除去できないことによります。 結果を次の図に示します。
図 5. 前記の照会例の結果 <name>Matt Foreman</name> 3 record(s) selected - 述部と一致しない表内の各行に対して、空の XML シーケンスを含む行が戻されます。 これは、XMLQUERY 関数の XQuery 式が一度に 1 つの行、または文書に適用され、 行が結果セットから除去されることがなく、その値のみ変更されることによります。 その XQuery によって作成される値は、述部が真の場合は顧客名要素、そうでない場合は空のシーケンスです。 これらの空の行は、SQL/XML 規格に従えば意味論として正しく、示されているように照会を作成すれば必ず戻されます。
- 照会のパフォーマンスが低下します。 まず、 この照会は行の除去ができないため、/customerinfo/phone に索引が作成されていても使用できません。 次に、この照会は多数の空の行を戻すため、無用な時間がかかります。
パフォーマンスの問題を解決して必要な出力を取得するには、SELECT 文節で XMLQUERY 関数を使用して顧客名のみを抽出し、行を除去する検索条件を WHERE 文節の XMLEXISTS 述部に移動します。 このようにすると、索引の使用と 行のフィルター操作が可能になり、さらに空の結果行によるオーバーヘッドを回避できます。 この照会は次に示すようになります。
SELECT XMLQUERY('$i/customerinfo/name' passing info as "i")
FROM customer
WHERE XMLEXISTS('$i/customerinfo[phone = "905-555-4789"]' passing info as "i")詳しくは、以下を参照してください。
大括弧使用による XMLEXISTS のブール述部の回避
次の照会に示すように、XMLEXISTS 関数で前記の照会を、誤って大括弧を使用しないで 作成することがよくあります。
SELECT XMLQUERY('$i/customerinfo/name' passing info as "i")
FROM customer
WHERE XMLEXISTS('$i/customerinfo/phone = "905-555-4789"' passing info as "i")このように照会を作成すると、 結果は次に示すようになります。
<name>Matt Foreman</name>
<name>Peter Jones</name>
<name>Mary Clark</name>
3 record(s) selectedXMLEXISTS 述部の式は、XMLEXISTS が常に真と評価するように作成されています。 このため、 除去される行はありません。 ある行に対して、XMLEXISTS 述部は 内部の XQuery 式が空のシーケンスを戻した場合のみ、偽と評価します。 ただし、大括弧がなければ XQuery 式はブール式になって常にブール値を戻し、空のシーケンスを戻すことはありません。 注意が必要なのは、 XMLEXISTS は値の存在を正しく確認し、値がブール値の「偽」であっても、値が存在すれば真と評価することです。 これは、ユーザーの意図ではないにしても、SQL/XML 規格に従った正しい動作です。
繰り返しますが影響は、除去される行がないため電話の索引を使用できず、 実際に必要な行よりはるかに多数の行を受け取ることです。 また複数の述部を使用する場合も、次の照会に示すように同じ誤りをおかさないように注意してください。
SELECT XMLQUERY('$i/customerinfo/name' passing info as "i")
FROM customer
WHERE XMLEXISTS('$i/customerinfo[phone = "905-555-4789"] and
$i/customerinfo[name = "Matt Foreman"]'
passing info as "i")ここでも XQuery 式は "exp1 and exp2" のフォームになっていることから、ブール式です。 行をフィルター操作し、索引の使用を可能にするように作成した照会は、 次に示すようになります。
SELECT XMLQUERY('$i/customerinfo/name' passing info as "i")
from customer
WHERE XMLEXISTS('$i/customerinfo[phone = "905-555-4789" and name = "Matt Foreman"]'
passing info as "i")詳細は、「論理式」 を参照してください。
RUNSTATS の使用による XML データおよび索引に関する統計の収集
XML表および索引に関する統計を収集するためにRUNSTATSユーティリティーが拡張され、Db2オプティマイザーは、これらの統計を使用して、 XML照会のための効率的な実行プランを生成します。 したがって RUNSTATS を、リレーショナル・データで使用するように XML 表と索引でも継続して使用してください。 XML 表の統計を取得するには、XML 表スペース名を明示的に指定するか、 LISTDEF を使用して ALL または XML オブジェクトを組み込む必要があります。
詳しくは、以下を参照してください。
SQL/XML パブリッシング・ビューの使用によるリレーショナル・データの XML としての公開
リレーショナル列は SQL/XML パブリッシング・ビューに組み込むことができ、 ビューの照会時には、どの述部も、構成された XML に対してでなく、このリレーショナル列に対して表現してください。
SQL/XML パブリッシング関数を使用すると、リレーショナル・データを XML フォーマットに変換できます。 SQL/XML パブリッシング関数をビュー定義に隠すとよい結果になる場合があります。 アプリケーションまたは他の照会は、パブリッシング関数自体を扱うのでなく、単に構成された XML 文書をビューから選択できます。 次のステートメントによって、隠された SQL/XML パブリッシング関数を含むビューが作成されます。
CREATE TABLE unit( unitID char(8), name char(20), manager varchar(20));
CREATE VIEW UnitView(unitID, name, unitdoc) as
SELECT unitID, name,
XMLELEMENT(NAME "Unit",
XMLELEMENT(NAME "ID", u,unitID),
XMLELEMENT(NAME "UnitName", u.name),
XMLELEMENT(NAME "Mgr", u.manager)
)
FROM unit u;ビュー定義にリレーショナル列が含まれていることに注意してください。 これは、単にビューであり、マテリアライズされたビューでないため、物理的な冗長性が作成されることはありません。 リレーショナル列を公開することは、このビューを効率よく照会するために役立ちます。
次の照会はリレーショナル述部を使用して、 "WWPR" に対する XML 文書のみ確実に構成されるため、ランタイムが短縮され、特に大きなデータ・セットで顕著な結果になります。
SELECT unitdoc
FROM UnitView
WHERE unitID = "WWPR";XMLTABLE ビューの使用によるリレーショナル・フォーマットでの XML データの公開
ビューを使用して XML データをリレーショナル・フォーマットで公開することが必要な場合もあります。 前述の注意と同様の注意が必要ですが、 逆のやり方になります。 次の例の SQL/XML 関数 XMLTABLE は、XML 文書から値を表形式で戻します。
CREATE TABLE customer(info XML);
CREATE VIEW myview(CustomerID, Name, Zip, Info) AS
SELECT T.*, info
FROM customer, XMLTABLE ('$c/customerinfo' passing info as "c"
COLUMNS
"CID" INTEGER PATH './@Cid',
"Name" VARCHAR(30) PATH './name',
"Zip" CHAR(12) PATH './addr/pcode' ) as T;ビュー定義には、ビューを効率よく照会できるように XML 列「info」が含まれています。 指定した ZIP コードの顧客 ID と名前を表形式のリストにして取得したいとします。 これは、次の照会のいずれでもできますが、多くの場合 2 番目の照会のほうが最初の照会より実行が速くなります。
最初の照会で述部のフィルター操作は、 XMLTABLE 関数によって生成された CHAR 列の「Zip」で表されています。 ただし、リレーショナル述部のすべてが、内在する XML 列または索引に適用できるわけではありません。 したがって照会は、ビューがすべての顧客に対する行を生成することを求め、その後で Zip コード 「95141」に対応する行を選び出します。
SELECT CustomerID, Name
FROM myview
WHERE Zip = '95141';2 番目の照会は XML 述部を使用して、 確実に「95141」に対応する行のみを生成するため、ランタイムが短縮され、特に大きなデータ・セットで顕著な結果になります。
SELECT CustomerID, Name
FROM myView
WHERE xmlexists('$i/customerinfo[addr/pcode = "95141"]' passing info as "i");
パラメーター・マーカー付き SQL および XML ステートメントを使用した短い照会と OLTP アプリケーション
SQL/XML 関数の XMLQUERY、XMLTABLE および XMLEXISTS は、外部パラメーターをサポートします。
非常に 短いデータベース照会はきわめて短時間で実行される場合が多いため、そのコンパイルと最適化の時間が全応答時間の中の大きな割合を占めます。 そのため、 コンパイル、すなわち「準備」は一度だけにして、各実行では述部のリテラル値を渡すだけにすることが考えられます。 これは、短く、また繰り返しのある照会を含むアプリケーションに対して推奨する手法です。 次の照会は、前述の例の結果を得るためにパラメーター・マーカーを使用する方法を示します。
SELECT info
FROM customer
WHERE xmlexists('$i/customerinfo[phone = $p]'
passing info as "i", cast(? as varchar(12)) as "p")XML 挿入とリトリーブ時のコード・ページ変換の回避
XMLは、内部および外部でエンコードできるため、Db2内の他のタイプのデータとは異なります。 内部エンコードとは、XML データのエンコードをデータ自体から派生させることが可能ということです。 外部エンコードは、エンコードが外部の情報から派生するということです。
Db2とXMLデータを交換するために使用するアプリケーション変数のデータ・タイプによって、エンコード方式がどのように派生するかが決まります。 アプリケーションが XML に文字タイプの変数を使用していれば、 外部エンコードです。 バイナリーのアプリケーション・データ・タイプを使用している場合は、 XML データは内部エンコードとされます。
内部エンコードとは、エンコードが Unicode バイト・オーダー・マーク (BOM) または XML 文書自体のエンコード宣言 ( <?xml version="1.0"
encoding="UTF-8" ?> など) によって決定されることを意味します。
コード・ページ変換は余分な CPU サイクルを消費するため、パフォーマンスの観点から考えると、コード・ページ変換を可能な限り避けてください。 内部エンコードは不要なコード・ページ変換を防止するので、外部エンコードのデータより内部エンコードの XML データのほうが適切です。
このことから、
アプリケーションでは文字タイプよりバイナリー・データ・タイプを優先的に使用すべきです。 例えば、ODBC で SQLBindParameter() を使用してパラメーター・マーカーを入力データ・バッファーにバインドする場合、 SQL_C_CHAR, SQL_C_DBCHAR または SQL_C_WCHAR ではなく、SQL_C_BINARY データ・バッファーを使用する必要があります。 ホスト・アプリケーションでは、XML AS BLOB をホスト変数タイプとして使用します。
Java™アプリケーションからXMLデータを挿入する際には、XMLデータを文字列として読み込むよりも（setString ）、バイナリストリームとして読み込む（setBinaryStream ）方が望ましいです。同様に、Javaアプリケーションが Db2 からXMLを受信し、ファイルに書き込む場合、XMLがバイナリ以外のデータとして書き込まれると、コードページの変換が発生する可能性があります。
XMLデータをDb2からアプリケーションに取得すると、それがシリアライズされます。 シリアライゼーションは、XML 構文解析と逆の操作です。 これは、Db2が内部XMLフォーマットを変換するために使用するプロセスです。内部XML形式は、構文解析されたツリー状の表現であり、アプリケーションが理解できるテキスト形式のXML形式に変換されます。 ほとんどの場合、Db2に暗黙的な直列化を実行させるのが最善です。 これは、以下の例に示すように、SQL/XMLステートメントは、単にXMLタイプの値を選択するだけで、Db2はできるだけ効率的にアプリケーション変数に直列化を実行することを意味します。
CREATE TABLE customer(info XML);
SELECT info FROM customer WHERE...;
SELECT XMLQUERY('$i/customerinfo/name' passing info as "i")
FROM customer
WHERE...;アプリケーションが非常に大きな XML 文書を扱うときは、 データ・リトリーブに LOB ロケーターを使用することが適切な場合があります。 この場合、 CLOB などの文字タイプへの明示的なシリアライゼーションは、エンコードの問題および不要なコード・ページ変換が生じるおそれがあるため、LOB タイプ、できれば BLOB への明示的なシリアライゼーションが必要です。 明示的シリアライゼーションは、次の照会に示すように XMLSERIALIZE 関数を使用します。
SELECT XMLSERIALIZE(info as BLOB(1M)) FROM customer WHERE...;XMLMODIFY ステートメントを使用した XML 文書の部分的更新
XML 文書の一部のみを変更する必要がある場合、XMLMODIFY 関数を使用することで、XML 文書全体を置き換える場合よりも効率的に XML データを変更できます (特に大規模な XML 文書の場合)。 小規模な XML 文書の場合、単一のレコード内に収まる文書に XMLMODIFY ステートメントを使用してもパフォーマンス上の利点はありません。
アプリケーションが XML 列の更新に XMLMODIFY ステートメントを使用しない場合、XML 列の XML 文書全体が削除され、新規 XML 文書で置き換えられます。 XMLMODIFY を使用して XML 列を更新する場合、XMLMODIFY 関数により変更された XML 表スペースの行のみを削除または置き換える必要があります。
詳しくは、以下を参照してください。
構文解析されたXML文書の入力データにExtensible Dynamic Binary XML Db2 Client/Server Binary XML Formatを使用します
XML データの解析は、XML データの INSERT、LOAD、および UPDATE 操作中のパフォーマンスに影響する、最も重要な要因の 1 つです。 データの挿入、更新またはロードを行う時にExtensible Dynamic Binary XML Db2 Client/Server Binary XML Formatを使用すると、CPUオーバーヘッドが削減されます。 Db2 DRDAの zIIP リダイレクトはバイナリXMLの影響を受けませんが、 z/OS XMLシステムサービスは zIIP、 zAAP バイナリXMLには影響を受けませんが、XMLシステムサービスは、解析が不要なため、バイナリXMLの影響を受けます。
クライアント上のJavaアプリケーションから Extensible Dynamic Binary XML Db2 Client/Server Binary XML Format データを送信することで、 Db2 サーバーで必要なCPU時間を削減できます。 しかし、XMLデータをバイナリ形式に解析することは、 IBM® Data Server Driver for JDBC and SQLJ クライアント上で実行されます。 テキスト XML を送信する場合と比べて、クライアントでクラス 1 経過時間が増加することがあります。 経過時間の増加が貴社の環境に影響を与えない場合は、 Db2 サーバーのCPU時間を短縮するためにバイナリXMLを使用してください。
XPath または XQuery を使用するタイミングを決定する場合のパフォーマンスの考慮
通常、XQuery および XPath を使用する類似した操作を実行する場合は、似たようなパフォーマンスが得られるはずです。 ただし、場合によっては、XPath によってパフォーマンスが向上することがあります。
詳しくは、以下を参照してください。
XML_RANDOMIZE_DOCID サブシステム・パラメーターを設定して最高のパフォーマンスを得る
XML 列を含んだ表の DOCID 値をランダム化することによって、XML データ挿入の待ち時間を減らすことができます。 DOCID 値を順次挿入する場合、XML データを並行して挿入する間、複数のスレッドが同じデータ・ページのラッチを待機しなければならないような、ホット・スポット状態が発生する可能性があります。
ただし、XML_RANDOMIZE_DOCIDサブシステム・パラメーターの値がYESの場合、Db2は、XML列が含まれているすべての新規表および最初のXML列が追加される時に、既存の表に対してALTER TABLEで、CREATE TABLEのDOCID値をランダム化します。 XML_RANDOMIZE_DOCID サブシステム・パラメーターの値を変更しても、XML 列を含んだ既存の表に影響はありません。 ランダム化された DOCID 値を含んだ表を、順次 DOCID 値を使用するように変換することはできません。 同様に、既に順次 DOCID 値を含んだ表を、ランダム化された DOCID 値を使用するように変換することもできません。
SYSIBM.SYSSEQUENCES カタログ表の ORDER 列の値を調べて、特定の表にランダム化された DOCID 値が含まれるかどうかを判別することができます。
詳しくは、以下を参照してください。
FETCH WITH CONTINUE を使用した XML データへの高速アクセス
FETCH WITH CONTINUE ステートメントを使用して、最大長が不明または非常に大きい XML 列を参照する照会のパフォーマンスを向上させることができます。
LOADパフォーマンスを向上させるためにバイナリXMLを使用する
UNLOAD ユーティリティーによって入力データが作成されるときに、BINARYXML オプションを使用すると、XML データのロード時間を減らすことができます。 さらに、XMLデータが事前に検証済みであり、以下の条件が満たされている場合、検証を省略することができます
- ロードされる XML 列に対して 1 つの XML スキーマしか定義されていない。
- ロードされる XML 文書の最初の部分で、ルート・エレメント名前空間とスキーマ・ロケーション・ヒントが XML スキーマのものと一致する。
- ルート・エレメント名前空間が一致するが、xsi:schemaLocation が存在しない、または最初の xsi:schemaLocation 属性ペアにルート・エレメント名前空間に一致する名前空間が含まれない。
詳しくは、以下を参照してください。