選択されたシステム・カタログを更新できるという機能によって、 次のことが可能になります。
実動システム上では統計を更新しないでください。 最適化プログラムが照会に最適のアクセス・プランを検出する妨げになってしまうためです。
それらの統計列の値を更新するには、 SYSSTAT スキーマに定義された視点に対して SQL UPDATE ステートメントを使用します。 更新できる統計は、次のものです。
さらに、自分のユーザー ID に、 データベースに対して明示的な DBADM 権限が与えられている場合、 つまり、そのユーザー ID が DBADM 権限を持つものとして SYSCAT.DBAUTH 表に記録されている場合は、 これらの統計を更新することができます。 DBADM グループに属していることは、 明示的にこの権限を付与することにはなりません。
これらの視点を使用すると、DBADM ですべてのユーザーの統計行を表示することができます。 DBADM 権限のないユーザーは、CONTROL 特権を持つオブジェクトの統計が入った行しか表示できません。
以下に、EMPLOYEE 表の表統計を更新する例を示します。
UPDATE SYSSTAT.TABLES SET CARD = 10000, NPAGES = 1000, FPAGES = 1000, OVERFLOW = 2 WHERE TABSCHEMA = 'userid' AND TABNAME = 'EMPLOYEE'
カタログ統計を更新するときは慎重に行ってください。 勝手な更新は、以降の照会のパフォーマンスに重大な影響を与える可能性があります。 以下のいずれかの方法を使って、これらの表に適用した更新をすべて置換できます。
場合によっては、最適化プログラムが特定の統計値か値の組合せを無効と判断して、 省略時値を使い、警告を出すことがあります。 しかし、統計の更新時には大部分の妥当性検査が行われるので、 このような状況はまれです。
追加情報: カタログ統計の更新については、 以下を参照してください。
カタログ統計を更新する場合、 一般的な規則のうち最も重要なのは、各種統計の有効な値、範囲、 および形式を確実に統計視点に保管するということです。 さらに、各種統計相互間の関係の一貫性を保つことも重要です。
たとえば、SYSSTAT.COLUMNS 内の COLCARD は SYSSTAT.TABLES 内の CARD より小さくなければなりません (列内の個別値の数は、 行の数より多くすることはできません)。 ここで、COLCARD を 100 から 25 に減らし、CARD を 200 から 50 に減らしたいと仮定します。 このとき最初に SYSCAT.TABLES を更新したとすると、 エラーを受け取ることになります (CARD が COLCARD より小さくなってしまうため)。 正しい順序は、最初に SYSCAT.COLUMNS 内の COLCARD を更新し、 その後で SYSSTAT.TABLES 内の CARD を更新するという順序です。 逆に COLCARD を 100 から 250 に 増やし、CARD を 200 から 300 に増やしたい場合にも、同じことが言えます。 その場合には、最初に CARD を更新してから、 その後で COLCARD を更新しなければなりません。
更新された統計と別の統計との間に矛盾が検出された場合には、エラーが出されます。 ただし、矛盾が生じたときに必ずエラーが出されるとは限りません。 特に 2 つの関連する統計が別々のカタログにある場合など、状況によっては、 矛盾を検出したりエラーを報告したりするのが難しいことがあります。 したがって、こういった矛盾を起こさないように十分注意が必要です。
カタログ統計を更新する前に検査する必要のある規則のうち、 最も一般的なのは次のものです。
注: | 行タイプの場合、表レベルの統計 NPAGES、FPAGES、および OVERFLOW は、 副表に対して更新されません。 |
SYSTAT.TABLES 内で更新可能な統計値は、 CARD、 FPAGES、 NPAGES、 OVERFLOW の 4 つだけです。 更新の際には、以下に留意してください。
連合データベース・システムで作業している場合、 リモート視点に対するニックネームについての統計を手操作で提供 / 更新するときには、注意が必要です。 ニックネームが戻す行数などの統計情報は、 このリモート視点の評価にかかる実際のコストを反映していないことがあるので、 DB2 最適化プログラムが正しく動作しないことがあります。 統計の更新が役立つ状況には、 リモート視点が SELECT リスト上で列関数が適用されていない単一の基礎表上に定義されている場合が含まれます。 複合視点では、それぞれの照会の調整が必要な複合チューニング・プロセスが必要になることがあります。 DB2 最適化プログラムが視点のコストをより正確に導き出す方法を知ることができるように、 ニックネームに対してローカル視点を作成することを考慮してください。
SYSSTAT.COLUMNS 内の統計を更新する場合には、 以下の指針に従ってください。 列分布統計の更新の詳細については、列分布統計の更新の規則を参照してください。
カタログ統計を更新する方法に関する一般的な情報については、 ユーザー更新が可能なカタログ統計で説明されています。 列分散統計の更新を試みる前に、この部分をお読みください。
カタログ内のすべての統計を矛盾のない状態にするためには、 分布統計を更新するときに十分に注意を払わなければなりません。 具体的には、各列ごとに、頻出データ統計と変位値のカタログ項目は、 以下の制約を満たしていなければなりません。
行の数が"R"個である列 C1 で分布統計が使用可能である場合に、 データ値の相対比率を同じに保ったまま、 行数を"(F × R)"にした列に対応するように統計を変更したいものとします。 頻出値統計を F 倍するには、 列 VALCOUNT の各項目を F 倍しなければなりません。 同様に、変位値を F 倍するには、 列 VALCOUNT 内の各項目を F 倍しなければなりません。 これらの規則に従わないなら、 照会の実行時に最適化プログラムが誤ったフィルター要因を使用することになり、 予測不能なパフォーマンスになる可能性があります。
SYSSTAT.INDEXES 内の統計を更新する場合には、以下で説明する規則に従ってください。
有効な PAGE_FETCH_UPDATE は次のとおりです。
PAGE_FETCH_PAIRS = '100 380 120 360 140 340 160 330 180 320 200 310 220 305 240 300 260 300 280 300 300 300'
ここで、
NPAGES = 300 CARD = 10000 CLUSTERRATIO = -1 CLUSTERFACTOR = 0.9
FIRSTKEYCARD <= FIRST2KEYCARD <= FIRST3KEYCARD <= FIRST4KEYCARD <= FULLKEYCARD <= CARD
SYSSTAT.FUNCTIONS カタログ視点を使用すると、 ユーザー定義関数 (UDF) の統計を更新することができます。 これらの統計が使用可能であれば、 最適化プログラムは各種アクセス・プランのコストを見積もる際にそれらを使用します。 使用できる統計がないなら、統計の列の値は -1 になり、 最適化プログラムは単純な UDF を前提とする省略時値を使用します。
UDF に関して更新可能な統計列についての情報を、次の表にまとめます。
表 48. 関数統計 (SYSCAT.FUNCTIONS と SYSSTAT.FUNCTIONS)
統計 | 説明 |
---|---|
IOS_PER_INVOC | 関数が実行されるたびに実行される読み取り / 書き込み要求の数の見積値。 |
INSTS_PER_INVOC | 関数が実行されるたびに実行されるマシン語命令の数の見積値。 |
IOS_PER_ARGBYTE | 入力引き数バイトごとに実行される読み取り / 書き込み要求の数の見積値。 |
INSTS_PER_ARGBYTES | 入力引き数バイトごとに実行されるマシン語命令数の見積もり。 |
PERCENT_ARGBYTES | 関数が実際に処理する入力引き数バイトの平均比率 (パーセント単位) の見積値。 |
INITIAL_IOS | 関数が最初または最後に呼び出されるときにだけ実行される読み取り / 書き込み要求の数の見積値。 |
INITIAL_INSTS | 関数が最初または最後に呼び出されるときにだけ実行されるマシン語命令の数の見積値。 |
CARDINALITY | 表関数によって生成される行数の見積値。 |
たとえば、米国製の靴のサイズを、 それに対応する欧州製の靴のサイズに変換する UDF (EU_SHOE) を考えてみましょう。 (これらの 2 つの靴のサイズは、UDT になります。) この UDF の場合、統計列を次のように設定します。
PERCENT_ARGBYTES は、 必ずしも入力ストリング全体を処理するとは限らない関数によって使用されます。 たとえば、2 つの引き数を入力とし、第 2 引き数の中で、 第 1 引き数が現れる最初のオカレンスの開始位置を返す UDF (LOCATE) を考えてみましょう。 第 1 引き数の長さが第 2 引き数と比べると十分に小さく、 第 2 引き数の平均 75 パーセントが探索されるものとします。 この情報に基づくと、PERCENT_ARGBYTES は 75 に設定されます。 この平均 75 パーセントの見積もりは、以下に示す追加の前提事項に基づいています。
INITIAL_INSTS または INITIAL_IOS を使用すると、 最初または最後に関数が呼び出されるときにだけ実行されるマシン語命令または読み取り / 書き込み要求の数の見積もりを記録することができます。 これは、たとえば、スクラッチパッド域をセットアップするコストを記録するときなどに使用できます。
ユーザー定義関数によって使用される入出力と命令についての情報を得るには、 プログラム言語コンパイラーによって、 またはオペレーティング・システムで使用可能なモニター・ツールによって提供される出力を使用することができます。
テスト・システムに、 実動システムのデータのサブセットを入れる必要が生じる場合があります。 しかし、テスト・システムのカタログ統計と構成パラメーターを実動システムのカタログ統計と構成パラメーターと一致するように更新したのでない限り、 この種のテスト・システムで選択されたアクセス・プランは、 実動システムで選択されるアクセス・プランと必ずしも同じにはなりません。
生産性向上ツール db2look を実動データベースに対して実行すると、 テスト・データベースのカタログ統計を実動のものと一致させるのに必要な更新ステートメントを生成することができます。 これらの更新ステートメントを生成する場合は、 模擬モード (-m オプション) で db2look を使用します。 そのようにした場合、db2look は、 実動データベースのカタログ統計を模造するのに必要なステートメントをすべて含むコマンド・プロセッサー・スクリプトを生成します。 これは、テスト環境で Visual Explain を使用して SQL ステートメントを分析するときに便利です。
db2look -e を用いて DDL ステートメントを抽出すると、 表、視点、索引およびデータベース内の他のオブジェクトを含むデータベース・データ・オブジェクトを再作成することができます。 このコマンドから作成されたコマンド・プロセッサー・スクリプトを別のデータベースに対して実行すると、 データベースを再作成することができます。 -e オプションは -m オプションと一緒に使用することができます。
db2look によって生成された更新ステートメントを テスト・システムに対して実行したなら、テスト・システムを使用して、 実動で生成されるアクセス・プランを妥当性検査できるようになります。 最適化プログラムが表スペースのタイプと構成を使用して入出力コストの見積もりを行うので、 テスト・システムには、同じ表スペース形状つまり表スペース・レイアウトがなければなりません。 すなわち、同じタイプ (SMS か DMS のいずれか) のコンテナーが同じ数だけなければなりません。
db2look ツールは、 bin サブディレクトリーにあります。
この生産性向上ツールの使用方法について知りたい場合は、 コマンド行で次のように入力してください。
db2look -h
このツールの詳細については、 コマンド解説書 も参照できます。
コントロール・センターにも、 この db2look ユーティリティー (「SQL の生成 - オブジェクト名 (Generate SQL - Object Name)」と呼ばれる) へのインターフェースが備わっています。 コントロール・センターを使用すると、 このユーティリティーからの結果ファイルをスクリプト・センターに統合することができます。 コントロール・センターから、 db2look コマンドをスケジュールすることもできます。 コントロール・センターを使用する場合の違いは、 db2look コマンドを使用する場合は、 1 つの呼び出しで最大 30 の表を分析できるのに対して、 1 つの表の分析しか行えないということです。 コントロール・センターからは、 LaTex および図形出力はサポートされていないことも知っておく必要があります。
db2look ユーティリティーは OS/390 データベースに対して実行することもできます。 db2look ユーティリティーは、 OS/390 オブジェクトの DDL および UPDATE 統計ステートメントを抽出します。 これは、OS/390 オブジェクトを抽出して、 DB2 ユニバーサル・データベース (UDB) データベース内にそのオブジェクトを再作成したい場合に非常に役立ちます。 db2look ユーティリティーに関する追加情報については、 コマンド解説書 を参照してください。
DB2 UDB の統計と OS/390 の統計の間にはいくらかの違いがあります。 db2look は、適切な場合に DB2 (OS/390 版) から DB2 UDB への適切な変換を実行し、 DB2 (OS/390 版) で対応するものが存在しない DB2 UDB の統計については省略時値 (-1) を設定します。 以下に、db2look ユーティリティーが、 DB2 (OS/390 版) の統計を DB2 UDB の統計にマップする方法を示します。 以下の説明で、 "UDB_x"は DB2 UDB の統計列を、"S390_x"は DB2 (OS/390 版) の統計列を表します。
UDB_CARD = S390_CARDF
UDB_NPAGES = S390_NPAGES
S390_FPAGES はありません。 ただし、DB2 (OS/390 版) には、PCTPAGES という別の統計があり、 表の行を含んでいる活動状態の表スペース・ページのパーセンテージを表します。 それで、以下のように、 S390_NPAGES および S390_PCTPAGES に基づいて UDB_FPAGES を計算することができます。
UDB_FPAGES=(S390_NPAGES * 100)/S390_PCTPAGES
UDB_OVERFLOW にマップする S390_OVERFLOW はありません。 そのため、db2look ユーティリティーは、 この値を省略時値に設定します。
UDB_OVERFLOW=-1
UDB_COLCARD = S390_COLCARDF
UDB_HIGH2KEY = S390_HIGH2KEY
UDB_LOW2KEY = S390_LOW2KEY
UDB_AVGCOLLEN にマップする S390_AVGCOLLEN がないため、 db2look ユーティリティーは、 この値を省略時値に設定します。
UDB_AVGCOLLEN=-1
UDB_NLEAF = S390_NLEAF
UDB_NLEVELS = S390_NLEVELS
UDB_FIRSTKEYCARD= S390_FIRSTKEYCARD
UDB_FULLKEYCARD = S390_FULLKEYCARD
UDB_CLUSTERRATIO= S390_CLUSTERRATIO
OS/390 で対応するものがない他の統計は、 省略時値に設定されます。 つまり、以下のようになります。
UDB_FIRST2KEYCARD = -1 UDB_FIRST3KEYCARD = -1 UDB_FIRST4KEYCARD = -1 UDB_CLUSTERFACTOR = -1 UDB_SEQUENTIAL_PAGES = -1 UDB_DENSITY = -1
DB2 (OS/390 版) SYSIBM.SYSCOLUMNS には、 2 つのタイプの統計があります。 頻出値を表す「F」と、 カーディナリティーを表す「C」です。 DB2 UDB に適用可能なのはタイプ「F」の項目だけです。 考慮されるのは、これらの項目です。 また、DB2 (OS/390 版) の SYSIBM.SYSCOLUMNS には列 SEQNO がありませんが、 DB2 UDB では必要です。 そのため、db2look はその列を自動的に生成します。
UDB_COLVALUE = S390_COLVALUE UDB_VALCOUNT = S390_FrequencyF * S390_CARD