#はじめに
この記事は「Oracle Cloud Infrastructure(その2) Advent Calendar 2019」の12月24日の記事として投稿です。 記事の内容は執筆時(2019/12/24)のものなので、現在とは異なる可能性があります。「Oracleの機能拡張はとにかく早い!」ので、適宜、最新状況をご確認ください
さて、本日はクリスマスイブ明日、サンタがやってくるか楽しみです。そんな中、久しぶりに DBaaS を使って最新の Oracle Database と向き合ったときに面白そうな機能があったので、ご紹介したいと思います。
※DBの話で申し訳ないのですが、DBaaS 使っているので…
#最近 Oracle Database で遊んでいますか
最近、ホント Oracle Database と向き合うことが少なかったです。ほら、、Cloudとか、クラウドとか、くら、、、。うん、流行ってありますからね(汗) とはいえ、手軽に Oracle Database の新機能を確認できるようになったのは、Cloud時代様々ですと、出だしはどうでもいいですかねぇ
話を戻して、気付けば色々と Oracle Database も機能が拡充しています。追っかけるのが大変だと思いますが、ワクワクする機能もありますので、興味がある方は、イジり倒してもらえると嬉しい限りです
##検証環境
- Oracle Database 19c(19.4.0.0.0)
#マルチテナント構成の管理
久しぶりに Oracle Database を調べてみると、色々と機能拡張していました。そもそもライセンス的に大きい変更もありました、こちらです。
Database Licensing Information User Manualより引用
####PDBは、3つまで作って良いんだ!
SE2でもDBCS-SEでもDBCS-EEでも3つまで作って良い!ということなので、PDBをどこでも遠慮無く使って良い状態になりました。ということで、なかなか制限(ライセンス制限)あってできなかったことは**「データ複製用途でPDBクローンして運用したかった!!」**という方は多かったのではないかな?と思いますので、このあたりの紹介です。
##PDBを使った運用シナリオ
DB運用の中で、データ複製するとき CTAS(Create Table <table_name> As Select ...) を利用してデータ複製している方が多いと思います。一部のデータ抽出であれば、このワザが最適ですが、データベースのほとんどを占めるような大量データに対してCTAS運用は、その後に統計や索引などのメンテナンスを考えると、ちょっと大変かな?とも思いますので、このあたりで、**PDBクローンが使えるのではないかな?**というところで検証です。
##PDBクローンのおさらい
今までの Oracle Database は、PDBのクローンを行うにはクローン元を一貫性のある状態にするために、読取り専用(READ ONLY)モードにする必要がありましたが、19cからは、この制限は無くなりました。なので、気楽に使えるようになったのはいうまでもありません。
(READ ONLYに変えなくてはならないのは、さすがに運用で使いづらかった…。ですよね?)
マルチテナント関連の機能拡張は、他にもあるので気になる方は、こちらを確認してください
Oracle Databaseリリース19c、バージョン19.1での変更点
##PDBクローンを試してみた
今回は Oracle Cloud の DB(DBaaS) を使って検証しています。CPUコア数は2つの環境です。
とりあえず、機能としては使えるとは思いますので、今回の確認ポイントとしてはー
- ホントにRead Writeの状態で使えるのか?
- どのくらいパフォーマンスが良いのかな?
という視点での確認です。
※一部SQL Plusのコマンド結果は、見やすいように整形しています。
###対象データの確認
今回のCTASとPDBクローンのパフォーマンス確認で使うのは、こちら。
#####PDB01がソースPDBです。 バッチシ Read Write の状態
SQL*Plus: Release 19.0.0.0.0 - Production on Tue Dec 22 23:34:44 2019
Version 19.4.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to:
Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB01 READ WRITE NO
4 PDB02 READ WRITE NO
PDBクローンしてみるのはPDB01です。ちなみにPDB01の中には大きなテーブルTEST01がいます。データサイズとしてはこんな感じ。
#####データ件数(1.8億件)
SQL> show con_name
CON_NAME
------------------------------
PDB01
SQL> select count(1) from test01;
COUNT(1)
----------
187295201
#####表サイズ(42GBくらい)
set pages 100
set lines 50
col table_name format a10
SELECT
a.table_name
, b.GB
FROM user_tables a
, (select segment_name,sum(bytes)/1024/1024/1024 GB from user_segments group by segment_name) b
WHERE a.table_name = b.segment_name
ORDER BY a.table_name, b.GB desc;
TABLE_NAME GB
---------- ----------
DEPT .000061035
EMP .000061035
SALGRADE .000061035
TEST01 42.5537109
TEST02 1.0625
scottスキーマにtest01を作って、その表が1.8億件で42.5GBの表です。では、早速試してみましょう。
###CTASの実行
SQL> create table test11 as select * from test01;
Table created.
Elapsed: 00:16:46.07
###PDBクローン
書いていて気付きましたが、順序が逆になってしまったので、今回のPDBクローンはCTAS検証で追加した表(TEST11)も含めてのPDBクローンの結果です
SQL> create pluggable database pdb03 from pdb01 using keystore identified by <password>;
Pluggable database created.
Elapsed: 00:05:19.61
とりあえず、PDBクローンの方が早いようですね。まあ遅かったら「この機能って」となりますけど
話を戻して、確認したかった点は、下記の通り。
- ホントにRead Writeの状態で使えるのか? → 問題なくできました
- どのくらいパフォーマンスが良いのかな? → CTASより3倍くらい早いかな
##感想
今回は単純に投げれば、PDBクローンの方が早い結果は得られるだろうな。と思っていました(そりゃーねぇ)。CTASも利用用途としては、対象データのみ抽出できるという優れもの。ただ「どーん」とデータベース複製するぐらいのものを実施するのであれば、PDBクローンも使い勝手は良さそうです。CTAS運用で検討しなくてはならないのは、データだけもってくるので統計情報などメンテナンスは必要になるので、このあたりの運用を考えるとソースPDBを簡単に複製できるのは、楽チンではありますね。
稼働しているデータベースから、検証(テスト)環境としてデータベースを用意したい!!というデータ複製では大活躍しそうです。
##今後に期待したいこと
もう少し運用で考えると、指定した時間でPDBクローンができると嬉しいかったのですが、残念ながら、今はできなそうです
18cからPDBスナップショット・カルーセルが登場していたので、このカルーセルで管理されている時間内であれば、好きな時点でPDBクローンを作れるのではないか と、期待してしまったのですけどね…。(思い先行型のあるある…です(笑))
マルチテナント管理者ガイドより引用
だって、create pluggable database に、こんな指定もあるのですよ?
(上の図を見た後だと、できるかも?と思うことは自然だと思うのです!!)
USING SNAPSHOT { snapshot_name | AT SCN snapshot_SCN | AT snapshot_timestamp }
SQL言語リファレンス:CREATE PLUGGABLE DATABASE
と思いましたけど、よーくみたら 「snapshot_SCN または snapshot_timestamp」と記載されているのですよね。実はクローンしたい SCN や timestamp を指定する。ということで使えたりして…。と思い試してみましたが、無理でした
とはいえ、技術的には実現することも可能なはずなので、しれっと実装されることに期待です。時間指定でPDBクローンが使えるようになると、例えば、テスト時のデータ管理でステキなことが考えられそうな気がします。
※上記の検証結果を「おまけ」に記載しておきます。興味があれば、眺めてください。
では、みなさま、良いクリスマスを!! そして、良いお年を!!
##おまけ
オンプレ環境で申し訳無いのですが、自前PCで検証した結果です。
scn(2354716)とscn(2357825)で、snapshotを撮りました。
SQL> SELECT CON_ID, CON_NAME, SNAPSHOT_NAME, SNAPSHOT_SCN FROM DBA_PDB_SNAPSHOTS;
CON_ID CON_NAME SNAPSHOT_NAME SNAPSHOT_SCN
------- --------------- --------------------------- ------------
3 ORCLPDB1 ORA_SNAP01 2354716
3 ORCLPDB1 ORA_SNAP02 2357825
PDBクローンのポイントとしては、scn(2355255)を指定します。ちなみに、各SCNの時間は下記の通り。
SQL> ALTER SESSION SET NLS_TIMESTAMP_FORMAT = 'RR/MM/DD HH24:MI:SSXFF';
Session altered.
SQL> select scn_to_timestamp(2354716) from dual;
SCN_TO_TIMESTAMP(2354716)
---------------------------------------------------------------------------
19/12/22 15:13:38.000000000
SQL> select scn_to_timestamp(2355255) from dual;
SCN_TO_TIMESTAMP(2355255)
---------------------------------------------------------------------------
19/12/22 15:15:27.000000000
SQL> select scn_to_timestamp(2357825) from dual;
SCN_TO_TIMESTAMP(2357825)
---------------------------------------------------------------------------
19/12/22 15:49:10.000000000
ここで期待を裏切ってPDBクローンができたら感動したのですけど…
期待通り?のエラー(ORA-65364: snapshot not found)でした。
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 ORCLPDB1 READ WRITE NO
SQL> create pluggable database orclpdb2 from orclpdb1 using snapshot at scn '2355255'
2 create_file_dest='/opt/oracle/oradata/ORCLCDB';
create pluggable database orclpdb2 from orclpdb1 using snapshot at scn '2355255'
*
ERROR at line 1:
ORA-65364: snapshot not found
「スナップショットが見つかりません」と、怒られてしまいました
##参考
・Oracle Multitenant 管理者ガイド 19c(英語)
・Oracle Multitenant 管理者ガイド 19c(日本語)
※もはや Oracle あるあるですが、英語版の方が日本語版より更新が早く、新しい情報で記載されているため、可能な限り英語版を確認してください。(現時点で、英語版は2019年12月版。日本語版は2019年6月版です)