月別アーカイブ: 2014年8月

V$SQL_PLANでCRUD表モドキを作ってみる③

ここからはExcelで

前回のクエリーの結果をMicrosoft Excelのピボットテーブルを利用して集計してみましょう。(Excel2010での方法を説明します。)
今回はある架空アプリケーションにおける実績データを対象とします。

一番簡単なのはSQL*Plusの実行結果を以下のようにExcelのシートにコピー&ペーストするやり方です。

Excelにコピー&ペースト

 データをスペースで区切る

データ>区切り位置 で「区切り位置指定ウィザード」を呼び出し、「スペースによって右または左に揃えられた固定長フィールドのデータ」を選択して、データを区切ります。

区切り位置指定ウィザード

ピボットテーブルで集計

データを区切ったら、A〜C列(CRUD, SQL_ID, OBJECT_NAME)を選択した状態から、挿入>ピボットテーブル で「ピボットテーブルの作成(ウィザード)」を呼び出します。配置する場所が「新規ワークシート」となっていることを確認し、「OK」をクリックします。

ピボットテーブルウィザード

右側にピボットテーブルのフィールドリストを指定する画面が出てくるので、リストのそれぞれを下のボックスにドラッグして指定します。

  • レポートフィルタ: CRUD
  • 列ラベル: OBJECT_NAME
  • 行ラベル: SQL_ID
  • 値: CRUD(データの個数となっていることを確認)

ピボットテーブル設定

これで完成ですが、見やすくするためにテーブル名を90°回転させて列幅を揃える等の整形をします。

CRUD表を使ってみる

作成したCRUD表(モドキですが)は縦にSQL(SQL_ID)、横にテーブル名が並んだ表で、それぞれの交差部分に「1」が立っていれば、そのSQL文で該当するテーブルを使っていることを意味します。

まず、下図のB1カラム(レポートフィルタ)で「R」を選択し、SELECT文を見てみましょう。

1つのSELECT文で参照するテーブル数

例えば、SQL_ID = 2p8c09m8rupuk のSQL文は「ABCD_BHA」「NIC」「STU3」という3つのテーブルをアクセスしています。一番右端の総計欄を見るとSQL文でアクセスしているテーブル数の合計がわかります。(表を横に見ます。)

R1

この合計数が多いSQLはジョインしているテーブルの数が多い可能性が高いため、注目する必要があるものです。

あるテーブルを使用しているSQL文とその数

逆にあるテーブルから関連するSQL文とその数を確認するには、表を縦に見ます。

R2

上図の例では、「EFGH_DAY_OUT」というテーブルは一番下の総計欄が「34」になっています。これは34種類の異なるSQL文で使用されていることを示しています。

この数が多いということは

  1. 多くのSQL文でアクセスされるホットなテーブルである。
  2. バインド変数を使わないために類似SQL文が多数存在している。

という2つの可能性を示しています。

いずれにせよ、パフォーマンス・チューニングで注目すべきポイントになりますので、AWRレポート等他の情報と突き合わせて問題の特定を行うようにしましょう。

また、このあるテーブルに関係するSQL文の一覧を得ることは、テーブル定義の変更で影響を与える対象を把握するのにも役立ちます。

SQLテキストと実行計画を確認する

一覧ではSQL文を表示させていません。SQL_IDが特定できたら以下のSQL文を実行してSQLテキストと実行計画を確認します。

set pages 1000
set lines 140
select plan_table_output from table(DBMS_XPLAN.DISPLAY_CURSOR('<SQL_ID>'));

 

応用編

インデックス – SQL

V$SQL_PLANを使えば、テーブルとSQLの関係だけでなく、インデックスとSQLの関係を分析することもできます。

例えば、あるインデックスの定義を変更しようとする場合、1つのSQLだけに注目してしまうと他のSQLに影響があることに気づかず新たな問題を引き起こしてしまうかもしれません。

そのような場合、インデックスとSQLの相関表が役に立ちます。

DBA_HIST_*を使う

V$SQL_PLANもX$SQLAREAもメモリ(SGA)上にキャッシュされている情報です。従って、共有プールの使用率が高い場合等にはどんどんキャッシュから追い出されてしまい欲しい情報が得られない場合があります。

もし、AWRが使える環境であれば

  • V$SQL_PLAN → DBA_HIST_SQL_PLAN
  • V$SQLAREA → DBA_HIST_SQLTEXT

に置き換えれば、AWR(SQL)レポート保存期間以内のデータが保証されますので、事後解析でも有用なデータが得られます。

念のためAWR版の情報取得SQLを以下に紹介します。

select
 decode(CRUD_TYPE_ID,2,'C'
                    ,3,'R'
                    ,6,'U'
                    ,7,'D') CRUD
,SQL_ID
,OBJECT_NAME
,OPTIONS
from
(
select distinct
 SQL_ID
,OBJECT_NAME
,decode(operation,'TABLE ACCESS',3
                 ,'UPDATE',6
                 ,'DELETE',7) CRUD_TYPE_ID
,OPTIONS
from
 DBA_HIST_SQL_PLAN --V$SQL_PLAN
where OPERATION in ('TABLE ACCESS','UPDATE','DELETE')
and   OBJECT_OWNER ='xxxx'
union all
select
 SQL_ID
,ltrim(
  replace(
   upper(
    substr(
     regexp_substr(DBMS_LOB.SUBSTR(SQL_TEXT, 1000, 1),'INTO[[:space:]]+[^[:space:]\(]+',1,1,'i')
        ,6)
         )
    ,'"')
      ) OBJECT_NAME
,COMMAND_TYPE CRUD_TYPE_ID
,null OPTIONS
from
 DBA_HIST_SQLTEXT --V$SQLAREA
where COMMAND_TYPE = 2
) I
,DBA_TABLES D
where I.OBJECT_NAME = D.TABLE_NAME
and   D.OWNER       = 'xxxx'
order by
 CRUD_TYPE_ID
,SQL_ID
,OBJECT_NAME
;

最後に注意事項

V$SQL_PLAN等は負荷の高い状況ではアクセスしないことをお勧めします。DBAが手動で負荷状況を見ながら注意深く実行して下さい。

従って、スクリプトを組んで定期的に自動実行するような運用は行わない方が望ましいと思います。

すきやばし次郎は高いか?

20分3万円

今日はちょっと技術者の値段について考えたいと思います。

銀座に「すきやばし次郎」というミシュランの三ツ星を何年も獲得している伝説的な寿司屋があるそうです。
オバマ大統領の来日で一躍有名になりましたが、私は当然行ったことはありません。だから全部思い入れだけで書きます。

何でも、おまかせコースが3万円からだそうです。(この「から」というのがとても気になりますが。。。)
にぎり寿司が次から次へと無言で出てきて大体20分で(早い人は15分!!)食べ終わってしまい、お会計は3万円也です。驚きです!

ネットで検索したらこんな記事も見つかりました。
すきやばし次郎が20分3万円の寿司でも客が途絶えない本当の理由

文章を見た限りでは、この記事を書いた方は多分実際には食べてないでしょうし、実際にどんなお客さんが常連なのか調べたんでしょうか?

それにしても20分で3万円!時給換算で9万円!!その辺の回転寿司の店員の時給が1000円としても90倍です!!!

映画と本

2011年にはアメリカ人の監督が作った「二郎は鮨の夢を見る」という映画が公開され、私も最近WOWOWで観ました。

映画の中で私が最も印象に残った言葉は、店主の小野二郎氏が語った「お客さんの前に立った時には9割5分の仕事は終わっている。」というものです。
つまり、店主以外の店員が築地市場への仕入からネタの仕込みまで丹念な仕事をして、最後の5%の仕事は店主が握る熟練の技ということです。

それから「すきやばし次郎 旬を握る」という本を私も買って読みました。小野次郎氏は1925年生まれの88歳。寿司職人になって63年目だそうです。

この本には小野二郎氏が今まで培ってきた技術・経験のうち、文字や写真で語ることができる恐らく全体から比べるとホンの僅かな知識と技が満載です。

例えば、「第2章 本マグロを握る」ではP.97-158まで、本マグロの月毎の断面カラー写真やマグロに関する熱い想いなどがぎっしり詰まっています。何かに人生をかけるということはこういうことなのかと純粋に感動しました。

何度も言いますが私は「すきやばし次郎」に行ったことはありませんし、上の紹介記事のように私のような庶民には確かに行ってはいけない店なのかもしれません。

でも、映画と本を観て読んで、20分3万円の理由がちょっとだけわかったような気がしました。

いつ来るか分からない15分のための準備

我々エンジニアの仕事は一言で「知識集約職業」とでも言えるでしょうか?もちろん他の職業でも同じようなことは言えますが、この仕事は特にそうなのではないかと思います。

以前、ある企業から新人研修の講師として「Oracle入門」を6回シリーズくらいで教育を行うという仕事を請け負ったことがあります。大学を卒業したばかりで右も左もわからないというような集団でしたが、中に数人キラっと光る人達が居ました。

わからないことは積極的に質問してくるし、教えていないこともどんどん本を読んで吸収していく姿は本当に輝いていました。

最近その企業を5〜6年ぶりに訪問する機会があり、そんな教え子の一人と席を並べて仕事をする機会がありました。
今では技術的な打ち合わせもリーダーとして立派に取り仕切っているし、本当に生き生きと仕事をしていることを見て非常に嬉しく思いました。

私が教えた「Oracle入門」は現在の彼の業務とは直接関係ないのですが、机の上にはOracleの参考書が並んでいたり、私が少し専門的なことを話してもびっくりするくらいついてきてくれます。

逆に、かなり経験を積んだようなエンジニアでも時々がっかりする人がいます。知識はいろいろ豊富みたいなのですが、役立つ情報がサッと出て来ない。知識が整理されていなくて何を言っているのかさっぱりわからない。つまり本当に使える知識となっていないのです。

障害が起きた時に本当の姿が見える

IT運用はうまく行って当たり前の世界なので、極稀に起きるトラブル時にエンジニアの真価が発揮されるのではないかと思います。

トラブルシュートのためのコマンドが構文エラーのために実行できない!後ろでは「まだ復旧できないのか!」という無責任はギャラリー達。

こんな時に冷静に問題を分析して、何が間違っているのか知識をフル動員して見極める。こんなエンジニアが真のプロフェッショナルです。

自分の記憶だけに頼って間違ったコマンドを叩き続ける。なぜ冷静にマニュアルを見返せないのでしょう。それから安易にGoogle検索に頼るというのも考えものです。最初からGoogleに頼ると間違った情報に行き着くかもしれません。

Google検索を全面的に否定するわけではありません。最後の手段として活用するのはよいことだと思います。世界中の知識が集まっているのですから。

自分の知識データベースを育てよう

話変わって、「プロとは?」というテーマで最近「いつ来るか分からない15分のために常に準備をしているのがプロ、デザイナー奥山清行による「ムーンショット」デザイン幸福論」という記事を読みました。(これは「運用エンジニアから開発エンジニアになるためにやったこと」というなかなか秀逸な記事からたどっていったものです。)

いつ来るかわからない障害にあるいはいつ来るかわからない支援要請に備えて、プロフェッショナル・エンジニアとしての我々は何をすべきか?

  • 検証環境でとにかく手を動かして、コードを書く。コマンドを叩く。結果を確認する。
  • 文献を読んで重要な部分のコピーを手元に置いておく。
  • 経験・知識を体系的にまとめる

私はこのような用途には、Evernoteは最適な道具だと思います。

私のEvernoteには様々な知識情報が集積されています。「技術情報」というノートブックには1300件以上の「いつ来るかわからない」ことに対して役立つかもしれない情報(ノート)が蓄積されていて、日々増殖しています。

ノートはタグ付けされていて、探したいキーワードを入れると関連するノートが瞬時にピックアップされます。MacBookでまとめた情報はiPadでもiPhoneでもネットワークが繋がっていればどこでも見ることができますし、オフラインノートブックにしておけば電波が届かない場所でも参照することが可能です。

「自分だけのGoogle」これが理想です。

Evernoteを知らないエンジニアはとても不幸だと思います。

知っていても使うことができないエンジニアはもっと不幸です。私が知っているある大企業ではEvernoteのようなクラウドサービスはセキュリティ上の理由でご法度だそうです。

このような会社に限って社内サーバルームに設置してあるファイルサーバが使えなくなって大騒ぎになったりするんですね。

話がだいぶ逸れましたが、エンジニアのためのEvernote活用術は別途書きたいと思います。

結局、すきやばし次郎は高いか?

私がこの業界に入ってまだ日が浅かった頃、あるアプリケーション開発者が1日かけても解決できないことを5分足らずで解決してしまうスーパー・エンジニアが居ました。「ああなれたらいいな」と思って今日まできたと思います。

1日8時間として5分は約90分の1。次郎と回転寿司といい勝負です。でも、結局解決できないのであれば倍率は無限大です。

アマチュアに対するプロのエンジニア、生産性で比べたらミシュラン三つ星のすきやばし次郎にも匹敵する価値があるかもしれません。

価値を感じてもらえる。そんなエンジニアになりたいものです。

でも、一度は次郎に行ってみたい!