ORACLEをバージョンアップしたら、なんか変になったことありませんか？

例えば、パフォーマンスが悪くなったり、問題なく動作していた機能がダウンした・・・とか。

それは、バージョンアップしたことで、以下のようなことが起こったからだと考えられます。
　・知らない間に新機能が動作して、サーバのリソース不足に陥った。
　・新しいバージョンが抱えていたバグによる影響。
　・既存のパラメータのデフォルト値が変わったことによる影響。
などなど。

バージョンアップ後も、バージョンアップ前と同じように、安定してデータベースを稼働させるには、バージョン間の差異を見極め
るのが重要です。

以下の観点に注意してバージョンアップを行うと、大きな失敗はないと思います。
このコラムでは、主に10g以前のバージョンから、11g、12cへバージョンアップする場合を想定しています。
※例)のところで、私の経験を書いてます。

■初期化パラメータ
・追加されたパラメータを把握する
　毎回、多数の初期化パラメータが追加されます。
　ほとんどが新機能に関する初期化パラメータになります。
　バージョンアップ後に、その新機能を使用するかどうか判断して、初期化パラメータを設定します。
　特定の新機能を使用しないと判断すれば、その機能に関する初期化パラメータをOFFに設定します。

・既存パラメータのデフォルト値が変更されたか確認する
　値を設定していない初期化パラメータには、デフォルト値が設定されます。
　このデフォルト値が、バージョンアップした場合変更されることがあります。
　マニュアルで、今のバージョンのデフォルト値と、バージョンアップ後のデフォルト値の違いを把握しておきます。
　デフォルト値が変わることにより、バージョンアップ前の動作と異なることがあるので、バージョンアップ前の値を設定した
　ほうがいいか検討します。

・廃止パラメータについて把握する
　代わりのパラメータを設定すればいいかどうか検討しておきます。

■新機能
バージョンアップの度に、大小数百の新機能が追加されます。
出来る限り、どんな新機能が追加されたか、把握しておきます。
その機能を使用するかどうかは、運用しているシステムそれぞれによります。
現行システムの要件を変えないのであれば、新機能は使用しないという選択肢もあります。
新機能を使用するのであれば、その機能についての、メモリ、CPU、ディスクの使い方を把握する必要があります。

例)
11gには、パラレル実行の際に動作するパラレルプロセスを自動調整する機能が追加されました。
この機能は便利そうでしたが使用しませんでした。
理由としては、パラレルプロセス数は、サーバリソースを考えたうえで上限値を決めて設計していたからです。
また、バージョンアップ前と同じ動作をさせたかったというのもあります。

■サポートされなくなった機能
現行システムで使用している機能が、サポート対象外になっていないか確認します。
有名なところでは、exp/impが、11gからサポート対象外になりました。

例)
バッチ処理などで、exp/impを使用している部分は、データポンプ(expdp/impdp)に書き換えました。

■バグ
MOSやサポートを使い、バージョンアップ後のバージョンについて、バグ情報を収集します。
影響がありそうなバグは、個別パッチ、運用回避、パラメータ変更など対策を検討します。

例)
11.2.0.3のread mostly rockという新機能のバグで、業務がハングしたことがあります。
この機能はデフォルトで、ONになっていました。
使用する必要が無い機能だと判断したので、隠し初期化パラメータでOFFにする対応を取りました。

■他のデータベースとのバージョン差異
バージョンアップすることにより、連携するデータベースのバージョンとずれが無いか確認します。
サポート対象となるサーバ／サーバ間、サーバ／クライアント間のバージョンを把握しておきます。
サポート対象となるバージョンの組み合わせについては、ORACLE社から公開されています。

■セキュリティ
バージョンアップの度に、デフォルトのセキュリティ設定が強化されていく傾向があります。
例えば、11gからスキーマのパスワード有効期限がデフォルトで、180日間と設定されています。
現行システムのリプレースなら、このあたりのセキュリティ設定を現行と同じレベルにすべきか検討します。

監査ログなども、デフォルト設定だと大量に出力されることがあり、出力先のディスク容量の設計も考慮します。

例)
バージョンアップ後、数日してアプリケーションが動かなくなりました。
アプリケーションで、ORACLEのスキーマにログインする箇所でログインできず、ダウンしていたことが分かりました。
ログインできないのは、スキーマパスワードの有効期間が過ぎていたからでした。
11gより前のバージョンでは、無期限だったので、このようなことはありませんでした。
バージョンアップ前と、同等の設定に戻しました。

■メモリ
新機能が増えていくので、当然バックグラウンドプロセスの数が増えます。
また、セッション1接続当たりのメモリ単価も大きくなっていく傾向があります。
その分現行よりも、データベースサーバのメモリを消費するので、メモリを再設計する必要があります。

例)
負荷テストでデータベースサーバに一斉に接続した際、バージョンアップしたら1接続当たりのメモリサイズが増えることを考慮し
ていなかったため、データベースサーバのメモリ不足になりました。
接続単価の見直しを行い、メモリ再設計を行いました。

■まとめ
現行バージョンと、バージョンアップ後のバージョンの違いについて、把握しておくことはとても多いです。
ですが、バージョンアップ後に、データベースがハングしたり、パフォーマンスダウンを防ぐためには、必要な作業です。

注意しないといけないのは、決して、デフォルト設定が良いわけでは無いし、マニュアルで推奨していることが実際のシステムには
最適ではないことが多々あります。

次々追加される新機能は便利そうで、使いたくなります。
ですが、内部動作を把握して、使いこなせるようになるまでのコストは大きいです。
また、新機能は枯れるまでバグをはらんでいるものです。
管理しているシステムで、本当に必要かどうか検討して、現行の機能と作り込みで賄えると判断すれば、それはそれで最適な判断だと思いま

す。

また、ORACLEは、バージョンアップの度に、自動化される機能が増えて行っています。
SGA・PGAの自動管理、ASMによるストレージの自動管理など。
これらは昔、きっちりと値を設計し、手動で上限や配置場所を設定していました。
こちらである程度コントロールできる分、アプリの変更の度に値を見直すといった手間がありました。
そういった手間が少なくなったのは良いことだと思います。
しかし、自動化されたということは、中身はブラックボックスであり、こちらとしては、全てをコントロールできない立場になると
いうことです。
何か起きた時、何をしていいか分からないかもしれない。
そうならないために、これら自動化機能の内部動作やバグ情報については、常にフォローして把握しておく必要があります。