前回のおさらい
前回『SQL実行計画の変更 その1』では、SPM(Sql Plan Management)でアプリケーションに手を入れることなくパフォーマンス改善を行う方法についてお話をしました。
どんな内容だったかなぁ?というかたは、上記リンクから改めて確認してくださいね。
アプリケーション開発者からの相談
システムの「心臓」こと、Oracle Databaseに日々携わるたろーちゃん。
そんなたろーちゃんのところに、アプリケーション開発者のAさんがまた訪ねてきました。
今回は何があったのでしょうか?
Aさん「たろーちゃん、ちょっと時間ある?」
たろー「何?また何かあったの?」
Aさん「そんな顔するなよ。マジで困ってるんだから。」
たろー「どうしたの?」
Aさん「今日、新しいWEBシステムのカットオーバーだったんだけど、本番環境でデータベースのパフォーマンスが出てないんだ。」
たろー「どうせまた、開発環境で性能テストをサボったんじゃないの?」
Aさん「そんなことないよ。この前、たろーちゃんに注意されてから、ちゃんと性能テストをするようにしてるさ。ちょっと見てくれよ。」
たろーちゃんは、データベースサーバの構成を詳しく聞くことにしました。
本番環境 | ・ Real Application Clusters構成(11gR2 Standard Edition 2ノードRAC) ・ Statspack は30分おきにスナップショットが取られている。 |
開発環境 | ・ シングルインスタンス構成(11gR2 Standard Edition One) ・ Statspack は30分おきにスナップショットが取られている。 |
たろー「本番環境と開発環境の違いは、『シングルインスタンス構成かRAC構成か?』か。」
Aさん「そうなんだ。お客様がなるべく予算を低く抑えたいということで、開発環境はシングルインスタンス構成になったんだ。」
たろー「マシンスペックはどうなの?」
Aさん「本番環境のノードも、開発環境のノードも、全て同じだ。同じメモリ構成、同じCPUで動作している。」
たろー「ふむ。」
Aさん「それで、開発環境で性能テストした時は何も問題なかったんだけど、いざ本番移行すると、性能問題が発生したんだ。」
たろー「シングルインスタンス構成よりも、2ノードRAC構成のほうが遅いってこと?」
Aさん「そうなんだ。シングルインスタンス構成で性能テストをパスできれば、2ノードRAC構成の本番環境でも問題ないと思ってたんだが…。」
たろー「うむ…。」
普通に考えればAさんの言う通りである。1台より2台のほうが、早くなりこそすれ、遅くはならない。私は、シングルインスタンス構成には無いRAC特有の「キャッシュフュージョン」に問題があると予想していた。この時までは………。
たろー「とりあえず、Statspackレポートを見てみよう。」
アプリケーション開発者も知らないSQL
たろーちゃんは食い入るように Statspackレポートを見ていました。
たろー(・・・おかしい。てっきり「キャッシュフュージョン」に問題があって、gc (グローバル・キャッシュ)系の待機イベントが頻発しているかと思ったが、そうじゃない。一番大きい待機イベントは 『db file sequential read』だ。両方のノードで発生している。)
たろー「一番時間が掛かっているSQLは・・・。んん?!」
Aさん「どうした?」
たろー「なんだこれは?!アプリケーションから USER_TABLES や USER_IND_COLUMNS への SELECT 文が発行されていて、その実行にとても時間が掛かってるぞ!」
Aさん「なんだって?」
たろー「Aさん、アプリケーションからこんなSQL発行してるの?」
Aさん「いや、そんなSQLは発行してないぞ。」
たろー「じゃあ、なにこれは???」
Aさん「さ、さあ・・・」
Aさんも知らない謎のSQLがアプリケーションから発行されていました。
一体、何者なのでしょうか?
謎のSQLの正体
USER_TABLESやUSER_IND_COLUMNSは表やカラムの定義情報を参照するためのディクショナリビューであり、アプリケーションから参照することは通常ありません。
しかし、アプリケーションから発行されているこれらのSQLが遅延の原因なのは明らかなので、たろーちゃんはAさんに謎のSQLの調査をお願いしました。
数日後・・・。
Aさん「たろーちゃん、謎のSQLの正体が分かったぞ。」
たろー「なんだったの?」
Aさん「アプリケーションで使用している『フレームワーク』が、どうやら自動的に発行しているらしい。」
たろー「フレームワーク?」
Aさん「ああ。アプリケーション開発者がSQLをよく知らなくてもプログラミングできるよう、某 O/Rマッパー を使用してるんだが、それがあのSQLを発行しているらしいんだ。」
たろー「じゃあ必要なSQLだから、発行の抑制も出来ないってこと?」
Aさん「そうなる。」
SQLをよく知らない単価の安いプログラマーを雇うために採用したフレームワークが、まさかここにきて足枷になるとは。
Aさん「でも俺が気になっているのは他にあるんだ・・・。」
たろー「ああ、俺が思っているのと多分同じだ。」
Aさん「問題は・・・。」
たろー&Aさん「なぜ開発環境では性能問題が出なかったのか?」
今回はここまで。
次回は、なぜ開発環境では性能問題が出なかったのか?
その謎に迫ります。
投稿者プロフィール
-
「DBひとりでできるもん」運営チームです。
「親しみやすさと技術力」をテーマに、技術情報・サービス・インフラ系資格取得に役立つ情報、社員等の情報をお届けします。
70名弱の事業部員で鋭意、執筆中です。
少しでも当社を知って頂けるよう、愛情込めて頑張ります!
※facebook、X(旧twitter)、インスタグラムでは「DBひとりでできるもん」の更新情報を発信しています。
- Oracleライセンス2024年10月9日【オラクルライセンス】Oracle 1-click Program 販売に関する改定のご案内
- MaxGauge2024年10月8日【再掲載】【事例公開】フルキャストが保守・運用の悩みを解決できたワケ、DB安定のためにとった手段とは
- MaxGauge2024年10月7日【再掲載】事例紹介します!_2/2
- Dbvisit Standby2024年10月4日【再掲載】事例紹介します!_1/2