前回のおさらい

前回『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_TABLESUSER_IND_COLUMNS への SELECT 文が発行されていて、その実行にとても時間が掛かってるぞ!」

Aさん「なんだって?」

たろー「Aさん、アプリケーションからこんなSQL発行してるの?」

Aさん「いや、そんなSQLは発行してないぞ。」

たろー「じゃあ、なにこれは???」

Aさん「さ、さあ・・・」


Aさんも知らない謎のSQLがアプリケーションから発行されていました。

一体、何者なのでしょうか?

謎のSQLの正体

USER_TABLESUSER_IND_COLUMNSは表やカラムの定義情報を参照するためのディクショナリビューであり、アプリケーションから参照することは通常ありません。

しかし、アプリケーションから発行されているこれらのSQLが遅延の原因なのは明らかなので、たろーちゃんはAさんに謎のSQLの調査をお願いしました。


数日後・・・。

Aさん「たろーちゃん、謎のSQLの正体が分かったぞ。」

たろー「なんだったの?」

Aさん「アプリケーションで使用している『フレームワーク』が、どうやら自動的に発行しているらしい。」

たろー「フレームワーク?」

Aさん「ああ。アプリケーション開発者がSQLをよく知らなくてもプログラミングできるよう、某 O/Rマッパー を使用してるんだが、それがあのSQLを発行しているらしいんだ。」

たろー「じゃあ必要なSQLだから、発行の抑制も出来ないってこと?」

Aさん「そうなる。」

 

SQLをよく知らない単価の安いプログラマーを雇うために採用したフレームワークが、まさかここにきて足枷になるとは。

 

Aさん「でも俺が気になっているのは他にあるんだ・・・。」

たろー「ああ、俺が思っているのと多分同じだ。」

Aさん「問題は・・・。」

たろーAさんなぜ開発環境では性能問題が出なかったのか?

 

今回はここまで。
次回は、なぜ開発環境では性能問題が出なかったのか?
その謎に迫ります。

 

投稿者プロフィール

たろーちゃん
たろーちゃん
株式会社システムサポート インフラソリューション事業部に在籍するPlatinumホルダー。
Oracle Databaseのパフォーマンスチューニングを得意とする。
データベースは Oracle 以外興味がないという変わり者。
一番嫌いなエラーメッセージは CRS-02625。
連載「心臓外科医の術式」を執筆。