Oracle Database 12c エディション比較-SE/EEの …...第1回どさんこオラクル勉強会 Oracle Database 12c エディション比較-SE/EEの違い、Enterprise Editionで

第1回どさんこオラクル勉強会

Oracle Database 12c エディション比較-SE/EEの違い、Enterprise Editionでできること

Presented By シーズ・ネクスト 2015年10月28日

Copyright © 2015 Oracle & C’sNEXT Co.,Ltd. All rights reserved.

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


Oracle Databaseの進化時代の必要性に合わせた機能拡張

3

‘92 ‘97

Oracle7 パラレルクエリ

Oracle8 パーティション

表

Oracle8i コンポジットパーティション

FGA(セキュリティ) Java/XML対応

Oracle9i

RAC

Data Guard

Oracle 10g

EM Grid Control

Clusterware

ASM

Oracle 11g

DB Vault

Audit Vault

自動チューニング

テスト支援

データ圧縮エンタープライズシステム

大規模DB 対応

インターネット対応

ミッションクリティカル対応

エンタープライズグリッド

利便性・安全性強化

可用性と拡張性を両立するクラスタ技術と災害対策機能の実装

システム統合を実現するグリッド技術によるオープン化促

進

大規模データ管理と標準技術の採用

セキュリティ強化と運用最適・効率化による

データ管理コストの最適化を実現

様々なデータ活用ニーズに革新的な基盤ソリューション

を提供

クラウド時代

Oracle Exadata

Smart Scan

コモディティ機器

Infiniband

超並列データ処理

列圧縮

HW暗号

大規模データ超高速処理統合基盤

Oracle 12c マルチテナント・データベース Consolidation

Replay Heat Map

Automatic Data Optimization

Data Redaction

マルチテナント・アーキテクチャを

始めとする、データベース・クラウド実現に必要な機能強化

データベース・クラウド基盤

‘99 ‘01 ‘03 ‘06 ‘09 ‘13

Oracle Databaseの起源 •1977年:ラリー・エリソンが創業 •1977年:CIAのプロジェクト”Oracle”を受注 •1979年:Version2を初の商用RDBMSとしてリリース


Standard Edition と Enterprise Edition

• Standard Edition

– 部門システム等に利用

– 求められる要件が低いシステムを、手ごろな価格で構築可能

– 使用できる機能、 CPUソケット数等に制限あり

• Enterprise Edition

– 性能、可用性、セキュリティ等を重視するシステムに不可欠な機能

– オプションにより個別の要件に柔軟に対応可能

4

Standard Edition

Enterprise Edition


Enterprise Editionの利用による課題解決例

運用項目 Standard Edition Enterprise Edition

バックアップオンラインバックアップの取得（データ量が多くなれば時間もかかる…）

高速増分バックアップ機能で高速にバックアップ（データ量が多くなってもバックアップ時間を最小に）

監視

領域監視スクリプトで定期的に情報取得（管理者が手動で実行/分析する必要…）

しきい値を設定し、領域が不足する前にアラート通知（手動監視をしなくても領域問題を速やかに検知）

性能監視 CPU使用率やメモリヒット率の確認（管理者が手動で実行/分析する必要…）

監視に必要な情報が自動収集＋性能劣化時に通知（手動監視をしなくても性能問題を速やかに検知）

構成監視 OSやDBの情報をExcel等で個別管理（管理漏れ等により、トラブル解決が長引く…）

ホスト/OS/データベースの構成情報の自動取得（漏れなく情報を収集し、トラブル時速やかに原因究明）

チューニング

再現を待ってボトルネックを特定インフラ担当へ連絡→インフラチューニング開発担当へ連絡→SQLチューニング（原因の特定に時間がかかる）（各担当に個別に依頼しなければならない）

自動チューニング機能でボトルネックを自動診断＋通知（GUIで問題のSQLを特定して改善アドバイスを取得）（アプリケーションを変えることなく性能を改善）

5

※1 Forrester Research, The TEI of Oracle Enterprise Manager Database Management Packs

122% 3年間でのROI

81%削減

DBAの作業時間

※弊社データセンターにおける実績値

1/18 に削減

バックアップ時間 ※1


Program Agenda

1

2

3

4

パフォーマンスを向上させる機能

可用性を高める機能

データの統合（Consolidation、Integration）

データベース・セキュリティ

運用管理、保守

6

5


パフォーマンスを向上させる機能

7


データベースの性能問題に関する近年の傾向

8

CPUがボトルネックだったケースは、わずか9%（*弊社統計）

マルチコアを使いきることができておらず、ストレージI/Oや非効率なSQLがボトルネック

*データ：Oracle Directが直近で実施したパフォーマンスクリニックの結果より

性能ボトルネックの原因の傾向

CPU：9%

ストレージI/O： 43%

非効率なSQL文、索引の設計等：48%

非効率なSQLが多い

ストレージI/Oがボトルネック

効率的な監視による問題点の検出と改善パラレル処理でCPUを効率よく使う

物理読み込み量を削減する

Enterprise Manager（EM）

パラレル処理

Oracle Partitioning

Compression


パラレル処理バッチ処理などの時間のかかるSQL処理を高速化 Enterprise Editionでは、1つの処理をパラレル（複数CPU）で実行可能

9

パラレル処理（EE）

1つのSQLは単一プロセス（CPU）で処理 CPUコアを追加しても、「単一のSQL文」の処理速度向上は期待できない

1つのSQLを複数プロセスを使用して実行複数のCPUコアを有効に活用することが可能

シリアル処理（SE）

Enterprise Edition


パラレル処理パラレル処理の進化と効果

• インメモリパラレル処理（11gR2~） –共有メモリを利用したより高速なパラレル処理が可能に

•自動パラレル度設定 – SQL毎に必要とするデータ量とストレージ能力を照らし合わせて、パラレル度を自動決定

10

40X

10X

6000万件(13GB)のデータの集計処理が • パラレル処理で、約10倍高速 • インメモリパラレル処理で約 40倍高速

Enterprise Edition


パーティショニング大量データ/長期間のデータ保持を効率化

• データ量の増加による性能劣化の抑止

• 統計収集やバックアップ等のメンテナンス時間短縮

11

パーティショニング有り

データ量が増えると、検索時のアクセス対象も増大（I/O増加）

必要なパーティション表だけにアクセス DiskI/Oを削減し、性能を向上

パーティショニング無し

Enterprise Edition Partitioning Option


パーティショニング Oracle Partitioningの効果

• データの検索範囲に合わせて表を分割検索時にアクセスする範囲が限定され検索性能が向上（例）月単位で分割して、直近のデータのみにアクセス（例）契約会社ごとにデータを分割、自社のデータのみにアクセス

• 運用（バックアップや統計取得）をパーティション単位で実施可能

12


処理時間の検証


データ圧縮 Oracle Advanced Compression

•格納データ量：約1/2から1/3（ストレージ容量の節約）

• ディスクI/O量が減り、性能向上

13

検索処理時間の検証

検索処理における処理時間の内訳イメージ

更新処理における処理時間の内訳イメージ

更新処理時間の検証

非圧縮環境非圧縮環境

圧縮環境圧縮環境

更新のオーバーヘッドもほとんどない

■CPU時間 ■I/O時間

検索の処理時間が大幅に短縮

■CPU時間 ■I/O時間

Enterprise Edition Advanced Compression Option


【参考】パラレル実行のパフォーマンス結果

• SE 24コアとEE2コアでパフォーマンスを比較 –約100GBのテーブルから１ヶ月の受注Top10を分析するSQLを実行

• EEのパラレル実行+EE Optionの効果で処理を大幅に高速化

14

0 50

100 150 200 250

SE 24コア EE 2コア RAC 4コア RAC 4コア + Partitioning

RAC 4コア + Part/Advanced

Comp

処理時間

(

s

e

c)


結果キャッシュ問い合わせ結果をキャッシュに保存し、検索性能の性能向上

• SQL問合せの結果とPL/SQLファンクションの結果をメモリ領域に格納

• 問合せおよびファンクションが繰り返し実行される場合、その結果をキャッシュ・メモリーから直接取得することで、レスポンス時間を高速化

15

Inventory

Back Orders

Line Items

Pick Lists

Orders

従来のキャッシュ

結果キャッシュ

Inventory

Back Orders

Line Items

Pick Lists

Orders

読み込みブロック全体をキャッシュ

SQL検索結果のみキャッシュするため、読み取りがより高速

結果

Enterprise Edition


結果キャッシュの活用検証 PL/SQLファンクション結果キャッシュの活用による再帰処理の高速化

16

商品マスター表（10,000件）から単一商品の価格を取り出すファンクションを100,000回実行

100.00

50.57

0

20

40

60

80

100

120

なし

あり

結果キャッシュなし結果キャッシュあり

□PL/SQLファンクション結果キャッシュ設定例（商品マスター表から単一商品の価格を取り出すファンクション）

create or replace function get_price(v_prod_name in varchar2) return number result_cache relies_on(test.prod_tbl) as v_prod_price number(10); begin select price into v_prod_price from prod_tbl where prod_name = v_prod_name; return v_prod_price; end get_price;

□ 実行時間の比較(結果キャッシュなしを100とした場合)

結果キャッシュの活用により、実行時間を削減

Enterprise Edition


集計処理の高速化マテリアライズド・ビュー(MVIEW)およびクエリー・リライト

• 複雑な集計や結合処理の結果を予め保持、データの集計分析処理性能を向上

• クエリー・リライト機能により、アプリケーションの改修の必要なし

– 実表に対する問い合わせが自動的にMVIEWを参照するよう書き換えられる

17

Enterprise Edition

集計・結合結果を MVIEWとして作成

表A 表B

受注集計(MVIEW)

Select ～ From 表A,表B Where ～

Select ～ From 受注集計 Where ～

クエリーリライトでMVIEW参照に自動書き換え

受注の集計をしたい…

更新データは、高速リフレッシュで差分のみ適用可能


複数のSELECT結果のマージの実行時間短縮 Union（ALL）での各SELECTの同時実行 • リモート表（DBLINK経由）が対象の場合、特に大きな効果が見込まれる

18

DB12c EE ~ DB11g

12c EE： 30+α 秒

Union （ALL）検索

それぞれのSELECTはシリアル実行（個々のSQLはパラレル化可能）

~ 11g： 10+20+30+α 秒

10秒かかる 20秒かかる 30秒かかる

Union （ALL）検索

複数のSELECTを同時に実行可能に

10秒かかる 20秒かかる 30秒かかる

Enterprise Edition


システムの処理によって選択できる索引の種類 OLTPに適したBツリー索引／DWHに適したビットマップ索引

Bツリー索引ビットマップ索引

カーディナリティの高い（種類の多い）列に適している

カーディナリティの低い（種類の少ない）列に適している

ORを使用した検索にはそれほど適していない

OR条件などのビット演算による高速な検索を行うことが可能

更新のオーバーヘッドが大きい更新のオーバーヘッドが非常に大きい

OLTP向き DWH向き

索引のサイズ比較的大きい索引のサイズ比較的小さい

標準機能 EEのみ

19

Enterprise Edition

1～40

1～20 20～30

1..10 11..20 21..30 31..40

ROWID 男女

ID1 1 0

ID2 0 1

Bツリー索引のイメージ

ビットマップ索引のイメージ

• EEなら、より効率的に索引のメンテナンスを実現可能！ • オンラインでの索引再ビルドおよび索引構成表編成 • 索引作成および再ビルドのパラレル実行

索引再構築や再作成に時間がかかり、夜間メンテナンス

が終わらない・・・


DWHシステムでのビットマップ索引の効果活用例：売上表と顧客表に基づいた購買分析

20

Enterprise Edition

列値の種類

ID ユニークな数値

名前ランダムな文字列

性別男/女

地域 5地域

列値の種類

ID ユニークな数値

ユーザID 顧客表のIDに紐づくID

購買日日付

商品 6種類

顧客表 30万件約24MB

売上表 50万件約40MB

Bツリー索引もしくはビットマップ索引を作成

顧客表と売上表を結合したビットマップ結合索引を作成

0.29

1.00

0.19

1.00

ビットマップ索引

Bツリー索引 INDEX

ビットマップ索引

Bツリー索引 INDEX

索引サイズ(相対比)

Bツリー索引 (性別)

ビットマップ索引 (性別)

Bツリー索引 (地域)

ビットマップ索引 (地域)

CREATE BITMAP INDEX bitmap_join_idx ON 売上表(顧客表.性別,顧客表.地域) FROM 売上表 ,顧客表 WHERE 売上表.ユーザID= 顧客表.ID

ビットマップ索引はコンパクト！


DWHシステムでのビットマップ索引の効果活用例：売上表と顧客表に基づいた購買分析

21

Enterprise Edition

100%

62.9

% 30.5%

100%

62.58%

2.42% 0%

20%

40%

60%

80%

100%

120% 時間

物理読込

フルスキャンビットマップ索引

ビットマップ結合索引

2.関東に住む女性の購買分析

100%

61.5%

0.7%

100%

16.72%

0.04% 0%

20%

40%

60%

80%

100%

120%

フルスキャンビーツリー(gender/area) ビットマップ(gender/area)

時間

物理読込

1.関東に住む男女比の分析

フルスキャン Bツリー索引ビットマップ索引

表の結合を含む分析の場合は、ビットマップ結合索引を使用することで改善！

Bツリー索引では改善しきれない性能が、ビットマップ索引を使用することで、大幅改善！


事後対応可能な性能監視 Oracle Enterprise Manager （Diagnostics Pack）

22

Enterprise Edition Enterprise Manager Diagnotistic Pack

Enterprise Managerがあれば！

一般的に必要な監視項目は事前設定、自動情報収集済み • 過去の情報も遡って確認可能 • 事前定義済みしきい値により、アラート通知

様々なツールやコマンドを駆使して管理・監視 • 情報の収集に手間と時間がかかる • 十分な情報収集がなく、問題発生時に困ることが多い • 収集した情報のグラフ化、レポート化のコスト

Enterprise Managerがないと…


性能監視自動情報収集、アラート通知 • データベースの監視に必要な稼動情報（メトリック）を自動的に収集・保存

• 監視項目（メトリック）に対し「しきい値」を設定、管理者にアラート通知可能（メール通知も可能）

• 障害分析用の履歴データやキャパシティプランニングにも活用可能

23

Enterprise Edition Enterprise Manager Diagnotistic Pack

メトリックの例

■運用管理データベースの稼動確認リスナーの稼動確認アラートログの定常監視 ■領域管理表領域の空領域監視 ■性能 CPU使用率の監視メモリ使用量の監視 DISK I/O性能の確認アクティブセッション数の確認

しきい値を超えるとアラートが発生履歴データも簡単に参照可能

「警告」と「クリティカル」の 2段階のしきい値

アラート発生時に自動的に実行する処理の定義


性能改善チューニング・アドバイザ機能

24

Enterprise Edition Enterprise Manager Tuning Pack

Enterprise Managerがあれば！

SQLチューニングに必要な多くの作業を自動化できる •パフォーマンス画面から非効率なSQL文を特定 • 「チューニング・アドバイザ」を使ってアドバイスを取得 • アプリケーションを変更することなく、チューニング可能

SQLのチューニングには、複雑な調査と時間が必要 • 非効率なSQL文を見つけるために、処理を再現 • 非効率なSQLを特定 • 非効率なSQLの実行計画を取得し、分析（専門家に依頼） • SQL文を変更（アプリケーション変更）

• チューニングの効果を測定（十分な効果を得られなかった場合には、再度SQL文を分析）

Enterprise Managerがないと…


性能改善チューニング・アドバイザ（例）SQL文のチューニングの手順

25


アドバイスボタンをクリック

リアルタイムで負荷状況を確認（過去にさかのぼって確認可能）

負荷の高いSQL文やセッションを特定可能

アドバイスと効果。実装したい項目をクリック


性能改善リアルタイムSQL監視によるチューニングの効率化

• 時間のかかるSQLを自動的に取得/表示、処理の進捗状況や処理時間の内訳を確認可能

• チューニングに必要な情報をまとめて保存、チューニング担当者に送付可能

26


各ステップごとの実行タイミングや実行時間、待機イベントの発生個所などが分かる

「今ここ！」マークで、現在どの処理が実行されているかが分かる

進行状況がわかるため、「あとどれくらいでバッチ処理が終了するか」等の見当をつけられる


パラレル処理による性能改善例

27


チューニングの例（シリアル実行）

表のフルスキャンにより13GBのI/Oが発生

16スレッド(4コア×2CPU×HT)利用できるのにもかかわらず、1スレッド分も使い切れていない

I/Oスループットはわずか30MB/sほど


チューニングの例（パラレル処理に変更）

CPU使用効率は改善(平均5スレッド程度) 、ストレージのボトルネックにより、まだ空きリソースがある

今回のストレージの最大性能である350MB/sほどに達している

パラレル化されたことで所要時間が改善された

しかし、引き続き13GBのディスクI/O発生

パラレル化されている


チューニングの例（インメモリ・パラレル処理化）

I/Oが無くなったため、I/Oスループットのグラフも空に

In-Memory PXにより、I/Oが無くなった！


効率的なデータの保存管理(ILM) アクセス頻度などのサービスレベルに応じたデータの分割管理

• パーティショニングとCompression による、データの効率的な管理

（例）古いデータを「パーティションごと削除」、「高圧縮領域に移動」、「読み取り専用にして定期バックアップから除外」

31


Advanced Compression Option

ハイエンドストレージ層

ローコストストレージ層

オンラインアーカイブストレージ層

オフラインアーカイブ

高アクセス低アクセス履歴データアーカイブ

Q4 Q4 ４年前

新年度 Q1

Q1 Q4 Q3 Q2 1年前

･･････

パーティショニング

データ圧縮 4年前以降


データの移動・圧縮の自動化適切な対策を適切なタイミングで実施

• Heat Map機能 –データへのアクセスパターンを内部的に記録（アクセスが最後に発生した日時など）

• Automatic Data Optimization機能 – ILMアクション（圧縮／移動）の自動化

–タイミングをポリシー設定

–アクセスパターン（Heat Map情報）を利用

32

Enterprise Edition Advanced Compression Option

ALTER TABLE sales ILM ADD CompressionPolicy COMPRESS Partitions for Query AFTER 90 days from creation;

ALTER TABLE sales ILM ADD MovePolicy TIER Partitions TO ‘Archive_TBS’ AFTER 180 days of no modification;

Policy1: 作成から90日後経ったら圧縮

Policy2:180日以上変更がなければアーカイブ


可用性を高める機能

33


データベース・システムの停止の種類

停止の種類原因説明

計画外停止サイト障害 •停電、自然災害、テロ、悪意ある攻撃 •サイト全体のNetwork障害

クラスタ障害 •クラスタ内の全サーバー停止 •インターコネクト全障害、クラスタウェア障害

ノード（サーバ）障害

•ハードウェア、NIC障害 •OS障害、インスタンス障害

ストレージ障害 •ディスクドライブ障害 •ディスクコントローラ障害

データ破損、書込み欠落

•OS、ストレージデバイスドライバ障害 •ソフトウェアの不具合

人的エラー •入力ミス •ファイル、テーブル等の誤削除

計画停止システム変更 •クラスタノード、ストレージ追加、ディスク追加 •H/W、ソフトウェア、アプリケーションのアップグレード、パッチ適用

34


データベースの停止への対策

停止の種類原因対処するための主な機能

計画外停止サイト障害 •Data Guard/GoldenGateによる複数DBの保持

クラスタ障害 •Data Guard/GoldenGateによる複数DBの保持

ノード（サーバ）障害

•Data Guard/GoldenGateによる複数DBの保持 •RAC/RAC One Node によるフェイルオーバー

ストレージ障害 •Data Guard/GoldenGateによる複数DBの保持 •ASMによるミラー化、自動リバランス

データ破損、書込み欠落

•ASMによるミラー化、破損修復 •RMANによるブロック単位でのリストア、リカバリ •Active Data Guardによる自動ブロック修復

人的エラー •Flashbackテクノロジ

計画停止システム変更 •Data Guard/GoldenGateによる複数DBの保持 •RACのローリングパッチ適用 •ASMのリバランス •オンライン・メンテナンス

35


データベースのボリューム・マネージャ兼ファイル・システム Automatic Storage Management 複数のディスクを「ディスク・グループ」として一つの単位で管理

• ASMの代表的な機能

– ストライピング：ディスク・グループ内の、全てのディスクでストライピング（ホットスポットが発生しない）

– ミラーリング：ファイルの種類に応じて、 Oracleレベルでミラーリング（ミラーなし / 二重化 / 三重化）

– 動的リバランシング：ディスクの追加/削除時に自動的に再配置

36


ダウンタイムの極小化 Oracle Real Application Clusters

• 高可用性：Active-Activeのクラスタ構成障害時に別ノードで処理を引き継ぎ、サービスの継続提供

• 高拡張性：サーバの追加によって容易にスケールアウトが可能

37

Enterprise Edition Real Application Option

Or Standard Edition

Active Active Active 障害

障害発生


HA構成、RAC One、RACの比較

HA構成 RAC One Node RAC

イメージ

メリット・既に他社のクラスタウェアを利用している場合は、他の環境と統一できる

・全てオラクル製品で統一できる・計画停止（メンテナンス等）時オンラインでのノード切替が可能

・全てオラクル製品で統一できる・2台分のサーバ・リソースによる負荷分散・サーバ障害時ダウンタイム極小（数十秒）

デメリット

・利用可能サーバ・リソースは常に1台・サーバ障害時の切り替え時間がかかる（ノード、ストレージパスの切り替え）

・Oracle DBに関して監視できる項目が少なく、問題切り分け工数がかかる

・利用可能サーバ・リソースは常に1台・サーバ障害時には自動的にもう1台

のサーバに切り替わるが、若干のダウンタイムが発生

38

ACTIVE STANDBY

DB

他社Clusterware

DB

ACTIVE ACTIVE

Oracle Clusterware

DB

ACTIVE STANDBY

DB

Oracle Clusterware

DB


SERACとEERACを比較

SERAC EERAC

CPU使用率を向上し、マルチコアCPUを効率よく使いきる

シリアル実行によるCPUネック

SEでは1つの処理(SQL)をシリアルで実行するため、1つのCPUコアしか使用しません。その為、CPUコアを追加しても、性能向上は期待できないケースが多くあります。特に、1つの処理の負荷が高いバッチ処理やDWH系の分析処理は、性能向上は期待できません。

パラレル実行によるSQLの高速化

• EEのパラレル実行を利用することで、複数CPUコアを活用し、処理を実行可能です。これにより、複数のCPUコアを有効活用し、重たい集計処理を高速化が期待できます。

• さらに、物理メモリ上にキャッシュされたデータに対するパラレル実行により、ストレージの性能限界を排除した高速処理を実現可能です。

物理読込量を削減し、ストレージI/Oボトルネックを防ぐ

索引もしくは表の分割による物理I/O量の削減

索引を使用することで、読み込むデータ量を絞り込むことができますが、検索対象データが多い場合は、索引を使用してもパフォーマンスは向上しない可能性があります。

SEではEEのPartitioningに準ずる機能はなく、手動で表を分割するしかあ

りません。この場合、アプリケーションの変更が必要で、実装が困難になりやすいです。また、定期的に表のメンテナンスが必要になります。

Partitioningとデータ圧縮による物理I/O量の削減

対象データが格納されたパーティション表だけにアクセスし、Disk I/Oを削減する機能です。Disk I/Oを削減し、パフォーマンスを大幅

に向上できます。アプリケーションの変更がいらず、容易に実装可能です。また、パーティション単位で管理することで、メンテナンス負荷を削減です。

39


リアルタイム・データベース複製、災害対策 Oracle Data Guard

•本番データベースのコピーを作成し、データを保護

•災害対策/データ保護、移行/アップグレード

40

Enterprise Edition

DB ログを転送

REDOログ適用

REDOログ情報を自動的に転送

本番データベーススタンバイ・データベース

データ誤差無し

高速なデータ同期、ネットワーク帯域小

トランザクションの順次性保障

同期転送 (SYNC)

非同期転送 (ASYNC)

データ保護プライマリの更新はスタンバイへの転送完了後に確定

プライマリでの更新はスタンバイへの転送未完了でも確定

性能への影響

あり

スタンバイへの更新適用を待機

なし


アクティブなスタンバイ・サイトを実現 Oracle Active Data Guard

41

Enterprise Edition Active Data Guard Option

本番データベーススタンバイ・データベース

ネットワーク

ログ転送

Active Data Guard

DRサイトの利活用破損データブロックの自動修復機能

スタンバイサイトのリソースを徹底活用し、TCOの大幅削減が可能


遠隔地スタンバイ構成での同期転送 Far Sync

42

Enterprise Edition Active Data Guard Option

Standby

Primary

同期転送

非同期転送

Far Sync

同期転送のオーバーヘッド軽減近距離の遠隔同期インスタンスまでの同期転送

ゼロ・データロスの実現 Primary DB 停止時にも、必要な REDO データは遠隔同期インスタンスへ転送済み

最小限のファイル構成遠隔同期インスタンスは制御ファイルと REDO ログファイルのみから構成

シームレスなロール変換遠隔同期インスタンスを意識せずスイッチオーバーの実行が可能

遠隔地スタンバイで実現が難しかった「ゼロ・データロスのスタンバイ構成」を実現


リアルタイム・データ・レプリケーション Oracle GoldenGate

• 既存のデータベースやネットワークへの負荷は最小限

• 稼働中のデータベース同士で双方向に連携が可能

• 異なるデータベースやOSの種類・バージョンで構成されたシステム間での連携が可能

• データベース全体だけではなく、表・列など必要な部分に絞った柔軟な連携が可能

43

Oracle GoldenGate

ログの高速転送

システムA

Database

GoldenGate

Database

GoldenGate

双方向同期

片方向データ複製

システムB


可用性を高める各種機能の比較

44

RAC RAC One Node Data Guard/

Active Data Guard GoldenGate

機能概要 Active-Activeのサーバ・クラスタ構成

Active-Standbyのサーバ・クラスタ構成

同期/非同期でのログ転送によりデータベース複製

異環境間でも実現できるリアルタイム・レプリケーション

適応ケース

•サーバ障害やインスタンス障害発生時のゼロダウンタイム

•複数ノードのリソースを活用して性能拡張

•低コストでサーバ冗長化を実現したい

•計画停止時（メンテナンス）のダウンタイムゼロ

•完全なデータベースの複製

•あらゆる障害リスクに対応した強固な構成

•スタンバイ側リソースを有効活用（参照処理のオフロード/バックアップ実行）

•異種OS,データベースを混在した構成

• SE(One)で実現 •オブジェクト/スキーマ単位で連携

留意点

•サーバのクラスタリングなので、サイト障害/ストレージ全損/ブロック破損には対応できない

•サーバのクラスタリングなので、サイト障害/ストレージ全損/ブロック破損には対応できない

•スタンバイ側の更新は不可

•同一のデータベース同士であることが原則

•ブロック破損に対処できない

•データベース自体は論理的な複製なので、リカバリに時間と手間がかかる


人的エラーへの対応 Oracle Flashback Technology

• Flashback Technologyが必要とされる背景

• アプリケーション障害の約40%はオペレータまたはユーザーのエラー

• ユーザーエラーの復旧は非常に困難

• Flashback Technologyの目的

• 人為的（ユーザー）エラーからの早急かつ容易な復旧(数分でシングル・コマンドで復旧)

- 間違ったデータの削除、間違った表の削除、違うバッチを流してしまったなど

• Flashback Technologyの効果

• データベースのバックアップ全体のリストアは不要

- 変更されたブロックのみをリストア、DBを特定時点にまで戻す

• 過去データの参照が可能！

- 不正なデータ改竄防止に効果

45

Enterprise Edition


Flashback Technology の種類

機能名使用する領域利用するデータ概要機能カテゴリ

指定方法使用可能なエディション

Flashback Query UNDO UNDOデータテーブル単位で過去時点のデータを表示参照 SCN

TIMESTAMP SE/EE

Flashback Version Query UNDO UNDOデータ指定した時間間隔のすべての変更履歴を行単位で表示参照 SCN

TIMESTAMP SE/EE

Flashback Transaction Query UNDO UNDOデータ

サプリメンタルログ

一定期間に行われたトランザクションの変更履歴と

UNDO_SQL文を表示参照 XID EE

Flashback Data Archive FDA領域履歴表データ一定期間の履歴データを保持し、テーブル単位で遠い過去のデータを表示

参照 SCN

TIMESTAMP EE

+Ad. Comp

Flashback Transaction UNDO UNDOデータ

サプリメンタルログトランザクション単位での操作取り消しリカバリ XID EE

Flashback Table UNDO UNDOデータテーブル単位で過去の時点へ復旧リカバリ

リストアポイント SCN

TIMESTAMP EE

Flashback Drop RECYCLEBIN RECYCLEBIN Drop したテーブルを復旧リカバリテーブル指定 SE/EE

Flashback Database 高速リカバリ領域

Flashback log データベース全体を過去の特定の時点に復旧リカバリ

リストアポイント SCN

TIMESTAMP EE

46

Enterprise Edition


Flashbackの機能で救われた実例

47

Enterprise Edition

RAC/ASM構成（Exadata）

＋Data Guard による DR環境

性能を重視しセカンダリに Flashback Log を確保

RAC+ASM

カットオーバ直前(数時間前)に実施したバッチが誤っていた（通常の復旧作業では間に合わない・・）

DG Switch Over 運用でロール切替(正副入替)

Flashback DB 機能で処理実行直前へ巻き戻し

DG Stand by 再構築再びDG Switch Overでロール切替(正副)

正規の処理を確実に実施 -> 無事運用開始へ

https://blogs.oracle.com/dbjp/entry/exadata_000193

Flashback Database

RAC+ASM

DataGuard


データの統合（Consolidation、Integration）

48


複数データベースのマルチテナント統合 Oracle Multitenant

49

Enterprise Edition Multitenant Option

顧客管理 DB 販売管理 DB 経理 DB これまでのデータベース・アーキテクチャ

メモリ、プロセス、データファイルによって構成データベースごとに専有のメモリやプロセスが必要

企業によっては、数百のデータベースがあるケースも稀ではない

マルチテナント・コンテナ・データベース（CDB） Oracle Database 12c マルチテナントを実現する新しいアーキテクチャ

メモリとバックグラウンドプロセスは共有

運用管理はデータベース単位で

システムはPDB毎に稼働


データベース統合手法の進化スキーマ統合の課題を解決するマルチテナント・アーキテクチャ

50


Hypervisor

OS

DB

App

OS

DB

App

OS

DB

App App App

OS

12c CDB

PDB PDB PDB

App App App

スキーマスキーマスキーマ

サーバ物理統合インスタンス統合スキーマ統合

１台もしくは複数台のサーバーにまとめる

OSを１つにまとめ、インスタンス単位で統合

インスタンスを１つにまとめ、スキーマ単位に統合

マルチテナント化

インスタンスを１つにデータベースは複数

OS

DB

App

OS

DB

App

DB

App

DB

App


マルチテナント・アーキテクチャ • メモリとバックグラウンドプロセスは共有

– 1つのコンテナDB(CDB) に、複数の仮想DB(PDB) を構築

– 管理リソース（制御ファイル、REDOなど）は効率的に共有

• 運用管理はデータベース単位

– アップグレード、バックアップなど（PDB毎でも可）

– パッチ適用はCDB

• システムは PDB ごとに稼働

– 1つのデータベースに複数作ることができる

– アプリケーション&DBに変更は不要

– 移動、コピー、環境作成などは簡単なコマンドで実施できる

• 全体の可用性・対障害性

– RAC、スタンバイ（DataGuard）構成に対応

51


データベース

Oracle インスタンス

システム・グローバル領域

バックグラウンド・プロセス群

PDB : ERP

データファイル

PDB : CRM


PDB : DWH


制御ファイル、REDOログファイル、アーカイブREDOログファイル


データベース統合を支える効率的なリソース管理 Oracle Resource Manager

• サーバ内の柔軟なリソース制御が可能

• 処理特性毎にリソース利用ポリシーを定義、アプリケーション毎のサービスレベル管理が可能

• 時間帯による運用切り替えも可能

52

Enterprise Edition

• インスタンス・ケージング

インスタンス単位のCPUリソース制限可能

• Maximum Utilization Limit

特定グループの CPU リソースの

使用率を任意の値に制限可能

• I/O Resource Manager (Exadataのみ)

コンシューマグループ毎にIO帯域を割り当て、

優先度に応じたサービスレベルの管理が可能


複数データベース環境を1つの画面で一括管理 Oracle Enterprise Manager Cloud Control

53

・1つのDBを1つの箱で表現

・負荷が高いDBは面積が大きく表示される

・主な負荷のタイプ（CPU負荷やIO負荷や

待機）により色分けされる

DB1 DB2 DB3 DB4

DB5

クリックで各DBに

ログイン可能

管理している全てのDB

に対するインシデントが確認可能

複数DB対して情報の表示やログインが可能 ※Cloud Control の利用には外部サーバが必要


データベース・セキュリティ

54


データベースのセキュリティ対策

55

Sensitive

Confidential

Public

クライアント Block

Log

Allow

Alert

Substitute

外部からの攻撃データ盗難/紛失

原因追究と対策

データの暗号化（DB内データ／バックアップデータ）

データのアクセス制御

不正アクセスブロック・検知

監査ログの取得・モニタリング

権限に応じたデータアクセス


データの暗号化機能透過的データ暗号化

• Oracle Database内部で暗号/復号処理を行うため、アプリケーションの変更なし

• 性能への影響を最小限にした暗号化機能が可能

56

Enterprise Edition Advanced Security Option

バックアップデータの暗号化

データの暗号化

AES-NI との組み合わせにより、さらに高速な暗号化処理を実現（Advanced Encryption Standard New Instructions） Intel® Xeon® プロセッサー 5600 番台から搭載された新しい命令セット暗号化/復号処理をプロセッサー側で高速処理

非暗号

暗号（AES-NI使用）

暗号（AES-NI未使用）

500GBの表に対するSELECT文の処理時間


不正なデータベースアクセス対策 Oracle Database Firewall

57

Block

Log

Allow

Alert

Substitute （変換）

Database Firewall Server （SQL文法解析による正確なブロッキング）

Sybase IBM

Microsoft

正規アクセス

• ホワイトリスト／ブラックリストによるブロッキング • OS/DBユーザ名、IPアドレス、アプリケーション名、SQL文などの要素の組み合わせで定義

外部からのSQLインジェクション開発者・管理者の内部アクセス

不正アクセス

Oracle Audit Vault and Database Firewall


低負荷、機能強化されたデータベース監査機能 Unified Auditing（標準機能）

従来の監査機能 Unified Auditing（12c~）

監査対象オブジェクトの定義

監査対象毎に定義ポリシー定義により、一つのポリシーで

DB内のすべてを監査可能

監査条件の指定指定不可条件と監査頻度の指定可能

監査対象ユーザの指定 BYで監査ユーザ指定 BYで監査ユーザ指定 EXCEPTで免除ユーザ指定

監査ログ書き込みの仕組み

同期書き込みのみログのとり漏れはないが、パフォーマンスへの影響があり

同期書き込みログのとり漏れはないが、パフォーマンスへの影響があり

非同期書き込み DBが異常停止の場合、SGA上のログが失われる可能性がある

ログの書き込み先監査の種類による（OSファイル、Syslog、XMLファイル、内部表）

UNIFIED_AUDIT_TRAIL に統合

ユーティリティ操作のログ取得不可取得可能（RMAN、DataPump、exp/imp、SQL*Loader Direct Path Load）

58

監査設定が簡易に

除外ユーザ設定が可能に

パフォーマンスへの影響を小さくすることが可能に

ログを一元的に管理・分析することが

可能に

ログを一元的に管理・分析することが

可能に


取り漏れのないデータベース操作ログ取得 Oracle Audit Vault and Database Firewall

59


OS, ディレクトリ独自ログの監査ログ

Audit Vault Server

アプリケーション

データベース

スイッチ

Database Firewall

Server

Sybase IBM

Microsoft

Fire

wal

l のログ

レポート・分析、アラートメール


Oracle Audit Vault and Database Firewall 最小限の投資で最大限のセキュリティ対策を実現

60

モニタリングとブロッキングの両方を、シンプルかつお求めやすい価格で提供

ソフトウェア・アプライアンスで簡単・短期間に構築

•インストールは1日で完了。監査目的であれば、約1ヶ月で構築可能



権限に応じたリアルタイム・データリダクション Oracle Data Redaction

61

Enterprise Edition Advanced Security

ユーザーの権限やクライアント情報に応じてリアルタイムにデータをリダクション

アプリケーションのコード修正は不要

コールセンターやサポート業務などの職責に応じた顧客情報へのアクセス制御の実現、PCIDSSに対応したクレジットカード番号の表示、アプリ開発者の直接アクセスも制御

クレジットカード番号

4451-2172-9841-4368 5106-6342-4881-5211 4891-3311-0090-5055

データ責任者

業務オペレーター

ポリシーの条件となる要素 - IPアドレス - DBユーザー - 時間 - - アプリケーションID等

Policy


機密性の高いデータの検証DB環境の作成 Oracle Data Masking

• 機密性の高い情報を不可逆な形式にマスキング

– 個人情報、医療情報、患者情報、クレジットカード番号・・・

• 稼働中のデータベースのデータ特性を維持しつつテスト用に最適化

– 列データの要素数、分布、件数などが本番データと同等になるようにマスキング

– マスキングされたデータで実稼働と同条件でのクエリー実行

• 定義済みフォーマット・ライブラリを提供

62

LAST_NAME CREDIT_ID SALARY

ANSKEKSL 111—23-1111 60,000

BKJHHEIEDK 222-34-1345 40,000

LAST_NAME CREDIT_ID SALARY

AGUILAR 203-33-3234 40,000

BENSON 323-22-2943 60,000

本番データベーステスト・データベース

Enterprise Edition Data Masking and Subsetting Pack


行レベル・アクセス制御（Oracle8i~） Oracle Virtual Private Database（VPD）アプリケーションを変更なく、問い合わせを実行したユーザ毎にアクセス制御

63

Enterprise Edition

SELECT * FROM customers;

Alan

Tom

SELECT * FROM customers WHERE sales_rep = ‘Alan’;

SELECT * FROM customers WHERE sales_rep = ‘Tom’;

検索の実行

処理の開始前にWHERE句を自動付加


列レベル・アクセス制御（Oracle10g～） Oracle Virtual Private Database（VPD）

特定の列に対して、アクセス制御を有効にする

64

Enterprise Edition

ACCOUNT_MGR_ID = 149 のデータは結果を返す

ACCOUNT_MGR_ID = 149 以外はNULLは結果を返す

CREDIT_LIMIT：機密情報

ACCOUNT_MGR_ID = 149

検索の実行


特権ユーザのための強制アクセス・コントロール Oracle Database Vault

65

アプリケーション

select * from finance.customers

職務分掌特権ユーザ（SYS, DBA権限）であっても情報にはアクセスさせない

透過的既存アプリケーションの変更不要、どの経路からのアクセスも一律に制御

厳密ユーザー、クライアント情報（IPアドレス、アプリ名）、時間を組み合わせたポリシー設定

管理者（特権ユーザ）

人事情報

顧客情報

財務情報

Enterprise Edition Database Vault


Oracle Databaseのアクセス制御の特徴

Data Redaction Virtual Private Database Database Vault

機能概要列のアクセス制御 &

リダクション行・列のアクセス制御

表のアクセス制御特権ユーザー管理

必要ライセンス Advanced Security Option Enterprise Edition Database Vault Option

バージョン 12c～(11.2.0.4も可) 8i～(列は10gR1～) 10gR2～

対象アクセス列(SELECT) 列・行(DML) オブジェクト・SQLコマンド

説明表に定義したリダクションポリシーの条件に応じて、列を表示させないまたは、任意の値にリダクション

表に定義したVPDポリシーの条件に応じてWHERE句を自動的に付与することで行を表示させない。その際に特定の列をNULL表示させることもできる

レルム、ルール、コマンドルールの各要素を使って、オブジェクト(表やビュー、PL/SQL等)へのアクセス、SQLコマンド自体の実行を詳細に強制アクセス制御することができる

特権ユーザーポリシーは適用されないポリシーは適用されないどのユーザーでも

ポリシーは適用される

設定 DBMS_REDACTパッケージ

または、Oracle Enterprise Manager DBMS_RLSパッケージ

または、Oracle Enterprise Manager DVSYS.DBMS_MACADMパッケージまたは、Oracle Enterprise Manager

66


Oracle Data Masking との違いデータをマスクする結果は同じだが、用途が異なる

Oracle Data Masking Oracle Data Redaction

実装方式 Oracle Enterprise Manager DBMS_REDACTパッケージまたは、Oracle Enterprise Manager

目的表を直接マスキングし、本番に近いテストデータを作成

ユーザーの権限に応じて表やビューをリダクションするアクセス制御

実行タイミングオフライン表・データベースのクローン作成後にマスキングを実行

オンライン問い合わせ結果にリアルタイムでマスク処理を実行

格納データへの影響永続的にデータを変更影響なし

67


Oracle Database Security Products 解決策と製品のまとめ

セキュリティ観点解決策・機能名製品名

データの暗号化透過的データ暗号化（TDE） Oracle Database Enterprise Edition + Oracle Advanced Security Option

不正なデータベースアクセスのブロック・検知 Database Firewall Oracle Audit Vault and Database Firewall

取り漏れのないデータベース監査ログの取得 Audit Vault Oracle Audit Vault and Database Firewall

権限に応じたリアルタイム・データリダクション Oracle Data Reduction Oracle Database Enterprise Edition + Oracle Advanced Security Option

機密性の高いデータの検証DB環境の作成 Oracle Data Masking Oracle Database Enterprise Edition ＋ Oracle Data Masking Pack

68


運用管理、保守

69


計画停止時間を極小化オンライン・メンテナンス

• ストレージのパラメータ変更、表領域の変更、表の定義変更などの再定義を、オンライン状態(トランザクション(DML)が発生している状態)で実行可能

70

Enterprise Edition

メカニズム元表(emp) 仮表(int_emp)

② 更新履歴の記録

① 表データの変換

③ 更新履歴の反映

スナップショット・ログ

適応例

Empno Name Salary Hire_Date

100 林真彦 350,000 2001/06/01

200 鈴木成美 250,000 2010/04/01

Empno Name Sal Hire_Date Deptno

100 林真彦 385,000 2001/06/01 10

200 鈴木成美 275,000 2010/04/01 10

列名変更

1.1倍削除列追加

パーティション化索引

索引再構築

※実行後、元表はユーザーが削除、スナップショットログは自動削除されます

④ 表の入れ替え


システム停止による機会損失を防ぐオンライン・メンテナンス

• オンライン・メンテナンス機能により、システムを停止することなくメンテナンス作業を実施できます

71

Enterprise Edition

機能 Standard Edition

Enterprise Edition

機能概要

オンライン列追加／変更 ○ ○ オンラインで列の追加／変更が可能

オンライン索引ビルド × ○ オンラインで索引の構築／再構築が可能

オンライン表再編成／再定義 × ○ オンラインで表の論理／物理構造を再定義することが可能

オンラインパーティション操作 × ○ オンラインでパーティションの追加／削除／移動などの操作可能


オンラインでのデータファイルの移動 MOVE DATAFILE コマンドによるファイルの移動

• データファイルの MOVE/RENAME

72

Enterprise Edition

ALTER DATABASE MOVE DATAFILE '<移動前のパス>' TO '<移動後のパス>';

表領域 X

Disk1 Disk2

Datafile1

Datafile2

Datafile3

Datafile2

オンライン実行 • DB が ONLINE の状態で実行可能 • 表領域の OFFLINE 化不要 • コマンド実行中の更新も移動先に反映

ファイルの自動コピー • 物理ファイルのコピーも実行 • 手動でのファイルのコピー、移動は不要 • ASM にも対応

※ コマンド実行中は最大で (移動するファイルサイズ x 2) の DISK 領域が必要


Oracleの推奨するバックアップ・リカバリ Recovery Manager（RMAN）

• バックアップ、リストア、リカバリ、バックアップ･ファイルの管理用ユーティリティ

– 操作がシンプル

– バックアップファイルの管理が容易（必要なバックアップのセットを一元管理など）

– Oracleのデータブロックを利用しているため、効率的に復旧可能

– バックアップのサイズ縮小、高速化の機能

– リカバリアドバイザによる、復旧時間短縮

73

リストア/リカバリの時間

障害解析に要する時間

総ダウンタイム

障害解析に要する時間＝人間が考えている時間

リカバリアドバイザで短縮可能！


様々なバックアップ・リカバリ機能を搭載 Recovery Manager（RMAN）で実現できること

SE EE 機能概要増分バックアップ〇〇

オンラインバックアップ〇〇 ARCHIVE LOGモードでの運用が必要

高速増分バックアップ (ブロック変更トラッキング)

× 〇増分バックアップの際、EEではバックアップ時間の短縮が可能・ SE：すべてのデータにアクセスする・ EE：更新部分のみの読込みだけにアクセス

ブロックのスキップ (未使用ブロックの圧縮)

× 〇バックアップ・サイズを大幅に縮小可能・ SE：RMANでデータファイルのすべてのブロックが読み取る・ EE：バックアップ時にその時点で未使用のブロックを削除

ブロックレベル・メディア・リカバリ

× 〇 1つのブロックが破損した場合・ SE：データファイルをオフラインしバックアップをリストア・ EE：ブロック単位にリカバリが可能、短時間で復旧可能

パラレル・バックアップ/リカバリ × 〇・ EE：RMANのバックアップ操作を並列化、高速なバックアップ実行が可能

表領域のPoint-in-Time リカバリ

× 〇その他の表領域およびオブジェクトには影響を及ぼさずに、過去の時点まで迅速に表領域をリカバリすることができる機能。

試行リカバリ × 〇メディア・リカバリ時の問題解決の手段として、リカバリのシミュレーションができる機能。試行リカバリはメモリー内でのみ発生。

ファスト・スタート・リカバリ × 〇インスタンス障害またはシステム障害からのリカバリにかかる時間を予測できる機能。

74

Enterprise Edition


バックアップサイズの縮小、高速化高速増分バックアップなど

増分バックアップ高速増分バックアップ（Enterprise Edition）

特徴 • データ･ファイル全体を読み込み、更新のあったブロックをコピーする

• データの変更時に更新ブロック情報を記録 • バックアップ時は記録されたブロックのみを読み込み

バックアップに要する時間全体バックアップと比較して変わらない全体バックアップと比較して短縮可能

イメージ図

Standard Edition Enterprise Edition

未使用ブロックのスキップ × ○ バックアップ・サイズを縮小可能

パラレル処理 × ○ バックアップ処理の高速化が可能

75

Enterprise Edition

水

火

月

月

水

火

火

月

水

水

月

火

RMAN

水水水水水

火

月

月

水

火

火

月

水

水

月

火

RMAN

ブロック・チェンジ・トラッキング・ファイル

CTWR

水水水水


ブロック破損からの迅速な復旧ブロック・メディア・リカバリ

• ブロック破損＝ブロックレベルのデータ消失

– 通常、広範囲なデータ消失は引き起こさない

– 断続的でランダムなI/Oエラーや、破損したメモリーがディスクに書き込まれることが原因で発生

• RMANでは、1つ以上の破損したデータ・ブロック単位でリカバリ可能

• リカバリが必要なブロックのみがリストア、リカバリされるため、リカバリ時間が短縮

• 同一データファイルに存在している、リカバリが不要なオブジェクトはオンラインのまま利用可能

76

Enterprise Edition

表領域（オンライン）バックアップ領域

データファイルブロック･メディア・リカバリ RMANではバックアップの際に

ブロック破損をチェック、正常なバックアップセットから

確実にリストア可能


データベース特化のテスト効率化 Real Application Testing

•本番環境での処理を Capture & Replay

• Upgrade や Patch 適用などによるパフォーマンス影響を判断可能

–実業務のワークロードに即したデータベースの包括的なテスト • 疑似クライアントで高負荷状態も再現可能

–特定の重要な SQL に関してシステム変更によるパフォーマンス影響の有無を確認する SQL の単体テスト • システム変更前後における実行計画や実行時の統計値の比較

77

Enterprise Edition Real Application Testing

SALES

HR

ERP

CRM

複数DBの稼働状況を重ね合わせることも可能（Oracle12c～）


テスト結果・分析レポートの活用 Database Replay / SQL Performance Analyzer (SPA)

78

Enterprise Edition Real Application Testing

パフォーマンスが劣化/改善した SQL を特定

EMの機能を利用して、SQLチューニングを実施

パフォーマンス/エラー/データの違い

AWR/ASH比較レポート


本番&検証&開発環境の構成情報を一元的に管理 DB Lifecycle Management Pack

79

Enterprise Edition Lifecycle Management Pack

構成として保持したいタイミングでベースラインを作成。以降、構成変更が入る度にベースラインを更新。（ディクショナリ・ベースライン） ⇒スナップショットによる変更履歴の管理

検証環境と本番環境の差違を確認する際は、お互いのベースライン、または、どちらかのベースラインを作成し、比較対象環境（ベースライン）と比較。（ディクショナリの比較） ⇒ 環境間・世代間の差分チェック

必要に応じて同期処理を実施 ※世代管理しているので戻すことも可能（ディクショナリの同期） ⇒ 検証環境から本番環境へのロールアウト

構成情報の保存

構成情報の比較

構成情報の同期

本番DB

検証用DB

開発用DB


データベースをよりシンプルに

• Oracle Database Appliance X5-2

• シンプルで、高い信頼性を、手頃な価格で

• Oracle11g R2およびOracle12c利用可


Oracle Database Appliance のポイントシンプルかつ低コストで高可用性＆高性能なデータベース基盤を実現

81

シンプルな構築、管理、障害対応を実現

オラクルのベストプラクティス構成をすぐに利用可能

高可用性を

シンプルに

最適化されたHW設計 + SW設定 + Oracle DB EE

圧倒的なコストパフォーマンスを実現

コスト

パフォーマンス

必要なCPU能力に合わせてライセンスを拡張購入可能

Oracle DB EE が2コアからスタートできる

スモール

スタート

オラクルが全てのコンポーネントを提供

世界中の数千台が同一構成で稼働している安心感サポート


選択される理由

82

• Engineered Systems である –シンプルに高可用性、高いコストパフォーマンス、リスク低減

– “Build vs. Buy”：一から作るよりも買ってきた方が賢い選択

• Oracle Database Enterprise Edition が使える –スモールスタート：Capacity-On-Demand ライセンス

– Enterprise Edition を採用できるシステムレンジが大幅に拡大

中堅企業の基幹システムだけでなく、

大手企業の部門・拠点システムでも数多く導入されています


本日お話した内容

• Enterprise Edition データベース・サーバの課題/懸念を「自動解決」、「管理/運用を効率化」するための仕組みを実装

• パフォーマンス、可用性、運用効率化、セキュリティなどの要件を求められるシステムでは、 Enterprise Edition の機能が有効

Enterprise Editionのメリット効果的に管理/運用する機能を「自動実装」

Enterprise Edition

パフォーマンス

情報ライスサイクル

管理

可用性

データの統合

セキュリティ

運用管理


技術情報の入手、最新情報キャッチアップのポータルオラクルエンジニア通信

オラクルエンジニア通信

Keyword 検索

「○○を知りたい！調べたい！」

キーワードを自由に入力し、関連情報を一括検索できます。例）「バージョンアップ」「レプリケーション」「11gR2」

カテゴリ検索

「興味のあるテーマについて幅広く知りたい！」

ジャンルから、興味のあるテーマの情報を探すことができます。例）「インストールとDBの作成・構築」「他社製品との比較・移行」

マニュアル検索

製品機能についてはまずマニュアルを確認

各マニュアル内をキーワードで検索することが可能です。例）「Oracle Database 11g R2」

特集テーマ Pick Up

ニーズの高い技術情報をまとめてお届け

開発や運用の現場で役立つ情報・Tipsをテーマ毎に。例）「性能改善特集」「サーバ仮想化特集」「.Net特集」

おすすめ活用法～OTNセミナーオンデマンドのテーマ別コンテンツ検索～

スマホでも学習できます（無償）

Copyright © 2015 Oracle & C’sNEXT Co.,Ltd. All rights reserved. 85

Documents

Oracle Database 12c エディション比較-SE/EEの …...第1回どさんこオラクル勉強会 Oracle Database 12c エディション比較-SE/EEの 違い、Enterprise Editionで

Oracle Database 12c エディション比較-SE/EEの …...第1回どさんこオラクル勉強会 Oracle Database 12c エディション比較-SE/EEの違い、Enterprise Editionで