Oracle Database: リリースモデルとアップグレード・パッチ計画 (2021年2月版)

Oracle Database
リリースモデルとアップグレード・パッチ計画
⽇本オラクル株式会社
テクノロジー事業戦略統括
2021年2⽉

本資料は、
• 2018年に導⼊されましたOracle Databaseのリリースモデル
• アップグレードやパッチ適⽤をどのように計画していくか
をご紹介しています。
はじめに
Copyright © 2021, Oracle and/or its affiliates
2

• リリースモデルに関する基礎知識
• アップグレード・パッチ計画の⽬的とベスト・プラクティス
• アップグレード・移⾏の⽅法
• アップグレード・パッチ適⽤におけるテストの効率化
• まとめ
アジェンダ
3

安定稼働のためのアップグレード・パッチ適⽤に関するベスト・プラクティス
運⽤フェーズでのベスト・プラクティス
1
2
3
Update/Revisionを定期的に適⽤する
ライフサイクルにアップグレードを組み込む
定期的な作業が可能なシステム構成と⼿順を採⽤する
l 実⾏計画、設定変更の必要な修正はデフォルトオフ(最⼩限のアプリ・テスト)
l 広く該当するまたは致命的な不具合修正と、最新セキュリティ・パッチを含む
l 新規パッチ提供期間中の年次リリースに保つ必要がある
l 次のLong Term Releaseに該当する年次リリースへのアップグレードを計画しておく
l 繰り返しの実⾏に耐えられるよう、⼿順・バージョンは標準化する
l 定期的なメンテナンスができるようにダウンタイムをコントロールする
4
アップグレードやパッチ適⽤をどのように計画していくか
にあたり、まずはリリースモデルについてご説明します

Oracle Database: リリース及びサポート・タイムライン
5
* as of February 2020
Release Schedule of Current Database Releases (Doc ID 742060.1)

Oracle Database: リリース及びサポート・タイムライン (詳細版)
6
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
EXTENDED
2027/4まで
19c 2024/4まで
現在のLong Term Release
Premier Support 5年/Extended Support 3年
18c 2021/6まで
各サポートレベルでの提供内容
Premier Support :
24x365⽇の技術問い合わせ、不具合修正とパッチ提
供、セキュリティ・アラートおよび修正、OS等の新規認証
Extended Support︓
24x365⽇の技術問い合わせ、不具合修正とパッチ提
供、セキュリティ・アラートおよび修正
Sustaining Support (PaaSは提供なし)︓
24x365⽇の技術問い合わせ、作成済のパッチ提供
* 詳細はOracle Software テクニカル・サポート・ポリシー参照
EXTENDED
12.1 12.1.0.1
12.1.0.2※
12.2.0.1 Limited Error
Collection
12.2.0.1のPremier Support2020/11/30まで。そ
の後2022/3/31までLimited Error Collectionを
提供。同期間はサポート料⾦は変わらず、Sev1
BugとSecurity修正のみ対応
11.2 EXTENDED
11.2.0.1
11.2.0.2
11.2.0.3
11.2.0.4※
11.2.0.4のExtended Supportは2020/12に終了。2022/12ま
でACSの追加サービスとしてMarket Driven Supportあり
21c 2023/6まで
最新のInnovation Release
Extended Supportは提供なし
オラクル社は、2020年にお客様が直⾯した前例のない経済的およびビジネス上の混乱に留意し、Oracle Database 20c Previewバージョンを⼀般提供しない決定をしました。
その代わりに、20cで提供予定であった機能をすべて21cリリースに組み込み、21cをAutonomous Database Free Tierで利⽤できるようにしています。
Paid Extended Support
Premier Waived Extended Support fee Limited Error Collection
* as of February 2020
Release Schedule of Current Database Releases (Doc ID 742060.1)

Long Term Release
• Premier Supportを5年間
• Extended Supportを3年間
• 安定性を重視し、⻑期間にわたってパッチ修正を提供
• ⻑期間安定して運⽤したいシステム向け
• 現時点ではOracle Database 19cが該当
Innovation Release
• Premier Supportを2年間
• Extended Supportは提供しない
• 多くの機能拡張や新しい機能を提供
• まず新しい機能を試したいお客様向け
• 現時点ではOracle Database 21cが該当
Oracle Database の2つのリリースタイプ
7
Build
QA
Ship

リリース・サイクルのイメージ
• Long Term Release: Premier Supportを5年間、Extended Supportを3年間提供
• Innovation Release: Premier Supportを2年間提供
Oracle Database の2つのリリースタイプ
8
19c
21c
新規パッチの提供が受けられるのは、
最⻑Extended Supportまで

Oracle Database 18c より採⽤したリリースモデル
年次リリースモデル
9
Update
四半期ごと
• 四半期毎に新しい
番号でリリース
• セキュリティ修正
• リグレッション修正
• 機能修正
• オプティマイザ修正
(デフォルトではオフ)
Revision
四半期ごと
• Updateに対し最⼤2つ
ü 0, 1, 2
• セキュリティ修正
• リグレッション修正
リリース
毎年
• リリース年の下⼆桁
ü 18 : 2018年
ü 19 : 2019年
ü 20 : 2020年
• 新機能
• 性能 (パフォーマンス) 向上
• バグ・フィックス
: 19． 3． 0
バージョン
表記例
Oracle Database - Overview of Database Patch Delivery Methods for 12.2.0.1 and later versions (Doc ID 2337415.1)

Oracle Database 18c より採⽤したリリースモデル
Annual Releases
• 従来の11g -> 12c, R1 -> R2といった数年に⼀度のサイクルから「年次リリース」に変わりました
バージョン番号はリリース年の下⼆桁となります
• 従来計画されていた12.2.0.2はRelease 18、12.2.0.3はRelease 19というバージョンとなっています
• Long Term Release と Innovation Release
• Long Term Support Release : 現時点では19c、数リリースに⼀度、Extended Supportも含め⻑期間のサポート提供
• Innovation Release : 現時点では21c、多くの機能拡張や新しい機能を提供
３ヶ⽉ごとのUpdateとRevision
• Updateはプロアクティブパッチで既存で⾒つかった重要な機能修正やセキュリティ修正が含まれます
• RevisionはUpdateリリース以降の新たなセキュリティおよびリグレッション修正が含まれます
• 社内で⼗分なテストを⾏った後に提供されます
• Updateは個別のパッチ適⽤を⾏うリスクを低減するためのものです
UpdateとRevisionは1⽉、4⽉、7⽉、10⽉にリリースされます
• 以前のバージョンのBPやPSUのリリースサイクルと同等です
年次リリースモデル
10 Oracle Database - Overview of Database Patch Delivery Methods for 12.2.0.1 and later versions (Doc ID 2337415.1)

年次リリースモデルにおけるリリースイメージ
製品 2018/4 2018/7 2018/10 2019/1 2019/4 2019/7 2019/10
18c 18.2.0 18.3.0 18.4.0 18.5.0 18.6.0 18.7.0 18.8.0
18.2.1 18.3.1 18.4.1 18.5.1 18.6.1 18.7.1
18.2.2 18.3.2 18.4.2 18.5.2 18.6.2
19c 19.2.0 19.3.0 19.4.0 19.5.0
19.2.1 19.3.1 19.4.1
19.2.2 19.3.2
同じ
セキュリティ
リグレッション
レベル
Update/Revision 間は柔軟に⾏き来が可能
11

各データベース・バージョンのサポート期間
対象サービス
• Exadata Cloud (Public & Cloud@Customer)を含む全てのデータベース・サービス
サポート終了
• 基本的にオンプレミスのライフタイム・サポートに準拠して設定
(オンプレミスにおけるエラー修正終了時に、クラウドではサポート終了となり、Sustaining Supportは提供されない)
• セキュリティ・パッチを含むパッチ提供を終了、新規プロビジョニングを終了
• 当該バージョンのインスタンス稼働は保証されない (速やかなアップグレードもしくはインスタンス停⽌を推奨)
データベース・クラウド(PaaS)
12 Release Schedule of Current Database Releases (Doc ID 742060.1)
クラウドでの提供開始サポート終了
11g R2 (11.2.0.4) 2014年9⽉ 2021年3⽉31⽇
12c R1 (12.1.0.2) 2014年9⽉ 2022年7⽉31⽇
12c R2 (12.2.0.1) 2017年3⽉ 2022年3⽉31⽇
18c (12.2.0.2相当) 2018年3⽉ 2021年6⽉30⽇
19c (12.2.0.3相当) 2019年1⽉ 2027年4⽉30⽇
21c 2020年12⽉ 2023年6⽉30⽇
オンプレミスとの違い

まとめ
Oracle Databaseには2つのリリースタイプがあります
• ⻑期間安定して運⽤したいシステムにおいては、Long Term Releaseを採⽤します
パッチは四半期ごとに提供されます
• 重要な機能修正やセキュリティ修正へ対応するため、定期的に適⽤します
• 新規パッチの提供が受けられるのは、最⻑Extended Supportまでです
データベース・クラウド(PaaS)での留意点
• 基本的にオンプレミスのライフタイム・サポートに準拠してサポート期間が設定されています
• オンプレミスにおけるエラー修正終了時に、クラウドではサポート終了となり、Sustaining Supportは提供
されません
リリースモデルに関する基礎知識
13

• まとめ
アジェンダ
14

なぜアップグレードやパッチ適⽤を計画してくのか︖
アップグレード・パッチ計画の⽬的
15
安定稼働⻑期保守対応新機能の活⽤/機能
拡張
1 2 3

最新のセキュリティ・パッチの適⽤は、システムやサービス、データを攻撃から守るために必須
• セキュリティ・パッチがリリースされるタイミングで、セキュリティに関する問題や研究内容も同時に世界に向けて発信される
• アップグレードしないということは、攻撃者にとって明らかな問題を放置することと同義
アップグレードを運⽤に組み込むことで、システム・ダウンや結果不正などの重⼤な問題に予め対応でき、シス
テムの安定性が向上する
• 問題発⽣前にメンテナンスすることで、アップグレードせずに発⽣した問題に対応する場合と⽐較して、原因調査にかかる時間やコス
トを少なく抑えられる
1. 安定稼働
16
安定稼働の要件とは︖
「計画外で停⽌しない」「パフォーマンスが劣化しない」
「データが破損・漏洩しない」「不具合が発⽣しない」

17
Security
The most important reason to
upgrade and patch
アップグレードやパッチ適⽤の最も重要な⽬的はセキュリティ対策
アップグレード・パッチ適⽤の重要な⽬的

18
パッチ適⽤が遅れた情報漏洩事例
Source: https://www.nytimes.com/2019/07/22/business/equifax-settlement.html
Equifax社がデータ漏洩の解決のために、
過去最⼤の約6億5,000万ドルを⽀払う

外部接続されていないシステムも例外ではない
of malware
is delivered
via email
92%
92%のマルウェアがE-mailで配信されている

不具合にまつわる⼀つの事実
Exadataのお客様が遭遇した
不具合のうち、約70%は既存の
バンドルパッチやパッチセットで
修正済みのものであった
Oracle Corporation ⽶国開発部⾨バイスプレジデント Eleanor Meritt講演資料より
20

統合DB基盤で発⽣した障害の分析
あるお客様における安定稼働への取り組み例
製品不具合
運⽤上の
問題
⾼負荷/
設計上の
問題
0%
25%
50%
75%
100%
既知
新規
6〜8カ⽉
9〜11カ⽉
12か⽉
以上
1年間に発⽣した
障害の主な要因
新規/既知の
件数
発⽣の何か⽉前に
修正済みだったか︖
21

統合DB基盤で発⽣した障害の分析
あるお客様における安定稼働への取り組み例
製品不具合
運⽤上の
問題
⾼負荷/
設計上の
問題
0%
25%
50%
75%
100%
既知
新規
6〜8カ⽉
9〜11カ⽉
12か⽉
以上
1年間に発⽣した
障害の主な要因
新規/既知の
件数
発⽣の何か⽉前に
修正済みだったか︖
製品不具合に起因する障害のうち、
90%以上は既知の不具合が原因
であり、予防可能であった
既知の不具合は、すべて障害発⽣の6
カ⽉以上前に修正済みであり、
半年に⼀回の定期パッチ適⽤でも
防ぐことができた
22

サポート期間バージョンへアップグレードすることにより、新規パッチの提供が受けられます
• Long Term Release: Premier Supportを5年間、Extended Supportを3年間提供
• Innovation Release: Premier Supportを2年間提供
2. ⻑期保守対応
23
19c
21c
新規パッチの提供が受けられるのは、
最⻑Extended Supportまで

約11年で1,300以上に上る新機能および機能強化を実現
3. 新機能の活⽤/機能拡張
223 341 337 100 216
(Release 2)
※製品マニュアルにおける各リリースの新機能情報より抽出
※20c Preview Releaseは⼀般提供されず、すべての機能を21cに含めて提供
134
(Release 1) (Release 2)
• Data Redaction(11.2.0.4)
• RACcheck(11.2.0.4)
• GoldenGate統合(11.2.0.4)
• Solaris⽤TDE(11.2.0.3)
• サービス品質(QoS)管理(11.2.0.2)
• Database Replay(11.2.0.2)
• 各種管理機能強化(11.2.0.2)
• ブロック⾃動修復(11.2.0.1)
• EditionBase再定義(11.2.0.1)
• インメモリー・パラレル実⾏
(11.2.0.1)
• RAC機能強化多数(11.2.0.1)
• XStream(11.2.0.1)
• ACFS,DBFS(11.2.0.1)
• SecureFilesのサポート(11.2.0.1)
等
• Full Database
Caching(12.1.0.2)
• 各種インメモリー機能
(12.1.0.2)
• JSON対応(12.1.0.2)
• PDB機能強化(12.1.0.2)
• ゾーン・マップ(12.1.0.2)
• APEX機能強化(12.1.0.1)
• ヒート・マップ(12.1.0.1)
• Multitenant(12.1.0.1)
• Application
Continuity(12.1.0.1)
• Global Data
Services(12.1.0.1)
• ADG遠隔同期(12.1.0.1)
等
• Sharding
• Hadoop向け外部表
• MVIEW関連強化
• パーティション機能追加
• Multitenant,PDB,CDB機
能強化
• Exadata関連管理機能拡
張
• ADGでのIn-Memoryサ
ポート
• パブリック・クラウド対応
• ⾼可⽤性および信頼性各
種機能強化
等
• プライベート⼀時表
• RAC Sharding
• Big Data SQLのLOB対応
• DG環境でのPDBコピー
• DBCA PDBクローン
• PDBスナップショット・カルー
セル
• インメモリー式の動的取得
ウィンドウ
• ⾃動インメモリー
• 外部表に対するIn-
Memoryサポート
• インメモリー動的スキャンによ
る柔軟な並列化
• セキュリティ機能強化
等
• ⾃動索引付け
• Active Data Guard DML
リダイレクション
• Memoptimized
Rowstoreの⾼速収集
• 同じCDBでの複数のPDB
シャードのサポート
• ハイブリッド・パーティション表
• リアルタイム統計
• ADDMによるPDBサポート
• 粒度の⾼いサプリメンタル・ロ
ギング
等
• In-Database JavaScript
• JSON 性能強化と柔軟性
• In-Memory 性能向上
• AutoML
• Multitenant Data Guard
• SQL マクロ
• Native Blockchain
Tables
• Graph 性能強化
• Persistent Memory
• Sharding 機能拡張
• Multitenant セキュリティ
• Security 機能拡張
等
24

なぜアップグレードやパッチ適⽤を計画してくのか︖
アップグレード・パッチ計画の⽬的
25
安定稼働⻑期保守対応新機能の活⽤/機能
拡張
1 2 3

安定稼働のためのアップグレード・パッチ適⽤に関するベスト・プラクティス
運⽤フェーズでのベスト・プラクティス
1
2
3
Update/Revisionを定期的に適⽤する
ライフサイクルにアップグレードを組み込む
定期的な作業が可能なシステム構成と⼿順を採⽤する
l 実⾏計画、設定変更の必要な修正はデフォルトオフ(最⼩限のアプリ・テスト)
l 広く該当するまたは致命的な不具合修正と、最新セキュリティ・パッチを含む
l 新規パッチ提供期間中の年次リリースに保つ必要がある
l 次のLong Term Releaseに該当する年次リリースへのアップグレードを計画しておく
l 繰り返しの実⾏に耐えられるよう、⼿順・バージョンは標準化する
l 定期的なメンテナンスができるようにダウンタイムをコントロールする
26
この後は、どのような⽅法やツール
があるのかをご紹介していきます

• まとめ
アジェンダ
27

直接アップグレード
• データベースに含まれるデータ・ディクショナリを新しい
バージョンに更新すること
• JAVAVMなどのコンポーネントも含まれる
• ユーザー・データへの接触や変更、移動はない
新バージョンへの移⾏
• データベースのデータを新しい環境のデータベース
(ハードウェア、オペレーティング・システム / プラット
フォーム、キャラクター・セット)へ移動すること
直接アップグレードと新バージョンへの移⾏の違い
28

ユーティリティ、機能
直接アップグレード
• AutoUpgrade
• クラウドツールによるアップグレード
新バージョンへの移⾏
• Data Pump
• トランスポータブル表領域
• トランスポータブル表領域
• クロスプラットフォーム・トランスポータブル表領域
• 増分クロスプラットフォーム・トランスポータブル表領域
• フル・トランスポータブル表領域
• Oracle GoldenGate
• Oracle Zero Downtime Migration
• Cloud Backup Module for OCI
• など
直接アップグレードと新バージョンへの移⾏の違い
29

直接アップグレードについて
オンプレミスではAutoUpgrade、クラウドではクラウドツールによるアップグレードがそれぞれ登場し、
ボタン⼀つで簡単にアップグレードが可能になっています。
バックアップや切り戻しもツールで実⾏可能なため、アップグレード⼿順の複雑さ、
対応⼯数によるコストは年々低減されています。
アップグレードや移⾏は難しい︖
30
アップグレードは⼿順が複雑だったり、バックアップや切り戻しを検討するのが⼤変。。

AutoUpgrade
最新の⾃動アップグレードユーティリティ (アップグレード元は11.2.0.4以降)
• Configファイルを編集し、ツールを実⾏して⾃動アップグレード
• 事前チェックのみ、実⾏前後にユーザ定義のスクリプト処理などDBUAよりも柔軟に実⾏可能
参考資料
• Oracle Databaseデータベース・アップグレード・ガイド [3 Oracle DatabaseアップグレードでのAutoUpgradeの使⽤]
• The new AutoUpgrade utility in Oracle 19c (Oracle社 PM Mike Dietrichのブログ記事)
• Upgrade / Migrate / Consolidate to 19c [Japanese Version] / AutoUpgrade ハンズオンラボ
オンプレミスにおけるアップグレード
31
18.4
11.2.0.4
12.1.0.2
12.2.0.1
autoupgrade.jar
MOS Note: 2485457.1
4MB
config.cfg
autoupgrade.jar
12.2.0.1
18.5
19.6

クラウドツール
• コンソール、APIを使⽤して
DBCS BM/VM、ExaCSの
Oracle Database 19cへの
アップグレードが可能
• 事前チェックの実⾏により
アップグレード要件を満たしているか
確認可能
• アップグレードで問題が発⽣した
場合はロールバックが可能
• パッチも同⼀コンソールから
適⽤可能
クラウドにおけるアップグレード
32

新バージョンへの移⾏について
移⾏⽅式は要件に沿って様々ありますが、ポイントを考慮することで最適な移⾏⽅式が明確になります。
考慮すべきポイントは以下の通りです。
アップグレードや移⾏は難しい︖
33
データベース移⾏は⽅式がたくさんあってどれを選べばいいかわからない。。
• 移⾏先がクラウドかオンプレミスか
• 許容されるシステム停⽌の⻑さ
• ホスト・オペレーティング・システムとバージョン
• データベースのバージョン/エディション
• データベースの⽂字セット
• インデックスを含むデータの量
• データベースで使⽤されるデータ型
• データ・ステージングのためのストレージ
• データベースのホスト・プラットフォームのエンディアン形式
• データベースアーキテクチャ(Multitenant)
• ネットワーク帯域幅

主な移⾏⽅式⼀覧
34
移⾏ツール移⾏対象
最低移⾏元バージョ
ン(サポート中のDBの
み記載)(*1)
移⾏元
エディション
アップグレード
可否
ビックエンディアンからの
変換
スキーマ構成
の変更
non-CDBか
らCDBへの
移⾏
停⽌時間補⾜
Data Pump
DB/表領域/
スキーマ/表
11.2.0.4 SE〜〇〇〇〇⼤〜中
RMAN Backup/Restore DB 11.2.0.4 SE〜〇〇（⼀部制限あり） × ×(*3) 中〜⼩
RMAN Duplicate DB 11.2.0.4 SE〜〇〇（⼀部制限あり） × × ⼩
Transportable
Tablespaces
表領域 11.2.0.4 EE 〇〇（⼀部制限あり） × 〇中〜⼩移⾏先DBはEE以上が必要
Full Transportable
export/import
DB 11.2.0.4 EE 〇〇（⼀部制限あり） × 〇中〜⼩
移⾏先DBはEE以上が必要
移⾏先DBバージョンは12.1.0.1以降
RMAN Transportable
Tablespaces
DB/表領域 11.2.0.4 EE 〇〇（⼀部制限あり） × 〇中〜⼩移⾏先DBはEE以上が必要
PDB Unplug/Plug PDB 12.1.0.2 SE〜〇 × × × 中〜⼩
PDB Clone PDB 12.1.0.2 SE〜〇 × × × ⼩
Non-CDB Clone DB 12.1.0.2 SE〜 × × × 〇⼩
Data Guard DB 11.2.0.4 EE × × × × 極⼩移⾏先DBはEE以上が必要
GoldenGate
DB/表領域/
スキーマ/表
11.2.0.4(*2)
SE〜＋
GoldenGate
〇〇〇〇極⼩
ダウンタイムを極⼩化したい場合に
他の移⾏⽅式と併⽤しての利⽤を推奨
Cloud Backup Module
for OCI
DB 11.2.0.4(*2) SE〜 × × × × 中 Oracle Cloud Infrastructureへの移⾏
Zero Downtime
Migration(ZDM)
DB 11.2.0.4(*2) SE〜 × × × × 極⼩
Oracle Cloud Infrastructureへの移⾏
移⾏元ライセンスによって
選択可能な移⾏⽅式が異なる
アップグレードを伴う
移⾏は〇から選択
(*1)サポートされている最低バージョン。これよりも古いバージョンでのサポート可否は都度確認が必要。
(*2)利⽤製品/バージョン/OS等、ソースDBのサポート可否は都度確認が必要。
(*3)non-CDBが18c以降である場合はDBMS_PDB.EXPORTRMANBACKUPを活⽤することで実現可能
https://oracle-base.com/articles/18c/multitenant-usable-backups-of-non-cdbs-and-relocated-pdbs-18c

採⽤されることの多い移⾏⽅式とその理由
移⾏⽅式の選び⽅
35
Data Pump
・馴染みの深い移⾏⽅式で移⾏したい
・移⾏に伴いスキーマ構成を変更したい
GoldenGate ・移⾏期間中もなるべく停⽌期間を少なくしたい
・クロスプラットフォームの移⾏をしたい
・RMANと組み合わせて停⽌期間を短くしたい
Transportable
Tablespaces

GoldenGate
切替時間を極⼩化したデータベース移⾏
1) システム移⾏前 2) システム切替当⽇ 3) システム移⾏後
切り戻し
に活⽤
現⾏DB 新環境DB 現⾏DB 新環境DB 現⾏DB 新環境DB
GoldenGate GoldenGate GoldenGate
36

世界に誇る鉄道システム基盤の安全なリプレイスに成功
お客様概要
• 東⽇本旅客鉄道株式会社 (http://www.jreast.co.jp/ )
̶ 業種︓Travel and Transportation
̶ 従業員数︓58,550⼈（2015年4⽉1⽇現在）
• 株式会社ＪＲ東⽇本情報システム (http://www.jeis.co.jp/ )
̶ 業種︓High Technology
̶ 従業員数︓1,508⼈（2015年4⽉1⽇現在）
課題
• 2015年7⽉の輸送総合システムのリプレイスにおいて、サービス停⽌時間の極⼩化
や利⽤者側への負担などの影響を発⽣させることなく、新旧システム間で14サブシス
テムの業務アプリケーションの切替が必要
• 毎⽇実⾏するクリティカルな夜間バッチ処理については、新旧データベース間の同期
遅延時間を30分以内に収めることが必要
• 2015年3⽉、北陸新幹線⾦沢開業や上野東京ライン開業を含む例年以上に⼤
規模なダイヤ改正実施の状況下でも列⾞運⾏業務に影響を与えることなくシステム
リプレイスが必要
導⼊効果
• Oracle GoldenGateを採⽤し新旧データベース間を同期させたことで、システムの
運⽤制限を排除し、ＪＲ東⽇本の列⾞運⾏業務に影響を与えることなくスムーズ
なシステムのリプレイスを実現
• 夜間バッチ処理の実⾏中における新旧データベース間のデータ同期遅延時間を約5
分へ⼤幅な短縮に成功
• Oracle GoldenGate Veridataの採⽤でデータ整合性の確認を実現。通常期よ
りデータの更新量が増⼤するダイヤ改正の時期にも、⾼い安⼼感のなかで切替作業
を完遂
お客様の声
「Oracle GoldenGateとOracle GoldenGate Veridataの採⽤により、2015年3
⽉の⼤規模なダイヤ改正もあるなか、ＪＲ東⽇本の輸送総合システムのリプレイスを
スムーズに実施することができました。オラクルのコンサルタントによるスキルトランスファー
が、当社のエンジニア育成につながったことも⼤きな成果です」―株式会社ＪＲ東⽇
本情報システム鉄道・⽣活サービス部⾨鉄道システム部次⻑平野聖⼈⽒
顧客事例︓東⽇本旅客鉄道株式会社様
株式会社ＪＲ東⽇本情報システム様
製品とサービス
• Oracle GoldenGate
• Oracle GoldenGate Veridata
• Oracle Consulting
37

• まとめ
アジェンダ
38

パフォーマンスに問題の出るSQLを特定してチューニングする
アプリケーション・テストの負荷を下げる
「すべてのアプリケーションのすべてのSQLをテストでチェックすることはできない」
• アップグレードなどで環境が変わる場合、すべてのSQLの性能が劣化するわけではなく、逆に殆どのSQLで性能は向上する
• 性能が劣化するSQLだけを簡易かつ正確に抽出できれば、チューニングをおこなうSQLの数を削減できる
「本番環境と同じ環境を再現するだけのテストシナリオを⽤意することは無理だ」
• 本番環境で実⾏されたSQLをそのまま実⾏できれば、実際の環境と同じユースケースと実⾏負荷が再現できる
• 更にシナリオの検討とスクリプトの準備に費やす時間が不要になる
アプリケーション・テストの負荷
単体・結合テスト SQL性能確認シナリオ準備シナリオ性能テスト統合・移⾏テスト
この部分の負荷を抑えたい
39

Real Application Testing (RAT)
40
リスクの最⼩化
⾃動化
コスト削減
データベース
・リプレイ
データベース
統合リプレイ
SPA
SPA
クイックチェック
SPA = SQL Performance Analyzer
§ 負荷テストのソリューション
§ 問題を検出して修正
• SQL応答時間のテスト・
ソリューション
• 性能に問題のあるSQLを
識別し、調整
• オンプレミス、あるいは
Oracle Cloudのための
データベース統合の
キャパシティ・プランニング
• データベースの性能に対する
定期的なDBAタスクを事前
に特定
ü アップグレードやパッチ適⽤など、インフラ変更に伴うテストを⼤幅効率化
ü SQL単位の詳細⽐較や本番ワークロードを使ったリアルなテスト
ü アプリケーションに⼿を加えず、インフラチーム主体でテストを実施

オープン系共通基盤のハードウェアEOSLに伴う更改を実施
お客様事例︓国内⼤⼿保険会社様
41
オープン系共通基盤DB Migration（保険の契約・⽀払、Web関連システム）
•画⾯数 ︓約740画⾯
•バッチジョブ数︓約200ジョブ合計︓約28万SQLのテストを実施する必要あり
•テスト計画 ︓ 2⼈⽉
•アプリ解析 ︓ 4⼈⽉
•検証環境の構築 ︓ 2⼈⽉
•テスト・検証 ︓175⼈⽉
•チューニング ︓ 5⼈⽉
•テスト計画 ︓ 1⼈⽉
•アプリ解析 ︓ 0⼈⽉
•検証環境の構築 ︓ 1⼈⽉
•テスト・検証 ︓ 1⼈⽉
•チューニング ︓ 1⼈⽉
400万円
1.88億円
28万SQL÷5トランザクション×0.5時間
＝28,000時間(175⼈⽉)
28万SQLの10分の1のテストだと30.5⼈⽉。3,050万円
テスト・検証は、6⼈で、たった3⽇で完了
パフォーマンス変動なし ︓94.38％
改善 ︓ 5.37％
劣化 ︓ 0.01％
SQL構⽂エラー ︓ 0.24％
RATを利⽤したアップグレードテスト
従来のアップグレードテスト
テスト効率&精度の向上とプロジェクトのコスト&リスクの⼤幅削減に成功
⾼い効果が認められ標準プロセスに
ü 1回⽬︓ 11gR1 à 11gR2
ü 2回⽬︓ 11gR2 à 12cR2
ü 3回⽬︓ 12cR2 à 19c

42
アップグレードやパッチ適⽤の評価はOracle Cloud Infrastructureで
Oracle Cloud Infrastructure活⽤のメリット
• Oracle Database 19c環境が⾼速・簡単に構築可能
• Enterprise EditionならReal Application Testingを利⽤可能
これにより、より品質の⾼い移⾏評価を⾼速に実施可能
• Enterprise EditionならTuning Packを利⽤可能
移⾏時のSQLチューニング⼯程が簡単⾼速に
Oracle Cloud Infrastructureの利⽤で
簡単、⾼速、安価な移⾏評価が実施可能

FX取引システムにおけるデータベース・アップグレード時のテスト⼯数を⼤幅削減
課題・ニーズ
• データベースのアップグレードを実施
• 影響度テスト負荷・コストを削減したい
• 短期間でアップグレードを実施したい
ソリューション
DBCS＋RAT でテストを実施
• Oracle Database Cloud Serviceを⽤い、コストを抑えテ
スト環境を準備
• テスト・ソリューション (RAT) を⽤い効率的に短期間でDBテ
ストを実施
• 2,100本以上のSQLからチューニングが必要なSQLを特定
ベネフィット
通常のアップグレードと⽐較し、約7割のコスト削減を実現
お客様事例︓外為どっとコム様
AP
本番環境
変更後の環境に対してSQL
単体テスト実⾏(SPA試⾏)
Oracle Database Oracle Database (New Version)
STS
SPA
STS
STSをCloud環境
にインポート
Oracle Database Cloud 環境
レポート⽣成
https://www.oracle.com/jp/corporate/pressrelease/jp20170227.html
43

• まとめ
アジェンダ
44

アップグレード・パッチ計画の⽬的とベスト・プラクティス
• (1)安定稼働 (2)⻑期保守対応 (3)新機能の活⽤/機能拡張
には、アップグレード・パッチ計画が不可⽋です
• 定期的なパッチ適⽤と、システム・ライフサイクルへのアップグレードの組み込みが重要です
定期的な作業が可能なシステム構成や⼿順
• 要件に合わせたアップグレード⽅法が確⽴されています
• ダウンタイムが極めて少ないアップグレードの事例も数多くあります
• ツールを活⽤することで、アプリケーション・テストの負荷を⼤幅に下げることができます
• システムのクラウド化はもちろん、テストにおけるクラウド活⽤も、負荷を下げることにつながります
まとめ
45

Oracle Databaseのパッチやアップグレードに関する情報
Oracle Databaseに関するパッチのマスターノート
• Release Schedule of Current Database Releases (Doc ID 742060.1)
• Oracle Database (RDBMS) Releases Support Status Summary (Doc ID 161818.1)
不具合修正の提供⽅法と⽅針について説明
• Database、FMW、Enterprise Manager、TimesTen In-Memory Database および OCS に関する不具合修
正のポリシー(KROWN:54775) (Doc ID 1719011.1)
• KROWN#54775に関する製品ごとの補則および追加説明(KROWN:127321) (Doc ID 1741630.1)
その時点での推奨パッチの情報
• Oracle Recommended Patch -- Oracle Database(KROWN:132780) (Doc ID 1745092.1)
パッチに関する様々な情報を集約
• Information Center: Patching and Maintaining Oracle Database Server/Client Installations (Doc ID
1351428.2)
パッチに関するFAQ
• Frequently Asked Questions (FAQ): Patching Oracle Database Server (Doc ID 1446582.1)
参考情報
46

Oracle Database 19cへのアップグレード
Best Practices for Oracle Database Upgrade to 19c (Doc ID 2690728.2)
Oracle Databaseデータベース・アップグレード・ガイド, 19c
• https://docs.oracle.com/cd/F19136_01/upgrd/index.html
Oracle Database Technology Night #35「データベース・アップグレード成功のために知っておきたいこと」
• https://www.oracle.com/jp/database/events-docs/001/
参考情報
47

Oracle Database: リリースモデルとアップグレード・パッチ計画 (2021年2月版)

Oracle Database: リリースモデルとアップグレード・パッチ計画 (2021年2月版)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Oracle Database: リリースモデルとアップグレード・パッチ計画 (2021年2月版)

Similar to Oracle Database: リリースモデルとアップグレード・パッチ計画 (2021年2月版) (20)

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

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

Recently uploaded

Recently uploaded (14)

Oracle Database: リリースモデルとアップグレード・パッチ計画 (2021年2月版)