オンプレミスからクラウドへ：Oracle Databaseの移行ベストプラクティスを解説 (Oracle Cloudウェビナーシリーズ: 2021年2月18日)

オンプレミスからクラウドへ︓
Oracle Databaseの移⾏ベストプラクティスを解説
2021年2⽉18⽇
⽇本オラクル株式会社
テクノロジー事業戦略統括
ビジネス推進本部
⼭本祐介
Oracle Cloud ウェビナー
プロフェッショナルシリーズ

1. Oracle Databaseのリリースモデル
2. Oracle Cloud Infrastructureにおけるデータベース・サービス
3. オンプレミスからデータベース・サービスへの移⾏⽅法
4. 移⾏時におけるテストの効率化
アジェンダ
Copyright © 2021, Oracle and/or its affiliates
2
プロジェクト検討テスト移⾏作業
①, ② ④ ③
移⾏プロジェクトの流れと本セミナーでお話する項⽬

アジェンダ
3

Oracle Database: リリース及びサポート・タイムライン
4
* 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つのリリースタイプ
5
Build
QA
Ship

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

Oracle Database 18c より採⽤したリリースモデル
年次リリースモデル
7
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のリリースサイクルと同等です
年次リリースモデル
8 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 間は柔軟に⾏き来が可能
9

各データベース・バージョンのサポート期間
対象サービス
• Exadata Cloud (Public & Cloud@Customer)を含む全てのデータベース・サービス
サポート終了
• 基本的にオンプレミスのライフタイム・サポートに準拠して設定
(オンプレミスにおけるエラー修正終了時に、クラウドではサポート終了となり、Sustaining Supportは提供されない)
• セキュリティ・パッチを含むパッチ提供を終了、新規プロビジョニングを終了
• 当該バージョンのインスタンス稼働は保証されない (速やかなアップグレードもしくはインスタンス停⽌を推奨)
データベース・クラウド(PaaS)
10 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は提供
されません
リリースモデルに関する基礎知識
11

アジェンダ
12

Oracle Cloud Infrastructureを基盤に、Autonomous DatabaseやPaaS, SaaSを提供
Oracle Cloud
13
IaaS
PaaS
コンピュートストレージコンテナネットワークセキュリティ
Autonomous
Transaction
Processing
Autonomous
Data Warehouse
Autonomous Database
(⾃律型データベースクラウド)
データ管理アプリケーション開発
インテグレーション
アナリティクスコンテンツ管理
セキュリティ・IT管理
SaaS
ERP/EPM SCM HCM CX
Oracle Cloud Infrastructure (OCI) / Cloud@Customer (顧客DC)
Cloud
Applications
Oracle
Cloud
Infrastructure

Oracle Cloud Infrastructure が採⽤される理由
14
より良いサービスを
適切な価格で
より堅牢な
セキュリティの実現
よりデータ活⽤に
最適な環境
1 2 3

ミッションクリティカル・エンタープライズ・ワークロードのため
0から設計・構築したクラウド基盤
15
リージョン
(東京、⼤阪など）
物理ネットワーク
仮想クラウド・ネットワーク
サービス
AD1 AD2 AD3
• 物理コア専有環境
• ⾼速なハードウェアを標準採⽤
• ネットワーク仮想化を分離し、
専⽤のハードウェアで実⾏
• 低遅延/⾼帯域
• フラットなネットワーク
• オーバーサブスクリプションなし
• 1年で17から29リージョンへ展開
• お客様DCへの展開も可能に
• マルチクラウドへの拡張
SaaS Applications DWH Big Data AI HPC/Simulation
ISVs
ミッションクリティカル・システム⼤規模ワークロード

⼀般的な可⽤性だけでなく、性能/管理も加える
安定した⾼速な基盤を元に、業界初のSLAを定義
16
可⽤性
(利⽤できるか)
性能
(性能を満たしているか)
管理
(管理操作ができるか)
https://www.oracle.com/cloud/iaas/sla.html
A社 B社

利⽤頻度の⾼いサービス３つ全てで低価格を実現
圧倒的なコストパフォーマンス
17
Oracle の強み Oracle 他社クラウド
Compute ü 同⼀リソースを低価格で
提供
ü より⾼性能なリソースも提
供可能
¥61.25/時
Compute
(VM.Standard2.8;
16vCPU, 120GB, Linux)
¥119.94/時
仮想マシン
(16vCPU, 64GB, Linux)
Storage ü 他社標準ストレージ価格
で、⾼性能ストレージを
提供
ü IOPS設定＋SLA
¥5,100/⽉
Block Volume
(1TB, 25K IOPS)
¥239,040/⽉
ブロック・ストレージ
(1TB, 25K IOPS)
Network ü AD間無償
ü 10TB/⽉まで無償
ü 閉域網接続時はデータ
転送無償
¥18,972/⽉
FastConnect
(1Gbps, 100TB)
*閉域網接続
¥517,445/⽉
接続サービス
(1Gbps, 100TB)
*閉域網接続
¥
49%
低価格
¥
97%
低価格
¥
96%
低価格
Compute: 同⼀リソースを低価格で提供(メモリは約2倍)
Storage/Network:トランザクションやデータ転送量による料⾦変動を低減する料⾦体系
* as of August 2020, Tokyo Region

セキュリティ・ファーストで設計されたクラウド
より堅牢なセキュリティの実現
18
データ中⼼の
セキュリティ
⾃動化された
セキュリティ
管理
セキュリティ
・バイ・デザイン
SECURITY ON THE CLOUD
SECURITY OF THE CLOUD
＋
顧客環境の強⼒な分離
強制的な暗号化
越権できないリソース管理
ネットワーク攻撃遮断
特権ユーザーのアクセス制御
重要情報の隠蔽
⾏・列レベルでのアクセス制御
各種サービスへの認証・認可
データセキュリティ対策⾃動化
安全な設定の強制
リスクのある設定を⾃動検知
⾃動化されたIT管理・分析

19
Zoom
Oracle Cloud Infrastructure上でビデ
オ会議ソリューションを展開
“We chose Oracle Cloud Infrastructure because of
its industry-leading security, outstanding
performance, and unmatched level of support.”
“業界をリードするセキュリティ、卓越したパフォーマンス、⽐類
なきサポート・レベルが『Oracle Cloud Infrastructure』を選
定した理由です”
Eric S. Yuan
CEO, Zoom
• 企業向けビデオ・カンファレンスのリーダーカンパニー
• COVID-19の影響により、1⽇の会議参加者数が3
億⼈に急増
• 数時間で展開を完了し、同時会議接続
数⼗万⼈をサポート
• 世界中のOracle Cloud Infrastructureの
プラットフォームを介して、
1⽇あたり7ペタバイト以上をデータ転送
https://www.oracle.com/jp/corporate/pressrelease/jp20200428.html

2020年12⽉現在︓29リージョン提供中、さらに9リージョン計画 (2020年は12リージョン開設)
Oracle Cloud Infrastructure(OCI)のリージョン
20
SAN JOSE, CA
PHOENIX
CHICAGO
ASHBURN
TORONTO MONTREAL
MUMBAI
HYDERABAD
SINGAPORE
CHUNCHEON
SEOUL
ASIA
TOKYO
OSAKA
JOHANNESBURG
SYDNEY
MELBOURNE
Commercial
Commercial Planned
Government
Government Planned
Microsoft Interconnect Azure
Microsoft Interconnect Azure
Planned
デュアル・リージョン︓基本的に全ての国/地域
で2つ以上のリージョンを提供し、お客様の業務
継続要件に対応していく
(⽇本の場合は東京-⼤阪)
各リージョンはOracle Backboneで接続
JEDDAH
ISRAEL
DUBAI
SAUDI 2
UAE 2
NEWPORT
EUROPE
AMSTERDAM
FRANKFURT
ZURICH
LONDON
SWEDEN
ITALY
FRANCE
https://www.oracle.com/cloud/architecture-and-regions.html
SANTIAGO
VINHEDO
SAO PAULO

オラクルの提供するデータベース・サービス
PaaS: 今までのOracle Databaseを便利に利⽤できる Autonomous
Oracle Database on
Virtual Machines
1-24 OCPUs
Oracle RAC on
Virtual Machines
4-48 OCPUs
仮想マシン
1コアからスタート可能
RAC対応
Oracle Database on
Bare Metal Servers
2-52 OCPUs
ローカルNVMe搭載
ベアメタル
コア数を柔軟に設定
物理専有環境
⼤規模CPUやIO性能が必
要な場合に最適
Exadata
あらゆるワークロードで⾼性
能を実現するExadataの専
有環境
Oracle Exadata
Max 1,600 OCPUs
Autonomous
Autonomous
Transaction
Processing
Autonomous Data
Warehouse
AI/機械学習を活⽤した⾃
律型データベース
21

Oracle Database on
Virtual Machines
1-24 OCPUs
Oracle RAC on
Virtual Machines
4-48 OCPUs
仮想マシン
Oracle Database on
Bare Metal Servers
2-52 OCPUs
ベアメタル Exadata
Oracle Exadata
Max 1,600 OCPUs
Autonomous
Autonomous
Transaction
Processing
Autonomous Data
Warehouse
Oracle Database
Oracle Exadata
DBエンジン
ハードウェア通常サーバ
22

No.1データベースをそのままクラウド上で利⽤可能
Database Cloud Service
数百TB/数百万IOPSまで対応可能
クラウドでも RAC / ベアメタル / Exadata が選択可能
あらゆる要件
に対応
全エディションを従量制で利⽤可能(サポート込)
保有ライセンスの持ち込みも可能
使った分だけ
お⽀払い
数クリックでチューンナップされたDBが準備完了
⾃動化・効率化機能がビルトイン
⼀⽅で⾃由度の⾼い運⽤が可能(OSアクセス可能)
利便性と
⾃由度の両⽴
Database
Cloud Service
23

全エディションが従量制で利⽤可能、サポートもサービス費⽤に含む
Oracle Database Cloud Service: エディション
Extreme Performance
High Performance
Enterprise Edition
Multitenant
Partitioning
Advanced Compression
Advanced Security,
Label Security,
Database Vault
Real Application Clusters
DB In-Memory
Active Data Guard
• 完全なデータベース・インス
タンス
• 表領域暗号化
Standard Edition
• 全てのEE 標準機能
- Data Guard
- Hybrid Columnar
Compression(HCC)
- パラレル処理
etc
Real Application
Testing
OLAP
Management Packs
(Data Masking and
Subsetting Pack,
Diagnostics and Tuning
Packs) 全てのデータベース・オプション機能
が利⽤可能
Oracle Database Cloud では、
全てのエディションで
表領域暗号化機能を提供主なデータベース・オプション機能
が利⽤可能
Management Packs
(Database Lifecycle
Management Pack, Cloud
Management Pack for
Oracle Database)
¥25.8/h ¥106.452/h
¥51.61/h ¥161.292/h
機能
* 料⾦︓CPU当たり
https://www.oracle.com/cloud/price-list.html
24

Real Application Clusters (RAC)
• Active-Activeのクラスタ機能
• パブリッククラウドで唯⼀利⽤可能
Data Guard
• 災害/障害対策のためのレプリケーション機能
• 東京/⼤阪リージョン間で⾃動構成
Oracle Databaseの⾼可⽤性機能を利⽤可能
VCN
AD
プライマリ
Block
Volume
Database * 2
(EE) 4 CPU
Public
Compute
Block
Volume
AD
セカンダリ
Block
Volume
Database
(EE) 1 CPU
Public
Compute
Block
Volume
Tokyo Region Osaka Region
Data Guard
RAC
ノード数を2に設定するとRACを⾃動構成
EP(VM)
EE/HP/EP
機能
25

あらゆる性能要件に対応可能
Oracle Database Cloud Service: ラインナップ
仮想
数⼗万
数百万
52
24
IOPS
OCPU
1,600
ベアメタル
Exadata
他社データベース・サービス
他社のデータベース・サービ
スでは最⼤でも数万IOPS
オンプレミス構成からすると
かなり⾒劣りしてしまう
X
オンプレミスで実
現していたあらゆ
る性能要件を満
たせるクラウド
ü ⾼性能ストレージ
ü 専有環境
ü アプライアンス等々
オンプレミス
性能
26

Oracle Database on
Virtual Machines
1-24 OCPUs
Oracle RAC on
Virtual Machines
4-48 OCPUs
仮想マシン
Oracle Database on
Bare Metal Servers
2-52 OCPUs
ベアメタル Exadata
Oracle Exadata
Max 1,600 OCPUs
Autonomous
Autonomous
Transaction
Processing
Autonomous Data
Warehouse
Oracle Database
Oracle Exadata
DBエンジン
ハードウェア通常サーバ
Autonomous
はPaaSと
どこが違うのか︖
27

新時代のデータベース・サービス
Oracle Autonomous Database
AI/機械学習を利⽤した完全⾃動運⽤
チューニングをはじめとしたDB運⽤は消滅
完全な
マネージド
サービス
1CPU単位でCPUを無停⽌で増減可能
ワークロードに応じた⾃動増減も可能
CPU/ストレージは1秒間単位で課⾦
完全な
柔軟性
あらゆるワークロード(OLTP/分析/混在)
あらゆるデータタイプ(構造化/JSON/グラフ等)
1つのデータベースで対応可能
完全な
マルチモデル
Autonomous
Database
28

運⽤・管理範囲の違い
ファシリティ管理
サーバー管理
パッチ適⽤
リソース監視
バックアップ/リストア
HA/DR
DB最適化
お客様管理
OSインストール
DBインストール
DB設計・構築
スケーリング
オラクル管理
オンプレミス DB on IaaS
DB PaaS Automated
(Database/Exadata)
ユーザー管理範囲
ユーザー管理範囲+機能(ツール)提供
オラクル管理範囲
AP管理/最適化
サーバー管理
パッチ適⽤
リソース監視
HA/DR
DB最適化
DB設計・構築
スケーリング
AP管理/最適化
サーバー管理
パッチ適⽤
リソース監視
HA/DR
DB最適化
DB設計・構築
スケーリング
AP管理/最適化
サーバー管理
パッチ適⽤
リソース監視
HA/DR
DB設計・構築
スケーリング
AP管理/最適化
DB最適化
DB PaaS Full-Managed
(Autonomous Database)
29

Oracle Database on
Virtual Machines
1-24 OCPUs
Oracle RAC on
Virtual Machines
4-48 OCPUs
仮想マシン
1コアからスタート可能
RAC対応
Oracle Database on
Bare Metal Servers
2-52 OCPUs
ベアメタル
コア数を柔軟に設定
物理専有環境
⼤規模CPUやIO性能が必
要な場合に最適
Exadata
あらゆるワークロードで⾼性
能を実現するExadataの専
有環境
Oracle Exadata
Max 1,600 OCPUs
Autonomous
Autonomous
Transaction
Processing
Autonomous Data
Warehouse
AI/機械学習を活⽤した⾃
律型データベース
30
本⽇はDatabase Cloud
Serviceへの移⾏をお話します

⼀般的なPaaSでお客様が管理できる範囲⼀般的なPaaS
通常OSにログインできなくなり、パッチも⾃動的に適⽤さ
れます
• データベース・サーバにエージェントを⼊れたい、OSに
ファイルを⼀時的に保存したい
• パッチは任意に適⽤したい
こうした場合は、PaaSを諦めるか、運⽤を変更する必要
があります
Oracle Database Cloud
• OSへのアクセスが可能
• パッチはお客様でコントロール可能
PaaSとして⾃動化・効率化を搭載しながら、⾃由度を確
保しています
Database Cloud Serviceにおける運⽤の⾃由度
OS
31
⼀般的なPaaSでは
OSやDBの管理範囲が
オンプレミスと⽐べて⾃由
度が少なくなってしまう
こうした⾃由度を持つことから
クラウド移⾏においても従来の⽅式
を幅広く活⽤できます

詳細はこちらの資料をご覧ください
https://oracle-
japan.github.io/ocidocs/services/database/data
base-100/
Oracle Database を簡単に作成し利⽤することができる、
Database Cloud Service (DBCS) についての解説資
料です
Oracle Database Cloud Service
32

アジェンダ
33

• 許容されるシステム停⽌の⻑さ
• ホスト・オペレーティング・システムとバージョン
• データベースのバージョン/エディション
• データベースの⽂字セット
• インデックスを含むデータの量
• データベースで使⽤されるデータ型
• データ・ステージングのためのストレージ
• データベースのホスト・プラットフォームのエンディアン形
式
• データベースアーキテクチャ(Multitenant)
• ネットワーク帯域幅
考慮すべき主要なポイント
34
オンプレミスクラウド
データベース移⾏
バージョンアップ

データベース移⾏⽅式の検討例
移⾏⽅式の選び⽅
移⾏要件と前提条件を考慮して移⾏⽅式を検討
移⾏時のダウンタイム
を極⼒短くしたいか
データ転送に時間が
掛かるか
定期的なパッチ適⽤
運⽤を⾏っているか
Data Guard
GoldenGate
YES
YES
YES
NO
NO
NO
RMAN
移⾏時にバージョン
アップしたいか
マルチテナント構成か
GoldenGate
TTS マルチテナント
(Unplug/Plug)
YES
NO
YES
RMAN
Data Pump
NO
etc.
データ量:多
ネットワーク転送速度:低速
初期移⾏
移⾏要件
前提条件
初期移⾏
Data Guard
(⼀時ロジカル・ス
タンバイ)
Data Guard
Data Pump
切り戻しを⾒越した差
分同期機能が必要か
YES
NO
ZDM
ZDM etc.
35 Copyright © 2021, Oracle and/or its affiliates

主な移⾏⽅式⼀覧
移⾏ツール移⾏対象
最低移⾏元バージョ
ン(サポート中の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

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

Data Pump︓旧来から馴染みの深い移⾏⽅式
移⾏⽅式概要
38
移行方式がシンプル
ビックエンディアンから変換が可能
スキーマ構成の変更が可能
1. 移行先DBを構築
2. 移行元DBでdumpファイルをexport
3. dumpファイルを転送
4. 移行先DBでdumpファイルをimport
停止期間
停止期間の考慮が必要
主な前提条件
特徴作業ステップ
Database
DB
DB
dump

Transportable Tablespaces︓⾼速な移⾏
移⾏⽅式概要
39
メタデータはdata pump
データ・ファイルは物理コピーと
別々に移行し、高速な移行を実現
インポート先でインデックスの再構築
統計情報の再取得を実施しない
PL/SQLパッケージなどのオブジェクトは
移行先で作成する必要がある
2. 移行元DBで表領域をREAD ONLYに
3. 移行元DBでメタデータをexpdp
4. メタデータとデータ・ファイルを転送
5. 移行先DBでメタデータをimpdp
停止期間
移行対象は表領域
ユーザ表領域が対象(SYSTEM/SYSAUX
/TEMP/UNDOなどの管理表領域は対象外)
主な前提条件
・メタデータ
・データ・ファイル
Database
DB
DB
移行元/先ともにEEが必要

RMAN Backup/Restore︓DB全体移⾏ (アップグレードを含む)
移⾏⽅式概要
40
移行方式がシンプル
アップグレードが可能
本番運用にて取得してる
バックアップデータを使って移行可能
1. 移行元DBにてRMANバックアップを取得
2. OCIで移行先DBを構築
3. (必要に応じて)
dbcliコマンドを使用して初期データベースを削除
4. バックアップデータを移行先DBへコピー
5. (移行元DBが暗号化されている場合)
移行元パスワードファイルとTDEウォレットファイルを移行先DBへコ
ピー
6. RMAN制御ファイルリストア
7. RMANデータベースリストア
8. dbcli register-databaseを使用してOCIにDBを登録
※2-node RACの場合は手動でDB_UNIQUE_NAMEをDBシステム名の値に
変更
停止期間の考慮が必要
主な前提条件
Database
DB
DB
dump
停止
期間

Cloud Backup Module for OCI︓DB全体移⾏ (アップグレードなし)
移⾏⽅式概要
41
Object Storageに格納されたバックアップ
データから直接データベースを作成可能
バックアップ/リストアよりも
簡単に移行可能
1. バックアップツールを利用してオブジェクト
ストレージにバックアップを取得
2. コンソール(GUI)またはAPIを使用して、
クラウド上のバックアップからデータベース
を作成
Object Storage , Backup Cloud Service
の費用がかかる
主な前提条件
移行元DBバージョンが12c以降の場合は
CDB必須
停止期間
Object
Storage
スタンドアロン
バックアップ
Database
DB
DB
Oracle Database
Cloud Backup
Module
ODBCM

PDB Unplug/Plug︓マルチテナント構成で利⽤可能な⽅式
移⾏⽅式概要
42
Multitenantの利点を生かし
PDBを簡単に移行可能
12.2以降ではオンラインで
Unplug/Plugが可能
(PDB再配置)
PDB再配置では移行先PDBへの接続を
自動リダイレクト
1. 移行先CDBを作成
2. 移行元PDBを停止
3. Unplugコマンドを実行し
データ・ファイルのリスト
を含むXMLファイルを生成
4. XMLファイルと
データ・ファイルを転送
5. 移行先DBでXMLファイルと
データ・ファイルを
指定してPDBを作成
停止期間
PDB再配置にて移動時に接続中の
コネクションや実行中のトランザクション
はロールバックされる
12.1.0.2以降のPDBが対象
主な前提条件
特徴作業ステップ(Unplug/Plug) 作業ステップ(PDB再配置)
2. 移行先CDBに接続し、移行元CDB
へのデータベースリンクを作成
3. 移行先CDBに接続し、PDB再配置
のSQLを実行
4. 移行先PDBをOPEN

GoldenGate︓切替時間を極⼩化できるデータベース移⾏⽅式 (⾼い⾃由度)
移⾏⽅式概要
43
DB移行に使用することで
ダウンタイム最小限で移行可能
双方向同期により並行稼動ができるため
業務、DB毎などの段階移行が可能
DB全体だけでなくobject単位での
同期が可能
2. GoldenGate環境を構築
3. 別の移行方式で既存DBの初期データを移行
4. 差分データを同期
5. 環境切り替え
移行アセスメントを実施
主な前提条件
Oracle GoldenGateライセンスが必要
Database
DB
DB

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

Zero Downtime Migration Service(ZDM)︓切替時間を極⼩化できるデータベース移⾏⽅式
移⾏⽅式概要
OCIへの無償移行ツール
ダウンタイム最小での移行が可能
2パターンの移行方式
・バックアップ＆リストア (SE/EE)
・スタンバイDBを作成し同期後にスイッ
チ (EE)
1. ZDMツールをダウンロード
2. ZDMサービスホストへツールをインストール
3. 設定ファイルを作成
4. (必要に応じて)テスト実行
5. ZDMツール実行
6. スイッチオーバー
ソースとターゲットは
同一のバージョン/パッチレベル
主な前提条件
移行元DB , 移行先DB以外に
ZDMサービスホストと
Object Storageが必要
Application
ZDM
SSH SSH
SQLnet

その他の移⾏⽅式
46

RMAN Duplicate
移⾏⽅式概要
47
移行元DBがオンラインのまま
複製が可能
既存のバックアップセットをつかった
複製が可能
スタンバイデータベースの作成が可能
1. OCIで移行先DBを作成
2. (必要に応じて)
dbcliコマンドを使用して初期データベースを削除
3. dbcli create-dbstorageを使用してDATA,RECO,REDOストレージのディレクトリ
を設定
4. (ソースDBがTDE構成の場合)
移行元DBのウォレットをコピーし
復元操作中にウォレットを参照できるよう設定
5. 静的リスナーの設定
6. RMAN Duplicateコマンドを使用して
データベースを移行
7. dbcli register-databaseを使用してOCIにDBを登録
※2-node RACの場合は手動でDB_UNIQUE_NAMEをDBシステム名の値に変更
移行先DBシステムから移行元DBシステム
のリスナーポートへ接続可能なこと
移行先DBシステムから
移行元DBシステムへSSH接続が可能なこと
主な前提条件

Full Transportable export/import
移⾏⽅式概要
48
Transportable Tablespacesと異なり
DB全体を移行可能
PL/SQLパッケージなどのオブジェクト
も一括で移行
大量データをコピーする場合は
RMAN増分バックアップを利用することで
停止期間を短縮した移行が可能
2. 移行元DBで表領域をREAD ONLYに
3. 移行元DBでexpdpを実行
(FULL=Y, TRANSPORTABLE=ALWAYSを指定)
4. メタデータとデータ・ファイルを転送
5. 移行先DBでimpdpを実行
(FULL=Y, TRANSPORTABLE=ALWAYSを指定)
停止期間
移行元DBバージョンは11.2.0.3以降
移行先DBバージョンは12.1.0.1以降
主な前提条件
・メタデータ
Database
DB
DB

RMAN Transportable Tablespaces
移⾏⽅式概要
49
RMANバックアップセットから
表領域を作成することで
表領域をREAD ONLYにせずに移行可能
オンプレミスにて運用している
既存のバックアップ設定を
変更する必要がない
2. 移行元DBで
RMAN> TRANSPORT TABLESPACE
(メタデータのdmp,データベース・ファイ
ル,impdpサンプルスクリプトが作成されます)
3. 出力されたファイルを転送
4. 移行先DBでimpdpを実行
移行対象はDB全体、表領域どちらでも
主な前提条件
・impdpサンプルサクリプト
・メタデータ
Database
DB
DB

PDB Clone
移⾏⽅式概要
50
移行元PDBをクラウド環境へそのまま
クローニング
12.2以降であればオンラインで
クローン可能(ホットクローン)
12.2以降でクローン実行後に移行元PDBの
データ更新をターゲットPDBに反映可能
(リフレッシュ可能クローン)
2. 移行先CDBに接続し、
移行元CDBへの
データベースリンクを作成
クローンPDB作成SQLを実行
ソースPDBを含むCDBはローカルUNDOモード
12.1.0.2以降のPDBが対象
主な前提条件
特徴
ソースPDBを含むCDBはARCHIVELOGモード
作業ステップ(ホットクローン) 作業ステップ(リフレッシュ可能ク
ローン)
移行元CDBへの
(refresh mode句を指定)
4. 指定した値で自動リフレッシュ
or 手動リフレッシュコマンド実行
※リフレッシュ時に移行先PDBは
CLOSEされていること
CRM
Pricing Retail
Pricing
Dev1
Pricing
Dev2
Pricing
Dev3

Non-CDB Clone
移⾏⽅式概要
51
移行元非CDBを移行先の環境へ
PDBとしてクローニング
移行元環境が12.1.0.2以降であれば
非CDBを簡単にPDB化して移行できる
1. 移行先CDBを構築
2. 移行元非CDBをREAD ONLYに
移行元非CDBへの
5. 移行先DBノードで、
$ORACLE_HOME/rdbms
/admin/noncdb_to_pdb.sqlを実行
12.1.0.2以降の非CDBが対象
主な前提条件
停止期間
DB

主な移⾏⽅式⼀覧
移行ツール移行対象
最低移行元バー
ジョン(サポート中
の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

オンプレミスからクラウドへのデータ転送⽅法の検討
53

• 次の表は、データセットをオンラインとオフラインで移⾏するのにかかる時間に関する情報を⽰しています。この表は、
データセットのサイズと使⽤可能な帯域幅を⽰しています
• ここではデータの送付およびアップロードにかかる時間のみを⽰しています。データ転送サービスを利⽤する場合は、これ
以外に事前準備作業やデータのコピー作業⽇数が必要です
オンプレミスからクラウドへのデータ転送⽅法の検討
おおよそのデータアップロード時間
データセットの
サイズ
10 Mbps 100 Mbps
1 Gbps
(FastConnect)
10 Gbps
(FastConnect)
データ転送ディスクを利
⽤した場合
10 TB 92 ⽇ 9 ⽇ 22 時間 2 時間 1 週間
100 TB 1,018 ⽇ 101 ⽇ 10 ⽇ 24 時間 1 週間
500 TB 5,092 ⽇ 509 ⽇ 50 ⽇ 5 ⽇ 1 週間
1 PB 10,185 ⽇ 1,018 ⽇ 101 ⽇ 10 ⽇ 2 週間
オフライン転送に向いているケース
54

データ転送サービス - Data Transfer Service
⼤容量のデータを⾼速かつセキュアに Oracle Cloud へ転送
お客様購⼊ディスクにデータをロードし、データ転送サイト
に送付
• 対応デバイス︓USB 2.0/3 .0ハード・ディスク・ドライブ
転送前にデータ暗号化(AES-256)
バケットにアップロードされたデータは削除されてから(NIST
800-88)お客様に返送
サービス費⽤無償
• 別途デバイス費⽤と往復輸送費、移⾏先オブジェクト・ストレー
ジ費⽤が必要
オラクルから貸し出すデータ転送アプライアンスにデータを
ロードし、データ転送サイトに送付
• 最⼤150TB (※東京/⼤阪リージョンについては 90TB)
転送前にデータ暗号化 (AES-256)
バケットにアップロードされたデータは削除される(NIST
800-88)
サービス費⽤無償
• 移⾏先オブジェクト・ストレージ費⽤が必要
• トライアルやPAYGでは利⽤不可
データ転送ディスクデータ転送アプライアンス
Object Storage
55

詳細はこちらの資料をご覧ください
https://oracle-
japan.github.io/ocidocs/services/storage/data-
transfer-and-storage-gateway/
オンプレミスからのデータ移⾏等で利⽤可能な、データ転
送サービス、ストレージ・ゲートウェイなどについて解説して
います
データ転送サービス - Data Transfer Service
56

移⾏ケース
57

移⾏ケース(1)︓Data Guard + Multitenant
12.2 12.2 19c
Unplug/Plug(アップグレード)
データベース移⾏の流れ
① オンラインによるData Guard構築
② REDO転送による同期開始
③ 業務閉塞
④ フェイルオーバーによるプライマリ化
⑤ Unplug/Plugによるアップグレード
⑥ 業務再開
数⽇間
数時間程度
前提条件/移⾏要件
n 12.2から19cへのバージョンアップを⾏いたい
n データ同期(初期データ移⾏+追いつき処理)は⻑時間掛かって
も問題ない
n 業務停⽌は週末の⼟⽇(最⼤48時間以内)で完了させる必要
がある
n 19cへの業務切り替え後の切り戻しは考慮しなくていい
Data Guard
データセンター東京リージョン(OCI)
58

移⾏ケース(2)︓Data Pump + Data Transfer + GoldenGate
データベース移⾏の流れ
① Data Pumpによるダンプファイル取得
② Data Transferによるデータ転送
③ 移⾏先データベースにインポート
④ GoldenGateによる同期開始
⑤ 業務閉塞
⑥ GoldenGateによる逆同期開始
⑦ 業務再開
前提条件/移⾏要件
n 11.2から19cへのバージョンアップを⾏いたい
n データ容量が数⼗TB
n システム切り替え時のダウンタイムは2時間以内
n システム切り替え後も切り戻しができるような構成
データセンター東京リージョン(OCI)
Data Pump
Data Transfer
GoldenGate
2時間以内
59
11.2 19c

アジェンダ
60

システム変更の種類
【インフラストラクチャの変更】
現⾏システム
ü パラメーター変更
ü パッチ適⽤
ü アップグレード
ü マイグレーションなど
変更内容例
テストに関わる要望・課題
なるべく本番通りの処理、負荷を流して、
劣化がないかチェックしたいが難しい
画⾯が100以上、SQLは1000以上あり、
テスト⼯数が⼤きすぎる
インフラの変更なので、アプリチームの理
解・協⼒を得るのが難しい
変更後の性能だけでなく、現⾏の性能と
の詳細な⽐較を⾏いたい
【アプリケーションの変更】
ü 新規開発
ü 機能追加
ü 機能修正
など
変更内容例
テストに関わる要望・課題
新しいアプリケーションに合わせて、
テストシナリオを柔軟に簡単に作成したい
画⾯への⼊⼒値を⾃動的に切り替え
ながら、さまざまなパターンでテストしたい
負荷をかけたあと(かけながら)、
性能レポートをすぐさまチェックしたい
多くの開発ベンダーに委託しているので、
データをきちんとマスキングしたい
61

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

Oracle Real Application Testing
SQL Performance Analyzer (SPA)
• SQL単体テスト
• システム変更前と変更後でのSQL⽐較レポートを⽣成
• SQL互換性(エラー有無)のチェック、実⾏計画や単体性能のチェックに
Database Replay
• システムテスト
• 本番環境のトランザクションを記録し、テスト環境で再現、⽐較レポート
• スループットのチェック、リソース使⽤量のチェックに
リアルなテストのための機能を1ライセンスで提供
• アップグレードやパッチ適⽤など、インフラ変更に伴うテストを⼤幅効率化
• SQL単位の詳細⽐較や本番ワークロードを使ったリアルなテスト
• アプリケーションに⼿を加えず、インフラチーム主体でテストを実施
63
データベース・クラウドの場合
DBCS EE/HP/EP, ExaCS
で利⽤可能

SQL Performance AnalyzerによるSQLの性能劣化の抽出とSQL Tuning Advisorによるチューニング (例︓10g
R2から19cへのアップグレード)
パフォーマンスのチェックとチューニング
l SQL ワークロードやパフォーマンス統
計を、SQL Tuning Set (STS) に格
納する
l フィルタリング、追加も可能(9i/10gR1
はSQLトレースからSTSに変換する必
要がある)
l 19cのテスト環境へSTSをインポート
l SPAからSTS を使ってSQLをシリアル
に1回ずつ実施して、実⾏計画とパ
フォーマンス統計を取得する
l 10gR2と19cでの違いをレポートとして出⼒(実⾏時間、
オプティマイザ・コスト、読み取りブロック数など)
l 変更前後で影響のあったSQLをリストして表⽰
l SQL Tuning Advisorを使って劣化したSQLをチューニ
ング
l 10gR2の時の実⾏計画を採⽤したいときはSQL Plan
Managementを使⽤
STEP-1 STEP-2 STEP-3
10gR2 Test 19c
64

SQLベースでのチューニングが完了したプログラムをDatabase Replayを使って本番環境の状態で実⾏(例︓10g R2か
ら19cへのアップグレード)
スループット負荷テスト
l 移⾏元環境でのトランザク
ションを1週間〜1ヶ⽉前から
キャプチャしておく (統計情報
も取得しておく)
l テスト環境を⽤意する (できれば
本番環境と同じ環境)
l キャプチャしたファイルを本番環
境からテスト環境にコピー
l テストを実⾏する環境で、キャプ
チャ・ファイルからリプレイ・ファイル
に変換
l リプレイ・クライアントから、本番
環境でキャプチャされたワークロー
ドを実⾏時間・並列度・コミット
順を再現するリクエストを送信
l 実⾏並列度や、処理が起きてい
ない時間の圧縮は可能
l 11.2.0.3+Patch以上で
Consolidated Replayも可能
l キャプチャ時とリプレイ時の違
いをレポートとして出⼒
• パフォーマンスの違い
• エラー発⽣の違い
• データ処理の違い(⾏
数など)
l 違いの発⽣したSQLを特定で
きる
STEP-1 STEP-2 STEP-3 STEP-4
10gR2 Test 19c
65

個々の機能検証と本番ワークロード検証
本番環境から
キャプチャ・ファイルを取得
評価
SPA 実⾏
チューニング DB Replay 実⾏
チューニング
評価
移⾏先環境へ適⽤
OK
NG
OK
NG
レポート
Replay Report /
AWR Report
キャプチャ・ファイル
キャプチャ・ファイル
個々の機能検証
本番ワークロード検証
66

オープン系共通基盤のハードウェアEOSLに伴う更改を実施
お客様事例︓国内⼤⼿保険会社様
67
オープン系共通基盤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

68
アップグレードやパッチ適⽤の評価は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
69

より詳しく知りたい
マニュアル
• クラウドへのデータベース移⾏
資料
• Oracle Cloud Infrastructure 概要資料
• Database Cloud 技術資料
• データベースアップグレードに有効 Real Application
Testing再⼊⾨
試してみたい
資料
• チュートリアル : Oracle Cloud Infrastructure を
使ってみよう
オンラインセミナー
• 2⽉19⽇︓ Oracle Cloud Infrastructure ハンズオ
ン
参考情報
70

Oracle Cloud ウェビナー
プロフェッショナルシリーズ
オンプレミスからクラウドへ︓
Oracle Databaseの移⾏ベストプラクティスを解説
Q&A

よくある質問
クラウド移⾏後のパッチ適⽤やバージョンアップはどのように
⾏いますか︖

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

Oracle Databaseは新しいリリースモデルを2018年より導⼊しています
現在最もサポート期間が⻑いリリースは、Oracle Database 19cです
Oracle Cloud Infrastructureへのデータベース移⾏に際しては、バージョンアップの要否、データ容量、システ
ムの停⽌許容時間に応じて、様々な⽅法を⽤意しています
Database Cloud Serviceは運⽤の⾃由度が⾼いため、従来の移⾏⽅式をそのままご活⽤いただけます
また、Zero Data Migrationをはじめ、OCIへの移⾏をサポートするツールやサービスもご⽤意しています
本セミナーのおさらい
74

Oracle Cloud サービス概要
• https://www.oracle.com/jp/
Oracle Cloud Free Tier
(Always Free＆無償トライアル)
• https://www.oracle.com/cloud/free/
マニュアル
• 英語 / ⽇本語
リージョン毎のサービス提供情報
• https://www.oracle.com/cloud/data-
regions.html#apac
東京/⼤阪リージョン最新情報
• https://blogs.oracle.com/oracle4engineer/co
lumn_cloud_gen2_oci
サービス・アップデート
• https://blogs.oracle.com/oracle4engineer/
技術情報
• 活⽤資料集 / チュートリアル
活⽤事例
• https://blogs.oracle.com/oracle4engineer/or
acle-cloud-platformpaasiaas
セミナー情報
• https://blogs.oracle.com/oracle4engineer/co
lumn_cloud_seminar
Oracle Cloud Infrastructure: 参考資料
75

Oracle Cloudにサインナップいただくと、両⽅が利⽤可能です
• https://www.oracle.com/jp/cloud/free/
Oracle Cloud Free Tier: Always Free＆無償トライアル
76
Always Free Free Trial
30 300
+

オンプレミスからクラウドへ：Oracle Databaseの移行ベストプラクティスを解説 (Oracle Cloudウェビナーシリーズ: 2021年2月18日)

オンプレミスからクラウドへ：Oracle Databaseの移行ベストプラクティスを解説 (Oracle Cloudウェビナーシリーズ: 2021年2月18日)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to オンプレミスからクラウドへ：Oracle Databaseの移行ベストプラクティスを解説 (Oracle Cloudウェビナーシリーズ: 2021年2月18日)

Similar to オンプレミスからクラウドへ：Oracle Databaseの移行ベストプラクティスを解説 (Oracle Cloudウェビナーシリーズ: 2021年2月18日) (20)

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

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

Recently uploaded

Recently uploaded (9)

オンプレミスからクラウドへ：Oracle Databaseの移行ベストプラクティスを解説 (Oracle Cloudウェビナーシリーズ: 2021年2月18日)