コーソルOracleスペシャリストがチェック!Oracle Database 12c R2新機能
Oracle Database 12c R2には非常に多くの新機能があります。これまでに存在しなかった純粋な意味での新機能もありますし、従来から存在している機能を改善した位置づけの新機能もあります。これらの新機能すべてをチェックすることは非常に大変な作業です。本連載では、Oracle Databaseを日々愛用(≒酷使!)するコーソルのOracleスペシャリストがチェックし、特に有用と思われる12c R2新機能をご紹介します。
是非本連載の記事をご覧いただき、現場で活用できそうな機能がありましたら、ぜひその新機能を使っていただきたいと思います。
本連載が、みなさまのお役にたてば幸いです。
第3回 12c R2のPDBリソース制御
株式会社コーソル 五十嵐 一俊(いがらし かずとし)
新卒としてコーソル入社後、Oracle製品のサポート業務を経て、現在はExadataの構築業務やデータベースの運用保守業務に従事。
「新しいことは、とりあえず何でも挑戦してみる!」をモットーに活動中。
「お客様にいつでもどこでも頼られる存在」を目指し、日々精進中。
[会社紹介] 株式会社コーソル
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技術をもとにお客様へ"心あるサービス"を提供し続けることにこだわっている。
12c R2のPDBリソース制御
Oracle Database 12c Release 2(以下 12c R2)では、PDBのリソース制御に関する新機能が追加され、Oracle Database 12c Release 1(以下 12c R1)よりもPDBリソースを制御できる幅が広がり、マルチテナント環境においてより適切にリソースを制御できるようになりました。本記事では、12c R1でのリソース制御の機能を振り返りつつ、12c R2で追加された新機能の使い方について、検証結果を踏まえながら紹介します。
1. MTA(Multitenant Architecture)とは
PDB(プラガブル・データベース)のリソース制御についてお話しする前に、MTA(Multitenant Architecture、マルチテナント・アーキテクチャ)について簡単におさらいします。
近年、ハードウェアと運用メンテナンスのコスト削減などを目的にデータベースを統合することが一般的になっています。Oracle Databaseでは、データベース統合を容易にする技術として、12c R1でMTAが導入されました。
MTAを使用することで、複数のPDB(プラガブル・データベース)をCDB(マルチテナント・コンテナ・データベース)と呼ばれる1つのデータベースに統合することができます。
【図1:CDBの構成要素】
- CDB$ROOT(ルート)
データベース全体で共有するオブジェクトやメタデータを管理しています。データ・ディクショナリにはデータベース全体で共有する情報として、付属する全てのPDBの情報が含まれており、コンテナ全体の管理が可能です。
- PDB$SEED(シード)
PDBを新規作成する際のテンプレートとして使用します。
- PDB(プラガブル・データベース)
MTAに統合されたデータベースに相当する部分であり、ユーザデータを管理する部分です。PDB内のスキーマや表領域を含む論理的なセットとして管理でき、それぞれのPDBのデータは分離されています。
PDB間のデータは分離されているため、CDB内に複数のPDBを統合することができます。
なお、MTA機能を用いて複数のデータベースを統合するには、Oracle Multitenantオプションが必要です。例外的に、CDB に1つのPDBのみを含む、シングルテナント構成の場合は、Oracle Multitenantオプションが必要ありません。
【12cを使用する上での留意事項】
非CDB構成(マルチテナント構成ではない従来型のシングル環境)は現時点では使用できますが、将来のバージョンでは使用できなくなる可能性があるため、CDB構成への移行を検討する必要があります。また12c R2からは、これから説明するPDBのリソース制御、PDBのクローン・移行に関する新機能が追加されたことにより、MTAはさらに実用的な統合機能になってきていると考えています。ただし、現時点ではCDB構成では使用できない機能がありますので、その点に留意する必要があるでしょう。 詳細は、以下のマニュアルをご確認ください。
- ✓ Oracle® Databaseアップグレード・ガイド 12cリリース1 (12.1)
「8.1.1 非CDBアーキテクチャの非推奨」
- ✓ Oracle® Database Readme 12cリリース2 (12.2)
「Oracle Database 12cリリース2 (12.2)のマルチテナント・コンテナ・データベースで使用できないか、または制限されている機能」
2. 従来のPDBリソース制御の課題
MTAを用いたデータベースの統合では、より多くのPDBを1つのCDBに統合し、管理コスト、ハードウェアコストを削減することが望ましいと考えられます。ただし、多くのPDBを統合する場合、それぞれのPDBに対して適切にリソース制御を行うことが重要になってきます。たとえば、特定のPDBで大量のリソースが必要な処理が実行された場合でも、ほかのPDBに大きな影響を与えないよう、各PDBのリソース使用量を制御できなければなりません。
12c R1ではリソースマネージャを利用することで、各PDBに対して割り当てるCPU使用率、パラレル実行サーバー数を制御することが可能でした。しかし、メモリサイズ、I/O量など一部のリソースについてはリソース使用量を制御する機能がない、などの課題がありました。この章では、MTA環境における12c R1のPDBリソース制御機能のおさらいをしながら、12c R2新機能によって解決された点について説明してゆきます。
2.1 12c R1で制御できるリソースの種類
12c R1では、PDBごとのCPU、パラレル実行サーバー数のリソース制御が可能です。I/Oについては、Exadata環境でのみ設定可能です。
PDBリソースの種類 | 説明 |
---|---|
CPU | PDBごとにCPU使用率の配分と上限値を設定可能 |
パラレル実行サーバー数 | PDBごとにパラレル実行サーバー数の配分と上限値を設定可能 |
I/O | PDBごとにI/Oの優先度、最大I/O量などを設定可能 |
表1:12c R1で設定可能なリソース制御一覧
2.1.1 CPU
リソースマネージャを使用して、各PDBのCPU使用率の配分と上限値を設定することが可能です。CDBリソースプランディレクティブのsharesでCPU使用率の配分、utilization_limitでCPUの上限値が決まります。
例えば、同一CDB内にTEST1、TEST2というPDBが2つあり、CDB_PLANというCDBリソースプランがあるとします。TEST1にshares=1、TEST2にshares=2を設定した場合は1:2の配分で調整されるため、TEST1は33%、TEST2は66%を最低CPU使用率として使用できるということになります。また、TEST1にutilization_limit=60、TEST2にutilization_limit=90を設定した場合、TEST1は60%、TEST2は90%を最大CPU使用率として使用できるということになります(図2)。
【図2:12c R1におけるリソース制御の設定例(CPU)】
2.1.2 パラレル実行サーバー数
リソースマネージャを使用して、各PDBで使用できるパラレル実行サーバー数の配分と上限値を設定することが可能です。CPU使用率と同様にCDBリソースプランディレクティブのsharesでパラレル実行サーバー数の配分が決まります。また、CDB初期化パラメータPARALLEL_SERVERS_TARGETの値をCDBリソースプランディレクティブのparallel_server_limitで乗算した値が上限値となります。先程の例で挙げたMTA環境に対して、TEST1にshares=1、TEST2にshares=2を設定、そして、CDBの初期化パラメータとしてPARALLEL_SERVERS_TARGET=200を設定したとします。そうした場合、1:2の配分で調整されるため、少なくともTEST1では67(≒200*1/3)、TEST2では133(≒200*2/3)のパラレル実行サーバーが起動できるということになります。加えて、TEST1にparallel_server_limit=50、TEST2にparallel_server_limit=80を設定した場合は、TEST1では最大100(=200*50%)、TEST2では最大160(=200*80%)のパラレル実行サーバーを起動できるということになります(図3)。
【図3:12c R1におけるリソース制御の設定例(パラレル実行サーバー数)】
2.1.3 I/O(Exadata環境のみ使用可)
I/Oリソースマネージャ(以下 IORM)を使用して、各PDBでI/Oの優先度、最大I/O量を設定することが可能です。ただし、IORMはExadata環境のみで使用できる機能であり、非Exadata環境では、使用することはできません。今回は、I/Oリソースマネージャについての説明は割愛します。
2.2 12c R1 PDBリソース制御の問題点
非Exadata環境を前提にすると、12c R1ではCPUやパラレル実行サーバー数のリソース制御のみが可能で、メモリやI/Oといった、それ以外のリソースは制御することができませんでした。そのため、あるPDBが大量のメモリを使用したり、I/Oを発生させると、ほかのPDBの処理パフォーマンスに影響を与えてしまう問題がありました。
また、Oracle Database単体では、GUIでリソースマネージャを使用できないことも気になる点です。もちろん、PL/SQLでリソースマネージャを使用することはできます。使ってみるとわかりますが、かなり煩雑な手順になっており、手軽に使用できるものでありません。しかし、GUIでリソースマネージャを使用したい場合は、別途Enterprise Manager Cloud Control(EMCC)を導入する必要がありました。EMCCはOracle Databaseとは別の製品であり、導入作業が必要です。
2.3 12c R2 PDBリソース制御による問題点の解決
2.3.1 制御できるPDBリソースの拡張
12c R2では、制御できるPDBリソースの種類や設定手段が増え、より適切にリソース制御ができるようになっています。詳細については、次章で詳しく説明してゆきます。
2.3.2 Enterprise Manager Database Expressのリソースマネージャサポート開始
12c R2からEnterprise Manager Database Express(EMEX)でリソースマネージャ機能がサポートされ、Oracle Database単体でGUIを用いてリソースマネージャを使えるようになりました。EMEXは12c R1からOracle Databaseに同梱されたGUIベースのデータベース管理ツールです。12c R1ではEMEXでリソースマネージャ機能を使えませんでしたが、12c R2からは可能です。そのため、GUIを用いてリソースマネージャを使うためにEMCCを導入する必要がなくなりました。
3. 12c R2でのPDBリソース制御
12c R1では、PDBを対象にするリソース制御において制御可能なものはCPU使用率とパラレル実行サーバー数だけでしたが、12c R2では、制御できるPDBリソースの種類が増えています。また、PDBレベルの初期化パラメータを使って、簡単な設定方法も追加されています。
PDBリソースの種類 | 設定手段 | DBバージョン | |
---|---|---|---|
12c R1 | 12c R2 | ||
CPU | リソースマネージャを使用した制御 | ○ | ○ |
PDBレベルのCPU関連初期化パラメータを使用した制御 NEW!! | × | ○ | |
パラレル実行サーバー数 | リソースマネージャを使用した制御 | ○ | ○ |
メモリ | PDBレベルのメモリ関連初期化パラメータを使用した制御 NEW!! | × | ○ |
I/O | I/Oリソースマネージャを使用した制御(Exadata環境のみ) | ○ | ○ |
PDBレベルのI/O関連初期化パラメータを使用した制御 NEW!! | × | ○ |
表2:12c R1と12c R2におけるPDBリソース制御の比較
3.1 PDBメモリ関連リソース制御
メモリ関連の初期化パラメータを使用することでSGAやPGA、各SGAメモリコンポーネントに関しての上限値、下限値を設定できるようになりました。メモリの上限値を設定しておくことで1つのPDBがメモリを占有してしまうのを防いだり、メモリの下限値を設定したりしておくことで、他のPDBがメモリを大量に使用している場合でも一定のメモリを特定のPDBに割り当てておくことができるようになりました。
以下に、PDB単位で設定可能になったメモリ関連の初期化パラメータを記載します。
PDB初期化パラメータ(メモリ関連) | 説明 |
---|---|
SGA_TARGET | PDBが利用できるSGAの最大サイズを指定 |
SGA_MIN_SIZE | PDBで保証されるSGAの最小サイズを指定 |
DB_CACHE_SIZE | PDBで保証されるバッファ・キャッシュの最小サイズを指定 |
SHARED_POOL_SIZE | PDBで保証される共有プールの最小サイズを指定 |
PGA_AGGREGATE_TARGET | PDBが利用できるPGAの目標サイズを指定 |
PGA_AGGREGATE_LIMIT | PDBが利用できるPGAの最大サイズを指定 |
表3:PDBで設定可能なメモリ関連初期化パラメータ一覧
【図4:PDBのSGA管理例】
3.2 PDB I/O関連リソース制御
I/O関連の初期化パラメータを使用することで、1秒あたりのI/Oリクエスト数や転送量の上限値を設定できるようになりました。これにより、ある特定のPDBで大量にI/Oリソースを使用する状況を防ぐことができます。
以下に、PDB単位で設定可能になったI/O関連の初期化パラメータを記載します。
PDB初期化パラメータ(I/O関連) | 説明 |
---|---|
MAX_IOPS | PDBごとの1秒当たりの最大I/Oリクエスト数を指定 |
MAX_MBPS | PDBごとの1秒当たりの最大I/O転送量(Mbytes)を指定 |
表4:PDBで設定可能なI/O関連初期化パラメータ一覧
MAX_IOPS・MAX_MBPS初期化パラメータは、非Exadata環境において使用できます。ただし、Exadata環境においては、I/Oリソースマネージャを使用してください。Exadata環境ではこれらの初期化パラメータは使用できません。
3.3 CPUのリソース制御機能も拡張された
PDBに対して、初期化パラメータCPU_COUNTを設定することで、PDBごとにCPU使用率の上限値を設定できるようになりました。CPU_COUNTには、PDBで使用したいCPU数を指定します。例として、CDBにCPU数が10割り当てられている状態(CDBのCPU_COUNTは10)で、PDBに対してCPU_COUNT=7を指定した場合は、PDBでは、最大7つのCPUを使える(最大CPU使用率70%)ということになります(図5)。
【図5:12c R2におけるリソース制御の設定例(CPU)】
初期化パラメータCPU_COUNTは、従来から存在するパラメータです。ただし、12c R1以前では、CPU_COUNTを設定できるのは、CDBまたは非CDBのインスタンスだけであり、PDBに設定することはできませんでした。12c R2からは、CPU_COUNTをPDBに設定できるようになっています。
なお、「2.1. 12c R1で制御できるリソースの種類」で説明したCDBリソースプランディレクティブshares、utilization_limitを使っても、PDB単位でCPU使用率のリソース制御を行うことができます。CPU_COUNTを使う方法は、設定のシンプルさ・明解さが利点ですので、シンプルな設定・構成ではCPU_COUNTを使用してPDB単位のリソース制御を行い、複雑な設定・構成では、CDBリソースプランディレクティブshares、utilization_limitを使うことをお勧めします。
4. 12c R2 PDBリソース制御機能の使い方をチェック
では、12c R2で使用可能になったCPU、メモリ、I/Oのリソース制御の動作を確認してみましょう。リソース制御動作の確認には、EMEXや12c R2から新しく登場したV$RSRCPDBMETRIC_HISTORYビューを使います。
4.1 PDBで初期化パラメータCPU_COUNTを設定してみる
PDBに対してCPU_COUNTを設定することで、設定値以上のCPUが使用されないようになることを確認します。
初期化パラメータCPU_COUNTは、特定のPDBがCPUを想定以上に使用することにより、他のPDBの処理に影響を与えないようにしたい場合などに設定を検討します。以下の手順を行うことで設定可能です。
- CDBリソースプランの設定
- PDBにCPU_COUNTを設定
4.1.1 設定例
PDB1にCPU_COUNT=1を設定した場合の例を以下に記載します。
SQL> --★CDB$ROOTへの接続
SQL> ALTER SESSION SET CONTAINER=CDB$ROOT;
Session altered.
SQL>
SQL> SHOW CON_NAME
CON_NAME
------------------------------
CDB$ROOT
SQL> --★CDBリソースプランの設定
SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='DEFAULT_CDB_PLAN' SCOPE=BOTH;
System altered.
SQL> --★PDB1への接続
SQL> ALTER SESSION SET CONTAINER=PDB1;
Session altered.
SQL> SHOW CON_NAME
CON_NAME
------------------------------
PDB1
SQL>
SQL> SHOW PARAMETER CPU_COUNT
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
cpu_count integer 3
SQL>
SQL> --★CPU_COUNTの設定
SQL> ALTER SYSTEM SET CPU_COUNT = 1 SCOPE=BOTH;
System altered.
SQL>
SQL> SHOW PARAMETER CPU_COUNT
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
cpu_count integer 1
4.1.2 CPU使用状況を確認する
今回は、CDBのCPUは全部で3つ、かつPDB1にCPU_COUNT=1が設定されているという状態で、CPUの使用状況を確認します。
CPUの使用状況は、12c R2から新しく登場したV$RSRCPDBMETRIC_HISTORYビュー(または V$RSRCPDBMETRIC)のCPU_UTILIZATION_LIMIT列とAVG_CPU_UTILIZATION列から確認が可能です。CPU_UTILIZATION_LIMIT列は、PDBで使用できるCPU使用率を表し、AVG_CPU_UTILIZATION列は、実際に使用されているCPUの割合を表しています。
CDBのCPUは全部で3つ、かつPDBにCPU_COUNT=1が設定されているため、CPU_UTILIZATION_LIMIT列は33.33(≒1/3*100)%となっています。AVG_CPU_UTILIZATION列を確認すると、PDB1のCPU使用率はCPU_UTILIZATION_LIMIT列の値以上にCPUが使用されないようにOracle Databaseによって制御されていることが確認できます。
SQL> COLUMN PDB_NAME FORMAT A10
SQL> ALTER SESSION SET NLS_DATE_FORMAT='yyyy-mm-dd hh24:mi:ss';
Session altered.
SQL> SELECT r.BEGIN_TIME, r.END_TIME,r.CON_ID, p.PDB_NAME, r.CPU_UTILIZATION_LIMIT, r.AVG_CPU_UTILIZATION
2 FROM V$RSRCPDBMETRIC_HISTORY r, CDB_PDBS p
3 WHERE r.CON_ID = p.CON_ID AND p.PDB_NAME='PDB1'
4 ORDER BY BEGIN_TIME;
BEGIN_TIME END_TIME CON_ID PDB_NAME CPU_UTILIZATION_LIMIT AVG_CPU_UTILIZATION
------------------- ------------------- ---------- ---------- --------------------- -------------------
2017-04-16 13:44:17 2017-04-16 13:45:17 3 PDB1 33.33 .009955202
2017-04-16 13:45:17 2017-04-16 13:46:16 3 PDB1 33.33 0
2017-04-16 13:46:16 2017-04-16 13:47:17 3 PDB1 33.33 5.83153944
2017-04-16 13:47:17 2017-04-16 13:48:17 3 PDB1 33.33 33.0302023
2017-04-16 13:48:17 2017-04-16 13:49:17 3 PDB1 33.33 33.4769828
2017-04-16 13:49:17 2017-04-16 13:50:17 3 PDB1 33.33 32.9406545
2017-04-16 13:50:17 2017-04-16 13:51:17 3 PDB1 33.33 33.1317495
2017-04-16 13:51:17 2017-04-16 13:52:16 3 PDB1 33.33 32.9918287
2017-04-16 13:52:16 2017-04-16 13:53:17 3 PDB1 33.33 32.8125173
2017-04-16 13:53:17 2017-04-16 13:54:17 3 PDB1 33.33 33.0701025
2017-04-16 13:54:17 2017-04-16 13:55:17 3 PDB1 33.33 33.1720162
2017-04-16 13:55:17 2017-04-16 13:56:17 3 PDB1 33.33 32.7483242
2017-04-16 13:56:17 2017-04-16 13:57:17 3 PDB1 33.33 33.1359831
2017-04-16 13:57:17 2017-04-16 13:58:16 3 PDB1 33.33 33.1315522
2017-04-16 13:58:16 2017-04-16 13:59:17 3 PDB1 33.33 33.1925741
15 rows selected.
【図6:V$RSRCPDBMETRIC_HISTORYによるCPU使用率の推移】
また、CPU_COUNT以上のCPUを使用しようとした場合は、待機イベント"resmgr:cpu quantum"が発生します。EMEXからCPU_COUNTで設定した値以上にCPUが使用されないように制限されていることが確認できます。
【図7:EMEXパフォーマンス・ハブ画面例-CPU_COUNT未設定時】
【図8:EMEXパフォーマンス・ハブ画面例-CPU_COUNT=1設定時】
4.2 PDBで初期化パラメータMAX_MBPSを設定してみる
PDBに対してMAX_MBPSを設定することで、設定値以上のI/O転送が行われないようになることを確認します。
初期化パラメータMAX_MBPSやMAX_IOPSは、複数のPDBのデータファイルやREDOログファイルなどの管理ファイルが1つのディスクで管理されている場合などに設定を検討します。各PDBがそれぞれ異なるディスクを使用している場合は、I/O競合は発生しない状況になるため、この初期化パラメータの使用を検討する必要はありません。PDBに接続後、ALTER SYSTEM文を実行することで設定が可能です。
4.2.1 設定例
PDB1にMAX_MBPS=1を設定した場合の例を以下に記載します。
SQL> --★PDB1への接続
SQL> ALTER SESSION SET CONTAINER=PDB1;
Session altered.
SQL> SHOW CON_NAME
CON_NAME
------------------------------
PDB1
SQL>
SQL> SHOW PARAMETER MAX_MBPS
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
max_mbps integer 0
SQL>
SQL> --★MAX_MBPSの設定
SQL> ALTER SYSTEM SET MAX_MBPS = 1 SCOPE=BOTH;
System altered.
SQL>
SQL> SHOW PARAMETER CPU_COUNT
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
max_mbps integer 1
4.2.2 1秒あたりのI/O転送量を確認する
1秒当たりのI/O転送量については、V$RSRCPDBMETRIC_HISTORYビュー(または V$RSRCPDBMETRIC)のIOMBPS列から確認が可能です。1秒当たりのI/O操作数については、IOPS列で確認できます。
以下は、実際にMAX_MBPS=1が設定されている場合にI/Oが多い処理を実行した際のV$RSRCPDBMETRIC_HISTORYの情報です。MAX_MBPS=1を設定した場合は、1秒当たりのI/O転送量は1Mbyteが上限として設定されるため、V$RSRCPDBMETRIC_HISTORYのIOMBPS列からは、1Mbyte以上にI/O転送量が増えないようにOracle Databaseによって制御されていることが確認できます。
SQL> COLUMN PDB_NAME FORMAT A10
SQL> ALTER SESSION SET NLS_DATE_FORMAT='yyyy-mm-dd hh24:mi:ss';
Session altered.
SQL> SELECT r.BEGIN_TIME, r.END_TIME, r.CON_ID, p.PDB_NAME, r.IOMBPS
2 FROM V$RSRCPDBMETRIC_HISTORY r, CDB_PDBS p
3 WHERE r.CON_ID = p.CON_ID AND p.PDB_NAME='PDB1'
4 ORDER BY BEGIN_TIME;
BEGIN_TIME END_TIME CON_ID PDB_NAME IOMBPS
------------------- ------------------- ---------- ---------- ----------
2017-04-16 15:19:16 2017-04-16 15:20:16 3 PDB1 .202736949
2017-04-16 15:20:16 2017-04-16 15:21:17 3 PDB1 .629660315
2017-04-16 15:21:17 2017-04-16 15:22:17 3 PDB1 1.02717031
2017-04-16 15:22:17 2017-04-16 15:23:17 3 PDB1 .996181305
2017-04-16 15:23:17 2017-04-16 15:24:16 3 PDB1 .980889565
2017-04-16 15:24:16 2017-04-16 15:25:17 3 PDB1 1.00759828
2017-04-16 15:25:17 2017-04-16 15:26:17 3 PDB1 1.01077051
2017-04-16 15:26:17 2017-04-16 15:27:16 3 PDB1 1.02953586
2017-04-16 15:27:16 2017-04-16 15:28:17 3 PDB1 .960582974
2017-04-16 15:28:17 2017-04-16 15:29:17 3 PDB1 1.01010101
2017-04-16 15:29:17 2017-04-16 15:30:17 3 PDB1 1.02572726
2017-04-16 15:30:17 2017-04-16 15:31:17 3 PDB1 .963615218
2017-04-16 15:31:17 2017-04-16 15:32:17 3 PDB1 1.01194426
2017-04-16 15:32:17 2017-04-16 15:33:16 3 PDB1 .980889565
2017-04-16 15:33:16 2017-04-16 15:34:17 3 PDB1 1.00759828
15 rows selected.
【図9:V$RSRCPDBMETRIC_HISTORYによる1秒あたりのI/O転送量の推移】
MAX_IOPSまたはMAX_MBPSで設定した値以上のI/O要求があった場合には、待機イベント”resmgr:io rate limit”が発生します。
【図10:EMEXパフォーマンス・ハブ画面例-MAX_IOPS未設定時】
【図11:EMEXパフォーマンス・ハブ画面例-MAX_IOPS=1設定時】
4.3 PDBで初期化パラメータSGA_TARGETを設定してみる
PDBに対してSGA_TARGETを設定することで、設定値以上のSGAが使用されないようになることを確認します。
メモリ関連初期化パラメータは、特定のPDBでメモリを占有してしまうような処理が実行される状況でも、他のPDBの処理に影響を与えないようにしたい場合などに設定を検討します。PDBに接続後、ALTER SYSTEM文を実行することで設定が可能です。
4.3.1 設定例
PDB1にSGA_TARGET=150Mを設定した場合の例を以下に記載します。
SQL> --★PDB1への接続
SQL> ALTER SESSION SET CONTAINER=PDB1;
Session altered.
SQL> SHOW CON_NAME
CON_NAME
------------------------------
PDB1
SQL>
SQL> SHOW PARAMETER SGA_TARGET
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sga_target big integer 0
SQL>
SQL> --★SGA_TARGETの設定
SQL> ALTER SYSTEM SET SGA_TARGET = 150M SCOPE=BOTH;
System altered.
SQL>
SQL> SHOW PARAMETER SGA_TARGET
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sga_target big integer 150M
4.3.2 SGA使用状況を確認する
SGAの使用状況については、V$RSRCPDBMETRIC_HISTORYビュー(または V$RSRCPDBMETRIC)のSGA_BYTES列から確認が可能です。なお、V$RSRCPDBMETRIC_HISTORYビューからは、SGAの使用状況以外にも、PGAやバッファ・キャッシュ、共有プールの使用状況についても確認が可能です。
以下は、実際にSGA_TARGET=150Mが設定されている場合にSGAを使用する処理を実行した際のV$RSRCPDBMETRIC_HISTORYの情報です。SGA_TARGET=150Mを設定した場合は、SGAの使用量は150Mが上限として設定されるため、V$RSRCPDBMETRIC_HISTORYのSGA_BYTES列からは、SGAの使用量が150M以上にならないようにOracle Databaseによって制御されていることが確認できます。
SQL> SELECT r.BEGIN_TIME, r.END_TIME, r.CON_ID, p.PDB_NAME, r.SGA_BYTES
2 FROM V$RSRCPDBMETRIC_HISTORY r, CDB_PDBS p
3 WHERE r.CON_ID = p.CON_ID AND p.PDB_NAME='PDB1'
4 ORDER BY BEGIN_TIME;
BEGIN_TIME END_TIME CON_ID PDB_NAME SGA_BYTES
------------------- ------------------- ---------- ---------- ----------
2017-04-15 16:51:39 2017-04-15 16:52:39 3 PDB1 72614234
2017-04-15 16:52:39 2017-04-15 16:53:39 3 PDB1 89651059
2017-04-15 16:53:39 2017-04-15 16:54:39 3 PDB1 129799858
2017-04-15 16:54:39 2017-04-15 16:55:39 3 PDB1 132168184
2017-04-15 16:55:39 2017-04-15 16:56:39 3 PDB1 136384498
2017-04-15 16:56:39 2017-04-15 16:57:39 3 PDB1 139352630
2017-04-15 16:57:39 2017-04-15 16:58:39 3 PDB1 147815716
2017-04-15 16:58:39 2017-04-15 16:59:39 3 PDB1 152257309
2017-04-15 16:59:39 2017-04-15 17:00:39 3 PDB1 149874601
2017-04-15 17:00:39 2017-04-15 17:01:39 3 PDB1 150278868
2017-04-15 17:01:39 2017-04-15 17:02:39 3 PDB1 151063762
2017-04-15 17:02:39 2017-04-15 17:03:39 3 PDB1 150919867
2017-04-15 17:03:39 2017-04-15 17:04:39 3 PDB1 151754836
2017-04-15 17:04:39 2017-04-15 17:05:39 3 PDB1 151860898
2017-04-15 17:05:39 2017-04-15 17:06:39 3 PDB1 153424379
15 rows selected.
【図12:V$RSRCPDBMETRIC_HISTORYによるSGA使用状況の推移】
メモリ使用量が設定した上限値を超えた場合、特定の待機イベント発生は確認できませんでした。
5. まとめ
12c R2の新機能として各PDBに対して、CPUだけでなく、メモリやI/Oに対して上限値や下限値を設定できる初期化パラメータが導入されました。このことによって、12c R1まで解決できなかったPDB間のメモリやI/Oのリソース競合に対して、柔軟に対応できるようになりました。加えて、12c R2においてEMEXでリソースマネージャが使用できるようになったことにより、手軽にリソース制御を行えるようになりました。
ただし、これらの初期化パラメータの具体的な推奨値はありませんので、システムの特性を把握した上で設計や十分な検証を行っていく必要が出てくるでしょう。