[Database] Sleeping Beauties - Upgrade to 11.2.0.4 can be slow

原文はこちら。
https://blogs.oracle.com/UPGRADE/entry/sleeping_beauties_upgrade_to_11

---

USのお客様から先週LinkedInを通じて連絡があり、次の質問をいただきました。

"Is it expected that my patch set upgrade from Oracle 11.2.0.3 to Oracle 11.2.0.4 takes over 3 hours?"
（Oracle 11.2.0.3から11.2.0.4へのアップグレードのためのパッチセットって3時間以上かかるもの？）

当然ながら、Noです。そんなことはありません。
以下はutlu112s.sqlを使ってアップグレード後に収集したアップグレード統計情報です。

SQL> @?/rdbms/admin/utlu112s.sql ; .
Oracle Database 11.2 Post-Upgrade Status Tool 10-31-2014 10:05:29
Component Current Version Elapsed Time
Name Status Number HH:MM:SS
Oracle Server
. VALID 11.2.0.4.0 02:46:19
JServer JAVA Virtual Machine
. VALID 11.2.0.4.0 00:08:34
[..]
Final Actions
. 00:00:00
Total Upgrade Time: 03:06:47

いやいや、全くもって想定外です。ってわけで、問題のアップグレード・スクリプトc1102000.sql内の上記ステートメントを見つけ、根本的な原因を見極めることを試みました。

194 -- wri$_optstat_histhead_history2.
195 execute immediate
196 q'#create unique index i_wri$_optstat_hh_obj_icol_st on
197 wri$_optstat_histhead_history (obj#, intcol#, savtime, colname)
198 tablespace sysaux #';
199
200 execute immediate
201 q'#create index i_wri$_optstat_hh_st on
202 wri$_optstat_histhead_history (savtime)
203 tablespace sysaux #';
204 end;
205 /

この箇所は、ヒストグラム表の索引を再作成しています。既定の統計情報保持期間が31日なので、お客様の環境には非常に大量の統計情報があります。
索引の再構築が（並列実行せず、NOLOGGING句がないため）あまり効率的に行われていないのは明らかです。こうしたことが発生する可能性があり、この事象が何ら問題ないことも時としてあります。しかし、今回の場合、索引の再構築のためだけに2時間以上を要しました。
幸いにも、同僚のCindyが、こうした事象に対応するすばらしい人材です。私たちのチームへ問い合わせをもらった後、私はこの件でバグ番号を取り、コードの修正をすでにチェックイン（現在レビュー中）したことを返信しました。

bug19855835:
Upgrade from 11.2.0.2 to 11.2.0.4 is slow

追伸
この問題に目を向けさせてくれたTanの功績です。ご不便をおかけして申し訳ありません。