Oracle Databaseアップグレード成功のための極意otndnld.oracle.co.jp/ondemand/dbup-kowakunai-aug2017/1...Oracle マルチテナントDatabaseが革新的なコスト削減を実現

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

Oracle Databaseアップグレード成功のための極意

2017年8月23日日本オラクル株式会社クラウド・テクノロジー事業統括Cloud Platformビジネス推進本部ビジネス推進第2部部長桑内崇志


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

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。


Oracle Databaseのアップグレードとは?

•バージョンアップ 10g => 12c

•ハードウェア(プラットフォーム)の変更– オンプレミスからクラウドへの移行も

3


アップグレードにまつわるよくある話•安定して稼働しているのでそのままのバージョンで使いたい–何も変えずに「安定稼働」の前提は関連システムも何も変わらないこと。

–アプリケーション、インフラが変わるのであれば、バージョン固定はむしろリスク。

• バージョンアップにメリットを感じない–バージョンアップそのものは無償。既存の問題の解決に関わる機能拡張をご確認ください。

– とはいえコストはかかります。せっかくなら新機能を理解し、アップグレードの目的の明確化

• アプリケーションの変更とインフラの変更を同時に行うのは大変–その通りです。別々に更新を行える工夫も必要。

–オラクルのリリース戦略を理解しながら「いつ行うべき」を含めたアップグレード戦略の明確化

4


アプリケーションもプラットフォーム製品もリリースサイクルはますます早くなっている

Source: techtarget.itmedia.co.jp

Source: Wikipedia.orgSource: cloudscaling.com

一年あたりのリリース数

次のリリースがでるまでの日数

Source: Wikipedia.orgを元に作成

アップデート数

Source: vmware.com

Source: cnet.com

Source: tomcat.apache.orgを元に作成

アップデートが出る平均日数

5


なぜ、アップグレードするのか？アップグレードによるメリット、しないことによるリスク

• アップグレードを行うメリット–新機能の活用/機能拡張等による、性能向上・運用管理性向上・セキュリティ強化

–既知不具合の解消・新規パッチの提供

• アップグレードをしないとリスク–セキュリティ事故発生のリスク

–既知不具合による障害発生のリスク

–アップグレード難易度上昇のリスク

Multitenant In-Memory

6

アップグレードの目的を明確にする


第1世代1984年～

Oracle Databaseの進化の歴史

‘79年

‘84年 ‘88年

Oracle 2世界初商用RDBMS



Oracle 4読み取り一貫性

Oracle 5パラレルサーバー

Oracle 7パラレルクエリーストアドプロシージャ

’97年Oracle 8パーティショニング

R1

DBDB

ミニコンピューターメインフレーム

‘85年

‘98年

クライアントサーバーモデル

‘01年

’04年

’07年

’13年2016年

グリッドコンピュートインターネット

DBクラウドマルチテナント

DBDB

R2Oracle 6行レベルロックPL/SQL

リニアスケーラビリティと高可用性の実現「Oracle RAC」「Data Guard」

コストパフォーマンスの限界を突破「Oracle Exadata Database Machine」


インターネット時代のデータベース「大容量機能」「パラレル処理」

インフラストラクチャーのグリッド化「Grid Infrastructure」「自動データベース化」

クラウド時代のDatabase as a Serviceの実現「Multitenant」「Database In-Memory」

R1

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


Oracle Database 12c Release 2 主要プラットフォームすべてで出荷開始

• Oracle Cloud (2016年9月17日)

• Oracle Exadata & Super Cluster (2017年2月10日)

• Linux 86, Solaris SPARC & x86 (2017年3月1日)

• Windows (2017年3月16日)

• HP-UX/AIX (2017年4月13日)

8


NEW:300以上の新機能を搭載したOracle Database 12c Release 2 がいよいよ登場

データ・マネジメントの変化に対応

➢ディスクベースから In-Memory へ

➢データウェアハウスから Big Data へ

➢オンプレミスからCloudに最適化されたデータベースへ

9

今後、5年、10年先のお客様の投資を保護するため


1.データベース標準化と統合集約 3.クラウドを用いたシステムの拡張

10

2.参照/分析用データベースの統合 4.災害対策システム構築

アップグレード後に目指すデータベース基盤のユースケース

12c

データ同期

12c

開発・検証データ参照

テスト

OLTP 参照分析DB

12c

運用コスト削減

リアルタイムデータの高速分析

12c

データ参照、分析

クラウド


1.データベース標準化と統合集約

Oracle マルチテナント Databaseが革新的なコスト削減を実現シングル・コンテナ・データベースにプラガブル・データベース(PDB)としてデータベースを仮想化

マルチテナントは劇的にソフトウェア管理を削減可能、一方で仮想化は増加

PDB PDBPDB

Plu

ggable

シングル・コンテナ・DB (CDB)

オペレーションとサービスの共有と集中化

• 簡単かつ高速にPDBをプロビジョニング・移行・クローン

さらに俊敏• 多くのPDBを一つとして管理

• コンテナDBでパッチ・アップグレード・バックアップ・スタンバイ

低いOPEX 低いCAPEX• サーバあたりにより多くのPDBを構築 –PDBはメモリとプロセッサを共有

11



データベースの高密度集約(ITリソース有効活用)マルチテナントの集約率は、インスタンス統合よりも高い（社内検証より）

統合できるDBの数メモリ*

250

50200MB

1600MB

参考: Oracle Multitenant: Study of Database Consolidation Efficiency

87.5%カット5倍

シングルインスタンス

マルチテナント構成

同環境なら、5倍の数のデータベースを統合可能

同じ性能を出すために必要なメモリサイズを87.5%カット(1/8に縮小)

ライセンス/ハードウェアのコストを節約できる

5倍の利用効率高い費用対効果

同じ環境だったら同じ性能を出すには

*DBを動かすために必要なメモリサイズ

12


• コンテナあたり最大4,096 PDB

• メモリー、CPU、I/Oリソースの優先順位付け

• プライベート・クラウドおよびパブリック・クラウド間で設定可能な分離性

13


Oracle Multitenant : 大規模環境にも対応可能な統合と分離

RetailPricing

Container Database



PDB単位のキャラクタセット

• CDB は AL32UTF8

• PDBのキャラクタセット変換は不要に

• 国際化キャラクタセットもPDB別に設定可

• 混在も可能

SQL> @lang

UNICODE_TEST_STRING

-------------------------------------

Arabic العربية :

Chinese : 中文

English : English

French : Français

German : Deutsch

Greek : Ελληνικά

Hebrew עברית :

Japanese : 日本語

Korean : 한국어

Portuguese : Português

Russian : Русский

Spanish : Español

Thai : ไทย

14

* SQL from sqlsnippets.com

異なるキャラクタセットでの統合が容易に


2.参照/分析用データベースの統合

In-Memory with Oracle Database 12c

リアルタイム分析パフォーマンスシンプルな実装

OLTP とAnalyticsを同じデータベース上で

数秒以内のレポーティングとデータ分析

アプリケーションの変更不要

15


•本番データベースに全く影響を与えずにリアルタイム分析

• スタンバイ・データベースのリソースを有効活用できる

•本番とスタンバイで異なるデータをポピュレーション可能

MonthIn-Memory

Production Standby

YearIn-Memory

16


In-Memory with Active Data Guard : Exadata & Cloud


松井証券様– Data Warehousehttps://www.oracle.com/jp/corporate/pressrelease/jp20150706.html

• 情報系システムに適用

• 定型業務や非定型的な分析用の2つDBを統合

• 特に非定型分析が高速化

17

国内某流通業 – Mixed Workload

• 基幹システムとDWHの統合

• DWH専用データベースのリプレース

• コストが約50%削減

• 本番データベースとリアルタイムに同期

国内某金融機関 – DWH

• 顧客情報の分析

• 専用アプライアンスのリプレース

• 分析クエリーが300倍高速化したものも

• 本番データベースとリアルタイムに同期


Oracle Database In-Memory 導入事例とユースケース

Die Mobiliar – Mixed Workload

• カスタムのリスク管理システム

• 専用アプライアンスのリプレース

• 分析クエリーが50-240倍高速化

• データベース・サイズが大幅に削減


2.参照/分析用データベースの統合 : Big Dataへ拡張したお客様事例

アプリログデータを活用し、顧客満足度の高度化を図る

18

某コーヒーチェーン様

• 顧客の“待ち時間”解消が目的

• 2015年9月よりモバイル注文＆決済サービス（Mobile Order & Pay）を全米7,400店舗で展開

• 顧客満足度向上のための更なる取り組み

– DWH上の顧客データと、アプリ、ビーコン、Wifiなどのログデータを横断した分析

– 店舗分析、製品開発

– プロモーション効果、顧客行動、顧客ニーズ分析

・プロモーション分析・顧客行動・モバイルアプリ改善・商品、サービス改善

SQLアプリログ

BeaconWi-Fi

・顧客情報・購入履歴・プロモーション・ポイント


JSON

3.クラウドを用いたシステムの拡張

JSON Support in Oracle Database 12cPowerful SQL Analytics

JSON

RESTful サービスまたはネイティブ APIによるアクセス

JSON形式のデータ永続化 SQLによる分析

Oracle Database 12c

SQL

19


3.クラウドを用いたシステムの拡張

Oracle REST Data Services

20

REST-enable your data

JSON

Oracle Database(Relational)

Oracle Database(Document Store)

Oracle NoSQL Database

OracleRest Data Services

REST

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

https://www.oracle.com/jp/corporate/pressrelease/jp20170512.html


4.災害対策システム構築

クラウドを活用したDRシステム

• DRシステムの利用用途–もちろん大規模な災害/障害時のため

–普段はレポーティングや開発等の用途にも利用可能

–パッチテスト環境

–技術ホワイトペーパーで構成手順を記載

• Public CloudまたはCloud Machine–リソースを柔軟に増減できるのがクラウドのメリット

22

(Active) Data Guard

On-Premises Primary Database

Oracle CloudStandby Database

Sandbox Test/Dev in the cloud

Reporting


データベース・アップグレード戦略を明確にする

23


Oracle Databaseのライフタイムサポート

2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021

Oracle11.2

Oracle12.1

11.2.0.1

11.2.0.2

11.2.0.3

11.2.0.4

12.1.0.1

12.1.0.2

Oracle12.2 12.2.0.1

Premium SupportExtended Support(無償期間)Extended SupportSustaining Support

パッチ提供期間

11gR2のExtended Support無償期限は2018年12月まで12cR1のExtended Support無償期限は2019年7月まで

現在

24


Oracle Databaseのアップグレード戦略例

25

2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021

Oracle11.2

Oracle12.1

11.2.0.1

11.2.0.2

11.2.0.3

11.2.0.4

12.1.0.1

12.1.0.2

Oracle12.2 12.2.0.1

12.2.0.2

「新機能積極採用」派12.1を経由するパターンもあり

「リスク最適型堅実運用」派

「有償Extend Support最大限活用」派

Premium SupportExtended Support(無償期間)Extended SupportSustaining Support

パッチ提供期間


アップグレード戦略と考え方小規模なアップグレードやパッチ適用を組み込むことが戦略としても重要

26

「リスク最適型堅実運用」派は、まず12.1.0.2へ11g リリース2の無償延長サポート期間内に12c Release 2に移行しようとすると、移行先は12cリリース2の初期リリースの想定が必要に「堅実運用」を求めるのであれば、まず12c Release 1のターミナルパッチセット(12.1.0.2)に移行してサポート期間を確保した後、12c Release 2に移行するタイミングを伺う

「新機能積極採用派」は12.2.0.1へ新機能の優位性を早く享受する。ただし、12.2.0.1のサポート期間を鑑みながら(新規パッチが出なくなる)、12c Release 2の中で定期的にアップグレードしていく

「有償延長サポート最大限活用派」は11.2.0.4を最長2020年まで一部のクリティカルな領域では11g Release 2(のターミナル)をできる限り長く使うことが求められるケースもあり、そうした場合は有償延長サポートを最大限に活用してこれを実現することが可能。移行期間や並行稼働期間を鑑み、2019年には12c Release 2への移行プロジェクトを開始する


Oracle Database アップグレード成功のために

•何を活用するか、アップグレードの目的を明確にする–必要な新技術は取り込みながら、システムのレベルアップ。

• どのバージョンか、戦略を明確にする–システムの特性に応じた無理のない戦略をご検討ください。

• できれば定期的なパッチ適用やアップグレードの適用を–ある時点で「大きな変更」するより、「小さな変更」を定期的に

– 「小さな変更」を定期的に行うためのシステム構成もあります

–システムの安定、セキュリティ・リスク低減にもつながります

27

Documents

Oracle Databaseアップグレード成功の ための極意otndnld.oracle.co.jp/ondemand/dbup-kowakunai-aug2017/1...Oracle マルチテナントDatabaseが革新的なコスト削減を実現

Oracle Databaseアップグレード成功のための極意otndnld.oracle.co.jp/ondemand/dbup-kowakunai-aug2017/1...Oracle マルチテナントDatabaseが革新的なコスト削減を実現