IT « WR blog

Developers Summit 2009でお話させていただきます！

* [Development Style（DB)](http://www.seshop.com/event/dev/2009/timetable/Default.asp?mode=detail&eid=124&sid=761&tr=13%5FDevelopment+Style%81iDB%29#761)

なんとDevelopers Summit 2009(2/13(金) 13:10?14:00 at 目黒雅叙園)にてお話させていただくことになりました！講演のタイトルは「プロとしてのOracleアーキテクチャ入門 ?番外編?」です。来場される方の担当業務としては、DBA、インフラ設計よりはむしろ SQL/プログラム開発の方が多いのかなという判断で、 SQL実行/チューニングにまつわる Oracleアーキテクチャについてお話させていただきます。書籍「プロとしてのOracleアーキテクチャ入門」でいうと、「CHAPTER 13 問い合わせ処理の仕組み」＋αの内容になると思います。

「テクノロジーの変化を体感するためのDevelopmentStyle 2.0」というテーマに沿うよう、11g新機能や知られていないテクノロジを紹介できるように準備を進めていますが、SQL/プログラム開発の方にターゲットを絞っている関係上、内容的には基本的/基礎的なものになるかと思いますので、この点、あらかじめご了承ください。

さて、具体的には、以下の内容についてお話させていただく予定です。

* SQL実行のためのOracleアーキテクチャ * 実行計画とCBO * ヒストグラムと最適なアクセスパス * SQL開発におけるOracleアーキテクチャ特有の注意点 * オプティマイザ統計の重要性 * 共有プールのflush * バインドピーク

それでは、当日会場でお会いできることを楽しみにしています。

CHAPTER 02 クライアントアプリケーションとサーバープロセス – プロとしてのOracleアーキテクチャ入門

今回のentryでは、「SECTION I Oracleアーキテクチャ概要」の「CHAPTER 02 クライアントアプリケーションとサーバープロセス」について補足説明します。この章では、SQL*PlusなどのOracleに接続するアプリケーションである「クライアントアプリケーション」とクライアントから指示に従い実際に処理を実行する「サーバープロセス」について説明しています。

あるクライアントアプリケーションがOracleに接続すると、そのクライアントアプリケーション専用のサーバープロセスが起動します。ここで、クライアントアプリケーションとサーバープロセスの間に設定されるコネクションを、 Oracleではセッションと呼びます。これらについては、書籍で説明したとおりですが、このentryでは、 Linux上でクライアントアプリケーションとしてSQL*PlusでOracleに接続した場合を例に、クライアントアプリケーションとサーバープロセスの関係について、プロセスの相互関係、セッションの観点から確認してみます。

まず、SQL*Plusを起動して、connectコマンドでOracleに接続すると、サーバープロセスが起動します。これは、SQL*Plusにおいて、fork()、exec()システムコールを実行することで、プロセスが複製され、複製されたプロセスの実体がoracleプログラムに変わるためです。このような処理を行うことで、サーバープロセスに対応したプロセスが新規に作成されます。そして、このサーバープロセスはSQL*Plusの子プロセスとなり、サーバープロセスとSQL*Plusは子プロセス、親プロセスの関係をもちます。そして、2つのプロセス間にパイプと呼ばれるプロセス間通信路を設定します。すなわち、セッションはパイプにより実現されるわけです。

ここで説明した動作を実際に確認してみましょう。まず、SQL*Plusを実行して、Oracleに接続してみます。

[o11106@hp1 ~]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 – Production on 日 11月 9 15:36:10 2008

SQL> connect […]

CHAPTER 01 データベースとインスタンス – プロとしてのOracleアーキテクチャ入門

私が中心になって執筆した書籍「プロとしてのOracleアーキテクチャ入門」について、紙幅や構成上の制約で触れることができなかった点、誤記などについて、各章ごとに補足説明をしたいと思っています。

今回のentryでは、「SECTION I Oracleアーキテクチャ概要」の「CHAPTER 01 データベースとインスタンス」について説明します。この章では、OS上のファイルの集合として構成される「データベース」と、 OS上のプロセスとメモリとして実現される「インスタンス」について取り上げています。

ファイルはlsコマンド(UNIX/Linux)や、エクスプローラ(Windows)にて実際に確認できますから、「データベース」についてはイメージしやすく実感がわきやすいものと思います。

しかし、プロセスとメモリとして実現される「インスタンス」については、理解がしにくいかもしれません。このため、書籍のP17 では、UNIX/Linux版Oracleを例にとり、 psコマンドやshow sgaコマンド(SQL*Plus)の実行例を記載することで、理解を助けるように工夫しています。読者がより親しんでいるであろうOSのWindows版 Oracleを例にとり説明できればよかったのですが、以下の理由でUNIX/Linuxプラットフォームでの説明とせざるをえませんでした。

[…]

書籍「プロとしてのOracleアーキテクチャ入門」を執筆しました

（なんと前回のエントリから3年近く間が空いてしまいました・・・） Oracle Database のアーキテクチャについて説明した書籍「プロとしてのOracleアーキテクチャ入門」を執筆するお話をソフトバンククリエイティブ社様よりいただき、同じ職場のOracle暦10年のベテランエンジニアの方と共同で執筆作業をすすめ、 2008/8/22に（なんとか）無事出版できました。

* [ソフトバンククリエイティブの本:プロとしてのOracleアーキテクチャ入門](http://www.sbcr.jp/books/products/detail.asp?sku=4797349801)

Amazonのレビューでも好意的なコメントをいただけており、ほっと一安心といったところです。

[…]

Joel on Software

業務都合によりあまり時間が取れませんでしたが、私もレビュワーとして協力させていただきました。

この本、本当にいい本です。

第一線でプロとしてソフトウェア開発を行う全員に読んでほしい。強くそう思います。

超オススメです。文句なく、自身が読んだ中での今年のNo.1書籍といえますね。

PofEAA 8th

そろそろポジションペーパ書きに飽きて来たので手抜きをしてしまいました。いかんですね。

### Unit Of Work : まさゆきさん

* Hibernate との比較で語られていたので、わかりやすかったように思う。 * ちなみに、EOF/WebObjects関連の資料は、WebObjects基礎研究室とか、WebObjects関連プレゼン資料にあります。

#### ちょいとHibernateに対する疑問 * 1 Request = 1 Sessionなる考え方にどうもなじめないなぁと。EOF/WebObjectsの1 HTTP Session = 1 Unit of Workの方がシンプルな気がするのです。なぜなら、複数画面に渡る編集機能を実現することを考えた場合を考えると、いちいちdetachしてattachするのが面倒に思えるので。（と某mixi日記に書いたのですが、獄長から「Hibernateでも1 HTTP Session = 1 Unit of Workでつかえるよん」とツッコミが。1 Request = 1 Sessionと1 HTTP Session = 1 Unit of Workを使い分けるというのがよい？） * なんであんなにListenerが必要なのだろうか？実行の順序性に意味がありそうな一連のオペレーションを、Event, Listenerモデルで構築する意味がわからない・・・

### Identify […]

佐藤正美氏新刊出版記念セミナー

（佐藤正美氏新刊出版記念）新T字形ER手法「TM」で始めるシステム分析セミナー ?短納期・高品質・低投資時代への対応?

あるみたいです。 TM/T字形ER手法に興味がある方は是非。

PofEAA 7th

参加してきました。今回は発表はなしでした。

### TableDataGateway (わたなべさん) 読書会の議論でも発言させていただきましたが、TableDataGatewayは（非常に荒いレベルの）オブジェクトの設計方針について、わかりやすい指針を示しているものに過ぎないと考えます。

* 具体的な対象と照らし合わせた上での、責務の範囲 : 具体的には・・・RDBの構成要素（テーブル、カラム、複数テーブルなど）を相手にするGateway一般の中で、TableDataGatewayは、テーブル（もしくはテーブル類似のビューなど）を相手にする。責務の範囲をテーブルとする * クライアントから見た場合のインスタンス関係。もっと言えば、アイデンティティ。：具体的には・・・TableDataGatewayは1テーブルにつき1個。（テーブルの数は簡単に数えられる（苦笑）ので、インスタンスのアイデンティティも容易に理解できる）

### RowDataGateway (和田さん) あとで書きます。

### ActiveRecord(inoueさん) Railsのデモが中心。やっぱRailsすげー！

ちょっと気になったのは、Railsの実行モデル。あれだけ評価・処理実行・自動生成が走るとなると、CGIでは・・・きついよね。多分。

### 議論を聞いて。ビジネスロジックの割り当て、データアクセスの議論が混在している印象。ここは分けて話さないとまずいっす。

せっかくファウラーたんが、整理してくれているのだから。（わかりにくいけど）

### 角谷さんの意見に同意わからない部分を曖昧に、抽象的に触れて流すよりも、わからない部分を明確に提示し、自分が理解できている（と思っている）部分を具体的に示すほうが良いと思う。ここはそれが許される「場」であると思います。

言い方を変えれば、せっかくなんだから燃料を投下しましょうよ。どんなに炎上しても誰かが整理してくれるし。となるかも。

### 資料（半）公開希望。再度資料を見て、記憶を呼び戻したいので。懇親会で酔っ払ったので、良く思い出せないというは秘密。

### 戦果 ogijun氏が蔵書の一部を販売していたので、以下の2冊を購入。

* ユースケース実践ガイド 1500yen : 最近、プロセス屋さんの世界で next ユースケースが熱いらしいので、あらためて基礎を抑えておこうかと。 * ソフトウェアエンジニアリング基礎知識体系 600yen : なんか、書き物書くときに便利そうじゃない？たとえば・・・「IEEE xxx では、?における特性として、a) ・・・性、b) ・・・性、c) ・・・性、が求められている。本ドキュメントでは、a) ・・・性の・・・について記述する。」とか。

[…]

コマンドパターンとストラテジパターン

PofEAA 読書会で話題になったので。

シンタックス的に利用する機構（＝多態性）が同じこの2つのパターン。思うところをつれづれと書いてみたりする。

### コマンドパターン * マクロでみた意味的には、そのインスタンスにコマンド実行（処理実行）に必要なデータと、ロジックを詰め込むようなイメージ。 * 必要なデータとロジックがインスタンスにパッキングされているがゆえに、1番目の処理Aと2番目の処理Bと3番目の処理Aを実行したい場合は、処理Aに対応したインスタンス＋処理Bに対応したインスタンス+処理Aに対応したインスタンスをキューなどに並べておき、順次実行すればよいこととなる。 * コマンド実行のトリガを与えるクライアントが、コマンドのインスタンス以外に気を使わなくて良い点がポイント。コマンドクラスが、そのコマンド実行に必要なデータ、ロジックをカプセル化して保持しているから。 * さらに、コマンド実行を取り消す（アンドゥ）ために必要なデータと、ロジックも詰め込むようにすることで、アンドゥ処理が可能となる。 * OOPの意味的な観点でいうと、コマンドパターンは「インスタンス」に意味がある。 * 具体的には、同じMoveCommand(dx, dy)でも、new MoveCommand(5,10)と new MoveCommand(-10,20)は、処理内容が異なる。 * 多態性は、クライアントが異なるコマンド種別を統一的に実行できるために活用される。 * Command cmd = queue.getCommand(); cmd.execute()

### ストラテジパターン * マクロで見た意味的には、ロジックをプラガブルにしたようなイメージ。インスタンスレベルで保持するデータにはあまり重きを置かれていない。 * クラスとか、インスタンスとかが本質的な意味でポイントにはならず、プラガブルな構成要素的な観点を持つものであればよい。 * OOPの意味的な観点でいうと、ストラテジパターンは「インスタンス」にあまり意味がない。 * プラガブルな機構を実現できれば、ストラテジが提供するメソッドはクラスメソッドでもかまわない。（暴論気味・・・） * 多態性は、クライアントの統一的な利用というよりは、プラグ差し替えを実現するための機構として利用される。本質は利用形態の一元化ではなく、差し替え可能性にある。

### 最近のコマンドパターン StrutsのActionFormをコマンドパターンとか言う人もいて、ちょっと違和感を感じていたりもするけど、まぁいいかも。という気もする。

HTTPリクエストの内容を、1つのインスタンスにパックしており、かつ、ビジネスレイヤの呼び出しというロジックも（一応）実装しているから。上記に話とも一応対応している。

が、キューに格納されるでもなく、アンドゥ機構を提供するでもない点がちょっと引っかかるかな。コマンドパターンのご利益を活用しているわけではないということ。

executeメソッドを実装しているクラス群が何でもコマンドパターンというのは違うと思いますがね。インスタンスにデータとロジックがパッキングされていることがポイント。と思いますよー。と、気弱にまとめてみた。

PofEAA 6th

PofEAA’s Wiki – PofEAA読書会第6回

行ってきた＆少しお時間をいただけたので、発表しました。

### サーガ .NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)”

箇条書きにて。

* 時間15分もらえた。 * OHPは5ページ進んだ * 残り30(!)ページ * サーガの定義について鋭いツッコミ * いやー書籍における定義は、自分も怪しいとおもっていのたのだよねーと。（→OHP該当ページの一番下の行を見られたし） * 補償トランザクションの補償は電話（＝運用対処） * 補償トランザクションの実現イメージ * 純粋OLTP系処理なら黒伝＋赤伝なるイメージとなる。トランザクションデータ（=取引系データ)に、通常の取引系データ（黒伝）と、打ち消し用取引系データ（赤伝）なる2種類を用意しておき、アプリ側では、赤伝が存在する場合は、黒伝がないものとして扱うようにする。など。 * ただ、ただ、大量データを扱うバッチの場合は実現方法にもう一工夫必要となりそうな気がする。 * また、正方向のトランザクションと、補償トランザクションの時間差も重要。Webサービスとの絡みで論じられるロングトランザクションは、純粋なトランザクションの観点では同様であるけれども、オンラインバッチの補償トランザクションとは、時間がカナリ異なる。 * これらの意味で、当日の議論は若干ずれていた気がする。その場では、理解した気になっていたのですが。すまぬ。＞皆様 * バッチでキャッシュは怖い * よねー。やっぱり。

### いろいろ * yyamanoさんのPCの壁紙がカッコイイ。（覗き見したった。） * 議論の参加者が増えていい感じ。 * 整理も必要かもと、ちょっとおもったが、ドメインモデルのあたりの話は複雑すぎて、参戦できず・・・。実装センスが弱いな。＞俺

### 感謝あれだけの大人数なのに、一体感をもって進められたのは、絶妙な座席配置に資する部分も大きいかと。ありがとうございます。＞オージス軍団の方々。

→ GLADさんとkukutaniさんの工夫みたい。すばらしいです。ありがとうございます。

WR blog

Recent Posts

Archives