oracle database 11g r2 の最新最終パッチセッ …...2013/12/11 · 2010 today 1 2012 2013...

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 1

Oracle Database 11g R2 の最新/最終パッチセット11.2.0.4

THIRD PARTY

COMPANY LOGO

日本オラクル株式会社テクノロジー製品事業統括本部支社ソリューション本部西日本グループ 2013年12月11日

第116回夜な夜な! なにわオラクル塾


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

Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標または商標です。その他の名称はそれぞれの会社の商標の可能性があります。


Program Agenda

Oracle Databaseのパッチ

Oracle Database 11g R2 Patch Set Release 3 (11.2.0.4)

DatabaseのUpgrade

最新Upgrade事例

Real Application Testing機能概要


目的とゴール

Oracle Databaseのパッチの種類を理解する

11.2.0.4の価値を理解する

効果的なUpgrade手法を理解する

目的

最新バージョンの利用の価値を知る

ゴール


Oracle Database のパッチ


Oracle Database のパッチの種類と位置づけいつどれを適用するかの戦略が必要

種類名称バージョン表記例リリース頻度説明

Patch Set Release (PSR) 11.2.0.3.0

11.2.0.4.0

1~2年メジャー・リリースの間で作成され、複数の不具合に対する修正を統合したもの

ベース・リリースと過去のパッチ・セットに対して累積的なパッチ

不具合修正の他、新機能やオプティマイザの変更、新規パラメータが含まれる

Exadata Bundle Patch (BP) 11.2.0.3.20

11.2.0.3.21

1ヶ月

(3カ月)

Exadata向けに、PSUを含んだ重要な不具合の修正を統合したもの

PSRに対する累積パッチ

Patch Set Update (PSU) 11.2.0.3.1

11.2.0.3.2

3ヶ月最も重要な修正、最新のSPUを含んだ4半期ごとに提供されるパッチ

Security Patch Update (SPU) N/A 3ヶ月セキュリティ修正で構成される累積的なパッチ

Interim Patch （個別パッチ、One-off Patch、PSE/Patch

Set Exception）

N/A 適時ある不具合を修正するために、次のPSU/PSRや新製品のリリースまで待つことができないお客様のために作成される1つ以上の修正を含むパッチ

KROWN#159766


（参考） Patch Set Update – PSU が提供する内容

適用が強く推奨される不具合の修正の累積パッチ

– 広く発生しうるために全てのユーザに適用されることが望ましい修正や、既に知られている重大な問題に対する修正を含むため、

起きる可能性が高い問題にあらかじめ対処することが可能

– 適用すると、リリース番号の5桁目が変更され、適用したPSUを認識可能（個別パッチはリリース表記で認識不可能）

最新のセキュリティ・パッチ（SPU）が含まれている

– セキュリティ・パッチはコンサルタントなど社外の団体からの協力なども得て作成され四半期ごとに提供さる

PSUは常に最新のSPUを含む

– セキュリティ問題は、パッチが提供された時点でまだ認知されていない問題についても公開されため、

常に最新のセキュリティ・パッチが適用されていることが非常に望ましい

実行計画や設定変更を必要とする修正は含まれない

– PSUは、オプティマイザの実行計画を変更する可能性がある修正や、データベースの設定変更が必要な修正は含みない

負荷が高いパフォーマンステストやアプリケーションテストを行う必要はない（基本テスト、インストールテストは推奨）

– リリースの1ヶ月前に内容をFIXし、オラクル社にて昼夜続けての機能テスト・システムテスト・パフォーマンステストを

延べ3000時間ほど行った上で提供

既知の個別パッチとの競合を解消するパッチ

– 個別パッチとPSUの間に、既知の競合がある場合には、競合を解消するパッチを提供（11.2以降）

四半期ごと（難しい場合は半期ごと）の PSU 適用を推奨


Oracle 製品に対するリリースとサポート期間の原則

Premier Support：新規パッチ作成と新規プラットフォーム対応がされる期間で、グローバル

GA から5年間提供

Extended Support：所定の料金を支払うことにより継続して新規パッチの提供を受けることができる期間で、Premier Support 終了から3年間提供

Sustaining Support： Premier Support期間中に作成された各種のパッチ提供と、技術QAを受けられる期間で、無期限で提供

Grace Period：新規パッチ提供期間は PSR ごとに決められている。次のPSR のGAから2年後に（ただし最初のPSRに関しては1年後）当該PSR はSustaining Support に移行し、新規パッチの提供がされなくなる。次のPSRがリリースされてからの2年間（最初のPSRは1年間）はアップグレードのための期間という意味でGrace Period(猶予期間) と呼ばれる。

参照： Lifetime Support Policy、他


ライフタイム・サポート・ポリシー

t 2008

2003

2004

2005

2006

2007

2002

2009

2010

today

20

11

2012

2013

2014

Sustaining Support Premier Support

R2 2007年7月

Extended Support

2010年7月

2009年1月 2012年1月

R2 2010年7月 2013年7月

2015

2016

2012年8月 2015年8月

2008年7月

2011年7月

R2 2017

2018

2015年1月

2015年7月


Oracle 11g Release 2 Patch Set Release（PSR）

11g Release 2 リリース状況

– Linux および Windows プラットフォームの一部を抜粋

PSR を含む製品のリリース状況

Linux x86, x86-64

Windows x64

2009年9月 2010年9月 2011年9月

2010年4月 2010年12月 2011年11月

PSR 11.2.0.2.0

PSR 11.2.0.3.0

PSR 11.2.0.4.0

11.2.0.1.0

2013年8月

2013年10月


Sustaining Support

（参考）各PSR バージョンのサポート期間について Release Schedule of Current Database Releases Note.742060.1

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月末まで）


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月末まで）


パッチ提供期間（2009年9月18日まで） 11.1.0.6

パッチ提供期間（2008年9月-2015年8月末まで） 11.1.0.7

パッチ提供期間（2011年9月13日まで） 11.2.0.1

Sustaining Support

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ANNOUNCEMENT&id=742060.1


パッチセットのロードマップ Release Schedule of Current Database Releases Note.742060.1

リリース日パッチ終了日例外など

11.2.0.4 31-Jan-2018

HP-UX Itanium は Jan 2020 にパッチ終了予定

Feb 1, 2018 以降は、 Sev 1 に関する修正のみ

(no PSU or CPU will be produced).

11.2.0.3 27-Aug-2015

11.2.0.2 31-Oct-2013 28-Feb-2013から延長

11.2.0.1 13-Sep-2011 Exadata のパッチ終了日は30-Apr-2012

11.1.0.7 31-Aug-2015

HP-UX Itanium は Dec 2015 にパッチ終了予定

Sep 1, 2015 以降は、Sev 1 に関する修正のみ

(no PSU or CPU will be produced).

11.1.0.6 18-Sep-2009

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ANNOUNCEMENT&id=742060.1


11g Release 2 における PSR 不具合の修正に加えて、いくつかの新機能や機能拡張を含む

Oracle Database 11g Release 2 Patch Set 1 （PSR 11.2.0.2） • Oracle Real Application Clusters One Node （RAC One Node）機能拡張

• Oracle ASM クラスタ・ファイルシステム（ACFS）新機能

• Oracle Clusterware 新機能および機能拡張

• Oracle Database QoS 管理（サービスのクオリティ管理）新機能

Oracle Database 11g Release 2 Patch Set 2 （PSR 11.2.0.3） • Oracle ACFS 機能拡張

• Oracle Clusterware 機能拡張

• Oracle Database QoS 管理（サービスのクオリティ管理）機能拡張

Oracle Database 11g Release 2 Patch Set 3 （PSR 11.2.0.4） • 12c 新機能のバックポート

Data Redaction

データベース・リプレイ機能の拡張（データベース統合リプレイ）

動的サンプリングの拡張（動的統計）


11g Release 2 における PSR

フルインストレーションとして提供

– PSR の新規インストール時に、初期リリースが不要

– PSR であっても、初期リリースと同様の手順で環境構築が可能

– PSR 適用時のダウンタイムの削減

– Oracle ホームを共有する複数のインスタンスを、個別にアップグレード可能

適用方法

より安全に PSR の適用を実施

最新の PSR 環境の構築を簡易化


Oracle Database 11g R2 Patch Set Release 3 (11.2.0.4)


PSR 11.2.0.4

■概要

Oracle Database 11g R2 のターミナル・リリース

– ターミナル・リリースとは Oracle Database の各メジャーバージョンでの最後の PSR を指し、オラクルが提示しているサポート期間中はパッチの作成が行われるバージョン

新機能の追加、既存の機能の拡張

– Oracle Database 12c のいくつかの新機能が11.2.0.4

で利用可能

Windows Server 2012対応

– Windows Server 2012 に対応するバージョン

（シングル構成、クラスタ構成ともにサポート）

※注) Exadata/ODAの対応済

概要と各プラットフォーム版のリリーススケジュール

Platform Schedule

Linux x86-64 2013年8月

Solaris 2013年8月

Windows 2013年10月

AIX 2013年10月

HP-UX Itanium 2013年10月


PSR 11.2.0.4 新機能 / 機能拡張

Data Redaction (Advanced Security), データベース統合リプレイ(Real Application Testing), フラッシュバック・データ・アーカイブ最適化 (Advanced Compression) の使用には、それぞれ所定のオプションライセンスが必要

12c 新機能をバックポートして11g で実装

Oracle Data Redaction データベース統合リプレイ

▪ ユーザーの権限や接続しているクライアントなどの条件に応じて、データをリアルタイムに「マスク表示（リダクション）」

▪ アプリケーションやデータには手を入れずに、ユーザーに対するデータ表示のみをマスキング

動的統計フラッシュバック・データ・アーカイブ最適化

▪ 複数のデータベース（DB 10g 以降）から取得したワークロードを統合して、統合先の環境で同時にリプレイ

▪ データベース検討時に、統合後のデータベースのリアルな負荷検証を実施可能に

▪ 履歴データ格納先のテーブルを圧縮

▪ 圧縮によりストレージ容量削減と検索パフォーマンス向上の両立を実現

▪ 圧縮機能の利用有無を選択可能

▪ 11.2.0.3 まで「動的サンプリング」機能と呼ばれていたもの

▪ オプティマイザ統計が取得されていない、または古い場合に、データをサンプリングし一時的な統計を取得

▪ サンプリング・レベルと取得ブロック数を自動決定


PSR 11.2.0.4 新機能 / 機能拡張

現環境の設定の値がアップグレードで上書きされることはない

新規に追加されたパラメータについては、現環境と同じ動作にするために設定が必要なものがある

11gR2 機能の拡張 /サポート・ユーティリティの統合

Oracle Data Guard の拡張 Oracle GoldenGate 連携の拡張

▪ 新規のData Guard Broker のプロパティ追加

▪ Data Guard構成でプライマリ・データベースのLost Write

発生をスタンバイ側で検知した際プライマリ・データベースの処置を設定

▪ 通信状況に応じた振る舞いの設定

sqlnet.ora の拡張サポート・ユーティリティの統合

▪ 新規のデータベースの初期化パラメータ追加

▪ 基本的に GoldenGateを使用する際には設定が必須なパラメータ

▪ ソース / ターゲットの双方で設定が必要

▪ クラスタの診断情報を取得するユーティリティ、RAC構成の監査を行うツールが同梱

▪ クラスタワイドでの迅速かつ網羅的なログ収集が可能

▪ ベスト・プラクティスに基づいた構成レビューが可能

▪ 新規のsqlnet.oraファイルのパラメータ追加

▪ データベース接続をSSL認証する際に使用する証明書の「拡張鍵用途」を設定


11.2.0.4 の新機能 Oracle Data Redaction TFA コレクタ RACcheck データベース統合リプレイ動的統計フラッシュバック・データ・アーカイブの拡張 sqlnet.ora の拡張 Oracle Data Guard の拡張 Oracle GoldenGate 連携の拡張


Oracle Advanced Security で実現する 2 つの機能

データの暗号化

Transparent Data Encryption

リアルタイムアクセス制御

Oracle Data Redaction

NEW


Oracle Data Redaction ユーザーの権限に応じたリアルタイム・アクセスコントロール

ユーザーの権限やクライアント情報に応じてリアルタイムにデータをリダクション

アプリケーションのコード修正は必要のないデータベース内で完結する列アクセス制御

コールセンターやサポート業務などの職責に応じた顧客情報へのアクセス制御の実現や

PCIDSS に対応したクレジットカード番号の表示、アプリ開発者の直接アクセスも制御

クレジットカード番号

4451-2172-9841-4368

5106-6342-4881-5211

4891-3311-0090-5055

Policy データ

責任者

業務

オペレーター

Oracle Advanced Security


Oracle Database のアクセス制御の特徴

Data Redaction Virtual Private Database Database Vault

機能概要列のアクセス制御 &

リダクション行・列のアクセス制御

表のアクセス制御

特権ユーザー管理

必要ライセンス Advanced Security Option Enterprise Edition Database Vault Option

バージョン 11.2.0.4/12c～ 8i～(列は10g R1～) 10g R2～

対象アクセス列(SELECT) 列・行(SELECT/DML) オブジェクト・SQLコマンド

説明表に定義したリダクションポリシーの条件に応じて、列を表示させないまたは、任意の値にリダクション

表に定義した VPD ポリシーの条件に応じて WHERE 句を自動的に付与することで行を表示させない

その際に特定の列を NULL 表示させることも可能

レルム、ルール、コマンドルールの各要素を使って、オブジェクト(表やビュー、PL/SQL 等)へのアクセス、SQL コマンド自体の実行を詳細に強制アクセス制御することが可能

特権ユーザーポリシーは適用されないポリシーは適用されないどのユーザーでも

ポリシーは適用される

設定 DBMS_REDACT パッケージ

または、Oracle Enterprise Manager

DBMS_RLS パッケージ


DVSYS.DBMS_MACADM パッケージ



サポートされるリダクションの種類用途の応じたデータの参照範囲を定義

052-51-2147 XXX-XX-2147

格納されているデータリダクション結果

10/09/1992

[email protected] [hidden]@acme.com

4451-2172-9841-4368 4943-6344-0547-0110

Full

Partial

Regular

Expression

Random

01/01/2001

Oracle Advanced Security


Oracle Data Masking との違い

Oracle Data Masking Oracle Data Redaction

実装方式 Oracle Enterprise Manager DBMS_REDACT パッケージ


目的表を直接マスキング(更新)し、

本番に近いテストデータを作成ユーザーの権限に応じて表やビューをリダクションするアクセス制御

実行タイミングオフライン表・データベースのクローン作成後にマスキングを実行

オンライン問い合わせ結果にリアルタイムで

マスク処理を実行

格納データへの影響永続的にデータを変更影響なし

データをマスクする結果は同じだが、用途が異なる


TFA コレクタ

Oracle Grid Infrastructure、Oracle RAC システムにおいて、診断情報の収集をシンプルにするためのユーティリティ

オン・デマンドで、任意のタイミングで、クラスタ内の 1 ノードから、全ノードのアラート、トレース、OS ログなどを収集し、パッケージングすることが可能

診断情報を取得する対象(OS、クラスタ、ASM、DB)、日時を指定することも可能

アラートに出力される重篤なエラー(ORA-600、ORA-7445 など)をトリガーに自動収集するように設定も可能

– デフォルトでは OFF のため、明示的な設定が必要

11.2.0.4 より、Oracle Grid Infrastructure に同梱

– 従来より My Oracle Support にて公開されているツール

MOS NOTE : TFA Collector- The Preferred Tool for Automatic or ADHOC

Diagnostic Gathering Across All Cluster Nodes (Doc ID 1513912.1)

Oracle Clusterware 管理およびデプロイメント・ガイド 11gリリース2(11.2) Appendix H

Trace File Analyzer and Collector


TFA コレクタ

オン・デマンドの診断情報の収集

– クラスタの全ノードで、全てのコンポーネントの1日前からの情報を収集する場合

– 収集した情報は zip ファイルとして生成され、TFA レポジトリに出力される

自動収集の設定

– クラスタの全ノードで自動収集の設定を有効化

– 設定状況の確認

Trace File Analyzer and Collector

# /u01/app/11.2.0/grid/tfa/bin/tfactl diagcollect -all -since 1d

# /u01/app/11.2.0/grid/tfa/bin/tfactl set autodiagcollect=ON -c

# /u01/app/11.2.0/grid/tfa/bin/tfactl print config

...

| Automatic diagnostic collection | ON |

...


11.2.0.4 の新機能 Oracle Data Redaction TFA コレクタ RACcheck データベース統合リプレイ動的統計フラッシュバック・データ・アーカイブの拡張 sqlnet.oraの拡張 Oracle Data Guard の拡張 Oracle GoldenGate 連携の拡張


RACcheck

RAC 構成において重要な設定項目の監査を行うツール

– 単一インスタンス、Oracle Restart、RAC One Node の各構成でも利用可能

11.2.0.4 より、Oracle Database に同梱

– 従来より My Oracle Support にて公開されているツール

全スタックにおいて、MAA ベスト・プラクティスに基づいた推奨を提供

MOS NOTE : RACcheck - RAC Configuration Audit Tool (Doc ID 1268927.1)

Oracle Real Application Clusters 管理およびデプロイメント・ガイド 11g リリース2 (11.2) Appendix D

監査項目

Oracle RAC Configuration Audit Tool (RACcheck)

OS カーネル・パラメータ

OS パッケージ、システム構成

Oracle Grid Infrastructure

Oracle ASM

Oracle Database

DB 初期化パラメータ、重要な設定項目

11.2.0.[3|4]、12.1.0.1 へのアップグレードのレディネス・アセスメント


RACcheck

raccheck コマンドの手動での実行方法

– Oracle Database ソフトウェア所有者で実行

– root 権限による処理のため、sudo により、パスワードなしで実行可能とすることも可能

– デフォルトで、$ORACLE_HOME/suptools/raccheck 配下にタイムスタンプが入ったディレクトリが作成され、取得情報と html ファイルが生成される

raccheck コマンドの自動実行の設定

– raccheck デーモンを使用して、バックグラウンドで定期的に実行が可能


[oracle]$ $ORACLE_HOME/suptools/raccheck/raccheck

この後、インタラクティブに設定し、監査を開始

[oracle]$ raccheck -set AUTORUN_INTERVAL=1d <1 日ごとに実行する場合>


RACcheck

出力結果の例 (html ファイル)



データベース統合リプレイデータベースの統合テストを支援

SALES

HR

ERP

CRM

ワークロード

ワークロードを統合してリプレイ

ひとつまたは異なる複数のデータベース（DB 10g 以降）から取得した

ワークロードを統合してテスト環境で同時にリプレイ

スキーマ統合、プラガブル・データベースによるデータベース統合の

評価などに有効

ワークロードのリプレイ先に

PDB を指定することも可能

DB 12.1 以降または

DB 11.2.0.2 / 11.2.0.3 + パッチ、

DB 11.2.0.4 で利用可能

Oracle Real Application Testing

Available now

in DB11.2


データベース統合リプレイサポートされるワークロード・キャプチャのタイプ

ERP

CRM

ワークロード

同一または異なる OS 上で動作する

ひとつまたは複数の Oracle Database 10g 以降のワークロード・キャプチャを利用可能

Oracle Real Application Testing

Oracle Database 10g Release 2 on AIX

Oracle Database 11g Release 2 on Solaris SPARC


動的統計

11.2.0.3 までの「動的サンプリング」機能

オプティマイザの判断により、自動的にサンプリングのレベルと取得ブロック数を決定

設定する初期化パラメータ、およびヒントの名称は変わらない

– OPTIMIZER_DYNAMIC_SAMPLING

– /*+ dynamic_sampling([表名] レベル値) */

以下の条件で発動

– OPTIMIZER_DYNAMIC_SAMPLING=11

– OPTIMIZER_DYNAMIC_SAMPLING を明示的に指定していない、

かつパラレル実行


動的統計のレベルレベルオプティマイザが動的サンプリングを使用するタイミングサンプル・サイズ

0 動的統計を使用しない該当なし

1 次の条件を満たす場合のみ、すべての分析されていない表に対して動的統計を使用

• 分析されていない非パーティション表が問合せに少なくとも1つある場合

• この分析されていない表に索引がない場合

• この分析されていない表に、この表の動的統計に使用されるブロックの数よりも多いブロックがある場合

32

2 文の少なくとも 1 つの表に統計がない場合は、動的統計を使用 64

3 次のいずれかの条件が当てはまる場合は、動的統計を使用

• 文がレベル 2 の基準を満たす場合

• 文に、たとえば WHERE SUBSTR (CUSTLASTNAME,1,3) のように、WHERE 句の述語で使用される1つ以上の式がある場合

64

4 次のいずれかの条件が当てはまる場合は、動的統計を使用

• 文がレベル 3 の基準を満たす場合

• 文が複雑な述語を使用している(同じ表で複数の述語を OR または AND 演算子でつないでいる)場合

64

5 文がレベル 4 の基準を満たす場合は、動的統計を使用 128





10 すべての文に動的統計を使用すべてのブロック

11 オプティマイザが必要と判断した場合、動的統計を使用自動的に判断


12c での動的統計との違い

発動条件

– 11.2.0.4 ：OPTIMIZER_DYNAMIC_SAMPLING を明示的に

指定していない場合、パラレル処理か否かを判断し

パラレル処理であれば動的統計を取得

– 12c ：すべての SQL で動的統計が有効か否かを判断

統計情報の永続化

– 11.2.0.4 ：永続化しない

– 12c ：永続化する


フラッシュバック・データ・アーカイブ

従来のフラッシュバック・テクノロジーを進化させた新しい変更履歴ソリューション

– アプリケーションからは透過的

– 従来のフラッシュバック・クエリー、バージョン・クエリーでアクセス可

– Database 側だけのシンプルな設定方法

– パフォーマンスへの影響を最小限に

– 履歴データ管理にパーティショニング、圧縮オプションを活用

使用用途

– コンプライアンス

– 監査レポート

– Information Lifecycle Management (ILM)

– データ解析 Insert

Update

Delete Flashback Data Archive

Select

Insert

Update

Delete

Oracle Advanced Compression


フラッシュバック・データ・アーカイブ

バックグランド・プロセス 'FBDA' により、非同期で UNDO から履歴を自動取得 (基本 5 分間隔)

履歴データは、自動的に圧縮、パーティション化

保存期間を過ぎた履歴データは自動で削除

表名や列名等のスキーマ変更にも対応

履歴データは Read Only となり、改ざんは不可

– パーティション化により高速なフラッシュバック・クエリーを実現

– FBDA プロセスは、負荷に応じて自動的にスレッドを作成しパラレル処理を実行

fda1 employees

Undo data

DML

DML

Original data in buffer cache

Background (fbda) process

DML

DML

undo

負荷に応じて拡張

. . help



履歴データのパーティションニング＆圧縮

履歴データは、24 時間間隔で必要に応じて、SCN をパーティションキーとして自動的にパーティション化

フラッシュバッククエリー、バージョンクエリーは該当パーティションのみを検索

データブロック内のデータが一定の閾値に

達すると圧縮が行われる

(OLTP 圧縮を使用）

11.2.0.3 まで

emp

Flashback Data Archive fba1

・・・

レンジパーティション (SCN)

emp の履歴表

OLTP 圧縮



履歴テーブルの最適化

履歴テーブルの最適化＝圧縮の有無を指定

– OPTIMIZE DATA 句により指定

– デフォルトは NO OPTIMIZE DATA

履歴テーブルのデータを自動的に圧縮

– 圧縮方法は以下のいずれかから自動的に選択される（OLTP 圧縮の機能）

Advanced Row Compression

Advanced LOB Compression

Advanced LOB Deduplication

11.2.0.4 Oracle Advanced Compression


SSL_EXTENDED_KEY_USAGE パラメータ

sqlnet.ora ファイルのパラメータで、

SSL 証明書の拡張鍵用途を指定

– データベース接続の認証で使用する証明書

の拡張鍵用途を指定

– 例

SQLNET.SSL_EXTENDED_KEY_USAGE =

"client authentication"

sqlnet.ora の拡張

証明書の拡張鍵用途


Data Guard Broker のプロパティ追加

プロパティ名値デフォルト備考

ObserverOverride TRUE or

FALSE

FALSE TRUE に設定された場合、スタンバイとプライマリの接続が正常であったとしても、オブザーバーがプライマリとの接続を失った際に自動フェイルオーバーする

ObserverReconnect >=0 0 オブザーバーがプライマリとの新規接続を確立する頻度を設定する。デフォルトの 0 の場合、オブザーバーはプライマリとの接続を作成・維持するが、定期的に新規接続を作成しない。

これにより、定期的に新規接続を確立する処理のオーバーヘッドを削減できるが、接続できない場合の検知ができなくなる。接続の障害を検知でき、かつ定期的な接続の負荷を抑えられるよう、小さい値に設定することを推奨する

PrimaryLostWriteAction CONTINUE

or

SHUTDOWN

CONTINUE スタンバイ・データベースがプライマリでのLost Writeを検知した際の振る舞いを設定する： ▪ CONTINUE - スタンバイ・データベースでプライマリのLost Write

を検知しても、プライマリは処理を継続する

▪ SHUTDOWN – プライマリをshutdown abortで停止させる

プライマリでのLost Writeを検知しても、ファストスタート・フェイルオーバーは発生しない。


Data Guard Broker のプロパティ追加

プロパティ名値デフォルト備考

ApplyLagThreshold >=0 0 ロジカルまたはフィジカル・スタンバイにおいて、データベースの適用ラグが発生した際の警告を生成する時間間隔を秒単位で指定する。0 の場合、適用ラグがあっても警告は生成しない

TransportDisconnectedThreshold >=0 30 ロジカルまたはフィジカル・スタンバイ、スナップショット・スタンバイにおいて、プライマリ・データベースからの最後の通信がこのプロパティで指定した値（秒単位）を超えた場合に警告を生成する。0

の場合、警告は生成しない

TransportLagThreshold >=0 0 ロジカルまたはフィジカル・スタンバイ、スナップショット・スタンバイにおいて、データベースの転送ラグが発生した際の警告を生成する時間間隔を秒単位で指定する。0 の場合、転送ラグがあっても警告は生成しない


Oracle Database との統合

GoldenGate による抽出や適用を実行する際に設定するパラメータ

– Classic Capture や Integrated Capture / Replicat 実行時

– TDE 対象データの利用

– ターゲット側でのトリガーの制御

– データ重複の制御

– データ制約の制御

TRUE or FALSE で設定（デフォルトは FALSE）

– ALTER SYSTEM で動的に設定変更可能

リファレンス

– MOS NOTE : ENABLE_GOLDENGATE_REPLICATION database parameter

(Doc ID 1568417.1)

ENABLE_GOLDENGATE_REPLICATION 初期化パラメータ


DatabaseのUpgrade


バージョン選定について

下記3点を選択の基準としてご検討

1. 新規パッチ提供を、いつまで必要か

（またはPremier Support にて受けられる期間がいつまで必要か）

2. 新規パッチ提供を、PSR の適用無しに受けられる期間がいつまで必要か

3. 12.1.0.1 でなければ実現できない機能要件があるか

新規環境に利用するデータベースのバージョン選定（11.2.0.4 / 12.1.0.1）

メジャー･リリース 11g Release2 (11.2) 12c Release1 (12.1)

Premier Support 2015年1月末まで 2018年7月31日まで

Extended Support 2018年1月31日まで（初年度はES料金無償） 2021年7月31日まで

パッチ・セットリリース 11g Release2 (11.2.0.4 ) 12c Release1 (12.1.0.1)

メンテナンス終了 2018年1月31日次の PSR のGAから1年後


安定稼働を支える定期メンテナンスのために推奨されること

1. 定期的なパッチ適用を組み込んだ運用計画最新のセキュリティ・パッチを適用できる定期的なメンテナンス・スケジュールを計画

利用しているリリースでの既知不具合についても定期的に累積パッチを適用するメンテナンス計画

2. アップグレードを組み込んだシステム・ライフサイクルの計画パッチ提供を受け続けられるよう、パッチ提供期間内でのアップグレードタイミングを策定

システム・ライフサイクルを通して必要なアップグレードの回数、タイミング、頻度を運用計画に組み込む

3. 定期的なパッチ適用とアップグレードが可能な環境メンテナンス作業中も含むダウンタイムの最小化を行うために

MAA （Maximum Availability Architecture）などの高可用性構成を検討

テスト負荷の最小化のため、本番環境のトランザクションを再現する方法やパフォーマンスに対する

影響を検知・修正するための手順を確立

長期的な運用に必要な3つのポイント


計画の定義 #1：サポート提供期間の確認

製品リリース・サイクルの変化により、平行してサポートされるリリースの種類は少なくなる傾向にある

– 11gR2 リリース時：4つ前のメンテナンス・リリースである 9iR2 以降がサポート期間中

– 12cR1 リリース時：サポート期間中であるのは2つ前のメンテナンス・リリース以降

– サポート期間終了後も運用を継続する場合には、次のメンテナンス・リリースに移行するタイミングを予定しておく必要があり

メジャー・リリースをスキップしない

11gR2をリリースした時点では、9iR2以降の5つのリリースがサポート期間中

2002

2003

2004

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

2025

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(TBD)

JUL 2010JAN 2007

Sustaining Support

JAN 2012JAN 2009

AUG 2015AUG 2012

JAN 2018JAN 2015

JUN 2021JUN 2018

JUL 2013JUL 2010

Waived Extendend Extendend SupportPremier Support

18ヶ月

18ヶ月

25ヶ月

25ヶ月

44ヶ月

2013年11月現在サポート期間中のリリースは3つ


計画の定義 #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 R2Premier Support（2015年1月末まで：例外的に5年以上に設定）

Extended Support（2018年1月末まで）

※

12c R1Premier Support（2018年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 R1Premier Support（2012年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系アプリケーションの処理確認

オンライン／バッチによるパフォーマンステスト

実行計画の影響有無を確認

監視、ジョブスケジュール確認を含む疑似本番テスト

全画面遷移検証

オンライン業務処理、バッチ処理

総合テスト

実行計画の変化による影響確認

運用監視を含むサイクルテスト


Oracle Application Quality Management

DBサーバ

APサーバ

アプリケーション

Application Testing Suite(ATS) アプリケーションの機能テスト、性能テストを支援する機能や、テストプロセス管理などの機能を提供

テストの自動化やテストシナリオ作成の容易化等が可能

Application Replay ユーザーリクエスト(HTTP)をキャプチャーし、再現する機能を提供

本番機の負荷を別サーバで再現したり、負荷試験の負荷を容易にリプレイすることが可能

Real Application Testing(RAT) DBの負荷をキャプチャーし、再現する機能を提供

本番機の負荷を別サーバで再現したり、負荷試験の負荷を容易にリプレイすることが可能

テストソリューションツール一覧


Oracle Application Quality Management

Synthetic Workload

– 想定されるトランザクションをテストスクリプトとして手動作成

– 新規開発や改修などのテストを効率化

Real Workload

– 本番環境で処理されているトランザクションからテストスクリプトを自動作成

– アップグレードや構成変更時の影響確認テストを効率化

2つのワークロードによる高品質のテスト

ミドルウェア

データベース

物理&仮想サーバー

ストレージ

アプリケーション・スタック全体の品質管理

ATS

Application

Replay

Real

Application

Testing

Real Synthetic

目的に応じた高品質のテストを実現


現状分析

要件定義

影響調査

詳細設計

フィージビリティ調査

方式設計環境構築

移行ツール・運用ツール作成

移行ツール・運用ツール試験

基盤試験

移行試験

運用試験

移行

リハーサル

本番移行

稼働確認

基盤稼働

状況分析

パッチ適用/動作確認

テストタスク別製品マッピング

要件定義設計開発・単体

試験／構築

結合・総合

試験移行運用

現状分析

要件定義

影響調査

基本設計

詳細設計

アプリケーション開発

単体試験

結合試験

総合試験

AP稼働確認 AP稼働状況

分析

基盤

アプリ

パッチ適用/動作確認

テストを実施するタスク

アプリ変更/動作確認

Application Testing Suite

Real Application Testing

Application Replay

RAT

ATS

REP

ATS

RAT

REP

ATS

RAT

REP

ATS

ATS

ATS ATS

ATS

ATS

RAT

REP

PJフェーズ別タスクと製品の使い所

RAT


Oracle Database 11g Release 2 へのアップグレード

利用可能なアップグレード方式について、コンポーネントごとの一覧は以下

Oracle Grid Infrastructure は out-of-place でのアップグレードが必須

Oracle Database は out-of-place でのアップグレードを推奨

Oracle Database Client については、制限や推奨は特になし

利用可能なアップグレード方式

○：利用可－：利用不可

製品 In-place アップグレード Out-of-place アップグレード

Oracle Grid Infrastructure － ○ （必須）

Oracle Database ○ ○ （推奨）

Oracle Database Client ○ ○


PSR 11.2.0.4 へのアップグレード

PSR 11.2.0.4 へのアップグレード時に、アップグレード元の

バージョンに応じて、事前にパッチ適用が必要

– Oracle Grid Infrastructure のアップグレード時に以下を適用

11.1.0 から: 11.1.0.7.7 （PSU #7）を適用

11.2.0.1 : Patch 9413827 および 9706490 を適用

11.2.0.2 : Patch 12539000 および 10229886 を適用

アップグレード時に適用が必要なパッチ


要件に合ったアップグレード/移行方法の選択

※1. 移行先環境に旧バージョンの DBを構築することで可能

※2. Recovery Manger (RMAN) を使用することで可能

※3.NETWORK_LINKインポートを使用することで可能

アップグレード方式

異なる断片化の解消

切り戻し中間

ファイル

移行

時間

停止

時間 H/W OS ブロック

サイズキャラクタセット

Database Upgrade

Assistant(DBUA)

△ ※1

× × × × ○ 不要小小

コマンドライン

アップグレード(CLI) ○ × × × × ○ 不要小小

Data Pump (10.1-) ○ ○ ○ ○ ○ △ 不要 ※3

データ量

比例中

Export / Import ○ ○ ○ ○ ○ △ 必要データ量

比例大

DBリンク+ ダイレクト・パス・インサート

○ ○ ○ ○ ○ △ 不要データ量

比例中

トランスポータブル

表領域 (8i -) ○

△ ※2

× × × ○ 必要

データ・ファイル

容量比例

小

Oracle GoldenGate ○ ○ ○ ○ △ ○ 必要極小極小


最新Upgrade事例


住友重機械工業様

システム統合を推進するアップグレードの効率化

プロジェクト背景 - 基幹系業務システムのアップグレードプロジェクト

- 生産管理や本社系のバックオフィスなど、多数のデータベースが稼働中

- 11gへのアップグレードを促進 - 移行プロジェクトのリスクを回避

- 属人化された移行方法から脱却し、平準化

採用の効果（RAT / Veridata） - 移行期間の短縮と移行費用のコスト削減 - アップグレードによる影響範囲の瞬時に把握 - 新環境におけるデータ整合性の確認

「Real Application Testing」「GoldenGate Veridata」採用事例


RAT / Veridata を活用した Upgrade 住友重機械工業様

Upgrade 時の課題と Project Scope

Upgrade 作業が属人化してしまい、平準化できない

インスタンス数が多数あるため、平準化された技術を用いて横展開していきたい

改善すべき SQL の簡易的な特定を実施できず、全ての SQL

チェックをしなければならない

最終的なデータの確認作業を自動化・省力化したい

本番環境をキャプチャし、テスト環境でリプレイするという単純作業で平準化し、全インスタンスへ適応可能

RAT を用いることにより、システムの性能劣化を瞬時に判定可能

旧環境と新環境間でのデータは Veridata を利用し、自動的に内容を確認可能

Upgrade 工数の 30% 削減を目標に実施

本番環境

(旧 DB Ver.)

疑似本番環境

(旧 DB Ver.)

新本番環境

(新 DB Ver.)

RAT / Veridata 活用後の現状

性能検証性能検証 +

整合性検証

Veridata Server

データの完全一致を目指すため、本番環境ではなく疑似本番環境を構築し、整合性チェック

(※本番環境は常に更新され続けるため)

本構成を用いることで、OLTP / Batch などあらゆるワークロードでの性能 / 整合性テストが可能

インフラ担当部門のテスト範囲の拡大と品質向上

Project 構成

Project Topics

事例


テスト手法の切り分け

夜間 Batch 処理の前に一旦システムを停止しバックアップを取得するため、制止点を確保可能

Batch と OLTP において別々のテストを実施

– Batch 処理ではデータの整合性テストと性能検証を実施

– OLTP では、別途テスト環境を構築し、性能検証のみを実施

お客様業務に基づくテスト手法

Batch

OLTP

DB 停止

(Cold Backup)

Batch 処理終了後

OLTP の開始深夜に Cold Backup で

日時 Backup を取得

time

事例

ワークロードの検証整合性テスト単体 SQL の性能

検証

個別チューニング /

全体チューニング


事例

実行結果の整合性テスト

「違いのあるコール」として件数のみ表示

整合性テストのため、GoldenGate Veridata を利用し、各 DB でどのような違いが起こったのかの検証を実施


事例

DB time による単体 SQL の性能比較

劣化する SQL と改善する SQL を比較するために、

AWR Report の DB time よりその差を判断しようとしていた

SQL Trace の Elapsed Time で比較するためのツールを作成

– 10g 以降であれば DB time での比較が可能なため、この手間を削減できる

SQL A : 0.5 s × 1000本

SQL B : 20 s × 1本

SQL A が5秒遅くなる場合、業務への影響は多大だが、

SQL B が10秒遅くなっても全体への影響は少ない

各 SQL の特徴をつかみ、改善計画を立てることが重要

例)

対処策


事例

その他のお客様でのユースケース

1

2

サーバー更改における

プラットフォーム選定

新環境で旧環境を再現

AP 層や周辺システムとの連携に多大な時間がかかる

各ベンダーへのテストデータ/アプリの提供や稼働確認への対応時間がかかる

ストレステストを簡易的に実施したい

本番環境でのCaptureが実施できない(Patch適用ができない)ため、RATを利用できない

RAT でキャプチャした SQL とキャプチャ直

前のバックアップデータのみで各ベンダーに於いて短時間でテストが可能

RAT のパラメータを変更することで、高負荷状態を再現

新環境で optimizer_features_enable パラメータを 9i に設定してからキャプチャし11g

に変更してReplay

課題解決策


事例集


最新移行事例 RATを使用した試験精度の向上とコスト削減の実現

高品質/短期間のテストをデータベースの移行において実施したい

10gR2 RAC 11gR2 RAC

RAT

10gR2 RAC 11gR2 RAC

SQL SQL

検証環境検証環境

本番環境検証環境

本番ワークロードを使用した為、高品質なテストを実現

開発チームのテストコスト削減とDBチームのテスト準備・実施コストの削減

AP/DB間の連携を疎にすることでスケジュールの柔軟性を確保

目的

RAT導入効果


RAT事例① DB Replay/SPAを使用したデータベースのUpgrade

使用機能

– Database Replay / SPA

目的

– 高品質なテストを実現したい

– 10gから11gへの移行に際し、事前にSQL性能がどの程度向上するか、または劣化するものがあるかを開発チームに依頼するのではなく、DBインフラチーム(DBA)のみで確認したい

– APサーバーとは独立してDBサーバーのテストを実施したい


RAT事例① RATを使用しない場合のSQL性能確認運用

開発チームが確認し問題がある場合にDBAへ連携

検証環境：

新本番環境：

SQL

実行結果 A

SQL

実行結果 B

問題があればDBAと共有開発チーム

新規開発と既存性能担保で負荷が増大

DBAとの連携調整も

工数が増加する原因に


RAT事例① RATを使用した場合のSQL性能確認運用

DBAチームが確認し問題がある場合に開発チームへ連携することで、開発チームの工数も削減

本番環境：

新本番環境：

問題があれば開発チームと共有 DBAチーム

Replay結果

開発チームは既存SQLの

劣化確認工数が削減され新規開発に集中

連携調整も最小限に

抑えられた

SQL


RAT事例① RATを使用しAPサーバーと独立してDBインフラをテスト

DBサーバーはAPサーバーとは独立してテストを実施することでスケジュールを前倒し

フェーズ１フェーズ２フェーズ３フェーズ４フェーズ５フェーズ６フェーズ７

アプリ

DB

要件定義設計構築移行試験改修リリース

要件定義設計構築改修リリース移行試験

改修移行試験

アプリとDBの密な関係を排除し、独立して試験等を前倒しで実施


DB ReplayとSPAの一連の処理をスクリプト化し自動化

AWRレポートの生成

RAT事例① RAT関連の作業をスクリプト化し自動化

以前のワークロード情報の削除

CAPTURE

以前に作成したSTS情報の削除

CAPTURE時のAWRスナップからSTSの作成

ステージング表のエクスポート

以前REPLAYしたワークロード情報の削除

REPLAYの開始

DB REPLAY REPORTの生成

CAPTURE時のAWRスナップのインポート

AWRレポートの生成

ステージング表のインポート

SPAレポートの生成

AWRスナップのエクスポート


RAT事例② DB Replayを使用した長時間ワークロードのCapture

使用機能

– Database Replay

目的

– データベースの移行時に本番でCaptureしたワークロードを実行し問題把握をしたい。その実現のために1ヶ月のワークロードをCaptureし全ての業務を網羅的に試験する



1ヶ月単位で全ての処理が実行されるため、1ヶ月分のワークロードを取得し構成変更時のインフラテスト・評価をインフラチームのみで実施

本番環境：

検証環境：

1ヶ月分の本番のCaptureファイルを保存



非常に長い間Captureするため、Captureファイルの出力も大量となることが懸念された。そこで事前に必要なディスク容量を計算する為に下記の式を用いて試算

「 AWRレポートのSQL*net from client 」 x 2


RAT事例③ DB Replayを使用した非互換調査の工数削減

使用機能

– SPA/Database Replay

目的

– 10gから11gへの移行に際し、マニュアル/KROWN/NOTEといったソースを洗い出し非互換調査をするのは工数的に不可能。そこでRATを使用することで大きな非互換を実行ベースで洗い出し、最低限の非互換調査を実施したい


RAT事例③ DB Replayを使用した非互換調査の工数削減

SPA/DB Replay時に発生したORAエラーを確認し非互換調査とする

本番環境：

新本番環境：

ORAエラー

新環境で発生したORAエラーを確認し、

非互換となっているものを洗い出す


RAT事例③ DB Replayを使用した非互換調査結果例

新環境でエラーとなると下記のようにレポートとして表示される

そのエラーを調査することで該当しうる非互換を調査することが可能

Capture時は「Successful」と成功している

Replay時はORA-00918が発生している

※ORA-00918 : 列の定義が未確定


RAT事例③ DB Replayを使用した非互換調査結果例

本エラーを調査した結果、KROWN#128950の事象に該当し、

10gで検知されなかった事象が11gで検知されるようになることが判明

KRONW#128950

BUGの修正により ANSI JOIN 実行時の列定義の検証がより厳密に実施されるようになります

これにより、11g以降のデータベースで以下の条件をすべて満たす場合、ORA-918 を通知します

ANSI 準拠の結合を実施している

結合する表が同一の列名を保持している

この列名を表名またはエイリアスによる修飾をおこなっていない

SELECT empno

FROM emp a

JOIN emp b

ON a.empno = b.empno

JOIN emp c

ON a.empno = c.empno;


RAT事例④ 新機能/新製品導入時の性能検証の実施

使用機能

– Database Replay

目的

– 新製品や新機能を導入する際に、フィジビリティ確認や本番時の

リハーサルをより精度の高いテストで実施したい

– 本番想定の負荷を再現するには非常に工数がかかる、

もしくは不可能であるため、その課題を解決したい


RAT事例④ GoldenGate導入時のフィジビリティ/性能試験でのDB Replayの利用

GoldenGate導入プロジェクトでは下記のマイルストーンによって進める

１ヶ月目２ヶ月目３ヶ月目４ヶ月目５ヶ月目６ヶ月目７ヶ月目８ヶ月目

機能検証

（PoC)

GoldenGate

設計

環境構築/テスト

移行

要件定義

方式策定

環境構築基盤試験性能試験（業務試験）

ﾘﾊｰｻﾙ本番移行

これらテストフェーズでテストアプリを作成

するのではなく、RATを使用してGoldenGate

の各種試験を実施


RAT事例④ RATを使用したGoldenGate性能検証

Script作成時のDB分析とコーディングに工数が多くかかる

工数をかけたScriptではSQLの種類の網羅性は担保出来なかった

検証環境： (ソース)

検証環境： (ターゲット)

Cap

DP REP

SQL

スクリプト

本番のAWR

本番のOS情報

業務知識

実SQLとは異なり、必要十分な

テストが実行できない


RAT事例④ RATを使用したGoldenGate性能検証

Script作成の工数とテスト精度の向上を達成

GoldenGate設計の妥当性判断も可能

検証環境： (ソース)

検証環境： (ターゲット)

Cap

DP REP

本番のCaptureファイル

本番環境： (ソース)


Real Application Testing 機能概要


アップグレードに伴うパフォーマンス問題

全 SQL

実行計画が変わる SQL

性能が劣化する SQL

チューニング対象

一部の SQL のために

全アプリケーションのテストを

するには工数がかかる

エラーが出る SQL や

パフォーマンス劣化が起こる SQL を

簡単に特定したい


Real Application Testing(RAT) とは？

アプリケーションに手を加えずにアップグレードの工数を削減

実業務のワークロードに即したテストができる

– 本番環境での SQL を Capture & Replay

– Upgrade や Patch 適用などによるデータベースの変化に伴うパフォーマンス影響を判断可能

– 疑似クライアントで高負荷状態も再現可能

– 一度の Capture で Transaction のタイミング等を変えてテストの実行が可能

下記の 2 つの機能を包含し、RAT と総称

– SQL Performance Analyzer (SPA)

パフォーマンスへの影響を調査

– Database Replay (DB Replay)

アプリケーションのワークロードを調査

– 実行時間、SQL実行結果行数、エラー内容

データベースに特化したテストを効率化するためのOption機能


SPA と DB Replay の違い用途と機能

※Database Replay と SQL Performance Analyzer はそれぞれ補完しあう機能

SQL Performance Analyzer(SPA) Database Replay(DB Replay)

どんな場面で使い分ける?

特定の重要な SQL に関してシステム変更によるパフォーマンス影響の有無を確認する SQL の単体テスト

データベースサーバー本番環境での負荷を用いサブシステムも含めた包括的なテストを実施する場合

何ができる機能? システム変更に伴う SQL 応答時間の変化の影響を受ける前に確認する

テストシステム上において本番環境の負荷を再現

機能の目的は? SQL の応答時間に対する影響度を評価システムにおけるスループットに対する影響度を評価

仕組みは? SQL Tuning Set に格納された個別の SQL

文を実行しシステム変更前後における実行計画や実行時の統計値の比較を行う

本番環境にて収集された負荷を同時実行性やタイミングおよびトランザクション間の依存性も含め再現を行う


SQL Performance Analyzer (SPA) 基本概念

本番環境テスト環境(11.1以降)

・・・・クライアント

APサーバ

DBサーバ/

ストレージ

①SQLワークロード

の取得

②変更前の

SQL実行

③変更後の

SQL実行 ④分析

DBサーバ/

ストレージ STS

特定範囲に実行されたSQL群の情報


Step 1. SQL ワークロードの取得

SQL ワークロードを SQL Tuning Set (STS) に格納

STS に含まれるデータ

– SQL テキスト

– バインド変数

– 実行計画

– 統計情報

既存の STS に対して SQL を追加可能

一定時間ごとにカーソル・キャッシュから情報収集し、STS に格納

– 9i と 10gR1 は SQL トレースを取得し、 STS への変換が必要

STS に格納する SQL はフィルタリング可能

SQL Performance Analyzer (SPA)

本番環境 SQL Tuning Set


Step 2. 変更前のSQL実行

環境変更後のテストと比較するための

ベースラインを作成

SQL の実行計画と統計情報を取得

SQL をシリアルに実行

各 SQL を1回ずつ実行

DML / DDL は実行されない(default)

– DBMS_SQLPA.EXECUTE_ANALYSIS_TASKプロシージャを使用して EXECUTION_PARAMS の EXECUTE_FULLDML パラメータを TRUE にすることにより、DML も実行可能 (SPA 実行後、ロールバックされる)

SQL を実行せず、

実行計画だけを取得することも可能


SQL Tuning Set

テスト実行

実行計画および

統計情報

結果を保存


Step 3. 変更後のSQL実行

テスト環境に変更を適用

– DB アップグレード、パッチ適用

– オプティマイザ統計情報の更新

– スキーマ変更

– チューニング

変更を適用後、同じ SQL を再実行

– 実行計画と統計情報を収集


SQL Tuning Set

テスト実行

実行計画および

統計情報

結果を保存


Step 4. 分析およびレポート

比較して表示される項目

– 実行時間

– CPU 時間

– バッファ読み取りブロック数

– ディスク読み取りブロック数

– ダイレクト・パス書き込み

– パース時間

– オプティマイザ・コスト

変更適用により、影響のあった SQL を表示

– 性能が改善した SQL

– 性能が劣化した SQL

– 性能が変わらなかった SQL

SQL Tuning Advisor を利用して性能劣化した SQL をチューニング


比較分析

レポーティング


分析レポートの活用

パフォーマンスが劣化した / 改善した SQL

を特定できる

SQL Tuning Advisor や SQL 計画管理を利用して、劣化してしまったSQL のチューニングを実施



SPA の考慮点

ワークロードの取得

– 特に監視を必要とするワークロードやピーク時のワークロードの選択を推奨

テスト環境

– 本番環境とテスト環境が同程度のオプティマイザ統計情報を持つようにする

– 変更適用前後の Buffer Cache のフラッシュを推奨

パフォーマンス劣化の修正

– SQL Tuning Advisor および SQL Plan Baseline を使用して、パフォーマンス劣化を修正


Database Replay (DB Replay)

本番環境の負荷を取得し、そのままテスト環境で再現

基本概念

本番環境 (9.2 と10.2以降) ※個別 Patch 必要な場合あり

テスト環境 (11.1以降)

・・・・クライアント

APサーバ

DBサーバ/

ストレージ

①キャプチャ ②前処理 ③リプレイ ④分析

リプレイ・クライアント

DBサーバ/

ストレージ

ワークロード履歴

(ファイル)のコピー


Step 1. ワークロードのキャプチャ

クライアントからの全リクエストを

バイナリファイルにキャプチャ可能

(キャプチャ・ファイル)

– バックグラウンド処理は除外

セッションを指定し、特定のワークロードの取得/除外が可能

– セッションごとに、***.rec というファイルを作成

– SYS、SYSTEM、DBSNMP、RMAN の除外を推奨

キャプチャの実行時間を指定可能

9.2.0.8 or 10g R2 以降でキャプチャ可能

RAC 環境ではキャプチャ・ファイルの保存先に共有ファイルとローカルファイルの両方をサポート

Database Replay (DB Replay)

キャプチャ・ファイルのサイズ見積もり

(SQL*Net bytes from client) × 2

キャプチャ時のオーバーヘッド

CPU使用率:3～5%程度

本番環境


Step 2. ワークロードの前処理 Database Replay (DB Replay)

事前準備

– 本番環境で取得したキャプチャ・ファイルをテスト環境へコピー

– データを本番環境でのキャプチャ開始時点の内容に合わせておく

キャプチャ・ファイルをリプレイ可能なフォーマットに変換(リプレイ・ファイル)

※リプレイする環境で実施することを推奨

リプレイ・ファイルは何度でも実行可能

RAC 環境でキャプチャした場合は、全インスタンスで生

成されたキャプチャ・ファイルを一か所に集め、前処理を実施

リプレイ・ファイルキャプチャ・ファイル

テスト環境


Step 3. ワークロードのリプレイ Database Replay (DB Replay)

本番環境で取得されたワークロードの実行時間、並列度、コミット順を再現してリプレイ

リプレイ・クライアントがリクエストをDBサーバに送信

クライアントはスレッドで実行されるため、1プロセスで複

数並列度を再現可能。しかし負荷が大きい場合には必要に応じてクライアントを複数プロセス起動する（1プロセス最大50セッション）

11.2.0.3 + Patchで Consolidated Database Replay

が可能

スキーマレベルの Database 統合のテストを実施する際に利用する機能

リプレイ・ファイル

テスト環境

リプレイ・クライアント


(ご参考)リプレイ・オプション Database Replay (DB Replay)

パラメータ説明備考

Synchronization このパラメータはワークロード・リプレイ時に使用される同期のタイプを決定します。このパラメータがSCNに設定された場合、取得されたワークロードの COMMIT順序はリプレイ中もグローバルに保持され、取得時間SCNが小さいすべてのCOMMITアクションが完了した後でのみ、リプレイされたすべてのリクエストが実施されます。このパラメータがOBJECT_IDに設定されている場合、取得時間SCN値とデータベース・オブジェクトの両方に基づくより精度の高い同期方法を使用して、リプレイされたコール間の依存性が計算されます。デフォルト値はSCNです。

OFFに設定した場合、COMMIT発行順序性が担保されない事から、通常においては必ずSCN

を設定します。

connect_time_

scale

ワークロード取得が開始されてから、指定した値でセッションが接続されるまでの経過時間を変更します。

入力は、%値として解釈されます。

ワークロードのリプレイ中に同時ユーザー数を増加または削減する場合に使用できます。DEFAULT VALUE

は100です。

何を評価するのかに依存しますが、DBのみのActivityを評価する場合は0に設定することも検討します。

think_time_

scale

同じセッションからの2つの連続したユーザー・コール間の経過時間を変更します。

入力は、%値として解釈されます。

ワークロードのリプレイ中に同時ユーザー数を増加または削減する場合に使用できます。

DEFAULT VALUEは100です。

何を評価するのかに依存しますが、DBのみのActivityを評価する場合は0に設定することも検討します。

think_time_auto

_correct リプレイでのユーザー・コールの完了にかかる時間が、元の取得で同じユーザー・コールの完了にかかった時間よりも長くなる場合に、コール間の思考時間を適切に自動修正します。

DEFAULTのTRUEでは、リプレイが取得よりも遅くなった場合に思考時間が短縮されます。

通常TRUEに設定することで対応します。


Step 4. 分析およびレポート Database Replay (DB Replay)

キャプチャ時とリプレイ時の違いをレポート

パフォーマンスの違い

エラーの違い

リプレイ時に発生した新規エラー

キャプチャ時に発生していたがリプレイ時に発生しなかったエラー

キャプチャ時に発生していたがリプレイ時に変異したエラー

データの違い

キャプチャ時と異なる行数が変更された DML

キャプチャ時と異なる件数が返された SELECT

リプレイ実行後、比較レポートを生成

ワークロード・リプレイレポート

AWR 比較レポート

ASH レポート


分析レポートの活用 Database Replay (DB Replay)

開始時間と終了時間や、取得時と Replay 時

の処理時間を比較し、全体性能の劣化がないかを確認

エラーの有無も確認可能

結果の概要

詳細 AWR


違いのあるコールの確認

ドリルダウン

違いのあるコール部分の SQL ID 列をドリルダウンすると、詳細の SQL を確認できる

違いの内容まで確認することは不可


Database Replay の考慮点

Capture 前の考慮点

– 出力ファイルを保存するためのストレージ容量

– CPU オーバーヘッド

Capture 期間

– 最初は極力短い時間で実施し、その後期間を延長していくことを推奨

– 特に監視を必要とするワークロードやピーク時のワークロードの選択を推奨

Capture 時のデータの整合性の担保

– Replay 時の再現性を高めるため、Capture 前に Oracle Database を

RESTRICT モードで起動することを推奨

(Capture 開始後は自動的に通常 OPEN 状態に戻る)


RAT のまとめ (再掲) 用途と機能

SQL Performance Analyzer Database Replay

どんな場面で使い分ける? 特定の重要な SQL に関してシステム変更によるパフォーマンス影響の有無を確認する SQL の単体テスト

データベースサーバー本番環境での負荷を用いサブシステムも含めた包括的なテストを実施する場合

何ができる機能? システム変更に伴う SQL 応答時間の変化の影響を受ける前に確認する

テストシステム上において本番環境の負荷を再現

機能の目的は? SQL の応答時間に対する影響度を評価システムにおけるスループットに対する影響度を評価

仕組みは? SQL Tuning Set に格納された個別の SQL 文を実行しシステム変更前後における実行計画や実行時の統計値の比較を行う

本番環境にて収集された負荷を同時実行性やタイミングおよびトランザクション間の依存性も含め再現を行う

※Database Replay と SQL Performance Analyzer はそれぞれ補完しあう機能


RAT の活用手順 (Best Practice)

本番環境から

STSとCapture File を取得

評価

SPA 実行

チューニング DB Replay 実行

チューニング評価

移行先環境へ適用

OK NG

OK

NG STS Report

Replay Report /

AWR Report

STS

Capture File

Capture の時間は1時間程度

※徐々に延長していくことを推奨

Capture 時のDB の状態を統一するため、

RESTRICTモードでの起動を推奨

本番環境を停止できない場合、

SCN で DB の状態をそろえることを推奨


単体/結合テスト

SQL 性能確認/改善

シナリオ検討/準備

シナリオ性能確認/改善

通常

RAT

利用時

総合/移行テスト

SQL 性能確認/改善

– 劣化する SQL を探す工数を削減

– SQL Tuning Advisor によりチューニングを実施

シナリオ検討/準備

– DB Replay により、本番環境と同じシナリオを利用

シナリオ性能確認/改善

– 問題のあった SQL を瞬時に特定

– 何度でも同じテストを実行

RAT のポイント工数削減のポイント


まとめ

<Insert Picture Here>


まとめ

パッチの種類・サポート期間を考慮した選択

11.2.0.4の新機能の活用

最新機能を活用した安心Upgrade

11.2.0.4を安心してご利用ください

oracle database 11g r2 の最新 最終パッチセッ …...2013/12/11 · 2010 today 1 2012 2013...

Documents

oracle database 11g r2 の最新最終パッチセッ …...2013/12/11 · 2010 today 1 2012 2013...