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

Copyright (c) 1982, 2007, Oracle. All rights reserved.

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のレビューでも好意的なコメントをいただけており、ほっと一安心といったところです。

[…]

メインフレームとかは真面目に勉強しといたほうが良いかも

メインフレームとかは真面目に勉強しといたほうが良いかも

via 読書記録ChageLog

WOMeetingでのkawasakiさんのお話などを聴くと、 UNIX, Windows, IAアーキテクチャといった現状のIT基盤はイマイチ信用にかけると思わざるを得ない。IT基盤の究極の姿はメインフレーム的な機能・特性を持つものになるのかなと。

ちょっと勉強したい・・・が、どうやって?何のために?

ま、自身の技術的な興味はさておき、ユーザーのニーズにこたえるIT屋の立場にたって考えると、 キチンとしたIT基盤の上で仕事がしたい。とか思いませんか?

IT基盤がある程度の予見性をもった、信頼に足る基盤であるためには、メインフレーム的な基盤が必要であるように思える(素人なので話半分で・・・)。 とすると、いつかはメインフレーム的な基盤を使用することが一般的になるはず。 が、ここらへんの技術がコモディティ化してくるのは、一体いつになるんですかね・・・。 ユーザーがメインフレーム的な特性が実現できるよう、IT技術サプライヤに強く求めていくような構図ができないと、歩みはゆっくりにならざるを得ないでしょうね。

> 素人目で見ても仮想OSでは長い歴史のあるメインフレームOSの > 仮想OS機能を知るのが第一歩だと思いますが。 > もちろん一番気の毒なのは、UNIX系だけがOSだと思いこんでいる > 人たちによるOSの授業や、研究指導を受ける学生さんたち。

うーん、メインフレームと大学って、なんで相性が悪いんでしょうか・・・ 確かに大学(某旧帝大)時代のコンピュータ系の研究室って2パターンに分かれていたような気がします。

* *BSDマンセー * プロセッサアーキテクチャ(?)

メインフレームはあまり扱ってなかったような気がします。なぜかUNIXが主流。 なんつーか、UNIXって一種のカウンターカルチャー的な部分を持つからそれが大学のカルチャーにマッチしたのかな?

トランザクション関連書籍

手持ちのトランザクション関連書籍をまとめてみる。なんとなく。

比較的わかりやすい。

難しい。

ほとんど読めてない。

OLTPシステム―オンライントランザクション処理

これまた難しい。

オススメできる。

追記@2005/06/03 ちょっぴり詳しいレビューはこちら

JTAに関連する箇所を拾い読みしただけ。

### PoEAA 4th

* 次回開催までに、なんかしら読めたらいいな&ネタ提供できたらイイなっと。

その他気になる点

* DIコンテナ利用を前提にしたトランザクション処理 * LL(PHP, Perl, … )な人のトランザクション処理 * RDBMS分離性の使い分け

[…]

XAエミュレート対象となるリソースマネージャの扱い

from S2.2.9 リリース – koichikのひとりごと > 例えば XA に対応した Oracle (Oracle が提供する XADataSource を使用する) と対応していない HSQLDB (S2 が提供する XADataSource で XA をエミュレートする) を同一のトランザクション中で更新する場合,最初に HSQLDB からコネクションを取得することで,二つの DB がどちらもコミットされるかどちらもロールバックされるかという原子性 (ACID の A) が実現できます.

なるほどーそういうことか。理解できました! ありがとうございます! koichikさん。

### 昨日の質問 昨日のJ2EE勉強会(仮)で、以下の質問をさせていただいた。(若干、わかりやすく整理しています。昨日はもっと要領を得ない質問な感じ(苦笑)でした。)

> S2JTAの枠組みの中で、XA非対応のリソースマネージャを扱う場合、XAをエミューレートするラッパ経由で扱うことになるようだが、その場合、 > XA非対応のリソースマネージャ1つがJTA配下のトランザクションに参加している場合、1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ1つの場合、通常の1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ2つ以上の場合、2フェーズコミットプロトコルを使用する >

> という理解でよいか?

なるほど、S2JTAの実装はLast Resource Commit Optimizationの機構を持っているため、 1番目、2番目の内容は正しいようだ。ただ、koichikさんの日記にかかれてあるように、

> Last […]

J2EE勉強会(仮)

J2EE勉強会(仮) – ひがやすを blog

参加してきた。

内容は、

* Seasar2のJTA実装、コネクションプール実装をソースコード中心に追っかける * JSFの特徴・アーキテクチャをPPTで説明する

でした。説明はすべてひがさん。お疲れ様でした&ありがとうございました。

[…]

ほんたったがほしいがいじんさん

仕事を終えてから、明日のズラ会に備えてファミレスでJava Transaction Processingを読んでいた。 いつもと同じように、X31と書見台:ほんたった、ポストイットがお供。 そして、本の内容や目次、不明な用語などをExcelにまとめつつ、読み進めた。

この本の対象はトランザクションという分野であるため内容が多少概念的だし、英語で書かれているから、読むのにちょっと時間がかかる。今日は無理に読み進めることはせず、JDBCとXAResouceの関係、JTAの代表的なインタフェースであるUserTransaction, TransactionManager, Transactionの関係と、UserTransactionとTransactionManagerの相違点に触れている箇所を抜粋して読んだ。 これらの位置づけを大体理解したので、明日のズラ会で不明な点、理解があいまいな点がクリアになることを期待しようかなと。

さて、本題。

自分は、よくファミレスで本を読むのだけど、そのときは、

* Thinkpad X31をたたきながら、 * 本を書見台:ほんたったに載せて、 * ポストイットを手元に置いて

という感じでやっている。結構大掛かりな感じであって、ちょっと目立つ。でも便利なので、気にしないことにしている。

当然、今日もこんな感じでやっていた。

今日は遠くから熱い視線を感じる・・・。と思ったら、遠くの席の外人さんにチェックされているようだ。 そんなに物珍しいかね? ま、気にせずに本を読んでいたのだけど、2時になったので帰宅することにした。 レジに向かう途中、その外人さんが近寄ってきて、たどたどしい日本語で・・・

.NETエンタープライズWebアプリケーション開発技術大全 Vol.5 トランザクション設計編

Amazonマーケットプレイスで安価に販売していたので衝動買い。 実は昔から気にはなっていたのだけど、プラットフォームが.netだったので買うのを躊躇していた。 内容はかなりイイ。.netに関係しなくても、トランザクション設計について悩みがある人は、立ち読みして内容を試し読みするぐらいの価値はありそう。私に関しては、少なくとも値段分の元は取れそうな感じである。 .netフレームワークでエンタープライズアプリケーション開発をする人は必読ではないだろうかね。カナリお勧めできます。

以下に、この本の良い点をあげる。

まず第一に、アプリケーション開発者の立場で書かれている点がある。 ACIDなどのトランザクションそのものの概念や、RDBにおけるトランザクションを論じた・解説した書籍は数あれど、アプリケーション+RDB or/and … で構成されるシステム全体においてトランザクション設計をどのように行うか?を論じた本は少ない。和書だと皆無に近いのではないだろうか?この本は、その領域をターゲットとしている。

第二に、トランザクション、同時実行制御、ロック、分離性など、初学者が混同しがちな概念を整理して語っている点。 私は、SQL Serverにおいて、分離性を変えることでどのようにロックの保持期間が変わるか?取得するロックの種類が変わるか?の説明が面白く感じた。(2.2 分離レベルによるロック挙動の変化) 恥ずかしながら、分離性の概念がどのように実現されているかをキチンと理解していなかったため、この箇所を興味深く読ませていただいた。ロック保持に関する概念図とEnteprise Managerのロック状態表示画面を多用して丁寧に解説されているため、非常に理解しやすくなっている。すばらしすぎます。

第三に、わかりやすさを優先しつつも、正しさにも配慮している点。 本書では、おそらくわかりやすさのため、多少の厳密さを犠牲にした記述がされている。 本文で犠牲にした厳密さを補うため、筆者の愛情こもった脚注がたくさん記してある。これまた、すばらしい。

第四に、「くーす」に近いステートレスなクラス設計を説いている点(笑)。 まぁ、COM+の流れから当然なんですが、MSの立ち位置は「ビジネスロジックはステートレス」というもの。

筆者は、これを踏まえつついくつかの補足的な説明をしており、その結論として、 「エンティティ中心のオブジェクト指向設計は、スタンドアロンのシングルユーザアプリケーションに向いているケースが多いが、WebアプリケーションやWebサービスのような、サーバサイドのOLTP型マルチユーザアプリケーションには適していない。」と整理している。まったく持ってそのとおりと感じている。

第五に、具体的なアプリケーション毎に、設計方針を示している点。 対話型アプリケーション、バッチアプリケーション、キュー型のアプリケーションなどのに対して ある程度具体的な指針を示している。(ただし、本書の中で著者が述べているとおり、「定式化が難しい」ため、さすがに「この記述に従えばうまくいく!」という内容までにはなってない。というか、なりえないよね・・・。)