■ 基幹システム移行
去年（2016年）からずっと取り組んでいた基幹システムの移行（
基幹システムの移行！（2017）、
基幹システムの移行！（2017）の徹夜でダウン（風邪）、
DBサーバのディスクをSSDにしたら高速移行が出来た）ですが、ようやく完了しました。
しかし、本稼働後に少し問題は出ました。
Oracleのバージョンが11から12に変わったのですが、その影響か一部の処理（というか、
SQL）が異様に遅くなりました。DBサーバの膨大なメモリと
SSDの力で何とか業務が止まらない程度の速度は出ているのですが、ちと問題です。
統計情報に問題があるのかとも思ったのですが、取得し直しても結果は変わらず。色々と対応方法は思いつくのですが、素直にヒント句を追加して性能の安定を図りました。
他にもパラパラと出てしまいましたが、大きな目線で問題になることはなかったので一安心です。
■ ラックの移設
本稼動から数週間。今度はラックの移設を行いました。
新しいサーバー（などの機器）は、一時的に借りたラックに置いていたのですが、月を跨ぐと費用が発生してしまいます。今更切り戻しってこともあり得ないので、古い機器を撤去して、その場所に移設することにしました。
言葉にすると簡単ですが、IDCの機器って普段は電源入れっぱなしってのが多いので、移設に合わせて電源の入れ直しをするのは実は結構なリスクがあったりします。
電源の入れる順番を間違えると起動しないとか普通にあるし、電源を入れた後でさらに別のサービスを起動しないと行けなかったりと、きちんとシステム構成を把握していないと大問題に発展します。
ってことで、電源の停止＆起動の順番を考えて、稼動後の確認手順を作成して、私がいなくても問題なく作業できるように関係者に周知して、そうそう、移設作業中はシステムが使用できないので現場に連絡して、うん、意外とやることありますね。
・・・・・・・・・・・・いや、基幹システム自体の持分は私ですが、ラックの移設って別の人の担当だったような気が。まぁ、別に良いんですけどね。
■ 後書き
遅くなった
SQLを見ると、片方はWITHで作った内部テーブルを抽出条件として使用するSELECT文を UNION ALL でくっ付けています。実行計画を見ると、何故かWITHの結果を見ないで妙な条件で再抽出するような奇妙な動作をしています。もう片方は
SQLを引っこ抜いて実行計画を見ると特に変な感じはしません。
前者は結構知恵を絞りました。使用するインデックスの指定だけではダメで、テーブルの結合順番まで細かく指定して、ようやく望みの実行計画になってくれました。
Oracleのオプティマイザって徐々に良い感じに動くようになっているとは思いますが、逆に言うと妙な動作をするようになったのなら、チューニングも手間が掛かるようになったとも言えるかも知れません。
問題は後者の方です。Enterprise Managerで実行時の
SQLを見るとマスタ系のテーブルをフルテーブルスキャンしたり、明らかに参照していない項目を使ったインデックスを使っていたりと、奇妙な実行計画になっています。
しかし、その
SQLを引っこ抜いて
SQL Developerで実行計画を取って見ると、良い感じに実行計画を作っています。こういった特定の条件下で発生する遅延って厄介です。
まぁ、実は原因は想像がついていて、おそらく
COBOLから実行しているのが良くないと思われます。
COBOLから
Oracleを使うには、ソースをPro*
COBOLプリコンパイラなるものを通して変換する必要があるのですが、その変換に何やら問題がありそうなのです。
こうなった時の対策は、ヒント句を突っ込むのが手っ取り早いです。
いや、正確には動的SQLにしてやればPro*
COBOLによる変換を回避できるようなので、そっちにするって手もあるのですが、埋め込みSQLを動的SQLに書き換えるのは少し手間だし、ヒント句の追加に比べてリスクが高くなるので避けたいところです。
最新の記事：
http://harikofu.blog.fc2.com/投稿記事の一覧：
http://harikofu.web.fc2.com/--- blog end —
スポンサードリンク
システム開発
0
0