スキップしてメイン コンテンツに移動

投稿

疑似コードで、昨今のIn-Memoryとかカラム型とかを味わう

とうとう、JPOUG Advent Calendar 2014 も最終日となりました。今年もご参加頂いた皆様に感謝しつつも、去年に続き、オオトリを務めさせていただきます。

Oracleデータベースも12.1.0.2というバージョンでIn-Memoryかつカラム型で分析系ワークロード用を高速化するオプションが導入されていることはご存じの通りです。

このIn-Memoryオプションという文脈で

"ディスクは遅くメモリーは速い。だからIn-Memoryなデータベースは速い"
とか

"分析系ワークロードはカラム型といったデータフォーマット合っている。だからカラム型が速い"
とか

"データベースの処理をSIMD(シムディー)とかVector処理といった処理で行うと速い"
とか

なかなか、上記のキーワードがどのようにデータベース処理と関連しているか不明な状態で説明されることが多いのではないか。と思う今日この頃です。

今日は、In-Memoryやカラム型やSIMDといったキーワードを自分なりに関連あることとして、ここにメモ書きを残そうと思います。

言葉でアレコレ説明しても、よく分からん。(どなたかはSIMDの気持が知りたい。と仰っていた)なので、とてつもなくシンプルな疑似コードで説明してみたいと思います。

* ちなみに、以下示される疑似コードはOracleとも他のデータベースの作りとも全く関係ありません。目的は、疑似コードで処理のイメージを掴めれば良い程度の簡単なものです。(要はこんなにデータ構造はシンプルではないですし、コードもこんなに非汎用的ではないですし、正直、WHERE句のSIMD適用はこんなにお手軽ではないですし)

前提)
以下のような数十カラムを含むテーブル構成で1億件のランダムなデータが入っていると想定

SQLで書くと以下のような感じ

create table large_table ( l_quantity number ,l_tax number ,... ,(沢山) ,... );
こんなテーブルをコードで書くと(とりあえずC)、以下のような構造体の配列(これは通常のロー型を想定)になると思います

typedef struct { int l_quantity; int l_tax; ..…
最近の投稿

12cでリソースの共有と非共有のはざまで... その3

I/Oリソース編
 これまで、マルチテナント・アーキテクチャにおけるCPUリソース、Memoryリソースの制御方法を考察してきたが最後にI/Oリソースの制御について考えてみる。

 Oracle Databaseは共有ディスクアーキテクチャーをとることから、従来からI/Oはボトルネックになりやすい重要なコンポーネントだった。マルチテナント・アーキテクチャにより、多くのインスタンスが集約されるとさらに、I/Oのリソース管理の重要性が増してくることは明らかである。

 さらに、初回のCPUリソース編でも述べたが、Database Resource ManagerではI/Oのリソース管理は提供されておらず(*1)I/Oリソース管理をするにはExadataによりI/O Resource Managerを使用する必要がある。

 筆者はExadataを検証環境として持ち合わせていないので、ここでExadata I/O Resource Managerの検証結果を記載できない。

 そこで、CPUリソース編で説明したOSネイティブなリソースマネージャ(*2)を使用したI/Oリソースの管理の方法を紹介したい。

(*1) Runaway SessionとしてのI/Oリソース管理は提供されている
(*2) Linuxのcgroupsと初期化パラメーターPROCESSOR_GROUP_NAMEを使用する

I/Oリソース制御としてPROCESSOR_GROUP_NAME
 初回のCPUリソース編で初期化パラメーターPROCESSOR_GROUP_NAMEを紹介したが、これはPROCESSORに限らずOSの持つcgroups(本件検証環境はOracle Linux 6.4 x86_64)の全ての機能を使用できる。


注意 cgroupsの機能をOracle Database 12cがどこまでサポートしているか明確なドキュメントはなく、現時点は検証目的としてPROCESSOR_GROUP_NAMEでcgroupsのI/O制御を行っている事に注意

 まず、I/Oリソースに関して全く制御していない状況で、I/Oの速度を計測してみる。I/Oの速度計測にはOracleが提供しているDBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャを使用する

set serveroutput on declare l…

12cでリソースの共有と非共有のはざまで... その2

Memoryリソース編 前回CPUリソース編として、Oracle Database 12cのマルチテナント・アーキテクチャにおけるCPUリソースの制御の様子を検証してみた。今回は、Oracle Databaseで重要なコンポーネントであるSGA(System Global Area)を含むMemoryリソースの制御の様子を見てみたい。

 Oracle Databaseはインスタンス単位でSGAをもち、SGA内のコンポーネント(つまりMemoryリソース)の配分は、DBAが手動もしくは、Oracle Databaseによる自動管理で行うことが従来より可能であった。ここでのポイントは、Memoryリソースはインスタンス単位である点であり、プラガブル・データベース単位での制御はないということである。

 結論を先に書くと、Database Resource Managerや従来のDBAによる手動もしくはOracle Databaseによる自動によるMemory管理では、プラガブル・データベース毎にMemoryリソースを制御することは不可能である。

 本検証では、Memoryリソース管理が不可能である点を踏まえ、マルチテナント・アーキテクチャを考える際に注意しなければいけない(であろう)事を検証してみる。


 まず、マルチテナント・アーキテクチャにおけるSGAの仕組みを簡単に見てみる。

 この図から、SGAはコンテナ・データベースが管理し、プラガブル・データベース固有のSGAは存在しないことが分かる。
 さらに、重要なのは従来からSGAコンポーネントの中での鬼門であったSHARED POOLもコンテナ・データベースに1つしか存在しないという事をである。これは、1つのプラガブル・データベースでSHARED POOLの枯渇を誘発するような処理(例えばバインド変数を使用しないSQLが大量に実行されている等)により、他の問題のないプラガブル・データベースでエラー(ORA-4031など)が発生するといった悪影響に関する懸念が残る。

 今回は、このSHARED POOL、特にLIBRARY CACHE周りの動きを少し検証してみようと思う。
LIBRARY CACHE内のカーソルは誰のもの? SHARED POOL内のコンポーネントの中でも、SQL文の解析情報を格納するLIBRARY CACHEは特に重要…

12cでリソースの共有と非共有のはざまで... その1

はじめに 2013年のJPOUG Advent Calendarも今日で最後になりました。私のAdvent Calendarネタに関しては、若干、旬を過ぎた感は否めませんが、Oracle Database 12cに関するものにしようと思います。
 実は、Oracle Database 12cリリース時に某メディアに寄稿予定だったものを(いろいろ事情があってお蔵入りになっていたもの)この場を借りて、全3回でお送りしようと思います。
Oracle Database 12c マルチテナント・アーキテクチャについて Oracle Database 12cの"c"がCloudを意味するようになり、プライベートやパブリックを問わずデータベースを集約して効率良くデータベースの集積率を高めるようなアーキテクチャを備えた今、"c"であるためのポイントは、集約した結果として物理的なリソースをどのように適切に配分するのか?また、物理的なリソースを適切に配分できるのか?ということに尽きると思う。

 物理的なリソースとはデータベースが使用するCPUリソース、Memoryリソース、I/Oリソースとなるが、細かいことを言えば、データベース内部のラッチなども挙げられる。

 Oracle Database 12cでは、どのようなリソース管理が可能かについて検証していくつもりです。また、Oracle Database 12cのマルチテナント・アーキテクチャで、データベースにおける各種リソースの管理方法が旧来のリリースから変更されており、合わせてOracle Database 12cがどのようにリソースを管理しているかについても適宜、検証を行いたい。

 まず、簡単にマルチテナント・アーキテクチャをおさらいしておく。




 マルチテナント・アーキテクチャを簡単に理解すると、OSの持つリソースはコンテナ・データベースが管理し、プラガブル・データベースは、あたかも従来のスキーマのような振舞い(しかし、個別のデータベースとして隔離されて動作する)をしているように見える。

 プラガブル・データベースの追加は、スキーマ追加と同様にCPUやメモリーといった新たなリソースを確保する必要はない。必要な時に、必要なだけ、上位のデータベース(コンテナ・データベース)が用意する。

注意
誤解があるといけ…

db tech showcase tokyo 2013 - 特濃JPOUG -

2013/11/15の午後から4セッション連続で「特濃JPOUG」として題してセッションを実施させてもらいました。私もセッションを1枠もらって、"log file sync"に関して、基本的な動作と幾つかバージョン間での違いの話をしました。

データベースの基本的な操作の"COMMIT"で繰り広げられる基本的な動作の話なので、特濃かどうかは微妙な点ではありますが、多くの方にご参加頂き(Facebookの松信さんが裏セッションだったにも関わらず :) )、とても楽しい時間でした。

途中、プロジェクターの電源が数回切れるアクシデントもありましたが、参加者の方々の暖かい雰囲気のおかげで、何とか乗り切ることができました。この場を借りて、参加して頂いた方に感謝です。ありがとうございました。


Dbts2013 特濃jpoug log_file_sync from Koji Shinkubo

コンカレンシーにまつわるアレ・コレ

最初に 今日は、JPOUG Advent Calendarのエントリです。
昨日の小田さんに続き、私は、1μmも役には立たないエントリとなります !

最近思うこと 昨今、データベースシステムを構成するハードウェアは大量のコア、一昔では考えられないほどの大量のメモリーが搭載し、さらにデータベースのボトルネックの王者たる風格さえ漂っていたI/Oにも高速化の波が押し寄せてきています。

そんな中、古くて新しい、そして、RDBMSとしての真価を問われるコンカレンシーの問題がボトルネックとして浮かび上がっているような気がしています。

このコンカレンシーの問題は、曲者で、どんなに高速なCPUを沢山搭載しても、どんなに沢山のメモリーを積んでも、ロケットばりの高速ストレージを使っても、コンカレンシーがボトルネックとなると全くパフォーマンスがスケールしません。(まぁー、極端な言い回しですが)



そんな事を、つらつら考えつつ、コンカレンシーの問題が大きく関係するBuffer Cache上で繰り広げられる様々な動きを考えて見ることにします。

ここで、登場するボトルネックの原因となるWait Eventは、こんな物です。

latch: cache buffers chainslatch: cache buffer lru chainfree buffer waitsread by other session

まず、SELECT文のEXEC/FETCHフェーズを想像して下さい。

上記のWait Eventを噛み砕くと、こんな感じでしょうか?

latch: cache buffers chains 「僕の探しているブロックはキャッシュされていますか~」を多くの人(Session)が聞きたがっている。でも、キャッシュされているか答えをもらうためのチケット(cache buffers chains latch)は一つ(もしくは非常に少ない)なので、なかなか、その順番が回ってこない。なので、「待つ」

* ちなみに latch: cache buffers chains は"聞く"だけなら、コンカレンシーの問題は起こらないのですが、このラッチは、「ブロックをキャッシュするので、ちゃんと管理しておいて~」の場合には、他の人が触れないようにする必要がある("聞く"こともでき…

Oracle OpenWorld 2012 Unconference presented by JPOUG

2012/04/06に六本木アカデミーヒルズにてOracle OpenWorld 2012 Unconference presented by JPOUGとして多くのセッションが行われました。お越しいただいたい全ても皆様、セッションを担当して頂いた方々、Unconferenceの運営を任せて頂いた関係者各位に感謝申し上げます。

Unconferenceの中で、私も1つのセッションを担当しました。本質的には、

- プリミティブな世界の変化により、アプリケーションは変わらなければいけないし、変わらざるを得ない - 今まさに、データベースにおいても、その変化が起きている
つまり、我々データベースに携わるものも変わらなければいけないし、変わらざるを得ない

ということですが、セッション終了後、私がセッション内でお題として扱った


同一のSQL文をネタにして、  同一の実行計画により、 異なるI/Oパターン

の方法論について質問がありました。本セッションの本質ではないため、あまり説明はしませんでした。(本当は、ちょっと異なるI/Oパターンとしては無理くり感があり、恥ずかしかったので...) しかし、質問がありながら、公開しないほどのものではないので、本ブログにセッション内で使用した資料も合わせて掲載しておきます。
oow2012 unconference
View more presentations from Koji Shinkubo.
- DIRECT PATH READ
11gR2が検証環境でしたので、十分大きいセグメントに対しては自動的にdirect path readをオプティマイザが選択するので、本検証環境は何も特別なことは実施していません。
古いバージョンでは"_serial_direct_read"等にて制御可能です。

- DB FILE SCATTERED READ
alter session set events '10949 trace name context forever, level 1'; alter session set "_very_large_object_threshold"=500000;
"_very_large_object_threshold"はこちらで説明し…