Autonomous を支える技術、Oracle Database 18c デモンストレーション

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. |
Oracle Database Connect 2018
Oracle Database 18c
デモンストレーションと共に
日本オラクル株式会社
クラウド・プラットフォームソリューション統括
Cloud Platform ソリューション本部
Database ソリューション部
髙橋敏行
Autonomous を支える技術

Safe Harbor Statement
The following is intended to outline our general product direction. It is
intended for information purposes only, and may not be incorporated into
any contract. It is not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making purchasing
decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion
of Oracle.
2

$> whoami
•なまえ : 髙橋敏行
(たかはしとしゆき)
Twitter : @YukkiTakahashi
Facebook : Toshiyuki Takahashi
SNS Info
• しごと
Database 製品担当
(技術検証、PoC）
Database Fix Delivery
（不具合修正パッチの提供）
金融機関のお客様担当エンジニア
（DBソリューション提案）
Database 製品担当
（案件支援、技術支援、情報発信）
今ココ
3
Call me ゆっきー

ゆっきーの週刊DBちゃんねる
～30秒でちょっといい話～
• 役立つおすすめ技術コンテンツを
高速にご紹介してます
• 世の中にたくさん出ている
Oracle Database の
技術コンテンツをピックアップ、
ぎゅっと凝縮してお届けします！
• 週刊の動画連載です
• ゆっきー@YouTuber
ご参考
オラクルゆっきー youtube 検索
おかげさまで、総累計視聴回数
30,000 view を
突破しました！！ (2018/3時点)
4

本日の内容
Oracle Database 18c
マルチテナント
データベース管理
Autonomous Data Warehouse Cloud
Appendix
1
4
3
2
5

Oracle Database 18c
6

はじめに
Autonomous と 18c について
7

Autonomous Database を構成するテクノロジー
Autonomous
Database
Oracle
Cloud
Oracle Autonomous
Database Cloud tooling
Oracle Database 18c
多くの自動化された
データベース機能を提供
セルフ・ドライビング・
オートメーションに
注力した統一された
標準プラットフォーム
それぞれの
ワークロードを
自動的に最適化
本セッションの内容
8

ここで
Oracle Database 18c とは？
9

Oracle Database 18c
• 年次リリース・モデル (2018)
– 品質の向上
– 新機能の早期取り込み
• 各プラットフォームのリリース時期情報
– Release Schedule of Current Database Releases
• MOS Doc 742060.1
10

ライフタイム・サポートの考え方
• 18c/19c のライフタイム・サポート
– 18c : 12.2.0.2 相当
– 19c : 12.2.0.3 相当
– 12.2 のライフタイム・サポート・ポリシーを踏襲
Lifetime Support Policy
詳細はこちらを参照 : MOS Doc 742060.1
11

18c 新機能ついて
12

18c 新機能～今回は 2 つのカテゴリでご紹介～
マルチテナント・アーキテクチャ
オペレーション(管理)
1
2 デモ
13

1. マルチテナント・アーキテクチャー
Multitenant Architecture
14

皆様、
ご存じですか？
15

簡単に
ご紹介します
Oracle Database 12c 以降の
標準的なアーキテクチャです
16

Oracle Database 12c 開発背景
欧州グローバル金融機関における課題
発生していた課題
① 非効率で肥大化するシステム
② 複雑で属人化する作業
③ 維持コストの増大
④ 低下するガバナンス
Oracle Database 12c
 統合でリソース利用率向上
 DB層での統合・マルチテナント化
 複製・プロビジョニングの自動化
 複数DBの一括管理・運用
1
2
3
4
データベース
クラウド構築
17

オラクル・マルチテナント・アーキテクチャ
データベースの統合とシンプルな運用のための新しいアーキテクチャ
アプリケーションごとにPDBの提供
• ポータビリティ/可搬性 (プラガビリティ)
• 高速なプロビジョニング (クローン)
• アプリケーションの変更は不要
メモリーとバックグラウンド・プロセスの共有
• より多くのアプリケーションを稼働できる
CDB$Rootで共通オペレーションの実施
• Manage many as one
(アップグレード、パッチ適用、バックアップ、HA構成)
• 細かい制御も可能
CDB (Container Database)
PDB1
PDB2
PDB$SEED
1. プラガブルデータベース(PDB)
 ポータビリティ/可搬性 (プラガビリティ)
 高速なプロビジョニング (クローン)
 アプリケーションの変更は不要
2. コンテナデータベース(CDB)
 一括した共通オペレーション
 細かい制御も可能
3. メモリーとバックグラウンド・プロセスの共有
 高いリソース利用効率
 より多くのアプリケーションを稼働できる
18

PDB1
PDB2
PDB$SEED
PDBPDB
19

PDB1
PDB2
PDB$SEED
CDB
20

PDB1
PDB2
PDB$SEED
 より多くのアプリケーションを稼働できるCDB単位で共有
21

方式
Virtual Machines
サーバ統合
(インスタンス分割)
データベース統合
(スキーマ分割)
マルチテナント・
アーキテクチャ
構成
リソースの集約と手法
データベース統合の形態
CDB
PDBPDBPDB
App App App
OS
DB
SchemaSchemaSchema
OS
App App App
OS
DB DB DB
App App App
Hypervisor
App App App
Guest
OS
Guest
OS
Guest
OS
DB DB DB
仮想マシンの利用
共有サーバ上で
個々のデータベース
1つのデータベースに
スキーマで統合
リソース効率は良いが、
移行コストが高い
システム毎にDBがリソースを
取るためリソース効率に課題
リソースと管理コストの
オーバーヘッドが大きい
低い統合コストに加え
分離性と統合密度を両立
仮想DBによる統合
22

[ご参考] マルチテナント・アーキテクチャ構成要素
ユーザ・データはプラガブル・データベース(PDB)に格納され物理的に分離される
マルチテナント・コンテナ・データベース（CDB）
シード（PDB$SEED）
ルート（CDB$ROOT）
プラガブル・データベース（PDB）
ユーザーデータ
内部的な管理データ
23
統合しやすく
密度が高い

[ご参考] データ・ディクショナリ・ビュー
• データ・ディクショナリ・ビューの種類には、次の 4つがある
データ・ディクショナリ・ビューの種類
CDB_xxx
• ルートおよび全 PDB 内のオブジェクトに関する情報
DBA_xxx
• ルートあるいは PDB 内のオブジェクトに関する情報
ALL_xxx
• ユーザーがアクセス可能なオブジェクトに関する情報
USER_xxx
• ユーザーが所有するオブジェクトに関する情報
新たに追加
24

12.1以前のアーキテクチャマルチテナントにおけるアーキテクチャ
Oracleのメタデータとユーザー・データ
メタデータユーザー・データ
root
PDB
メタデータユーザー・データ
＊Oracle に関するメタデータは CDB$ROOT で保持
＊アプリケーションに関するメタデータは各 PDB で保持
マルチテナントによる解決
- 水平分割されたデータ・ディクショナリ
- Oracle固有のメタデータのみがrootに存在
→可搬性の高いアーキテクチャ
従来のアーキテクチャにおける課題
- ユーザ・データをデータベースに格納する際、
Oracleとユーザのメタデータが混在
→可搬性に課題が生じる
25

マルチテナント・アーキテクチャのプロビジョニング
PDBの高速なクローニング
<運用中>
CDB1
ローカルCDB内
クローニング
<開発環境1>
CDB2
 リモートCDBから
クローニング
 アンプラグ&プラグ
1ステップでコピーが可能
26

PDB ホット・クローン
•PDB ホット・クローン
–オンラインでテスト・マスターを作成
CRM
開発 / テスト
Pricing Retail CRM
Snap Clone
Snap Clone
CRM Dev1 CRM Dev2
開発者データベースへの変更
ホット・クローン
本番
27

現在 ( ～12.2.0.1 )
• コンテナによるデータベースの仮想化
• 多くのデータベースを 1 つとして管理
– パッチ適用、バックアップ、セキュリティ、
オンライン・クローニング、オンライン再配置
• Software as a Service
– 共有メタデータ、データ位置の透過性
Oracle Database 18c
( 12.2.0.2)
• リフレッシュ可能 PDB スイッチ・オーバー
• スナップショット・カルーセル
• トランスポータブル・バックアップ
• 高速アップグレード
Oracle Database 18c のマルチテナント・アーキテクチャ
28

ここで
新機能の話の前に、
29

APテストの時、過去のデータベース
断面でテストをしたいって、
言われたことありませんか？
30

開発者(東京都 S.Nさん)の声
「手動または定期的に自動取得された
データベース断面があったら、嬉しい」
テスト時やAP監視時で、過去に遡って調べる必要があるとき
→再現するためには過去のDBの断面が必要
マイクロサービス開発のように、複数AP/DBがある場合
→他の機能(AP/DB)に影響しないと嬉しい過去DB1AP検証
31

できるんです、18cでは
PDB スナップショット・カルーセル
32

PDB スナップショット
–ある時点の
(point-in-time)
PDB コピー
–PDB ホット・クローンの
仕組みを利用して取得
–取得スナップショットは
フル・クローン
定期的な PDB の point-in-time コピーのリポジトリ
16th
15th14th
13th
12th
11th10th
9th
T-0
T-1 T-2
T-3
T-4
T-5T-6
T-7
33

・カルーセル
–PDBスナップショット
のリポジトリ
–最大 8 つまで (18c時点)
PDB スナップショットを保持
–カルーセルが一杯の状態では
最古のスナップショットを削除
16th
15th14th
13th
12th
11th10th
9th
T-0
T-1 T-2
T-3
T-4
T-5T-6
T-7
・カルーセル
34

• MANUAL (デフォルト)
– 手動でスナップショットを取得
• EVERY <スナップショット間隔> [ 分 | 時間 ]
– 指定した間隔で自動的にスナップショットを取得
– 設定可能な間隔 (分指定 3,000 分 / 時間指定 2,000 時間 )
• NONE
– PDB スナップショットの取得を無効化
利用可能なスナップショット・モード
35

・カルーセル
–カルーセル内のPDBスナップ
ショットからPDBを作成
–作成されたPDBは
フル・クローンと同じ
–READ/WRITE オープン可
16th
15th14th
13th
12th
11th10th
9th
T-0
T-1 T-2
T-3
T-4
T-5T-6
T-7
CREATE PLUGGABLE DATABASE
... USING SNAPSHOT
36

から、もう 1 つご紹介します
リフレッシュ可能な PDB スイッチオーバー
37

PDB リフレッシュ
•PDB リフレッシュ
–最新のデータによるクローンの増分
リフレッシュ
CRM
開発 / テスト
Pricing Retail CRM
Snap Clone
Snap Clone
CRM Dev1 CRM Dev2
開発者
時間
データベースへの変更
変更のみコピー、適用
本番
38

再度
新機能ご紹介、の前に
39

APのデプロイに合わせて
PDBを無停止で切り替えられたら
便利じゃありませんか？
環境1
環境2
スタンバイ
プライマリ
切替え
40
AP DB
デプロイ

できるんです、18cでは
41

Oracleではトランザクションを守る
機能が 12.1 からあります
この機能と組み合わせて実現します
+ Application Continuity
42

[補足] Application Continuity (AC)
RACのノード障害からアプリケーションを守るデータベースアクセスの自動再実行機能
43
RACノードの
障害発生時
Oracle
RAC
アプリケーションの変更なく、ノード障害時のクエリ実行をDB層で保証
特長
未コミットのDMLを
記録し、透過的に再実行
Success!
AP Server

[補足] Application Continuity (AC)
RACのノード障害からアプリケーションを守るデータベースアクセスの自動再実行機能
44
RACノードの
障害発生時
ユーザに障害を
気付かせない
重複処理
の防止
必要に応じて
処理の自動再実行
Oracle
RAC
透過的
アプリケーションの変更なく、ノード障害時のクエリ実行をDB層で保証
特長
未コミットのDMLを
記録し、透過的に再実行
Success!
AP Server

サーバー 1
CDB1
CDB2
サーバー 2
1. create pluggable database Red;
4. create pluggable database Brown;
6. create pluggable database Grey
from Grey@CDB2_Link
refresh mode every 2 minutes;
2. create pluggable database Red
from Red@CDB1_Link
refresh mode every 2 minutes;
3. create pluggable database Gold;
5. create pluggable database Grey;
45

計画スイッチオーバー
サーバー 1
CDB1
CDB2
サーバー 2
1. alter pluggable database Grey
refresh mode every 2 minutes
from Grey@dblink switchover;
46

計画外スイッチオーバー
サーバー 1
CDB1
CDB2
サーバー 2 1. alter pluggable database Grey
refresh;
refresh mode none;
open read write;
47

リフレッシュ可能な
PDB の活用
1. PDB リフレッシュ可能な PDB スイッチオーバー
2. PDB スナップショット・カルーセル
Demonstration
48

1. PDB リフレッシュ可能な
PDB スイッチオーバー
Demonstration
49

AP
DB02
DB03
TXN1 : 200
TXN2 : 200
TXN3 : 200
TXN1 : 300
TXN2 : 200
TXN3 : 200
TXN1 (100行挿入)
TXN2 (100行挿入)
TXN3 (100行挿入)
PDB
スイッチオーバー
Demonstration
50

ここで
PDBスイッチオーバー内部挙動
今の動きをプレイバック！！
51
Demonstration

AP
DB02
DB03
TXN1 (100行挿入)
TXN2 (100行挿入)
TXN3 (100行挿入)
TXN1 : 200
TXN2 : 100
TXN3 : 100
TXN1 : 100
TXN2 : 100
TXN3 : 100
Demonstration
52
PDBスイッチオーバー
内部挙動

AP
DB02
DB03
TXN1 (100行挿入)
TXN2 (100行挿入)
TXN3 (100行挿入)
TXN1 : 200
TXN2 : 100
TXN3 : 100
TXN1 : 100
TXN2 : 100
TXN3 : 100
Demonstration
53
PDBリフレッシュ
TXN1 : 200
TXN2 : 100
TXN3 : 100
内部挙動

AP
DB02
DB03
TXN1 : 200
TXN2 : 100
TXN3 : 100
TXN1 : 100
TXN2 : 100
TXN3 : 100TXN1 (100行挿入)
TXN2 (100行挿入)
TXN3 (100行挿入)
Demonstration
54
TXN1 : 200
TXN2 : 100
TXN3 : 100
内部挙動

AP
DB02
DB03
TXN1 : 200
TXN2 : 100
TXN3 : 100
TXN1 : 100
TXN2 : 100
TXN3 : 100TXN1 (100行挿入)
TXN2 (100行挿入)
TXN3 (100行挿入)
Demonstration
55
TXN1 : 200
TXN2 : 100
TXN3 : 100
内部挙動 TXN2
ロールバック

AP
DB02
DB03
TXN1 : 200
TXN2 : 100
TXN3 : 100
TXN1 : 100
TXN2 : 100
TXN3 : 100TXN1 (100行挿入)
TXN2 (100行挿入)
TXN3 (100行挿入)
Demonstration
56
TXN1 : 200
TXN2 : 100
TXN3 : 100
ACによる
TXN2再実行
内部挙動
TXN1 : 200
TXN2 : 200
TXN3 : 100

AP
DB02
DB03
TXN1 : 200
TXN2 : 100
TXN3 : 100
TXN1 : 100
TXN2 : 100
TXN3 : 100TXN1 (100行挿入)
TXN2 (100行挿入)
TXN3 (100行挿入)
Demonstration
57
TXN1 : 200
TXN2 : 100
TXN3 : 100
内部挙動
TXN1 : 200
TXN2 : 200
TXN3 : 100
TXN2
ロールバック
PDB
スイッチオーバー

Demonstration
58

AP
DB02
DB03
TXN1 : 500
TXN2 : 500
TXN3 : 500
16th
15th14th
13th
12th
11th10th
9th
T-0
T-1T-2
T-3
T-4
T-5T-6
T-7
SOE
_S01
SOE
_S02
TXN1 : 500
TXN2 : 500
TXN3 : 500
SOE
_S01
DEV
PDBスナップショット
からPDB作成
SOE
_S02
DEV
Demonstration
59

データベース管理
Database Operation
60

データベース管理機能
自律型データベースにとって
非常に大切なジャンル
61

ゼロ・インパクト Grid Infrastructure パッチ適用
• データベース操作を中断することなく
Grid Infrastructure へのパッチ適用可能
• パッチは、1 ノードずつ out-of-place および
ローリング方式で適用
• ノード上のデータベース・インスタンスは
適用中も起動、実行し続ける
• 2 ノード以上のクラスタで構成された
RAC データベースで利用可能
パッチ適用中データベース・インスタンスを落とさない
62
※Flex ASMが必要

Autonomous Health Framework
•Oracle Clusterware 上で稼働する
システムの情報を監視/収集する機能
から成るフレームワーク
•収集したデータは
監視や分析、障害解析に利用
•蓄積したデータを予兆検知に活用
情報を集約/活用して、クラスタウェア全体の健全性を保つためのフレームワーク
Hang
Manager
Cluster
Verification
Utility
Cluster
Health
Advisor
Trace File
Analyzer
Cluster
Health
Monitor
Memory
Guard
Quality of
Service
Management
ORAchk
Managemen
t Repository
63

Autonomous Health Frameworkに含まれる機能
• OS状態確認やGI/RAC環境の必須要件、
ベスト・プラクティスをチェックし、レポーティング
• Grid Infrastructure やデータベースが稼働する環境
全体の構成をレポーティング
• ベスプラとの乖離や潜在的な既知問題を確認可能
• OSのメトリックを監視/収集
• 蓄積データは分析に活用でき、様々な機能で
使用される
• データベースのハングを検知した際に、原因をロジカルに
分析、解決可能な問題に対処
• 自動で解決して継続稼働と性能を保つ
• メモリーの使用率に応じて接続を制御し、
アプリケーションからの処理を保護
• RAC環境でメモリー不足による障害を防止
• Grid Infrastructure、データベースなどのログ収集・
分析をシンプルに行えるツール
• 問題発生時の分析の迅速化を図る
• AHF関連機能のデータを蓄積する
リポジトリ・データベース
Cluster Verification Utility
ORAchk/EXAchk
Cluster Health Monitor/Advisor
Hang Manager
Memory Guard
Grid Infrastructure Management Repository
Trace File Analyzer
• SLA担保の為に、システム全体のワークロードを監視
• 状態に応じてパフォーマンスレベルに合わせた
リソース割り当てを自動的に行える
Quality of Service Management
64

ochad
Fault Detector
Diagnosis Engine
DB
Health
Node
Health
Cluster Health Advisor (CHA)
• デフォルト有効
• CHMのデータから、クラスタ内のノードや
データベースの性能問題を検知/分析
• 早めのアラートとアクションを提示
• 分析結果はGIMR に蓄積
• GUI(EMCC/CHAG)、CUI(CHACTL)
から監視可能
• インシデント・マネージャーや通知機能と連携
クラスターノードやデータベースに対するリアルタイム診断と処置
* RACもしくはRAC One Node ライセンスが必要
GIMR
CHAG
EMCC
OS Data
CHM
chactl>
DB Data
65

Cluster Health Advisor – 機械学習
• 実際の社内外顧客データから
モデル開発を推進
• 知識抽出のための機械学習
– 専門の開発チームによってデータを精査
• ベイジアン・ネットワークベースを
用いた根本原因の診断モデル生成
– リアルタイム予測のためベイジアン・
ネットワークに基づくリアルタイム・モデル
クラスタやデータベースの潜在的な問題を発見
CHA Dev Team
ASH
機械学習
知識抽出
BN
Models
CHA
Runtime
Model
Feedback
CHA
CHA
Scrub Data
Expert
Supervision
66

障害検知/診断インタフェース
Cluster Health Advisor
Machine
Learning,
Pattern
Recognition, &
BN Engines
Time CPU ASM
IOPS
Network
% util
Network_
Packets
Dropped
Log
file
sync
Log file
parallel
write
Gc cr
request
Gc current
request
Gc current
block 2-way
Gc
current
block
busy
Enq:
CF -
conte
ntion
…
15:16:00 0.90
0.85
4100
4550
88%
39%
105
0
2 ms
2.3
600 us
620 us
504 ms
200 us
513 ms
250us
2 ms
250 us
5.9 ms
1.5 ms
0
0
15:16:00 OK OK HIGH HIGH OK OK HIGH HIGH HIGH HIGH OK
ABNORMAL: Network Bandwidth Utilization - explains
ABNORMAL: Network Packet Loss - explains
ABNORMAL: Global Cache Requests Incomplete
ABNORMAL: Global Cache Message Latency Slow
Input : Data Point at Time t
Fault Detection and Classification
Diagnostic Inference
Green : Predicted
67

Enterprise Manager Cloud Control (EMCC) の画面
問題の分析と
解決策の提示

ADWC
69

Autonomous Data
Warehouse Cloud
サービス・インスタンスの
作成 Demonstration
70

まとめ
71

まとめ
• Oracle Database 18c
– 年次リリース・モデル
– 新機能の取り込みと品質向上
• マルチテナント
– PDB スナップショット・カルーセル
– PDB リフレッシュ可能な PDB ス
イッチオーバー
•データベース管理
– ゼロ・インパクト GI パッチ適用
– Cluster Health Advisor
• Autonomous Data
Warehouse Cloud
72

自律型データベースを実現するテクノロジー
73
Oracle は 10 年以上かけてデータベース自動化テクノロジーを開発
Cost-based
Optimization
Performance Tuning
and Diagnostics
Data
Optimization
Cloud-Scale
Operations
Automatic SQL Query
Optimization
自動メモリー、リソース管理
Automatic memory and resource
management
自動 UNDO 管理
Automatic undo
management
Automatic Standby
Management (Broker)
自動統計収集
Automatic statistics gathering
自動インデックス、マテリアライズド・ビュー・ア
ドバイザ
Automatic index and materialized
view advisors
自動セグメント領域管理
Automatic segment space
management
自動診断フレームワーク
Automatic Diagnostic
Framework
クエリー・リライト
Automatic query rewrite
自動データベース診断モニター
Automatic Database Diagnostic
Monitor (ADDM)
自動ストレージ管理
Automatic Storage
Management (ASM)
Multitenant Architecture
自動 SQL 計画管理
Automatic SQL Plan
management
自動データベース・ワークロード・リプレイ
Automatic Database Workload
capture & replay
自動データ最適化
Automatic Data
Optimization
Automatic Database
Clone Refresh
自動 SQL チューニング
Automatic SQL tuning
Automatic Workload Repository
(AWR)
Automatic columnar
cache
ML in Cluster Health
Advisor

まとめ
自動化、自律型に向けた機能の
継続的な進化が
Autonomous を支えていく
Autonomous Database
74

Appendix
- Autonomous Data Warehouse Cloud
- マルチテナント・アーキテクチャ
- パフォーマンス – 18c Improvements
75

データウェアハウスのための自律型データベース・クラウド
簡単な設定ですぐにDBが構築、利用可能に
チューニングが不要でデータ管理に人手をかけない
パッチ適用やバックアップの自動化 - DBA工数の削減簡単に使える
Exadataのテクノロジーを最大限活かした高速性能
大規模な同時アクセスにも対応
AWS Redshift と比べた優れたコストパフォーマンスパフォーマンス
初期投資不要、使った分だけの課金
CPUやストレージは稼働中に拡張・縮退可能
ピーク時にリソースを増やす、不要時に停止など柔軟柔軟性
76
Autonomous

導入フェーズ構築フェーズ運用フェーズ
Autonomous Data Warehouse Cloudのもたらす価値
①すぐに使える
• 早ければ30秒で
データベース構築
• 構築コスト削減
• 初期投資不要
②Elastic
• CPU/ストレージは
拡張・縮退可能
• 費用は使った分だけ
• 事前のサイジングは
必要なし
③チューニング不要
• 索引やパーティションの設
計コスト削減
• Exadataの業界を
リードするパフォーマンスに
よって高速
④ピーク時対応
• 月末のピークなど必要な際
にオンデマンドで拡張可能
• 事前の設計コストやサービ
ス費用削減
⑤自動運用
• パッチ適用、バックアップ
など運用の
自動化
• DBAコスト削減
⑥システム拡張
• 無停止でCPU/ストレー
ジの拡張可能
• 拡張時のシステム再設
計やデータ移行が不要
77
Autonomous

Oracle マルチテナント・アーキテクチャの運用管理
バックアップ作業の効率化と簡単な開発・検証環境作成本日の内容
78

マルチテナント・コンテナ・データベースの物理構造
79
データベース関連ファイル
CDB
CDB$ROOT
制御ファイル
REDO ログ
ファイル
アーカイブ
REDO
ログファイル
PDB 2
データファイル
SYSTEM SYSAUX USERS TEMP
PDB$SEED
SYSTEM SYSAUX TEMP
SYSTEM SYSAUX USERS TEMP UNDO
PDB n
・・・
PDB 1

データ・ディクショナリ・ビューの例（CDB_xxx）
• 接頭辞が CDB_ であるビューには、すべてのコンテナの情報が含まれる
– ルートおよび、すべての PDB の情報を確認することが可能
CDB_TABLESPACES ビュー
SQL> SELECT TABLESPACE_NAME, STATUS, CON_ID FROM CDB_TABLESPACES;
TABLESPACE_NAME STATUS CON_ID
-------------------- -------------------- ----------
SYSTEM ONLINE 1
SYSAUX ONLINE 1
UNDOTBS1 ONLINE 1
TEMP ONLINE 1
USERS ONLINE 1
SYSTEM ONLINE 2
SYSAUX ONLINE 2
TEMP ONLINE 2
8行が選択されました。
ルートの表領域
PDB の表領域
80

パフォーマンス
Database Performance
81

Top-N approximate aggregation
• 上位-N クエリに対する概算結果
– おおよそどの程度のページ・ビューが上位 5 つの blog 投稿に対して先週あったか?
– 各地域のトップ 50 の顧客と、そのおおよその支出は?
• 高い精度でひと桁速い処理 (エラー率 < 0.5%)
• 新しい近似関数 APPROX_COUNT(), APPROX_SUM(), APPROX_RANK()
テラバイトのデータに対するインタラクティブな応答時間
SELECT blog_post, APPROX_COUNT(*)
FROM weblog
GROUP BY blog_post
FETCH FIRST 5 ROWS ONLY;
SELECT region, customer_name,
APPROX_RANK(PARTITION BY region
ORDER BY APPROX_SUM(sales) DESC) appr_rank,
APPROX_SUM(sales) appr_sales
FROM sales_transactions
GROUP BY region, customer_name
HAVING APPROX_RANK(..) <=50;
近似ヒット数によるトップ 5 blogs 各地域のトップ 50 顧客とおおよその支出
82

Oracle Database In-Memory
について
83

２種類の主要なデータベース・フォーマット
データベースの主要なデータフォーマットとして、ロー型とカラム型が存在
ロー型
(行)
OLTP処理の高速化に向く
例：注文データの挿入と検索
カラム型
(列)
集計、分析処理の高速化に向く
例：都道府県毎の売上合計のレポート
売上
売上
Oracle Database In-Memoryは
２種類のフォーマットを同時にメモリ上で実現
84

SGA
• データベースのメモリ空間内で、同一の
データをロー型、カラム型双方のデータ
フォーマットで保有
• 双方のデータ・フォーマットを使い分けること
で、全てのデータベース処理の高速化を実
現
– 分析、集計処理はカラム型フォーマットに対して実行
– OLTP処理はロー型フォーマットに対して実行
• トランザクションの一貫性は保証される
インメモリ・デュアル・フォーマット
同一データをメモリ上で2種類のフォーマットを保持し、全ての処理を高速化
メモリメモリ
売上表売上表
ロー型
フォーマット
カラム型
フォーマット
売上表ディスク上には
ロー型のみ
85

デュアル・フォーマットの透過的/効果的な活用
データベースのオプティマイザがSQLにあわせて最適なフォーマットを選択
ロー型
カラム型
select * from sales
where order_id = ‘ABC123’;
select region, sum(amount)
from sales
group by region;
Oracle Database
オプティマイザ
sales表
デュアル・フォーマット
B-Tree索引を
使用した処理
インメモリ検索を
使用した処理
少数の行の全カラムのデータ取得
一部の列を使った大量行の集計処理
SQL毎に処理するデータフォーマットを変えることが可能
同一の表をOLTP処理にも、DWH処理にも利用することが可能
86

System Global Area (SGA)
Buffer Cache Shared Pool Redo Buffer
Large Pool
Other shared
Memory
Components
In-Memory
Area
INMEMORY_SIZE
パラメータ
インメモリ・カラム・ストアの基本構成
SGA内の新たな領域として、
インメモリ領域を追加
INMEMORY_SIZE
パラメータによりサイズ設
定
最小値は100MB
SGA_TARGET は十分に
大きな値の設定が必要
静的プールとして確保
87

インメモリ領域
インメモリデータ配置中も処理を継続可能
新たなバックグランド・プロセスがメモリ上に配置(ポピュレート)
ディスク上には
ロー型フォーマットの
み保存
優先
レベル
ロードタイミング Note
CRITICAL データベース起動後一番優先度が高い
HIGH データベース起動後 CRITICALの次の優先度
MEDIUM データベース起動後 HIGHの次の優先度
LOW データベース起動後 MEDIUMの次の優先度
NONE 初回オブジェクトアクセス時デフォルト値
バックグランド・プロセス
（ポピュレート）
ロー型
カラム型
ロー型→
カラム型
変換
メモリ上にカラム型データのポピュレート完了まで、ロー型データを利用し処理が可能
メモリへの展開(配置)を待つことなく業務処理を開始する事が可能
パラメータでプロセス数を設定可能
テーブル毎に優先度を設定することが可能
88

• インメモリ・カラムストア
• Software in Silicon
• Engineered Systems
• 低レイテンシ・メモリ・トランザクション
• 不揮発性メモリのサポート
– 多階層のデータベース・キャッシュ
• インメモリ・カラムストアの機能拡張
– 自動ポピュレーション
パフォーマンス
現在 Oracle Database 18c
89

In-Memory 18c 主要機能
• 自動インメモリ管理
• 外部表に対する In-Memory
• In-Memory for Extreme Capacity
NVRAM Memory
• Many performance improvements:
–In-Memory ダイナミック・スキャン
–混合ワークロード・パフォーマンス改善
90

自動インメモリ管理
•ヒート・マップ (アクセス統計) を利用し、
インメモリ・テーブルおよびパーティションを
自動的にランク付け
•ホットな (アクセス頻度の高い) データを
自動的に判断してポピュレート(配置)
•コールド (アクセス頻度の低い)
インメモリ・データは自動的に除去
クラウド・サービスの自動化と管理を低減
Sales_Q3
Sales_Q2
Sales_Q4
インメモリ・カラム・ストア
Sales
_Q1
91

インライン外部表
• 実行時に提供される外部表定義
– インライン・ビューと類似
• 一度のみ使われる外部表を事前に作成する必要なし
– 開発者の生産性向上
外部データへの透過的アクセス
INSERT INTO sales
SELECT sales_xt.*
FROM EXTERNAL(
(prod_id number, … )
TYPE ORACLE_LOADER
…
LOCATION ’new_sales_kw13')
REJECT LIMIT UNLIMITED );
CREATE TABLE sales_xt
(prod_id number, … )
TYPE ORACLE_LOADER
…
LOCATION ’new_sales_kw13')
REJECT LIMIT UNLIMITED );
INSERT INTO sales SELECT * FROM sales_xt;
DROP TABLE sales_xt;
92

In-Memory For External Tables
• 外部データの超高速分析
• データベース外部のデータの
インメモリ・カラム・キャッシュ
• すべてのインメモリ最適化を適用
–ベクター処理, JSON
Expressions は外部表に対して
透過的に拡張
• 最大 x100 高速
外部データの高速分析
インメモリ
外部表
RDBMS
インメモリ
データベース
テーブル
外部データ
DB TABLES
オブジェクト・
ストレージ
ファイル
Hadoop
93

無料トライアル
実施中
*Autonomous Data Warehouse Cloudをお試し頂けます
https://cloud.oracle.com/ja_JP/tryit

Autonomous を支える技術、Oracle Database 18c デモンストレーション

Autonomous を支える技術、Oracle Database 18c デモンストレーション

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Autonomous を支える技術、Oracle Database 18c デモンストレーション

Similar to Autonomous を支える技術、Oracle Database 18c デモンストレーション (20)

More from オラクルエンジニア通信

More from オラクルエンジニア通信 (20)

Autonomous を支える技術、Oracle Database 18c デモンストレーション