SQL実行計画の変更その２(1/2)

2018年12月14日『心臓外科医の術式』

1 前回のおさらい
2 アプリケーション開発者からの相談
3 アプリケーション開発者も知らないSQL
4 謎のSQLの正体

前回のおさらい

前回『SQL実行計画の変更　その１』では、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さん「それで、開発環境で性能テストした時は何も問題なかったんだけど、いざ本番移行すると、性能問題が発生したんだ。」

たろー「シングルインスタンス構成よりも、２ノードRAC構成のほうが遅いってこと？」

Aさん「そうなんだ。シングルインスタンス構成で性能テストをパスできれば、２ノードRAC構成の本番環境でも問題ないと思ってたんだが…。」

たろー「うむ…。」

普通に考えればAさんの言う通りである。１台より２台のほうが、早くなりこそすれ、遅くはならない。私は、シングルインスタンス構成には無い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ひとりでできるもん運営チーム

「DBひとりでできるもん」運営チームです。
「親しみやすさと技術力」をテーマに、技術情報・サービス・インフラ系資格取得に役立つ情報、社員等の情報をお届けします。
70名弱の事業部員で鋭意、執筆中です。
少しでも当社を知って頂けるよう、愛情込めて頑張ります！
※facebook、X(旧twitter)、インスタグラムでは「DBひとりでできるもん」の更新情報を発信しています。