門外不出のOracle現場ワザ

第3章 データベース管理 転ばぬ先の杖~設計編

日本オラクル株式会社 コンサルティング統括本部テクノロジーコンサルティング本部 小田 圭二(おだ けいじ)

目次

Part2 インフラ設計チーム編

DBAの読者にとって、インフラ設計は最も馴染みのある部分だと思います。ここで言うインフラ設計とは、業務アプリケーションを動かす「土台」の設計のことです。DBに関しては物理設計、パラメータ設計、運用設計あたりのことを指します。そのため一般的に広く紹介されているノウハウは省略します。本パートは世の中に存在するインフラ設計のガイドを補足するものとして捉えてください。方式設計など関係する話も多くあるので、業務アプリ開発チームの方も、ぜひ本パートを参考にしてください。

方式設計を甘く見てはいけない

パフォーマンス問題と方式設計

パート1で説明した、業務チームが強く意識しなければならない要件の話以外にも、DBのパフォーマンスに関する“取り返しのつかない決定”が設計フェーズで行なわれることがあります。それはパート1でも述べた「方式設計」です。

RDBMSに持たせるべき役割や、システム全体における処理上の役割分担を見誤ってしまうと、取り返しのつかないパフォーマンス低下につながります。そして、それに気づいた時には実装も進んでいるでしょうから、簡単には変更できません。アプリケーションのログのようなもの、一時的にアプリケーションが使用するようなもの、画面をまたがって使いたい(その後捨てられる)データといったものは、本当にDBに格納する必要があるのか確認してください。

一般論として、そもそも同じ処理を行なったとしても、APサーバー上で処理する数倍以上のコストがDB上ではかかるものです。持っていただきたい考え方は、パート1で説明したのと同じです。RDBMS内で発生する処理をアルゴリズムの観点から考えて、妥当な方式設計かどうか考えてみてください。

図1は、処理量の違いのイメージをつかんでいただくための図です。

図1 RDBMSと自作の比較

図1 RDBMSと自作の比較

「一時的にデータを格納する」という機能をアプリケーション上で自作した場合と、RDBMSを使った場合で比較します(個々の処理は厳密ではありません)。この図から、RDBMSのほうがいろいろな処理を必要とすることが分かります。しかも、RDBMSの個々の処理は、アプリケーションで自作する場合と比べてブレイクダウンされていません。つまり、本当はもっと多くの処理が必要ということです。

耐障害性と方式設計

現実のプロジェクトにおいてインフラチームのDB担当者が困ることの1つに、運用が始まってからの耐障害性の向上があるのではないでしょうか。例えば、ハードウェア障害が発生してから6時間で業務が再開したとして、「それでは遅い。今後は30分で再開しろ」と言われ、耐障害性の向上を検討したが、「そもそもHA構成(コールドスタンバイ構成)になっていなかったため、どうやっても実現できない」というような話を聞きます。 また、コールドスタンバイ構成であっても1分という業務停止時間の実現を求められ、「ホットスタンバイ構成でなければ実現できないが、いまさら変更できない」という話も聞きます。万が一のときのバックアップメディアからのリカバリ時間も同じで、データ量やシステムの特性によってはリカバリに1日から数日かかるようなシステムもあります。

このように耐障害性は万が一に備えたものとはいえ、設計時にしっかり考えておかないと取り返しがつかない事項です。本件についてはTipsも参考にしてください。

TIPS:「できるだけ早く回復」の“できるだけ”って??

エンドユーザーに「目標ダウンタイムはどれくらいですか?」「DBが壊れたときはどれくらいでリカバリできればいいですか?」と質問すると、よく返ってくる答えが「できるだけ早く」です。一見、SIerやインフラチームにとって優しい答えに思えますが、筆者は違うと考えます。実際にトラブルになると「もっと早くリカバリできないのか」といった要求が上がってくるからです。

トラブルが起きてから時間短縮を考えても手遅れです。本文に書いたようにリカバリ時間やダウンタイムを抑えるためには、方式設計にまで遡らないと抜本的な解決ができないケースは多いからです。このダウンタイムやリカバリ時間も、要件のヒアリング時に確実に行なうべき項目です。ただし、現場の担当者にとって悩ましいのは、上層部にこの質問をすると非現実的な目標時間(と予算)が返ってきがちだということでしょうか……。

▲ ページTOPに戻る

インフラ設計の盲点

ここでは各種物理設計について説明します。読者の中には「物理設計は完璧さ!」という方も多いと思います。しかし、トラブルを防ぐという観点では意外と知られていないノウハウがあります。

障害に備えた物理設計

物理設計についても、通常書かれているような内容は記述から外します。そのため設計の際には一般の書籍やマニュアルも参考にしてください。

最初は「REDOログファイルは十分な対障害性を持っているか」から説明したいと思います。データが壊れたときに一番大事なファイルがREDOログファイルであることは知られていますが 注1、そのREDOログファイルのメンバー(冗長化のためのミラーファイル)が別ディスクになっているなど、十分な耐障害性を持っていることが重要です。

注1:REDOログファイルとアーカイブREDOログファイル以外は、どんなに壊れても各種ファイルのバックアップがあれば基本的にリカバリ可能です。

ここで「十分な対障害性」について考えてみたいと思います。耐障害性については皆さんもいろいろな定義(や思い)をお持ちで、何か議論の軸となるものを決めないと話を進められません。そこで、今回は「SPoF(Single Point of Failure:一重障害)」を基準に話を進めます。プロジェクトによっては、耐障害性について、この「SPoFに耐えられること」という定義がされていると思います。逆に言えば、多重障害は耐えられないことがあると言えます。

さっそく、この定義をREDOログファイルに当てはめてみましょう。「ファイルなのだから、RAID0以外のRAIDを組んでいれば大丈夫なんじゃないの?」と思われた方もいらっしゃるかと思います。RAIDを構成するディスクの1つが壊れた場合に関しては、もちろん大丈夫です。しかし、世の中には「OSが間違ったデータを書き込む」とか、「ホストバスアダプタが壊れて、配下のほぼ全部のファイルのデータが不正になった(壊れた)」とか、「ディスクコントローラーが壊れてしまい、RAIDを組んでいたディスク群が全損した」という事例もあります。

さらに信じられないSPoFもあります(守秘義務があるため、残念ながら内容は言えません)。何が言いたいのかというと、要は次の2点になります。

  • 可能な限り“手前”で冗長化を図るべき
  • 完全な耐障害性というものはなく、不測の事態は起こり得る。そのための最悪のシナリオの準備もしておく

「可能な限り“手前”で冗長化を図るべき」とは、例えば、ストレージ内の冗長化よりは、もっと手前のOracleレベルの冗長化のほうが一般に耐障害性が高いことを指しています(図2)。

図2 可能であれば手前で冗長化を行なうべき

図2 可能であれば手前で冗長化を行なうべき

ただし、ソフトウェアRAID5のように手前の冗長化にはパフォーマンス劣化の恐れが高くなるものもあるため、選択の際には気をつけてください。これらをREDOログファイルに当てはめると、「ストレージがRAID構成であってもOracleレベルで冗長化する(メンバーを2つ以上作る)のがお勧めで、REDOログファイルが全損するようなケースも想定しておくべき」となります。設計の全般にわたってこのような視点を持っていていただきたいと思います。

さて、次は少し軽い話題です。「リストア時にREDOログファイルや制御ファイルをテープからディスクに戻してしまう」です。この内容はバックアップ/リカバリに含まれるべきですが、ここで紹介します。バックアップ対象に制御ファイルを入れておくことはお勧めです。

一方、REDOログファイルはバックアップ不要です。しかし、通常のリカバリの際には、制御ファイルやREDOログファイルをテープからディスクに戻してはいけません。バックアップしたものを普通にリストアしてしまうと、上書きされてしまうので気をつけてください。REDOログファイルが上書きされると、完全回復が不可能になり、制御ファイルの場合もリカバリ手順が変わって難しくなってしまいます。

そのほかにも、処理の高速化やアーカイブREDOログサイズの削減を目的として、表に対してnologgingを指定することがあります。しかし、nologgingを指定してしまうと、リカバリの際にデータを復旧させることはできません。リカバリ手順書も複雑になってしまいます。nologgingは、このようなデメリットも把握した上で設定してください。

物理設計における管理対象の分割の目安

何事もほどほどが重要です。物理設計についても同じことが言えます。ここで触れたいのは、管理対象をどれくらい分割して管理するかについてです。例えば、データファイル数をいくつにするのが望ましいかといった話について説明します。

管理対象を細かくしてしまったがために、トラブルが発生してしまうことがあります。「細かくする=管理対象が増える」からです。製品の上限値に達してしまったり、細かくした管理対象に対する何かの処理の際に、時間がかかってしまいます。

例えば、ディクショナリ管理のエクステントの場合、1表あたり100エクステント程度にすることをお勧めします。最近でもディクショナリ管理の採用を予定しているプロジェクトもあるようですが、できる限り競合をなくすために今後はローカル管理にすると良いでしょう。データファイル数も大きなDBではない限り、数十個から200個程度にするべきです。データファイルも多いと、OSのファイル記述子が多数必要になるなどのオーバーヘッドが増えるためです。

では逆に、管理対象が大きければ良いものなのでしょうか。サイズが大きい場合、管理対象が減ることによるロック競合が問題になります。例えば、通常のファイルシステムにデータファイルを置くと、読み書きの際にロックがかかります。ファイルシステムの多くでは、1つのプロセスがWriteしている最中は、ほかのプロセスはWrite(Readも)できません。データファイル数が少なく、処理量が多いシステムではこのロックが問題になることがあります。1つのサイズが大きい場合、サイズの無駄も出てきます。例えば、多少、領域が足りないだけでも、大きなサイズのデータファイルを追加しなければならなくなります。さらには、データファイルサイズの上限もあります。基本的に最大データファイルサイズは4194303×DB_BLOCK_SIZEバイトです。それ以上のサイズは作成できません 注2。

pctfreeやpctincreaseも領域を節約するために空きをほとんど作らない設定にしてしまうプロジェクトがあります。更新や削除がほとんどないデータを除き、逆に非効率な使用状況になり苦労することがあります。これらのパラメータも少しは余裕を持たせるようにしましょう。

以上から分かるように、設計においても極端はいけません。トラブルの元になります。

注2:別途、OSや製品の制限が存在することもあります。詳しくはマニュアルを参照してください。

物理設計におけるインデックス容量の見積もりなど

インデックスの容量は要注意です。理由は見積もりが難しいからです。そもそも、インデックスは開発の後半において予定よりも多く付与されがちです。そのサイズを見越して、最初の設計では領域の余裕を持っておかなければなりません。さらに、インデックスのフラグメントの分や、オンラインリビルドを行なうのであれば、リビルドの際に使用されるサイズも余分に確保しておかなければなりません。

フラグメントについては領域が足りなくなったらリビルドする前提で50%から100%くらい余裕を見ておけば良いかと思います。オンラインリビルドは、稼動させながら新たなインデックスを作るため、インデックスもう1つ分の容量が必要となります。

文字コードの世界も奥が深いと言えます。まず「使いたい文字は何か」を確認してください。ユーザー定義外字やベンダ定義外字を扱う必要性も確認してください。その後、使用するキャラクタセット(文字コード)を選んでください。

次は容量です。日本語データを格納する際に発生するバイト数の問題があります。例えば、UNICODE(UTF8)において日本語の1文字は3バイト必要とします。

最後は文字コード変換の問題です。格納できたとしても、システム内で処理されるうちに文字化けが発生することがあります。原因は製品(ベンダ)間の文字コードのマッピングが異なることです。きちんと製品間の相違点を調査するか、もしくはテストプログラムを作成してすべての文字を入力し、その後、取り出すテストを行なって問題がないことを確認することをお勧めします。

初期化パラメータについては簡単に概要のみを説明します。全般的に言えるのが「まずマニュアルを見る癖をつける」です。デフォルト値でもそこそこは動きますが、トラブルを少しでも少なくしたいのであればきちんと精査すべきです。サポート契約を結んでいるプロジェクトであれば、オラクルサポートのKROWNも検索してみてください。きっと役に立ちます。

TIPS:ユーザーの誤操作やアプリケーションのバグによるデータ不整合をデータベースのリカバリで復旧すべきか

「ユーザーの誤操作によるデータの消失をデータベースのリカバリで復旧できるようにして欲しい」と言われることがあります。また、「アプリケーションのバグにより、おかしな値に書き換えられてしまったデータを元に戻して欲しい」と言われることもあります。確かにOracleは、一部の表や表領域のデータのみを過去に戻すことができますが、筆者はこれは現実的ではないと考えます。理由はいくつかあります。まず、誤操作以降に発生したほかのユーザーのトランザクションが失なわれることです。

また、一部の表や表領域のみのリカバリでは、ほかの表や表領域のデータとの整合性が保てる保証がありません。業務チームに整合性を聞いたところで、業務チームも困るだけでしょう。また、リカバリに時間がかかり、その間は業務が止まってしまうことも問題です。以上のことから、誤操作に関してはデータベースのリカバリではなく、アプリケーション側で行なうか、EXPORTで頻繁にデータを保存しておくか、Oracle 10gで充実してきたフラッシュバック機能を使用すべきと考えます。

▲ ページTOPに戻る

ストレージの設計とトラブル

数年前と比較してディスクは大容量化しています。ストレージを購入する際、選択できる最小容量のディスクを選択したとしても、DBに必要な総ディスク容量を満たすにはディスク2~3本で事足りてしまう場合も少なくありません。このような技術の進歩とともに、「ディスクは容量を重視して購入すればたいていはなんとかなる」という時代は過ぎ、IOPS(I/O Per Sec)を一層重視して購入する時代になったと言えます。

RDBMSから見ると、ディスクの主な性能指標は2つあります。1つは転送レートを表わすMB/secであり、もう1つはランダムアクセスの回数を表わすIOPSです。ランダムアクセスの際には、ディスク内のアクチュエータ 注3が動きます。

注3:アクチュエータとは、ディスク内のアームのことでディスクヘッドを動かします。

ディスクの容量はどんどん大きくなっていますが、アクチュエータは機械を使用しているため、性能(IOPS)は昔と較べてそれほど上がっていません。I/Oのサイズとは関係なく、1ディスクあたり秒間100回から150回(100から150IOPS)程度です。

見積もりにおいては、このIOPSが重要となります。ディスク容量のみに着目してストレージを購入したことによって、ディスクがボトルネックとなり、パフォーマンスが出ないシステムを筆者は数多く見てきています。特に、ストレージにキャッシュがなく、かつ、物理設計が悪い場合、数SQL/secの負荷にすら耐えられないかもしれません(図3)。

図3 IOPSが足りない例

図3 IOPSが足りない例

また、いくらストレージのキャッシュがあってもWrite I/Oは、いつかはディスクに書き込まれます(図4)。

図4 ストレージのキャッシュもWrite I/Oの削減はできない

図4 ストレージのキャッシュもWrite I/Oの削減はできない

そのため「大きなストレージキャッシュがあればディスク本数がいくら少なくても大丈夫」とも言えません。これらの事情とディスクの本数を少なくせざるを得ないという理由により、数年前に推奨されていた、表領域の特性に合ったRAIDの選択や、細かい物理レイアウト設計は推奨できなくなってきました。

そこで新たに現われた方針が、「できる限りディスクはひとまとめにする。その中でストライピングして、Oracleは細かいことを意識しない(ストレージに任せる)」というものです(下のTipsも参照のこと)。

I/Oを可能な限り減らすために、Oracleのバッファキャッシュを大きくすることも有効です。OSや製品の上限がない限り、数GBのバッファキャッシュサイズにしても動作します(世の中には100GBを越えるバッファキャッシュサイズのシステムも存在します)。

ただし、バッファキャッシュに欲しいデータが常時載っているとは限らないことに気をつけてください。起動直後やバッチ処理直後は、欲しいデータがバッファキャッシュに載っていないことが多く、一時的にSQLの性能が出ないこともあります。また、書き込みI/O数の削減に関しては、このOracleのバッファキャッシュは効果がありません。

TIPS:S.A.M.Eを利用したストレージ設計

S.A.M.Eとは「Stripe and Mirror Everything」の頭文字をとったもので、数年前からOracleが推奨しているストレージ物理設計の方針です。簡単に言うと、「できるかぎり多くのディスクを1つにまとめてしまいましょう。ストライピングで性能向上させましょう。Mirrorでデータ保護しましょう」というものです(図5)。

図5 S.A.M.E.を用いたストレージの設計例

図5 S.A.M.E.を用いたストレージの設計例

見方を変えると、スループット重視とも言えます。次のURLにS.A.M.E.を解説した良いドキュメントがあります(英語です。 http://www.oracle.com/technology/deploy/availability/pdf/oow2000_same.pdf)。

なお、S.A.M.E.はあくまでも方針(考え方)であって、各システムで厳密に実装しなくても構いません。例えば、ミラー(RAID1)ではなくほかのRAIDでも性能が出れば構わないと言えます。また、筆者は勉強用としても上記ドキュメントをお勧めします。理由は、「ディスクのパフォーマンス特性を考えると、こう設計すべきだ」ということを数値を使って論理的に説明している数少ないドキュメントだからです。

▲ ページTOPに戻る

ネットワークのトラブル防止

Oracleはソケット通信を行ないます。しかし、その障害検知の仕組みはご存知でしょうか。このネットワークに関するトラブル防止も設計時に行なうべき項目なのです。この実装が行なわれていないと、「DBサーバー再起動時には、APサーバーも再起動させる」運用が必要になったり、誰も保持していないロックがDBサーバー上に残ったりします。

TCP/IPの障害検知は複雑なため、残念ながらすべては紹介できません。そのため、ここでは単純化して扱います。ソケットに対するRead待ちと、ソケットを使っていない状態と、ソケットに対するWrite待ちの3つの状態を考えてください。

図6の3つの状態をサーバープロセスに当てはめると、一番上の状態がSQL文の受信待ちとなります。2番目の状態が、SQL文を処理中の状態です。一番下の状態はSQL文の結果を返す時と言えます。SQL文を返したらまた上の状態に戻ります。

図6 代表的な3つの状態

図6 代表的な3つの状態

クライアントマシンがダウンした場合は2つの状態が考えられます。サーバープロセスがRead待ちだった場合(大多数のケース:SQL文が届いていない)と、Write中もしくはSQL文を処理中で、これからWriteするケースです(図7)。

図7 切断時のサーバープロセスの動き

図7 切断時のサーバープロセスの動き

厄介なのは、サーバープロセスがRead待ちだった場合です。このRead待ちのタイムアウトは長いため、長時間にわたって、すでに存在しなくなってしまったクライアントからのリクエストを待ってしまいます。このサーバープロセスがロックを保持したままだと事態は最悪となります。トランザクションが終わらず、ほかのSQL文をひたすら待たせてしまうからです。

このような事態を防ぐために、expire_timeの設定やTCP/IPのパラメータチューニングを行ないます。これらのパラメータを設定すると、設定した時間まで通信が一度も行なわれない場合に、相手が生きているか確認するパケットを送ります。

DBマシンがダウンした場合も、クライアントプロセスの2つの状態が考えられます。SQL文を送信中もしくはエンドユーザーからの入力を待ってこれから送信する場合と、SQL文を送信済みでOracleからの応答待ちの状態です(図8)。

図8 切断時のクライアントプロセスの動き

図8 切断時のクライアントプロセスの動き

前者の場合には、SQL文をOracleに送信した際にエラーとなります。しかし、後者はひたすらOracleからの結果を待ち続けます。このような待ちを避けるためには、tnsnames.oraファイルに相手が生きているか確認する“enable = broken”を設定するか、もしくはアプリケーション側で何らかのタイムアウトを実装してください。ただし、“enable = broken”を設定しても、検出を早くするためにはTCP/IPのパラメータの調整が必要です。

多くの場合、チューニングが必要なのは、TCPの「キープアライブ」と呼ばれるパケットを送信するまでの時間の調整と、再送のタイムアウト時間の変更です。タイムアウトの設定が必要な理由は、相手がキープアライブに対して無応答でも一定時間経過後は切断と判断しなければいけない(タイムアウトしなければならない)からです。ただし、タイムアウトの時間が短いと一時的な瞬断であってもタイムアウトしてしまうため、短すぎてはいけません。

このようにネットワークのパラメータはバランスが重要であるため、調整は専門家もしくはベンダに相談の上、行なってください。また、ネットワーク障害はこれですべてではありません。コネクション接続時や分散トランザクション、DBリンクの場合にはほかの考慮も必要です。ただし、基本となる考え方は同じです。

TIPS:【上級編】障害検知がエンドユーザーからの通報で良いか?

どんな大きなプロジェクトであっても、全体スローダウンに対しての良い検知方法はなかなか持っていないものです。しかし、この全体スローダウンは業務に大きな影響を与えることもしばしばです。本来はAPサーバー側で検知すべきと思うのですが、なかなかできていません。そのため、エンドユーザーのクレームからトラブル対応が始まります。さらにどこが原因か判らないため、DBチームが巻き込まれることもしばしばです。

そこで筆者が考え、各プロジェクトおよび社内で推奨しているのが、「アクティブなセッション数を見る」方法です。「アクティブ」とは「SQL文を処理中」を意味します。APサーバーの例である図9と図10を見ながら次の説明をお読みください。

APサーバーに対して、各ユーザーはリクエストをほぼランダムに投げます。全体がスローダウンしていない場合には、ある一定時間で処理が終了して結果を返せるでしょうから、SQL文を処理中であるセッション(ここではほぼコネクションと同義)は一定数以下であり、余裕があります(図9の状態)。

図9 APサーバーを使用したシステムにおける通常時の動き

図9 APサーバーを使用したシステムにおける通常時の動き

次に全体がスローダウンした場合について説明したいと思います。

まず、図10を見ながら、例として銀行の窓口業務を思い浮かべてみてください。Oracleのプロセスが銀行員で、コネクションプールが窓口です。何らかの理由で銀行員の処理が滞ると、普段並みのお客数でも窓口はいつも使用中になり、待ち行列ができることが想像できると思います。次に示す方法は、窓口が常時使用中という事実から、行列待ち(遅延)が起きているのではないかと推測する方法です。

図10 APサーバーを使用したシステムにおける全体スローダウン時の動き

図10 APサーバーを使用したシステムにおける全体スローダウン時の動き

システム全体がスローダウンすると、SQL文の処理に時間がかかるようになります。もしくは処理が止まってしまいます。すると、リクエストは次々に届くため、コネクションプールのコネクションがどんどんアクティブになっていきます。表のロック待ちからCPUパワー不足、ディスク障害まで、全体がスローダウンするような事態になれば、基本的にこの現象が起きます。

コネクションプールを使っていないシステムにおいては、コネクション(セッション)数がどんどん増えていくので検知できます。具体的には、V$SESSIONにおいて、同じMACHINE列、PROGRAM列のセッション群の、ほとんどのSTATUS列が“ACTIVE”(もしくは普段に較べて明らかに多い)になっていれば、そのコネクションプールはほぼすべてのコネクションにおいてSQL文を実行中で余裕がない(処理が滞っている)ことを示します。

一時的な業務集中による誤判断を避けるためには、数十秒間隔で数回確認して発報もしくは切り分けすると良いでしょう。コネクションプールを使っておらず、処理のたびにコネクションをコネクトするシステムでも、通常のコネクション数を測っておき、安全率も見た上で上限の数を決めて検知もしくは切り分けをすると実現できます。

もちろんこの方法も万能ではありませんが、筆者の経験ではかなりの確率で全体スローダウンを発見できます。注意点は、バッチに対して使えないことです。バッチはコネクトしたら、そのままずっとコネクションを使い続けるからです。

このような運用ツールに含まれていない検知の方法は上級テクニックとなりますが、各自工夫して考えてみてください。

▲ ページTOPに戻る

おわりに

本特集を読んで、「ここまでやる必要があるのか」と思われた方も多いでしょう。しかし、トラブル対応に懸命になることが素晴らしいのではなく、トラブルを起こさないことが素晴らしいのです。また、設計フェーズでの問題を後で取り返そうと思うと数倍~数十倍の労力がかかります。

ぜひ、プロジェクトに合わせて本記事中のノウハウを使用してみてください。その結果、皆さんのプロジェクトにおいてトラブルが少しでも起こらなくなれば幸いです。

▲ ページTOPに戻る

"門外不出のOracle現場ワザ" インデックスに戻る

Copyright © 2009, Oracle Corporation Japan. All rights reserved.

無断転載を禁ず

この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。

Oracleは米国Oracle Corporationの登録商標です。文中に参照されている各製品名及びサービス名は米国Oracle Corporationの商標または登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります。

1996年日本オラクル入社。人事教育本部にて、新卒や中途採用社員に対し、データベースやOS、ネットワークの講師を5年ほど経験した後、2000年にテクノロジーコンサルティング本部に異動。 テクノロジーのコンサルタントとして、主に大規模ミッションクリティカルシステムを担当。

ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき」。 スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。