http://www.csus4.net/d about Enterprise IT, Oracle Database, Jazz/Fusion Music, etc... Sun, 09 Nov 2008 09:22:41 +0000 http://backend.userland.com/rss092 en 今回のentryでは、「SECTION I Oracleアーキテクチャ概要」の「CHAPTER 02 クライアントアプリケーションとサーバープロセス」について補足説明します。 この章では、SQL*PlusなどのOracleに接続するアプリケーションである「クライアントアプリケーション」 とクライアントから指示に従い実際に処理を実行する「サーバープロセス」について説明しています。 あるクライアントアプリケーションがOracleに接続すると、そのクライアントアプリケー ション専用のサーバープロセスが起動します。 ここで、クライアントアプリケーションとサーバープロセスの間に設定されるコネクションを、 Oracleではセッションと呼びます。 これらについては、書籍で説明したとおりですが、このentryでは、 Linux上でクライアントアプリケーションとしてSQL*PlusでOracleに接続した場合を例に、 クライアントアプリケーションとサーバープロセスの関係について、 プロセスの相互関係、セッションの観点から確認してみます。 まず、SQLPlusを起動して、connectコマンドでOracleに接続すると、サーバープロセス が起動します。 これは、SQLPlusにおいて、fork()、exec()システムコールを実行することで、 プロセスが複製され、複製されたプロセスの実体がoracleプログラムに変わるためです。 このような処理を行うことで、サーバープロセスに対応したプロセスが新規に作成されます。 そして、このサーバープロセスはSQLPlusの子プロセスとなり、 サーバープロセスとSQLPlusは子プロセス、親プロセスの関係をもちます。 そして、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 / as sysdba 接続されました。 SQL> このとき、pstreeコマンドを使用して、プロセスの親子関係を確認してみます。 [o11106@hp1 ~]$ pstree -p -a o11106 bash(9438) (略) sshd,9667 ... http://www.csus4.net/d/2008/11/09/chapter-02-%e3%82%af%e3%83%a9%e3%82%a4%e3%82%a2%e3%83%b3%e3%83%88%e3%82%a2%e3%83%97%e3%83%aa%e3%82%b1%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3%e3%81%a8%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc%e3%83%97%e3%83%ad/ 私が中心になって執筆した書籍 「プロとしての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プラットフォーム での説明とせざるをえませんでした。 Windows版OracleではOracleのプロセス（バックグラウンドプロセス、サーバープロセス）は Oracle.exe内のスレッドとして実装されているため、容易に確認できないこと Windows版Oracleでは、OracleDatabaseサービスを起動すると、デフォルトでインスタンス も自動的に起動してしまうするため、「インスタンス未起動」→「インスタンス起動」の 流れを説明しにくいため（※: 一旦インスタンスを停止してから、インスタンスを起動する必要がある。） 本書の冒頭部分の、まだ「データベース」や「インスタンス」について理解ができていない 時点で、UNIX/Linux版OracleとWindows版Oracleの実装上の違い（スレッド、プロセス、OracleDatabaseサービス） について触れることは理解の点で混乱を招く可能性が高いこと ここでは、P17の内容をWindows版Oracleを使って説明してみることにします。UNIX/Linux版OracleとWindows版Oracleのアーキテクチャの違いについて理解の度合いを確認してみてください。 コマンドプロンプトでの実行例を以下に示します。 C:\>net start OracleServiceO111 ... http://www.csus4.net/d/2008/11/07/proarch_chap01/ （なんと前回のエントリから3年近く間が空いてしまいました・・・） Oracle Database のアーキテクチャについて説明した書籍「プロとしてのOracleアーキテクチャ入門」を 執筆するお話をソフトバンククリエイティブ社様よりいただき、 同じ職場のOracle暦10年のベテランエンジニアの方と共同で執筆作業をすすめ、 2008/8/22に（なんとか）無事出版できました。 ソフトバンククリエイティブの本:プロとしてのOracleアーキテクチャ入門 Amazonのレビューでも好意的なコメントをいただけており、ほっと一安心といったところです。 執筆のお話を頂戴したのは、2007年の年末で、当初のプランでは ゴールデンウィーク前に執筆を終えるはずだったのですが、 紆余曲折あり執筆に半年以上の期間を要してしまいました・・・。 しかも、ページ数は（おそらくシリーズ最大の）400ページ。 長期間に渡る執筆において、大量の原稿に対して的確なフォローをしていただけた 編集の方にはとても感謝しております。ありがとうございました！ 目次 INTRODUCTION なぜOracleのアーキテクチャを学ぶのか SECTION Ⅰ Oracleアーキテクチャ概要 CHAPTER 01 データベースとインスタンス CHAPTER 02 クライアントアプリケーションとサーバープロセス CHAPTER 03 データファイルと関連する構成要素 CHAPTER 04 REDOログファイルとREDOデータ CHAPTER 05 サーバーパラメータファイルと制御ファイル CHAPTER 06 Oracleのメモリ管理 CHAPTER 07 その他の構成要素 SECTION Ⅱ スキーマオブジェクトとデータ格納方式 CHAPTER 08 ユーザーと権限 CHAPTER 09 テーブルとデータ型 CHAPTER 10 索引の仕組み CHAPTER 11 その他のオブジェクト CHAPTER 12 オブジェクトの格納方式と記憶域 SECTION Ⅲ SQL処理の仕組み CHAPTER 13 問い合わせ処理の仕組み CHAPTER 14 更新処理の仕組み SECTION Ⅳ トランザクション処理 CHAPTER 15 トランザクションの概要とACID特性 CHAPTER 16 Oracleのトランザクションと隔離性 CHAPTER 17 Oracleのロック機能 SECTION Ⅴ 起動・停止とリカバリの仕組み CHAPTER 18 インスタンスの起動と停止 CHAPTER ... http://www.csus4.net/d/2008/10/13/proarch/ Joel on Software 業務都合によりあまり時間が取れませんでしたが、私もレビュワーとして協力させていただきました。 この本、本当にいい本です。 第一線でプロとしてソフトウェア開発を行う全員に読んでほしい。 強くそう思います。 超オススメです。 文句なく、自身が読んだ中での今年のNo.1書籍といえますね。 http://www.csus4.net/d/2005/12/16/joel-on-software-ja/ そろそろポジションペーパ書きに飽きて来たので手抜きをしてしまいました。 いかんですね。 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 Map Fawlerの語りの意味を読み解く作業は不毛感ありまくりな気がするなぁ。 FawlerはIdentify Mapをキャッシュと密接な関連を持つものと位置づけているようだ。 Lazy Load t-wada さん、相変わらずすばらしい発表ですね・・・。構成がイイ！なんというか、つかみがうまいんですよねー 具体的な事例、コードを見る視点と、抽象的なレベルでのアーキテクチャの捉え方の視点をいったりきたりする感じがとてもイイ！です。 WRサーガ：非TM対応RM, キュー形トランザクション ちょっと仕込みが足りなかった感じ。反省 べき等のあたりの説明って、理解できました？　＞　皆様 あれ？　困ったときのkoichikさん頼り　ができないじゃん！・・・と思ったらafukuiさんがいらしていたので・・・よかった！助かった！ 【お願い】TM未対応RMの実行順序を工夫するあたりで、中村さん（？）が言っていた内容がよく聞こえなかったのですが、誰か教えてもらえません？ 次回で無事終わることができる・・・かもしれない。 http://www.csus4.net/d/2005/12/06/pofeaa8th/ （佐藤正美氏新刊出版記念）新T字形ER手法「TM」で始めるシステム分析セミナー　　～短納期・高品質・低投資時代への対応～ あるみたいです。 TM/T字形ER手法に興味がある方は是非。 http://www.csus4.net/d/2005/10/27/tm-seminar-1110/ 参加してきました。今回は発表はなしでした。 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) ・・・性の・・・について記述する。」とか。 懇親会 獄長！獄長！獄長！ry) http://www.csus4.net/d/2005/10/24/pofeaa-7th/ 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メソッドを実装しているクラス群が何でもコマンドパターンというのは違うと思いますがね。 インスタンスにデータとロジックがパッキングされていることがポイント。 と思いますよー。と、気弱にまとめてみた。 http://www.csus4.net/d/2005/09/19/comannd-pattern-and-strategy-pattern/ PofEAA's Wiki - PofEAA読書会第6回 行ってきた＆少しお時間をいただけたので、発表しました。 サーガ .NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)" 箇条書きにて。 時間15分もらえた。 OHPは5ページ進んだ 残り30(!)ページ サーガの定義について鋭いツッコミ いやー書籍における定義は、自分も怪しいとおもっていのたのだよねーと。（→OHP該当ページの一番下の行を見られたし） 補償トランザクションの補償は電話（＝運用対処） 補償トランザクションの実現イメージ 純粋OLTP系処理なら黒伝＋赤伝なるイメージとなる。トランザクションデータ（=取引系データ)に、通常の取引系データ（黒伝）と、打ち消し用取引系データ（赤伝）なる2種類を用意しておき、アプリ側では、赤伝が存在する場合は、黒伝がないものとして扱うようにする。など。 ただ、ただ、大量データを扱うバッチの場合は実現方法にもう一工夫必要となりそうな気がする。 また、正方向のトランザクションと、補償トランザクションの時間差も重要。Webサービスとの絡みで論じられるロングトランザクションは、純粋なトランザクションの観点では同様であるけれども、オンラインバッチの補償トランザクションとは、時間がカナリ異なる。 これらの意味で、当日の議論は若干ずれていた気がする。その場では、理解した気になっていたのですが。すまぬ。＞皆様 バッチでキャッシュは怖い よねー。やっぱり。 いろいろ yyamanoさんのPCの壁紙がカッコイイ。（覗き見したった。） 議論の参加者が増えていい感じ。 整理も必要かもと、ちょっとおもったが、ドメインモデルのあたりの話は複雑すぎて、参戦できず・・・。実装センスが弱いな。＞俺 感謝 あれだけの大人数なのに、一体感をもって進められたのは、絶妙な座席配置に資する部分も大きいかと。ありがとうございます。＞オージス軍団の方々。 → GLADさんとkukutaniさんの工夫みたい。すばらしいです。ありがとうございます。 http://www.csus4.net/d/2005/09/11/pofeaa-6th/ 渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - レファレンスモデル 公開されたようです。 http://www.csus4.net/d/2005/08/31/conceptware-accounting/