X

オラクルエンジニア通信では、オンプレミスからクラウドまで、オラクルテクノロジーの最新情報をお届けします

オラクルコンサルタントが教える「最低限のSQLコーディング・ルール」4箇条とその例

Oracleのパラレル処理は簡単?速くなる?

「最低限のSQLコーディング・ルール」は大きく4つのカテゴリに分かれます。

それぞれ例を挙げていますので、ルール策定の参考にしてみてください。


1. アーキテクチャに伴う性能問題を避けるためのルール


例:「バインド変数の使用」

指針

  • WHERE句に条件を指定する場合は、バインド変数を使用する

理由
  • 一般にOLTP系では、バインド変数を使用しない場合、本来必要でない再解析が多発し、CPU負荷の上昇や、共有プール内の他のSQL用の解析結果を追い出すことによるDB全体のスループット低下を招く可能性が高くなるためです

注意点
  • アプリケーションでSQLを生成するような場合には特に注意してください。SQLの内部に値を直接付け加えるのではなく、(JDBCであれば) setInt、setStgring 等を使用し、必ずバインド変数を使用してください
  • なお、このルールは一般にOLTP系のガイドです。DWH系のシステムでは、バインド変数を使用せずに、値データの異なるSQLを共有させず、SQLごとに最適な実行計画で処理を行った方が性能がよい場合もあります


2. 使用方法やノウハウを元に性能問題を回避するためのルール


例:「ビューに対する結合の回避」

指針

  • ビューとビューの結合やビューと表の結合は避ける。このような結合によりデータを取得したい場合はビュー定義を参照し、ビューの元表を使用してSQL文を記述する

理由
  • ビューを結合に用いると、データを取得するために必要な本来の表以外の余計な表にアクセスする可能性があります。このような状況が生じた場合、直積結合の発生等で、必要以上のデ
    ータアクセスが発生し、性能問題が発生する可能性があります


3. 可読性や管理性を高めるためのルール


例:「管理用コメントの付与」

指針

  • SQLに管理用コメント追加する。管理コメントの命名規則を定義し、それに従ってコメントを記載する。どのモジュールからどのような目的で発行されたものであるかが分かるような命名規則にしておく必要がある

理由
  • 管理用コメントを記載しておくことで、チューニングやデバックの際に原因SQLを発行しているプログラムの特定が容易になります。また、SQLの発行状況などのトレンド把握も容易になります

注意点
  • 管理用コメントをあまりにも細かく分類すると、解析情報を共有すべき“同一のSQL”が同一でなくなってしまう懸念があります。プログラムやSQLを特定するのに必要十分な区分で、管理用コメントを付加します
  • 汎用的なSQLが、コメントによって、“同一のSQL”でなくなってしまっては、本末転倒です。汎用SQLに対するコメントも命名規則を定義しておく必要があります


4. 運用ポリシーをコーディングに反映させるルール


例:「ヒント句の使用を検討する」

指針

  • SQL内にヒント句の使用を検討する

理由
  • アプリケーションロジックから、SQLを外部ファイルに記載しておいたものを呼び出す運用を行っているので、SQLチューニングの判断によりヒント句を使用して改善を行うことを検討します
  • SQLのパフォーマンス管理は、業務チームが最終的に判断して行ってください。しかし、業務チームの判断のみでヒント句を追加することは禁止します




参考資料

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.