Oracle Database 12c R2には非常に多くの新機能があります。これまでに存在しなかった純粋な意味での新機能もありますし、従来から存在している機能を改善した位置づけの新機能もあります。これらの新機能すべてをチェックすることは非常に大変な作業です。本連載では、Oracle Databaseを日々愛用（≒酷使！）するコーソルのOracleスペシャリストがチェックし、特に有用と思われる12c R2新機能をご紹介します。
是非本連載の記事をご覧いただき、現場で活用できそうな機能がありましたら、ぜひその新機能を使っていただきたいと思います。
本連載が、みなさまのお役にたてば幸いです。
株式会社コーソル 河野 敏彦（こうの としひこ）
コーソルに中途入社後、Oracle Databaseのサポート業務を経験したのち、ミッションクリティカルシステムのDBAとしてOracle Databaseの運用保守業務に従事している。
「いつでも楽しく笑顔でお仕事」をモットーに、笑顔をふりまきながら奮闘中。
お笑いと甘いものが大好き。元調理師の異色エンジニア。
[会社紹介] 株式会社コーソル
Oracleを中心にデータベースの設計、導入・構築、運用管理、保守・サポート、コンサルティング等、「Oracle Database技術」の強みを活かしたビジネスを展開。エンジニア社員の「ORACLE MASTER」の保有率は98％に及び、その内の約40％はORACLE MASTER Platinumを取得している。技術者を数多く育成した企業に贈られる「Oracle Certification Award」を5年連続で受賞。2016年現在、企業別ORACLE MASTER 11g/12c Platinum取得者数ランキングで国内No.1。「CO - Solutions＝共に解決する」の理念のもと、「データベース技術」×「サービス」を軸とし、高いDB技術をもとにお客様へ"心あるサービス"を提供し続けることにこだわっている。
Oracle Database 12c Release 2(以下12c R2)では、PDBの移行およびクローンに関する新機能が追加され、Oracle Database 12c Release 1(以下12c R1)よりも活用しやすくなりました。本記事では、各機能の特徴を実行手順を交え紹介していきます。
Oracle Cloudをはじめとするクラウド環境でデータベースを稼働することが一般的になりつつあります。これに伴い、オンプレミス環境で動作しているデータベースをクラウド環境へ移行したいというご相談を多く頂戴するようになりました。
また、パブリッククラウド環境を利用すると簡単にサーバーを準備できますので、クラウド環境に開発環境を構築する事例が増えてきています。
【図1. クラウド環境への移行・クローン】
このような状況に対して、PDB移行・クローンの12c R2新機能がとても役立ちます。
さて、12c R2新機能を紹介する前に、まずは12c R1での移行・クローン機能についておさらいしましょう。
ご存知の通り、12c R1で、マルチテナント・アーキテクチャが導入されました。データベースをマルチテナント環境のPDBとして構成すると、Oracle Database 11g Release 2(以下11g R2)までの一般的なデータベース構成では使えなかった、PDB特有の移行・クローンにかかわる機能を利用できます。
PDBクローニングとは、ソースPDBが配置されているCDB上もしくは異なるCDB上に簡単にPDBのクローンを作成することができる機能です。「CREATE TABLE AS SELECT」文のようにSQL文でデータベースのクローンを作成することが可能です。なお、クローニング中はソースPDBを読み取り専用にする必要があること、PDBのサイズが大きいほど読み取り専用の時間が長くなることに注意が必要です。
■ PDBクローニング
SQL> create pluggable database <作成するPDB名> from <複製するPDB名>; PDB再配置とは、ソースPDBが配置されているCDBとは異なるCDB上にソースPDBを移行することができる機能です。ALTER文でPDBのunplug(PDBを、現在配置されているCDBから取り外すこと)を行い、作成されたｘｍｌファイルおよびデータファイルを移行先環境にコピーし、移行先CDBにPDBをplug(unplug状態のPDBを、CDBに配置すること)することで移行を完了することができます。なお、PDBのunplug実行前にデータベースを停止しなければならないこと、クローン時と同様にPDBのサイズが大きいほどデータファイルのコピーに時間がかかるため、データベースの停止時間が長くなることに注意してください。
【図2.PDB再配置の動作】
■ PDB再配置
SQL> alter pluggable database
↓ 移行先に、xmlファイルおよびデータファイルをコピー
SQL> create pluggable database <作成するPDB名> using ''; 上記で説明した通り、PDBの移行・クローンを実行するコマンドは非常にシンプルです。11g R2までの方法に比べると、手順はわかりやすくなり、簡単に実行できます。
しかし、依然として以下のような問題は残っています。
移行のためのPDB再配置実行中は、PDBを停止する必要があります。PDBのサイズが大きい場合、再配置処理が長時間になる可能性があるため、PDBの停止時間も長くなります。
多くのシステムでは定期的なサービス停止日や時間帯を設けており、その際にデータベースのメンテナンスや移行を行いますが、PDBのサイズが大きい場合、移行作業が時間内に作業が完了しない可能性があるため、規模の大きいシステムでの使用は不向きでした。クローン実行中は、クローン元のPDBを読み取り専用にする必要があります。PDBのサイズが大きい場合、クローン処理が長時間になる可能性があるため、クローン元のデータベースを読み取り専用とする時間も長くなります。読み取り専用の間は、更新処理を実行できませんので、これが長時間になると、サービスに大きな影響与えてしまいます。
これらの問題を解決するため、12c R2では以下の新機能が導入されています。
機能名に「ホット」「オンライン」が記載されてることから予測できる通り、PDBの移行・クローン時にデータベースを停止、読み取り専用モードにする必要がなくなり、オンラインでの実施が可能となりました。また、マテリアライズド・ビューのようにデータの「リフレッシュ」が可能なPDBを作成できるようになりました。
以降の章ではどのような動作でオンラインでの実施を可能としているかを、新機能の使い方を交えつつ解説していきます。
12c R2では、PDB複製時にクローン元PDBを読み取り専用にせずにクローン処理を実行できるようになりました。これを「PDBホットクローニング」と呼びます。
【図3. PDBホットクローニング】
データベースのクローニングでは、一貫性を持つデータベースの状態をもとにして、新しいデータベースを作成します。このため、一貫性を持つデータベースの状態を、どのような方法で得るかがカギになります。
12c R1では、ソースPDBを読み取り専用モードに変更することで、一貫性を持つデータベースの状態を得ていました。ソースPDBが読み取り専用モードになっている間に、PDBを構成するデータファイルをコピーして、クローン処理を実現していました。
【図4. 12c R1でのPDBクローニングの動作】
12c R2では、クローン処理実行時に、ソースPDBを読み取り専用モードに変更する必要はありません。読み取り専用モードではないため、実行中のトランザクションや、データファイルに反映されていない変更が存在しており、ソースPDBは、一貫性を持つデータベースの状態ではありません。このため、12c R2のPDBホットクローニングでは、データファイルをコピーした後に、REDOおよびUNDOを適用します。これにより、ターゲットPDBが一貫性を持つデータベースの状態にすることができます。
【図5. 12c R2でのPDBホットクローニングの動作】
なお、アラートログを確認するとターゲットPDBにREDOが適用され、内部的にメディアリカバリーが実行されていることが確認できます。
2017-03-20T15:58:13.037436+09:00
create pluggable database C201OYPDB2 from C201OXPDB2@CLONE_LINK ★ PDBホットクローニング開始
path_prefix = '/u01/app/oracle/oradata/c201ox/c201oxpdb2'
file_name_convert = ('/u01/app/oracle/oradata/c201ox/c201oxpdb2/', '/u01/app/oracle/oradata/c201oy/c201oypdb2/')
2017-03-20T15:58:13.571538+09:00
Opatch validation is skipped for PDB C201OYPDB2 (con_id=5)
：：：：
：：：：
2017-03-20T15:58:23.838067+09:00
Applying media recovery for pdb-4099 from SCN 1530059 to SCN 1530076
Remote log information: count-1
thr-1, seq-3, logfile-/u01/app/oracle/fast_recovery_area/c201ox/C201OX/foreign_archivelog/C201OXPDB2/2017_03_20/o1_mf_1_3_4011655719_.arc, los-1486593, nxs-18446744073709551615
C201OYPDB2(5):Media Recovery Start ★メディアリカバリが実行されている
2017-03-20T15:58:23.844335+09:00
C201OYPDB2(5):Serial Media Recovery started PDBホットクローニング機能を使用するために満たすべき主な前提条件、制限は以下の通りです。
詳細はマニュアルを確認してください。
==============================================
Oracle Database管理者ガイド 12cリリース2 (12.2) E72998-02
38 SQL*Plusを使用したPDBの作成および削除
==============================================
では、実際にPDBホットクローニング機能を使用してみましょう。
今回は、異なるサーバー上にそれぞれCDBが存在し、PDB「C201OXPDB2」を、CDB「c201oy」に「C201OYPDB2」という名前でクローンPDBを作成することを想定して進めます。
【図6. 作成想定環境】
1. まずは、ソースCDB(c201ox)に接続し、前提条件である「ローカルUNDOモード/ARCHIVE LOGモード」になっているかを確認します。
SQL>SELECT PROPERTY_NAME,PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';
PROPERTY_NAME PROPERTY_VALUE
--------------------- ---------------
LOCAL_UNDO_ENABLED TRUE ★ 「TRUE」であればローカルUNDOモードです。
SQL> archive log list
Database log mode Archive Mode ★ 「Archive Mode」であればARCHIVE LOGモードです。
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 29
Next log sequence to archive 31
Current log sequence 31 2. 次に、ターゲットCDB(c201oy)に接続し、ソースCDB(c201ox)に接続可能なデータベースリンクを作成します。
なお、今回はソースとターゲットが異なるCDB上にあることを想定して作成しているためデータベースリンクの作成が必要ですが、同一CDB上にクローンを作成する場合には、データベースリンクの作成は不要です。
SQL> create public database link CLONE_LINK connect to system identified by oracle using 'C201OX';
Database link created.3. 最後に、ターゲットCDB(c201oy)に接続し、クローンPDB作成のSQLを実行すれば、作業完了です。
SQL> select name, open_mode from v$pdbs@CLONE_LINK;
NAME OPEN_MODE
------------ ----------
PDB$SEED READ ONLY
C201OXPDB1 MOUNTED
C201OXPDB2 READ WRITE ★ ソースPDBが「READ WRITE」であることを確認
SQL> create pluggable database C201OYPDB2 from C201OXPDB2@CLONE_LINK
2 path_prefix = '/u01/app/oracle/oradata/c201ox/c201oxpdb2'
3 file_name_convert = ('/u01/app/oracle/oradata/c201ox/c201oxpdb2/', '/u01/app/oracle/oradata/c201oy/c201oypdb2/');
Pluggable database created.
SQL> SELECT PDB_ID, PDB_NAME, STATUS FROM DBA_PDBS ORDER BY PDB_ID;
PDB_ID PDB_NAME STATUS
---------- --------------- ----------
2 PDB$SEED NORMAL
3 C201OXPDB1 NORMAL
4 C201OYPDB3 NEW
6 C201OYPDB2 NEW ★ クローンが作成されている 見て頂いてわかる通り、実行するSQLは12c R1と変わりません。とてもシンプルな手順ですので、ぜひ試してみてください。
「2.3. 12c R1 でのPDB移行、PDBクローンの課題」で触れましたが、12c R1では、クローン実行後、ソースPDBのデータ更新をターゲットPDBに反映する簡単な方法がありませんでした。12c R2では、リフレッシュ可能なクローンPDBが導入され、クローン完了後のソースPDBに加えられた更新内容を、定期的もしくは任意のタイミングでターゲットPDBに反映できるようになっています。ソースPDBに更新内容を反映することを、リフレッシュと呼んでいます。
【図7. リフレッシュ可能なクローンPDB】
ソースPDBの更新をターゲットPDBに反映するために、内部的にREDOの転送、REDOの適用が実行されています。
【図8. リフレッシュ可能なクローンPDBの動作】
ターゲットPDBをリフレッシュするにはalter pluggable database refreshコマンドを実行すればOKです（手動リフレッシュ）。12c R1のように、PDBを再クローンしたり、変更を反映させるための作りこむなどは不要です。
定期的にターゲットPDBをリフレッシュすることもできます（自動リフレッシュ）。
また、リフレッシュ時にクローン元PDBを読み取り専用にする必要はありません。
リフレッシュ可能なクローンPDBを作成するためには、PDBホットクローニングと同様に、いくつかの構成前提条件、制限があります。
詳細については以下のマニュアルに記載されているためよく確認しましょう。
==============================================
Oracle Database管理者ガイド 12cリリース2 (12.2) E72998-02
38.1.2.13 PDBのリフレッシュ
==============================================
それでは、リフレッシュ可能なPDB作成していきましょう。
今回は、異なるサーバー上にそれぞれCDBが存在し、PDB「C201OXPDB2」を、CDB「c201oy」に「C201OYPDB4」という名前で、60分ごとに自動リフレッシュされるPDBを作成することを想定して進めます。
【図9. 作成想定環境】
1. ソースCDB(c201ox)に接続し、PDBホットクローンと同様に前提条件である「ローカルUNDOモード/ARCHIVE LOGモード」になっているかを確認します。
SQL> SELECT PROPERTY_NAME,PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';
SQL> archive log list 2. ターゲットCDB(c201oy)に接続し、ソースCDB(c201ox)に接続可能なデーベースリンクを作成します。
ここもPDBホットクローンと同様の手順です。
SQL> create public database link CLONE_LINK connect to system identified by oracle using 'C201OX';
Database link created. 3. ターゲットCDB(c201oy)に接続し、リフレッシュ可能なPDB作成のSQLを実行します。PDBホットクローンとの違いは「refresh mode」句が指定しているかどうかの違いだけです。指定を省略した場合のデフォルトは「ｒｅｆｒｅｓｈ ｍｏｄｅ ｎｏｎｅ」となりリフレッシュ不可PDBとなるため、明示的に指定する必要があります。
SQL> create pluggable database C201OYPDB4 from C201OXPDB2@CLONE_LINK refresh mode every 60 minutes
2 path_prefix = '/u01/app/oracle/oradata/c201ox/c201oxpdb2'
3 file_name_convert = ('/u01/app/oracle/oradata/c201ox/c201oxpdb2/', '/u01/app/oracle/oradata/c201oy/c201oypdb4/');
Pluggable database created.
手動リフレッシュで作成する場合には以下の構文で作成できます。
CREATE PLUGGABLE DATABASE <ターゲットPDB> FROM <ソースPDB> REFRESH MODE MANUAL;
SQL> SELECT PDB_ID, PDB_NAME, STATUS FROM DBA_PDBS ORDER BY PDB_ID;
PDB_ID PDB_NAME STATUS
---------- ------------ ----------
2 PDB$SEED NORMAL
3 C201OXPDB1 NORMAL
4 C201OYPDB3 NEW
5 C201OYPDB2 NEW
7 C201OYPDB4 REFRESHING ★ リフレッシュ可能PDBが作成されている
★「DBA_PDBS」表のREFRESH_INTERVAL列で、リフレッシュ間隔を確認することができます。
SQL> select PDB_ID,PDB_NAME,STATUS,REFRESH_MODE,REFRESH_INTERVAL from DBA_PDBS;
PDB_ID PDB_NAME STATUS REFRES REFRESH_INTERVAL
---------- ----------- ---------- ------ ----------------
2 PDB$SEED NORMAL NONE
3 C201OXPDB1 NORMAL NONE
4 C201OYPDB3 NEW NONE
5 C201OYPDB2 NEW NONE
7 C201OYPDB4 REFRESHING AUTO 60 ★ 60分間隔でリフレッシュ なお、自動リフレッシュで作成した場合でも以下のコマンドを実行して、任意のタイミングでリフレッシュすることもできます。
SQL> alter pluggable database close; ★ リフレッシュするため、PDBをクローズする
SQL> alter pluggable database refresh; リフレッシュ時のアラートログを確認すると、先ほど説明した通りホットクローニング時同様にREDOが転送/適用されメディアリカバリーが実行されていることを確認することができます。
2017-03-20T18:00:25.792869+09:00
C201OYPDB4(6):alter pluggable database refresh ★ リフレッシュ開始
2017-03-20T18:00:26.774723+09:00
Applying media recovery for pdb-4099 from SCN 1540300 to SCN 1540507
Remote log information: count-1
thr-1, seq-3, logfile-/u01/app/oracle/fast_recovery_area/c201ox/C201OX/foreign_archivelog/C201OXPDB2/2017_03_20/o1_mf_1_3_4011655719_.arc, los-1486593, nxs-18446744073709551615
C201OYPDB4(6):Media Recovery Start ★ メディアリカバリーが実行されている
2017-03-20T18:00:26.775818+09:00
C201OYPDB4(6):Serial Media Recovery started
2017-03-20T18:00:26.829116+09:00
C201OYPDB4(6):Media Recovery Log /u01/app/oracle/fast_recovery_area/c201ox/C201OX/foreign_archivelog/C201OXPDB2/2017_03_20/o1_mf_1_3_4011655719_.arc
2017-03-20T18:00:27.078908+09:00
C201OYPDB4(6):Incomplete Recovery applied until change 1540507 time 03/20/2017 18:00:25
2017-03-20T18:00:27.081232+09:00
C201OYPDB4(6):Media Recovery Complete (c201oy)
C201OYPDB4(6):Completed: alter pluggable database refresh12c R1では、unplug/plug機能により異なるCDB間でPDBを移動できました。しかし、移動している間はPDBを停止する必要がありました。12c R2では、PDBの移動中に停止することなく、読取り/書込みモードでPDBの移動をすることが可能となりました。これをオンラインでのPDB再配置と呼びます。
ただし、PDBの移動時に接続中のコネクション、実行中のトランザクションはそれぞれ切断およびロールバックされることに注意してください。
【図10. オンラインでのPDB再配置】
クローン（コピー）と移行（移動）という違いはありますが、オンラインでのPDB再配置の動作は、PDBホットクローンの動作と似ています。まずPDBを構成するデータファイルがコピーされ、その後、REDOの転送および適用が行われます。
ただし、オンラインでのPDB再配置に特有の機能として、再配置後のPDBへの接続を自動でリダイレクトする機能が実装されています。PDB再配置にソースPDB側のリスナーに対してクライアントから接続要求があった場合、接続要求はターゲットPDBに自動的にリダイレクトされます。この機能があるため、再配置の前後でクライアントの設定を変更する必要はありません。
【図11. オンラインでのPDB再配置の動作】
オンラインでのPDB再配置を実行するための構成前提条件、制限を確認していきましょう。
PDBホットクローン時と同様にローカルUNDOモード、ARCHIVELOGモードである必要があります。
詳細については以下のマニュアル参照してください。
==============================================
Oracle Database管理者ガイド 12cリリース2 (12.2) E72998-02
38.5.2 PDBの再配置
==============================================
それでは、オンラインでのPDB再配置を実行していきましょう。
今回は、異なるサーバー上にそれぞれCDBが存在し、PDB「C201OXPDB2」を、CDB「c201oxs」に再配置することを想定して進めます。
【図12. 想定環境】
1. ソースCDB(c201ox)に接続し、前提条件である「ローカルUNDOモード/ARCHIVE LOGモード」になっているかを確認します。
SQL> SELECT PROPERTY_NAME,PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';
SQL> archive log list 2. ターゲットCDB(c201oxs)に接続し、ソースCDB(c201ox)に接続可能なデーベースリンクを作成します。
SQL> create public database link RELOC_LINK connect to system identified by oracle using 'C201OX';
Database link created. 3. ターゲットCDB(c201oxs) に接続し、PDB再配置のSQLを実行します。
SQL> create pluggable database C201OXPDB2 from C201OXPDB2@RELOC_LINK RELOCATE AVAILABILITY MAX
2 path_prefix = '/u01/app/oracle/oradata/c201ox/c201oxpdb2'
3 file_name_convert = ('/u01/app/oracle/oradata/c201ox/c201oxpdb2/', '/u01/app/oracle/oradata/c201oxs/c201oxpdb2/');
Pluggable database created. 4. 最後に、ターゲットCDB(c201oxs)に配置されているターゲットPDB(C201OXPDB2)をOPENします。これにより、再配置先のPDBに接続がリダイレクトされるようになり、オンラインでのPDB再配置は完了です。
※ OPEN前の再配置先PDBのSTATUS
SQL> SELECT PDB_ID, PDB_NAME, STATUS FROM DBA_PDBS ORDER BY PDB_ID
PDB_ID PDB_NAME STATUS
---------- -------------- ----------
2 PDB$SEED NORMAL
3 C201OXSPDB1 NORMAL
5 C201OXPDB2 RELOCATING ★
SQL> alter pluggable database C201OXPDB2 open; SQLコマンド実行結果からは、リスナーのリダイレクトが構成されていること、ソースPDBが停止される動作がわかりにくいですが、ターゲットPDBのアラートログや、ソースCDB上の「lsnrctl status」コマンドの出力結果を確認すると、それらを確認ができます。
■ターゲットPDBのアラートログ
2017-04-09T18:57:07.019654+09:00
alter pluggable database C201OXPDB2 open ★ ターゲットDBのOPEN
2017-04-09T18:57:07.945084+09:00
Applying media recovery for pdb-4099 from SCN 2417681 to SCN 2419036
Remote log information: count-1
■ソースPDBのアラートログ
2017-04-09T18:57:09.334479+09:00 ★ターゲットPDBのOPEN後、
C201OXPDB2(4):JIT: pid 7552 requesting stop ★ソースPDBの停止がリクエストされている
Pluggable database C201OXPDB2 closed
C201OXPDB2(4):JIT: pid 7552 requesting stop
Pluggable database C201OXPDB2 closed
2017-04-09T18:57:11.333019+09:00
Deleted file /u01/app/oracle/oradata/c201ox/c201oxpdb2/users01.dbf
Deleted file /u01/app/oracle/oradata/c201ox/c201oxpdb2/temp01.dbf
■ソースCDB側「lsnrctl status」コマンドの出力結果(ターゲットPDBのOPEN前)
Service "c201oxpdb2.domain" has 1 instance(s).
Instance "c201ox", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:220 refused:0 state:ready
LOCAL SERVER
■ソースCDB側「lsnrctl status」コマンドの出力結果(ターゲットPDBのOPEN後)
Service "c201oxpdb2.domain" has 1 instance(s).
Instance "c201ox", status READY, has 2 handler(s) for this service...
Handler(s):
"D000" established:0 refused:0 current:0 max:1022 state:ready
DISPATCHER
(ADDRESS=(PROTOCOL=tcp)(HOST=lc201oxd.domain)(PORT=32676))
"COMMON" established:1 refused:0 state:ready
FORWARD SERVER ★ ターゲットPDBのノードへリダイレクトされている
(ADDRESS=(PROTOCOL=TCP)(HOST=lc201oxs.domain)(PORT=1521)) 今回ご紹介させて頂いた12c R2の新機能によって、移行・クローン時に読み書き可能な状態での実施が可能となり、データベースの長時間停止を許容できない環境でも機能を使いやすくなりました。また、リフレッシュ可能なPDBにより、クローンは最新の状態のデータを保持できるようになり、クローン環境を簡単に最新の状態にリフレッシュできるようになりました。
皆様の中には、これから11g R2から12cにバージョンアップをされる方もいらっしゃると思います。その際には、データベースの移行やテスト環境の運用など、先の運用を見据え12c R2を選定頂ければ幸いです。