Oracle Database 機能概要

Oracle Database機能概要
Oracle Database 19c
日本オラクル株式会社
2021/02/05

View Slide

• Introduction
• Parallel Query
• Oracle Partitioning
• Advanced Compression
• Database In-Memory
• Diagnostics Pack & Oracle Tuning
Pack
• Recovery Manager
• Database Lifecycle Management
Pack
• Multitenant
• Real Application Clusters
• Automatic Storage Management
• Data Guard & Oracle Active Data
Guard
• GoldenGate
• Advanced Security
• Database Vault
• Audit Vault and Database Firewall
• Real Application Testing
• Data Masking and Subsetting Pack
• Machine Learning
• Spatial
• Big Data SQL
• Oracle Net Services
• External Table
• Database Link
• Materialized View
• Automatic Indexing
• Optimizer Statistics
• Server Result Cache
• Memoptimized Rowstore
• Flashback Technology
資料内容
Copyright © 2021, Oracle and/or its affiliates
2

View Slide

DB-Engines Ranking
Oracle Database is #1 Database
3
https://db-engines.com/en/ranking_trend

View Slide

私たちのミッションは、人々が新たな方法
でデータを理解し、本質を見極め、無限
の可能性を解き放てるよう支援していくこ
とです。

View Slide

設立前 AMPEX社に勤務していたLarry Ellisonが、
CIAのプロジェクトOracleに参画
1977年 Software Development Labs設立
1978年 CIAが最初の顧客
1979年世界で初めてリレーショナル・データベースを
商用化(Oracle Version 2)
Wright-Patterson空軍基地が採用
1982年企業名をOracle Systems Corporationに
改名
1995年企業名をOracle Corporationに改名
Oracle Databaseの生い立ち
5
Ed Oats Bruce Scott Bob Miner Larry Ellison

View Slide

時代の要望に応じた継続的なイノベーション
Oracle Databaseの歴史
6
メインフレームと
ミニコンの時代
クライアント/サーバーの時代インターネット・
コンピューティングの時代
クラウドと
ビッグデータの時代
●
Oracle v2
世界初商用RDBMS
●
Oracle v4
読み取り
一貫性
●
Oracle v5
クライアント/
サーバー
● ●
Oracle v6
行レベルロック
PL/SQL
Oracle7
パラレルクエリー
ストアドプロシージャ
●
Oracle8
パーティショニング
オブジェクト指向
●
Java/XML
マテリアライズド・ビュー
●
Real Application Clusters
Data Guard
●
自動データベース診断
ASM
●
Exadata
Active Data Guard
● ●
Multitenant
Database In-Memory
Autonomous Database Cloud
●
Automatic Indexing

View Slide

リレーショナルデータベース登場から40年。何度か単機能データベースが注目される時期もあるが、
その後淘汰されてコンバージド・データベースが選択されるトレンド
繰り返されるデータベースのトレンド
7
1970s
Relational
DB
1980s
Object DBs
Converged DB
XML DBs
Converged DB
JSON DBs
Converged DB
1990s 2000s 2010s 2020s
Cobol
ISAM
Next DB?
Solution Complexity
注目された製品のその後は…

View Slide

かつては、携帯電話、音楽プレイヤー、手帳、時計、カメラなど、
異なる製品が必要だった
→ 今ではその機能の多くがスマートフォンに包含されている
かつては、OLTP、Analytics、XML、In-Memory、JSONなど、
異なるデータベースが必要だった
→ 今ではその機能の多くがコンバージド・データベースに包含されている
時代はコンバージド・データベース
8

View Slide

マルチモデル
• リレーショナル、JSON、XML、
グラフ、地理空間データ、OLAP
マルチワークロード
• OLTP、分析処理、インメモリー、IoT、
Streaming、Blockchain
マルチテナント
• データベースのためのコンテナ仮想化と
オーケストレーション
• テナントデータベースに対して、分離、
スケールアウト、トランザクションの一貫性を提供
Oracle Databaseはコンバージド・データベース
9
アナリストや開発者、運用者にとっての
主なメリット
• すべてのデータを網羅するオープン
スタンダードなSQLに加えて、
RESTなどの一般的なAPIも
利用可能
• トランザクションをすべてのデータで
サポート
• すべてのデータの一貫性のある、
クエリ可能なビュー
• 信頼性、スケーラビリティ、
セキュリティ

View Slide

主要プラットフォーム上で動作し、お客様の投資を保護
他のデータベース
• 各データベースは、独自のハードウェアやプラット
フォーム上でのみ動作する
= ベンダー・ロックイン
• 他のプラットフォームに移行するには既存資産を
改修する必要有り
Oracle Database
• どのプラットフォームでも全く同じデータベースが動作
= ロックインなし
• Exadata、Autonomous Databaseも同様
• アプリケーションを変更せず、他のプラットフォーム上へ
容易に移行可能
Oracle Databaseの特長 - マルチプラットフォーム対応
DB2
for z/OS
zOS
IBM MF
SQL
Server
Windows
x86 HW
Aurora
AWS
SQL
Azure
MS
Azure
Oracle Database
UNIX Linux Windows
AWS
MS
Azure
Oracle
Cloud
HPE IBM Oracle x86 HW
10

View Slide

Oracle Databaseは、異なる特性の処理であっても最適化機能を同一データベースで提供
• オンライン・トランザクション処理
• トレーディング・システムやショッピング・サイトなど
• 同時、大量ユーザー、低レイテンシ
• 分析処理
• ペタバイト級のデータ・ウェアハウスなど
• 大量データ、大量処理
コンピュート・ノードとストレージのそれぞれをスケールアウトさせることが可能
Oracle Databaseの特長 - パフォーマンスとスケーラビリティ
ストレージ
コンピュート・ノード
11

View Slide

数十年にわたって、世界中のミッション・クリティカル・システムを支え続けてきた実績
• 最大のデータ保護を実現
• アプリケーションの停止を極小化
• Oracle Databaseに組み込まれ、自動化された機能
• 高いROI (投資回収率)
実績をもとに作成されたベスト・プラクティス
Oracle Maximum Availability Architecture (MAA)
• データベース・サーバーに関わる全階層を考慮
• コンピュート、ストレージ、サイトを冗長化可能
• システムの可用性要件に応じて最適な
リファレンス・アーキテクチャを選択
Oracle Databaseの特長 - 高可用性
12
サイト・レプリケーション
Oracleクライアント
コンピュート・
ノード
ストレージ
接続フェイルオーバー

View Slide

Oracle Databaseは機密データを保護するあらゆる機能を提供
• データベースを評価し、セキュリティ・リスク軽減や改善の対象となる箇所を特定
• ポリシーに違反するデータ・アクセスの試みを検知
• アクセス制御や暗号化等により、データへの不適切あるいはポリシーに違反するアクセスを防止
世界中の政府/国防機関で使われ続けてきた実績
• CIAのプロジェクトから始まったOracle Database
• 軍事用に開発された技術を民生転用
• Oracle Databaseのエンジンに組み込まれた機能
• 既存のアプリケーションに修正を加えずセキュリティ実装が可能
• システムのセキュリティ要件に応じて最適なソリューションを選択可能
• 実績をもとに作成されたリファレンス・アーキテクチャ
Oracle Maximum Security Architecture (MSA)
Oracle Databaseの特長 - 堅牢なセキュリティ
13

View Slide

14
Oracle Databaseのパラレル実行

View Slide

大量データの処理を分割し、複数のハードウェア(CPU/ストレージ)に
割り当てて同時に実行することで、全体の処理時間を短縮する技法
パラレル実行
15
並列度
処理時間
並列度1 並列度2 並列度4

View Slide

Exadata X8M-2に使用されているデータベース・サーバー
は1RUサイズのIntel Xeon 2ソケット・マシン
CPU
• Intel Xeon 8260 Cascade Lake (24コア)
• 24コア × 2ソケット = 48コア
DRAM (DDR4)
• 32GB DIMM × 12スロット = 384GB
最近のサーバー・ハードウェア
16
CPUコア数の高密度化は1RUサイズのサーバーでも2桁の並列度を可能にした

View Slide

大量データ処理の並列化
Oracle Databaseのパラレル実行
アプリケーションのデータ操作
• SELECT
• DML (INSERT/UPDATE/DELETE/MERGE)
• PL/SQL
オブジェクトのメンテナンス
• 表/索引統計収集
• DDL (CREATE TABLE AS SELECT)
• CREATE/ALTER INDEX
物理/論理バックアップ
• RMAN BACKUP/RESTORE (ファイル・コピー)
• Data Pump
高可用性
• インスタンス・リカバリ (インスタンス障害)
• RMAN RECOVER (REDOログ適用)
• Data Guard REDO Apply
17

View Slide

1つのSQL処理を並列に処理
分析/集計処理や大量一括更新に対応
• SELECT
• DML (INSERT/UPDATE/DELETE/MERGE)
• PL/SQL
複数のパラレル実行サーバー・プロセス(PX)が
処理対象の表/索引に対してアクセスする範囲を
自動分割して同時に処理
パーティション化されていない通常の表/索引でも
パラレル処理が可能
アプリケーションのデータ操作
18
PX
PX
PX
パラレル実行
サーバー・プロセス
表/索引
PX

View Slide

オブジェクトに対するフルスキャンやソート等を並列に処理
表/索引統計収集
• オプティマイザがSQLの実行計画を決定するのに
使われる
• オブジェクトの値の分布を事前に調べる
DDL
• CREATE TABLE AS SELECT
B-Tree索引のメンテナンス
• 表の特定列の値をソートして行へのアドレスを持つ
• CREATE INDEX
• ALTER INDEX REBUILD
オブジェクトのメンテナンス
19
B-Tree索引表

View Slide

サイズの大きなファイルが複数あるコピー等を並列に処理
RMANによる物理バックアップ
• ファイル・コピーの並列化
• BACKUP
• RESTORE
Data Pumpによる論理バックアップ
• エクスポート/インポートの並列化
• 論理バックアップにはREDOログ適用はできない
物理/論理バックアップ
20
BACKUP
データファイル
アーカイブREDOログ
バックアップ

View Slide

リカバリ(REDOログ適用)操作を並列に処理
インスタンス・リカバリ
• Oracleインスタンス異常終了後のデータ一貫性の
復元の並列化
• ロールフォワード(REDOログ適用)
• ロールバック
RMANによるリカバリ
• REDOログ適用の並列化
Data Guard REDO Apply
• プライマリ・データベースから受け取ったREDOデータの
適用(リカバリ)処理の並列化
高可用性
21
REDOログ
RECOVER

View Slide

22
Oracle Partitioning

View Slide

パーティショニングのメリット
大量データを扱うシステムにおいてパフォーマンス・メンテナンスの課題を解決
• 検索パフォーマンスの向上
• 表全体に影響を与えずにパーティション毎にメンテナンス可能
エンタープライズ・エディションにおけるオプション機能
Oracle Partitioning
23
表ブロック
パーティション1
表
表1 表2

View Slide

アクセスするデータ・ブロックを減らす
SELECT * FROM t1
WHERE primary_key = value1
B-Tree索引は表の特定の列の全行の値をソートして
行へのアドレスを持っている
トランザクション系アプリケーションのようにアクセス対象の
行数が少ない場合は表ブロックのフル・スキャンよりも
索引ブロック → 表ブロックをたどった方がアクセスするデー
タ・ブロックの個数が圧倒的に少ない
SQLチューニングの基本的な考え方
B-Tree索引ブロック表表ブロック
24

View Slide

分析および集計処理
SELECT * FROM t1
WHERE column1
BETWEEN value1 AND value2
分析および集計処理では、表の中の多くの行へ
アクセスすることが必要になるケースが多い
アクセスする行数の割合が大きくなると、索引ブロックから
表ブロックへのランダム・アクセスを繰り返すよりも、
表ブロックをフル・スキャンした方が高速になる
さらにデータが増えるほど索引ブロックの階層も増えるため、
索引アクセスよりもフル・スキャンの方が高速になる
SQLチューニングの基本的な考え方
25

View Slide

列の値が特定の条件を満たすグループに表を分割する
SELECT * FROM t1
WHERE column1
BETWEEN value1 AND value2
列の値が特定の条件を満たすグループ(パーティション)に
表を分割する
SQLのWHERE句の絞り込み条件がパーティションの条件
に合致すると、該当するパーティションのみにアクセスする
(パーティション・プルーニング)
分析および集計処理の表フル・スキャンが特定の
パーティションのフル・スキャンに限定できる
パーティション表
26
表表ブロック

View Slide

アクセス対象の行数が多くなるとフル・スキャンのほうが高速
索引アクセス
索引ブロック→表ブロックのランダム・アクセスを繰り返す
パーティション・プルーニング
列の値が条件を満たすパーティションにだけアクセス
多数の行にアクセスするSQLのアクセス範囲の限定
27
表表ブロック

View Slide

アクセス範囲が表全体のサイズに影響されない
28
2020/01/01
2020/02/01
2020/03/01
2020/02/01
2020/01/01 2020/01/01
時間の経過
パーティション追加パーティション追加
1か月単位で集計するのでパーティションを1か月単位で分割する想定例
表全体のサイズは増加していくが、SQLがアクセスする範囲は1か月分のパーティションに限定される

View Slide

大量の行にアクセスする分析および集計処理の高速化
SQLのWHERE句の絞り込み条件でアクセスする範囲を
特定のパーティションに限定しIO時間の削減、高速化
処理量が表全体のサイズに影響されない
パーティション・ワイズ結合
表の結合(ジョイン)がアクセスする範囲を特定の
パーティションに限定する
パラレル実行と組み合わせることでさらに高速化が可能
パーティション化によるSQL処理の高速化
29
表1 表2

View Slide

パーティション表をさらにサブ・パーティションで分割可能
2段階のパーティション化が可能
• パーティションキーとサブ・パーティションキーは
それぞれ異なる列を指定できる
• 2段階のパーティション・プルーニング、
もしくはパーティション・プルーニングと
パーティション・ワイズ結合が異なる列で可能
コンポジット・パーティション
30
表1 表2
パーティション・ワイズ結合

View Slide

大量データのメンテナンスに関わる処理時間を削減
データ削除
• DROP PARTITION
• TRUNCATE
パーティション追加
• 空パーティション
• 別の表を取り込む
索引リビルド
圧縮
読み取り専用
パーティション単位のメンテナンス操作
31
表1 表2
列定義が同じ表をパーティションとして取り込む

View Slide

32
Advanced Compression

View Slide

データを圧縮して格納し、容量の節約と検索性能向上を実現
• データを圧縮することで、格納データ量を約1/2から1/4に抑えることが可能
• データを圧縮することにより、ストレージ容量を節約
• さらに、I/O量が減ることにより検索パフォーマンスの性能向上にもつながる
• ヒート・マップと自動データ最適化機能(ADO)による高度なデータ配置管理
• 既存のアプリケーションの変更は一切必要なし
Oracle Advanced Compression
33
処理時間の検証
非圧縮環境
圧縮環境
検索の処理時間が
大幅に短縮
CPU時間
I/O時間
非圧縮環境
圧縮環境
CPU時間
I/O時間
更新のオーバーヘッドも
ほとんどない
検索処理における
処理時間の内訳イメージ
OLTP処理における
処理時間の内訳イメージ

View Slide

Oracle Databaseの圧縮機能
34
機能名対象および用途
基本表圧縮データの変更が少ない表やパーティション
高度な行圧縮データの変更が頻繁にある表やパーティション
高度なLOB圧縮と重複削除 DWH環境やOLTP環境における非構造化データ
高度な索引圧縮索引
高度なネットワーク圧縮クライアントとサーバーの間の通信データ
REDO転送の圧縮 Data Guard環境
RMANバックアップ圧縮物理バックアップ
データ・ポンプデータの圧縮論理バックアップ
自動データ最適化(ADO)/ヒートマップデータ配置の最適化
ハイブリッド列圧縮 – ウェアハウス用
データ変更が少ない表やパーティション、より高い圧縮で分析クエリを高
速化したい場合
ハイブリッド列圧縮 – アーカイブ用
データの変更が少なく、データの検索も少ない表やパーティション、最も
高い圧縮率が実現される
Advanced Compression
Option
Oracle
Storage,
Exadata

View Slide

データの変更が頻繁にある表やパーティションに最適
• DML操作を含めた、あらゆるタイプのデータ操作の処理中に、表データを圧縮することが可能
• コールドデータまたは非アクティブデータにも使用可能
• OLTPおよびデータウェアハウスアプリケーションの両方に使用可能
• 非圧縮時のデータ量と比較して2倍から4倍の圧縮率
最良な圧縮率とパフォーマンスを提供
• すべてのDML操作とバルクロード操作で圧縮を維持
• ほとんどのクエリでは、データは圧縮されたままバッファキャッシュに格納
• バッファキャッシュに格納される圧縮データが多いため、総I/O回数が少なくなり、クエリの高速化を期待できる
高度な行圧縮
35

View Slide

非構造化データの圧縮と重複排除によるパフォーマンス向上
高度なLOB圧縮
• 非構造化データを扱う SecureFiles LOBでの圧縮機能を提供
• 圧縮の恩恵を受けないデータは自動的に対象外
• 圧縮済みLOBをさらに圧縮対象から除外
• コンテンツ管理、メールアプリケーション、ビデオなどのデータアーカイブなどに効果的
• 圧縮アドバイザーがSecureFiles LOBに関するアドバイスを提供
• オーバーヘッドのない読み取り操作
• キャッシュされたデータによる読み取りパフォーマンスの向上
重複排除
• SecureFilesデータの重複コピーを排除
• データに消費されるストレージ容量を大幅に削減
• 書き込みおよびコピー操作を大幅に改善
高度なLOB圧縮と重複排除
36

View Slide

索引の圧縮によるストレージ領域の削減と問い合わせパフォーマンスの向上
索引ブロックごとに最適な圧縮アルゴリズムを自動選択し、可能な限り最高の圧縮率を適用
• 異なる索引リーフブロックを異なる方法で圧縮することも、まったく圧縮しないことも可能
高度な索引圧縮(Low)
• 最小のCPUオーバーヘッドで低い圧縮率を提供
• 非圧縮時のデータ量と比較して2倍以上の圧縮率
高度な索引圧縮(HIGH)
• わずかなCPUオーバーヘッドでより高い圧縮率を提供
• 非圧縮時のデータ量と比較して4から5倍
高度な索引圧縮により領域が大幅に節約される一方で、索引を使って実行される問合せのパフォーマンスも向上
高度な索引圧縮
37

View Slide

バックアップ領域の節約とバックアップ所要時間の短縮
バックアップデータのストレージ要件を大幅に削減
• Oracle Recovery Manager (RMAN)で利用可能なバックアップデータ圧縮機能
• 要件にあわせた圧縮レベルを指定可能
• バックアップデータは圧縮されてからストレージまたはテープに書き込まれる
RMANバックアップによる圧縮
38
圧縮レベル Advanced
Compression
パフォーマンスのメリットとデメリット
BASIC 不要
基本機能として利用可能なデフォルトの圧縮アルゴリズム(SE2でも利用可能)
圧縮率はMEDIUMと同等だがCPU使用率が高い
LOW 必要バックアップ・スループットへの影響が最小
MEDIUM 必要
ほとんどの環境で推奨され、圧縮率と速度の優れた組合せ
CPU使用率と圧縮率に優れている
HIGH 必要
ネットワーク速度が制限事項となる、速度の遅いネットワークでのバックアップに最適
高い CPU使用率と最高の圧縮率

View Slide

ヒート・マップによるデータ配置の最適化
ヒート・マップ
• アクセスパターンやアクセス頻度の記録
自動データ最適化(ADO)
• ADOポリシーには、アクション(圧縮や移動)とタイミング(アクションの条件)を定義
• ADOポリシーに従ったアクションの自動実行
データの圧縮と移動を自動化
39
ADOポリシー
ヒート・マップ適用
自動検出自動実行

View Slide

データの参照や更新の状況を追跡し、情報ライフサイクル管理の基準となるデータを提供
データの参照および更新頻度を自動的に追跡
自動データ最適化機能との組み合わせによる高度なデータ配置管理を提供
ヒート・マップ
40
古いデータはまれに参照されるが更新
は一定期間行われていない
直近の過去データは頻繁ではないが
参照され、まれに更新も行われている
頻繁に参照や更新が行われている
時系列でのパーティション

View Slide

ポリシーに従って自動でデータ配置を最適化
表/表領域単位でポリシーを設定し、データの圧縮やレベル変更を自動化
ヒート・マップが取得するデータ操作からの経過時間によりパーティションまたは、表領域のレベルでポリシーの条件を設定
ヒート・マップとの組み合わせによる高度なデータ配置管理を提供
自動データ最適化(ADO)
41
ADOポリシー1:
作成から90日後経ったら圧縮
ADOポリシー2:
180日以上変更がなければより高い
圧縮率で圧縮
ALTER TABLE Sales ILM ADD POLICY
ROW STORE COMPRESS ADVANCED
SEGMENT AFTER 90 days of creation;
ALTER TABLE Sales ILM ADD POLICY
COLUMN STORE COMPRESS FOR ARCHIVE
HIGH
SEGMENT AFTER 180 days of no
modification;
時系列でのパーティション

View Slide

ストレージ容量の削減にとどまらず、I/Oパフォーマンス性能も向上
透過的: アプリケーションの改修は必要なし
高速: トランザクション処理、分析処理、データウェアハウス
• インメモリオプションと組み合わせる事で、より多くのデータがバッファキャッシュとフラッシュキャッシュに収まる
• クエリの高速化、バックアップと復元の高速化
自動化されたデータストレージの最適化
• データのライフサイクル全体でストレージの使用量とコストを削減する手法を自動化
削減: フットプリントをより小さく
• データベースのサーバーおよびストレージコストを削減
• 重複排除圧縮は、データベースのサイズが大きくなるにつれて、継続的な節約を提供
データベースストレージ最適化の利点
42

View Slide

43
Oracle Database In-Memory

View Slide

トランザクション処理と分析処理の性能向上はトレードオフ
行型データベース vs. 列型データベース
44
行型
 トランザクション処理を高速化する行型
– 例: 注文データの挿入と検索
– 少数の行(ロー)と多数の列(カラム)を高速処理
列型
 分析処理を高速化する列型
– 例: 都道府県毎の売上合計のレポート
– 少数の列(カラム)と多数の行(ロー)を高速処理
SALES
SALES
従来は、どちらかを性能向上させると、どちらかにオーバーヘッドが発生するため、
トランザクション処理と分析処理を単一のデータベースで共存することは難しかった

View Slide

同一データをメモリー上に2種類のフォーマットで保持し、全ての処理を高速化
データベースのメモリー空間内で、
同一データを行型、列型両方のフォーマットで保持
• 行型: バッファキャッシュ
• 列型: インメモリー列ストア(IM列ストア)
両方のフォーマットを使い分けることで、
全てのデータベース処理の高速化を実現
• 分析、集計処理は列型フォーマットに対して実行
• トランザクション処理は行型フォーマットに対して実行
トランザクションの一貫性保証
Database In-Memory (DBIM)機能概要
45
バッファ
キャッシュ
IM列
ストア
SALES SALES
行型
フォーマット
列型
フォーマット
SALES
1つのSALES表に対して
2つのフォーマット
ストレージ上には
行型のみ

View Slide

DBIMの特徴
46
リアルタイム分析実装が簡単
アプリケーションの
変更なし
混合ワークロード
の高速化
Analytics
Transactions
OLTPシステムで
分析を実行する
リアルタイムのビジネス決定
を可能にする
100X
100X
100%の互換性
実証済みの
スケールアウト、
可用性、セキュリティ

View Slide

導入の容易性
DBIMの特徴
47
1. IM列ストアのサイズを設定
inmemory_size = XXX GB
2. IM列ストア上に格納する表、
パーティションを選択
alter table | partition … inmemory;
3. 自動的にポピュレート
設定の基本3ステップ
インメモリー導入事前調査
（IMアドバイザ、圧縮アドバイザ）
IM列ストア上に列型データのポピュレートが完了するまで、行型データを利用し処理が可能です
これによりIM列ストアへのポピュレートを待つことなく素早く処理を開始する事が可能です
システム・グローバル領域 (SGA)
ストレージ上には
行型フォーマットのみ
保存
行型
フォーマット
行型→列型
変換
SALES SALES
行型
フォーマット
列型
フォーマット
バックグランド・プロセス
（ポピュレート）
SALES

View Slide

デュアルフォーマットを透過的に選択
データベースのオプティマイザがSQLにあわせて最適なフォーマットを選択
DBIMの特徴
48
表毎に処理するデータフォーマットが決まるのではなく、SQL毎に処理するデータフォーマットが透過的に選択されるため、
同一の表をトランザクション処理にも、分析処理にも利用することが可能
行型
列型
select * from SALES
where order_id = ‘ABC123’;
select region, sum(amount) from SALES
group by region;
Oracle Database
オプティマイザ
SALES表
デュアル
フォーマット
Bツリー索引を
使用した処理
インメモリー検索を
使用した処理
少数の行の全列のデータ取得
一部の列を使った大量行の集計処理

View Slide

インメモリーのデータ更新
IM列ストア利用時においても、更新処理は基本的に従来と同じ
仕組みで処理される
① 行ストア (バッファ・キャッシュ)における更新
② IM列ストアの該当IMCUエントリを失効させる
③ 無効なデータの再ポピュレーション（自動/手動）
無効なデータの再ポピュレーションは、表単位ではなくIMCU単位で
非同期に実行される
• In-Memory Compression Unit (IMCU)は、
インメモリー上の圧縮された記憶域単位
IM列ストアを利用しても、DML実行時に追加のI/Oは発生しない
ためオーバヘッドはほぼない
DBIMの特徴
49
システム・グローバル領域 (SGA)
バッファ
キャッシュ
IM列
ストア
SALES SALES
行型
フォーマット
列型
フォーマット
更新
失効
①
②
③

View Slide

ご参考
DBIM単一ユーザーの性能テスト(平均Elapsed Time)
50
検証シナリオ
• スター・スキーマ
• 100個のランダムに生成された分析スタイル問合せ
• 複数テーブル結合、集計、その他
• 単一DBユーザーが100個の問合せを順番に実行
• パラレル度 = 4
備考）
スター・スキーマに対する問合せ性能向上には、基本的にはビットマップ索引を作成します。
本テストシナリオでは、他クエリーも流れていることを想定し、パラレル度は 4 に設定してあります。
つまり、最大性能を示す検証結果ではありません。
Elapse Time (秒)
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
10.0
ビットマップ索引 Exadata In-Memory on Exadata
問合せあたりの実行時間(秒)

View Slide

代表的なユースケース
51
データ
マート
OLTP
DWH
分析用
DB
基幹系
OLTP
① 既存DWHを統合、インメモリ化し高速化
② データマートをインメモリ化し、さらに高速化
③ OLTPシステムを直接インメモリ化し、分析用途に利用
• 分析、レポーティングの高速化
• ダッシュボード画面の高速化（経営／業務系）
• リアルタイム分析の促進
④ 基幹系OLTPシステムとの分離構成
既存システムを極力変更しない分析処理を負荷分散
レプリケーション

View Slide

オプションを購入することなく、最大16GBのIM列ストアを利用可能に
Enterprise Editionの19c RU (19.8)から利用可能
INMEMORY_FORCEパラメータで有効化
• BASE_LEVELに設定
INMEMORY_SIZEは1インスタンス辺り最大16GB
• RACでは、各インスタンスで最大16GBに使用可能
• マルチテナントはCDBの各インスタンスあたり16GBに制限
特記事項
• 圧縮アルゴリズムの指定不可、自動インメモリー(AIM)は無効など一部制約あり
• 認定クラウド環境では、Oracle Cloud Infrastructureで利用可能
Database In-Memory Base Level機能
52
System Global Area (SGA)
Buffer
Cache
Large
Pool
Log
Buffer
Shared
Pool
In-Memory
Area
(Max 16GB)
Other

View Slide

53
Oracle Diagnostics Packおよび
Oracle Tuning Pack

View Slide

性能の定常的な監視と自動チューニング機能
データベースの性能問題の発見・分析・解決をシームレスに実現
• データベースの稼働に必要な情報を自動的に収集し、分析
• 性能問題が発生した場合に、メール等で管理者に通知
• チューニング・アドバイザ機能を使うことで、高度な知識がなくても、簡単にチューニングを実施することが可能
Oracle Diagnostics PackおよびOracle Tuning Pack
54
特定の時間の
処理を確認
この時間帯に行われていた
処理の内訳を確認
実行計画と各種統計を確認
時間と待機の概要 I/Oの概要
SQLの概要

View Slide

データベースのパフォーマンス情報を簡単に収集して分析
自動ワークロード・リポジトリ(AWR)
• パフォーマンス統計を自動収集
• パフォーマンス履歴の表示および分析
• レポートやビューを簡単に生成
アクティブ・セッション履歴(ASH)
• アクティブ・セッションの情報を自動収集
• レポートやビューを簡単に生成
自動パフォーマンス診断(ADDM)
• AWRデータを自動で素早く分析
• 具体性、一貫性、実行可能性を備えたパフォーマンス提案
Oracle Diagnostics Pack
55

View Slide

過去に遡ってデータベースのパフォーマンスを分析
• データベース統計を自動的に収集し、スナップショットとして保存
• スナップショットからAWRレポートを生成
自動ワークロード・リポジトリ(AWR)
56
1時間毎に収集*
SGA
AWRスナップショット
8日間保存*
データベース統計
時間
スナップショットID
データベース統計
id=100 id=101 id=102
100-101間のAWRレポート
101-102間のAWRレポート
AWRレポートから得られる情報例
• スナップショット詳細
• ロード・プロファイル
• サーバー・プロセスのイベントトップ10
• インスタンス効率(%)
• SQL統計
• 共有プール統計
• IO統計
• セグメント統計
• SQL文
*変更可能

View Slide

短期間のパフォーマンス問題の分析
• アクティブ・セッションの情報を毎秒メモリー(SGA)に格納
• SGA上から、サンプリングして定期的に表へ書き出す
• 期間を指定し、ASHレポートを生成可能
アクティブ・セッション履歴(ASH)
57
CPU時間待機時間
時間
SessionがACTIVE
セッション1
セッション2 1秒ごとにすべてのアクティブ・セッションの
状態をサンプリングして積み上げ
1/10にサンプリングしストレージへ格納

View Slide

AWRのデータを定期的に分析し、データベースのパフォーマンスを監視および診断
• AWRに収集されたデータを定期的に分析し、データベースのパフォーマンスを監視 / 診断
• 問題を発見すると、解決方法とともに画面に表示
自動パフォーマンス診断(ADDM)
58
チューニングアドバイザの
実施を指示

View Slide

複雑で時間のかかるチューニング・タスクを自動化
データベースのアプリケーション・チューニング・プロセスを自動化
データベースの管理コストが大幅に抑制され、パフォーマンスと信頼性が向上
SQLチューニング・アドバイザ
• 問題のあるSQL文を特定し、文のパフォーマンスの改善方法を提示
• 自動化メンテナンス・タスクとして実行することも可能(自動SQLチューニング・アドバイザ)
リアルタイムSQL監視
• 実行中のSQLに対して実行計画や処理の進捗状況を確認可能
• パフォーマンス・メトリックなどを含むSQL監視レポートを生成および表示
Oracle Tuning Pack
59

View Slide

SQLを調査し、SQLチューニングの推奨事項を取得
特定のSQLに包括的な分析を実施し特定されたさまざまな問題に対する推奨事項を提供
リアルタイムおよび過去のパフォーマンスデータを利用して、代替実行計画を特定
自動メンテナンス・タスクとしてデータベース・メンテナンス・ウィンドウで実行も可能
(自動SQLチューニング・アドバイザ)
60
SQLプロファイル(*)
統計情報分析
アクセス・パス分析
SQL文分析
実行計画分析
パラレル・クエリー分析
自動チューニング・オプティマイザ
DBA
SQLチューニングの
推奨事項例
欠落または失効した統計の収集
SQLプロファイルの作成
不足しているアクセスパスの追加
SQL文の変更
代替実行計画の利用
(*) SQL文に関する補足的な統計情報
例: SQL文で実際に戻された行数

View Slide

性能状況をグラフィカルに表示し、実行中のSQL処理を特定、チューニングまで自動化
61
グラフからリアルタイムで負荷状況を確認
(過去にさかのぼって確認することも可能)
負荷の高いSQLを選択し
アドバイザ実行
実装したい項目を選択

View Slide

時間のかかるSQLを監視し、進捗状況や内部的な実行ステップを確認、チューニングに活用
SQLが自動的に表示(*)され、処理の進捗状況や処理時間の内訳を確認
パーティショニングやパラレル処理がどのように使われているかを簡単に確認
チューニングに必要な情報をレポートとして保存し、ファイルとして共有することが可能
リアルタイムSQL監視
62
(*)
下記の条件を満たす SQLを自動取得
・5秒以上のCPU時間またはI/O時間を
消費しているSQL
・パラレル実行されているSQL
Status: Executing (実行中)
終了したものはDONE
SQL文、実行開始時間、パラレ
ル度、待機イベント、I/O統計が
確認可能
実行計画の各ステップや
待機時間などが確認可能

View Slide

63
Oracle Recovery Manager (RMAN)

View Slide

用途が異なる
Oracle Databaseの物理バックアップと論理バックアップ
物理バックアップ論理バックアップ
ツール Recovery Manager (RMAN) Data Pump Export
機能データファイル(データ・ブロック)をコピーするデータベースの一部のデータもしくは全体を
エクスポートする
いつのデータを
復旧できるか
データ・ブロックに破損が生じてもリストア
(データ・ブロックの変更の起点)とリカバリ
(データ・ブロックにREDOログの変更の差分
を適用)で障害直前の状態に復旧できる
エクスポートしたデータをインポートしても
REDOログの適用はできない
エクスポートした時点のデータしか復旧できない
用途障害に備える仕組みデータを移し替える仕組み
64

View Slide

Oracleインスタンス管理下で行われるデータベースのバックアップ、リストアおよびリカバリ
データベース無停止でのオンライン・バックアップ
• アプリケーションはバックアップの実行を関知しない
データ・ブロック破損の検査
• 破損ブロックのバックアップの防止
• バックアップ・ファイルの検査
どのファイルをどこにバックアップしたかを自動管理
• どのバックアップ・ファイルからリストアするかを自動
判別
バックアップおよびリストア時間の短縮
• 並列化
• 高速増分バックアップ
• 増分更新バックアップ
• データ・ブロック単位のリストア
Oracle Recovery Manager (RMAN)
65
oracle
rman
（コピー元）
バックアップ
（コピー先）
RMANクライアント
Oracleサーバー・
プロセス

View Slide

推奨はRMAN
• Oracle付属のバックアップ・ツール
• Oracleサーバー・プロセスがデータベースのファイルにア
クセスする仕組みを使ってファイルをコピー
• Oracleインスタンス管理下で行われる操作
• RMAN以外の方法でコピーするすべての手法
• Oracleインスタンスがコピーを関知しない
• OSのファイル・コピー・コマンド
• ストレージ機能のスナップショットやスプリット・ミラー
Oracle Databaseの2種類の物理バックアップ手法
66
oracle
rman
（コピー元）
バックアップ
（コピー先）
スナップショット
スプリット・ミラー
Recovery Manager (RMAN) ユーザー管理バックアップ
プロセス
コピー元ボリュームバックアップ・ボリューム

View Slide

RMANはSQL実行のストレージI/Oをブロックしない
• バックアップのファイル・アクセスの仕組みがSQL実行の
ファイル・アクセスと同じなのでSQL実行のストレージ
I/Oをブロックしない
• ストレージ機能のスナップショットやスプリット実行時に
短時間でもI/Oをフリーズさせるものがある
オンライン・バックアップ
67
oracle
rman
（コピー元）
バックアップ
（コピー先）
プロセス

View Slide

確実にリカバリするための"Recovery" Manager
• コピー時に破損検査が行われる
• バックアップしたファイルの破損検査も可能
• 破損領域がそのままコピーされる
• 誤った単位でボリュームをコピーしているとリカバリ時に
なってはじめてリカバリ不能に気付く
データ・ブロックの破損検査
68
oracle
rman
（コピー元）
バックアップ
（コピー先）
プロセス

View Slide

確実にリカバリするための"Recovery" Manager
• どのファイルをいつどこにコピーしたかをOracle自身が管
理する(制御ファイルおよびリカバリ・カタログ)
• それに基づきリストアおよびリカバリ操作が自動化でき
る
• どのファイルをリストアすべきかを人が判断する
• 誤った単位でボリュームをコピーしているとリカバリ不能
になる
バックアップの自動管理
69
oracle
rman
（コピー元）
バックアップ
（コピー先）コピー元ボリュームバックアップ・ボリューム
管理情報
プロセス

View Slide

RMANでのバックアップ、リストアおよびリカバリ時間の短縮
70
並列化
複数あるコピー対象を並列化
高速増分バックアップ
前回のバックアップ時点から更新された
データ・ブロックのみにアクセス
増分更新バックアップ
フル・バックアップにあらかじめ
増分バックアップを適用
ブロック・メディア・リカバリ
1ブロック単位のリストアおよびリカバリ
BACKUP
RESTORE
データファイルバックアップ
フル・バックアップ
増分バックアップ
データファイルバックアップ
RECOVER

View Slide

Oracle Databaseの2種類の物理バックアップ手法
71
破損検査されるされない
リストアおよび
リカバリ操作
自動化できる破損個所の特定からどのファイルをリストアするか
まですべて管理者の判断
最小リストア粒度データ・ブロックファイルまたはボリューム
バックアップおよび
リストア時間の短縮
• 高速増分バックアップ
• 増分更新バックアップ
• ブロック・メディア・リカバリ
• 並列化
ストレージ機能との組み合わせ
ストレージ機能(スナップショットなど)はバックアッ
プ構成を誤ると容易にリカバリ不能になるので
注意

View Slide

Database Lifecycle Management Pack
72

View Slide

データベース、システムおよびアプリケーションの管理者が、Oracle Databaseのライフサイクル管理に
必要なプロセスを自動化するのに役立つ、包括的なソリューション
Database Lifecycle Management Pack概要
期待される効果
• 構成の「ずれ」によるトラブルの防止
• リリース時のヘルスチェックや障害時の
情報収集の高速化
• データベースとデータのセキュリティ強化
• プロアクティブなセキュリティ強化と
障害予防
• 開発・テストサイクルの高速化
ライフサイクル管理ソリューション
• 検出
• DBのプロビジョニング
• パッチ適用
• DBオブジェクトの変更管理
• DBやOSの構成管理
• コンプライアンス管理
• Enterprise Data Governance
• 変更アクティビティ・プランナ
73

View Slide

検出
• ホストとそのソフトウェアデプロイメント
の識別、管理可能なターゲットとして
のホストの追加、およびホストの状態
の監視と管理
DBのプロビジョニング
• DBソフトウェアのインストール、DBの
作成やクローニングを自動化すること
で、構成の標準化、開発およびテス
トの迅速化を実現
パッチ適用
• セキュリティパッチなど定期パッチの適
用作業を自動化することにより、低コ
ストでセキュリティ対策の最新化、障
害の未然予防を実現
DBオブジェクトの変更管理
• 複数DBのオブジェクト定義情報を一
元管理、履歴管理、比較、同期す
ることで、多数あるオブジェクトの開発
およびリリースにおけるリスクと工数を
削減
DBやOSの構成管理
• 初期化パラメーターやパッチレベル、
カーネルパラメーター等を一元的に履
歴管理し、テスト時やリリース時に発
生しがちな環境間差異等のリスクを
低減
コンプライアンス管理
• データベースの構成を定期的に自動
チェックし、組織の定めた標準や業界
標準(PCIDSS等)から逸脱していな
いか、脆弱性にさらされていないかを
評価
Enterprise Data Governance
• 複数のデータベースから機密データの
格納された表や列を検出、マスキン
グ等のセキュリティ対策漏れを防止
変更アクティビティ・プランナ
• 四半期ごとのセキュリティ・パッチの
ロールアウト、ビジネス要求に合せた
新しいサーバーの構築、データ・セン
ターの移行または統合、および環境
全体へのコンプライアンス標準の導入
など様々なオペレーションの計画、管
理および監視
Database Lifecycle Management Pack主な機能
74

View Slide

DBソフトウェアのインストール、DBの作成やクローニングを自動化することで、構成の標準化、
開発およびテストの迅速化を実現
主なユースケース
• Oracle Databaseのプロビジョニング
• Oracle Real Application Clustersのプロビジョニング
• Oracle Real Application Clustersの拡張および縮小
• Oracle Databaseの作成
• プラガブル・データベースのプロビジョニング
• Oracle Database Clientのプロビジョニング
データベースのプロビジョニング
75
基本となる環境検証環境 ①
検証環境 ②
検証環境 ③
既存構成をプロファイル化し、
迅速に構成を配布

View Slide

セキュリティパッチなど定期パッチの適用作業を自動化することにより、低コストでセキュリティ対策の最新化、障害の未然
予防を実現
• パッチ推奨
• 構成情報をもとに、未適用の推奨パッチを提示
• パッチ計画
• 複数のパッチを「パッチ計画」に追加、
一斉適用可能
• パッチ情報、および構成情報をもとに
競合の事前チェック
• パッチ適用
• 手動操作によるオペレーション・ミスを防止
• 検証済みのパッチ計画をテンプレート化することで適用を標準化
パッチ適用
76
未適用の推奨パッチ

View Slide

複数DBのオブジェクト定義情報を一元管理、履歴管理、比較、同期することで、多数あるオブジェクトの開発およびリ
リースにおけるリスクと工数を削減
データベース・オブジェクトの変更管理
77
開発DB
本番DB
Ver 0.1
Ver 0.2
Ver 1.0
異なるバージョン間で
オブジェクト定義の差分比較
リリースに必要なDDLを作成、実行し、オブ
ジェクト定義を安全かつ確実に同期
EMPLOYEES表のEMAIL列の長
さが25から30に増えている

View Slide

初期化パラメーターやパッチレベル、カーネルパラメーター等を一元的に履歴管理し、テスト時やリリース時に発生しがちな
環境間差異等のリスクを低減
データベースやOSの構成管理
78
本番環境と検証環境で
差分が無いかチェック

View Slide

データベースの構成を定期的に自動チェックし、組織の定めた標準や業界標準(PCIDSS等)から
逸脱していないか、脆弱性にさらされていないかを評価
• オラクル提供の豊富なコンテンツによる自動評価
• セキュリティ上の推奨やベストプラクティス
• ルール等はセルフアップデート機能を通じて更新可能
• 評価結果は「スコア」として自動算出
• スコアの過去履歴も保存
• ルール違反の詳細情報
• 違反の詳細
• 推奨される解決方法
• My Oracle Supportのナレッジとのリンク
コンプライアンス管理
79

View Slide

複数のデータベースから機密データの格納された表や列を検出、マスキング等のセキュリティ対策漏れを防止
• メタデータ検出: スキーマ、表および列名のパターンでのみ検索
• データ検出: 実際のデータをドリル・ダウンして、ユーザー指定の機密タイプおよび
オブジェクト・レベルの保護の詳細に一致するものを検索
Enterprise Data Governance
80

View Slide

81
Oracle Multitenant

View Slide

データベースの統合とシンプルな運用のための新しいアーキテクチャ
Oracle Multitenantの背景
82
サーバー仮想化インスタンス分割スキーマ分割 PDB分割
構成
DB
App App App
スキーマスキーマスキーマ
OS
CDB
PDB PDB PDB
App App App
OS
OS
DB
DB
DB
App App App
OS
DB
DB
DB
App App App
OS OS
Hypervisor
Multitenant

View Slide

データベースの統合とシンプルな運用のための新しいアーキテクチャ
アプリケーションごとにPDB (プラガブル・データベース)を提供
• アプリケーションの変更は不要
• 高速なプロビジョニング(クローン)
• ポータビリティ/可搬性
CDB (コンテナ・データベース)で共通オペレーションの実施
• 一元管理(アップグレード、バックアップ、HA構成)
• 必要に応じて個別の管理も可能
メモリーとバックグラウンド・プロセスの共有
• より多くのアプリケーションを稼働できる
Oracle Multitenantの特徴
83
PDB
Root
CDB
OS

View Slide

Multitenantのメリット
84
• 設備投資の低減
• サーバー台数の削減
• サーバーのメモリ、コア数の削減、
それに伴うライセンス数の削減
• 運用コストの低減
• 複数データベースをまとめて管理
• 運用手順の標準化
• 俊敏性の向上
• 迅速なプロビジョニング
• セルフサービスによるプロビジョニング
• 容易な移行
• アプリケーションの変更なしの移行
メリットサーバー仮想化インスタンス分割スキーマ分割 Multitenant
設備投資の低減 × △ 〇〇
運用コストの低減 × △ 〇〇
俊敏性の向上〇〇 × 〇
容易な移行〇〇 × 〇

View Slide

Multitenantの高集約により、設備投資の低減
データベースの高密度集約(ITリソース有効活用)
85
統合できるDBの数メモリ容量*
250
50
200MB
1600MB
87.5%カット
5倍
同環境なら、5倍の数のデータベースを統合可能
同じ性能を出すために必要なメモリサイズを
87.5%カット(1/8に縮小)
ライセンス/ハードウェアコストの節約
5倍の利用効率による
高い費用対効果
同じ環境だったら同じ性能を出すには
*DBを動かすために必要なメモリサイズ
シングルインスタンス
Multitenant構成

View Slide

ファイル構造
Multitenantアーキテクチャ
86
non-CDB構成
オンライン
REDOログ
ファイル
制御
ファイル
データ
ファイル
DB
CDB構成
オンライン
REDOログ
ファイル
制御
ファイル
データ
ファイル
データ
ファイル
データ
ファイル
CDB Root PDB PDB
CDB Root
PDB
• CDB Rootが、REDOログと制御ファイルを持つ
• PDBごとにデータファイルが独立している

View Slide

簡単かつ高速なデータベースの移動と複製
Multitenant機能と活用
87
同一CDB内でのPDBの複製
• 全データ
• 指定表領域のみ
• メタデータ（表定義）のみ
別CDBへのPDBの移動
• Unplug & Plug
別CDBへのPDBの複製

View Slide

簡単かつ効率的なデータベースのアップグレード
A) 一括でアップグレード B) Unplug & Plugの活用
88
Oracle 12.1.0.2
Oracle 19.8.0.0
アップグレード
Oracle 12.1.0.2
Oracle 19.8.0.0
Unplug
& Plug
Oracle 19.8.0.0

View Slide

アプリケーション・テナントの
中央集中管理
• アプリケーション・コンテナ
• PDB間でアプリケーションの
オブジェクト共有
• プロキシPDB
• 異なるCDB間での
アプリケーション・ルートの同期
• コンテナ・マップ
• PDBを使った
ロジカル・パーティション
大規模環境にも対応可能な
統合と分離
• 1 CDBあたり最大4,096PDB
• PDB毎にキャラクタセット変更可
• PDB毎にフラッシュバック可
• メモリー、I/O、CPUの
リソース制御
• ロックダウン・プロファイル
• より細かい権限の制御
プロビジョニングの容易さとテナントの
移動しやすさ
• 再配置
• PDBの再配置をしても
アプリケーションは継続利用可能
• 最小限のダウンタイムでサーバー側
のロードバランスを実施
• リフレッシュ可能なクローン
• 参照用途で手動もしくは定期的に
同期をとるPDBを設定可能
• ホット・クローン
• オンラインでPDBの複製が可能
89

View Slide

PDBスナップショット・カルーセル
• PDBスナップショットを複数世代取得し、テストなどで
利用することが可能
• ホット・クローンの仕組みを利用して取得
• 最大8つまでのスナップショットを保存
• 9つ目のPDBスナップショットが取得されると古いものを削除
• カルーセル内のPDBスナップショットからread/write可能な
PDBをオープン
PDB単位でのReal Application Testing
• 特定のPDBに接続してワークロードのキャプチャ、
リプレイが可能
• PDB管理者が、管理するPDBに対して実施
• 接続しているPDBのワークロードのキャプチャを実施。同様
に、接続しているPDBでワークロードのリプレイを実施。
90
16th
15th
14th
13th
12th
11th
10th
9th
T0
T1 T2
T3
T4
T5
T6
T7
CREATE PLUGGABLE DATABASE
.. USING SNAPSHOT …
本番
ALTER PLUGGABLE DATABASE
SNAPSHOT …
開発
AP
DB
SQL/ワークロードを取得
取得したSQL/ワークロード
本番環境テスト環境
Client Replay
Client
DB

View Slide

1. 既存システムの統合基盤 2. 開発・検証環境のアジリティ向上 3. SaaS/ASPサービスの基盤として
の活用
Multitenantの代表的なユースケース
91
既存環境を統合しMultitenant化
統合(本番)
開発
マスター (開発2)
(開発1)
開発本番
オンプレミス
オンプレミス or Oracle Cloud
異なる環境への複製独立性、セキュリティ、
運用コスト削減と運用効率化
A社 B社 C社
SaaS/ASP
サービス展開

View Slide

Oracle Real Application Clusters
92

View Slide

共有ストレージ・共有キャッシュ型で全ノードがアクティブ
スケーラビリティ
• 全ノードがアクティブで対等に更新可能
• ノード数(CPU数)増加による性能向上
• トランザクション系: 同時ユーザー数の向上
• 分析系: 並列度向上
可用性
• Oracleインスタンスに障害が発生しても正常ノードに
よって自動的にリカバリされる
• 最低1つのOracleインスタンスが稼働していれば
全データにアクセス可能
• ノードごとのローリング・メンテナンス可能
透過性
• Oracleクライアントから見た挙動が
シングル・インスタンスと同じ
Oracle Real Application Clusters (RAC)
93
共有ストレージ
データ・ベース・サーバー

View Slide

トランザクション系も分析系も同じアーキテクチャで対応
トランザクション系
• 多数のセッションからの同時並行リクエスト
• より多くの同時リクエストを処理
集計/分析系
• 1つのSQL処理を並列化
• より高い並列度で1つのSQLを処理
スケーラビリティ
94
QC
PX PX PX PX PX PX PX PX

View Slide

RACノード数(CPU数)の増加とトランザクション処理量の例
95
トランザクション系処理のRACノード数と相対スループット検証例
https://jpn.nec.com/soft/oracle/files/gc_1SSDB-MAT-03-09002_NEC_GRIDCenter_16nodeRAC_external_ver2.pdf

View Slide

データベース・サーバーに障害が発生すると正常ノードが自動リカバリ
Oracleインスタンス障害
• 一瞬でOracle Grid Infrastructureに検出される
• Oracleインスタンス障害が検出されると正常ノードの
Oracleインスタンスによって自動的にリカバリされる
• 最低1つのOracleインスタンスが正常動作していれば
全データにアクセス可能（アプリケーションが動作す
る）
OSより下の階層の障害
• OS以下の障害は正常ノードのOracle Grid
Infrastructureがタイムアウトで検出
可用性: データベース・サーバー障害
96
GI GI GI GI
GI: Oracle Grid Infrastructure

View Slide

一部のノードを停止させてもデータベースは稼働を継続可能
1. 停止
2. パッチ適用
3. 起動
ローリング・パッチ適用
• RACは最低1つのOracleインスタンスが正常動作して
いれば全データにアクセス可能(アプリケーションが動作
する)
• Oracleインスタンス停止 → パッチ適用 → 起動をノード
ごとに繰り返すことでデータベース全体としては稼働さ
せたままパッチ適用が可能
可用性: ローリング・メンテナンス
97
GI GI GI
GI: Oracle Grid Infrastructure

View Slide

Oracleクライアントから見た挙動がシングル・インスタンスと同じ
Oracleインスタンスからのデータの見え方が同じ
• ストレージを共有しており1つのOracleインスタンスから
全データにアクセス可能
• 複数ノード間でのメモリーの一貫性を全自動で維持
(Cache Fusion)
スキーマ構造が同じ
• 表/索引を格納するデータ・ファイルが同じ
• 表/索引のパーティショニングは不要
トランザクション分離レベルの挙動が同じ
• 複数のセッションがノード内/ノード間で同じデータにア
クセスしたときの挙動が同じ
透過性
98
シングル・インスタンスで開発したアプリケーションがそのまま動作する

View Slide

Oracle接続ドライバは標準機能でRACのことが考慮されている
ロード・バランシング
• 接続数や負荷に応じて適切に振り分け
フェイルオーバー
• 接続リクエストを自動再試行
• 接続時フェイルオーバー
• 更新トランザクションを自動再実行可能
• アプリケーション・コンティニュイティ
RACへの接続
99

View Slide

Oracle Real Application Clusters
ノード数(CPU数)増加による性能向上
• トランザクション系処理はより多くの同時リクエストに対応
• 集計/分析系処理はより高い並列度で実行時間短縮
可用性
• Oracleインスタンス障害/ノード障害からの自動リカバリ
• 最低1つのOracleインスタンスが正常動作していれば全データにアクセス可能
• ノードごとのローリング・メンテナンス可能
アプリケーションからはシングル・インスタンスと同じに見える
• スキーマ構造とトランザクション分離レベルが同じ
• シングル・インスタンスで開発したアプリケーションがそのまま動作する
まとめ
100

View Slide

Oracle Automatic Storage Management
101

View Slide

高性能、高可用性、管理容易性を提供するデータベースとして理想的なストレージ管理機能
Oracle Databaseのストレージ仮想化機能
• Oracle Databaseに対するボリューム・マネージャ兼ファイルシステム
• エディションに関係なく、シングルまたはクラスタ環境ともに利用可能
• ASMによるファイルシステム機能も提供
I/O性能を最大限引き出しつつ、ストレージ管理工数を
大幅削減
• すべてのストレージ・デバイスにまたがったディスクの仮想化とストライピ
ングを自動で行い、アクセスを均一化
• ストレージ・デバイスの増減にあわせた自動リバランス
ストレージ筐体をまたがる高可用性と拡張性
• ミラーリング(二重化/三重化)可能
• 冗長構成でファイル破損を検出すると自動修復
• ストレージ・デバイス異常を検出すると自動切り離し
• ストレージ・デバイスの増減にあわせた自動リバランス
Oracle Automatic Storage Management (ASM)
1 2 3 4
1 2 3 4
4 3 1 2
追加
自動リバランス
削除
高性能の維持
高可用性の担保
管理容易性ミラーリング
ストライピング
102

View Slide

アーキテクチャ
ASMインスタンス
• ASMディスク・グループ内の構成情報(メタデータ)の管理を行うための
インスタンス
ASMディスク
• ASM用に定義されたLUNやストレージ・デバイス
ASMディスク・グループ
• ディスクの論理的な単位
• ディスク・グループごとに冗長化レベルを設定可能
障害グループ
• 同一コントローラ配下のディスクをまとめた単位
• 異なる障害グループ間でミラーリングし、データ損失を回避
ASMファイル
• ASMディスク・グループ内に格納されるファイル
• データベース・ファイルなども含まれる
AU(アロケーション・ユニット)
• 分割したASMファイルをASMディスクに割り当て配置する単位
Oracle Automatic Storage Management (ASM)
103
データベース
インスタンス
ASM
インスタンス
ASMディスク
ASM
ディスク・グループ
ASMファイル AU(アロケーション・ユニット)
障害グループ

View Slide

「ディスク追加をする際の作業が大変」
例) ディスクや表領域が非常に細かく分割されている
• 空き領域がディスクや表領域毎に独立しているため、無駄な空き領域が増大
• 監視対象（ディスクや表領域）が多く、頻繁に領域不足に陥り、運用工数が増大
• データ・ファイル数が多く、SQLの性能劣化やミス・オペレーションを誘発
• 管理レイヤー数が多い為、運用オペレーションの複雑化
• 変更する際のデータベース管理者とストレージ管理者の間での調整作業の難しさ
例) ディスク追加時に、既存データをリバランスしていない
• 空き領域が新規ボリュームにのみ存在する為、新たにINSERTされるレコードがそのボリュームに集中することで、
ボトルネックが発生し易い
• 既存レコードは既存ボリューム内に格納されている為、性能改善効果は無し
データベースのストレージ～よくある課題その1: 性能と運用の複雑化
104
ディスク追加のみだと
新規レコードが一点集中
対策として、一度データを
退避し、全ディスクへ
再投入
データロード後、
データやアクセスが均等化

View Slide

Stripe And Mirror Everything (S. A. M. E)
「全てのストレージ・デバイスの均等利用を目的に、データをストライプして全てのストレージ・デバイス上に分散配置し、
ミラーリングも行う」という設計手法
• I/O性能の確保：全てのストレージ・デバイスのI/O帯域をフル活用
• 可用性を確保：ミラーリングの採用
• 設計の簡素化：物理的なストレージ構成を隠蔽し、特別な設計は不要
ASMの基本思想
105
1 2 3 4
3 6 1 7
5 6 7 8
4 2 8 5
異なるデバイスに
ミラーリング
すべてのデバイスにストライピング

View Slide

高性能、高可用性、管理容易性を提供するデータベースとして理想的なストレージ管理機能
ストライピング
• 全ディスクでファイルを自動均等分散
の形でストライピングし、高性能を維
持
ミラーリング
• ミラーリング(2重化/3重化)により、スト
レージ・デバイス障害に対する可用性
の担保
• ストレージ筺体を区別し、筐体間でミ
ラーを保持
動的リバランシング
• ストレージ・デバイスの追加/削除時に
既存データを動的に自動再配置し、
容易な管理が可能
• 容量やIOPS不足時に、ストレージ・デ
バイスを追加するだけでストレージ拡
張を実現
• データベース無停止でのリバランスが
可能
Oracle Automatic Storage Management
106
1 2 3 4 1 2 3 4
4 3 1 2
筺体#1
Primary
Secondary
筺体#2
追加

View Slide

ストレージ管理を圧倒的に効率化
ASMによるデータベースの物理設計の簡易化
キャパシティ
プランニング
データ位置
の検討
論理ボリュームの
作成
ファイルシステムの
作成
Oracle
インストール DB作成
キャパシティ
プランニング
ディスクグループの
作成
Oracle
インストール DB作成
ホットポットを見つ
ける
データファイル移動
ディスクグループ内での自動均等
分散により管理作業なし
H/Wへの
ディスク追加
論理ボリュームの
作成
ファイルシステムの
作成
移動データ
の検討
新規ディスクに
ファイルを移動 DBファイルの改名
H/Wへの
ディスク追加
ディスクグループへ
の追加
DB
作
成
チ
ュ
ー
ニ
ン
グ
デ
ィ
ス
ク
追
加
工数と所要時間を
大幅に削減
ASM
ASM
ASM
一般的なストレージ
107

View Slide

「耐障害性のためにミラーリングなど対処していたがデータにアクセスできない」
ストレージ・データの障害の例
• ソフトウェアから永続化デバイスまでのどこかの階層がデータを破損させた
• それを「検出」するのはデータを読み取って中身を解釈するOracleのプロセス
• 破損させた階層は「自分が壊した」というログを残さないため多くの場合根本原因は
迷宮入りする
ストレージ・ハードウェアの障害の例
• 破損データの書き込みリクエストは「そのまま」格納される
• 主に永続化層であるHDDおよびフラッシュ・メモリのハードウェア故障への対処
• エンタープライズ向けストレージはコントローラーやインターフェースのハードウェアも
ひととおり冗長構成になっている
• ハードウェアの故障を検出したら切り替える、または切り離すという対処
データベースのストレージ～よくある課題その2: 可用性
108
Oracle Database
OS
multipath driver
device driver
Host Bus Adapter
storage controller
network
CPU/memory

View Slide

Oracle Clientに透過的かつ自動的な切り離し、再配置、ブロック修復
ストレージ・デバイス障害時に自動切り離し
• OSシステム・コールがエラーになるストレージ・デバイスをオフライン化、
復旧できない場合は切り離す
• 冗長化されていれば処理は継続
• ストレージ・パス障害の切り替えはOSのI/Oタイムアウトに依存
(60秒程度)
• Exadataならば数秒でノード障害を切り離せる
• ストレージ・デバイスの増減にあわせてリバランスして冗長性を回復
ファイル破損時の自動修復
• 読み取ったファイルの破損を「検出」するのはOracleのプロセスで
あるが...
• ストレージ・デバイス以外の階層の異常でもストレージのデータを
破損させる場合がある
• ASMで冗長化している場合ファイル破損を検出すると自動的に
ミラーから読み取り処理継続し、破損個所を自動修復
ASMのストレージ障害への対処
109
データベース
インスタンス
ASM
インスタンス
1 2 3
2 3 1
自動切り離し
処理継続
自動修復

View Slide

110
Oracle Data Guard / Active Data Guard

View Slide

システム停止による影響
111
計画外のデータセンターの
停止や災害の影響による
平均コスト
年間の合計停止時間の平均 24ヶ月間で計画外停止を
経験したUSデータセンターの
割合
91%
$10M
$350K
Source: Gartner, Data Center Knowledge, IT Process Institute, Forrester Research
87時間
停止時間による1時間当たり
の平均コスト
→

View Slide

Oracle Database自身が持つレプリケーション機能でデータ保護・可用性の提供 + 適切なROIを実現
Oracle Data Guard / Oracle Active Data Guard
プライマリ・
データベース
スタンバイ・
データベース
同期・非同期
破損ブロックの
自動修復※
レポーティング※
バックアップ※
データ保護迅速な切り替えリソースの有効活用
スイッチオーバー
REDO転送によって同期をとること
で、データーベースを障害およびデー
タ破損から保護
計画/計画外停止時に迅速に切り
替えることでダウンタイムを縮小し、
業務を継続
レポーティング、テストやバックアップ
用途でスタンバイ・データベースを活
用可能
※Active Data Guardオプションが必要
112

View Slide

「必要な時に切り替えようとしたら壊れていて切り替えられなかった」
ストレージ・ミラー方式
• ストレージのコピー機能を利用して、ソースとレプリカ
の間でデータの同期をとる方式
• ストレージ・ミラーなどのレプリケーション方式の場合、
ソースでのデータ破損がレプリカにもコピーされ、
いざ切り替えようとしても切り替えられないレプリカに
なる可能性がある
Oracle Databaseのレプリケーション機能では
• REDO (差分)を用いて同期をとる方式
• 受信したREDO情報を検査した上で、スタンバイに
適用するため、破損が伝搬しない
• Oracle Active Data Guardは、ブロック破損や
ロスト・ライトなどを防ぎ、普段から利用して、
いざという時に使えるレプリカを保持
データベースのレプリケーション～よくある課題その1: データ保護
113
ストレージストレージ
ストレージストレージ
インスタンス
(メモリ)
インスタンス
(メモリ)
インスタンス
(メモリ)
REDOログ REDOログ
REDOログ REDOログ

View Slide

データ保護・災害時の業務継続に適したレプリケーション
• 要件・用途に合わせたレプリケーション
• 2種類の適用方法を提供
• フィジカル・スタンバイ・データベース (データブロックレベルでプライマリと等しい)
• ロジカル・スタンバイ・データベース(論理的にプライマリと等しい)
• 2種類の転送方法を提供
• 同期転送(データ保護を優先)
• 非同期転送(システム性能を優先)
• データ差分/整合性を担保する仕組み
• スタンバイへの書き込み(データ変更)は不可
• 適用プロセスの並列化で差分を削減
• 自動でギャップ解決
• ロスト・ライトを自動で検知
• 破損ブロックを自動で修復し、正しい結果を返す(自動ブロックメディアリカバリ)*
Data Guardによるデータ保護
114
*Active Data Guardオプションが必要
プライマリ・データベーススタンバイ・データベース
同期・非同期

View Slide

Data Guardアーキテクチャ
Data Guardにおける同期の仕組み
115
ログ
バッファ
プライマリ・
データベース
スタンバイ・
データベース
NSS/
TT
LGWR
RFS
データ
ファイル
データ
ファイル
アーカイブ
ログ
アーカイブ
ログ
オンライン
REDOログ
スタンバイ
REDOログ
REDO転送
REDOを転送、スタンバイ側で受信
REDO適用
リカバリの仕組みでREDOを適用
ロール変換
スイッチオーバー(計画的)
フェイルオーバー(計画外)で
ロールを変更
MRP
※各バックグラウンド・プロセスの名称
RFS: リモート・ファイル・サーバー・プロセス
MRP: 管理スタンバイ・リカバリ・プロセス
※各バックグラウンド・プロセスの名称
LGWR: ログ・ライター・プロセス
NSS: ネットワーク・サーバーSYNCプロセス
TT: REDO転送スレーブ・プロセス

View Slide

同期転送(SYNC)
データ保護
• プライマリでコミットが発行されるとスタンバイへ転送完
了後にコミット確定
パフォーマンス影響
• スタンバイへの転送時間に依存してプライマリのコミット
処理が待機
非同期転送(ASYNC)
データ保護
• プライマリでコミットが発行されてもスタンバイへの転送
をまたずにコミット確定
パフォーマンス影響
• プライマリへのコミット処理はスタンバイへの転送を待
機しない
Data Guardによるデータ保護
116
転送方式
3.応答
2.転送
4.確定
1.コミット 1.コミット 2.確定
2.転送

View Slide

「切り替え手順が複雑、アプリ側との連携に時間がかかるので切り替えるのを諦めた」
ストレージ・コピーの課題
• 切り替え手順が煩雑で「切り替えることができなかった」、
「時間を要した」結果、サービス停止時間が長期化
• ストレージの切り離しやマウントなどOS上での操作など
Oracle Data Guardでは
• 計画停止と計画外停止などケースにあわせた2種類の切り替え
• 障害時に自動切換も可能
• 少ないステップで数秒～数分で切り替えが可能のため、
サービス停止を縮小可能
データベースのレプリケーション～よくある課題その2: 運用の煩雑化
117
スタンバイ
→プライマリ
プライマリ
迅速に切り変えられ
ず、長期停止
迅速に切り替え、
停止時間を抑える
レプリカ
マスター

View Slide

切り替えや切り戻しが容易
• 少ないステップでの切り替えが可能
• SQLでの切り替え
• Data Guard Broker (Data Guard管理機能)を利用して1コマンドでの切り替え
• 切り替え実施時に高速アプリケーション通知(FAN)を発行可能
• Enterprise Manger Cloud Controlを利用して1クリックでの切り替え
• ケースごとの切り替え方法
• スイッチオーバー: メンテナンスなど計画停止で行うロール変換
• 差分がない状態(データが完全に同期)での切り替え
• スイッチ後の同期も自動で実施され、スイッチバックも可能
• フェイルオーバー: 障害発生時など、計画外停止で行うロール変換
• 同期転送(最大保護モード)以外はデータ損失の可能性あり
• フェイルオーバー後に、旧プライマリをフラッシュバック機能を使って
簡単に新スタンバイにすることが可能
• 自動切り替えも可能(Fast Start Failover)
Data Guardの切り替え
118
プライマリスタンバイ
スタンバイ
→プライマリ
プライマリ
→スタンバイ
スタンバイ
→プライマリ
旧プライマリ

View Slide

「災対環境の必要性は理解しているけれども普段使わない環境へ投資するのは難しい」
ストレージコピーの課題
• 通常時はレプリカ側が利用されず、有事しか活用されないリソースへ
投資することへの費用対効果が見合わない
• 普段使ってないことから、実際に切り替えようとしたら使えない状態で
切り替えられなかった
• レプリカ側のデータ破損やロストライト等、レプリカ側のデータ障害に気付けず、
データ差分があった
Oracle Data Guardでは
• スタンバイを参照用として利用可能(DMLも対応)なので、
参照系の別システムや参照系処理のオフロードで有効活用
• 日々のバックアップ処理をオフロードしてメインの負荷を削減
• 一時的に書き込み可能モードに切り替えて、テスト環境として利用可能
• 普段から利用し、有事の際にきちんと使えるスタンバイを保持
データベースのレプリケーション～よくある課題その3: 費用対効果
119
ソースレプリカ
プライマリスタンバイ

View Slide

適切なROIを実現
• 参照可能モード(READ ONLY)で平常時の利活用
• Active Data Guardオプションが必要
• DMLも実行可能(頻繁な更新がないようなケースを想定)
• バックアップをスタンバイで取得することで、プライマリでのバックアップ処理の
負荷を削減し業務影響をなくすことが可能
• 一時的に書き込み可能モードに変換してテスト環境として利用
• フィジカル・スタンバイから一時的に書き込み可能な
スナップショット・スタンバイに切り替え
• フラッシュバック機能でテスト前の状態に戻し、フィジカル・スタンバイに
戻したら自動で差分適用
• 普段から利用することでデータの整合性、正常性を自動確認
• 参照用として動かすことでデータベースとしての利用可否を確認
• ロストライトなど同期されていないブロックを自動検知
Data Guardのスタンバイ有効活用
120
レポーティング*
バックアップ*
テスト環境
*Active Data Guardオプションが必要

View Slide

Data Guardのユース・ケース
121
DR構成やHA構成
クエリ・オフロード
テスト環境
メンテナンス
バックアップ処理のオフロード
データベースの複製
▶ 可用性レベルを向上したデータ保護
▶ 分析などの参照系のオフロード
▶ プライマリのバックアップ負荷削減
▶ データベース複製時のプライマリへの負荷削減
▶ 一時的に書き込み可能モードに変換してテスト
▶ メンテナンスなどの計画停止をローリングで実施することでダウンタイムを短縮

View Slide

最小構成
ローカル・スタンバイ
瞬時の切り替えや同期転送が
可能な近距離のスタンバイ
リモート・スタンバイ
大規模障害を見据えた災対環境
マルチ・スタンバイ
マルチ・スタンバイ
ローカル・リモートともにスタンバイを持
ち、状況に応じて切り替え。スタンバ
イごとに、同期・非同期を設定可
カスケード
カスケード・スタンバイ
テスト用途などスタンバイとは別に
レプリカを持ちたい場合
FarSync(遠隔同期)スタンバイ
遠隔地スタンバイとの同期転送の中継
構成パターン
122
同期非同期

View Slide

Oracle Data Guard/Active Data Guardは、データ保護のための最善策
データ保護
• REDO転送によって複製データベースに同期をとることで、データーベースを障害及びデータ破損から保護
迅速な切り替え
• 計画/計画外停止時に切り替えることでダウンタイムを縮小し、業務を継続
リソースの有効活用
• レポーティング、テストやバックアップ用途でスタンバイ・データベースを活用可能
まとめ
123

View Slide

124
Oracle GoldenGate

View Slide

リアルタイムなデータ統合およびレプリケーション
• データベースに行われた変更を、Trailファイルという汎用的なフォーマットに変換して転送し、
他のデータベースへリアルタイムに反映
• データベースやOSの種類やバージョンが異なるシステム間での連携が可能
• 稼働中のデータベース同士で双方向に連携が可能
• データベース全体だけではなく、表や列など必要な部分に絞った柔軟な連携が可能
• 既存のデータベースやネットワークへの負荷は最小限
Oracle GoldenGate 概要
125
ソースターゲット
抽出転送受信適用
Trailファイル Trailファイル

View Slide

Classic ArchitectureとMicroservices Architectureの違い
Oracle GoldenGateアーキテクチャ概要
126
• REST対応サービスを提供する
新しいアーキテクチャ
• Oracle Databaseのみサポート対象
• WebUIベースの設定・管理
• 今後Oracle Databaseが
接続対象の場合の推奨ビルド
• 従来から提供されている
アーキテクチャで継続的に提供
• Certification matrix記載の
すべてがサポート対象
• コマンドラインベースの設定・管理
※補足※
• それぞれ、別々のビルドイメージとして提供されています。
• ExtractおよびReplicatは、どちらのArchitectureでも同じものが提供されます
• Oracleでは、ExtractはIntegrated Mode、ReplicatはParallel Modeの利用を推奨しています
Microservices Architecture
Classic Architecture
Replicat (Apply)
- NonIntegrated Mode
- Integrated Mode
- Parallel Mode
Extract (Capture)
- Classic Mode
- Integrated Mode Service Manager
Admin Server
Distribution Server
Metrics Server
Service Manager
Receiver Server
Metrics Server Admin Server
Extract (Capture)
- Classic Mode
- Integrated Mode
Data Pump Collector
Manager
Manager
Replicat (Apply)
- NonIntegrated Mode
- Integrated Mode
- Parallel Mode

View Slide

主なユースケース
Oracle GoldenGate
127
Data Lake
あらゆるデータレイクへの
ストリーミングデータ供給
Stream Analytics
機械学習、地理空間および高度な
ルールの適用
Data Pipelines
ストリーム上で受け取った
データの変換処理
Database HA/DR
アクティブ-アクティブ, マルチマスター,
ゼロダウンタイムDB移行
OLTP Replication
OLTPデータベース間での
トランザクション伝搬
Data Warehouse
データウェアハウスへの
最新トランザクションデータ供給

View Slide

多種多様な製品やサービスに対応
Oracle GoldenGate
128
リアルタイムな
トランザクションデータ伝搬
Oracle Stream Analytics
Kafka
ETL
&ML
Spark
DBMS
Cloud
Big Data
NoSQL
Streams
MySQL Database Server
Oracle Database
IBM Db2
Microsoft SQL Server
Cassandra
Java Message Service
HPE NonStop (Guardian)
SAP Sybase ASE
IBM Informix
SAP Sybase ASE
Netezza
TERADATA
IBM Db2
HPE NonStop
(Guardian)
Oracle
Database
MySQL
Database
Server
Microsoft
SQL Server
IBM Informix Greenplum
SAP HANA
Elasticsearch
MongoDB
JDBC
JDBC
Cloudera Hortonworks
Cassandra Oracle NoSQL
Java Message
Service
Oracle Cloud
Object Storage
MapR
Google BigQuery
Amazon
S3
Amazon
Aurora
Amazon
Kinesis
Amazon
Redshift
Oracle
Database
Cloud
Oracle
Autonomous
Database
Confluent
Oracle
Autonomous
Database
Kafka
Kafka
Kafka
HBase
HDFS
Snowflake
Microsoft
Azure Ecosystem
HIVE
Flink
ETL
&ML

View Slide

多種多様な製品やサービスに対応
Oracle GoldenGate – Data GuardやActive Data Guardとの違い
129
• DB全体を複製
• REDO適用を利用した物理的な
レプリケーション
(※1) 一部制限あり
異なるOSやDB間での
レプリケーションが可能
(※1)
同一のバージョンやエンディアン間での
レプリケーションが可能(※2)
(※2)同じData Guard構成内の異機種のプライマリとスタンバイのData Guardサポート(Doc ID 2201589.1)
• 必要な表のみをレプリケーションできる
• 論理的なレプリケーション
Data Guard
Active Data Guard
Oracle GoldenGate
【堅牢】
【柔軟】

View Slide

ライセンスの違いによる使用可否
Oracle GoldenGate – Data GuardやActive Data Guardとの違い
130
 REDOログを転送、適用
 計画停止、ディザスタ・リカバリ
 様々なデータ破損からの保護
 同期および非同期構成のサポート
 スタンバイDBの活用(Active Data Guard)
 破損データブロックの自動修復(Active Data Guard)
 REDOログから抽出したTrailを転送し、SQLを実行
 計画停止、移行やアップグレード、リアルタイム・データ連携
 異なるOSやDB間でのレプリケーション
 オブジェクト単位の柔軟なレプリケーション
 Active – Active 構成
REDOを転送
Trailを転送
Trailを転送
Oracle Active Data Guard (ADG)
Oracle GoldenGate (GG)
※Oracle GoldenGateのライセンスには、Oracle Active Data Guardのライセンスが含まれます

View Slide

131
Oracle Advanced Security

View Slide

データベース内の機密データを暗号化、リダクションにより保護
透過的データ暗号化
• データベース層でデータを暗号化
• データベースを迂回して、ストレージから
直接機密データを読み取ることを阻止
Data Redaction
• 問合せ結果データをリダクション(マスク)
• 権限のないユーザーに対して
データが表示されるリスクを軽減
Oracle Advanced Security
132
Redacted
Applications
Data Redaction
XXXX-XXXX-4368
Disks
Exports
Backups
Transparent
Data Encryption
Encrypted
Storage
d$f8#;!90Wz@Yg#3

View Slide

133
アプリケーションの変更なしに機密データを暗号化
透過的データ暗号化(TDE)
Disks
Exports
Backups
Transparent
Data Encryption
Encrypted
Storage
d$f8#;!90Wz@Yg#3
データ・ファイルに格納されているデータを保護
• データ・ファイルに格納されている機密データを暗号化
• 記憶域メディアやデータ・ファイルが盗まれた場合、
格納されているデータの情報流出を防止
• セキュリティに関連した規制コンプライアンスの問題への対応
アプリケーションを変更することなく、機密データへのアクセスが可能
• 許可されているユーザーやアプリケーションでは、
自動的にデータの暗号化および復号を実施
• 暗号化、復号のためにアプリケーション変更は不要

View Slide

134
データベース暗号化のイメージ例
透過的データ暗号化(TDE)
正当な権限を持つユーザーが
DBに接続してデータを参照
ID Name Salary
1 John $100,000
2 Bill $200,000
3 Kevin $50,000
4 Susan $300,000
ID Name Salary
Ko W(KS -7j_
Nu u/eED l=.d9
A9 k7<: “gxjm
F) Lc<= ‘a}41
暗号化によって、ストレージから
直接データの参照は不可
アプリケーションは変更不要で
暗号化データの参照が可能
ストレージ上のファイルから
直接データを参照

View Slide

135
• ユーザーの権限に応じてリアルタイムにデータをマスクし、アクセスコントロールを実現
• 職責に応じて閲覧させるべき情報をデータベース側で制御
• アプリケーションの変更なしに、情報漏洩リスクを最小化することが可能
通常業務で不必要な機密データへのアクセスを抑制
Data Redaction
業務上、参照が必要なユーザーテーブル
DBサーバー
ポリシー設定
APサーバー
2172-9841-4368
XXXX-XXXX-4368
アプリ
DBはポリシー設定に基づいて、
利用者権限に応じたマスクを実施
アプリケーションは
伏字化を意識する必要がない
2172-9841-4368
XXXX-XXXX-4368
業務上、参照が不必要なユーザー
2172-9841-4368
6342-4881-5211
3311-0090-5055
マスキングとは異なり、
DB上のデータはマスクされない

View Slide

136
Oracle Database Vault

View Slide

特権ユーザーの職務分掌にも対応したアクセス制御
137
職務分掌特権ユーザー (SYS, DBA権限)であっても情報にはアクセスさせない
透過的既存アプリケーションの変更不要、Multitenant Architecture対応
厳密ユーザー、クライアント情報 (IPアドレスなど)、時間を組み合わせポリシー設定
アプリケーション
SELECT *
FROM customers
管理者
(特権ユーザー)
人事情報
顧客情報
財務情報

View Slide

特権ユーザーの職務分掌
特権ユーザーの無制限のアクセスを禁止し、ユーザーごとのアクセス権限を分離する
138
機密データの
取り扱い者
DB管理者
セキュリティ
管理者
機密データ
データ・ディクショナリ
業務データ
ユーザ・アカウント
時刻
=8:00～19:00
曜日 = 月～金
IPアドレス
=xxxxx
• 許可された範囲で
機密データにアクセス可能
• DBの運用管理業務
• 業務データと機密データへの
アクセスは不可
• アカウントと鍵の管理業務
• 業務データと機密データへの
アクセスは不可
必要に応じてルールを適用し、
時間帯やIPアドレスでアクセスを制限する
一般利用者
• 許可された範囲で
業務データにアクセス可能
ルールセット

View Slide

Multitenant Architecture環境でのDatabase Vault
139
SYS
給与
SYS
在庫
PDB2
PDB1
SYS
SYSTEM
CDB
Database Vaultで保護されている
PDBの表に対して、CDBのSYS
ユーザーはアクセスできない
Database
Vault ON
Database
Vault OFF
CDB
管理者
PDB
管理者
それぞれのPDB管理者が
自分のPDBのみを管理する
インフラ管理として
必要な業務のみ
アクセスを許可
顧客人事 CDBのSYSユーザーは
PDBの表にアクセス
できてしまう

View Slide

テストフェーズにおけるポリシーの妥当性評価
Database Vaultポリシーをシミュレーション
• ポリシー違反があった場合、アクセスをブロックするのではなく、ログとして記録
単体テストからシステムテストのフェーズでポリシーの妥当性評価に最適
シミュレーション・モード
140
シミュレーション・ログ
(DBA_DV_SIMULATION_LOGビュー)
HR スキーマ
HR App
BI Tool
シミュレーション・モード

View Slide

141
Oracle Audit Vault and Database Firewall

View Slide

漏れのない監査と不正なSQLからの防御を実現
Oracle Audit Vault and Database Firewall
142
• Oracle Solaris
• Oracle Linux
• Red Hat Enterprise Linux
• IBM AIX on Power Systems
• Microsoft Windows Server
ユーザー
ネットワーク
イベント
Database Firewall
監査情報、
イベントログ
Operating Systems
Databases
ポリシー
レポート
アラート
Audit Vault Server
• Oracle Database
• MySQL
• IBM DB2
• Microsoft SQL Server
• SAP Sybase ASE
透過的既存アプリケーション、データベースの変更不要
正確な検知 SQL文を正確に理解し検知するSQL文法解析エンジンを搭載
漏れのない監査データベースへのローカル接続等、ネットワークを経由しないSQLも監視

View Slide

監査情報の収集、分析、およびレポート
• OSと一体化したソフトウェア・アプライアンス
• データベース、OS、ディレクトリから
監査レコードを収集し、安全に保存
• 容易なログの絞込み＆分析
• アラート通知
• 調査とコンプライアンスのためのカスタム
および事前定義されたレポート
• 収集したログはリテンションポリシーで管理
Audit Vault Server
143
監査情報、
イベントログ
Operating
Systems
Databases
ポリシー
レポート
アラート
Audit Vault Server

View Slide

ネットワークのモニタリングによるデータベース監視とSQLインジェクション対策
• OSと一体化したソフトウェア・アプライアンス
• ネットワーク・トラフィックからデータベースの
アクティビティを監視
• 典型的なアクティビティのプロファイルを作成し、
アクセスパターンの変化をすばやく特定
• これまでにないSQLがデータベースに到達するのを
検出またはブロック
• ホワイトリスト/ブラックリストベースのポリシーを使用した
異常検出と脅威のブロック
Database Firewall Server
144
ユーザー
ネットワーク
イベント
Database Firewall Server Databases
ポリシー
レポート
アラート
Audit Vault Server

View Slide

ネットワークのモニタリングによるデータベース監視とSQLインジェクション対策
いずれかの方法でデータベースに接続可能
• プロキシ
• ネットワークを介したデータベースへの
不正アクセスの検出と防止
• ホスト監視
• データベースのネットワーク・トラフィックを
アクティブに監視
• Out-of-band
• ネットワーク・エージェントを使用せずに
データベース・トラフィックをアクティブに監視
Database Firewall Server
145
ユーザー
Database
Firewall
Server
ホスト監視
Out-of-band
プロキシ

View Slide

Oracle Real Application Testing
146

View Slide

システムおよびパフォーマンス・テストは、ミッション・クリティカルなシステムで必須
• 実プロジェクトにおいてシステムの開発期間がますます短くなり、テスト期間も短い
• スケジュール通りに進捗せず、要件定義や設計フェーズで遅れが生じることも多く、
システム・カットオーバの日付を後ろ倒しにもできず、結果としてテスト期間が削られる
求められる「テストの自動化・効率化」
• 自動化できる項目の見極めを行う必要がある
• 適切なテスト計画・テスト項目策定のスキル、テストツールの操作スキルが必要
• 高品質のテストを行うためには、単純に「ツールで自動化」すればよいというものでもない
テスト・ソリューションの必要性
147

View Slide

データベース性能を担保するための、プロアクティブな管理ツール
• アプリケーションのサービス品質の向上
• 迅速なアップグレードを可能にし、リスクを軽減
• リスクの無いアップグレードと新しいテクノロジーの採用によりビジネスの俊敏性が向上
• DBAの生産性を大幅に向上
Real Application Testing (RAT)とは
148
サービス品質の
管理
低リスクの
テクノロジーの
迅速な採用
DBAの
生産性向上

View Slide

Real Application Testing (RAT)の機能
149
リスクの最小化
自動化
コスト削減
データベース
・リプレイ
データベース
統合リプレイ
SPA
SPA
クイックチェック
SPA = SQL Performance Analyzer
 負荷テストのソリューション
 問題を検出して修正
• SQL応答時間のテスト・
ソリューション
• 性能に問題のあるSQLを
識別し、調整
• オンプレミス、あるいは
Oracle Cloudのための
データベース統合の
キャパシティ・プランニング
• データベースの性能に対する
定期的なDBAタスクを事前
に特定

View Slide

本番環境のSQLワークロードをテスト環境で再現し、SQL単位のパフォーマンス比較が可能
• システム変更前後などで実行計画を比較
• 実行計画が変動するSQLが特定でき、性能劣化が予測されるSQLに関しては事前に対策、
運用後のトラブルを軽減
劣化が予測されるSQLのチューニングが容易に
• パフォーマンスを比較するだけではなく、SQLチューニング・アドバイザやSQL計画管理を併用することで
SQLチューニングも実施可能
• Oracle Enterprise Managerで自動的にグラフィカルなレポーティングを出力、チューニング後の確認も
画面上から可能
SQLパフォーマンス・アナライザ(SPA)
150

View Slide

SQLパフォーマンス・アナライザ: 処理の流れ
151
クライアント
APサーバー
DBサーバー /
ストレージ
①SQLワークロード取得
②変更前の
SQL実行
③変更後の
SQL実行
④分析
実行計画
(変更後)
実行計画
(変更前)
比較分析
SQL Tuning Set:
指定期間に実行された
SQL群の情報
実行計画
(変更後)
実行計画
(変更前)
STS STS
テスト環境
本番環境

View Slide

システム変更後にコストを抑えながら高い信頼度で検証を実行し、確実な改善を達成
• 分析可能なシステム変更例
• DBアップグレード、パッチ、初期化パラメータの変更
• OS、HW、DBの構成変更
• 索引の追加、パーティション化、マテリアライズド・ビューなどの変更
• オプティマイザ統計情報の収集および更新
• SQLプロファイルの作成などのSQLチューニング操作
• プラガブル・データベース(PDB)またはスキーマ統合手法を使用したデータベース統合テスト
SQLパフォーマンス・アナライザ: ユースケース
152

View Slide

SPAクイック・チェック
• 本番データベース上でシステム変更を簡単に、素早く検証
• ボタン1つをクリックするだけで初期化パラメータ変更の影響、オプティマイザ統計収集の影響、
キーSQLプロファイル実装の影響といったDBAタスクを検証
• Oracle Enterprise Manager Cloud Controlに含まれる機能
SPAクイック・チェック
153
DBA
テスト環境本番環境
SPAを実行したい…
実行するには、安全だけど…しかし
• 別途HWが必要
• テストデータは本番データと同等であるべき
• 変更により、タスクに時間がかかったり、
エラーが発生しやすい
実行するには簡単だけど…しかし
• リソースを大量に消費し、本番パフォーマンスに
影響を与える可能性がある
• 変更は手動でプライベートセッションに
スコープする必要がある
• 完了するのに長時間がかかるかもしれない
• デフォルトでリソース制御がない

View Slide

初期化パラメータ変更の影響検証
• 変更する前に、データベース・ワークロードへの影響を検証
• alter session文で変更できる値
オプティマイザ統計の影響検証
• オプティマイザ統計を収集する前に、データベース・ワークロードへの影響を検証
キーSQLプロファイル実装の影響検証
• 自動SQLチューニング・アドバイザで自動実装で作成されるプロファイル(キーSQLプロファイル)を実装前に、
プロファイル実装の影響を検証
自動SQLチューニング・アドバイザの統計結果の検証
SPAクイック・チェック: ユースケース
154

View Slide

実稼働ワークロードによるデータベースの負荷とパフォーマンスのテスト
• タイミング、トランザクション依存性などの作業負荷特性を完全維持
トランザクションのスループットをテストおよび測定
• 本番展開前にテスト・システムのアプリケーション・スケーラビリティと同時実行性の問題を特定
使用シナリオ
• プラットフォームの移行 (例えば Exadata)、アップグレード、パッチ適用、新しいデータベース機能または
オプションの実装など
データベース・リプレイ
155

View Slide

データベース・リプレイ: 処理の流れ
156
分析レポート
キャプチャ
ファイル
キャプチャ
ファイル
リプレイ・
クライアント
①ワークロードをキャプチャ
キャプチャ時のCPU使用率3 ~ 5%程度
②前処理 ③リプレイ ④分析
DBサーバー /
ストレージ
クライアント
APサーバー
DBサーバー /
ストレージ
本番環境テスト環境

View Slide

リプレイ実行後、比較レポートを生成
• ワークロード・リプレイレポート
• AWR比較レポート
• ASHレポート
キャプチャ時とリプレイ時の違い
• パフォーマンスの違い
• エラーの内容
• リプレイ時に発生した新規エラー
• キャプチャ時に発生しリプレイ時に
発生しなかったエラー
• キャプチャ時に発生しリプレイ時に発生したエラー
• データの違い
• キャプチャ時と異なる行数が変更されたDML
• キャプチャ時と異なる行数が返されたSELECT
データベース・リプレイ: 分析結果
157

View Slide

データベース・リプレイ一般的な負荷ツール
テストシナリオ不要。
本番ワークロードをキャプチャし、リプレイするだけで
本番負荷を再現。
必要。
本番相当のワークロードを擬似的に作成し、広範囲に及ぶ
テストシナリオの作成が必要となり、時間とコストがかかる。
「テストシナリオが不十分 = テスト品質が不十分」
作成者のスキルに依存。
テスト担当データベース管理者アプリケーション担当者
負荷テスト環境 DBサーバー環境
APサーバーが使用できない状況でも負荷テストが可能
APサーバーとDBサーバー環境が必要
テストデータベース・レイヤに限定し負荷をかけるため DB担当者が
本番のワークロードをキャプチャすることで繰り返しリプレイする
ことが可能
負荷ツールとテスト対象アプリケーション両方に精通している
必要がある
分析データベース管理者だけで負荷テストが実施でき、
理解しやすい分析結果のレポートが出力される。
アプリケーションがデータベース全体に与える影響を検証するには、
DB 担当者のデータベース性能結果分析スキルが必要。
アプリケーション担当者だけでは、負荷テストの実施から
分析までを完結することができない。
データベース・リプレイ: 一般的な負荷ツールとの比較
158

View Slide

データベース統合を管理するための包括的な
エンド・ツーエンド・ソリューション
推測による作業や人的ミスを排除することにより正確な
統合アプローチを提供
• 過去のワークロードに基づく分析(データベースおよび
ホストのメトリック)
• 計画から展開までの統合のすべての段階における
自動化
さまざまなシナリオに柔軟なアプローチを提供
• ExadataまたはOracle Cloudへの統合をサポート
計画
• 統合候補データベースのAWRを利用した統合に
関するアドバイスを提供
移行
• EMプロビジョニング機能を使用しデータベースを
新しい統合プラットフォームに移行することで
統合計画を実装
検証
• 統合データベースでテスト・ワークロードを実行すること
で統合計画を検証
データベース統合リプレイ
159

View Slide

複数の環境を組み合わせてテストを実施
データベース統合リプレイ
160
本番環境
CRM
DB1
HCM
DB2
DWH
DB3
Windows
DB 11gR2
AIX
DB 11gR2
HP-UX
DB 12cR2
Capture 1 Capture 2 Capture 3
5月31日
月末処理
6月15日
ピーク時
6月18日
ETL処理
テスト環境
統合リプレイ・ディレクトリ
リプレイ
Capture 1 Capture 2 Capture 3

View Slide

161
Oracle Data Masking and Subsetting

View Slide

非本番環境へ安全にデータを共有
Oracle Data Masking and Subsetting Pack
162
利点
• テスト環境、開発環境から
機密データの漏洩防止
• データのサブセット化による
ストレージコストの最小化
• テストデータが監査の対象外となる
コンプライアンス・コストを削減
機能
• 機密性の高い列、表の親子関係を自動検出
• 包括的で拡張可能なマスキング変換
• 統合型のデータ・サブセット化
01001011001010100100100100100
1001001001001001000100101010
01001001001110010010010010010
01000010010010111001001010100
10010101010011010100101010010
0000011111111000
SSN
463-62-9832
クレジット・カード
3715-4691-3277-8399
SSN
463-62-9832
576-40-7056
518-12-6157
281-50-3106
クレジット・カード
3715-4691-3277-8399
5136-6247-3878-3201
3599-4570-2897-4452
5331-3219-2331-9437
本番
テスト/開発
555-12-1234
5555-5555-5555-4444
機密性の高い情報を不可逆な形式にマスキング

View Slide

機密性の高い列と表の親子関係を自動で検出
Data Masking
163
• あらかじめ組み込まれた検出パターンによって、
Oracle Databaseの表から自動的に機密情報
(例: クレジットカード番号、メールアドレス)、
個人情報を含んだカラムを検出
• データベース・オブジェクトの参照関係、
親子関係も自動で検出

View Slide

拡張可能なマスキング・フォーマット・ライブラリ
事前定義済みのマスキング・フォーマットを提供
マスキング・フォーマットはカスタム可能
• ランダムな数字、文字列、日付
• 置換
• ユーザ定義のPL/SQL関数
マスクされた値のサンプルを生成
E-Business SuiteとFusion Applicationsのテンプレートを提供
Data Masking
164
事前定義されているフォーマット
定義したフォーマットによるサンプル生成
様々なマスキング形式

View Slide

マスキングの例
Data Masking
165
Country Identifier
CA 226-956-324
US 610-02-9191
UK JX 75 67 44 C
Country Identifier
CA 368-132-576
US 829-37-4729
UK AI 80 56 31 D Emp ID First Name
324 Albert
986 Hussain
Emp ID First Name
324 Charlie
986 Murali
Emp ID First Name
324 Charlie
986 Murali
経理
Company Closing Price
IBFG $36.92
XKJU ¥789.8
Company Closing Price
IBFG $89.57
XKJU ¥341.9
フォーマットを維持してランダム値へ変換
一貫性を持ったアウトプットの生成
人事
条件に沿ったマスク
BLOB
3178973456
6509876745
Search : [0-9]{10}
Replace : *
BLOB
**********
**********
BLOB として格納されたファイルのマスク
シャッフル
ID COUNTRY
1 US
2 JP
3 US
4 UK
5 FR
ID COUNTRY
1 US
2 FR
3 UK
4 JP
5 US
Country カラムの値に応じたフォーマットを作成
(Country が UK なら [英字][英字][6桁の数字][英字])
通貨、桁数を変えずに、ランダム数値でマスク

View Slide

表と表の関連性を維持したままデータのサブセットを生成
サブセットの生成前に不要な行を削除することで、セキュリティ・リスクを軽減
テスト環境のストレージ・コストを削減
2つのサブセット化方式を提供
• 目標ベース: 相対的なデータベース・サイズ(本番1TB、テスト用100GBなど)、相対的な表サイズ
• 条件ベース: Where句により、以前の日付のデータ破棄やある地域のデータの抽出など可能
Data Subsetting
166
100%
100M Rows 20%
20M Rows
2%
2M Rows
目標ベース
相対的なサブセット
条件：
DepartmentID=10
条件ベース
Where句条件によるサブセット

View Slide

167
Oracle Machine Learning

View Slide

高度な分析をデータベース内で実行できる機械学習プラットフォーム
データ分析にかかる変換コスト、データ移動コストの削減
• Oracle Database標準機能としてDB内で処理完結
• データの移動コストを最小化
• データ前処理 (変換/補完)、モデル生成が高速
• RやPythonのスクリプトをDB内で実行
• 分析サーバーを別途用意する必要なし
システム化、実装のコストの削減
• MLモデルをDB内に生成
• そのままDBのデータに適用可能
• 高性能、スケーラブルでセキュアなプラットフォーム
機械学習をすべての人に
• 機械学習ベースのソリューションを活用する
すべての人をサポート
• オープンソースパッケージを活用して、機能を拡張可能
Oracle Machine Learningの概要
Oracle Machine Learning
OML Microservices*
Supporting Oracle Applications
Image, Text, Scoring, Deployment,
Model Management * Coming soon
OML4SQL
Oracle Advanced Analytics
SQL API
OML4Py*
Python API
OML4R
Oracle R Enterprise
R API
OML Notebooks
with Apache Zeppelin on
Autonomous Database
OML4Spark
Oracle R Advanced Analytics
for Hadoop
Oracle Data Miner
Oracle SQL Developer extension
168

View Slide

オラクルの取り組み
従来の分析環境
RDBMSなどオリジナル・データの
ある場所からデータをツール内に移動して分析を実行
データが存在する場所で
分析を実行
分析
• モデリングのデータの準備・移動に時間や手間がかかる
• データの絞り・サンプリングでモデル作成
• シングルスレッドが主流(マルチスレッドには工夫が必要)
• ファイル等の持ち出しによるセキュリティの問題
• アドホックな運用環境のスキルが必要
• 本番環境へのモデルのデプロイには様々な作業が必要
• データの移動が不要でモデリングに手間要らず
• 全量分析が可能
• 手軽にマルチスレッドが可能
• DB内から外へデータを出さずに分析
• 分析や機械学習のスキルセットで運用
• DB内のモデルはSQLで簡単に本番環境へ適応・更新
データ分析をデータベース内で実行
169
データ移動
分析
?
データ移動
Flat File

View Slide

回帰(Regression)
線形モデル(LM)
一般化線形モデル(GLM)
サポート・ベクター・マシーン(SVM)
ステップワイズ線形回帰
ニューラル・ネットワーク
異常検出(Abnormally Detection)
1クラスSVM
相関(Association Rules)
Apriori/バスケット分析
属性評価(Attribute Importance)
最小記述長(Minimum Description
Length)
CUR行列分解
教師なしペアワイズKLダイバージェンス
A1 A2 A3 A4 A5 A6
分類(Classification)
決定木(Decision Tree)
(2項分類)一般化線形モデル(GLM)
単純ベイズ(Naïve Bayes)
ランダム・フォレスト(Random Forest)
サポート・ベクター・マシン(SVM)
明示的セマンティック分析(ESA)
ニューラル・ネットワーク
クラスタリング(Clustering)
期待値最大化法(EM)
k平均法(k-means)
直交パーティショニング・クラスタリング
(O-Cluster)
時系列(Time Series)
指数平滑法等
(単純,、2重、Holt-Winters法、Regular & Irregular,
with and w/o trends & seasonal 含む)
特徴抽出(Feature Extraction)
明示的セマンティック分析 (ESA)
Non-Negative Matrix Factorization
(NMF)
特異解分析 (SVD)
主成分分析 (PCA)
教師無し Pair-wise KL Div
予測問合せ(Predictive Queries)
クラスタリング問合せ
特徴抽出問合せ
異常検出問合せ
統計関数(Statistical Functions)
基本関数：最小、最大、メジアン、標準偏
差、t検定、F検定、ピアソン分布、カイ二乗検
定、分散分布(ANOVA)等
SQL関数：行列の選択、条件式、結合、等
Oracle Machine Learning Algorithms and Analytics
170

View Slide

データベースに統合された機械学習エンジン
• Oracle Database, Autonomous Databaseの機械学習機能への迅速なアクセスでSQLユーザを支援
データベース内で完結した並行・分散アルゴリズム
• 別の機械学習エンジンへのデータ抽出の必要無し
• 高速性と拡張性を兼ね備える
• 実時間バッチスコアリング
• 予測に対して根拠を示す
データベースオブジェクトとしての機械学習モデル
• パーミッションに基づいたアクセスコントロール
• ユーザの行動を監視
• 異なるデータベース間でモデルのエクスポート/インポート
Oracle Machine Learning for SQL (OML4SQL)
171
SQL Interfaces
SQL*Plus
SQL Developer
…
Oracle
Autonomous
Database
OML Notebooks
Oracle Database

View Slide

シンプルなSQL文を用いた分類モデルの活用例
OML4SQL: モデルの作成とリアルタイム予測
BEGIN
DBMS_DATA_MINING.CREATE_MODEL(
model_name => 'BUY_INSUR1',
mining_function => dbms_data_mining.classification,
data_table_name => 'CUST_INSUR_LTV',
case_id_column_name => 'CUST_ID',
target_column_name => 'BUY_INSURANCE',
settings_table_name => 'CUST_INSUR_LTV_SET');
END;
SELECT prediction_probability(BUY_INSUR1, 'Yes'
USING 3500 as bank_funds, 825 as checking_amount, 400 as credit_balance, 22 as age,
'Married' as marital_status, 93 as MONEY_MONTLY_OVERDRAWN, 1 as house_ownership)
FROM dual;
モデル作成(PL/SQL)
リアルタイムスコアリング(SQLクエリ) ※クエリ内で予測され結果が取得できます
172

View Slide

Autonomous Database上でデータサイエンティストが協力し合うためのUI
• Autonomous Data Warehouse Cloudの標準機能
機械学習ソリューションをビルド、評価、デプロイ可能
• Apache ZeppelinベースのNotebook型SQLインターフェイス
複数のデータソースや複数のAutonomous Databaseサーバーに
アクセス可能
• 複数のユーザが1つのノートブックを開くことが可能で
ユーザによる変更は他のユーザに即座に反映
• SQLやPL/SQLスクリプト言語を分析し値を抽出、
機械学習アルゴリズムがインサイトや予測を提供
Oracle Machine Learning Notebooks
173

View Slide

データベースの機能としてRの実行環境を提供
• Rの処理をデータベース・サーバーへオフロード
• データ・フレーム上またはOracle Databaseの表でRを実行可能
• DB内統計エンジンとの連携
• R関数の透過的な実装
• コマンド、コンソール、ワークスペースは通常のRと同じものを利用可能
企業のデータベースをRで利用
• データベース内のデータに対してダイレクトかつ透過的に処理
• 大規模データセットをRで扱うことが可能
高いパフォーマンス
• 自動で並列処理をデータベース内にて実行
• クライアントのパフォーマンスに頼ることのなくRを実行
Oracle Machine Learning for R (OML4R)
174
OML4R
SQL Interfaces
SQL*Plus
SQL Developer
…

View Slide

R言語を使用した機械学習機能
R言語の処理を透過的にOracle Database内の処理に変換することで、大規模、かつ複雑な分析を実現します。
Database内処理に変換できない部分もDatabaseサーバー上でRプロセスを実行します
OML4Rのアーキテクチャ
175
R Engine
R Engine
R Engine Other R
packages
Rの処理をDatabase内の処理に変換・オフロード
OML4R
R Engine
OML4R
SQL/R R
結果結果
Databaseサーバー内で外部プロセスとしてRを実行することも可能
Other R
packages
Rクライアント
• RスクリプトをOracle Databaseで
実行するようにスクリプトを発行します。
• グラフの描画や処理フローの制御は、通常の
Rの機能を利用し、クライアント側で実行します。
Oracle Database内部での実行
• Rの関数をSQLに変換して実行します。
• Oracle Databaseの並列実行の仕組みを
活用し、大量のデータに対応します。
• Oracle Databaseの持つ統計関数、データ
マイニング機能を内部的に活用します。
Oracle DatabaseサーバーでのR実行
• データベースが複数のRのプロセスをデータベース
サーバー上に外部プロセスとして起動します。
• SQLやPL/SQLからRのスクリプトを
呼び出し可能です。
分析者
Oracle Databaseサーバー
外部
プロセス
(旧称Oracle R Enterprise (ORE))

View Slide

Oracle SQL Developer*で手軽に分析ワークフローを作成可能
データサイエンティストの生産性を向上
• 典型的なデータサイエンスの
作業を自動化
• 簡単にドラッグ＆ドロップが
可能なインターフェイス
• 手軽に分析ワークフローを
定義・共有
• 多様なアルゴリズムとデータ変換
• SQL文を生成することで
速やかなデプロイが可能に
*Oracle DatabaseのためのSQL開発ツール
Oracle Data Miner
176

View Slide

大規模分析に向けて更なる高速化のために
ORE透過層を利用した検証事例
• データの加工、モデルの作成、スコアリングなどの
各種処理を透過層にて処理できる場合は、
さらなる高速化が期待できます
• 一例として、新日鉄住金ソリューションズ様による
検証では、透過層の利用により、OSS Rと比べ、
処理時間を約40分の1に短縮可能なことを
確認できました
ご参考情報
• 検証結果の特集記事 (左の画像)
https://blogs.oracle.com/dbjp/oracle-advanced-analytics-v2
Oracle Machine Learning (旧: Oracle Advanced Analytics) 事例
177

View Slide

Oracle Spatial
178

View Slide

空間データ、地理データの高度な活用を実現する空間データベースプラットフォーム
Oracle Spatial
179
Oracle DB上で空間データを
検索、分析
• 空間データを扱うためのデータ型、関数、
プロシージャを提供
• SQLで空間演算子による空間データの検索、
分析が可能
• Partition、パラレルクエリなどOracle DB機能
も併用し、分析処理を高速化
高度な空間情報活用を実現する
各機能
• 最短経路など、最適なルートを探索する
ルーティングシステム
• 動線上の位置情報に様々な情報を
付随させる線形参照システム
• 空間データの高速な検索を実現する
空間索引機能
• 異なる座標系の空間データを自動的に
変換する座標系変換機能
継続的に品質向上、機能拡張に
注力
• Rasterデータや3Dデータへの対応、
KMLのサポート
• Oracle 12cでは更なる高速化のパラメータを
追加
他社GISソフトウェアとの高い親和性
• Autodesk社 : MapGuide/OnSite
• ESRI社：ArcGIS/ArcView
• GE社：Smallworld

View Slide

空間データを豊富な関数とSQLで扱える
多様な機能性
• 変換、分析～バリデーションや修正まで
• 測地系の明示的/暗黙的変換
• 空間分析、集計関数、線形参照システム..
パフォーマンスおよびスケーラビリティ
• R-Tree型空間索引による高速な空間検索
• Oracleの並列化/高速化技術を享受
• Spatial Vector Acceleration(SVA)
組み込み容易性
• ほとんどの機能はSQLベースでのアクセスが可能
• 空間関連処理をDBへオフロード
Oracle Spatial
180
ベクトルデータ関連の実装関数約250種
• 豊富な空間位相判定
• 空間データの変換、分析関数、測地系変換
• ラスター、3Dデータ、点群、TINにも対応
一般的なGeoDatabaseの限界を突破
• 検索範囲を範囲階層で絞り込む索引構造
• パーティションによるパラレルクエリ対応
• 索引のパーティション化にも対応
• SVAにより更なる高速化
SQLで空間データを自在に扱える
• 上述の空間判定、変換、分析関数も
• アプリケーションは結果の取り扱いに注力
ラスターデータ関連の実装関数約190種
• オルソ補正、光学補正、モザイク化、ピラミッド化
• 演算(ラスター代数)

View Slide

種々のデータにSQLでアクセス可能
Oracle Spatial
181
Topologies
3D / LiDAR
Raster
Networks
Polygons
Lines
Points
Location
Tracking
(Geofencing)
SELECT a.customer_name, a.phone_number
FROM policy_holders a
WHERE sdo_within_distance( a.geom, hurricane_path_geom,
‘distance = 10 unit = mile’) = ‘TRUE’;
Spatial Analysis Through SQL

View Slide

Big Data SQL
182

View Slide

Oracle SQLを利用して、すべてのデータへ効率的にアクセス
Oracle Big Data SQL
183
Oracle Database
Kafka NoSQL
Hadoop Object Storage
Oracle Big Data SQL
Any SQL Client
様々なデータストアに
簡単アクセス
HDFS、NoSQL、Kafka、
Object Storage
全てのデータストアに
一貫したセキュリティを提供
OracleのSQLで全量データを
分析
Smart Scanによる
高パフォーマンスクエリの実現

View Slide

外部表として、HDFSなどのデータへアクセス
Oracle Databaseの外部表
• SQLやJavaなどのアプリケーションからは普通の
外部表としてアクセス
• Oracle Databaseのセキュリティ機能も有効
分散環境におけるスケーラブルなデータ処理
• HDFS、NoSQLなど様々なストレージから
効率的なRead処理を実施
• Oracle型にデータを変換し、SQL処理を実施
• 選択、射影、結合
• 関数処理
• 集計
Big Data SQLアーキテクチャ
184
Hadoop Cluster
Data
Node
BDSQL
Data
Node
BDSQL
Data
Node
BDSQL
Data
Node
BDSQL
Hive
Metadata
Object
Stores
Kafka NoSQL
Python Graph
R
node.js Java
REST SQL
Oracle Database
+ Big Data SQL

View Slide

Oracle Databaseのセキュリティモデルを適用
Big Data SQLセキュリティ機能
185
Hadoop Security
ACL’s | Sentry | HDFS Encryption | Encryption in Motion
• Oracle Databaseと同様のセ
キュリティモデルをより広範なデー
タストアに適用
• データリダクションなど高度な機能
が適用でき、異なるソリューション
間で結合が可能

View Slide

Oracle Databaseを介せずにHDFS等のデータにSQLでアクセス
Query Server
• Oracle Database不要(ライセンス含む)
• エッジサーバー上にデプロイされるクエリエンジン
• HDFSやKafka、Object Storage、NoSQLに
従来のBDSと同じようにSQLアクセス可能
• メンテナンス不要
• Cloudera Manager、Ambariから管理
Query Server
186
Hadoop Cluster
Data
Node
BDSQL
Data
Node
BDSQL
Data
Node
BDSQL
Data
Node
BDSQL
Hive
Metadata Edge Node
BDSQL Query
Server
Object
Stores
Kafka NoSQL
Python Graph
R
node.js Java
REST SQL

View Slide

標準構成とQuery Server構成の比較
187
標準構成
Oracle Database + Big Data SQL
Query Server
SQL Support Oracle SQL Oracle SQL
サポートされる
Oracle Database
4.1.1: 19.9
4.1: 19.6, 19.8
4.0: 18c
3.2.x: 12.1, 12.2
N/A (database included)
Oracle Databaseとしての利用 Supported Not supported
Hive Metadata連携手動(+ tooling) 自動同期
セキュリティ HDFS + Sentry + Oracle Database Advanced
Policies
HDFS + Sentry
デプロイメント Data Nodes + Oracle Database 19c Data Nodes + Edge Node
インストール作業 Hadoop側でのセットアップ
Oracle Database側でのセットアップ
Hadoop側セットアップ時にDB (Query Server)を
自動構築

View Slide

Oracle Databaseへのネットワーク接続
Oracle Net Services
188

View Slide

Oracle Databaseのネットワーク接続に関係するコンポーネントの総称
Oracle Databaseのネットワーク接続に関わるOracle
NetプロトコルやOracleリスナー・プロセスなどのコンポーネ
ントの総称をOracle Net Servicesという。
OracleクライアントからOracleサーバーへの接続だけでな
く、 Oracleサーバー同士を接続するDatabase Linkや
Data GuardなどもOracle Net Servicesの役割。
Oracle Net Services
tnslsnr
Oracle Net Services
Database Link
Data Guard
Oracle Net
プロトコル
Oracleインスタンス
• 共有メモリー
• バックグラウンド・プロセス
Oracleリスナー・プロセス
• 接続リクエスト受信
データベース
• ファイルの集合
189

View Slide

メジャーな言語をカバーマルチ・プラットフォーム接続可能なバージョン組み合わせ
Oracleクライアントからの接続
190
言語 API
C OCI, ODBC, ODPI-C
C++ OCCI
Java JDBC
.NET ODP.NET
Node.js node-oracledb
Python cx_Oracle
PHP OCI8, PDO_OCI
R ROracle
Erlang erloci
Perl DBD::Oracle
Ruby ruby-oci8
Rust rust-oracle
Go goracle, go-oci8
Julia Oracle.ji
クライアントサーバー
Windows x64
Linux x86-64
Solaris SPARC
Solaris x86
HP-UX
AIX
zLinux
Windows x64
Linux x86-64
Solaris SPARC
Solaris x86
HP-UX
AIX
zLinux
12c Release 2
11g Release 2
12c Release 1
12c Release 2
18c
19c
ある程度バージョンに幅がある
詳細はAppendix

View Slide

tnslsnr
Oracleインスタンスとネットワーク接続リクエストを受けるOracleリスナー・プロセスが独立している
(1) OracleクライアントはOracleリスナー・プロセスの保持
するTCPサーバー・ソケットに対して接続リクエストを発
行する。
(2) Oracleリスナー・プロセスがOracleサーバー・プロセスを
生成し、Oracleリスナー・プロセスが確立したTCPコネ
クションをOracleサーバー・プロセスに引き継ぐ。
(3) OracleクライアントのプロセスはOracleサーバー・プロ
セスとTCP接続する。
この接続形態を専用サーバー(Dedicated Server)接続
という。これが最も基本的な接続形態。
Oracle Databaseアーキテクチャ
Oracleインスタンス
• 共有メモリー
• バックグラウンド・プロセス
Oracleリスナー・プロセス
• 接続リクエスト受信
データベース
• ファイルの集合
oracle Oracleサーバー・プロセス
• SQL処理の主体
(1)
(2)
(3)
191

View Slide

Oracle Databaseサーバーの接続先を指定する記法
「サービス」に接続するという概念
接続記述子(Connect Descriptor)
• Oracle Netの全パラメータを指定することが可能な記法
• これをあらかじめ定義して別名をつけておくファイルがtnsnames.ora
簡易接続(EZCONNECT)
• Layer 4以下のプロトコルをTCP/IPに決め打ちし簡略化した記法
• 本番システムの高可用性構成(RACやData Guard)では使用しない
簡易接続プラス(EZCONNECT Plus) 19c以降
• EZCONNECTに接続記述子のパラメータを指定できるように拡張した記法
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = hostname) (PORT = port))
(CONNECT_DATA = (SERVICE_NAME = service) )
)
hostname:port/service
tnslsnr
service
TCP/IPサーバー・
ソケット
データベースの
ワークロードの
抽象概念
192

View Slide

Oracleクライアントは「サービス」に接続する
データベースのワークロードを抽象化した概念
サービス
service1
ノード1 ノード2
Oracleインスタンスの名前
• INSTANCE_NAME
• SID (ORACLE_SID)
データベースの名前
• PDB_NAME
• DB_UNIQUE_NAME
• DB_NAME
「サービス」とはデータベースのワークロードを抽象化し
た概念であり、Oracleインスタンスの名前でもなくデータ
ベースの名前とも異なる抽象概念である。
クラスタ・ノードの仮想化
共有ストレージ・共有キャッシュ型クラスタ・データベース
であるOracle Real Application Clustersは複数の
Oracleインスタンスが同じサービスを担当できるので、
Oracleクライアントからは「サービスに接続する」という概
念で複数ノード構成であることを仮想化している。
マルチ・テナント・アーキテクチャ
1つのOracleインスタンスが複数のプラガブル・データベー
ス(PDB)をホストしているが、PDBごとに異なるサービス
名があるので、Oracleクライアントは「サービスに接続す
る」という概念で接続するPDBを区別している。
PDB1 PDB2 PDB3
service2
service3
193

View Slide

「サービス」で接続するデータベースを区別する
プラガブル・データベース(PDB)ごとに一意なサービス名を持っている
各Oracleインスタンスはデータベースのワークロードを抽象
化した「サービス」という属性を持っている。コンテナ・データ
ベース(CDB)構成の場合はプラガブル・データベース
(PDB)ごとに一意なサービス名を持っている。
1つのOracleリスナー・プロセスが同一のTCP/IPポートで
複数のOracleインスタンスへの接続リクエストを担当でき
る。
Oracleリスナー・プロセスはどのサービスをどのOracleインス
タンスが担当しているかを把握している。
Oracleクライアントはサービス名を指定して接続リクエスト
を発行し、Oracleリスナー・プロセスはそのサービスを担当
する適切なOracleインスタンスにリクエストをルーティングす
る。
tnslsnr
Non-CDB1
Oracle
インスタンス1
Oracle
インスタンス2
service1 service2
Oracleリスナー・
プロセス
PDB2 PDB3
service3
CDB2
host:port/service1 host:port/service2
194

View Slide

標準機能で高可用性構成に対応
Oracle Net Servicesが持つ付加機能
195
接続ロード・バランス
RACの複数ノードに対して負荷分散
クライアント
接続に失敗したら別の接続先を試行
クライアント
コネクション・プール
接続確立処理の省略
oracle
pool
高速アプリケーション通知
クラスタウェアとコネクション・プールが連携
クライアント
pool

View Slide

RACにはクラスタを代表するSingle Client Access
Name (SCAN)リスナーがあり、どのサービスをどの
Oracleインスタンスが担当しているかを認識している。
サービスがアクティブになっているOracleインスタンスに接
続リクエストをリダイレクトして負荷分散する。
接続確立後はクライアント・プログラムとOracleサーバー・
プロセスはTCPコネクションで直結される。
RACの複数ノードに負荷分散
接続ロード・バランス
tnslsnr
Oracle
instance1
Oracle
instance2
tnslsnr
ノード 1 ノード 2
tnslsnr
service1 service1
tnslsnr
service1
instance1
instance2
(1)接続リクエスト発行
SCAN
リスナー
(2)リダイレクト
196

View Slide

データベース・サーバー側の高可用性構成に接続ドライバが対応
新規コネクション確立失敗時のフェイルオーバー
• 接続時フェイルオーバー
確立済みコネクション切断時の自動再接続と再実行
• 透過的アプリケーション・フェイルオーバー
• アプリケーション・コンティニュイティ(※)
197
tnslsnr
Oracle
instance1
Oracle
instance2
tnslsnr
service1 service1
tnslsnr
Oracle
instance1
Oracle
instance2
oracle
service1 service1
※Enterprise Edition RACもしくは
Active Data Guard

View Slide

接続確立処理の省略
クライアント側コネクション・プール
Oracle接続ドライバ側のコネクション・プール
• Universal Connection Pool for Java (UCP)
• OCI Session Pool
• ODP.NET
サーバー側コネクション・プール
Oracleクライアント側でプールできない場合の次善策
• Database Resilient Connection Pool
(DRCP)
• Oracleサーバー・プロセスをあらかじめ生成しておく
コネクション・プール
198
Oracle
instance1
Pool
oracle oracle
Oracle
instance1
App
oracle oracle

View Slide

Oracle Clusterwareとコネクション・プールの連係
Oracle ClusterwareとOracleクライアントのコネクション・
プール間に、SQL実行用コネクションとは別にイベント通
知用のコネクションを持つ。
高速接続フェイルオーバー
(Fast Connection Failover: FCF)
• サービスの起動及び停止、ノード停止イベントの
通知
• クライアントは停止したノードとのコネクションをTCP
タイムアウトを待たずに切断できる
ランタイム接続ロード・バランス
(Runtime Connection Load Balance: RCLB)
• サーバー側で最適な負荷配分を算出して通知
• プールされたコネクションから負荷配分を考慮して
SQLを実行するインスタンスを決める
高速アプリケーション通知(Fast Application Notification: FAN)
199
Oracle
instance1
Oracle
instance2
service1 service1
Clusterware Clusterware
Pool
FANイベント FANイベント
SQL実行用
コネクション
FAN用
コネクション

View Slide

200
外部表

View Slide

データベース内の表にあるデータと同様に、外部ソースのデータにアクセス可能
CREATE TABLE で宣言するだけで外部ソースをテーブルとしてアクセス可能
• 通常のテーブルと異なり実データをデータベース内に持たない
• データにアクセスするために表にデータを事前にロードしておく必要がない
• 外部ソースの変更は表の検索結果に即座に反映
外部表の概要
201
外部ソース
Oracle Database
外部表
SELECT * FROM
CUSTOMER_LIST
問合せ
Hive
HDFS
バイナリ
ファイル
テキスト
ファイル
CUSTOMER_LIST

View Slide

外部ソースにアクセスするためのインターフェイスとして
外部ソースをデータベース外から読み込む
データをロードするためのインターフェイスとして
外部ソースからCREATE TABLE AS SELECTや
INSERT文でデータを高速にロードすることが可能
複数のノードでパラレル処理を実行可能
外部表のユースケース
202
Oracle Database
外部表
Oracle Database
外部表
外部ソース実表
ロード
外部ソース

View Slide

外部ソースもハイブリッド・パーティションに利用可能
外部表の例①：ハイブリッド・パーティション
203
Oracle Database
Partition_2018
Partition_2019
Partition_2020
Partition_2021
Hybrid Partition表
テキスト
ファイル
テキスト
ファイル

View Slide

HDFSやApache Hiveに格納された外部ソースもハイブリッド・パーティションに利用可能
外部表の例②：ハイブリッド・パーティションとBig Data
204
Oracle Database
Hybrid Partition表
HDFS
Hive
Partition 1
Partition 2
Partition 3
Partition 4

View Slide

外部ソースを実表にロードするユーティリティ
• データベースとは異なるシステム上の外部ソースをネットワーク経由でロード可能
• 排除されたデータやエラーとなったデータは、OSファイルとして出力
SQL*Loader
205
外部ソース
SQL*Loader
Oracle Database
実表
ロード
Bad Files
Discard
Files

View Slide

206
データベース・リンク

View Slide

Oracle Databaseから他のデータベース上にあるスキーマ・オブジェクトへのアクセスを可能にする機能
クライアントが接続しているOracle Database (ローカル・データベース)上のオブジェクト(表など)と同様に
ネットワーク経由で他のデータベース(リモート・データベース)上の表に対して操作が可能
データベース・リンク(Database Link)
207
ローカル・データベースリモート・データベース
SELECT ～
FROM DEPT@Remote
WHERE ～
DEPT
クライアント

View Slide

分散トランザクションの実施
リモート表に対しても、ローカル表と同様に参照・更新を
同一トランザクションとして、処理可能
マテリアライズド・ビューとの連携
リモート・データベース(マスター・サイト)の
データをもとにマテリアライズド・ビューでデータを
ローカル・データベース(マテリアライズド・ビュー・サイト)に
複製可能
ローカル・データベースリモート・データベース
ユースケース
208
リフレッシュにより、
マスター・サイトの
データを反映
ローカル・データベース
UPDATE SALES@Remote ～;
INSERT INTO EMP ～;
COMMIT;
リモート・データベース
クライアント
データベース・リンク SALES
EMP
同一トランザクション
として処理

View Slide

209
マテリアライズド・ビュー

View Slide

概要
• サマリーとして集計結果を格納しておくスキーマ・オブジェクト
• 事前に集計処理した結果セットを保持しておくことで
検索処理時間の短縮を図る
• 特徴
• 参照先をマテリアライズド・ビューに透過的に変換する
クエリー・リライト
• 最新データを迅速に反映する高速リフレッシュ
マテリアライズド・ビュー(Materialized View: MVIEW)
210
事前集計済みのデータをSELECT
都度SELECT
遅い
高速!!
SELECT結果を事前に格納
売上集計
(マテリアライズド・ビュー)
都道府県
支店製品
日時
売上明細
CREATE MATERIALIZED VIEW 売上集計
AS
SELECT ～
FROM 売上, 製品, 支店, 日時
WHERE ～

View Slide

売上集計
都道府県
支店製品
日時
売上明細
• 発行されたSELECT文がマテリアライズド・ビューの定義と同義である場合に、
該当するマテリアライズド・ビューを参照させる機能
• アプリケーションの書き換えなしに検索処理を高速化
クエリー・リライト機能
211
オプティマイザクエリー・リライト
SELECT ～
FROM 売上、製品、支店、日時
WHERE ～
SELECT ～
FROM 売上集計
WHERE ～
マテリアライズド・ビューを
参照するよう自動変換
(クエリー・リライト)

View Slide

更新差分のみを適用することで迅速なリフレッシュが可能
• マテリアライズド・ビューをリフレッシュ(データ更新)することで、
元表の変更(データロード、挿入、更新、削除)を反映
• リフレッシュ・オプション
• リフレッシュのタイミング
• 元表に対するCOMMIT発行時
• 元表に対するDML実行時
• 手動実行(DBMS_MVIEWパッケージを利用)
• リフレッシュ方法
• 完全リフレッシュ(データを再集計)
• 高速リフレッシュ(差分更新、右図)
高速リフレッシュ
212
売上集計
売上明細
高速リフレッシュ
挿入
更新
マテリアライズド・ビュー・ログ
変更
差分

View Slide

214
Automatic Indexing

View Slide

パフォーマンスに対するアプローチ
性能に関する機能はDBのエキスパートの存在を前提としている
• エキスパート(DBA、開発者)が機能の使い方や使い時を理解していることが前提
• 担当者のスキルセットに大きく依存
• アドバイザリ機能を「いつ」、「どのように」活用し、「どのタイミング」でアドバイスを検証・実装するかはDBA任せ
Automatic Indexingは自動でDBのエキスパートと同等の索引チューニングが可能
• 自動で高度な索引チューニングを行うことで最高のパフォーマンスを低コストで実現
Automatic Indexing
215
従来の索引チューニング Automatic Indexing
*Autonomous Databaseを含む
Exadata上でのみ利用可能

View Slide

自動で絶え間なく索引チューニングを実行
手間のかかる索引チューニングをDBA不在でも実現
アプリケーション・ワークロードを監視して、自動的に索引
の作成や削除などの管理を行う
候補索引の識別、利用前の検証を行う
• 全プロセスが完全自動
• アプリケーション、DB設計を変更する必要なし
• 全てのチューニング・アクティビティがリポートより
監査可能
15分おきに左図のオペレーションが自動で実行され、
アプリケーション・ワークロードの性能向上に役立つ索引を
作成・検証・有効化・監視する
この機能により、単一索引、結合索引、ファンクション索
引、圧縮索引を作成する
Automatic Indexing
216
Capture
Identify
Verify
Decide
Online
Validation
Monitor

View Slide

Capture, Identify Candidates, Verify
1. Capture (取得)
• 定期的にアプリケーションのSQL履歴をSQLリポジトリに取得する
(SQL、実行計画、バインド変数、実行統計など)
2. Identify Candidates (候補索引の特定)
• アプリケーション・ワークロードに役立つ(性能向上する)候補索引を特定する
• 候補索引をunusableおよびinvisible状態にて作成(メタデータの変更のみ)
• 新たに作成された索引により不必要となった索引を削除(論理統合)
3. Verify (検証)
• オプティマイザに新たに作成した候補索引を使用するか確認
• 索引を作成し、SQLを実際に実行、新しい索引により性能向上がみられるか検証を行う
• 全ての検証はアプリケーション・ワークロードの外で行われる
Automatic Indexingの動作
217
Capture
Identify
Verify
Decide
Online
Validation
Monitor

View Slide

Decide, Online Validation, Monitor
4. Decide (索引の決定)
• 全てのSQLの性能が向上した場合、索引はvisibleとなる
• 全てのSQLの性能が低下した場合、索引はunusableになり、後に自動で削除される
• 一部のSQLの性能が低下するが、全体的に性能が向上する場合、索引はvisibleとなる
5. Online Validation (オンライン検証)
• 他のSQLに対する新たな索引の有効性検証はオンラインで継続
• 1セッションだけが新たな索引を利用することが許される
6. Monitor (監視)
• 索引の利用状況は継続的に監視
• 自動的に作成された索引は長期間利用されないと削除される
Automatic Indexingの動作
218
Capture
Identify
Verify
Decide
Online
Validation
Monitor

View Slide

制御可能な範囲
Automatic Indexingの利用
219
有効、無効の設定
自動索引削除の期間指定索引を作成する
表領域の指定
利用可能な表領域の
サイズ指定
スキーマ単位での有効/無効

View Slide

220
オプティマイザ統計

View Slide

オプティマイザとは
• 目的地へのルート探索と同じように、
データにアクセスするためのルートを選択する機能
• ルート探索の際に道路や交通の状況を考慮するのと
同様に、Oracle Databaseでは表の情報、データのば
らつき、システムの情報といった統計情報をインプットと
して最も処理時間の短い(コストの低い)実行計画を
選択する
オプティマイザの概念
221
A
B
1時間12分
58分
45分
①
②
③
ルート距離予想所要時間渋滞有無
① 21km 45分無
② 16km 58分有
③ 22km 1時間12分有

View Slide

データ変動に応じて適切な実行計画を選択するための情報
表、索引、データの種類、データ分布などのデータ特性を表す情報
オプティマイザはインプットの一部として統計情報を使用してコストを見積もり、最もコストの低い実行計画を選択する
データベースを運用する中で日々変化していくデータに対して、適切な実行計画に基づいてデータへアクセスするために
適切な統計をタイムリーに収集することが重要
222
SQLテキスト
オブジェクト構造
初期化パラメータ
Oracle Database
オプティマイザ
実行計画

View Slide

オプティマイザ統計の種類
223
種類主な構成内容オプティマイザによる利用のされかた
表統計行数、平均行長、データ・ブロック数表スキャンおよび表結合のコストを判断する
列統計
個別値の数、NULLの数、最小値/最大値、
ヒストグラム関連情報、拡張統計
正確なカーディナリティの見積もりを生成し、索引の使用、
結合順序、結合方法などについての決定を行う
索引統計
索引内の個別値数、リーフ・ブロックの平均数、
データ・ブロックの平均数、階層数
索引スキャンのコストを判断する
システム統計 CPUパフォーマンスと使用率、I/Oパフォーマンスと使用率
実行計画を選択する際に、
I/OおよびCPUコストをより正確に見積る

View Slide

オプティマイザ統計の収集方法
224
収集方法概要
自動オプティマイザ統計収集
実データの変動をOracle Databaseが適切に認識するために、
定期的にオプティマイザ統計を新しい情報に自動更新する収集方法
高頻度自動オプティマイザ統計収集
デフォルトで15分ごとにオプティマイザ統計を収集することで、
自動オプティマイザ統計収集を補完するExadata専用機能
データが頻繁に更新されるデータベースでも適切な統計を収集することが可能
オンライン統計収集 DDLおよびDML操作によって自動的にトリガーされる統計収集方法
処理をきっかけとして統計収集を行うため、データが頻繁に更新されるデータベースでも適切な統計を収集可能
オプティマイザ統計の手動収集 DBMS_STATSパッケージを使用することで、自動統計収集の代替または補足として、オブジェクト、スキーマ、
データベースなどの様々なレベルに細分化してオプティマイザ統計を手動収集することが可能

View Slide

統計がない、または統計が古いデータベース・オブジェクトのオプティマイザ統計を、
事前定義されたメンテナンス時間枠で自動収集
デフォルトでは、各曜日に対応するメンテナンス時間枠が設定されている
• 月曜日～金曜日：22時から翌2時まで
• 土曜日・日曜日：6時から翌2時まで
必要に応じて自動メンテナンス・タスクを無効にしたり、メンテナンス時間枠を変更することが可能
自動オプティマイザ統計収集
225
22:00 02:00
実行イメージ
:自動統計オプティマイザ統計収集の実行時間

View Slide

• オプティマイザ統計を高頻度に収集(デフォルトで15分毎)するExadata専用機能
• 古い統計(10%を超える変更)のみを収集する軽量タスク
• データが頻繁に更新されるデータベースでも適切な統計を収集することが可能
• 制御可能な範囲は以下の通り
• 有効、無効の設定(デフォルトは無効)
• 最大実行時間
• 実行間隔
高頻度自動オプティマイザ統計収集
226
22:00 02:00
:自動統計オプティマイザ統計収集の実行時間
:高頻度オプティマイザ統計収集の実行時間
実行イメージ

View Slide

DDLおよびDML実行時にオプティマイザ統計を収集する
表への更新をきっかけとして統計収集を行うため、データが頻繁に更新されるデータベースでも適切な統計を収集可能
• バルク・ロードのためのオンライン統計収集
• バルク・ロード中に統計を収集する(デフォルト無効)
• パーティション・メンテナンス操作のオンライン統計収集
• 以下のパーティション操作中に統計を収集する
MOVE, MERGE, COALESCE
• リアルタイム統計(Exadata専用)
• DML (INSERT/UPDATE/MERGE)操作の一部として統計を収集する
• 行数、最小値、最大値といった最も重要な統計のみが収集される
オンライン統計収集
227

View Slide

DBMS_STATSパッケージを使用することで、自動統計収集の代替または補足として、オブジェクト、スキーマ、
データベースなどの様々なレベルに細分化してオプティマイザ統計を手動収集することが可能
手動で統計を収集する必要がある例
• 自動メンテナンスタスクの実行まで待機することができない場合に、任意のタイミングで統計を収集したい
• CPUの高速化、メモリーの増設、ディスク記憶域の交換など、
環境に物理的な変化が生じたときにシステム統計を収集したい
オプティマイザ統計の手動収集
228
プロシージャ収集対象
GATHER_INDEX_STATS 索引統計
GATHER_TABLE_STATS 表、列および索引の各統計
GATHER_SCHEMA_STATS スキーマのすべてのオブジェクトの統計
GATHER_DICTIONARY_STATS
SYSやSYSTEMなどのすべてのシステム・スキーマのほか、CTXSYSやDRSYSなどの
オプション・スキーマの統計
GATHER_DATABASE_STATS データベース内ですべてのオブジェクトの統計
GATHER_SYSTEM_STATS システム統計

View Slide

229
サーバー結果キャッシュ

View Slide

Oracle Databaseインスタンス
繰り返し実行される問合せのレスポンスを向上
SQL問合せ結果キャッシュ
• SQL問合せの結果セットを共有プールに格納
• ブロックの再読取りおよび結果の再計算という多くのリソースを消費する操作を行う必要がなくなる
• 結果の構成に使用されているデータの更新が行われた場合、そのキャッシュは自動的に無効化される
PL/SQLファンクション結果キャッシュ
• ファンクションの結果セットを共有プールに格納
230
ORDERS
ORDER_ITEMS
PRODUCT_INFORMATION
CUSTOMERS
SQL問合せ結果キャッシュ
キャッシュ済みの結果が
返され、高速レスポンス
1. SELECT 2. SELECT
初回アクセス時に
SQL問合せの結果
セットをキャッシュ

View Slide

SQL問合せ結果キャッシュ使用方法
RESULT_CACHEヒントを使用して問合せまたは問合せ断片にヒントを付け、結果をSQL問合せ結果キャッシュに保存す
ることを指定
※ RESULT_CACHE_MODE初期化パラメータを変更することによって、ヒントを付けなくてもSQL問合せ結果がキャッシュされるように
変更可能です。しかしながら、すべての問合せをキャッシュするためメモリーの枯渇にご注意ください。
231
SELECT /*+ RESULT_CACHE */ department_id, AVG(salary)
FROM hr.employees
GROUP BY department_id;

View Slide

232
Memoptimized Rowstore

View Slide

高頻度な単一行挿入処理を最適化
例: 測定温度の書込み遅延挿入による高速収集
• ラージ・プールに一時的にバッファリング
• 非同期のストレージ書き込み
• ストレージに書き込むときに変更を自動的にコミット
使用方法
• 表に対してMEMOPTIMIZE FOR WRITEを宣言
し、INSERT文でMEMOPTIMIZE_WRITEヒントを
指定
• 特殊な列や索引などがある表では使用できない
• 圧縮、列デフォルト値、列暗号化、ファンクション索引、
ビットマップ索引、未使用列、仮想列、LOB、トリガー、外
部キー、ネストした表、索引構成表、外部表など
Memoptimized Rowstore – 高速収集
233
ラージ・プール
IoT Client
非同期の
ストレージ
書き込み
バッファに
書き込み
収集バッファ
時刻温度
05:50 52o
05:55 54o
06:00 54o
06:05 55o
INSERT into temp
VALUES(‘6:05’, 55)

View Slide

高頻度な問合せのパフォーマンスを高速化
例: Joeの残高照会ハッシュ索引による高速な主キー参照
• Memoptimizeプールにデータとハッシュ索引を格納
使用方法
• Memoptimizeプールを有効化し、表に対して
MEMOPTIMIZE FOR READを宣言
• 制限事項
• 表は圧縮できない
• 主キー制約を有効にする必要がある
Memoptimized Rowstore – 高速参照
234
Memoptimizeプール
50
Hash Index Buffers
CUST ID NAME BAL
5 Jack 12
1 Ying 76
31 Joe 32
12 Maria 31
SELECT bal FROM balance
WHERE cust_id = 31
Client

View Slide

Flashback Technology
235

View Slide

過去のデータにアクセスする機能
Flashback Database
Flashback Logを利用し、データベースをリストアポイントや時間
/SCN指定で巻き戻す機能
物理的なリストア、リカバリ操作無しにデータベースを過去の状態
に戻す事が可能
• 通常のリストアポイントの利用
• 保証付きリストアポイントの利用
Logical Flashback
表・トランザクションなどを対象に過去データの参照だけでなく、ト
ランザクションの巻き戻しなども可能な機能
Flashback Technology
236
機能名解説
Flashback Query 過去データの検索が可能
Flashback Version Query 過去データの各バージョン(データ)を取得可能
Flashback Transaction Query トランザクションおよびメタデータ・履歴データを取得可能
Flashback Transaction オンラインでのトランザクションロールバックが可能
Flashback Data Archive 表に対する全トランザクションを追跡および格納可能
Tx

View Slide

概要の理解
Flashback Database
238
ミス! 30分前に戻りたい …
Flashback Database TO TIME “戻したい時間”
 リストアポイント
(戻したい地点の設定)
 SCN
(戻したい変更点へ)
 時間
(戻したい時間へ)
例えば30分前に巻き戻し
(Flashback Logの適用)
Flashback
Flashback 未設定の場合は、
従来のリストア、リカバリを実施する
Flashback Logの
取得

View Slide

リストアポイントについて
Flashback Database
239
種類解説
リストアポイント無し Flashback Database Windowと呼ばれる巻き戻し可能範囲内で戻る
通常のリストアポイント制御ファイル内に記録された巻き戻す時点(SCN)情報(自動的にエージアウトされる)
保証付きリストアポイント制御ファイル内に記録されたエージアウトされない巻き戻す場所(SCN)情報
これ以降であれば任意の時点へFlashbackが可能
ただし、高速リカバリ領域が枯渇すると、エラーとなるので注意(ORA-19809、ORA-19804)
Flashback Log
変更される前の状態を保持
(高速リカバリエリア内)
Flashback Database Window
リストアポイントまたは
保証付きリストアポイント

View Slide

Flashback Databaseの使用について
• Flashback Databaseの有効化
• 高速リカバリ領域の設定とFlashback Databaseの有効化が必要
Flashback Database
240
高速リカバリ領域関連パラメータ
初期化パラメータ必須説明
DB_RECOVERY_FILE_DEST_SIZE Yes ディスク割当て制限を指定します。ディスク割当て制限は、この
データベースのリカバリ領域で使用されるデータの最大格納量を
バイト単位で示したもの
DB_RECOVERY_FILE_DEST Yes リカバリ領域の場所を指定します。ファイル・システム上のディレク
トリまたはASMディスク・グループを指定
DB_FLASHBACK_RETENTION_TARGET No データベースをFlashbackできる時点の上限(分)を指定します。
このパラメータは、Flashback Databaseでのみ必要
SQL>ALTER DATABASE FLASHBACK ON; ALTER DATABASE FLASHBACK OFF;

View Slide

Flashback Databaseと性能について
• 最適なFlashback Databaseのパフォーマンスのための環境の構成
• 高速リカバリ領域のI/O性能に大きく影響されるので、可能な限り高性能な環境を準備する
• 十分なディスク・スピンドルを準備する、または非揮発性RAMなどを採用するなど
• Flashback Databaseのパフォーマンスに対する影響の監視
• AWRレポート/スナップショットの情報 (flashback buf free by RVWR)のチェック
• V$FLASHBACK_DATABASE_STATビュー
• V$SYSSTATビュー
Flashback Database
241
列名列の意味
physical write I/O request データ・ブロックの書込みのために発行された書込み操作の数
Physical read I/O request データ・ブロックの読取りのために発行された読取り操作の数
Redo writes REDOログへの書込みのために発行された書込み操作の数
Flashback log writes Flashback Logへの書込みのために発行された書込み操作の数
Flashback log write bytes このインスタンスから書き込まれたFlashback Databaseデータの合計バイト・サイズ

View Slide

制約および留意点
• メディア障害の修復またはデータファイルの誤った削除からのリカバリには使用できません
• データファイルの縮小操作を元に戻すことはできません
• Flashback Databaseのみを使用して、削除されたデータファイルを回復することはできません
• 制御ファイルがバックアップからリストアされるか、または再作成されると、すべての累積Flashback Log情報が破棄されます
• Flashback Databaseを使用して、制御ファイルのリストアまたは再作成が行われたときより前に戻すことはできません
• NOLOGGING操作が行われていたターゲット時刻を指定してFlashback Databaseを使用すると、NOLOGGING操作の影響
を受けたデータベース・オブジェクトとデータファイルのブロックが破損している可能性があります
• NOLOGGING操作と同時の目標時点またはSCNでFlashback Databaseを使用することを避けてください
Flashback Database
242
https://docs.oracle.com/cd/F19136_01/bradv/using-flasback-database-restore-points.html#GUID-28EB12CA-6E98-4ED4-A798-1326E4A938AB

View Slide

Multitenant ArchitectureとFlashback Database
CDB単位でのFlashback Database PDB単位でのFlashback Database
Flashback Database
243
CDB 全体をFlashback
プラグされているPDBもFlashbackされる
(CDB ROOTでリカバリポイントを持つ)
特定のPDBのみをFlashback
(PDBごとにリストアポイントを持つ)

View Slide

Flashback機能概要
• 自動UNDO管理により格納されたトランザクションに関するメタデータおよび履歴データが利用される
• Flashback 機能の利用範囲(期間)はUNDO表領域のサイズに依存する
Logical Flashback
244
※ 参考
PDB個別にUNDO表領域を構成可能

View Slide

自動UNDO管理について
Database Configuration Assistant(DBCA)を使用してデータベースを作成すると、
自動拡張可能なUNDO表領域が自動的に作成される
• UNDO管理用の初期化パラメータの概要
• 動的パフォーマンス・ビュー: V$UNDOSTAT
Flashback機能
245
初期化パラメータ
UNDO_MANAGEMENT AUTOまたはNULLの場合は、自動UNDO管理が使用可能
MANUALの場合は、手動UNDO管理モードとなる (デフォルトはAUTO)
UNDO_TABLESPACE 自動UNDO管理モードの場合のみ有効(オプション)でUNDO表領域の名前を指定する
データベースに複数のUNDO表領域があり、データベース・インスタンスで特定のUNDO表領域を
使用するように指定する場合にのみ使用
UNDO_RETENTION 最小UNDO保存期間(秒単位)を指定
現行のUNDO表領域に十分な領域がある場合にのみ有効

View Slide

Flashback機能(アプリケーション開発機能あるいは管理者向け機能)
Flashback機能
246
機能名解説特記事項
Flashback Query 過去のある時点で存在していたデータを取得可能本資料内で解説
Flashback Version Query 特定の時間間隔に存在した、特定の行の各バージョン(データ)を取得可能
Flashback Transaction Query 特定の時間間隔内における特定のトランザクションまたはすべてのトランザク
ションのメタデータおよび履歴データを取得可能
Flashback Transaction データベースがオンラインである間にトランザクションおよびその依存トランザク
ションをロールバック可能
DDL操作、LOBデータなど一部で
制約あり
Flashback Data Archive 存続期間中、表に対する全トランザクションの変更を追跡および格納可能本資料内で解説
一部の表構成で制約あり

View Slide

Flashback Queryの使用例
Flashback機能
247
現在のデータ
2020-12-04 14:30:06 のデータ
過去のデータ
Tx

View Slide

Flashback Data Archiveとは
Flashback Data Archiver プロセス(FBDA)は、存続期間にわたって表に
対するトランザクションの変更を追跡し、格納できる機能を提供する
これにより、表をいつでもFlashbackして、元の状態にリストア可能
オブジェクトと維持条件を指定し有効化する事で、意識的に過去データを
利活用できる
使用例：
デフォルトのFlashback Data Archive fla1を作成
(最大10GBの表領域tbs1を使用し、データは5年間保持)
CREATE FLASHBACK ARCHIVE DEFAULT fla1 TABLESPACE tbs1
QUOTA 10G RETENTION 5 YEAR;
表inventoryおよびstock_dataのFlashback Data Archiveを有効にし
て、デフォルトのFlashback Data Archiveに履歴データを格納
ALTER TABLE inventory FLASHBACK ARCHIVE;
ALTER TABLE stock_data FLASHBACK ARCHIVE;
2007年の年初にすべての品目の在庫を取得する問合せ
SELECT product_number, product_name, count
FROM inventory
AS OF TIMESTAMP TO_TIMESTAMP ('2007-01-01 00:00:00',
'YYYY-MM-DD HH24:MI:SS');
Flashback機能
248

View Slide

Flashback機能(データベース管理機能)
Flashback機能
249
機能名解説特記事項
Flashback Table 表を以前の状態にリストアできる
TO SCN句、TO TIMESTAMP句、TO RESTORE POINT句などが利用可
能だが、システム内のUNDOデータ量に依存する
DDL操作済みのものは対応不可
Flashback Table処理はロール
バックできない
Flashback Drop Flashback TableにTO BEFORE DROP句を使用し、Drop Table文を無
効化できる
Flashback Database 前述のとおり

View Slide

250

View Slide

View Slide

Oracle Database 機能概要

Oracle Database 機能概要

oracle4engineer
PRO

More Decks by oracle4engineer

Featured

Transcript

Oracle Database 機能概要

Oracle Database 機能概要

oracle4engineer PRO

More Decks by oracle4engineer

Featured

Transcript

oracle4engineer
PRO