お久しぶりです！

お久しぶりです。以前、DBデータの論理削除の記事を執筆させて頂きました。
今回は、マルチテナントに関連する、ロックダウン・プロファイルの機能
について、ご紹介したいと思います。

---

参考
◆DBデータの論理削除（というOracle Databaseではやや珍しい機能）
右のカテゴリメニュー[Oracle Database 管理] > VLDBとパーティショニング > [すぐに使える！DBデータの論理削除](連載)

◆マルチテナントの概要
右のカテゴリメニュー[Oracle Database 管理] > [マルチテナント] ＃当社プラチナホルダー執筆記事

をぜひご覧ください。

 

そのPDB、周りに迷惑をかけていませんか？

12cR1よりリリースされたマルチテナント・アーキテクチャは、簡単に言うと、
「データベース(CDB)の中に、複数のデータベース(PDB)を作成することができる」機能です。

そのため、CDBのなかでは、PDBがCDBのリソースを分け合って使用することになります。

マルチテナント・アーキテクチャは、しばしばアパートやマンションに例えられます。
建物自体や廊下、エントランスなどの共有部分は利用者全員で共有しつつ、利用者ごとにプライベートな部屋を持ち、各利用者の部屋は他の利用者には公開されません。
メンテナンスなども自分の部屋だけで良く、共有部分は共有部分の管理者(マルチテナントでいえば、インフラ基盤やCDB管理担当者)が管理を行ってくれます。

ところが、マルチテナントの共有のリソースを分け合って利用する、という特徴は、各利用者が共通のルールを守ることができる、という前提が必要になります。

先ほどのアパートやマンションの例で、たとえば共有部分のはずの廊下やエントランスに勝手に家具や荷物を置いてしまうような入居者がいると、リソースの共有は成り立たなくなってしまいます。マルチテナントも同様で、たとえばCDBのCPUを一つのPDBが100%占有してしまったり、業務データが多過ぎて、一つのPDBでディスク容量を使い切ってしまうと、ほかのPDBはDBとして成り立たなくなってしまいます。
　

　

 

マルチテナント機能には、各PDBの利用者が、自分たちがリソースを使いすぎている「迷惑なPDB」になっていないかを意識しなくても良いよう、PDBのリソース変更や、利用可能な容量の上限を設定する機能が用意されています。

この機能を「PDBロックダウン・プロファイル」といい
禁止された操作を実行しようとすると、権限不足のエラーを返し処理を失敗させることができます。

詳細な動作は次回ご紹介させていただくとして、今回は簡単に処理が禁止されている様子を見てみましょう。

---

今回、ORCLというDB名のCDBに、PDBORCLとPDBORCL2の2つのPDBを作成しました。
　

$ sqlplus / as sysdba

SQL*Plus: Release 18.0.0.0.0 - Production on 土 11月 24 17:35:00 2018

Version 18.3.0.0.0

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

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

Version 18.3.0.0.0

に接続されました。

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED

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

         2 PDB$SEED                       READ ONLY  NO

         3 PDBORCL                        READ WRITE NO

         4 PDBORCL2                       READ WRITE NO

SQL>

　
それでは、各PDBのDBインスタンスで使用するメモリを制限するパラメータの一つ、SGA_TARGETの値を確認し、とりあえずPDBORCLでSGA_TARGETの値を変更してみます。
　

SQL> show parameter SGA_TARGET;

NAME                                 TYPE        VALUE

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

sga_target                           big integer 600M

SQL> alter session set container=PDBORCL2;

セッションが変更されました。

SQL> show parameter SGA_TARGET;

NAME                                 TYPE        VALUE

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

sga_target                           big integer 600M

SQL> alter session set container=PDBORCL;

セッションが変更されました。

-- PDBORCLのSGA_TARGETを650Mに変更
SQL> alter system set sga_target=650M container=current scope=both;

システムが変更されました。

-- PDBORCLのSGA_TARGETが変更されていることを確認
SQL> show parameter sga_target

NAME                                 TYPE        VALUE

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

sga_target                           big integer 650M

SQL> alter session set container=PDBORCL2;

セッションが変更されました。

SQL> show parameter SGA_TARGET;

NAME                                 TYPE        VALUE

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

sga_target                           big integer 600M

SQL>

　
問題なくPDBORCLのSGA_TARGETを50MB増加できました。
このような変更を各PDB利用者が自由に実行しては、CDB全体のメモリがすぐに枯渇し、ほかのPDBがリソース不足になってしまいます。

それを防ぐため、変更ができないようにしてみます。
設定はCDBから行います。
　

SQL> show con_name




CON_NAME

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

CDB$ROOT

-- pdb_lockdownに事前に設定しておいたtest_profileを設定
SQL> alter system set pdb_lockdown=test_profile scope=both;

システムが変更されました。

-- pdb_lockdownにtest_profileが設定されていることを確認
SQL> show parameter lockdown;

NAME                                 TYPE        VALUE

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

pdb_lockdown                         string      TEST_PROFILE

SQL> alter session set container=PDBORCL;

セッションが変更されました。

-- pdb_lockdownにtest_profileが設定されていることを確認
SQL> show parameter lockdown;

NAME                                 TYPE        VALUE

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

pdb_lockdown                         string      TEST_PROFILE

SQL> alter session set container=PDBORCL2;

セッションが変更されました。

-- pdb_lockdownにtest_profileが設定されていることを確認
SQL> show parameter lockdown;

NAME                                 TYPE        VALUE

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

pdb_lockdown                         string      TEST_PROFILE

SQL>

　
事前に設定しておいたTEST_PROFILEという設定が有効化され、CDBで変更した設定が各PDBに伝播していることがわかります。

プロファイルについては次回以降、詳しくご紹介しますのでお楽しみに！

それでは、PDBORCL2でSGA_TARGETを増やしてみましょう。
　

SQL> show con_name;

CON_NAME

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

PDBORCL2

SQL>

-- 権限不足でSGA_TARGETの変更が出来ない
SQL> alter system set sga_target=650M container=current scope=both;

alter system set sga_target=650M container=current scope=both

*

行1でエラーが発生しました。:

ORA-01031: 権限が不足しています

SQL>　 show parameter sga_target;

NAME                                 TYPE        VALUE

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

sga_target                           big integer 600M

SQL>

　
SGA_TARGETの変更に失敗しました。
このように、PDB側での特定の操作を禁止させ、強制的にリソース共有のルールを守らせる機能が、
PDBロックダウン・プロファイルです。

次回はロックダウン・プロファイルの有効化/無効化方法について紹介！

一回で全て紹介しようとすると長くなってしまうため、具体的な設定方法は次回以降、紹介していきたいと思います。

昨今、インフラ基盤の性能向上により、DBの統合やクラウド化を考える機会は増えてきたかと思います。
DBの統合の際、管理コストを大幅に減少させることが可能なマルチテナントは、積極的に採用していきたい機能ですが、冒頭で述べたようなリソースの取り合いはしばしば議論に上ってくる問題かと思います。

本機能であれば、監査機能でリソース変更を監視し、検知したらアラートを上げ、変更を元に戻し…といった運用から解放されます！

DB統合の際は、ぜひ一度ご検討いただければと思います。

投稿者プロフィール

技術チーム

DBひとりでできるもんを盛り上げるべく、技術チームが立ち上がり早6年。ひとりでできるもんと言いつつ、技術者が読んでプッとなるような、極めてピンポイントでマニアックな技術ネタを執筆しています！

• Oracle Cloud2024年11月21日コネクタ・ハブを利用してOCIのログイン通知を行う
• Dbvisit Standby2024年11月20日【Dbvisit Standby】チュートリアル_再同期（スタンバイDBとの同期復旧）
• Dbvisit Standby2024年11月19日【Dbvisit Standby】チュートリアル_Standbyフェイルオーバーテスト
• Dbvisit Standby2024年11月12日【Dbvisit Standby】チュートリアル_自動同期の有効化/無効化