DBA & Developer Day 2016...

Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

Oracle Database 12c:データベース・インメモリーの新機能解説使いやすさの向上と高速化

日本オラクル株式会社クラウド・テクノロジー事業統括Database & Exadataプロダクトマネジメント本部プリンシパルコンサルタント井上克己

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |

• 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

2


本日の内容

12c R1での機能およびユースケース

Active Data Guard 対応

構成の多彩化、使いやすさの向上

高速化機能

1

2

3

4

3


本日の内容




高速化機能

1

2

3

4

4


What is Oracle Database In-Memory?• Breakthrough: デュアルフォーマットデータベース

• 一つの表につき行および列フォーマットの両方

• 同時にアクティブ、および、トランザクション一貫性

• 分析& レポーティングは新しい in-memory 列フォーマットを使う

• OLTPは実績のある行フォーマットを使用する

通常のバッファーキャッシュ

新規 In-Memoryフォーマット

SALES SALES

RowFormat

ColumnFormat

SALES

5


Min 1Max 3

Min 4Max 7

Min 8Max 12

Min 13Max 15

カラム型表は何故分析用クエリーが高速か?

C1 C2 C4 C5 C6C3

ポイント1：集計に必要なカラムのみアクセス＋効果的な圧縮技術により圧縮した状態で検索が可能 (ディクショナリ圧縮)

ポイント3：最新のプロセッサで搭載されているSIMDにより高速フィルター

ポイント4：パラレル・クエリーとパーティション表によりさらに高速化可能

ポイント2：インメモリ・ストレージ索引により最小限のIMCUのみスキャン

例) where storeid > 8

ベクター・レジスタ

複数のデータをロード

一度の命令で全ての値をベクター演算

CPUCA

CACA

CA

6


SPARC M7 CPU ソフトウェア・イン・シリコンによるインメモリーデータ処理DAX scan processing in DAX frees most of the cores for transactional processing

7

SALES (ディクショナリー圧縮) DAX

Softwarein Silicon


ユースケースと事例

8


Oracle Database In-Memoryの代表的なユースケース

9

DWH

ETLデータマート

ETL

OLTPDWH

ETL

分析用DB

基幹系OLTP

レプリケーション（GoldenGate, 将来はActive DataGuardをサポート）

①既存DWHをインメモリ化（現在の主流事例）

• 既存Oracle 11gのDWHを12cに移行してインメモリ化

• 既存DWHアプライアンスをOracle 12c にリプレース

②既存データマートをインメモリ化

最新のExalyticsはDatabase In-Memoryを包含

③OLTPシステムを直接インメモリ化（統合）

• 分析、レポーティングの高速化

• ダッシュボード画面の高速化（経営／業務系）

• リアルタイム分析の促進

④基幹系OLTPシステムとの分離構成

既存システムを極力変更しない分析処理を負荷分散

某証券様

某銀行様

AT&T Wifi様

Swiss Mobiliar様

某大手製造業様

某大手製造業様某大手流通業様

某大手流通業様


Oracle Database In-Memory活用顧客BOSCHはCRMの性能を最大20倍に

10

• SAP CRMは意思決定分析を含むOLTPアプリケーション–さらに様々なアドホック・クエリーやレポーティングをサポート

• 33個のカスタム索引を作成し分析クエリーのパフォーマンスを担保–ただし、CRMトランザクション処理の性能とデータベースサイズには悪影響

• Oracle Database 12cへアップグレードし33個のカスタム索引を削除–アドホック・クエリーやレポーティングは2-20倍高速化– OLTPプロセスは2-3倍高速化

• アプリケーション変更は必要なかった


本日の内容




高速化機能

1

2

3

4

11


Standby

1 Year In-Memory

• プロダクションDBに何ら影響を与えることなくリアルタイム分析

• スタンバイデータベースのリソースを活用

• プロダクションDBとは異なるデータをポピュレーション可能–新規の "DISTRIBUTE BY

SERVICE" 句によりどちらに表をポピュレートするか指定する

–カラムナー領域のトータルなサイズは増える

1 MonthIn-Memory

OLTP: In-Memory on Active Data Guard

Production

12


In-Memory on Active Data Guard:スタンバイのみでIn-Memory

• INMEMORY_SIZE パラメータ– スタンバイ・サイトのみで設定

• 表にDISTRIBUTE FOR SERVICE句なしでINMEMORYを設定

• 分析問合せ– セカンダリ・サイトに接続 & In-Memoryデータにアクセス

スタンバイ・サイト本番サイト

LAN/WAN

13

LAN/WAN


IM on Active Data Guard: サイト間で異なるIn-Memory データ

• INMEMORY_SIZE パラメータ– プライマリ&スタンバイ・サイトの両方で設定– 異なる値も可能

• 全てのオブジェクトに以下を設定INMEMORY DISTRIBUTE FOR SERVICE

– プライマリのサービスを設定または

– スタンバイのサービスを設定• 分析問合せ

– 適切なサービスを指定し接続

スタンバイ・サイト本番サイト

14

LAN/WAN


• DISTRIBUTE FOR SERVICE 句によりプライマリ、スタンバイ、両方でメモリーにポピュレーションするかどうかを指定

• スタンバイが複数ある場合、各々で異なる表をインメモリー化可能

• ロールベースサービス使用可能

• 非Grid Infrastructure環境ではdbms_service.start_service() 使用

Capacity + Availability: In-Memory on Active Data Guard

15

ALTER TABLE SALES INMEMORY DISTRIBUTE FOR SERVICE A

Primary Standby

ShipmentsIn-Memory

SalesIn-Memory

SHIPMENTS

ALTER TABLE SHIPMENTS INMEMORYDISTRIBUTE FOR SERVICE B

有効なサービス: A 有効なサービス: B

srvctl add service -db db_unique_name -service サービス名 [-eval] -serverpool server_pool [-cardinality {UNIFORM | SINGLETON}] [-edition edition_name] [-netnum network_number][-role "[PRIMARY][,PHYSICAL_STANDBY][,LOGICAL_STANDBY][,…]"


本日の内容




高速化機能

1

2

3

4

16


ADO/ILM 対応Automatic Data Optimization(自動データ最適化)Information Lifecycle Management(ILM)Heatmap(ヒートマップ)

17


Oracleの考えるILM真に統合されたデータライフサイクルマネジメントの実現

18

ディスク

Flash

NVRam

DRam

HDFS

Ora

cle

Data

base

• ”ホット”化したデータを高速レイヤーに移動

• ”コールド”なデータを低コストレイヤーに移動

• 圧縮レベル変更

• ホットなデータをメモリーにポピュレーション

ディスク


• ADOのインメモリーへの拡張• Heat map はデータアクセス頻度をトラックする

• ポリシーにより以下を定義可能：– IMカラムストアへデータをポピュレーション

–データがクールダウンすると圧縮レベルを上げる

– IMカラムストアからデータを排出(evict)

自動化: In-Memory データ自動ポピュレーションポリシー

Sales_Q3

Sales_Q2

Sales_Q4

インメモリーカラムストア

Sales _Q1

19

ALTER TABLE SALES ILM ADD POLICYNO INMEMORY AFTER 9 months OF CREATION


FastStartポピュレーションの高速化

21

SALESインメモリ・カラムナー領域

SALES

SYSDBIMFS_LOBSEG$

初回ポピュレート処理

二回目以降のポピュレート処理

セキュアファイルLOB


Population Performance:In-Memory Fast-Start• IM 列フォーマットのストレージへの永続化

• In-Memory カラムストアの内容がポピュレーション時にSecureFile LOBへチェックポイントされる

• DB 再起動時のポピュレーションは列フォーマットを直接ストレージから読み出してくるのでより高速

• データの再フォーマットの必要がないためカラムストアのリストアはより高速(2-5倍)

Buffer Cache

In-Memoryカラムストア

DBFILE1

Table

Index Table

TableIndex

DBFILE2SALES表領域

FAST START表領域

Fast Start データ

22


本日の内容




高速化機能

1

2

3

4

23


In-Memory Expression(IME)仮想カラム事前計算列実行履歴からのキャプチャー

24


• 分析的なクエリーが複雑な計算式(expression)を含んでいる– 通常は各行につき計算される

• Expression(表現、計算式)は事前に計算されin-memoryに格納可能に–仮想カラムでユーザが明示的に指定する

–または expression が自動的に検出される

• 全ての In-Memory に最適化された処理が適用可能(SIMDなど)

• 複雑なクエリー: 3-5倍高速に

Real-Time Analytics: In-Memory Expressions

Net = Price + Price * Taxインメモリーカラムストア

Sales

Pric

e +

Pric

e X

Tax

例: 売り上げの総額を計算

Tax

Pric

e

25

CREATE TABLE SALES (PRICE NUMBER, TAX NUMBER, …, NET AS (PRICE + PRICE * TAX)) INMEMORY;


CREATE TABLE t ( a NUMBER, b NUMBER, v AS ( a + b ) );

SELECT a * b

FROM t

WHERE a / b = 1;

• 仮想列–表内のカラムを含んだ演算式表現–ディスク上にはデータなし–その他のカラムと同様に検索可能

(オン・ザ・フライ評価)• 自動In-Memory Expression

– "ホット"な演算式を自動検知–表内の単一行の１つ以上の列で定義され、定数も含むことも可

–表内の行と１対１でマッピングされる

26

In-Memory ExpressionsTypes


• Expressions Statistics Store (ESS) は常にワークロードをモニター– “Hot”な計算式や関数呼び出しをパース時に頻度やコストに応じて累積的に記録

– 12.2の新規のprocedureのIME_CAPTURE_EXPRESSIONS()を実行するとインスタンス中の上位20個の計算式が判別されキャプチャーされる• DBMS_INMEMORY_ADMINパッケージの１プロシージャー

27

– IME_POPULATE_EXPRESSIONS()を実行すると隠し仮想カラムが作成され計算結果、関数実行結果の値がインメモリー領域にポピュレーションされる• DBMS_INMEMORY_ADMINパッケージの１プロシージャー

In-Memory Expressions : 自動キャプチャーExpression 統計ストア(ESS) 上位20個のexpression

(計算式)をキャプチャーIMEは

インメモリー・カラム・ストアに自動的に作成される

IM Column storeEXPRESSION

（表現、計算式）

テキスト

回数

コスト

A+5 23434 36

UPPER(x) 4134 40

C*D 343 32


• JSON ドキュメント全体が最適化されたバイナリーフォーマットでポピュレートされる

• JSON列上のexpression(表現、計算式)の事前処理結果をカラムストアにポピュレーション可能

• 例) JSON_VALUE(…,…)

• JSONデータへのクエリーでは自動的にIn-Memoryフォーマットが使われる

• 例) Find movies where movie.name contains “Jurassic”

• 60倍の高速化も可能

Real-Time Multi-Model Analytics:In-Memory JSON

Relational

Pure In-Memory カラム型

In-Memory仮想カラム

In-MemoryJSON

フォーマット

{"Theater":"AMC 15","Movie":"Jurrasic World 3D","Time“:2015-11-26T18:45:00","Tickets":{

"Adults":2}

}

Relational Virtual JSON

28


Join Groups

29


• 分析的クエリーにJOINがあり、フィルター述語が無い場合

• "ジョイン・グループ" でテーブルをJOINするカラムを指定–それらのカラムは圧縮ディクショナリーを共有する

–実際のカラム値データそのものではなくディクショナリー値によりJOINされる

• 2-3倍高速な join 処理が可能に

Real-Time Analytics: より高速な In-Memory ジョイン

Sales

VEHI

CLE

NAM

E

Stor

e IDNAM

E例: 各VehicleのSales価格を調べる

SalesVehicle

NAME がジョインカラム

CREATE INMEMORY JOIN GROUP V_name_jg(VEHICLES(NAME),SALES(NAME));

30


SELECT v.year,

v.name,

s.sales_price

FROM Vehicles v, Sales s

Where v.name = s.name;

31

Bloom Filterが使われない Hash Join

SALESVEHICLESNAME がジョイン

列

例: 各々の車輌の販売価格を問い合わせ

12.1では圧縮値の伸張と

ハッシュ値計算が実行時間の大部分を占めるためあまり高速化されない


• 両方の表からのジョイン列を共通の”ディクショナリー”で圧縮

• ジョインは実際の列の値データではなく”ディクショナリー値”で行われる–圧縮を伸張する処理を省略できる–データのHash処理も省略

• "表名(カラム名) "グループ化最大数は 255

• 同一カラムは2つ以上のJOIN GROUPに属することはできない

32

ジョイン・グループ: より高速な Hash ジョイン

SALESVEHICLESNAME がジョイン

列

例:各々の車輌の販売価格を問い合わせ

CREATE INMEMORY JOIN GROUP V_name_jg(VEHICLES(NAME),SALES(NAME));


ジョイン・グループ: 共通のディクショナリーが両方の表で使われる

パーティション化されている表でも表全体で共通ディクショナリーが使われる

IMCU IMCU

IMCUIMCU

IMCU IMCU

IMCUIMCU

2

2

2

2

2

0

0

0

1

1

1

1

44

4

4

5

55

53

3

34

3

3

4

15

24

2

VEHICLES 表IMCU IMCU

IMCUIMCU

IMCU IMCU

IMCUIMCU

2

2

2

2

2

0

0

0

1

1

1

1

44

4

4

5

55

53

3

34

3

3

4

15

24

2

SALES 表IMCU IMCU

IMCUIMCU

IMCU IMCU

IMCUIMCU

2

2

2

2

2

0

0

0

1

1

1

1

44

4

4

5

55

53

3

34

3

3

4

15

24

2

共通ディクショナリー

NAME ID

AUDI 0

BMW 1

CADILLAC 2

PORSCHE 3

TESLA 4

VW 5

33


その他12.2 でのパフォーマンス改良点• ベクター集計(VECTOR GROUP BY)がより多くの場合で実行可能に

– 12.1.0.2では比較的保守的に実行方法を選択し、HASH GROUP BYになる場合が多かった

– 12.1.0.2 では /*+ VECTOR_TRANSFORM */ヒントをつけてもIMA実行方法にならない場合があった

• ZoneMap 機能使用可能に• ベクター集計の際に作られる一時表操作が全てメモリー上で完結• DML時のクエリー実行時間への影響を最小化

–無効化の粒度が行全体ではなくカラムレベルに–インメモリー領域のSCN毎の有効行を保持する(CRクローン)

• インメモリー領域からのサンプリングが可能に34


本セッションでお伝えしたかったこと• 12c R2のデータベース・インメモリー機能は12cR1を着実に進化させた製品です.–基礎性能の向上

• Active Data Guardのスタンバイでインメモリーが可能になったことによりスタンバイの有効利用、および、場合によってはより多くのデータをインメモリーで分析することが可能になりました.

• いくつかの足回り的な機能により使いやすさが向上しました.• いくつかの高速化機能により高速化する分析的クエリーのパターンが増えました.

35

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 36

Oracle Database 12c 対応研修コースのご案内

Oracle Database 12c: SQL 基礎 I (3日間)

Oracle Database 12c: 管理ワークショップ

(5日間)

Oracle Database 12c: SQL チューニングワークショップ

(3日間)

Oracle Database 12c: PL/SQL プログラム開発 (3日間)

Oracle Database 12c: インストール＆アップグレード

(2日間)

Oracle Database 12c: バックアップ・リカバリ(5日間)

Oracle Database 12c: 新機能(5日間)

Oracle Database 12c: セキュリティ

(5日間)

Oracle Database 12c:Clusterware 管理

(4日間)

Oracle Database 12c:RAC 管理(4日間)

Oracle Database 12c: PL/SQL 基礎

(2日間)

データベース設計(3日間)

Oracle Database 12c: パフォーマンス・チューニング

(5日間)

Bronze

Silver

Platinum

Gold

Oracle Database 12c: SQL 基礎 II

(2日間)

Oracle Database 11g: データ・マイニング

手法(2 日間)

Oracle Database 12c: Database Vault

(2日間)

Oracle ではじめる統計入門(1 日間)

Oracle R Enterprise エッセンシャルズ

(2 日間)

※ Oracle Database 12cR2対応研修は順次提供予定です。詳しくはオラクルユニバーシティまでお問い合わせください。

Oracle Database 12c: マルチテナント・アーキテクチャ

(2日間)

Oracle Database 12c: ASM 管理(2日間)

Oracle Database 12c: 管理クイック・スタート(2日間)

Oracle Database 12c: 管理ネクスト・ステップ(3日間)

Adva

nced

Ana

lytic

s O

ptio

n 対応コース

基礎から上級スキルまで。Oracle Database 12c の製品機能を学習できる多彩な研修コースでスキルアップを


Oracle Digitalは、オラクル製品の導入をご検討いただく際の総合窓口。電話とインターネットによるダイレクトなコニュニケーションで、どんなお問い合わせにもすばやく対応します。

もちろん、無償。どんなことでも、ご相談ください。

http://www.oracle.com/jp/contact-us/index.html

DBA & Developer Day 2016...

Documents

Transcript of DBA & Developer Day 2016...