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

過去記事は以下の通り。

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

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

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

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

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

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

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

す。

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