常駐先で、ORACLEデータベースの管理やってます。ORACLE Platinum10g、データベーススペシャリスト保有してます。データベースの話をメインにしたいです

しくじらないバージョンアップ

»

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

11

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

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

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

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

Comment(6)

コメント

湯二さんこんにちは
文系の院卒がIT業界に入ってみて感じたこと管理人ひろ氏です。

この世界バージョンアップが必ずしも改善ではないのはあるあるですよね。
今の現場でPSRを11.2.0.4にあげたら何故かSQLのレスポンスが遅くなっててんやわんやしてグレードダウンしなおすことになりました。
Oracleは性能が良いからか無駄にスペック高いからかやたらとメモリ食いますよね。触ってて良く分からんなあと毎回思ってます。

湯二

ひろ氏さん、いつもコメントありがとうございます。

あるあるですね。
何も調べずにバージョンアップすると痛い目にあいます。

バージョンアップしたらSQLが遅くなりましたか。
私も、同じ経験をしました。
その時は、バージョンアップ前の統計情報をexp/impしたら同等の速度になりました。
バージョンが上がれば、オプティマイザも変わるので、そのあたりも注意が必要です。
ただ、グレードダウンするとは、なかなか思い切った決断をする現場ですね。

Oracleは慣れるまで扱いにくいですよ。
覚えることが多いし、インストールにしても前提条件が何やらで敷居が高い。
メモリ設定に関しては、とてもデリケートでちょっと変更を変えると起動しなくなったりとかよくありました。

ほしゅいん

バージョンアップではなく新規導入ですが
パスワードの有効期限設定漏れをされて、
夜間呼び出されました・・・

これを先に知っていれば、
ベンダーへの対応依頼がもっとスムースに行えたはずです。

これからも、これまでのように活用できるコラムを
よろしくお願いします。

ハリコフ

5年ほど前に9iから11gに上げたのですが、オプティマイザの挙動の変更に悩まされたことを思い出しました。

抽出結果が、ある並び順になる筈なのに、バージョンアップ後には並びがバラバラになる。仕様書(プログラム)を見ると、ソート順が指定されていない。
じゃあ、なんで今まで並んでいたんだ?って話で実行計画を比較してみると、結合方法がネスティッドループ結合からハッシュ結合に変わっていた。これが原因らしい。

これ、システム側のバグ(要件定義の不足かな?)が顕在化しただけなんですが、対応しないとダメって事は変わらないので、苦労しました。

湯二

ほしゅいんさん、いつもコメントありがとうございます。

こういう設定は、知ってないとそのままリリースして、あとで焦ることが多いですね。
お客さん側からすれば「何やってるんだ」って感じでしょうね。
知ってなくても、見つけられるようなテストシナリオを考えるべきなんでしょう。
つい性能や、データがちゃんと移行できたかとか、そういうことに目が行きがちですが、パッと見、表に出ないようなこういったことも気にしないといけないということを学びました。

これからも、活用できそうな情報を載せようと思います。
みんなが定時で帰れるように。

湯二

ハリコフさん、いつもコメントありがとうございます。

バージョンアップすれば、オプティマイザは頭が良くなるはずなので、PGAに余裕があればなるべく、ネスティッドループ結合よりハッシュ結合を使いますね。
※統計情報がちゃんと取得されていれば。
ソート順が設定されていなければ、表示順は保証されません。
開発環境と、本番環境で同じデータが入っていて、同じバージョンでも、ソート順をしていないSQLを実行したら表示順が異なって出てきました。

バージョンアップでバグが顕在化したんですね。。。
バグではないのですが、10.1.0.5から11.2.0.3にバージョンアップしたらSQLで全角の%(%)が使えなくなっていました。
なので、アプリケーションに記載されている
select * from xxx where yyy like '%zzz%';
というSQLで結果が返ってこなかったので、原因が分かるまで、すごい騒ぎになりました。
結局、%を%にして対応しました。
こういうのは、バージョンアップ前にマニュアルやKROWNなど隅から隅まで調べないと分からないですね。。。
お客さんからしたら、どちらにしろバグなんでしょう。

コメントを投稿する