How to Use the PowerPoint Template

Transcription

1 Oracle Database アップグレード成功のための極意 2017 年 8 月 23 日日本オラクル株式会社クラウド テクノロジー事業統括 Cloud Platform ビジネス推進本部ビジネス推進第 2 部部長桑内崇志

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

3 Oracle Databaseのアップグレードとは? バージョンアップ 10g => 12c ハードウェア(プラットフォーム)の変更 オンプレミスからクラウドへの移行も 3

4 アップグレードにまつわるよくある話 安定して稼働しているのでそのままのバージョンで使いたい 何も変えずに 安定稼働 の前提は関連システムも何も変わらないこと アプリケーション インフラが変わるのであれば バージョン固定はむしろリスク バージョンアップにメリットを感じない バージョンアップそのものは無償 既存の問題の解決に関わる機能拡張をご確認ください とはいえコストはかかります せっかくなら新機能を理解し アップグレードの目的の明確化 アプリケーションの変更とインフラの変更を同時に行うのは大変 その通りです 別々に更新を行える工夫も必要 オラクルのリリース戦略を理解しながら いつ行うべき を含めたアップグレード戦略の明確化 4

5 アプリケーションもプラットフォーム製品もリリースサイクルはますます早くなっている アップデート数 Source: Wikipedia.org を元に作成 Source: cnet.com 一年あたりのリリース数 アップデートが出る平均日数 Source: techtarget.itmedia.co.jp 次のリリースがでるまでの日数 Source: cloudscaling.com Source: Wikipedia.org Source: tomcat.apache.org を元に作成 Source: vmware.com 5

6 なぜ アップグレードするのか アップグレードによるメリット しないことによるリスク アップグレードを行うメリット 新機能の活用/機能拡張等による 性能向上 運用管理性向上 セキュリティ強化 既知不具合の解消 新規パッチの提供 アップグレードをしないとリスク セキュリティ事故発生のリスク 既知不具合による障害発生のリスク アップグレード難易度上昇のリスク Multitenant In-Memory アップグレードの目的を明確にする 6

7 Oracle Databaseの進化の歴史 Oracle 2 Oracle 5 Oracle 7 世界初商用 RDBMS パラレル サーバー パラレルクエリー ストアドプロシージャ 84年 79年 88年 Oracle 4 Oracle 6 読み取り 一貫性 行レベルロック PL/SQL 85年 第1世代 1984年 DB ミニコンピューター メインフレーム R1 クラウド時代のDatabase as a Serviceの実現 Multitenant Database In-Memory R1 98年 04年 97年 Oracle 8 01年 13年 2016年 07年 R2 パーティショニング 第2世代 1992年 DB 第3世代 1998年 DB 第4世代 2013年 DBクラウド マルチテナント グリッド コンピュート インターネット DB クライアント サーバーモデル インターネット時代のデータベース 大容量機能 パラレル処理 リニアスケーラビリティと高可用性の実 現 Oracle RAC Data Guard インフラストラクチャーのグリッド化 Grid Infrastructure 自動データベース化 コストパフォーマンスの限界を突破 Oracle Exadata Database Machine Copyright 2017 Oracle its affiliates. All rights reserved. Copyright 2017, Oracle and/orand/or its affiliates. All rights reserved.

8 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

9 NEW:300 以上の新機能を搭載した Oracle Database 12c Release 2 がいよいよ登場 データ マネジメントの変化に対応 今後 5 年 10 年先のお客様の投資を保護するため ディスクベースから In-Memory へ データウェアハウスから Big Data へ オンプレミスから Cloud に最適化されたデータベースへ 9

10 アップグレード後に目指すデータベース基盤のユースケース 1. データベース標準化と統合集約 3. クラウドを用いたシステムの拡張 運用コスト削減 テスト 開発 検証データ参照 データ参照 分析 12c 12c 2. 参照 / 分析用データベースの統合 4. 災害対策システム構築 データ同期 12c 12c OLTP 参照分析 DB リアルタイムデータの高速分析 クラウド 10

11 1.データベース標準化と統合集約 Oracle マルチテナント Databaseが革新的なコスト削減を実現 PDB PDB PDB シングル コンテナ DB (CDB) オペレーションとサービスの共有と集中化 Pluggable シングル コンテナ データベースにプラガブル データベース(PDB)としてデータベースを仮想化 低いOPEX 低いCAPEX さらに俊敏 多くのPDBを一つ サーバあたりに 簡単かつ高速に として管理 より多くのPDB PDBをプロビジョニ コンテナDBでパッ を構築 ング 移行 クロー チ アップグレード PDBはメモリと ン バックアップ スタン プロセッサを共 バイ 有 マルチテナントは劇的にソフトウェア管理を削減可能 一方で仮想化は増加 11

12 1.データベース標準化と統合集約 データベースの高密度集約(ITリソース有効活用) マルチテナントの集約率は インスタンス統合よりも高い 社内検証より 同じ環境だったら 250 同じ性能を出すには 1600MB シングルインスタンス マルチテナント構成 50 統合できるDBの数 5倍 同じ性能を出すために必要なメモリサイズを 87.5%カット(1/8に縮小) ライセンス/ハードウェアのコストを 節約できる 200MB メモリ* 87.5%カット *DBを動かすために必要なメモリサイズ 同環境なら 5倍の数のデータベースを統合可能 5倍の利用効率 高い費用対効果 参考: Oracle Multitenant: Study of Database Consolidation Efficiency 12

13 1. データベース標準化と統合集約 Oracle Multitenant : 大規模環境にも対応可能な統合と分離 コンテナあたり最大 4,096 PDB メモリー CPU I/O リソースの優先順位付け プライベート クラウドおよびパブリック クラウド間で設定可能な分離性 Pricing Retail Container Database 13

14 1.データベース標準化と統合集約 PDB単位のキャラクタセット CDB は AL32UTF8 PDBのキャラクタセット変換 は不要に 国際化キャラクタセットも PDB別に設定可 混在も可能 異なるキャラクタセット での統合が容易に UNICODE_TEST_STRING Arabic : العربية Chinese : 中文 English : English French : Français German : Deutsch Greek : Ελληνικά Hebrew : עברית Japanese : 日本語 Korean : 한국어 Portuguese : Português Russian : Русский Spanish : Español Thai : ไทย * SQL from sqlsnippets.com 14

15 2. 参照 / 分析用データベースの統合 In-Memory with Oracle Database 12c リアルタイム分析パフォーマンスシンプルな実装 OLTP と Analytics を同じデータベース上で 数秒以内のレポーティングとデータ分析 アプリケーションの変更不要 15

16 2. 参照 / 分析用データベースの統合 In-Memory with Active Data Guard : Exadata & Cloud Month In-Memory Production Year In-Memory Standby 本番データベースに全く影響を与えずにリアルタイム分析 スタンバイ データベースのリソースを有効活用できる 本番とスタンバイで異なるデータをポピュレーション可能 16

17 2. 参照 / 分析用データベースの統合 Oracle Database In-Memory 導入事例とユースケース 松井証券様 Data Warehouse 情報系システムに適用 定型業務や非定型的な分析用の 2 つ DB を統合 特に非定型分析が高速化 国内某流通業 Mixed Workload 基幹システムと DWH の統合 DWH 専用データベースのリプレース コストが約 50% 削減 本番データベースとリアルタイムに同期 Die Mobiliar Mixed Workload カスタムのリスク管理システム 専用アプライアンスのリプレース 分析クエリーが 倍高速化 データベース サイズが大幅に削減 国内某金融機関 DWH 顧客情報の分析 専用アプライアンスのリプレース 分析クエリーが300 倍高速化したものも 本番データベースとリアルタイムに同期 17

18 2. 参照 / 分析用データベースの統合 : Big Data へ拡張したお客様事例アプリログデータを活用し 顧客満足度の高度化を図る 某コーヒーチェーン様 アプリログ Beacon Wi-Fi プロモーション分析 顧客行動 モバイルアプリ改善 商品 サービス改善 SQL 顧客の 待ち時間 解消が目的 2015 年 9 月よりモバイル注文 & 決済サービス (Mobile Order & Pay) を全米 7,400 店舗で展開 顧客満足度向上のための更なる取り組み DWH 上の顧客データと アプリ ビーコン Wifi などのログデータを横断した分析 店舗分析 製品開発 プロモーション効果 顧客行動 顧客ニーズ分析 顧客情報 購入履歴 プロモーション ポイント 18

19 3. クラウドを用いたシステムの拡張 JSON Support in Oracle Database 12c Powerful SQL Analytics Oracle Database 12c JSON SQL RESTful サービスまたはネイティブ API によるアクセス JSON JSON 形式のデータ永続化 SQL による分析 19

20 3. クラウドを用いたシステムの拡張 Oracle REST Data Services REST-enable your data Oracle Database (Relational) REST Oracle Rest Data Services JSON Oracle Database (Document Store) Oracle NoSQL Database 20

21 21

22 4. 災害対策システム構築クラウドを活用した DR システム DR システムの利用用途 もちろん大規模な災害 / 障害時のため 普段はレポーティングや開発等の用途にも利用可能 パッチテスト環境 技術ホワイトペーパーで構成手順を記載 Public Cloud または Cloud Machine リソースを柔軟に増減できるのがクラウドのメリット On-Premises Primary Database (Active) Data Guard Sandbox Test/Dev in the cloud Oracle Cloud Standby Database Reporting 22

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

24 Oracle Databaseのライフタイムサポート 11gR2のExtended Support無償期限は2018年12月まで 12cR1のExtended Support無償期限は2019年7月まで Premium Support Extended Support(無償期間) Extended Support Sustaining Support パッチ提供期間 Oracle Oracle Oracle 現在 24

25 Oracle Databaseのアップグレード戦略例 Premium Support Extended Support(無償期間) Extended Support Sustaining Support パッチ提供期間 リスク最適型 堅実運用 派 Oracle 有償Extend Support 最大限活用 派 Oracle Oracle 新機能積極採用 派 12.1を経由するパターンもあり

26 アップグレード戦略と考え方 小規模なアップグレードやパッチ適用を組み込むことが戦略としても重要 リスク最適型堅実運用 派は まず へ 11g リリース2の無償延長サポート期間内に12c Release 2に移行しようとすると 移行先は12cリリース2の 初期リリースの想定が必要に 堅実運用 を求めるのであれば まず12c Release 1のターミナルパッチセット( )に移行してサポート期間を 確保した後 12c Release 2に移行するタイミングを伺う 新機能積極採用派 は へ 新機能の優位性を早く享受する ただし のサポート期間を鑑みながら(新規パッチが出なくなる) 12c Release 2の中で定期的にアップグレードしていく 有償延長サポート最大限活用派 は を最長2020年まで 一部のクリティカルな領域では11g Release 2(のターミナル)をできる限り長く使うことが求められるケースもあり そうし た場合は有償延長サポートを最大限に活用してこれを実現することが可能 移行期間や並行稼働期間を鑑み 2019年には12c Release 2への移行プロジェクトを開始する 26

27 Oracle Database アップグレード成功のために 何を活用するか アップグレードの目的を明確にする 必要な新技術は取り込みながら システムのレベルアップ どのバージョンか 戦略を明確にする システムの特性に応じた無理のない戦略をご検討ください できれば定期的なパッチ適用やアップグレードの適用を ある時点で 大きな変更 するより 小さな変更 を定期的に 小さな変更 を定期的に行うためのシステム構成もあります システムの安定 セキュリティ リスク低減にもつながります 27

28