回答編集履歴
1
追加質問について回答文に追記しました。
test
CHANGED
|
@@ -85,3 +85,39 @@
|
|
|
85
85
|
END;
|
|
86
86
|
|
|
87
87
|
```DBMS_STATS.GATHER_SCHEMA_STATS の options に GATHER AUTO を指定すると自動オプティマイザ統計収集と同じ動作になるはずです。ただ、そのままだと本当に収拾されてしまうので、統計情報の遅延適用を利用して、統計情報を更新しないようにしています。他スキーマの対象を見るには USER のところに適切なスキーマ名を指定してください。
|
|
88
|
+
|
|
89
|
+
|
|
90
|
+
|
|
91
|
+
---
|
|
92
|
+
|
|
93
|
+
|
|
94
|
+
|
|
95
|
+
> 空テーブルの統計情報の取得は行われてしまっているのですね。
|
|
96
|
+
|
|
97
|
+
> 正しいインデックスを使えず初回処理が遅くなることを回避するにはヒント句を利用となるのでしょうか？
|
|
98
|
+
|
|
99
|
+
|
|
100
|
+
|
|
101
|
+
ヒント句を正しく指定できるのであれば、それも 1 つの解決策となります。ただ、使用するべきヒントは時間経過（データの変化）と共に変わることが多いため、なかなか難しいところもあるかと思います。
|
|
102
|
+
|
|
103
|
+
|
|
104
|
+
|
|
105
|
+
・12c
|
|
106
|
+
|
|
107
|
+
12c では動的統計機能が強化されていますので、動的統計機能を試してみるのもありかと思います。該当テーブルの統計情報を削除しておいた上で統計情報をロックしておくと初期化パラメータで動的統計を無効にしていない限り、動的統計を使用してくれるはずです。
|
|
108
|
+
|
|
109
|
+
以下の文書にあるようにセッション毎にサンプリングレベルを設定するのが一番良いと思います。
|
|
110
|
+
|
|
111
|
+
[https://docs.oracle.com/cd/E57425_01/121/TGSQL/tgsql_astat.htm#GUID-F1C666DC-5450-4F92-83AA-607327DB5FD8](https://docs.oracle.com/cd/E57425_01/121/TGSQL/tgsql_astat.htm#GUID-F1C666DC-5450-4F92-83AA-607327DB5FD8)
|
|
112
|
+
|
|
113
|
+
|
|
114
|
+
|
|
115
|
+
どのタイミングで統計のロックを解除するかを判断するには、最初に回答した遅延状態で統計を採取し、セッションパラメータ OPTIMIZER_USE_PENDING_STATISTICS で遅延状態の統計を使用して実行時間・実行計画を見て判断されると良いかと思います。
|
|
116
|
+
|
|
117
|
+
参考：[http://www.oracle.com/technetwork/jp/database/articles/shibacho/index-1849103-ja.html](http://www.oracle.com/technetwork/jp/database/articles/shibacho/index-1849103-ja.html)
|
|
118
|
+
|
|
119
|
+
|
|
120
|
+
|
|
121
|
+
・11g
|
|
122
|
+
|
|
123
|
+
12c と同じ方法でも良いのですが、なぜか動的統計（11gでは動的サンプリング）を使用すると思うような結果が得られなかったため、実際に入ると想定されるダミーデータをロードして、統計情報を取得後に統計情報をロックして対応したことがあります。ただし、この手法ではダミーデータよりはるかに件数が少ない場合に思うような実行計画が策定されずに困ったこともあります。
|