EM Expressの強化

Copyright © 2016 CO-Sol Inc. All Rights Reserved. 1Copyright © 2016 CO-Sol Inc. All Rights Reserved.Copyright © 2016 CO-Sol Inc. All Rights Reserved.

Platinumホルダーが選ぶ！現場で役立つOracle Database 12c

次期リリース新機能

2016年10月27日株式会社コーソル渡部亮太

Copyright © 2016 CO-Sol Inc. All Rights Reserved. 2

自己紹介+所属会社紹介

渡部亮太（わたべりょうた）– 著書「プロとしてのOracleアーキテクチャ入門

[第2版]」「プロとしてのOracle運用管理入門」– 講演実績多数– ブログ「コーソルDatabaseエンジニアのBlog」

http://cosol.jp/techdb/– JPOUG 共同創設者、ボードメンバー– Oracle ACE

株式会社コーソル– 「CO-Solutions＝共に解決する」の理念のもと、Oracle技術に特化

した事業を展開中。心あるサービスの提供とデータベースエンジニアの育成に注力している

– 社員数: 131名 (2016年10月時点) – ORACLE MASTER Platinum 11g 取得者数 46名

ORACLE MASTER Platinum 12c 取得者数 29名取得者数日本 No.1 （日本オラクル様Webページより）

http://www.oracle.com/jp/education/omdata-171891-ja.html


今日の発表について

• 提案・導入・運用の現場で、Oracle Databaseを日々愛用（酷使）するコーソルの12c Platinum保持エンジニアから見て、地味ながら役に立ちそうな、知っておいた方がよさそうな12.2新機能をご紹介します。

• 弊社では、大小さまざまな規模のお客様に対してプロフェッショナルサービスを提供しております。このため、Standard Editionで使用可能な新機能から、有償オプションが必要な新機能まで、まんべんなくチェックいたしました。

• Oracle Database 12c Release 2マニュアルおよびダウンロード版のリリース前であるため、動作の詳細や、機能を使用可能なライセンス(Edition/Option/Pack)に認識違いがある可能性があります。リリース後に、ご自身でチェックいただけますようお願いいたします。

• 今日の内容が、皆さんの今後のご提案のお役にたてば、また、現場での会話のネタになれば、嬉しいです


今回ご紹介する機能Edition/ Option ご紹介する機能Standard Edition Long Identifier

Data-Bound CollationHandling Data Errors with SQLReal-time Materialized ViewsSQL*Plus Command HistorySQL*Plus CSV Output

(EM Express) EM Express Single Port AccessEM Express Resource Manager SupportEM Express SQL Performance Analyzer (SPA) SupportEM Express Performance Hub Enhancements

Enterprise Edition Application Continuity for OCI ApplicationsEnhanced SQL Plan Management

Advanced Security TDE Tablespace Offline Conversion TDE Tablespace Live ConversionFully Encrypted Database

Multitenant PDB Character SetNear Zero Downtime PDB Relocation

Active Data Guard Oracle Data Guard for Data Warehouses


Standard Editionで使える12.2 新機能


Long Identifiers

オブジェクト名の長さ制限を大幅に緩和

• 長い日本語のオブジェクト名が使いやすく

version 最大サイズ最大文字数 (日本語、UTF-8換算)12.1以前 30バイト 10文字12.2 128バイト 42文字

SQL> CREATE TABLE T_店別月次商品売上実績 ( store_id number, month date, amount number);CREATE TABLE T_店別月次商品売上実績 ( store_id number, month date, amount number)

*行1でエラーが発生しました。:ORA-00972: 識別子が長すぎます。

12.1

SQL> CREATE TABLE T_店別月次商品売上実績 ( store_id number, month date, amount number);

表が作成されました。

12.2

※：DBキャラクタセットAL32UTF8で検証


Data-Bound Collation

データベース側でCollationを設定可能に• Collation(照合) ≒ 文字列のソート・文字の等価規則

• 以下の設定が必要なことに注意– MAX_STRING_SIZE=EXTENDED、COMPATIBILITY>=12.2

• MAX_STRING_SIZE=EXTENDEDは文字列データの最大長を32Kバイトまで拡張する12.1新パラメータ

version 設定方法設定単位・影響範囲12.1以前 NLS_SORT

初期化パラメータセッション(ALTER SESSION)インスタンス(ALTER SYSTEM)

12.2 各種DDLのCOLLATION /COLLATE句

カラムテーブルスキーマ他

動的・ユーザー側

静的・データベース側


Data-Bound Collation

id str ・・・

A ・・・

a ・・・

Ａ・・・

12.1

NLS_COMP=LINGUISTICNLS_SORT=JAPANESE_M_CI

a → ａ → A → Ａ→ b → ｂ → B → Ｂ

12.2 Data-Bound Collation

NLS_COMP=BINARYNLS_SORT=BINARY

A → B → a → b→ Ａ → Ｂ → ａ → ｂ

SELECT ... ORDER BY ...


NLS_COMP=<XXX>NLS_SORT=<XXX>

a → ａ → A → Ａ→ b → ｂ → B → Ｂ


CREATE TABLE tab1(str VARCHAR2(10) COLLATE JAPANESE_M_CI);

ユーザー側で動的にCollationを指定

データベース側で静的にCollationを指定

原則無視される（無視しない設定も可能ではある）

id str ・・・

A ・・・

a ・・・

Ａ・・・


Handling Data Errors with SQL

データ型の変換処理におけるエラーに対応するためのSQL機能強化• 変換NGな異常データは通常ごく一部、一部の異常データ

のために変換処理全体がロールバックされるのは非効率• 外部データ（他DB、非構造化データ）を取り込むケースが増加

→ 変換エラー発生は避けがたい → 効率的な対処が必要# 狙い SQL機能強化1 変換NGな一部データを、

デフォルト値に一律変換するTO_<データ型>ファンクションにデフォルト値を設定可能に

2 変換NGな一部データを、変換実行前に特定可能に

VALIDATE_CONVERSION(<データ>AS <データ型>)ファンクションで変換OK or NGを判定可能に

[参考] DMLエラーロギング (従来機能)• 変換NGな一部データをスキップして、変換OKなデータのみを処理• 変換NGな一部データはエラーロギング表に記録


TO_<データ型>ファンクションのデフォルト値

id amount (varchar2型)1 1002 2003 XXX4 400

SQL> INSERT INTO cnv_dst (SELECT id, TO_NUMBER(amount) FROM cnv_src);INSERT INTO cnv_dst (SELECT id, TO_NUMBER(amount) FROM cnv_src)

*行1でエラーが発生しました。:ORA-01722: 数値が無効です。

SQL> INSERT INTO cnv_dst(SELECT id, TO_NUMBER(amount DEFAULT 999 ON CONVERSION ERROR) FROM cnv_src);

4行が作成されました。

id amount (number型)

id amount (varchar2型)1 1002 2003 XXX4 400

id amount (number型)1 1002 2003 9994 400

変換OKデータを含め全データ変換されず

変換NGデータはデフォルト値に変換


VALIDATE_CONVERSIONファンクション

VALIDATE_CONVERSION(<データ> AS <データ型>)– 変換OK → 戻り値 1– 変換NG → 戻り値 0

使用例 : 変換処理の事前チェックid amount (varchar2型)1 1002 2003 XXX4 400

SQL> SELECT id, amount FROM cnv_src2 WHERE VALIDATE_CONVERSION(amount AS NUMBER) = 0;

ID AMOUNT---------- --------------------

3 XXX

id amount (number型)

変換NGデータを特定


アイディア：外部表を用いたデータロードに活用

• データロードに伴う型変換を含むデータ処理をSQLで– 外部表のORACLE_LOADERアクセスドライバを用いてデータ処理を

実行しない– 外部表のDDL（≒SQL*Loaderの制御ファイル文法）をシンプルに

id amount(number型)

id amount(VARCHAR2型)

外部表表（データロード先）

CREATE TABLE "TBL_EXT2"("ID" VARCHAR2(255), "AMOUNT" VARCHAR2(255)

)ORGANIZATION external(… < SQL*Loaderの制御ファ

イル文法> …);

INSERT INTO tbl_toSELECT id, TO_NUMBER(amount DEFAULT 0 ON CONVERSION

ERROR), FROM TBL_EXT2;

フラットファイルなど

型変換


Real-time Materialized Views

MVの新鮮さとリフレッシュ負荷のトレードオフ問題を解決• MVIEWのデータを最新にするには、

MVIEWの頻繁なリフレッシュが必要 → 負荷の増加

モード動作概要 MVデータの新鮮さ

マスタ表更新頻発時のリフレッシュ負荷

ONCOMMIT

マスタ表への更新コミット時に毎回リフレッシュ ◎ × 更新都度リフレッシュ

するためONDEMAND

自動リフレッシュなし適宜手動でリフレッシュ

× リフレッシュしないと古いまま ◎

定期リフレッシュ

ジョブで定期的にリフレッシュ

？リフレッシュ頻度に依存

△ある程度新しいが最新ではない

マスタ表 MVIEW

既存リレッシュ機能の整理

更新リフレッシュ


Real-time Materialized Viewsの概念

MVをリフレッシュしなくても、最新のデータが得られる• MVの古いデータ＋MVログ → 最新データ

マスタ表 MVIEW

MVIEWログ

マスタ表への更新内容

古いデータ

データの乖離

参照

最新のデータ

最新のデータ

参照時にリフレッシュ相当の負荷が発生するが、更新頻度>>参照頻度であれば、トータルの負荷は軽減できると想定

更新


Real-time Materialized Viewsの使用方法

Real-time Materialized Viewsの構成• ENABLE ON QUERY COMPUTATION句を指定して

MVIEWを作成• マスタ表にMVIEWログが必要• 定期リフレッシュと組み合わせで使用するのがオススメ

Real-time Materialized Viewsから最新データを得るa. クエリリライト（要EE)を有効にして、マスタ表に問合

せb. /*+ FRESH_MV */ヒントを指定して、MVIEWに直接問

合せを発行


SQL*Plus Command History

DBA待望！のコマンド履歴機能

• readlineライブラリによる実装でないのが残念…→ 今後もrlwrapのお世話になりそう…

• とはいえ、ツール追加ができないカスタマ環境では助かる– 事前にset hist onを実行する必要が

ある点に注意！

SQL> set hist onSQL> select * from dual;

D-X

SQL> show userUSER is "SYS"SQL> hist

1 select * from dual;2 show user

SQL> hist 1 run

D-X


SQL*Plus CSV Output

問合せ結果をCSV形式で出力• 診断情報、統計情報をExcelなどで分析するときに便利

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';SQL> SELECT * FROM t_csv1;

N S D---------- ---------------------------------------- -------------------

1 string1 2016-01-01 01:00:002 string2 2016-01-01 02:00:00

SQL> set markup csv on delimiter , quote onSQL> SELECT * FROM t_csv1;

"N","S","D"1,"string1","2016-01-01 01:00:00"2,"string2","2016-01-01 02:00:00"


SQL*Plus CSV Output

CSV特有の処理も実装済み！SQL> set markup csv on delimiter , quote onSQL> SELECT * FROM t_csv2;

"N","S"1,"aaa""aaa"2,"AB"3,"_______（略 - とても長い文字列)______"

①非数値データのみをクォート

②文字列データ中の"を""として出力（ダブルクオート文字のエスケープ）

③文字列データ中の改行文字を改行として出力

SQL> set colsep ','SQL> SELECT * FROM t_csv2;

N,S----------,----------------------------------------

1,aaa"aaa2,A,B

3,________________________________________(略),_______________________________________

[参考] 従来の方法（苦肉の策だった…）では上記処理は実現できない

④表示幅(linesize)を超える文字列でもデータ途中で改行しない

③

①②

④


EM Expressの強化


EM Expressの強化

• EM Express : 12.1から導入されたEM Database Controlの後継となるWebベースのDB管理機能

• 12.2における EM Express新機能新機能名称説明EM Express Single Port Access

CDBとPDBが同一ポートでEMEXにアクセス可能にDBごとにEMEXを構成する必要がなくなった

EM Express Resource Manager Support

リソースマネージャの構成に対応OEM 12cとほぼ同等の機能（細かい差異あり）

EM Express SQL Performance Analyzer (SPA) Support

SQL Performance Analyzer(SPA) に対応SPA = Oracle Real Application Testingオプションに含まれるSQLパフォーマンス分析機能

EM Express Performance Hub Enhancements

パフォーマンスHUB画面が強化され、表示される項目が増えた


EM Express Single Port Access

CDBとPDBが同一ポートでEMEXにアクセス可能に– DBごとにEMEXを構成する必要がなくなった– 12.1では、DB個別にポートを割り当て、EMを構成する必要があった

• CDB・PDB共通のEMEXログイン画面で、「コンテナ名」欄でアクセスするDB（CDB、PDB）を指定

アクセスするDB（CDB、PDB）を指定


EM Express Resource Manager Support

• おおむねOEM13cと同等のディレクティブ（リソース制限項目）を設定可能

• (なぜか)細かい違いが存在– 12.2 EMEX非対応 :

ランナウェイ問合せ「文によるトラッキング」、「ESTIMATEを使用」

– 12.2 EMEXのみ対応(OEM13c非対応) : Set Session Directives（OEM 12c 「アイドル時間」）「PGA Limit(MB)」と「Temp Size Limit (MB)」


EM Express SPA Support

• SPA=SQL Performance Analyzer• Oracle Real Application Testingオプションに含まれるSQLパ

フォーマンス分析機能



CDB 12.2.0.1 CDB 12.1.0.2



PDB 12.2.0.1 PDB 12.1.0.2


Enterprise Editionで使用可能な12.2 新機能


Application Continuity for OCI Applications

• 実行中のDMLおよびトランザクションをインスタンス障害から保護（隔離）する非常にパワフルな機能– 実現機構は全く異なるが、TAFの更新処理対応版と位置付けると

理解しやすい• Application ContinuityがJDBC Thin Driver以外のプロ

グラミングインタフェースでも使用可能に

• SQL*Plus対応により、機能の理解・学習がしやすく– とはいえ最終検証はもちろん実際の構成でやるべきなのでしょう

version Application Continuity対応Programming Interface/ Program

12.1 JDBC Thinドライバのみ12.2 JDBC Thinドライバ, OCI, OCCI, ODP.Net

SQL*Plusも対応


Enhanced SQL Plan Management

OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = TRUE 設定で自動取得される計画をフィルタ可能に→ 計画ベースラインの肥大化を抑制できる• フィルタ条件に使用できる要素

– SQLが解析（実行）されたスキーマ– SQLを発行したプログラムのMODULE名– SQLを発行したプログラムのACTION名– 発行されたSQL文字列（ LIKE条件が適用される）

• 想定される利用シナリオ→ 特定の条件を満たすSQLのみSQL計画管理に登録– 特定のスキーマ（アプリケーション用スキーマなど）のSQLのみ– 特定のプログラム（バッチ用など）から発行されたSQLのみ– 特定のコメントを含むSQLのみ（要注意SQLなど）– 特定の表にアクセスするSQLのみ（大データを格納する表など）


フィルタ条件の指定

EXEC DBMS_SPM.CONFIGURE('<フィルタ用の属性>','<属性値>',<enable>);enable: true or false

属性適用されるフィルタ条件enable=true enable=false

AUTO_CAPTURE_SQL_TEXT以外 = <属性値> <> <属性値>AUTO_CAPTURE_SQL_TEXT LIKE <属性値> NOT LIKE <属性値>

DBMS_SPM.CONFIGUREに与えた引数と適用されるフィルタ条件

フィルタ用の属性名フィルタ条件AUTO_CAPTURE_PARSING_SCHEMA_NAME

SQLが解析（実行）されたスキーマ

AUTO_CAPTURE_MODULE SQLを発行したプログラムのMODULE名AUTO_CAPTURE_ACTION SQLを発行したプログラムのACTION名AUTO_CAPTURE_SQL_TEXT 発行されたSQL文字列（LIKE条件が適用）


フィルタ条件の確認

• DBA_SQL_MANAGEMENT_CONFIGから指定したフィルタ条件を確認可能

SQL> SELECT PARAMETER_NAME, PARAMETER_VALUE FROM DBA_SQL_MANAGEMENT_CONFIGWHERE PARAMETER_NAME LIKE '%AUTO%';

PARAMETER_NAME PARAMETER_VALUE ----------------------------------- -----------------------------------AUTO_CAPTURE_PARSING_SCHEMA_NAME parsing_schema IN (SPM1, SPM2) AUTO_CAPTURE_MODULE AUTO_CAPTURE_ACTION AUTO_CAPTURE_SQL_TEXT (sql_text LIKE %SPM_CAPTURE%)


フィルタ条件を複数指定した場合の動作異なるタイプのフィルタ指定はAND条件で結合される同じタイプの複数のフィルタ指定はOR条件に近い動きとなる→ 若干癖があるので、DBA_SQL_MANAGEMENT_CONFIGの確認と動作検証をオススメ

EXEC DBMS_SPM.CONFIGURE( 'AUTO_CAPTURE_PARSING_SCHEMA_NAME','SPM1',TRUE); EXEC DBMS_SPM.CONFIGURE('AUTO_CAPTURE_PARSING_SCHEMA_NAME','SPM2',TRUE); 実行後のDBA_SQL_MANAGEMENT_CONFIGの実行結果PARAMETER_NAME PARAMETER_VALUE ----------------------------------- -----------------------------------AUTO_CAPTURE_PARSING_SCHEMA_NAME parsing_schema IN (SPM1, SPM2)

:

EXEC DBMS_SPM.CONFIGURE( 'AUTO_CAPTURE_PARSING_SCHEMA_NAME','SPM1',TRUE); EXEC DBMS_SPM.CONFIGURE('AUTO_CAPTURE_PARSING_SCHEMA_NAME','SPM2', FALSE) 実行後のDBA_SQL_MANAGEMENT_CONFIGの実行結果PARAMETER_NAME PARAMETER_VALUE ----------------------------------- --------------------------------------------AUTO_CAPTURE_PARSING_SCHEMA_NAME parsing_schema IN (SPM1) AND parsing_schema NOT IN (SPM2)

:


Advanced Security Optionで使用可能な 12.2 新機能


表領域暗号化の強化

新機能名称説明TDE Tablespace Offline Conversion

既存表領域をオフラインで暗号化可能に12.1では表領域作成時のみ暗号化可能だった

TDE Tablespace Live Conversion

既存表領域をオンラインで暗号化可能に一時的に2倍の領域が必要なことに注意内部的にデータファイルのオンライン移動を使用していると思われる

Fully Encrypted Database SYSTEM、SYSAUX、UNDO、TEMP表領域が暗号化可能に12.1では、ユーザー用途の永続化表領域のみが暗号化可能だった

（以降は紹介のみ、説明は割愛）

ENCRYPT_NEW_TABLESPACESパラメータ

ENCRYPT_NEW_TABLESPACESをALWAYSに設定すると、ENCRYPTION句を指定せずにCREATE TABLESPACEを実行したときも暗号化される


TDE Tablespace Offline Conversion

既存表領域をオフラインで暗号化できる• 従来は表領域の作成時のみ暗号化が可能だった• 表領域をOFFLINEにして

ALTER TABLESPACE <表領域名> ENCRYPTION OFFLINE ENCRYPT; – DECRYPT指定で暗号化解除も可能

• 暗号化アルゴリズムはAES128のみ使用可能• ユーザー用途の永続的表領域に加えて、SYSTEM表領域、

SYSAUX表領域、UNDO表領域もオフライン暗号化可能(="Fully Encrypted Database"新機能）– 既存のTEMP表領域は暗号化できないが、暗号化した別のTEMP表

領域を新規作成し、切り替えることで同等機能を実現できる



既存表領域をオンラインのまま暗号化できる• ALTER TABLESPACE <表領域名> ENCRYPTION

ONLINE USING '<暗号化アルゴリズム>' ENCRYPT FILE_NAME_CONVERT = ('<old>', '<new>');– FILE_NAME_CONVERT = ('<old>', '<new>')に新旧ファイル

名の書き換えルールを指定する– DECRYPT指定で暗号化解除も可能

• 一時的に2倍の領域が必要なことに注意– 内部的に12.1新機能オンラインデータファイル移動のテクノロ

ジが使用されていると思われる• ユーザー用途の永続的表領域に加えて、SYSTEM表領域、

SYSAUX表領域、UNDO表領域もオンライン暗号化可能(="Fully Encrypted Database"新機能）



ALTER TABLESPACE SYSAUX ENCRYPTION ONLINE ENCRYPT FILE_NAME_CONVERT = ('sysaux01.dbf','sysaux01_enc.dbf');実行時のファイル状態監視

[Thu Jul 07 11:07:07.628 2016] -rw-r-----. 1 oracle oinstall 1073750016 Jul 5 17:07 /u01/app/oracle/oradata/orcl/sysaux01.dbf

[Thu Jul 07 11:07:08.695 2016] -rw-r-----. 1 oracle oinstall 1073750016 Jul 5 17:07 /u01/app/oracle/oradata/orcl/sysaux01.dbf[Thu Jul 07 11:07:08.695 2016] -rw-r-----. 1 oracle oinstall 1073750016 Jul 5 17:08 /u01/app/oracle/oradata/orcl/sysaux01_enc.dbf

: [Thu Jul 07 11:07:54.278 2016] -rw-r-----. 1 oracle oinstall 1073750016 Jul 5 17:09 /u01/app/oracle/oradata/orcl/sysaux01_enc.dbf[Thu Jul 07 11:07:55.303 2016] -rw-r-----. 1 oracle oinstall 1073750016 Jul 5 17:09 /u01/app/oracle/oradata/orcl/sysaux01.dbf

[Thu Jul 07 11:07:55.303 2016] -rw-r-----. 1 oracle oinstall 1073750016 Jul 5 17:09 /u01/app/oracle/oradata/orcl/sysaux01_enc.dbf

ONLINE暗号化実行中はファイルが2つ存在する

暗号化前

暗号化後


Multitenant Optionで使用可能な 12.2 新機能


PDB Character Set (1/2)

同一のCDBに異なるキャラクタセットのPDBを統合可能に• 従来はCDB含めすべてのデータベースのキャラクタセッ

トが同じ（正確には上位互換）である必要があった• AL32UTF8への移行コスト捻出が難しいレガシーキャラ

クタセットデータベースの統合が比較的容易に– レガシーキャラクタセット: JA16SJIS、JA16EUCなど

AL32UTF8

CDB - AL32UTF8

JA16SJIS JA16EUC

PDB


PDB Character Set (2/2)注意点• PDBを収容するCDBのキャラクタセットはAL32UTF8必須• CDBキャラクタセットと異なるキャラクタセットのPDBの新規作成は不

可– キャラクタセットAL32UTF8のCDBでも、非AL32UTF8のPDBを作成できない– 他のCDB内のPDBや非CDBを移行するのはOK（下図参照）

想定されるユースケース

AL32UTF8

CDB - AL32UTF8

JA16SJIS JA16EUC

PDB

CDB - JA16SJIS

JA16SJIS

JA16EUC

非CDB(従来型シングル)


Near Zero Downtime PDB Relocation

PDBを別マシン上の別CDBにNear Zero Downtimeで移行できる機能• アプリケーションからの接続を、移行先PDBへ自動転送する機能あり

(RELOCATE AVAILABILITY MAX句)

移行元CDB

移行元PDB

移行先CDB

移行先PDB

OLD NEW

Near Zero Downtimeで移行

オンプレミス環境など

クラウド環境など



仕組みと実行コマンド

移行元CDB

移行元PDB

移行先CDB

移行先PDB

移行先CDB→移行元CDB方向のDBリンク

ALTER PLUGGABLE DATABASE <移行先PDB> OPEN;

CREATE PLUGGABLE DATABASE <移行先PDB名> FROM <移行元PDB名>@<DBリンク名>RELOCATE AVAILABILITY [ MAX | NORMAL ]FILE_NAME_CONVERT = ('<old>', '<new>');

① データファイルCOPY

② REDOデータ転送

①

②

メディアリカバリ実行

移行先CDBで実行

①～②間の更新差分がメディアリカバリ

で埋められる

OLD NEW



RELOCATE AVAILABILITY MAX句の指定→ Relocate実行後の新規接続が移行先PDBに転送される

移行元CDB

移行元PDB

リスナーリスナーService "pdb1.world" has 1 instance(s).Instance "cdb1", status READY, ...Handler(s):

:"COMMON" established:0 ...

FORWARD SERVER←★:

(ADDRESS=(PROTOCOL=TCP)(HOST=<移行元サーバ>)(PORT=<port>))

移行元CDB

移行先PDB

接続要求

接続要求を転送

OLD NEW

移行



適用領域– オンプレミス → クラウドへのDB（PDB）移行– オンプレミス環境におけるCDB間のPDB移動– （場合によっては）シングルテナント間の移行

注意点– DBリンクの「向き」は、移行先CDB→移行元CDB– 移行元CDBへのDBリンク接続ユーザーにSYSOPER権限が必要– 既存の接続、実行中トランザクションは移行されない

→ 接続は切断、トランザクションはロールバックされる→ この制限が "Near" Zero Downtime たる所以か

– 移行元PDBと移行先PDBでファイルパスの変更がない場合でも、非OMFの場合は CREATE PLUGGABLE DATABASE にFILE_NAME_CONVERT句の指定（もしくは類似機構）が必要


Active Data Guard Optionで使用可能な 12.2 新機能


Oracle Data GuardのDHW向け拡張

新機能名称説明Oracle Data Guard for Data Warehouses

プライマリDBでのNOLOGGING操作実行により発生するブロック破損を修復可能に

（以降は紹介のみ、説明は割愛）

Oracle Database In-Memory Support on Oracle Active Data Guard

スタンバイDBでインメモリ機能を使用可能に

Data Guard support for Diagnostic Pack

スタンバイDBでAWRを使用可能にリモートDBに格納した診断情報を使用するようだ

Active Data Guard Support for SQL Tuning Advisor

スタンバイDBでSQLチューニングアドバイザを使用可能に

一時表、セッション順序(12.1新機能）

スタンバイDBで一時表、順序を使用したレポート生成の前処理を実行可能に


プライマリDBでの大量更新処理実行によるREDO転送・適用遅延の発生

プライマリDB スタンバイDB

大量データをローディング

オンラインREDOログファイル

スタンバイREDOログファイル

REDO転送

REDO適用

大量のREDOデータが生成

転送遅延

適用遅延


大量データ更新のNOLOGGING処理化によるスタンバイDBでのブロック破損発生


NOLOGGING操作実行（ダイレクトパスロードなど）



REDO転送

REDO適用

REDOログ実質出力なし

更新対象ブロックの破損

要データファイルのリストア＋リカバリ

（安全策をとってスタンバイDBを再作成する

ケースも多い）


RMAN RECOVER DATABASE NONLOGGED BLOCK

RMAN> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Statement processed

RMAN> RECOVER DATABASE NONLOGGED BLOCK;

Starting recover at 22-JUL-16using channel ORA_DISK_1

starting recovery of nonlogged blocksList of Datafiles=================File Status Nonlogged Blocks Blocks Examined Blocks Skipped---- ------ ---------------- --------------- --------------1 OK 0 0 1036793 OK 0 0 665594 OK 0 0 76797 OK 0 57 582

Details of nonlogged blocks can be queried from v$nonlogged_block view

recovery of nonlogged blocks complete, elapsed time: 00:00:01

Finished recover at 22-JUL-16


RMAN> RECOVER DATABASE NONLOGGED BLOCKを前提とした運用


① 一時的にFORCE LOGGINGを無効化



REDO転送

REDO適用

リストア、リカバリなしで破損

ブロックを復旧

③ 負荷が低い時間帯を選んでRMAN> RECOVER DATABASE NONLOGGED BLOCKを実行し、破損ブロックを復旧

REDOデータ削減によりREDO転送・適

用遅延を抑止

② NOLOGGING操作実行（ダイレクトパスロードなど）


Documents

EM Expressの強化