計画の定義 #1 ： サポート提供期間の確認
製品リリース・サイクルの変化により、平行してサポートされるリリースの種類は少なくなる傾向にある– 11gR2 リリース時：4つ前のメンテナンス・リリースである 9iR2 以降がサポート期間中
– 12cR1 リリース時：サポート期間中であるのは2つ前のメンテナンス・リリース以降
–
サポート期間終了後も運用を継続する場合には、次のメンテナンス・リリースに移行するタイミングを予定しておく必要がありメジャー・リリースをスキップしない
11gR2をリリースした時点で
は、9iR2以降の5つのリリー スがサポート期間中20 02 20 03 20 04 20 05 20 06 20 07 20 08 20 09 20 10 20 11 20 12 20 13 20 14 20 15 20 16 20 17 20 18 20 19 20 20 20 21 20 22 20 23 20 24 20 25
Oracle 9.2
(GA: Jul 2002)
Oracle 10.1
(GA: Jan 2004)
Oracle 10.2
(GA: Jul 2005)
Oracle 11.1
(GA: Aug 2007)
Oracle 11.2
(GA: Sep 2009)
Oracle 12.1
(GA: Jun 2013)
Oracle 12.2
JUL 2010 JAN 2007
JAN 2012 JAN 2009
AUG 2015 AUG 2012
JAN 2018 JAN 2015
JUN 2021 JUN 2018
JUL 2013 JUL 2010
計画の定義 #2 ： PSR 別パッチ適用期間の確認
各PSR
に対するパッチ提供は、その次のPSR
のリリースから2
年間（ベース・リリースは1
年間）
パッチ提供期間のリリースを利用していく上で、2年ないし3年に1度は新しいPSRの適用が必要
現時点でパッチ提供が行われているのは、11.1.0.7
、11.2.0.3
、11.2.0.4
、12.1.0.1
の4
種類のPSR
パッチが提供される PSR に常に保つ
Sustaining Support
2011 2012 2013 2014 2015 2016 2017 2018 2019 2020
11g R2 Premier Support
（
2015
年1
月末まで：例外的に5
年以上に設定）Extended Support
（
2018
年1
月末まで）※
12c R1 Premier Support
（
2018
年7
月末まで）Extended Support
（
2021
年7
月末まで）2021
Free Extended Support Extended Support
※HP-UXのみ
（2020年1月末まで）
パッチ提供期間 （2013年10月末まで） ※11.2.0.4 の出荷をカバーする期間まで延長済み パッチ提供期間 （2011年9月-2015年8月27日まで）
11.2.0.2 11.2.0.3
パッチ提供期間 （2013年8月-2018年1月末まで）
11.2.0.4
パッチ提供期間 （2013年6月- TBD）
12.1.0.1
11g R1 Premier Support
（
2012
年8
月末まで）Extended Support
（
2015
年8
月末まで）パッチ提供期間 （2009年9月18日まで）
11.1.0.6
パッチ提供期間 （2008年9月-2015年8月末まで）
11.1.0.7
パッチ提供期間 （2011年9月13日まで）
11.2.0.1
Sustaining Support
計画の定義 #3 ： パッチ適用の頻度
Interim Patch より PSU が推奨
オラクル社の開発部門でリリース前に行っているテストの量に違いがあるため Interim Patch は個別環境での特定の不具合を修正するためのパッチなので不具合修正テストのみ
PSUは、リリースより1ヶ月前にコードをFIXし、機能テスト、システムテスト、パフォーマンステストなど
3000時間を超えるテストを経て出荷される
PSU
は四半期ごとに適用する（
Exadata/Database Applianceの場合は四半期ごとのBundle Patchが推奨）
セキュリティと不具合の予防のために、四半期ごとの適用を想定して提供されるパッチセット
最新のセキュリティ・パッチである SPU に加えて、広く該当する可能性がある不具合の修正が提供される、セキュリティと不具合の両方に対して問題が起きる前に対応
PSU には実行計画に影響する修正、製品設定を変更する修正は含まれないため、負荷が高いパフォーマ
ンステストを行う必要がない
累積パッチであるため四半期ごとの適用が難しい場合には半期ごとの適用も可能（それ以下の頻度は推奨 しない）
個別パッチとの競合を解消するパッチも提供される四半期ごとの累積パッチである PSU の適用が推奨
計画の定義 #4 ： 長期的な戦略を立てる
原則1： 自社内のバージョンの種類を少なくし、共通バージョンを利用する–
インストールテストや基本テストの重複する作業の数を減らすことが可能–
既知の不具合などの情報を共通化することができ見落としが少ない–
パッチ適用やアップグレードのタイミングを管理しやすい
原則2： アップグレード要件をパターン分けして、少数の方法に振り分ける–
なるべく少ない方法に絞ることでスキルと知見を蓄積–
絞り込んだ方法を繰り返し実施することでプロセスの改善継続
原則3： 複数のデータベースをアップグレードする場合、どこからプロジェクトを開始するかルールを決めておく–
最も大変なプロジェクトから始めるか、最も簡単なプロジェクトから始めるか
原則4： 隣接するメンテナンス・リリースや PSR へのアップグレードを基本にする–
新しいリリースでは求められるデータやトランザクション量に見合ったデータ移行方法やアップグレードツールが提供されている–
要件やデータ量が進化して、データベースが古いままの場合、要件と選択肢のギャップが広がり、結果的に想定外の負荷がかかる少数に絞った手順を繰り返し行うことで洗練させる
計画の定義 #5: アップグレード手法の選択
データ移行、アップグレード後の切替、テスト方法の選択–
前述の原則に従って、いくつかのパターンをあらかじめ策定しておく
アップグレードに関する情報をプロジェクトで整理する–
以下の内容に応じて適切な手法を検討
移行元・移行先のバージョン
データベースサイズ （データ量、REDOのサイズなど） HW移行の有無
OS 変更の有無
Endian の変更の有無
移行するデータベース数 DataGuard、RACの利用有無
ダウンタイム要件
ネットワーク転送速度、等選択できる手段のうち、ダウンタイムとコストを最小限に抑えられるものを選択する
よく見るアップグレードをしない理由
主な理由は「テストの負荷」と「システムダウンやパフォーマンス劣化のリスク」
アプリケーションテスト/パフォーマンステストの負荷 が高い
• 影響の起きうる範囲が調べられない
• パフォーマンスが劣化する
• 本番環境と同じトランザクションを再現できない
テスト・ツールの利用により負荷削減が可能
• Database Replay により実運用環境のキャプチャ＆
リプレイ機能による実際の運用環境を再現
• SQL Performance Analyzerによるアップグレード前
後のパフォーマンスをSQLごとに比較し、影響を抽出 ダウンタイムが許容できない、サービス停止のリスクが高い
• システムが止められないのでアップグレードできない
• 今問題のないシステムに手を加えるリスクが取れない
アップグレードベストプラクティスが提供されている
• ダウンタイムが極めて少ないアップグレードの事例が
数多くあり、 その中で確立されたダウンタイム最小化の 手段や手順を参照可能アップグレードをする理由が見つからない
• インターネットに接続しない社内システムなのでセ
キュリティ対策はさほど重要ではない• アップグレードをするメリットを金額換算できない
アップグレードをしないリスクは想定
• セキュリティ事故が多くの社内で発生
• セキュリティ事故を含め、アップグレードをしないリス
クは金額で想定可能パッチ適用時に実施を検討するテスト内容
Interim Patch SPU、PSU BP、QDPE PSR
インストールテスト ○ ○ ○ ○
不具合の確認～
回避策としてパッチを適用 する時
可能な場合実施 関連箇所が検証可能な 場合実施
関連箇所が検証可能な 場合実施
関連箇所が検証可能な 場合実施
DB 基本動作確認、
基本的なアプリケーション動作、
代表的な負荷によるパフォーマ ンステスト
不要 オプション 必要 必要
アプリケーション全機能テスト、
パフォーマンステスト 不要 不要 不要 必要
テスト項目と効率化施策
全画面遷移検証
実行計画の変化による影響確認 オンライン業務処理、バッチ処理
総合テスト
運用監視を含むサイクルテスト
Web
系アプリケーションの処 理確認非
Web
系アプリケーション の処理確認オンライン／バッチによるパ フォーマンステスト
実行計画の影響有無を確認
監視、ジョブスケジュール確 認を含む疑似本番テスト
実施検討するテスト内容 テスト項目例 テストの内容
DB
基本動作確認 基本的なアプリケーション動作代表的な負荷による パフォーマンステスト アプリケーション全機能テスト
パフォーマンステスト
テスト項目と効率化施策
お客さまでのテスト項目 テストの内容 テスト効率化の施策
ATS (Oracle Function Testing) による
キャプチャとリプレイDB
ワークロードをキャプチャしRAT による DB リプレイ ATS(Oracle Load Testing) RAT(DB Replay)
による負荷RAT (SQL Performance Analyzer)
Diag Tuning
QA
システムでのサイクルテストWeb 系アプリケーションの処
理確認
非Web系アプリケーションの 処理確認
オンライン／バッチによるパ フォーマンステスト
実行計画の影響有無を確認
監視、ジョブスケジュール確 認を含む疑似本番テスト 全画面遷移検証
オンライン業務処理、バッチ処理 総合テスト
実行計画の変化による影響確認
運用監視を含むサイクルテスト