oracle database 11g への移行 - 詳細ガイドパート2...compatible パラメータ• 9i...

アジェンダ

準備

インストール

アップグレード

変更点とタクリトパラメータプロセス留意事項診断とチューニング

変更点とタスク・リスト

留意事項ツール自動化

LOB とSecureFiles

診断とチュニング

パフォーマンス・テスト LOB とSecureFilesフラッシュバック

ADR圧縮

ベスト・プラクティス

1© 2010 Oracle Corporation

COMPATIBLE パラメータ

• 11g データベースに対応するには、COMPATIBLE を少なくとも10.1.0 にする必要がある10.1.0 にする必要がある

• 11.1.0 以上をいったん有効にしたら、元に戻すことはできない• 10.1.0.5、10.2.0.2 以上、11.1.0.6 以上へのリリース・ダウングレードを、、サポート

• ALTER DATABASE RESET COMPATIBILITY コマンドはもはや

使用することはできない使用することはできない

COMPATIBLE = 10.0/1/2.0

COMPATIBLE = 11.0.0COMPATIBLE = 11.0.0



• 9i から11g へのアップグレードに関する注意事項:• 11g 環境での9i データベース起動前に、DST パッチの適用を必ず11g 環境での9i デタス起動前に、DST パッチの適用を必ず確認する

• 9i 11g の移行では、COMPATIBLE を必ず10.1以上にセット

するとはきな• COMPATIBLE=9.2.0 にすることはできない

• COMATIBLE の設定を上げてデータベースをOpen した後は、

元に戻すことはできない元に戻すことはできない

COMPATIBLE ≥ 10.1/2.0COMPATIBLE ≥ 10.1/2.0



• DBUA は9i データベースに対してのみ、COMPATIBLE を上げる

• アップグレード後に新しい機能を有効にするには:• アップグレド後に新しい機能を有効にするには: • 11.1: SQL> alter system

set compatible='11.1.0' scope=spfile;SQL> alter system

set compatible='11.1.0' scope=spfile;

• 11.2 : SQL> alter systemset compatible='11 2 0' scope=spfile;

SQL> alter systemset compatible='11 2 0' scope=spfile;

その後デタベスを再起動する

set compatible='11.2.0' scope=spfile;set compatible='11.2.0' scope=spfile;

• その後: データベースを再起動する

• 新しい機能が有効になる

• データファイルのヘッダーが調整されるデタファイルのッダが調整される

• 初回アクセス時にREDOログファイルが調整される


11g の新しいパラメータ

• Oracle リファレンス “新機能“ 内のリスト参照http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/whatsnew.htm#sthref6

• New in 11.1.0.6:• ASM_PREFERRED_READ_FAILURE_GROUPS

CLIENT_RESULT_CACHE_LAGCLIENT_RESULT_CACHE_SIZECOMMIT_LOGGINGCOMMIT WAIT

PARALLEL_IO_CAP_ENABLEDPLSCOPE_SETTINGSREDO_TRANSPORT_USERRESOURCE_MANAGER_CPU_ALLOCATION

COMMIT_WAITCONTROL_MANAGEMENT_PACK_ACCESSDB_LOST_WRITE_PROTECTDB_SECUREFILEDB_ULTRA_SAFEDDL LOCK TIMEOUT

RESULT_CACHE_MAX_RESULTRESULT_CACHE_MAX_SIZERESULT_CACHE_MODERESULT_CACHE_REMOTE_EXPIRATIONSEC CASE SENSITIVE LOGON

DDL_LOCK_TIMEOUTDIAGNOSTIC_DESTGLOBAL_TXN_PROCESSESJAVA_JIT_ENABLEDLDAP_DIRECTORY_SYSAUTH

_ _ _SEC_MAX_FAILED_LOGIN_ATTEMPTSSEC_PROTOCOL_ERROR_FURTHER_ACTIONSEC_PROTOCOL_ERROR_TRACE_ACTIONSEC_RETURN_SERVER_RELEASE_BANNERXML DB EVENTS

MEMORY_MAX_TARGETMEMORY_TARGETOPTIMIZER_CAPTURE_SQL_PLAN_BASELINESOPTIMIZER_USE_INVISIBLE_INDEXESOPTIMIZER USE PENDING STATISTICS

XML_DB_EVENTS

_ _ _OPTIMIZER_USE_SQL_PLAN_BASELINES

• New in 11.1.0.7 (for Exadata/SAGE):• CELL_OFFLOAD_PROCESSING

CELL OFFLOAD DECRYPTIONCELL_OFFLOAD_COMPACTIONCELL OFFLOAD PLAN DISPLAY

5

_ _CELL_OFFLOAD_PARAMETERS

_ _ _

© 2010 Oracle Corporation

11g Release 2 の新しいパラメータ

• Oracle リファレンス “新機能“ 内のリスト参照http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/whatsnew.htm#sthref6

• New in 11 2 0:• New in 11.2.0:• DEFERRED_SEGMENT_CREATIONDST_UPGRADE_INSERT_CONVLISTENER_NETWORKSPARALLEL_DEGREE_LIMITPARALLEL_DEGREE_POLICYPARALLEL_FORCE_LOCALPARALLEL_MIN_TIME_THRESHOLDPARALLEL_SERVERS_TARGET


11g の新しいパラメータ – 抜粋

• CONTROL_MANAGEMENT_PACK_ACCESS• デフォルト: DIAGNOSTIC+TUNING• デフォルト: DIAGNOSTIC+TUNING• 値: DIAGNOSTIC+TUNING

DIAGNOSTICNONE

• 目的: Diagnostics / Tuning Pack の一部の機能へのアクセスを制御する制御する

• 確認例: CONTROL_MANAGEMENT_PACK_ACCESS=NONECONTROL_MANAGEMENT_PACK_ACCESS=NONE

select count(*) from v$active_session_history;==> 0 rowsselect count(*) from v$active_session_history;==> 0 rows



• DIAGNOSTIC_DEST• デフォルト: $ORACLE BASE• デフォルト: $ORACLE_BASE• 値: OS path/directory• レイアウト:

<diagnostic_dest>/diag/rdbms/<dbname>/<instname>

• 目的: background_dump_dest、user_dump_dest、リスナー・トレースなどを置き換えリスナトレスなどを置き換え、ADRホーム（Automatic Diagnostic Repository）を指定する



• MEMORY_TARGET と MEMORY_MAX_TARGET• デフォルト: 0• デフォルト: 0• 値: integer [K | M | G] • 目的: Oracle サーバーに割り当てるメモリーと大メモリーを

指定する

MEMORY_MAX_TARGET

SGA_MAX_SIZE

MEMORY_TARGET

SGA_TARGET PGA_AGGREGATE_TARGET



• OPTIMIZER_USE_INVISIBLE_INDEXES • デフォルト: FALSE• デフォルト: FALSE• 値: TRUE

FALSE• 目的: FALSEに設定されている場合、オプティマイザは

“見えない” 索引を無視する（ただし、DMLはその索引に対しても実行される）その索引に対しても実行される）

• メリット: 索引によるパフォーマンス効果のテストをセッション・レベルで隔離できる

例• 例: CREATE INDEX emp_ename ON emp(ename) INVISIBLE;

ALTER SESSION SET

CREATE INDEX emp_ename ON emp(ename) INVISIBLE;

ALTER SESSION SETS SS O SOPTIMIZER_USE_INVISIBLE_INDEXES=TRUE;

S SS O SOPTIMIZER_USE_INVISIBLE_INDEXES=TRUE;



• SEC_CASE_SENSITIVE_LOGON 1/2• デフォルト: TRUE• デフォルト: TRUE• 値: TRUE

FALSE• 目的: パスワードの大/小文字区別のオン/オフを切り替える

注意: データベース・リンクに対しても有効となる！

• 情報:• 情報: SELECT username, password_versions FROM dba_users;

USERNAME PASSWORD_VERSIONS---------- -----------------

SELECT username, password_versions FROM dba_users;

USERNAME PASSWORD_VERSIONS---------- -----------------JONES 10G 11GPRESTON 11GBLAKE 10G

JONES 10G 11GPRESTON 11GBLAKE 10G

変更時のバージョン:

作成時のバージョン:



• SEC_CASE_SENSITIVE_LOGON 2/2• パスワードの大/小文字区別を有効にする際は次の点に注意• パスワドの大/小文字区別を有効にする際は次の点に注意

• 例えば、SCOTT/TIGER というユーザー名/パスワードを使用したスクリプトは、11g でscott/tiger などのユーザー名が作成

されると実行きなくなるされると実行できなくなる• 注意: アップグレード中は、従来のメカニズムがまだ有効

• パスワードで暗号化されたデータベース・リンクはチェックが必要ワ暗号化されたデタリンクはチック必要

• パスワード・ファイルのチェックのために有効にすることも可能

orapwd file=orapwSID password=GeHeIm ignorecase=norapwd file=orapwSID password=GeHeIm ignorecase=n

• 便利なヒントデフォルト・パスワードのビューをチェックするデフォルトパスワドのビュをチェックするDBA_USERS_WITH_DEFPWD


11g の新しいパラメータのデフォルト値

• AUDIT_TRAIL• デフォルト: NONE またはDB• デフォルト: NONE またはDB• 値: NONE

OSXMLDBDB_EXTENDED

• 目的: データベース監査のオン/オフ、監査ログの出力先を決定。アップグレード時、AUDIT_TRAILは9.2/10.1/10.2 (NONE)のデフォルトを保持 11g データベースをゼロから作成のデフォルトを保持。11g デタベスをゼロから作成した場合、デフォルトはDBとなり、監査ログはSYS.AUD$内に記録される


11g Release 2 の新しいパラメータ – 抜粋

• DEFERRED_SEGMENT_CREATION• デフォルト: TRUE• デフォルト: TRUE• 値: TRUE

FALSE目的目的:行が挿入された時、新たに作成された表は、そこではじめてセグメントを割り当てる

• 表領域はローカル管理である必要あり• COMPATIBLE ≥ 11.2.0• 新しい動作 - 11gR2 ではデフォルトg• 利点:

• 多数の表が作成されるが、データが投入されない時、ディスク領域の節約になる。

プリケシイト時間を削減• アプリケーションのインストール時間を削減

• 参照:• 初の行を挿入する時、少しパフォーマンス劣化あり。なぜならその際に新しい

セグメントが作成されるため

14

セグメントが作成されるため。


アジェンダ

準備

インストール





LOB とSecureFiles



ADR圧縮



バックグラウンド・プロセス

• 例:select name, description from v$bgprocess, v$processselect name, description from v$bgprocess, v$processselect name, description from v$bgprocess, v$processwhere paddr=addr;

NAME DESCRIPTION----- -----------------------

select name, description from v$bgprocess, v$processwhere paddr=addr;

NAME DESCRIPTION----- -----------------------

NAME DESCRIPTION----- --------------------------

ARC0 Archival Process 0ARC1 Archival Process 1ARC2 Archival Process 2ARC3 A hi l P 3

ARC0 Archival Process 0ARC1 Archival Process 1ARC2 Archival Process 2ARC3 A hi l P 3

MMAN Memory ManagerMMNL Manageability Monitor Pr 2MMON Manageability Monitor Pr

lARC3 Archival Process 3CJQ0 Job Queue CoordinatorCKPT checkpointDBRM Resource Manager process

ARC3 Archival Process 3CJQ0 Job Queue CoordinatorCKPT checkpointDBRM Resource Manager process

PMON process cleanupPSP0 process spawner 0QMNC AQ CoordinatorRECO distributed recoveryg p

DBW0 db writer process 0DIA0 diagnosibility process 0DIAG diagnosibility processDSKM l DiSKM

g pDBW0 db writer process 0DIA0 diagnosibility process 0DIAG diagnosibility processDSKM l DiSKM

CO d st buted eco e ySMCO Space Manager ProcessSMON System Monitor ProcessVKRM Virtual sKeduler for RMgrVKTM Vi t l K f TiMDSKM slave DiSKMon process

FBDA Flashback Data Archiver Pr.GEN0 General Task Execution Pr.LGWR Redo etc.

DSKM slave DiSKMon processFBDA Flashback Data Archiver Pr.GEN0 General Task Execution Pr.LGWR Redo etc.

VKTM Virtual Keeper of TiMe pr

BLUE: New in 11gR2RED: New in 11gR1

16

g


新しいバックグラウンド・プロセスプロセス

名説明対象

RAC環境では、このインスタンス単位のプロセス（Atomic Controlfile to Memory Service）は、配布される

ACMSy

SGAメモリー・アップデートがグローバルにコミットされることと、またエラー時にはグローバルに中止されるようにすることを保証するためのエージェントになります。 RAC

DIA0 ハング検出とデッドロック解決のために機能します。すべて

DIAG 診断情報のダンプを実行するとともに、oradebugコマンドをグローバルに実行します。すべて

DBRM Resource Managerプロセスは、Resource Plansの設定と、Resource Managerに関連するその他のタスクを受け持ちますすべて受け持ちます。

EMNC / e0xx

Event Monitor Coordinatorは、データベース内におけるイベント管理と通知アクティビティを調整します（Streams Event Notifications、Continuous Query Notifications、Fast Application Notificationsなど）。

イベント・アクティビティが登録されているすべて

(non-fatalオプション有)

FBDA 追跡する表内の行の履歴をフラッシュバック・データ・アーカイブ内にアーカイブし、そのフラッシュバック・アーカイブを管理します。すべて

GEN0 一般的なタスク実行プロセス。SQLとDMLを含む要求されたタスクを実行します。すべて

GMON ASMディスク・グループのディスク・メンバーシップを保持します。 ASM

GTX0-j RAC環境内のXAグローバル・トランザクションを透過的にサポートします。データベースは、これらのプロセスの数をXAグローバル・トランザクションの処理負荷に基づいて自動的に調整します。 RAC のみ


新しいバックグラウンド・プロセスプロセス

名説明対象

KATE のみデクがオライになる際メタイに対してプキシを実行しますASMKATE 11.1 のみ --ディスクがオフラインになる際、ASMメタファイルに対してプロキシI/Oを実行します。ASM

（オンデマンドで実行）

MARK オフラインのディスクへの書込みに失敗したとき、ASMの割当てユニットをstaleとしてマークします。ASM

（オンデマンドで実行）

PING インターコネクトのレイテンシを計測するプロセス。PING インタコネクトのレイテンシを計測するプロセス。各クラスタ・インスタンス・ペアの通信に関連するレイテンシを評価します。 RAC のみ

PSP0 Oracleプロセスを実行します。すべて

RMSn このRAC管理プロセスは、RACの管理タスクを実行します（新しいインスタンスがクラスタに追加されたときに、RAC関連のリソースを作成するなど）。 RAC のみ

RMSNこのプロセスは、RAC環境におけるバックグラウンド・スレーブ・プロセスの作成と、リモート・インスタンスとの

通信を管理します。作成されたバックグラウンド・スレーブ・プロセスは、別のインスタンスで実行中の RAC のみRMSN 通信を管理します。作成されたバックグラウンドスレブプロセスは、別のインスタンスで実行中の調整プロセスに代わってタスクを実行します。

RAC のみ

SMCO / Wnnn

この領域管理プロセスは、先読み型の領域割当てや領域の再利用など、さまざまな領域管理タスクの実行を調整します（タスクの実装にあたっては、スレーブ・プロセス（Wnnn）が動的に実行されます）。すべて

(non-fatalオプション有)

VKRM VKRMはOracleのプロセスを管理する全てのCPUスケジューリングを管理します。リソース・マネージャのアクティブなリソース・プランに従って管理されるプロセスをスケジュールします。

すべて (オプション)

VKTM このプロセス（Virtual Keeper of TiMe?）は、ウォールクロック時間（毎秒更新）と参照時間カウンタ（20ミリ秒

ごとに更新され、高優先度での実行時にのみ利用可能）の提供を受け持ちます。すべて


アジェンダ

準備

インストール





LOB とSecureFiles



ADR圧縮



CONNECT ロール

• CONNECTロールは10gR2以降、次のように変更:GRANTEE PRIVILEGEGRANTEE PRIVILEGEGRANTEE PRIVILEGE----------------------- -------------------CONNECT CREATE VIEWCONNECT CREATE TABLE

GRANTEE PRIVILEGE----------------------- -------------------CONNECT CREATE VIEWCONNECT CREATE TABLECONNECT CREATE TABLECONNECT ALTER SESSIONCONNECT CREATE CLUSTERCONNECT CREATE SESSION

CONNECT CREATE TABLECONNECT ALTER SESSIONCONNECT CREATE CLUSTERCONNECT CREATE SESSIONCONNECT CREATE SESSIONCONNECT CREATE SYNONYMCONNECT CREATE SEQUENCECONNECT CREATE DATABASE LINK

CONNECT CREATE SESSIONCONNECT CREATE SYNONYMCONNECT CREATE SEQUENCECONNECT CREATE DATABASE LINKCONNECT CREATE DATABASE LINK CONNECT CREATE DATABASE LINK

GRANTEE PRIVILEGEGRANTEE PRIVILEGER2 GRANTEE PRIVILEGE----------------------- -------------------CONNECT CREATE SESSION

GRANTEE PRIVILEGE----------------------- -------------------CONNECT CREATE SESSION

R2


CONNECT ロール

• 影響を受けるデータベース・ユーザーを検出:SELECT tSELECT tSELECT granteeFROM dba_role_privs

WHERE granted_role = 'CONNECT' and

SELECT granteeFROM dba_role_privs

WHERE granted_role = 'CONNECT' andgrantee NOT IN ('SYS', 'OUTLN', 'SYSTEM',

'CTXSYS', 'DBSNMP','LOGSTDBY_ADMINISTRATOR',

grantee NOT IN ('SYS', 'OUTLN', 'SYSTEM','CTXSYS', 'DBSNMP','LOGSTDBY_ADMINISTRATOR',_'ORDSYS', 'ORDPLUGINS','OEM_MONITOR', 'WKSYS','WKPROXY', 'WK TEST',

_'ORDSYS', 'ORDPLUGINS','OEM_MONITOR', 'WKSYS','WKPROXY', 'WK TEST', O , _ S ,'WKUSER', 'MDSYS','LBACSYS', 'DMSYS', 'WMSYS','EXFSYS' 'SYSMAN'

O , _ S ,'WKUSER', 'MDSYS','LBACSYS', 'DMSYS', 'WMSYS','EXFSYS' 'SYSMAN'EXFSYS , SYSMAN ,'MDDATA', 'XDB', 'ODM','SI_INFORMTN_SCHEMA');

EXFSYS , SYSMAN ,'MDDATA', 'XDB', 'ODM','SI_INFORMTN_SCHEMA');


10g以降での共有プールの計算

• 10g以降、shared_pool_size パラメータの計算方法が変更された更された

• 実際の共有プール = shared_pool_size – 起動オーバーヘッド

SQL> l t * f $ i fSQL> l t * f $ i fSQL> select * from v$sgainfo;

NAME BYTES RES-------------------------------- ---------- ---Fi d SGA Si 1266372 N

SQL> select * from v$sgainfo;

NAME BYTES RES-------------------------------- ---------- ---Fi d SGA Si 1266372 NFixed SGA Size 1266372 NoRedo Buffers 2924544 NoBuffer Cache Size 16777216 YesShared Pool Size 83886080 YesLarge Pool Size 0 Yes

Fixed SGA Size 1266372 NoRedo Buffers 2924544 NoBuffer Cache Size 16777216 YesShared Pool Size 83886080 YesLarge Pool Size 0 YesLarge Pool Size 0 YesJava Pool Size 50331648 YesStreams Pool Size 0 YesGranule Size 4194304 NoMaximum SGA Size 155189248 No

Large Pool Size 0 YesJava Pool Size 50331648 YesStreams Pool Size 0 YesGranule Size 4194304 NoMaximum SGA Size 155189248 NoMaximum SGA Size 155189248 NoStartup overhead in Shared Pool 29360128 NoFree SGA Memory Available 0

Maximum SGA Size 155189248 NoStartup overhead in Shared Pool 29360128 NoFree SGA Memory Available 0


GROUP BY 結果: ソートなし

• "Hash Group by" 集計により、ハッシュ・アルゴリズムでGROUP BY文を処理可能に文を処可能

• ソートには、ORDER BYを使用する必要がある

select sum(sal) deptno from scott emp group by deptno;select sum(sal) deptno from scott emp group by deptno;select sum(sal), deptno from scott.emp group by deptno;select sum(sal), deptno from scott.emp group by deptno;

SUM(SAL) DEPTNO---------- ----------SUM(SAL) DEPTNO

---------- ----------SUM(SAL) DEPTNO

---------- ---------SUM(SAL) DEPTNO

---------- ---------8750 10

10875 209400 30

8750 1010875 209400 30

9400 3010875 208750 10

9400 3010875 208750 10

• 説明 Note:345048.1• _gby_hash_aggregation_enabled=false

• 参照Note:295819.1 Potential Query Tuning Related Issues


セキュア・ビュー・マージ権限

• 10gR2で、複合ビュー構造のセキュリティに関するオプティマイザの問題を防ぐには:

• optimizer_secure_view_merging=false

• これをおこなわないと、複数の異なるユーザー・スキーマから同じオブジェクトに対する同じ文が発行された場合にオプティマイザがそブジェクトに対する同じ文が発行された場合に、オプティマイザがそれぞれ異なる実行計画を作成する可能性がある。

• 代替策:特定のユーザーに、MERGE ANY VIEW 権限を許可特定、権限を許

• Note:468380.1 参照


カスケードされたビューの問題 - 10.2.0.x• カスケードされたビューがある場合、オプティマイザが

間違ったリライトをすることがある間違ったリライトをすることがある

• 要件

• “ push join predicate” を TRUE に設定する_push_join_predicate を TRUE に設定する

• 解決方法

• 10.2.0.4に次のパッチを適用する: #744527610.2.0.4に次のパッチを適用する: #7445276

• または、 _optimizer_join_elimination_enabled=false

• これらをおこなわない場合、次のことが発生する可能性がある

• 問合せ: select * from some_view where col1=10;結果:

• 問題なし: select * from (select * from base_table where col1=10);

• 問題あり: select * from (select * from base table) where col1=10;• 問題あり: select * from (select * from base_table) where col1=10;


10g以降でのコストベースの問合せ変換

• 調査結果：10/11g へのアップグレード後は問合せのタイミングに関す10/11g へのアップグレド後は、問合せのタイミングに関する問題が発生する

• 10g以降、CBOには、コストベースの副問合せに対するネスト解除と、ビジ機能が追加されたビュー・マージの機能が追加された

• これは無効にすることができる• _optimizer_cost_based_transformation=off


10g以降でのCBOの結合順序検証

• 10g以降、CBOでは、よりコストの低い結合順序を割り出せるよう検証する結合順序の数を増加割り出せるよう、検証する結合順序の数を増加- これにより、解析時間が長くなることがある

• 解決方法: new initial join orders=false解決方法 _ _ _j _

• 例: EXPLAIN PLANでの調査結果

• Set OFE=920: 試行された結合置換の回数: 187

• Set OFE=10203: 試行された結合置換の回数: 986


10.2.0.4以降では、PL/SQLカーソルがキャッシュされない

• 10.2.0.4より前のリリースでは、PL/SQL カーソルはOPEN CURSORS に基づいて自動的にキャッシュされてOPEN_CURSORS に基づいて自動的にキャッシュされて

いたが、10.2.0.4以降では、PL/SQL 用のカーソル・キャッシュを確保するためSESSION_CACHED_CURSORS を定義する必要がある

• 解決方法: session_cached_cursors=500


11.1.0.6 以降では、表キャッシュが変更

• 大きな表は、ALTER TABLE CACHE 属性に関わらず、順次FTS (full table scan) のためのキャッシュがされない順次FTS (full table scan) のためのキャッシュがされない可能性が高い

• 対処方法: small table threshold を設定対処方法 _ _ _ を設定

• 例:• CREATE TABLE big_has_95000_rows(...);

• あらかじめ強制的にロード:ALTER SESSION SET "_small_table_threshold"=100000;SELECT /*+FULL(a) */ ... FROM big_has_95000_rows;

• 表がキャッシュされ、保持される


Bug 7596023• ORA-7445 [kkqtutlGenRowid()+157]

• Bug 7596023• Bug 7596023• 11.1.0.7 にパッチを適用

もしくはもしくは:

• 回避策:回避策

• “_optimizer_join_elimination_enabled”=false を設定

• bug 6167716 に対する修正を無効にする:• bug 6167716 に対する修正を無効にする:“_FIX_CONTROL”=‘6167716:OFF‘ を設定


インスタント・クライアント

• 汎用性に富み、フットプリントの小さいOracle クライアント• OCI OCCI Pro*C ODBC JDBC ODP NET ASP NET OLE DBOCI、OCCI、Pro C、ODBC、JDBC、ODP.NET、ASP.NET、OLE DB

およびOO4O の各アプリケーションに対応

• OUIによるOracle クライアントのインストールは不要

ププ• 簡単でシンプルなデプロイ• OTNからダウンロード可能

タゲトやクライアントのシステムにコピ• ターゲットやクライアントのシステムにコピー

• コピーしたディレクトリを PATH / LD_LIBRARY_PATH へ追加し、TNS_ADMINを設定_

• ODBCについては、提供されているバッチ・スクリプトを実行

• パッチ適用は、現バージョンを配置するだけ

• OTN上の詳細:• OTN上の詳細:http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html



• インスタント・クライアントのダウンロード:http://www.oracle.com/technology/software/tech/oci/instantclient/index.html



• インスタント・クライアントのパッケージ

• Basic: All files required to run OCI, OCCI, and JDBC-OCI applications (46 MB)q , , pp ( )• JDBC Supplement: Additional support for XA, Internationalization, and RowSet operations under JDBC (1.5 MB)• SQL*Plus: Additional libraries and executable for running SQL*Plus with Instant Client (0.8 MB) • SDK: Additional header files and an example makefile for developing Oracle applications with Instant Client (1 MB)• ODBC: Additional libraries for enabling ODBC applications (0.7 MB)• WRC: Workload Replay Client used to replay workload for RAT's DB Replay Feature (6 KB)

33

p y p y p y ( )• ´Precompiler: Additional files for "proc" binary and related files to precompile a Pro*C application and demo (0.5 MB)


クライアントのサポート状況

• クライアントのサポート状況 - Note: 207303.1Database リリース

10.1.0 9.2.0 9.0.1 8.1.7Database リリース

10.2.0⌧ ⌧

11.1.011.2.0 ⌧⌧

11.2.0

クライ

⌧ ⌧10.2.0 ⌧ ⌧

⌧

⌧

⌧ ⌧⌧

⌧⌧ ⌧ ⌧11.1.0 ⌧⌧

⌧

⌧ ⌧ ⌧⌧ ⌧ ⌧⌧ ⌧10.1.0

9.2.09 0 1

イアン ⌧⌧

⌧⌧⌧

⌧⌧

⌧ ⌧⌧ ⌧ ⌧9.0.1

8.1.7ト

⌧⌧⌧

⌧⌧ 動作保障

サポート終了サポート外

⌧サポート（ただしES）

34

⌧ サポ終了サポト外


クライアントのサポート状況

• データベース・リンク• 対応表で双方向に “サポート” となっている場合のみサポート対応表で、双方向にサポトとなっている場合のみサポト

• サポート外の場合は、各自の責任において使用

• JDBCのサポート情報のサポト情報• Note:401934.1

• ODBCのサポート情報• Note:66403.1• ODBC Drivers as part of ODAC

http://www oracle com/technology/software/tech/windows/odpnet/indhttp://www.oracle.com/technology/software/tech/windows/odpnet/index.html

• Forms / Reportsのサーティファイ情報p• Metalink 「Certify」タブ「Development Tools」


11g Release 2の 32bit クライアント

• 11g Release 2 には $ORACLE_HOME/lib32が存在しない

• 32-bit のライブラリは、Oracle データベース・サーバ 64-bitとOracle データベース・クライアント 64-bitのメディアに含まれないい

• 解決策:32 bit のライブラリが必要な場合別メデアとして出荷された32 bitの• 32-bit のライブラリが必要な場合、別メディアとして出荷された32-bitのクライアントをインストールする

• 新しい Oracle homeにインストール新

• 参照 Note:883702.1


RMAN – リカバリ・マネージャ

• RMAN 互換性マトリックス• Note:73431 1Note:73431.1

• 規則:• RMAN の実行可能なバージョンは、ターゲット・データベースと同じであるべき

• RMAN のカタログ・スキーマバージョンはRMAN実行可能なバージョンよりも上もしくは同じでなければならない

• RMAN カタログは、以前のリリースからのターゲット・データベースに下位互換がある


アプリケーションのアップグレード

• 互換性の問題：• 予約語のチェック• 予約語のチェック

• Upgrade Guide 付録A

• 動作変更のチェック• Upgrade Guide 付録A• Upgrade Companion

• データ・ディクショナリ内の変更のチェックィリ変更• Upgrade Guide 付録A



• プリコンパイラとOCIアプリケーション：

• Oracle Database Server ソフトウェアのアップグレド• Oracle Database Server ソフトウェアのアップグレード

• クライアント環境を変更していない場合、プリコンパイル、コンパイル、および再リンクをおこなう必要はない

• Database Server のバージョンは、クライアントのバージョンと同じか、またはそれ以上である必要がある

Oracle Client ソフトウアのアップグレド• Oracle Client ソフトウェアのアップグレード

• Oracleクライアント・ソフトウェアについては、サーバーと同じリリースのものを使用するのが望ましい

• 動的ライブラリ: 再リンク不要

• 静的ライブラリ: 常に再リンクが必要



• プリコンパイラとOCIアプリケーション

• 選択肢1：アプリケーションを変更しない選択肢アリケションを変更しな

• 例えば、Oracle9iで開発したアプリをOracle Database 11g で継続動作させるケース

• クライアントのアップグレードは不要

• シンプルで簡単シンプルで簡単

• Oracle Database 10g/11g の新機能や、パフォーマンス・メリットを活用できない

• 選択肢2：アプリケーションを新しい Oracle Database 11g ライブラリと再リンクさせるさせる

• コード変更なし、再コンパイルなしで Oracle Database 11g ライブラリに再リンク

• パフォーマンスの若干の向上を見込める

選択肢3 コド変更し Oracle Database 10g/11g 新機能を取り込む• 選択肢3：コード変更し、Oracle Database 10g/11g 新機能を取り込む

• Oracle Database 10g/11g の機能のメリットを活かすことができる

• パフォーマンスとスケーラビリティを大化することができる

ド変更のストが番高い方法• コード変更のコストが一番高い方法


ワードサイズ

• 32/64ビットのワードサイズ変更は、アップグレード/ダウングレードのプロセス中、暗黙的におこなわれるダウングレドのプロセス中、暗黙的におこなわれる• これはパッチ・セットについても同様

• アップグレードせずに32-bitと64-bitを変更するには、全パッケージとストアド・コードを無効化する utlip.sqlが必要になる


XE、SE、およびEE間の変換

• SE EE Note:117048.1を参照• フル・バックアップを取得フルバックアップを取得

• EE環境でcatalog.sql とcatproc.sql を実行

• EE SE Note:139642.1 を参照• サポートされるのは、exp/imp、またはexpdp/impdp を使用したエクスポート/インポートのみエクスポート/インポートのみ

• XE SE/SEone/EEXE SE/SEone/EE• http://download.oracle.com/docs/cd/B28359_01/server.111/b28300/intro.htm#BABGDCDD

• XEデータベースからSEone/SE/EEへのアップグレードには、DBUAを使用


アジェンダ

準備

インストール





LOB とSecureFiles



ADR圧縮



Enterprise Manager 11g

• Database Control - すべてのデータベース管理タスクをカバー•

• Grid Control - ITシステム管理ツール• Oracle、および非Oracleの各種ITインフラストラクチャをサポート

• GCパッチ・セット10.2.0.5に11g管理機能が含まれている

• Grid Control 11g は未提供


Enterprise Manager 11g

• コンポーネント• Database Control：Database Control：エージェントとスタンドアロンOC4J - 追加のWebサーバーは不要

• Grid Control：OMS M t A t R it D t bOMS、Management Agent、Repository Database

• インストール：• Database Control：• Database Control：

11gデータベース・ソフトウェアのインストール内で自動的に実行される

• Grid Control：ダウンロードまたはDVDでの個別提供

• ライセンス：両製品ともすべてのデタベスライセンスに含まれている• 両製品とも、すべてのデータベース・ライセンスに含まれている

• 特定のパックやプラグインが追加的にライセンス供与される場合もあり


SQL Developer 1.5.5• 追加コストの要らない開発ツール

http://www.oracle.com/technology/products/database/sql_developer/index.html

• 主な機能:• PL/SQLの開発とデバッグ

きわ高速なブジブザ• きわめて高速なオブジェクト・ブラウザ

• スキーマのコピーと比較

• Oracle 9iR2 以上をサポート• Oracle 9iR2 以上をサポト

• 以下に対応したMigration workbench:• MS SQL Server• MS Access

MySQL• MySQL• 追加ライセンス・コストは必要なし!


APEX 3.2• APEX = Application Express = ex-HTMLDB

• GUI開発環境GUI開発環境

• ウィザード・ドリブンで使いやすい

• Forms 変換アシスタント

• APEXはデフォルトで利用可能追加のインストルやライセンスは不要• 追加のインストールやライセンスは不要

• 現行のリリース: 3.2.1

• “Embedded Gateway” 経由のHTTP処理

構成プ• 構成作業は2つのステップ:• $ORACLE_HOME/apex/apxconf.sql• ALTER USER anonymous ACCOUNT UNLOCK;

47

• ALTER USER anonymous ACCOUNT UNLOCK;


APEX• 重要なAPEX のページ:

http://www.oracle.com/technology/products/database/application_express/index.html

htt // lhttp://apex.oracle.com


アジェンダ

準備

インストール





LOB とSecureFiles



ADR圧縮



11gでの自動化

• EM: スケジューラ・セントラル


11gでの自動化

• アップグレード後、メンテナンス・ウィンドウをチェック


11gでの自動化

• ジョブ – デフォルトのメンテナンス・ウィンドウ

240分 = 4時間 1200分 = 20時間240分 = 4時間 ... 1200分 = 20時間


11gでの自動化

• Segment Advisor で、解放可能な領域を自動検出


メカニズム: 表のスケール・ダウン

ハイウォーターマーク

表をコピー

• 追加のストレージが必要

• 古い表を削除古い表を削除

• 索引をメンテナンス



メカニズム: 表のスケール・ダウン

データを移動High

Watermark


• オンライン

索引がされる• 索引がメンテナンスされる

• トリガーは実行されない• ただし表領域はASSMである必要がある

をげるた排他表が• HWMを下げるためには排他表ロックが必要

ALTER TABLE <tablename> SHRINK SPACE;


アジェンダ

準備

インストール





LOB とSecureFiles



ADR圧縮



LONG LOB の変換

• LONGデータ型は現在もサポートされているが、LOB型に変換することを推奨

LONG LONG RAW

CLOB NCLOB BLOB

LONGの不便な点

CLOB NCLOB BLOB

• LONGの不便な点

• 表あたりのLONG列の大数 : 1• LONGとLONG RAWでのレプリケーションは不可

• 注意• LONG LOB の変換後は逆変換できない


LONG LOB の変換

• 変換ALTER TABLE long tab MODIFY ( long col CLOB );ALTER TABLE long tab MODIFY ( long col CLOB );

• オンラインでの表の再定義

ALTER TABLE long_tab MODIFY ( long_col CLOB ); ALTER TABLE long_tab MODIFY ( long_col CLOB );

オンラインでの表の再定義• 10g以降、LONG/LOBについて可能に

• パッケージ: DBMS_REDEFINITION 規定• 規定

• LONG CLOB• LONG RAW BLOB

• 変換は暗黙的に実行される

• 詳細: Note:251417.1 （詳細なサンプルを含む）

• 利点実行中、元表を常に使用可能


SecureFiles• SecureFiles = LOBの新しいストレージ技術

• パフォーマンスが向上ォ向

• 追加機能: 重複除外、暗号化

• 例

CREATE TABLE t1 (a CLOB) LOB(a) STORE AS SECUREFILE;

CREATE TABLE t2 (a CLOB) LOB(a) STORE AS SECUREFILE(DEDUPLICATE)

CREATE TABLE t1 (a CLOB) LOB(a) STORE AS SECUREFILE;

CREATE TABLE t2 (a CLOB) LOB(a) STORE AS SECUREFILE(DEDUPLICATE)(DEDUPLICATE);

CREATE TABLE t3 (a CLOB ENCRYPT USING 'AES128')LOB(a) STORE AS SECUREFILE (CACHE);

(DEDUPLICATE);

CREATE TABLE t3 (a CLOB ENCRYPT USING 'AES128')LOB(a) STORE AS SECUREFILE (CACHE);

• 表領域はASSMで管理する必要がある

• 追加のinit.oraパラメータDB_SECUREFILE = [NEVER | PERMITTED | ALWAYS | IGNORE]DB_SECUREFILE = [NEVER | PERMITTED | ALWAYS | IGNORE]


SecureFiles• SecureFilesの完全な透過性

• データ型はBLOB/CLOBのままデタ型はBLOB/CLOBのまま

• ストレージ句で定義するか、またはinitパラメータで制御

• 機能的な違いはなし

• “重複除外” も開発者に対して完全に透過的

API クセ• APIアクセスPL/SQL（DBMS_LOB）、JDBC、.NET、PHP...


アジェンダ

準備

インストール





LOB とSecureFiles



ADR圧縮



フラッシュバック

• フラッシュバックのタイプとそのソースはそれぞれ異なる• フラッシュバック問合せフラッシュバック問合せ

• バージョン問合せ

• トランザクション問合せUndo デフォルトで有効

• フラッシュバック表

フラシバクドロプ• フラッシュバック・ドロップデフォルトで有効

• フラッシュバック・データベース

Flashback Logs手動で有効化

Undo• Total Recall

Flashback Data Archive手動で有効化


EMでのフラッシュバック操作

• Enterprise Manager の画面


EMでのフラッシュバック操作

• リカバリの実行


リストア・ポイント

• リストア・ポイント – ジャンプ・ラベルを指定

• 名前付きリストア・ポイント• 名前付きリストア・ポイント• ブックマークに似ている

• 復元は、可能な場合もあるが保証はされない

• 制御ファイルに記録される

SQL> CREATE RESTORE POINT rpt;SQL> FLASHBACK DATABASE TO RESTORE POINT rpt;SQL> CREATE RESTORE POINT rpt;SQL> FLASHBACK DATABASE TO RESTORE POINT rpt;

• 保証付きリストア・ポイントトジナプシトに似る

Q p ;Q p ;

• ストレージ・スナップショットに似ている

• FLASHBACK_RETENTION_TARGETをオーバーライド

• 注意: 保証付きの場合、データベース全体が停止されることがある注意保証付きの場合、デタ全体が停されるとがある

SQL> CREATE RESTORE POINT grptGUARANTEE FLASHBACK DATABASE;

SQL> FLASHBACK DATABASE TO RESTORE POINT grpt;

SQL> CREATE RESTORE POINT grptGUARANTEE FLASHBACK DATABASE;


65

Q g p ;Q g p ;


Flashback Data Archive - Total Recall • どのように機能するか？

• バックグラウンド・プロセスラFBDAは、Flashback DataArchive（非同期）内で、監視対象の表に加えられたデタ変更を追跡するデータ変更を追跡する（UPDATEとDELETEのみ）

• undo情報からデータが抽出される抽出される

• デフォルトのキャプチャ間隔:5分キプ隔 FBDAFBDA• キャプチャ間隔は、システムの動作負荷に応じて自動的に変更される

EEのO i T l R llが

FBDAFBDA

• EEのOption: Total Recallが必要


Flashback Data Archive - Total Recall • 要件:

• FBDA用の表領域はASSMで管理される必要がある用の表領域はで管理される必要がある

• フラッシュバック・データ・アーカイブ用の表領域はなるべく個別に作成し、低価格なストレージ上に置いてコストを抑える

• フラッシュバックデタアカイブの作成:• フラッシュバック・データ・アーカイブの作成:CREATE FLASHBACK ARCHIVE fda1TABLESPACE fda

CREATE FLASHBACK ARCHIVE fda1TABLESPACE fdaTABLESPACE fdaRETENTION 1 year;TABLESPACE fdaRETENTION 1 year;

•

• 特定のオブジェクトに対するフラッシュバック・アーカイブ:ALTER TABLE t1 FLASHBACK ARCHIVE fda1;ALTER TABLE t1 FLASHBACK ARCHIVE fda1;


Flashback Data Archive - Total Recall • 実行される処理

• 表領域fdaに、いくつかの構造が作成される表領域に、くかの構造が作成される

NAME TYP------------------------------ ------------------SYS FBA DDL COLMAP 23107 TABLE

NAME TYP------------------------------ ------------------SYS FBA DDL COLMAP 23107 TABLE_ _ _ _SYS_FBA_HIST_23107 TABLE PARTITIONSYS_FBA_TCRV_23107 TABLESYS_FBA_TCRV_IDX_23107 INDEX

_ _ _ _SYS_FBA_HIST_23107 TABLE PARTITIONSYS_FBA_TCRV_23107 TABLESYS_FBA_TCRV_IDX_23107 INDEX

• 23107は、監視/アーカイブ対象となる表のOBJECT_ID

• 変更を追跡

• 定義された時間に達すると、一定のデータが自動的に削除される定義された時間に達すると、定のデタが自動的に削除される

• 完全に透過的 - アプリケーションへの変更は一切不要

• パーティショニングは自動的におこなわれる


Flashback Data Archive - Total Recall • FDA内のデータに変更を加えることは可能か？

• データは次のように格納される:デタは次のように格納される

ROWID STARTSCN ENDSCN O COL1------------------ ---------- ---------- - ----------AAAFplAAGAAAAAVAAA 1114797 1115141 I 1

ROWID STARTSCN ENDSCN O COL1------------------ ---------- ---------- - ----------AAAFplAAGAAAAAVAAA 1114797 1115141 I 1pAAAFplAAGAAAAAVAAB 1114797 1115141 I 2AAAFplAAGAAAAAVAAC 1114797 1115141 I 23AAAFplAAGAAAAAVAAD 1114797 1115141 I 24AAAFplAAGAAAAAVAAE 1114797 1115141 I 25

pAAAFplAAGAAAAAVAAB 1114797 1115141 I 2AAAFplAAGAAAAAVAAC 1114797 1115141 I 23AAAFplAAGAAAAAVAAD 1114797 1115141 I 24AAAFplAAGAAAAAVAAE 1114797 1115141 I 25AAAFplAAGAAAAAVAAE 1114797 1115141 I 25AAAFplAAGAAAAAVAAF 1115141 1116039 U 2...

AAAFplAAGAAAAAVAAE 1114797 1115141 I 25AAAFplAAGAAAAAVAAF 1115141 1116039 U 2...

• データの操作は不可:SQL> update SYS_FBA_HIST_23107 set col1=col1-1;update SYS_FBA_HIST_23107 set col1=col1-1SQL> update SYS_FBA_HIST_23107 set col1=col1-1;update SYS_FBA_HIST_23107 set col1=col1-1_ _ _

*ERROR at line 1:

ORA-55622: DML, ALTER and CREATE UNIQUE INDEX operations are not allowed on table "SYS"."SYS FBA HIST 23107"

_ _ _*

ERROR at line 1:

ORA-55622: DML, ALTER and CREATE UNIQUE INDEX operations are not allowed on table "SYS"."SYS FBA HIST 23107"

69

not allowed on table SYS . SYS_FBA_HIST_23107not allowed on table SYS . SYS_FBA_HIST_23107


Flashback Data Archive - Total Recall • 履歴データにアクセスするには？

SELECT * FROM t1AS OF TIMESTAMP '27-AUG-07 2:15:00pm';

COL1


COL1----------

12

23

----------12

2323


23


COL1----------

2

COL1----------

23

243

24


Flashback Data Archive - Total Recall • バックグラウンド・プロセスFBDAをオフにするには？

• SQL> ALTER SYSTEM SETSQL> ALTER SYSTEM SETSQL> ALTER SYSTEM SET"_disable_flashback_archiver"=1scope=spfile;

SQL> ALTER SYSTEM SET"_disable_flashback_archiver"=1scope=spfile;

SQL> STARTUP FORCE

$ ps -ef | grep fbda

SQL> STARTUP FORCE

$ ps -ef | grep fbda

• 11gR2 では、デフォルトでプロセスが起動しないため、必要なし


Flashback Data Archive –11.2 新機能

• 表に対して実行されるほとんどのDDLコマンドがサポートされるされる• 列のAdd、Drop、Rename、変更

• パーティションのDrop、Truncate• 表のRename、Truncate• 制約のAdd、Drop、Rename、変更

関連を関連付るためプジを• 関連を断つ/関連付ける、ためのPL/SQL プロシージャを利用して、特定の表でTotal Recall を一時的に無効にすることが可能可能• DBMS_FLASHBACK_ARCHIVE.DISASSOCIATE_FBA• DBMS FLASHBACK ARCHIVE.REASSOCIATE FBA_ _ _


アジェンダ

準備

インストール





LOB とSecureFiles



ADR圧縮



Automatic Diagnostic Repository • ADR: システム全体のロギング/トレーシング用ディレクトリ

• diagnostic destパラメータで設定g _ ラ設定

• デフォルト: ORACLE_BASE


Automatic Diagnostic Repository • ADR: システム全体のロギング/トレーシング用ディレクトリィクリ• "alert.logがすべてXML形式になるのでは...?"

ご安心を• ご安心を

• ファイルはテキスト・モードでも保持される

• 2種類の使いやすいインタフェース:• adrci• EM インターフェース

• ITIL標準に基づいたエラー・カテゴリ

• Problemなど重要なORA-600、ORA-7445、ORA-4031などの重要なエラー...

• Incident偶発的なエラー - 発生頻度が高まってきた場合にはPROBLEM扱いへと変更される！


Automatic Diagnostic Repository •V$DIAG_INFO:

SQL> SELECT name value FROM v$diag info;SQL> SELECT name value FROM v$diag info;SQL> SELECT name, value FROM v$diag_info;

NAME WERT----------------------- ----------------------------------------

SQL> SELECT name, value FROM v$diag_info;

NAME WERT----------------------- ----------------------------------------Diag Enabled TRUEADR Base c:¥oracleADR Home c:¥oracle¥diag¥rdbms¥source¥sourceDiag Trace c:¥oracle¥diag¥rdbms¥source¥source¥trace

Diag Enabled TRUEADR Base c:¥oracleADR Home c:¥oracle¥diag¥rdbms¥source¥sourceDiag Trace c:¥oracle¥diag¥rdbms¥source¥source¥traceDiag Trace c:¥oracle¥diag¥rdbms¥source¥source¥traceDiag Alert c:¥oracle¥diag¥rdbms¥source¥source¥alertDiag Incident c:¥oracle¥diag¥rdbms¥source¥source¥incidDiag Cdump c:¥oracle¥diag¥rdbms¥source¥source¥cdump

Diag Trace c:¥oracle¥diag¥rdbms¥source¥source¥traceDiag Alert c:¥oracle¥diag¥rdbms¥source¥source¥alertDiag Incident c:¥oracle¥diag¥rdbms¥source¥source¥incidDiag Cdump c:¥oracle¥diag¥rdbms¥source¥source¥cdumpHealth Monitor c:¥oracle¥diag¥rdbms¥source¥source¥hmDefault Trace File c:¥oracle¥diag¥rdbms¥source¥source¥traceActive Problem Count 1Active Incident Count 7

Health Monitor c:¥oracle¥diag¥rdbms¥source¥source¥hmDefault Trace File c:¥oracle¥diag¥rdbms¥source¥source¥traceActive Problem Count 1Active Incident Count 7Active Incident Count 7Active Incident Count 7


Automatic Diagnostic Repository •adrci

ADRCI: Release 11.1.0.7.0 - Production on Mon Apr 27 16:58:37 2009ADRCI: Release 11.1.0.7.0 - Production on Mon Apr 27 16:58:37 2009p

Copyright (c) 1982, 2007, Oracle. All rights reserved.

ADR base = "c:¥oracle"

p

Copyright (c) 1982, 2007, Oracle. All rights reserved.

ADR base = "c:¥oracle"

• 手順1: ADRCIホームをチェック、設定する

ADR base = c:¥oracleadrci> helpADR base = c:¥oracleadrci> help

• adrci> show homes• adrci> set homepath ¥diag¥rdbms¥source¥source

• 手順2: エディタを定義する:• adrci> set editor uedit32

• 手順3: alert.log、problem、およびincidentをチェックする• adrci> show alert -tail 50 -fadrci> show alert tail 50 f • adrci> show problem• adrci> show incident


Automatic Diagnostic Repository •adrci

• 有益なメモ:• 有益なメモ:• Note: 443529.1

11g How To Package And Send ORA-00600/ORA-07445 Di ti I f ti T S tDiagnostic Information To Support.

• Note: 564269.1Retention Policy for ADR Incidents y• SHORTP_POLICY:

短期間保存する情報をパージするためデフォルト: 720 => 30 日

• LONGP_POLICY:To長期間保存されるADRのコンテンツをパージするためデフォルト: 8760 => 365 日


Automatic Diagnostic Repository • サポート・ワークベンチ


Automatic Diagnostic Repository • サポート・ワークベンチ – 問題が発生した場合


Automatic Diagnostic Repository • サポート・ワークベンチ – 問題のパッケージ


Automatic Diagnostic Repository • サポート・ワークベンチ – Metalink 資格証明


Automatic Diagnostic Repository • サポート・ワークベンチ – パッケージされた問題


Automatic Diagnostic Repository • サポート・ワークベンチ – コンテンツの参照


Automatic Diagnostic Repository • サポート・ワークベンチ – Oracle Support へのアップロード


アジェンダ

準備

インストール





LOB とSecureFiles



ADR圧縮



圧縮

• 8i以降、索引の圧縮が可能に

• 9 2以降では表の圧縮が可能• 9.2以降では、表の圧縮が可能• DWH用

• ダイレクト・パスとバルクINSERT、CREATE TABLE .. AS 、SELECT が対象

• 圧縮されないケース: INSERT/UPDATE/DELETE

前構文• 11g以前の構文:CREATE TABLE sales_history… COMPRESSCREATE TABLE sales_history… COMPRESS

• 11gの新しい構文:l hil hiCCREATE TABLE sales_history…

COMPRESS FOR DIRECT_LOAD OPERATIONS


Advanced Compression

• Oracle 11g のAdvanced Compression 機能の対象:• 構造化および非構造化データ構造化および非構造化デタ• バックアップ• データ・ポンプ・エクスポート• Data Guard のギャップ解決 (11 1 0 7 => LGWR ASYNC)• Data Guard のギャップ解決 (11.1.0.7 => LGWR ASYNC)

• リソース要件とコストを軽減！• ストレージ

• 通常、2～4分の1程度まで圧縮可能PCTFREEに PCTFREEに

非圧縮DML

PCTFREEに到達:圧縮！

さらなる非圧縮DML

PCTFREEに到達:圧縮！

オーバーヘッド

空き領域空き領域

非圧縮

圧縮


‘実システム’ での圧縮性能サイズ大き件デタベ表トした結果サイズの大きい10件のERPデータベース表でテストした結果

2000

2500使用領域

1000

1500 表のスキャン0.4

0

500

4分の10.2

0.3 DMLパフォーマンス

30

40

分

0

0.1

2 5倍のスピド 10

20

30

2.5倍のスピード0

10

オーバーヘッドは3%未満

89

オッドは3%未満


Compression アドバイザ – フリーダウンロード

• http://www.oracle.com/technology/products/database/compression/index.html


アジェンダ

準備

インストール


変更点とタクリトオブジェクト統計情報パフォーマンス監視

SQLチニング診断とチューニング


SQLチューニング診断とチュニング

パフォーマンス・テスト



チューニングは適なツールで...


アジェンダ

準備

インストール









オプティマイザ統計情報の収集

• すべての表に対してDML監視がオンになる

•INSERTS UPDATES およびDELETESが監視される•INSERTS、UPDATES、およびDELETESが監視される

• 特定の表の統計情報をロックして、収集対象から除外するにはするには

executeDBMS STATS.LOCK TABLE STATS('SH','TAB1');

executeDBMS STATS.LOCK TABLE STATS('SH','TAB1');

• 今後、統計情報の収集には必ずDBMS STATSを使用

_ _ __ _ _

_する（ANALYZEは使用しない）



• デフォルト・メンテナンス・ジョブ



• メンテナンス・スケジュールの調整



• 設定やパラメータの調整


11gでのGATHER_STATS_JOB• 手動でジョブを開始する方法:

• 開始:開始:execDBMS_AUTO_TASK_IMMEDIATE.GATHER_OPTIMIZER_STATS execDBMS_AUTO_TASK_IMMEDIATE.GATHER_OPTIMIZER_STATS

• 進捗状況の監視:

SELECT job_name,stateFROM dba_scheduler_jobsWHERE program_name='GATHER_STATS_PROG';

SELECT job_name,stateFROM dba_scheduler_jobsWHERE program_name='GATHER_STATS_PROG';

• 詳細はNote:731935.1 参照(Thi t j t b d l d d d t id d i t i ibl i M t li k)

_ _ __ _ _

(This note can just be downloaded under support guidance and is not visible in Metalink)


GATHER_STATS_JOB

表監視オン SMON 手動の場合SQL> exec DBMS STATS.

15分ごと

DBA/USER TAB MODIFICATIONS に含まれるDML数:

_FLUSH_DATABASE_MONITORING_INFO();

DBA/USER_TAB_MODIFICATIONS に含まれるDML数:

統計情報のない表

EMPTY表の変更が10%超

STALE

自動ジョブ – 1日に1回

EMPTY STALE

手動の場合SQL DBMS STATS GATHER SCHEMA STATS('SCOTT')

99

SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS('SCOTT');


GATHER_STATS_JOBオブジェクト: 分析の順序:

高

27%27%

54%54% 優優先

度

54%54%27%27%

統計情報: EMPTY

27%27%

統計情報: STALE

統計情報: OK 低


統計情報がないときのオプティマイザの動作

• オブジェクトの統計情報がない場合はどうなる？オプティマイザ（CBO）が表と索引の統計情報を（解析時に）オプティマイザ（CBO）が表と索引の統計情報を（解析時に）見積もる

必要な設定O C S G 2OPTIMIZER_DYNAMIC_SAMPLING=2 [10g以降ではデフォルト]

• レベル0 - 動的サンプリングがオフになる（～OLTP）• レベル2 - オブジェクトの初の64ブロックがチェックされるルオジクトの初のックがチックされる

• すべてのレベルの詳細:Performance Tuning Guide

• 例:http://www.oracle.com/technology/oramag/oracle/09-jan/o19asktom.html


Adaptive Cursor Sharing• Adaptive cursor sharing は11gから導入

• 一般的な問題:• 般的な問題:• バインド変数を使用する時、初の実行計画は以下の事実のため

適になる将来の実行における将来の値で初の実行計画を共有• 将来の実行における将来の値で初の実行計画を共有

• 初に使用されたバインド・セットは、大半の実行における典型となる可能性がある

例と詳細説明を参照 N 836256 1• 例と詳細説明を参照 Note:836256.1


拡張されたオプティマイザ統計

• ビジネス上の問題 - 相互に関連する列• 実データでは頻繁に様々な属性間に相互関係が表れる• 実データでは頻繁に、様々な属性間に相互関係が表れる

• 例えば、ジョブ・タイトルは給料に影響し、車のモデルはメーカーを決定し、季節は売れるグッズの量に影響を及ぼす（例えば、冬にスノー・シューズ）（例えば、冬にスノシュズ）

• オプティマイザは正確なカーディナリティを見積もらなければならない

“追加のフィルタが結果セットを減らすか否か？”• 追加のフィルタが結果セットを減らすか否か？

• 解決策• 拡張されたオプティマイザ統計は列グループ上に統計を収集するため拡張されたオプティマイザ統計は列グルプ上に統計を収集するため

のメカニズムを提供する

• 既存の統計フレームワーク内に完全統合

• 自動的に列統計は保持される

改善されたカーディナリティは改善された実行計画をもたらす

• 自動的に列統計は保持される

• 統合されたアプリケーションへの瞬時で透過的な利点


例単一の列単の列

SELECT ……FROM..

BLACK530xiBMW

RED530xiBMW

ColorModelMakeWHERE model = '530xi'

BLACK530xiBMW

RED530xiBMW

RED911PORSCHE

SILVER530xiBMW

BLACK530xiBMWSILVER530xiBMW

SLIVERC320MERC

BLACKSLKMERC• 3行選択される• 単一列の統計は正確

---------------------------------------------------------------------

| Id | Operation | Name | Starts | E Rows | A Rows || Id | Operation | Name | Starts | E-Rows | A-Rows |

---------------------------------------------------------------------

|* 1 | TABLE ACCESS FULL| CARS | 1 | 3 | 3 |

104

---------------------------------------------------------------------


例相互関連のない列相互関連のない列

ColorModelMakeSELECT ……FROM..

BLACK530xiBMW

RED530xiBMW

ColorModelMakeWHERE model = '530xi'AND color = 'RED'

RED530xiBMW

BLACKSLKMERC

RED911PORSCHE

SILVER530xiBMW

• 1行選択される列に相互関連はない

RED530xiBMW

SLIVERC320MERC

BLACKSLKMERC• 列に相互関連はない

• 追加の述語は結果セットを減らす

• 単一の列統計は十分単の列統計は十分

---------------------------------------------------------------------

| Id | Operation | Name | Starts | E-Rows | A-Rows |

---------------------------------------------------------------------

|* 1 | INDEX RANGE SCAN| C_MC | 1 | 1 | 1 |

105

---------------------------------------------------------------------


例相互関連のある列 – 拡張された統計なし

RED530 iBMW

ColorModelMakeSELECT ……FROM..WHERE model = '530xi'

相互関連のある列 – 拡張された統計なし

SILVER530xiBMW

BLACK530xiBMW

RED530xiBMWWHERE model 530xiAND make = 'BMW';

RED530xiBMW

SLIVERC320MERC

BLACKSLKMERC

RED911PORSCHE

3行選択される

SILVER530xiBMW

BLACK530xiBMW

SLIVERC320MERC• 3行選択される• 相互関連のある列

• 追加の述語は効果なし• 追加の述語は効果なし

• 単一の列統計は十分でない

---------------------------------------------------------------------

| Id | Operation | Name | Starts | E-Rows | A-Rows |

---------------------------------------------------------------------

|* 1 | INDEX RANGE SCAN| C MC | 1 | 1 | 3 |

106

| | | _ | | | |

---------------------------------------------------------------------


例相互関連のある列 – 拡張された統計

ColorModelMakeSELECT ……FROM..WHERE model = '530xi'

相互関連のある列 – 拡張された統計

SILVER530xiBMW

BLACK530xiBMW

RED530xiBMWWHERE model 530xiAND make = 'BMW';

RED530xiBMW

BLACKSLKMERC

RED911PORSCHE

SILVER530xiBMW

SILVER530xiBMW

BLACK530xiBMW

SLIVERC320MERC• 3行選択される• 複数列統計は問題を解決する

---------------------------------------------------------------------

| Id | O ti | N | St t | E R | A R || Id | Operation | Name | Starts | E-Rows | A-Rows |

---------------------------------------------------------------------

|* 1 | TABLE ACCESS FULL| CARS | 1 | 3 | 3 |

107

---------------------------------------------------------------------


アジェンダ

準備

インストール









診断とチューニングの要件

• STATISTICS_LEVEL=TYPICAL [デフォルト]• その他の設定値:その他の設定値

• BASIC• ALLTYPICAL（推奨の設定）で有効になる機能• TYPICAL（推奨の設定）で有効になる機能:• SGA自動チューニング

• 統計情報の自動収集

• アクティブ・セッション履歴（ASH）の記録

• DMLの監視


10g以降の診断とチューニングのコンセプト

SGA

MMONメモリー内の統計情報 AWR

スナップショット

ADDMアラート

ADDM結果プロアクティブに

動作DBA

結果に応じて作業

DBA


10g以降のチューニング基本事項

• AWR （Automatic Workload Repository）• SYSAUX表領域内のパフォーマンス統計情報リポジトリ

プがれ在去各期• AWRスナップショットが置かれる（現在と過去の各期間について）

• 自己管理型

• AWRに格納されるデータはMMONによって収集されるAWRに格納されるデタはMMONによって収集される• 60分おきに動作し、7日間（11gでは8日間）保持される [デフォルト]

• AWRコンテンツの問合せ: DBA_HISTビュー

• 特定のスナップショットを以降の分析時の自動削除対象から除外• 特定のスナップショットを、以降の分析時の自動削除対象から除外するには、それらをベースラインとして定義する

• スナップショットが毎回オンデマンドで作成されるようにするには:EXEC db kl d it t h t()• EXEC dbms_workload_repository.create_snapshot();

• AWRのサイズと解析：• @?/rdbms/admin/awrinfo.sql

ポ• レポート:• SI: SQL>@?/rdbms/admin/awrrpt.sql • RAC: SQL>@?/rdbms/admin/awrrpti.sql

単文

111

• 単一の文: @?/rdbms/admin/awrsqrpt.sql



• AWR• 推奨: 保持期間の変更:推奨保持期間の変更



• AWR• 一般的な商用データベースの値般的な商用デタスの値

• 取得間隔: 30-60分 ... 保持期間: 20-31日


10gR2以降のチューニング基本事項

• AWRのトランスポート• 抽出抽出

DBMS_SWRF_INTERNAL.AWR_EXTRACT(dmpfile => 'awr_data.dmp', dmpdir => 'TMP_DIR',bid => 302, eid => 305);

• 一時スキーマ内にロードDBMS_SWRF_INTERNAL.AWR_LOAD( SCHNAME => 'AWRTEMP', dmpfile => 'awr data' dmpdir => 'TMP DIR' );dmpfile => 'awr_data', dmpdir => 'TMP_DIR' );

• 一時データをAWR用の場所に移動（SYS）DBMS_SWRF_INTERNAL.MOVE_TO_AWR(SCHNAME => 'AWRTEMP USER');SCHNAME => AWRTEMP_USER );

• どのようなケースで必要となるか？

• 本番システムの外部で評価をおこなう

セントラルリポジトリへロドする• セントラル・リポジトリへロードする



• ASH（Active Session History: アクティブ・セッション履歴）• ASHはデータベース診断のキー要素ASHはデタベス診断のキ要素

• SGA内の循環バッファ

• 固定サイズ: 2MB x CPU数 ( 大SGAの5%、または30MB)

• アクティブ・セッションに関する情報を保持する

• MMNLにより、10%までの情報がAWRに書き込まれる

ビ V$ACTIVE SESSION HISTORY• ビュー: V$ACTIVE_SESSION_HISTORY• 詳細: Note:243132.1• レポート:ポ

• シングル・インスタンス: SQL> @?/rdbms/admin/ashrpt.sql• RAC: SQL> @?/rdbms/admin/ashrpti.sql



• ASHのレポート間隔を定義する



•


チューニングの基本事項 - STATSPACK• STATSPACKは、10g、11gでも依然として利用可能

• AWR/ASH（Diagnostic Pack のライセンスが必要）と/ S （ ag ost c ac のライセンスが必要）とSTATSPACK のいずれかを選択して使用する

• 参照: Note394937.1（STATSPACK Guide）



• ADDM（Automatic Database Diagnostic Monitor）• パフォーマンス診断のナレッジ・ベースパフォマンス診断のナレッジベス

• パフォーマンス・スナップショットを分析し、アドバイス情報を提供

• （AWRスナップショットに対して）1時間ごとに自動的に実行するか、びが手動で呼び出すことが可能:

• SI: SQL> @$ORACLE_HOME/rdbms/admin/addmrpt.sql• RAC: SQL> @$ORACLE_HOME/rdbms/admin/addmrpti.sql



• ADDM の調査結果 – 例:


メモリーのチューニング - SGA & PGA

プストリムプル

バッチバッファ・キャッシュ

OLTP

バキシ

ストリーム・プールストリーム・プール

SGAラージ・プール

ラージ・プール

バッファ・キャッシュ

Javaプル

SQLキャッシュSQLキャッシュ

ラジプル

Javaプル

PGAソート

Javaプール

ソート

Javaプール

PGAソトソト


自動共有メモリー管理（ASMM）

• ASMMを有効にするには、SGA_TARGET（またはMEMORY_TARGET）とSTATISTICS LEVEL=TYPICALを設定する必要がある_

自動チューニング

データベースバッファ・キャッシュ Redoログ

バッファストリームプール

共有プール

ラージ・プール固定SGA

プル

Javaプール

ラジプル固定

SGA_MAX_SIZE=...

SGA全体


自動共有メモリー管理（ASMM）

• 統計情報の収集は、MMANによってバックグラウンドで起動される起動される

MMAN

バックグラウンド全コンポーネントを監視し各SGAコンポーネント SGA メモリーブローカ

全コンポネントを監視し、サイズ変更操作を調整

各SGAコンポネントのサイズを調整


DB Management Packの強化点（11g）• Diagnostic Pack

• RAC対応のADDM• RAC対応のADDM• AWRのベースラインと適応型しきい値

• AWRのトランスポート

• Tuning Packg• 自動SQLチューニング・アドバイザ

• パーティション・アドバイザ

タイム監視• リアルタイムのSQL監視

• SQL 計画管理と計画の進化


アジェンダ

準備

インストール









DB Management Packの強化点

• Diagnostic Pack• RAC対応のADDM• RAC対応のADDM• AWRのベースラインと適応型しきい値

• AWRのトランスポート

• Tuning Packg• リアルタイムのSQL監視

• 自動のSQLチューニング・アドバイザ

パシドバイザ• パーティション・アドバイザ


リアルタイムのSQL監視

• 特定のSQL文の実行負荷が高まった場合、その文専用の統計情報が収集される情報が収集される• ターゲット:

• パラレル問合せ、パラレルDML、およびパラレルDDL• CPU時間、またはI/O時間が5秒を超えたシリアル実行

• グローバルなSQLレベルの統計情報を収集: V$SQL_MONITOR• プラン・レベルの統計情報を収集（行数メモリー一時領域開始/終了• プラン・レベルの統計情報を収集（行数、メモリー、一時領域、開始/終了日付）: V$SQL_PLAN_MONITOR

• 問合せの実行中、統計情報はほぼリアルタイムに更新される

• 問合せの完了後、統計情報は低5分間保持される

• デフォルトでオン


SQL リアルタイム監視レポート

•DBMS_SQLTUNE.REPORT_SQL_MONITOR()で、

監視情報を表示監視情報を表示• フォーマット: xml、text、html• ASHデータと結合ASHデタと結合

• リアルタイムSQL監視は、11.1.0.7よりGUIに統合


SQL リアルタイム監視 – 例 1


SQL リアルタイム監視 – 例 2


手動でのSQLチューニング

• 複雑 - 複数の分野に精通していなければならない• SQLの適化: 実行計画の調整SQLの適化: 実行計画の調整

• アクセス設計: 高速データ・アクセスの提供

• SQL設計: 適切なSQL構造の使用

• 時間がかかる• 各SQL文は一意である各SQL文は意である

• 潜在的にチューニングする文の数が多い

• 決して終わらないタスク• SQLワークロードは常に進化する

• 実行計画の劣化が発生する可能性がある• 実行計画の劣化が発生する可能性がある


11gの自動SQLチューニング

• SQLのチューニング・タスクが完全自動化• 自動的に実行

• メンテナンス・ウィンドウ、CPUリソース制御、オン/オフ切替え

• 候補のSQLを特定し、ランク付けしてチューニング

• SQL Tuning Advisorの活用SQL Tuning Advisorの活用

• チューニング候補のSQLが自動的に選出• 除外対象: パラレル問合せ DML/DDL 再帰文アドホック（低頻度）• 除外対象: パラレル問合せ、DML/DDL、再帰文、アドホック（低頻度）

• SQLプロファイルをテストのうえ、（オプションで）実装改善度高プ（）だけを実装• 改善度の高いプラン（3x）だけを実装

• 効果の低いプランを避けるために十分な時間を使用

• DBAは10gのように、アドバイザを手動で呼び出して、事後対応的なチューニングをおこなうことも可能



• 自動SQLチューニングの構成画面



SQLプフイルをSQLプロファイル

SQLの処理

SQLプロファイルをテスト

SQLプロファイルを実装

SQLの処理アドバイス情報を

生成

候補のSQLを

自動処理！

候補のSQLを選出

1週間

SQLチューニングの対象

AWRDBA

レポートの参照/ プロセスの制御


結果のサマリー


SQLチューニング – 処理のステップ

1. 監視

2 チニングが必要な文を特定2. チューニングが必要な文を特定

3. 2つのチューニング・アドバイザを使用• SQL Access Advisor:SQL Access Advisor:

• 索引

• マテリアライズド・ビュー

• マテリアライズド・ビュ上の索引• マテリアライズド・ビュー上の索引

• ワークロードが必要

• SQL Tuning Advisorオプザをグド起動• オプティマイザをチューニング・モードで起動

• 各文のプロファイルを作成

• 1つのSQL文に対して実行可能

4. アドバイス内容を実装


SQL Tuning Advisor• EM内、またはCLI上で使用できる（DBMS_SQLTUNE経由）

• 2つのチューニング・モードがある2つのチュニングモドがある• “包括モード” - すべての分析オプションを使用できる

• “限定モード” - SQLプロファイルを生成しない

SQLプフイルではアプリケシンドを変更せず• SQLプロファイルでは、アプリケーション・コードを変更せずに実行計画を改善するための情報が提供される• 異なるオプティマイザ設定の使用案異なるオプティイザ設定の使用案

• 間違った/失効した統計情報の修正案

• 間違った見積り情報の修正案

• SQLプロファイルは存在し続けるSQLプロファイルは存在し続ける

• SQLプロファイルは元のSQL文を変更するものではない

• SQLはSQL Tuning Sets（STS）内にトランスポートできる

• SQLプロファイルはリスクを伴わずにテスト/検証できる• SQLプロファイルはリスクを伴わずにテスト/検証できる


SQLチューニング – ソース

自動選択

AWRADDM 高負荷のSQL

SQLソース手動選択

AWR

SQL Tuning Advisor

カーソル・キャッシュ SQL Tuning SetSQL Tuning Set（STS）

ユーザー定義

フィルタ/ ランク付け

139

定義


SQLチューニング

• 例: Tuning Advisorの結果 SQLプロファイル


SQLチューニング

• 例: 元のEXPLAIN PLANと新実行計画の比較


SQLチューニング - DBMS_SQLTUNE

• SQLプロファイルを取得するための4つのステップ• DBMS SQLTUNE CREATE TUNING TASKDBMS_SQLTUNE.CREATE_TUNING_TASK• DBMS_SQLTUNE.EXECUTE_TUNING_TASK• DBMS_SQLTUNE.REPORT_TUNING_TASK• DBMS_SQLTUNE.ACCEPT_SQL_PROFILE


SQLチューニング - DBMS_SQLTUNE

o CANCEL_TUNING_TASK o CREATE TUNING TASKo CANCEL_TUNING_TASK o CREATE TUNING TASK

o ACCEPT_SQL_PROFILEALTER SQL PROFILE

o ACCEPT_SQL_PROFILEALTER SQL PROFILE

チューニング・タスクの管理 SQLプロファイルの管理

o CREATE_TUNING_TASKo DROP_TUNING_TASK o EXECUTE_TUNING_TASK o IMPLEMENT_TUNING_TASK o INTERRUPT TUNING TASK

o CREATE_TUNING_TASKo DROP_TUNING_TASK o EXECUTE_TUNING_TASK o IMPLEMENT_TUNING_TASK o INTERRUPT TUNING TASK

o ALTER_SQL_PROFILEo DROP_SQL_PROFILEo ALTER_SQL_PROFILEo DROP_SQL_PROFILE

SQL文の選択o INTERRUPT_TUNING_TASK o REPORT_AUTO_TUNING_TASK o REPORT_TUNING_TASK o RESUME_TUNING_TASK o SCRIPT TUNING TASK

o INTERRUPT_TUNING_TASK o REPORT_AUTO_TUNING_TASK o REPORT_TUNING_TASK o RESUME_TUNING_TASK o SCRIPT TUNING TASK

o CAPTURE_CURSOR_CACHE_SQLSETo SELECT_CURSOR_CACHE o REPORT_SQL_MONITOR o SELECT WORKLOAD REPOSITORY

o CAPTURE_CURSOR_CACHE_SQLSETo SELECT_CURSOR_CACHE o REPORT_SQL_MONITOR o SELECT WORKLOAD REPOSITORYo SCRIPT_TUNING_TASK

o RESET_TUNING_TASKo SET_TUNING_TASK_PARAMETER

o SCRIPT_TUNING_TASK o RESET_TUNING_TASKo SET_TUNING_TASK_PARAMETER

_ _o SQLTEXT_TO_SIGNATURE

_ _o SQLTEXT_TO_SIGNATURE

SQLチューニング・セットの管理ステージング表の管理o ADD_SQLSET_REFERENCE o CREATE_SQLSET o DELETE_SQLSET o DROP SQLSET

o ADD_SQLSET_REFERENCE o CREATE_SQLSET o DELETE_SQLSET o DROP SQLSET

o CREATE_STGTAB_SQLPROF o CREATE_STGTAB_SQLSET o PACK_STGTAB_SQLPROF o PACK STGTAB SQLSET

o CREATE_STGTAB_SQLPROF o CREATE_STGTAB_SQLSET o PACK_STGTAB_SQLPROF o PACK STGTAB SQLSET

表

o DROP_SQLSET o LOAD_SQLSET o REMOVE_SQLSET_REFERENCE o SELECT_SQLSET o UPDATE SQLSET

o DROP_SQLSET o LOAD_SQLSET o REMOVE_SQLSET_REFERENCE o SELECT_SQLSET o UPDATE SQLSET

o PACK_STGTAB_SQLSET o REMAP_STGTAB_SQLPROF o REMAP_STGTAB_SQLSET o UNPACK_STGTAB_SQLPROF o UNPACK STGTAB SQLSET

o PACK_STGTAB_SQLSET o REMAP_STGTAB_SQLPROF o REMAP_STGTAB_SQLSET o UNPACK_STGTAB_SQLPROF o UNPACK STGTAB SQLSET

143

o UPDATE_SQLSETo UPDATE_SQLSETo UNPACK_STGTAB_SQLSET o UNPACK_STGTAB_SQLSET


リテラル（非バインド）を含むSQLプロファイル

• SQLプロファイルでは、（バインドではなく）リテラルを含む文を扱うことも可能:ことも可能:

• 11.1.0.6以降では、EM内でも可能:

• 10.2ではコマンドラインのみで可能:exec :p name:=dbms sqltune accept sql profileexec :p name:=dbms sqltune accept sql profile

SQL> select name, status, force_matching, sql_textfrom dba sql profiles;

:p_name:=dbms_sqltune.accept_sql_profile(task_name=>'XT',name=>'XT_PROFILE', FORCE_MATCH=>TRUE);:p_name:=dbms_sqltune.accept_sql_profile(task_name=>'XT',name=>'XT_PROFILE', FORCE_MATCH=>TRUE);

from dba_sql_profiles;

NAME STATUS FOR SQL_TEXT------- -------- ---- --------------------------------------------MY PROF ENABLED YES select /*+ use nl(c) ordered */ count(*)MY_PROF ENABLED YES select /*+ use_nl(c) ordered */ count(*)

from sh.sales s, sh.customers cwhere c.cust_id = s.cust_id

and CUST_FIRST_NAME = 'Mike'


SQLプロファイル – 評価

• SQLプロファイルを全ユーザーに提供する前に、その内容の評価をおこなう必要がある:をおこなう必要がある:exec:p_name:=dbms_sqltune.accept_sql_profiletask name=>'XT' name=>'XT PROFILE'task_name=>'XT',name=>'XT_PROFILE',category=>'TEST_ENV', FORCE_MATCH=>TRUE)

alter session set SQLTUNE CATEGORY='TEST ENV';

• 一部のユーザーだけが利用できる段階で、プロファイルを評価

• 満足な評価結果が出たら、全ユーザーに対して公開

alter session set SQLTUNE_CATEGORY= TEST_ENV ;

満足な評価結果が出たら、全ザに対して公開

execdbms_sqltune.alter_sql_profile(name=>'XT PROFILE'(name=> XT_PROFILE ,attribute_name=>'CATEGORY',value=>'DEFAULT')


SQLプロファイルの効果

• 当社顧客（EMEA地域の大規模な市場調査会社）での処理負荷テスト – チューニングが必要な高負荷問合せを73件検出負荷テストチュニングが必要な高負荷問合せを73件検出

• プロファイル導入前と導入後における問合せ実行時間の比較

Time (s) Time (s)

Before … … After

100

1000

10000

10 0

10 0 0

10 0 0 0

1

10

100

1

10

10 0

11 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69

Queries

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69

Queries


SQLプロファイル – 結果

• 当社顧客（EMEA地域の大規模な市場調査会社）での処理負荷テストチューニングが必要な高負荷問合せを73件検出負荷テスト – チュニングが必要な高負荷問合せを73件検出• 73件の複雑なDWH文に対する手動チューニングと自動チューニングの結果比較

平均長累積平均応答時間

長応答時間

累積応答時間

チューニングなし 817秒 5751秒 58821秒手動チューニング 30秒 275秒 2131秒自動チューニング(SQLプロファイル)

13秒 59秒 929秒(SQLプロファイル)


SQLプロファイルの所要時間

• 73件すべての文の適化を、約1時間半で完了！

Time (s)10 0 0

10

10 0

1

10

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69

Queries


アジェンダ

準備

インストール


変更点とタクリト

診断とチューニング


問題点診断とチュニング


問題点SQL Plan Management

Database ReplaySQL Performance Analyzer


y


問題点

• アップグレード時の問題と呼ばれているものの90%以上は、実はアップグレードの問題ではなくアップグレード後の実はアップグレドの問題ではなく、アップグレド後のパフォーマンスに関する問題である• テスト・シナリオとテスト方法を万全なものにすることが重要

• 問題になりやすいエリア

• オプティマイザ - 実行計画

問合せが遅• 問合せが遅い

• レポートやバッチの完了に時間がかかる

• 更なるリソース要件• 更なるリソス要件

• コード・パスの変更


問題点

• オプティマイザ - 実行計画の変更を防ぐ• 従来のアプローチ:• 従来のアプロチ:

• ルール・ベースのオプティマイザ(RBOはOracle 10g以降ではサポート外 - Note:189702.1)

• ヒントを使用

• ストアド・アウトラインを使用

• SQL文のリライト

• optimizer features enable=n.n.nを設定optimizer_features_enable n.n.nを設定

• 特定のオプティマイザ・パラメータを変更

• オブジェクトやシステムの統計情報をインポートして修正

効率的でリソス消費性能にも優れた新しいツル• 効率的でリソース消費性能にも優れた新しいツール

• SQL Plan Management• SQLプロファイル


アジェンダ

準備

インストール










y


SQL Plan Management がない場合

• 実行計画と統計情報を “固定” することが困難

• 例:• 例:• 文が解析され、実行計画が作成される検証は実行中におこなわれる:

HJ

GB

解析実行実行計画が承認される

• 何らかの条件（統計情報アップグレードパラメータ）が変更された場合

HJ

何らかの条件（統計情報、アップグレド、パラメタ）が変更された場合

• 新しい実行計画が作成される - これは果たして効率的か？

GB

NL

NL

GB

解析実行実行計画が有効でなくなる可能性がある


SQL Plan Management

• 予防的で、かつ完全に透過的なデータベース・メカニズムにより実行計画の安定性を確保より、実行計画の安定性を確保

• SQL実行計画を記録

• SQLプラン・ベースラインを作成• SQLプランベスラインを作成• 承認済みの実行計画から構成される

• 2回以上解析/実行された文の実行計画だけが対象

• 検証、および承認された既知の実行計画だけが使用される

• パッケージ: DBMS SPM_


SQL Plan Management

• 実行計画の安定を実現する3つのフェーズ:• キャプチャ• キャプチャ

• 信頼性のある実行計画から、SQLベースラインを作成する

• ベースラインはSYSAUX 内のSQL Management Base に保存される

• 選択

実際に使用されるのはあくまで承認済みの実行計画だけ• 実際に使用されるのは、あくまで承認済みの実行計画だけ

• 新しい実行計画が追加されたら、まず計画履歴に記録される

• 展開展開

• 特定の文に対応する実行計画のうち、検証を通過していないすべての実行計画（プラン履歴内にあるもの）を対象に、承認/却下を再評価する承認/却下を再評価する


SQL Plan Management• ホワイト・ペーパー:

• http://www.oracle.com/technology/products/http://www.oracle.com/technology/products/manageability/database/pdf/ow07/spm_white_paper_ow07.pdf


SQL Plan Management

• フェーズ1 – キャプチャ• 図 - OPTIMIZER CAPTURE SQL PLAN BASELINES=TRUE• 図 - OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE

解析

GB

実行実行計画がされる

HJ

HJ 承認される

プラン履歴再発性のある文に対する

初の実行計画は無条件に承認され、

SQL MANAGEMENT BASESYSAUX 表領域内に置かれる。

SYSAUXの容量の大10%を占める。週1回のジョブで実行計画をチェックし

GB

SQLプラン・ベースライン

SQLプラン・ベースラインに追加される

週1回のジョブで実行計画をチェックし、53週間使用されていないものは

削除する [デフォルト]。

SQLプロファイル

HJ

HJSQLプロファイル


SQL Plan Management

• フェーズ2 – 選択• 同じ文の2度目の解析時に前回とは別の実行計画が作成された場合• 同じ文の2度目の解析時に、前回とは別の実行計画が作成された場合

• OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=FALSE

解析NL

GB

NL

NL

プラン履歴

後続の新実行計画は、プラン履歴に追加

される。これは、検証で承認されるまでは


GB

で承認されるまでは使用されない。 GB

NL

NL

HJ

HJ


SQL Plan Management

• フェーズ2 – 選択• 図: OPTIMIZER CAPTURE SQL PLAN BASELINES=FALSE• 図: OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=FALSE

解析

GB

実行既知の実行計画であ済

HJ

HJ あり、かつ承認済み

プラン履歴オプティマイザは、検証を通過して


GB

GB

NL

NL

SQLプラン・ベースラインに格納された実行計画のうち

1つだけを使用する（それにより実行計画の

安定性を確保する）

HJ

HJ安定性を確保する）


SQL Plan Management

• フェーズ3 – 展開• 図:• 図:

プラン履歴プラン履歴現行の実行計画より



GBGB

GB

NL

NLGB

NL GB

現行の実行計画よりパフォーマンスが低い

実行計画はプラン履歴に残される

GB

NL

NL

NL

NL

HJ

HJ

GBNLNL

HJ

HJ

現行の実行計画と同等か、またはそれより高いパフォーマンスの実行計画はSQLプラン・

DBAオプティマイザ

実行計画はSQLプランベースラインに追加されるDBAが検証を

スケジューリング


SQL Plan Management


SQL Plan Management

• DatabaseControl – 構成:

初は5～14週間に設定しておくのが適当:exec DBMS_SPM.CONFIGURE('plan_retention_weeks',5);


SQL Plan Management – シナリオ

• アップグレード・シナリオ1:• オプティマイザのパラメータを “従来型” の動作に戻す• オプティマイザのパラメタを従来型の動作に戻す

• リリース8.0.3以降のすべてのデータベースで可能

• アップグレード・シナリオ2:アップグレドシナリオ2:• よく使用される実行計画を新しいリリースにトランスポートする

• 10gR2以降で可能

• 新しいアプリケーション（モジュール）を、適切なSQLプラン・ベースラインとセットにして提供する:

新良ジグ意• 新しい文に対する良の実行計画をステージング表内に用意することで、それらが確実に使用されるようにする

• 11g以降で可能11g以降で可能


SQL Plan Management -アップグレード1• アップグレード・シナリオ1

STS

再発性のある実行計画は、2回目の実行時にSQLプラン・ベースラインに追加される

その後、OFE=11の設定で作成された別の

プラン履歴


GB

NL

NL

実行計画がプラン履歴に追加される（後で検証される）

プラン履歴

GB

NL

NL

GB

HJ

HJ

GB

NL

NL


SQL Plan Management – アップグレード2• アップグレード・シナリオ2

ステージング

STSexp imp

STS表 expdp impdp

DB-Link ...

SQLプラン・ベースラインに

プラン履歴

10.2の実行計画が追加される

GB


GB

NL

GB

HJ

GB

NL

GB

NL

NL

NL

HJ

HJNL

新しい実行計画や、よりパフォーマンスの高い実行計画はプラン履歴に格納される

165

実行計画はプラン履歴に格納される


SQL Plan Management - 新アプリケーション

• 新しいアプリケーション（モジュール）を提供する

@ベンダー @顧客@ベンダ

DBMS_SPM.CREATE_STGTAB_BASELINE

ステージング

@顧客

ステージング

exp impexpdp impdp

表表

DBMS SPM.PACK STGTAB BASELINE

DBMS_SPM.UNPACK_STGTAB_BASELINE

プラン・ベースライン

GB

S_S . C _S G _ S

プラン・ベースライン

GB

NL

NL

GB

HJ

HJ

GB

NL

NL

GB

NL

NL

GB

HJ

HJ

GB

NL

NL


SQL Plan Management - 新アプリケーション

• 新しいアプリケーション（モジュール）の提供時に、適切な実行計画も一緒に提供できる:

• ソフトウェア・ベンダーは• ステージング表を作成する• ステージング表を作成する

DBMS_SPM.CREATE_STGTAB_BASELINE• 必要なSQLプラン・ベースラインをステージング表内にパッケージする

DBMS SPM.PACK STGTAB BASELINES_S . C _S G _ S• データ・ポンプかエクスポートを使用して、ダンプ・ファイル内に

ステージング表をエクスポートし、それをターゲット・システムにトランスポート

• 顧客は

• ダンプ・ファイルをターゲット・データベース内にインポートする• ダンプ・ファイルをターゲット・データベース内にインポートする

• ステージング表にパッケージされたSQLプラン・ベースラインを、ターゲット・システムのSQL Management Base内に取り込む

S S C S G S

167

• DBMS_SPM.UNPACK_STGTAB_BASELINE


SQL Plan Management – アウトライン• Oracle 11gR2 では、シンプルなストアド・アウトラインの移行がサポートされる• DBMS SPM MIGRATE STORED OUTLINE• DBMS_SPM.MIGRATE_STORED_OUTLINE• http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/optplanmgmt.htm#PFGRF3616

• Oracle 11gR1:ストアド・アウトラインからSQL PlanManagement への手動移行:Management への手動移行:

• Tuning Pack:10.2の実行計画を記録し、それらをトランスポート（アップグレドシナリオ2を参照）（アップグレード・シナリオ2を参照）

• Tuning Pack ライセンスがない場合:• アウトラインを使用したデータベースを11gにアップグレードする

• OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUEを設定

• アウトラインの問合せを2回実行する

• 実行計画がSQLプラン・ベースラインに記録される• 実行計画がSQLプランベスラインに記録される

• OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=FALSEに切り替える

ストアドアウトラインを削除する

168

• ストアド・アウトラインを削除する


アジェンダ

準備

インストール










y


Real Application Testing

• 目的:• 実環境の処理負荷を記録/再現して新システムのパフォーマンスを• 実環境の処理負荷を記録/再現して、新システムのパフォマンスをチェックする

• パフォーマンスの低下を確認し、アップグレードの前に実行計画を変更する変更する

• “Real Application Testing” のライセンス提供• Real Application Testing のライセンス提供Oracle Database 11.1.0.6 以降で提供

PSR 10.2.0.4 で提供

9.2.0.8 および10.2.0.2/3 用の個別パッチとして提供

必要な個別パッチの確認: Note:560977.1


Real Application Testing• Real Application Testing を構成するコンポーネント:

• Database Replay • パッケージ DBMS_WORKLOAD_CAPTURE

9.2.0.8、10.2.0.2/3/4、11.1.0.x および11.2.0.x でキャプチャ可能

• パッケージ DBMS_WORKLOAD_REPLAY11.1.0.x および11.2.0.x でリプレイ可能11.1.0.x および11.2.0.x でリプレイ可能

• SQL Performance Analyzer (SPA)パケジ• パッケージ DBMS_SQLPA

SQL文収集:9.2.0.x SQLトレースより取得

10.2.0.2/3/4、11.1.0.x および11.2.0.x カーソル・キャッシュより取得

評価と比較:10.2.0.2/3/4、11.1.0.x および11.2.0.x

• SQL Tuning Sets (STS)• SQL Tuning Sets (STS)• パッケージ DBMS_SQLTUNE



• ホワイト・ペーパー:• Database Replay:• Database Replay:

• http://www.oracle.com/technology/products/manageability/database/pdf/ow07/db_replay_white_paper_ow07_1.pdf

• SQL Performance Analyzer:• http://www.oracle.com/technology/products/manageability/database/pdf/o

w07/spa_white_paper_ow07.pdf

• OTN:• http://www.oracle.com/technology/products/manageability/database/index.html

• Command line examples for REPLAY and SPA:p• http://www.oracle.com/technology/products/manageability/database/tools/db_replay_cli.zip• http://www.oracle.com/technology/products/manageability/database/tools/spa_scripts.zip



• Database Control:


アジェンダ

準備

インストール










y


Database Replay• 本番データベースの処理負荷をテスト環境内で再現

• 本番環境に変更を加える前に、システムが不安定になる可能性を確認、分析、および修正

• 本番環境の処理負荷をキャプチャ

境厳密プグ並• 本番環境の処理負荷を厳密にキャプチャし、処理の発生タイミングや同時並行性までも記録

• キャプチャした処理負荷データをテスト・システムに取り込む

処負荷を環境• 処理負荷をテスト環境で再現• 予定している変更をテスト・システムに対して実行

• 本番環境と同じ処理負荷をリプレイ

• コミット順序も再現

• 分析とレポート• エラーエラ

• データの変化

• パフォーマンスの変化


Database Replay

• ワークフロー:


制限事項

• キャプチャできない情報（現時点）:• ダイレクト・パス・ロード• ダイレクトパスロド

• MTSリクエスト（11.2では可能）

• Oracle Streams （11.2では可能）とOracle Advanced Replication• 非PL/SQLベースのAQ• フラッシュバック問合せ

非SQ ベオブジクトクセ• 非SQLベースのオブジェクト・アクセス

• 分散トランザクション

• リモートのDESCRIBEおよびCOMMITsリモトのDESCRIBEおよびCOMMITs


Database Replay•ステップ・バイ・ステップ


Database Replay

1.データベースのコピーを作成（負荷の再現先となる）• バックアップ• バックアップ

• RMAN Duplicate• Snapshot Standby

• 場合によって、保証付きリストア・ポイントを作成


Database Replay

2.負荷のキャプチャに関するいくつかのガイドライン• なるべく本番データベースを再起動する• なるべく、本番デタベスを再起動する

• 理由: すべてのトランザクションが正常に終了できるようにするため

• RAC: 1つのインスタンスだけを稼動させた状態でキャプチャを開始しその後で他のインタンを起動する開始し、その後で他のインスタンスを起動する

• 各ユーザーがデータベースにログオンする前にキャプチャを開始する

• そのため、データベースはRESTRICTED モードで起動するそのため、デタベスはRESTRICTED モドで起動する

• キャプチャが始まると、すぐにUNRESTRICTED に切り替わる


Database Replay

2.EMでのワークフロー: 負荷のキャプチャ


Database Replay

2.EMでの準備ステップ: 負荷のキャプチャ


Database Replay

3.フィルタの定義:• デフォルト :• デフォルト :

すべてのユーザー・セッションを記録する

• 包含フィルタ:指定したザセシだけを記録指定したユーザー・セッションだけを記録

• 除外フィルタ:指定した以外の全ユーザー・セッションを記録指定した以外の全ザセッションを記録

• “OMS” と “emagent%” だけを除外する場合など

• 両方のフィルタを組み合せることはできない

• パッケージ:DBMS_WORKLOAD_CAPTURE.ADD_FILTER(fname=>'myFilter',

fattribute=>'USER',DBMS_WORKLOAD_CAPTURE.ADD_FILTER(fname=>'myFilter',

fattribute=>'USER',fvalue=>'SCOTT');

DBMS_WORKLOAD_CAPTURE.DELETE_FILTER(fname=>'myFilter');

fvalue=>'SCOTT');

DBMS_WORKLOAD_CAPTURE.DELETE_FILTER(fname=>'myFilter');


Database Replay

3.EMでのフィルタの定義:


Database Replay

4. キャプチャ名の定義:


Database Replay

4. キャプチャ・スケジュールの実行:


Database Replay

4. コマンドライン・モードでのキャプチャの開始:BEGINBEGINBEGINDBMS_WORKLOAD_CAPTURE.START_CAPTURE

(name => 'hammerora_single_01',dir > 'TESTING'

BEGINDBMS_WORKLOAD_CAPTURE.START_CAPTURE

(name => 'hammerora_single_01',dir > 'TESTING'dir => 'TESTING',default_action => 'EXCLUDE');

END;/

dir => 'TESTING',default_action => 'EXCLUDE');

END;/

5. キャプチャの停止:

//

キャチャ停

BEGINDBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE();

BEGINDBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE();

END;/END;/


Database Replay

• Database Control - キャプチャの統計情報:


Database Replay

• コマンドライン・モードでのAWRのエクスポート:BEGINBEGINBEGINDBMS_WORKLOAD_CAPTURE.EXPORT_AWR

(capture_id => 5);END;

BEGINDBMS_WORKLOAD_CAPTURE.EXPORT_AWR

(capture_id => 5);END;END;/END;/


Database Replay

• キャプチャした負荷データに対する前処理:


Database Replay

• コマンドライン・モードでの前処理

BEGINBEGINBEGINDBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE(capture_dir => 'TESTING');END;

BEGINDBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE(capture_dir => 'TESTING');END;

バクアプからデタベスをリストア

END;/END;/

• バックアップからデータベースをリストア


Database Replay

• AWRスナップのインポート

DECLARE db_id number;BEGIN db_id := DBMS_WORKLOAD_CAPTURE.IMPORT_AWR

DECLARE db_id number;BEGIN db_id := DBMS_WORKLOAD_CAPTURE.IMPORT_AWR_ _ _ _(capture_id => 5, staging_schema => 'TPCC');END;/

_ _ _ _(capture_id => 5, staging_schema => 'TPCC');END;/


Database Replay

• 処理負荷の再現: リプレイ・パラメータ


Database Replay

• 再現先となるクライアント（wrc: workload replay client）の初期化とパラメータ設定:初期化とパラメタ設定:

BEGIN

DBMS WORKLOAD REPLAY INITIALIZE REPLAY

BEGIN

DBMS WORKLOAD REPLAY INITIALIZE REPLAYDBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY(replay_name => 'play_hammerora_01',replay_dir => 'TESTING');

DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY(replay_name => 'play_hammerora_01',replay_dir => 'TESTING');

DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY(synchronization => TRUE);DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY(synchronization => TRUE);

END;/END;/


Database Replay

• リプレイ・クライアント数の決定• $> wrc mode=calibrate replaydir=/tmp/testing$> wrc mode=calibrate replaydir=/tmp/testing

• リプレイ・クライアントの起動• $> wrc system/oracle mode=replay$ y / p y


Database Replay

• リプレイをコマンドライン・モードで開始:BEGINBEGINBEGINDBMS_WORKLOAD_REPLAY.START_REPLAY ();END;/

BEGINDBMS_WORKLOAD_REPLAY.START_REPLAY ();END;///


Database Replay

• 相違情報の監視:


Database Replay

• リプレイの結果:


Database Replay

• CLIでのリプレイ・レポート生成:DECLAREDECLAREDECLAREcap_id NUMBER;rep_id NUMBER;rep rpt CLOB;

DECLAREcap_id NUMBER;rep_id NUMBER;rep rpt CLOB;rep_rpt CLOB;

BEGINcap_id := DBMS_WORKLOAD_REPLAY.GET_REPLAY_INFO

(dir => 'TESTING');

rep_rpt CLOB;BEGINcap_id := DBMS_WORKLOAD_REPLAY.GET_REPLAY_INFO

(dir => 'TESTING');

/* Get the latest replay for that capture */SELECT max(id) INTO rep_idFROM dba workload replays WHERE capture id=cap id;

/* Get the latest replay for that capture */SELECT max(id) INTO rep_idFROM dba workload replays WHERE capture id=cap id;FROM dba_workload_replays WHERE capture_id=cap_id;

rep_rpt := DBMS_WORKLOAD_REPLAY.REPORT(replay id => rep id,

FROM dba_workload_replays WHERE capture_id=cap_id;

rep_rpt := DBMS_WORKLOAD_REPLAY.REPORT(replay id => rep id,( p y_ p_ ,format => DBMS_WORKLOAD_REPLAY.TYPE_TEXT);

END;/

( p y_ p_ ,format => DBMS_WORKLOAD_REPLAY.TYPE_TEXT);

END;/


アジェンダ

準備

インストール










y


SQL Performance Analyzer: ワークフロー

本番テスト

をキプポ比較

ステップ (1) (2) (3) (4) (5)変更を加える

SQLをキャプチャ（STS）

トランスポートSTS

SQLの実行（変更前）

SQLの実行（変更後）

比較

（パフォーマンス）

(6) 繰り返す

No完了?

Yes(7)

完了?

本番環境への変更/ チューニング完了(7)本番環境への変更/

チューニングの展開


Enterprise Manager でのSPA


9iと11gの間でも使用できるSPA• 9iから11gへ直接アップグレードする場合のシナリオ

ORCL_ora_133674.trcORCL_ora_133674.trc

イベント 10046

コピー STSORCL_ora_133674.trcORCL_ora_133674.trc...

コピ STS

SQL Performance Analyzer

マッピング表

Id Owner Name

123 SH1 SAL1

124 SH2 CUST

exp / imp

Note:455889 1 - SPA example 参照

204

Note:455889.1 - SPA example 参照


SPA: 10.2.0.2 => 10.2.0.4 の場合

• セットアップ10 2 0 4


10.2.0.2 10.2.0.4

R2 R2

SQL Performance AnalyzerSQL

実行計画情報

SQLをSTS内にキャプチャ

SQL Performance Analyzer

STS

SQL

STS


SPA: 9iから11gへのアップグレード

• 時刻に関する統計情報を有効化:alter system set timed statistics=true;alter system set timed statistics=true;

• 9iでのSQLトレースを有効化:

y _y _

9iでのSQLトレスを有効化:alter system set events

'10046 trace name context forever, level 4';alter system set events

'10046 trace name context forever, level 4';



• 9iにマッピング表を作成:create table MAPPING TABLE as create table MAPPING TABLE as _

select object_id id, owner, substr(object_name, 1, 30) name

from dba_objects h bj t t NOT IN

_select object_id id, owner,

substr(object_name, 1, 30) name from dba_objects h bj t t NOT INwhere object_type NOT IN

('CONSUMER GROUP', 'EVALUATION CONTEXT','FUNCTION','INDEXTYPE', 'JAVA CLASS', 'JAVA DATA', 'JAVARESOURCE', 'LIBRARY', 'LOB', 'OPERATOR', 'PACKAGE','PACKAGE BODY' 'PROCEDURE' 'QUEUE' 'RESOURCE

where object_type NOT IN ('CONSUMER GROUP', 'EVALUATION CONTEXT','FUNCTION','INDEXTYPE', 'JAVA CLASS', 'JAVA DATA', 'JAVARESOURCE', 'LIBRARY', 'LOB', 'OPERATOR', 'PACKAGE','PACKAGE BODY' 'PROCEDURE' 'QUEUE' 'RESOURCE'PACKAGE BODY', 'PROCEDURE', 'QUEUE', 'RESOURCEPLAN', 'SYNONYM', 'TRIGGER', 'TYPE', 'TYPE BODY')

union all select user_id id, username owner, null name

'PACKAGE BODY', 'PROCEDURE', 'QUEUE', 'RESOURCEPLAN', 'SYNONYM', 'TRIGGER', 'TYPE', 'TYPE BODY')

union all select user_id id, username owner, null name

• その後、 9iでのSQLトレースを無効化:

from dba_users; from dba_users;

•

• Export mapping table with exp

alter system set events '10046 trace name context forever off';alter system set events '10046 trace name context forever off';

207

Export mapping table with exp



• 11g内にディレクトリ・オブジェクトを作成:create or replace DIRECTORY 'SPA DIR' as '/tmp/spa';create or replace DIRECTORY 'SPA DIR' as '/tmp/spa';

• SPAの個別パッチ（参照: Note:562899.1）をインストール

create or replace DIRECTORY SPA_DIR as /tmp/spa ;create or replace DIRECTORY SPA_DIR as /tmp/spa ;

するか、または11.1.0.7を使用する

• イベント10046のトレース・ファイルを11gシステムにトランスポート

• マッピング表をインポート



• 11g内にSQL Tuning Set（STS）を作成:declaredeclaredeclaremycur DBMS_SQLTUNE.SQLSET_CURSOR;

beginDBMS_SQLTUNE.CREATE_SQLSET('SPA_9iWKLD');

declaremycur DBMS_SQLTUNE.SQLSET_CURSOR;

beginDBMS_SQLTUNE.CREATE_SQLSET('SPA_9iWKLD');open mycur for

select value(p) fromtable(DBMS_SQLTUNE.SELECT_SQL_TRACE(

directory => 'SPA DIR',

open mycur forselect value(p) from

table(DBMS_SQLTUNE.SELECT_SQL_TRACE(directory => 'SPA DIR',directory > SPA_DIR ,file_name => '%ora%',mapping_table_name => 'MAPPING_TABLE'select_mode => DBMS_SQLTUNE.SINGLE_EXECUTION)) p;

( 9i )

directory > SPA_DIR ,file_name => '%ora%',mapping_table_name => 'MAPPING_TABLE'select_mode => DBMS_SQLTUNE.SINGLE_EXECUTION)) p;

( 9i )DBMS_SQLTUNE.LOAD_SQLSET('SPA_9iWKLD', mycur);close mycur;

end; /

DBMS_SQLTUNE.LOAD_SQLSET('SPA_9iWKLD', mycur);close mycur;

end; /

• DBA_SQLSET で進捗を確認

//



• 11g内にSPAタスクを作成:var tname varchar2(200);var tname varchar2(200);( );

execute :tname := DBMS_SQLPA.CREATE_ANALYSIS_TASK(

l t > ‘SPA 9iWKLD’

( );

execute :tname := DBMS_SQLPA.CREATE_ANALYSIS_TASK(

l t > ‘SPA 9iWKLD’sqlset_name => ‘SPA_9iWKLD’,task_name => ‘SPA_TASK_9i_11g’,description => ‘Test 9i to 11g upgrade');

sqlset_name => ‘SPA_9iWKLD’,task_name => ‘SPA_TASK_9i_11g’,description => ‘Test 9i to 11g upgrade');

print tnameprint tname



• SPAタスクのパラメータを設定

beginbeginbeginDBMS_SQLPA.SET_ANALYSIS_TASK_PARAMETER(

task_name => ‘SPA_TASK_9i_11g’,parameter => ‘WORKLOAD_IMPACT_THRESHOLD’,

beginDBMS_SQLPA.SET_ANALYSIS_TASK_PARAMETER(

task_name => ‘SPA_TASK_9i_11g’,parameter => ‘WORKLOAD_IMPACT_THRESHOLD’,_ _value => 0);

DBMS_SQLPA.SET_ANALYSIS_TASK_PARAMETER(task_name => ‘SPA_TASK_9i_11g’,parameter => ‘SQL IMPACT THRESHOLD’

_ _value => 0);

DBMS_SQLPA.SET_ANALYSIS_TASK_PARAMETER(task_name => ‘SPA_TASK_9i_11g’,parameter => ‘SQL IMPACT THRESHOLD’parameter => ‘SQL_IMPACT_THRESHOLD’,value => 5);

end;/

parameter => ‘SQL_IMPACT_THRESHOLD’,value => 5);

end;/

• 軽微なパフォーマンス変化を対象から除外するために、“SQL_IMPACT_THRESHOLD”=5を使用している（つまり、5%以上パフォーマンス低下したSQLだけが対象となる）



• “変更前” のテスト用SQLを作成（収集した9i情報から）beginbeginbeginDBMS_SQLPA.EXECUTE_ANALYSIS_TASK(

task_name => ‘SPA_TASK_9i_11g’,execution_name => ‘SPA_RUN1_9i’,

i ‘ ’

beginDBMS_SQLPA.EXECUTE_ANALYSIS_TASK(

task_name => ‘SPA_TASK_9i_11g’,execution_name => ‘SPA_RUN1_9i’,

i ‘ ’execution_type => ‘CONVERT SQLSET’,execution_desc => ‘9i run generated from STS’);

end;/

execution_type => ‘CONVERT SQLSET’,execution_desc => ‘9i run generated from STS’);

end;/

• 11gでのテストを実行

//

beginbeginbeginDBMS_SQLPA.EXECUTE_ANALYSIS_TASK(

task_name => ‘SPA_TASK_9i_11g’,execution_name => ‘SPA_RUN2_11g’,

beginDBMS_SQLPA.EXECUTE_ANALYSIS_TASK(

task_name => ‘SPA_TASK_9i_11g’,execution_name => ‘SPA_RUN2_11g’,execution_type => ‘TEST EXECUTE’,execution_desc => ‘Test now against 11g’);

end;/

execution_type => ‘TEST EXECUTE’,execution_desc => ‘Test now against 11g’);

end;/

212

//



• 結果を比較

executeexecuteexecuteDBMS_SQLPA.EXECUTE_ANALYSIS_TASK(

task_name => ‘SPA_TASK_9i_11g’,execution_name => ‘COMPARE_9i_11g_CPU’,

executeDBMS_SQLPA.EXECUTE_ANALYSIS_TASK(

task_name => ‘SPA_TASK_9i_11g’,execution_name => ‘COMPARE_9i_11g_CPU’,execution_type => ‘COMPARE PERFORMANCE’,execution_params => DBMS_ADVISOR.ARGLIST(

'COMPARISON_METRIC', 'CPU_TIME','EXECUTION NAME1', 'SPA RUN1 9i',

execution_type => ‘COMPARE PERFORMANCE’,execution_params => DBMS_ADVISOR.ARGLIST(

'COMPARISON_METRIC', 'CPU_TIME','EXECUTION NAME1', 'SPA RUN1 9i',

• 使用できる比較メトリック:

_ , _ _ ,'EXECUTION_NAME2', 'SPA_RUN2_11g'),

execution_desc => ‘Compare 9i vs. 11g on CPU_TIME’);

_ , _ _ ,'EXECUTION_NAME2', 'SPA_RUN2_11g'),

execution_desc => ‘Compare 9i vs. 11g on CPU_TIME’);

• 使用できる比較メトリック:• CPU_TIME• BUFFER_GETS• PARSE_TIME• ELAPSED TIME

低でもこれら2つのメトリックについてはパフォーマンスを比較する

• ELAPSED_TIME• USER_IO_TIME• DISK_READS• DIRECT_WRITESOPTIMIZER COST

213

• OPTIMIZER_COST



• サマリー・レポートを生成set heading offset heading offset heading offset long 1000000000set longchunksize 10000set echo off;

set heading offset long 1000000000set longchunksize 10000set echo off;set linesize 1000;

spool /tmp/spa_9i_11g_cpu_summary.html

select

set linesize 1000;

spool /tmp/spa_9i_11g_cpu_summary.html

selectselect xmltype(DBMS_SQLPA.REPORT_ANALYSIS_TASK('SPA_TASK_9i_11g', /* task_name */'html', /* type */

i l /* l l */

select xmltype(DBMS_SQLPA.REPORT_ANALYSIS_TASK('SPA_TASK_9i_11g', /* task_name */'html', /* type */

i l /* l l */'typical', /* level */'summary', /* section */null, /* object_id */100, /* top sql */

'typical', /* level */'summary', /* section */null, /* object_id */100, /* top sql */100, / top_sql /'COMPARE_9i_11g_CPU')).getclobval(2,2) /* execution_name */

from dual;

spool off

100, / top_sql /'COMPARE_9i_11g_CPU')).getclobval(2,2) /* execution_name */

from dual;

spool off

214

pp



• 劣化したSQL のレポート生成set heading offset heading offset heading offset long 1000000000set longchunksize 10000set echo off;

li i 1000

set heading offset long 1000000000set longchunksize 10000set echo off;

li i 1000set linesize 1000;

spool /tmp/spa_9i_11g_cpu_regressed.html

select

set linesize 1000;

spool /tmp/spa_9i_11g_cpu_regressed.html

select se ectxmltype(DBMS_SQLPA.REPORT_ANALYSIS_TASK('SPA_TASK_9i_11g', /* task_name */'html', /* type */' d' /* l l */

se ectxmltype(DBMS_SQLPA.REPORT_ANALYSIS_TASK('SPA_TASK_9i_11g', /* task_name */'html', /* type */' d' /* l l */'regressed', /* level */'all', /* section */null, /* object_id */null, /* top sql */

'regressed', /* level */'all', /* section */null, /* object_id */null, /* top sql */, / p_ q /'COMPARE_9i_11g_CPU')).getclobval(2,2) /* execution_name */

from dual;

spool off

, / p_ q /'COMPARE_9i_11g_CPU')).getclobval(2,2) /* execution_name */

from dual;

spool off

215

pp



• 実行計画変更レポートを生成set heading offset heading offset heading offset long 1000000000set longchunksize 10000set echo off;

set heading offset long 1000000000set longchunksize 10000set echo off;set linesize 1000;

spool /tmp/spa_9i_11g_changed_plans.html

select

set linesize 1000;

spool /tmp/spa_9i_11g_changed_plans.html

selectselect xmltype(DBMS_SQLPA.REPORT_ANALYSIS_TASK('SPA_TASK_9i_11g', /* task_name */'html', /* type */h d l /* l l */

select xmltype(DBMS_SQLPA.REPORT_ANALYSIS_TASK('SPA_TASK_9i_11g', /* task_name */'html', /* type */h d l /* l l */'changed_plans', /* level */

'all', /* section */null, /* object_id */null, /* top sql */

'changed_plans', /* level */'all', /* section */null, /* object_id */null, /* top sql */null, / top_sql /'COMPARE_9i_11g_CPU')).getclobval(2,2) /* execution_name */

from dual;

spool off

null, / top_sql /'COMPARE_9i_11g_CPU')).getclobval(2,2) /* execution_name */

from dual;

spool off

216

pp


実環境での結果: SPA• パフォーマンス・レポートの詳細:



ソース・データベースがOracle 9iDatabase なので、空欄になっている



• 結果の比較• テスト結果の解釈は慎重にテスト結果の解釈は慎重に

• 環境に関する注意点:• SPAは、変更前/後のテストにどの環境が使用されたかを認識しない

• データはSQLトレース中にも変化する

• 9iでは、SQLトレースがパフォーマンスに大きく影響する

• これらの理由により、レポート内容は実際よりも良い結果になったり、これらの理由により、レポト内容は実際よりも良い結果になったり、悪い結果になったりすることがある

次の点について確認/調査することが望ましい• 次の点について確認/調査することが望ましい:• CPU_TIMEとBUFFER_GETSで、移行による影響の概要を確認

• CPU TIMEとBUFFER GETSで、パフォーマンスが劣化したSQLを_ _確認

• 実行計画が変更されたすべてのSQLを確認


SPAで使用するSQL負荷のキャプチャ

• カーソル・キャッシュからキャプチャ• SQL Tuning Set（STS）を作成SQL Tuning Set（STS）を作成

BEGINDBMS_SQLTUNE.CREATE_SQLSET(

sqlset name => 'SPA STS'

BEGINDBMS_SQLTUNE.CREATE_SQLSET(

sqlset name => 'SPA STS'sqlset_name => 'SPA_STS',description => 'Upgrade test STS for SPA');

END;/

sqlset_name => 'SPA_STS',description => 'Upgrade test STS for SPA');

END;/

• SQLをカーソル・キャッシュからSTSに直接キャプチャ

//

EXECEXECCDBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET(sqlset_name => 'SPA_STS',time limit => 15*60,

CDBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET(sqlset_name => 'SPA_STS',time limit => 15*60,_repeat_interval => 10,capture_mode => dbms_sqltune.MODE_ACCUMULATE_STATS);

_repeat_interval => 10,capture_mode => dbms_sqltune.MODE_ACCUMULATE_STATS);


SPAで使用するSQL負荷のキャプチャ

• STSから文をフィルタ:EXECEXECEXECDBMS_SQLTUNE.DELETE_SQLSET(sqlset_name => 'SPA_STS',basic filter => 'parsing schema name=''MDSYS''');

EXECDBMS_SQLTUNE.DELETE_SQLSET(sqlset_name => 'SPA_STS',basic filter => 'parsing schema name=''MDSYS''');

• これにより、MDSYSに属するすべての文がSTSから削除される

• このDELETEアクションでは BASIC FILTERがWHERE句のように

_ p g_ _ );_ p g_ _ );

このDELETEアクションでは、BASIC_FILTERがWHERE句のように

扱われる

• SPA分析タスクの作成を進める: EXECUTE DBMS_SQLPA.CREATE_ANALYSIS_TASK(task name => ‘SPA TASK CURSOR CACHE’

EXECUTE DBMS_SQLPA.CREATE_ANALYSIS_TASK(task name => ‘SPA TASK CURSOR CACHE’task_name => SPA_TASK_CURSOR_CACHE ,description => ‘SPA with statements from CC’,sqlset_name => ‘SPA_STS’);

task_name => SPA_TASK_CURSOR_CACHE ,description => ‘SPA with statements from CC’,sqlset_name => ‘SPA_STS’);


パラメータ変更

• SPAでの推奨ツール: SQL Tuning Advisor

2

31


パラメータ変更

• SQL Tuning Advisor が提供するSQLプロファイル


アジェンダ

準備

インストール






パフォーマンス・テストフォルバックストラテジ


フォールバック・ストラテジガイドライン

アップグレード事例


フォールバック・ストラテジ

• 初に、次の項目を確認:• 不測の事態が起き、前のステップに戻る必要が生じた場合、それに不測の事態が起き、前のステップに戻る必要が生じた場合、それに

よってデータが失われても問題はないか（例: アップグレード後にシステム内のデータに変更が加えられた場合など）:• 問題がある: バックアップをリストアするか、フラッシュバック

する（10g以降）

• 問題ない: エクスポート/インポートを実行してダウングレードするする


フォールバック・ストラテジ – バックアップ

• バックアップのリストア• オンライン・バックアップを実行する（RMAN）オンラインバックアップを実行する（RMAN）

• 次の点を確認する:• バックアップを保存している場所（テープ、HDなど）

• リストアは正常に機能するか？

• 時間はどれくらいかかるか？• 各リストア・ジョブの優先順位をチェック

（仮想のテープ・ドライブについては特に）

• リカバリにかかる時間はどれくらいか？


フォールバック・ストラテジ – オフライン・バックアップクアップ

• 完全なバックアップをとる必要がない場合• すべてのデータ表領域を読取り専用モードにするすてのデタ表領域を読取り専用ドする

• Immediateモードでデータベースをシャットダウンする

• SYSTEM、TEMP、UNDOのデータ・ファイルおよびSYSAUXと、制御ファイル/REDOログをコピーする制御ファイル/REDOログをコピする

• データベースを再起動する

• アップグレード中に何らかの処理が失敗したら:• データベースをシャットダウンする

• バックアップ先の場所から SYSTEM TEMP UNDOバックアップ先の場所から、SYSTEM、TEMP、UNDO、SYSAUX、制御ファイル、およびREDOログをコピーする

• 移行元の環境でデータベースを起動する• 利点:• 利点:

• 簡単かつ高速

• COMPATIBLEを変更可能


フォールバック・ストラテジ – フラッシュバック

• フラッシュバック・データベース• 通常、リストア・リカバリよりもかなり高速に処理できる通常、リトアリカリよりもかなり高速処理できる

• COMPATIBLEは変更しない

• 10.2から使用可能

保証付きリストアポイントの作成• 保証付きリストア・ポイントの作成

• データベースのアップグレード

• もし失敗した場合、リストア・ポイントにフラッシュバック

• 成功した場合、リストア・ポイントを削除

SQL> CREATE RESTORE POINT grptGUARANTEE FLASHBACK DATABASE

SQL> CREATE RESTORE POINT grptGUARANTEE FLASHBACK DATABASEGUARANTEE FLASHBACK DATABASE;


GUARANTEE FLASHBACK DATABASE;



フォールバック・ストラテジ: exp/imp• exp/imp による9.2.0.xへのダウングレード

• Note:158845.1Note:158845.1• アップグレード前の状態に戻らなければならなくなった場合、

インポート用に空のデータベースを準備する

• 次に:• 次に:• 適切な$ORACLE_HOME/rdbms/admin/catexp.sql を実行して、

アップグレード後のデータベース内に9.2のエクスポート・ビューを作成するを作成する

• エクスポートには9.2の（移行元）expを使用する

• インポートには9.2の（移行元）impを使用する

• 11 1 0 7 での注意: Note:550740 1 参照• 11.1.0.7 での注意: Note:550740.1 参照• 11g database へSYSDBA権限で接続• CREATE OR REPLACE VIEW exu9defpswitches (

compflgs, nlslensem ) AS SELECT a value b valueSELECT a.value, b.value FROM sys.v$parameter a, sys.v$parameter b WHERE a.name = 'plsql_code_type' AND

b.name = 'nls_length_semantics'/

• 11g からデータを抜き出すために9iR2 exp を再スタート

230

• 11g からデータを抜き出すために9iR2 exp を再スタート


フォールバック・ストラテジ: catdwgrd.sql• catdwgrd.sgl によるダウングレード

• Note:443890 1• Note:443890.1• アップグレード元リリースへのダウングレード

• 10.1.0.510.1.0.5• 10.2.0.2/3/4

• COMPATIBLE 設定が上げられていない場合にのみ実行能実行可能!!!• 注意:

ダウングレードでは、アップグレード前のリリースに戻すことのみ可能。そのため、

パッチ・セットを適用する場合は常にアップグレードの開始前に適用する必要があるパッチセットを適用する場合は、常にアップグレドの開始前に適用する必要がある。そうしないと、パッチ適用後のリリースにしかダウングレードできなくなる。


フォールバック・ストラテジ: catdwgrd.sql• catdwgrd.sqlによる10gへのダウングレード

• 11g 環境でのタスク:

SQL> SPOOL /tmp/downgrade.logSQL> STARTUP DOWNGRADESQL> @catdwgrd sql

SQL> SPOOL /tmp/downgrade.logSQL> STARTUP DOWNGRADESQL> @catdwgrd sql

• アップグレード前の10g 環境でのタスク:

SQL> @catdwgrd.sqlSQL> SPOOL OFF SQL> @catdwgrd.sqlSQL> SPOOL OFF

アップグレド前の10g 環境でのタスク:

SQL> STARTUP UPGRADESQL> SPOOL /tmp/reload.logSQL> STARTUP UPGRADESQL> SPOOL /tmp/reload.logSQ S OO /t p/ e oad. ogSQL> @catrelod.sql-- The catrelod.sql script reloads the appropriate version of-- all of the database components in the downgraded database.

SQ S OO /t p/ e oad. ogSQL> @catrelod.sql-- The catrelod.sql script reloads the appropriate version of-- all of the database components in the downgraded database.

• 参照: データベースにEMリポジトリが存在する場合、追加のステップが必要となります。- Oracle 11g アップグレード・ガイドの6章データベースのダウングレードを参照して

SQL> SPOOL OFF SQL> SPOOL OFF

232

g アッグイ章デタダウングを参照しください。


アジェンダ

準備

インストール











ガイドライン

• 多数のシステムを一度に変更することは絶対に避ける！

• すべての変更内容を、詳細かつ明瞭な方法で変更ログに記録するすての変更内容を、詳細かつ明瞭な方法で変更グに記録する！

• テストには、必ず実環境のデータを使用する！

テストには手間を惜しまず十分な時間とリソスを費やす• テストには手間を惜しまず、十分な時間とリソースを費やす

• アップグレードを開始する前には必ず、できるだけ多くのパフォーマンス・データを収集する！ンデタを収集する

• フォールバック・ストラテジを作成しておく！

• フォールバック・ストラテジを作成したら、それが実際に機能するどうかを事前にテストしておくかを事前にテストしておく

• 特に注意する点:特に注意する点:アップグレードはこれまでになく簡単になったが、それでもテストは必ず実行する必要がある


アジェンダ

準備

インストール











Overview

• 5 つの顧客事例1 400のデタベスを移行（9i 11g）1. 400のデータベースを移行（9i→11g）2. シングル・インスタンスからRAC, ASM, DataGuard環境へ移行

• ダウンタイム2分でアップグレードとパッチを適用ダウンタイム2分でアップグレドとッチを適用

3. DWH50件を10.2から11gへ無人アップグレード

4. Upgrade from 10.2.0.3 RAC からto 11.1.0.7 RACへアップグドし大幅なパ向上レードし大幅なパフォーマンス向上

5. Oracle 9.2 から Exadata V1へ7TBのデータを24時間以内に移行移行

• 異機種間プラットフォームCross-platform• 異なるエンディアン

• 異なるバージョン


400のデータベースを（9i→11g）

• 顧客の概要主要な国際小売企業の1つ• 主要な国際小売企業の1つ

• ヨーロッパ、アフリカ、およびアジア地域の32か国に2,195店舗を展開

• 従業員: 約290,000人従業員: 約290,000人• 2008年の収益額: 680億ユーロ



• テクノロジーに関するデータ:O l 9 2 0 8• Oracle 9.2.0.8

• 400件のデータベース

• IBM AIX5Lサーバー - サーバーごとに3つのデータベースを稼動• IBM AIX5Lサバ - サバごとに3つのデタベスを稼動

• データベース1つにつき10件の小売店舗をホスト

• 毎日、夜間にOLTPバッチを実行毎、夜間ッを実行

• バッチ当たり25 GBのREDO• 時間的制約がきわめて厳しい

• 以前、8.1.7から9.2へアップグレードした際に生じた問題:• オプティマイザの問題

アプリケシンの変更が必要になた• アプリケーションの変更が必要になった



• 目標:Oracle 9iからOracle Database 11gに直接アップグレドする• Oracle 9iからOracle Database 11gに直接アップグレードする

• 11gの新機能によってパフォーマンスを適化する

• 自動SQLプロファイル自動SQLプファイル

• SQL Performance Analyzerを使用する

• 実行計画変更の検出

• Database Replayを使用する

• 機能テスト

• すべてのステップを自動化して再利用性を確保• すべてのステップを自動化して再利用性を確保



• セットアップ内容:IBM P670 16CPU 32 GB RAM• IBM P670 - 16CPU - 32 GB RAM

• EMCストレージ - DMX2000• 実稼動データベースのコピーを3件用意（Oracle 9.2.0.8）実稼動デタスのピを3件用意（Oracle 9.2.0.8）• 夜間バッチの記録データ - いつでもリプレイ可能

• 基準とするバッチ実行時間: 1:45:03


実環境での結果: アップグレード

• Oracle 9.2.0.8から11.1.0.6に直接アップグレード• catupgrd sqlによりシェル・スクリプトの部としてアップグレドを• catupgrd.sqlにより、シェル・スクリプトの一部としてアップグレードを実行（バックアップ処理と、いくつかの正常化動作を含む）

• 結果:• きわめて簡単に処理を完了

• 必要になったパッチは数件のみ - 大規模な問題発生はなし

完全にスクリプト対応• 完全にスクリプト対応

• 稼動環境のロールアウトには11.1.0.7を使用


テスト実行1: すべての9iパラメータを使用

• データベースは11gへと正常にアップグレード

•diagnostic destなどの必要な変更を除き調整作業は発生•diagnostic_destなどの必要な変更を除き、調整作業は発生せず

• 結果:果

• 結論:アプグレドは非常にスムズに進んだが多少のチングは必要• アップグレードは非常にスムーズに進んだが、多少のチューニングは必要


テスト実行2: 11gのデフォルトを使用

• データベースは11gへと正常にアップグレード

Oracle Database 11gのデフォルトのパラメタを設定• Oracle Database 11gのデフォルトのパラメータを設定

• 結果:

• 結論:前設定を削除デを使するが• 前のリリースの設定を削除し、11gのデフォルトを使用するのが望ましい


テスト実行3: システム統計情報を収集

• 処理負荷に関するシステム統計情報を収集• exec DBMS STATS GATHER SYSTEM STATS(‘start’);exec DBMS_STATS.GATHER_SYSTEM_STATS( start );• exec DBMS_STATS.GATHER_SYSTEM_STATS(‘stop’);

• ビューAUX_STATS$を参照

結果• 結果:

• 結論:• 有効なシステム統計情報は、オプティマイザがより有効な実行計画を判定するのに役立つ

244

するのに役立つ


テスト実行4: SPAによるinit.oraの適化

• SQL Performance Analyzerを使用（9i 11g）• Note: 562899 1（ホワイト・ペーパー）と Note:455889 1（SPAの参考例）を参照• Note: 562899.1（ホワイトペパ）と Note:455889.1（SPAの参考例）を参照

ORCL ora 133674.trcイベント10046

マッピング表

O C _o a_ 336 t cORCL_ora_133674.trcORCL_ora_133674.trcORCL_ora_133674.trc...

>> コピー >> SQL Performance Analyzer

ッピング表

>> exp / imp >>Id Owner Name

123 SH1 SAL1

124 SH2 CUST

STSアップグレード



• SPAレポートを使用して、init.oraの理想的な設定を判断:Parameters / Reports CPU TIME BUFFER GETSParameters / Reports CPU_TIME BUFFER_GETS

optimizer_features_enable=9 2 0=9.2.0

optimizer_features enable_=11.1.0.6

optimizer indexp __cost_adj=75

optimizer_mode=first_rows_10



• SPAを使用してinit.oraを適化

結果• 結果:

• 結論:• SPAは、実行計画の有効性が低下することをアップグレード前に検出できる非常に便利なツールである

247

検出できる、非常に便利なツルである


テスト実行5: PL/SQLのネイティブ・コンパイル

• PL/SQLのネイティブ・コンパイルのパラメータ:• plsql code type=native• plsql_code_type=native• plsql_optimization_level=3

• 再コンパイル: exec DBMS_UTILITY.COMPILE_SCHEMA(‘<username>’);結果• 結果:

• 結論:• ネイティブ・コンパイルを使用すると、全体的なコンパイル時間が少し改善する

248

ティを使用する、体な時間少改善する


テスト実行6: SQLプロファイル

• 自動SQLチューニングをオンにする• データベースはすべてのAWRスナップショットを対象に高負荷のSQLをチェック• データベースは、すべてのAWRスナップショットを対象に高負荷のSQLをチェックし、それらをSQL Tuning Advisor でのチューニング候補とします

• 目的は、SQLプロファイルを自動的に作成すること

249

テスト実行6: SQLプロファイル

• 自動SQLチューニングをオンにする• 6件のSQLプロファイルについてパフォーマンスを改善（DBAの作業は発生せず）6件のSQLプロファイルについてパフォマンスを改善（DBAの作業は発生せず）

• アプリケーションへの変更もなし

• 結果:

結論:• SQLプロファイルでは、アプリケーションを変更せずに速度を改善できる！

250

、リを変更ず度を改善


実環境での結果: Database Replay

• Database Replayの使用（9i 11g）D t b R l夜間バッチの Database Replay夜間バッチの

処理負荷

アップグレードアップグレド

前処理

• 結論: アプリケーションの変更は必要ない

リプレイ


実環境での結果: まとめ

• Oracle 9.2.0.8から11.1.0.7への直接アップグレード非常に良好に機能し作業は予想以上に簡単• 非常に良好に機能し、作業は予想以上に簡単

• SQL Performance Analyzer• 実行計画変更をアップグレードの前に検出するうえで便利• 実行計画変更をアップグレドの前に検出するうえで便利

• init.oraの適化に大きな効果を発揮

• Database ReplayDatabase Replay• すべてのアプリケーションでエラーが発生しないことを確認できた

• SQLプロファイル• 問合せとレポートの速度を改善

• 新リリースにアップグレードする際の作業負荷を50%軽減新リリスにアップグレドする際の作業負荷を50%軽減

• 大の注目点: アプリケーションの変更が一切不要

• 2009年5月に本番環境へロールアウト

252

• 2009年5月に本番環境へロルアウト


実環境での結果

• OTNから入手できるホワイト・ペーパー• http://www oracle com/technology/products/database/oracle11g/upgrade/• http://www.oracle.com/technology/products/database/oracle11g/upgrade/

presentations/9i_to_11g_real_world_customer_experience.pdf


"Real Application Clusters、ASM、ならびにData

G dを使用することで O l 9iからO lGuardを使用することで、Oracle 9iからOracle

Database 11gへの直接移行を、予想よりもはるかに

簡単に、またスムーズに実行できました"

ビーレフェルト大学ビレフェルト大学コンピューティング・センターデパートメント・マネージャー

Lars Köller 博士


プロジェクト2: ビーレフェルト大学

• ビーレフェルト大学• 学生数18000名数

• 従業員数1500名• Initiative of Excellenceで高く評価されている

• ドイツ国内の23大学をリードする運営が期待されているドイツ国内の23大学をリドする運営が期待されている

• アップグレード前のシステム構成:• Sun Solaris – Sunのハードウェア

10件のデタベスすべてO l 9 2 0 8• 10件のデータベース – すべてOracle 9.2.0.8• きわめて重要なアプリケーション群

• 目標:目標:• ASMとData Guardを使用して、シングル・インスタンスからRACへと移行する

• 非常に良好なパフォマンスを実現する• 非常に良好なパフォーマンスを実現する

• バージョンの異なる複数のOracleを、同じRAC環境内で稼動させる


プロジェクト2: ビーレフェルト大学

• 5つのフェーズ:プズ• セットアップ・フェーズ

• テスト・フェーズ

• パフォーマンス・フェーズ

• 高可用性フェーズ

• ロールアウト・フェーズ


プロジェクト2: セットアップ・フェーズ

• フェーズ1 – セットアップ:共有ストレジを使用する2ノドのSun Solarisクラスタ環境• 共有ストレージを使用する2ノードのSun Solarisクラスタ環境

• Oracle 11.1.0.6ホームx3 • 1つはOracle Clusterware用1 はOracle Clusterware用• 1つはASM用

• 1つはDatabase Homeとして

• Oracle 10.2.0.4ホームx1 • スタンバイの処理用にパワフルなSolarisマシンを1台セットアップ

• 複数のテストシステムを同様にセットアップ• 複数のテスト・システムを同様にセットアップ

• Oracle Grid Control 10.2.0.4とGrid Control 10.2.0.4エージェントを使用して監視を実行


プロジェクト2: テスト・フェーズ

• Phase 2 - Test:現在のデタベスはすべて正常にタゲットリリスへと• 現在のデータベースは、すべて正常にターゲット・リリースへとアップグレードまたは移行された（UTF8の変更を含む）

• 大学のクラス・スケジュールや、中央ユーザー管理システム、Webプレゼンスなどのミッション・クリティカルなアプリケーション群について、内部のテスト・ツールを使用して綿密なテストを行った。

• キャラクタ・セットの変換のためいくつかの変更が必要であった• キャラクタセットの変換のため、いくつかの変更が必要であった


プロジェクト2: パフォーマンス・フェーズ

• フェーズ3 – パフォーマンス:SQL Performance Analyzer（SPA）を使用して実行計画の性能低下を• SQL Performance Analyzer（SPA）を使用して、実行計画の性能低下を検出し、パフォーマンスを改善:


プロジェクト2: パフォーマンス・フェーズ

• フェーズ3 – パフォーマンス:SQL Tuning Advisorを使用してその他94件のSQL文を修正• SQL Tuning Advisorを使用して、その他94件のSQL文を修正

• 34件のSQLプロファイルが処理、実装された

• 速度パフォーマンスが99%アップしたSQL文もあった速度フォマンスが99%アップしたSQL文もあった


プロジェクト2: 高可用性フェーズ

• フェーズ4 - 高可用性:RMANを使用してスタンバイデタベスを自動的に作成• RMANを使用して、スタンバイ・データベースを自動的に作成

• Oracle 11gのRMANでは、現在の本番データベースからバックアップを

とることなくスタンバイを作成でき、スタンバイをネットワーク転送によってリストアできる

• ターゲット:一時的スタンバイを使用したローリング・アップグレードにより、わずか2分のダウンタイムでパッチ・セット11 1 0 7適用を実現予定わずか2分のダウンタイムでパッチセット11.1.0.7適用を実現予定• http://www.oracle.com/technology/deploy/availability/pdf/

maa_wp_11g_transientlogicalrollingupgrade.pdf


プロジェクト2: ロールアウト・フェーズ

• フェーズ5 – ロールアウト:稼動開始日: 2008年9月12日• 稼動開始日: 2008年9月12日

• 2008年10月中旬にロールアウト完了

• 冬期初旬にはすでにシステムの高負荷を記録冬期初旬にはすでにシステムの高負荷を記録

• ログイン数30%増加

• 応答時間は50%短縮

• 一時スタンバイを使用したローリング・アップグレードは完了:• 2009年2月13日金曜日


プロジェクト2: 一時スタンバイ

本稼動フィジカルスタンバイ

保証付きリストア・ポイント

LogminerBuild ロジカル

スタンバイ

DBUAでアップグレード

IDの保持

同期

DBUAでアップグレド

本稼動スイッチオーバー

データベースをフラッシュバック:

ロジカルスタンバイ

同期

保証付きリストア・ポイント

スタンバイ

新しい$OH フィジカルスタンバイ

同期

Logshipping経由で

アップグレード:

本稼動スイッチオーバー

t

フィジカルスタンバイ

263

t t


プロジェクト3: DWH50件の無人アップグレード

• 国際的なOracleパートナー

50件のDWHソリシンが対象• 50件のDWHソリューションが対象（主に大規模な通信会社にインストールされている）

• データベース・サイズは8～12 TBデタベスサイズは8 12 TB• ネットワーク・パフォーマンスとボトルネックを監視するアプリケーションあり

• データベース内に大200,000のパーティション

• 目標:• すべてのデータベースを10.2.0.2から11.1.0.7にアップグレードする

プビ• プラットフォームはRH Linux 64ビット

• インストール、構成作業、アップグレードをすべて無人でおこなう



• サイレント・インストール:OUIを使用してレスポンスファイルを記録:• OUIを使用してレスポンス・ファイルを記録:./runInstaller -record -destinationFile /tmp/inst.rsp

• レスポンス・ファイルをカスタマイズして、無人インストールに使う:./runInstaller -silent -responseFile /tmp/inst.rsp

• サイレント・パッチ・インストール:• サイレント・パッチ・インストール:• OUIを使用してパッチ・セットを記録モードでインストールし、レスポンス・ファイルをパッチ・セットのサイレント・インストールに使う

• サイレント・リスナー構成:• あらかじめ用意されたNETCAレスポンス・ファイルに修正を加える

• 次を実行: ./netca /silent /responseFile netca.rsp



• DBUAを使用したサイレント・アップグレード:• dbua silent sid dwh• dbua -silent -sid dwh

-oracleHome /opt/oracle/product/RDBMS10g-diagnosticDest /opt/oracle/diag-sysDBAUserName syssysDBAUserName sys-sysDBAPassword manager-recompile_invalid_objects true-degree of parallelism 4degree_of_parallelism 4-emConfiguration LOCAL

-dbsnmpPassword manager-sysmanPassword managery g



• 2008年11月22日、11.1.0.7へのアップグレード（本番環境）を正常に完了（本番環境）を正常に完了


Project 4: 10.2.0.3 => 11.1.0.7

• Deutsche Messe AG (ドイツ見本市 => CeBIT)10 2 0 3 から 11 1 0 7 移行• 10.2.0.3 から 11.1.0.7へ移行

• 3-node RAC – OS: Sun Solaris 10• 理由:理由:

• パフォーマンス – 自動SQLチューニングを利用

• RAW デバイスから ASMへ移行

• RMANの複製をフィジカル・スタンバイへ転送

• アップグレード:D t P• Data Pump

• 結果:• 以前よりもパフォーマンスが向上 – 3年前のH/Wで以前よりもパフォマンスが向上 3年前のH/Wで

• Better availabilty with Data Guardを使用して可用性が向上

• 2009年9月/10月に稼働


Project 5: Exadata V1への移行

• Loyalty Partner Solutions社 – Payback(ポイントサービス)設定:• 設定:• 移行元: Oracle 9.2.0.7, HP-UX PA-RISC

• 2つのデータベース: データ量 7TB、1.5 TB2 のデタス: デタ量 7TB、1.5 TB • 移行先: Exadata V1: Oracle Database 11.1.0.7, Oracle Enterprise

Linux 64bit 制限• 制限:• 24時間のダウンタイム

• 計画を含めた移行期間は 4ヶ月計画を含めた移行期間は、4ヶ月

• 8月 – 11月• 1ヶ月の同時稼動期間

• フォールバックの要件

• 稼働予定時期: 2009年11月15日



• Step-by-step1 中間システムを構築1. 中間システムを構築

2. 中間システムにバックアップをリストア

3 リストアしたデータベースを 11 1 0 7へアップグレード3. リストアしたデタベスを 11.1.0.7へアップグレド

PROD INTER

Restore+

U dUpgradeHP-UX PA-RISC HP-UX PA-RISC OEL 64bit

Prod Load


Prod Load


• Step-by-step4 D t P のNETWORK LINKパラメタを使用してスキマとデ4. Data PumpのNETWORK_LINKパラメータを使用してスキーマとデー

タを移行

5. 100GB以上の大規模な表はD t P

表

データベース・リンクで移行

PROD INTER

Data Pump onNETWORK_LINK

HP-UX PA-RISC HP-UX PA-RISC OEL 64bitINSERT APPEND INSERT APPEND on

database links for tables>100 GB

Prod Load


Prod Load


• データベース・リンクを介したData Pump• パラメータ: NETWORK LINKパラメタ: NETWORK_LINK• ターゲット・システム上で impdp を実行

• expdp を実行する必要はない

• LONG/LONG RAW型、オブジェクト型、シングルパーティションでは機能しない

• ディスクIOがなくダンプ・ファイルなしで転送可能• ディスクIOがなく、ダンプ・ファイルなしで転送可能

• 制限: ネットワーク帯域

• 例:$ impdp system/pw NETWORK_LINK=mydblink FULL=Y $ impdp system/pw NETWORK_LINK=mydblink FULL=Y



• Step-by-step6 E d t V1上で本番負荷の実行をテスト6. Exadata V1上で本番負荷の実行をテスト

7. Exadata V1上で全てのレポートと評価を行う

PROD INTER

HP-UX PA-RISC HP-UX PA-RISC OEL 64bit

Prod LoadAppsサーバでの本番環境の負荷をリダイレクト


Prod Load


• Step-by-step8 予定より2週間早く稼働8. 予定より2週間早く稼働

9. Exadataによる劇的なパフォーマンス向上

• 32時間のジョブを2時間に短縮32時間のジョブを2時間に短縮

• ユーザからは、パフォーマンスが良すぎるとのコメントも

PROD INTER

HP-UX PA-RISC HP-UX PA-RISC OEL 64bit

Prod Load


Prod Load

Summary

• Oracle Database 11g, 11g Release 2へのアップグレードは簡単単

• 安定したデータベース・リリース

• 優れた機能群• 優れた機能群

• Let's go ... :-)

• Any questions – would like to become an Oracle 11gR2

reference customer? Let us know about your upgradesreference customer? Let us know about your upgrades ...•[email protected]•Roy Swonger@oracle com•[email protected]•[email protected]


oracle database 11g への移行 - 詳細ガイド パート2...compatible パラメータ• 9i...

Documents

oracle database 11g への移行 - 詳細ガイドパート2...compatible パラメータ• 9i...