Oracle In-Memoryの内部について SGA→IMCU→CU

Oracle DBA & Developer Days 2014
の 11/26 Track1(A1-1)を（会場に行かず）オンラインで今聞いた内容のメモメモ

２人の講師の
　　１人目は、はじめのほうを聞き逃した
　　２人目は、１人目が終わったところで席を離れたので
はじめのほうは、メモとれてない。

(表題のSGA→IMCU→CUは、２人目発表で出てくる）

---

■ひとりめ（佐藤さん）

分析処理を高速化する新たな技術革新
インメモリ・デュアル・フォーマット

・使い分け
　コヒーレンス、TimesTen：トランザクションを早くする
　　→アプリケーションサーバーと同じきょうたい
　In memory：解析を早くする

・ロー型に、カラム型を追加して、分析を早くする
　　→どちらを使うかは、データベースが判断する
　　→Oracleは両方同時に実現
　ユーザーから見ると、同期されている
　高速化したいデータのみをメモリ上に展開
　インメモリ→分析系のインデックスに変わるものも
　　→インデックスを削除する効果

---

■２人目（丹羽さん）

コアテクセミナー：YouTubeを使った動画セミナー

Oracle Database In Memory(DBIM)の概要
・OLTPとOLAP：トレードオフ
　　→１２Cはオプティマイザで選択
・カラム型表は、なぜ分析用クエリーが高速か？
　　→必要なカラムのみアクセス
　　　ディクショナリ圧縮
　　　　　ディクショナリ・エンコードの２つのセクション
　　　　　→圧縮状態で検索可能
　　　インメモリストレージ索引
　　　　　カラム：複数のカラムユニット（IMCU)で管理
　　　SIMD（「しむでぃー」と読んでました）
　　　　　ベクターレジスタ
　　　　　ディクショナリ圧縮をCPUレジスタにロード可能

インメモリカラムストアの詳細
・インメモリ領域：SGA内の新しい領域
　INMEMORY_SIZE（最小サイズ１００M）
　SGA_TARGETはこの領域が入るように

・インメモリ領域：構成
　２つのサブプール
　　　IMCUプール：カラム書式データ
　　　SMUプール：メタデータとトランザクション情報
　→V$IMMEMORY_AREA

・IMCU(In Memory Compression Unit)
　カラム型データをある程度の行数セットで保持
　→カラムユニット（CU)として保存
　→V$IM_HEADER

・カラムユニット
　　各カラムの値の管理単位
　　全CUは、最小、最大値を持っている
　　CUの確認方法

DBIMのインメモリ・スキャン
・データベースの検索処理
　　データ処理層：集計、JOIN,ソート
　　データスキャン層：取得＋フィルタリング（全表検索、さくいん）

全表検索
・TableAccessFull
　　ふつうの全表検索
・TableAccessStorageFull：Exadata（スマートスキャン）
　　スキャンしながら、フィルタリング
・TableAccesInMemoryFull：インメモリの場合
　　カラムストア層で読み込みながらフィルタリング(プッシュダウン）

フィルタリングを効率化するための暗黙条件の成立

DBIMの導入効果が高い処理／高くない処理
・利用効率が大きい処理
　　少数列に対する大量行の処理に効果大
　　　　ディスクIOの物理読み込み量が大きい
　　　　SQLの処理：大量行の表を含む分析クエリ
　　　　　　db file scattered read
　　　　　　db file sequential read
　　大量行の表を含むJOIN,集計でディスクアクセスあり
　バッファキャッシュを用意して、キャッシュに入れたら？
　　→全表スキャンVSインメモリスキャンなので、高速化
　　　　→読み込みブロックが少ない
　インメモリ化すると、すべての検索が早くなる？　NO

・利用効率が大きくない処理
　・索引により最適化されている
　　　並列度を高く出来ない場合
　　→オプティマイザが判断する
　・集計値を持っている場合

DBIMのパフォーマンス統計情報
・CU（カラムユニット）の確認
・インメモリ系の主要統計量
　　V$sysstat,V$mystat,v$statnameで確認