Oracle 12C 中CDB和PDB的引數檔案管理

lhrbest發表於2018-08-31

Oracle 12C 中CDB和PDB的引數檔案管理



 

每個 CDB 有一個 SPFILE 用於儲存引數。引數值與根相關聯,應用於根,並且可用作所有其他容器的預設值。可以在 PDB 中為引數設定不同的值,前提是 V$PARAMETER 中的列 ISPDB_MODIFIABLE TRUE 。這些值全部在 PDB 作用域內設定,在 PDB 關閉再開啟後以及在 CDB 例項關閉又啟動後都會相應地保留。執行克隆和移走 / 插入操作後,也會保留。其他初始化引數只能針對根設定。

SQL> select PDB_UID, NAME, VALUE$ from pdb_spfile$;

PDB_UID NAME VALUE$

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

3100074415 optimizer_use_sql_plan_baselines FALSE

2862146267 optimizer_use_sql_plan_baselines FALSE

2862146267 ddl_lock_timeout 10

 

PDB 的引數儲存在 CDB PDB_SPFILE$ 字典表中以 con_id 區別,所以, PDB PDB_SPFILE$ 表是空的。

col NAME  format a25

col value$  format a30

select  a.pdb_uid ,  b.NAME ,  a.name ,  a.value$

   from  pdb_spfile$ a ,  v$pdbs b

  where  a.pdb_uid =  b.CON_UID

order by b.NAME ;

 

SELECT * FROM V$SYSTEM_PARAMETER d where d.NAME='db_create_file_dest';

SELECT * FROM  cdb_tables d where d.TABLE_NAME='PDB_SPFILE$';

 

http://blog.itpub.net/26736162/viewspace-2213348/

 

修改 PDB 中的初始化引數,事實:

PDB 從根 CDB 繼承引數值,除非它們在 PDB 級別被重寫。

普通的 ALTER   System ”命令用於修改 PDB 級別的引數,但永續性機制不同。

PDB 級別的初始化引數不是儲存在 SPFILE 中,而是儲存在 C DB 的資料字典 PDB_SPFILE$ 內部表中。

對於整個 CDB 及其所有 PDBs ,只有一個 物理 spfile 。開啟根 CDB 時讀取此 spfile

PDB spfile 等價的是 CDB PDB_SPFILE$ 表。

每個容器都有一個 PDB_SPFILE$ (CDB$root 和所有 PDB) 。但是,只有 CDB PDB_SPFILE$ 表包含為 PDB 專門設定的引數。

只要根的 CDB 是開啟的, PDBs 中的 SPFILE 總是被啟用的。即使 CDB 不使用 SPFILE Oracle 也允許 PDB 使用 SPFILE ,因為 PDB 沒有任何其他方法用於持久引數 (PDB 不支援 Pfile init.ora 檔案 )

PDB 中只能在本地修改整個 Oracle DB 初始化引數的一個子集。使用 V$PARAMETER.ISPDB_AUDIBE= YES ’查詢這些引數。

PDB 級別的引數在資料庫重新啟動的過程中持續存在,在拔出 / 外掛甚至克隆操作中也是如此。

根的 PDB_SPFILE$ 表是內部查詢的,在開啟可插拔資料庫 / 例項時會相應地設定引數。

當以特權使用者的身份連線到根容器 DB 時,預設情況下,任何 ALTER   System 命令都只指向根容器。

傳統的檢視 SPFILE 甚至警報日誌的方法只對 CDB 資料庫有用。這是因為 CDB 是控制 CDB PDB 之間共享的許多項的根級別。

要檢視 CDB 和所有 PDB 的引數 (PDB$SEED 除外 ) ,可以查詢 V$System_Parameter 。但是,除非安裝了 bug#20700587 的修復程式,否則不會列出隱藏引數或下劃線引數。

V$SPPARAMETER 檢視也可以被查詢以在從 PDB 內部查詢時顯示 PDB SPFILE 引數。

在非 CDB 中, V$SPPARAMETER 檢視讀取 spfile 並將引數顯示為查詢結果。 CDB 中的相同檢視讀取根中的 PDB_SPFILE$ 表,並在 PDB 中顯示 PDB SPFILE 引數。

為了在 PDB 級別修改引數,您需要連線到要對其進行修改的 PDB 容器。如果在根容器中連線,引數修改將對整個 CDB 進行。

每次開啟 PDB 時,如果特定的 PDB 對於某些 init 引數有自己的值,那麼 CDB SPFILE 的值將被 PDB_SPFILE$ 的值覆蓋。

可以為根 CDB DB 設定所有初始化引數。對於沒有為 PDB 顯式設定的任何初始化引數, PDB 繼承根的引數值。

就像正常的初始化引數一樣,有些下劃線引數不能在系統級別修改,或者不能在 PDB 級別上修改,或者引數 - 隱藏的或不隱藏的 - 需要在所有 RAC 例項中具有相同的值。

每個 PDB 中的 PDB_SPFILE$ 表都是截斷 / 空的,每個 PDB 的所有初始化引數都儲存在根的 PDB_SPFILE$ 表中。

PDB 插入到新的 CDB 中時,引數及其值將被恢復。

當一個 PDB 被拔出時,它自己的初始化引數也會被複制到 PDB 自己的 PDB_SPFILE$ 表中,這樣做是為了防止 XML 丟失。

PDB 插入到 CDB 並匯入其所有引數後,本地 PDB PDB_SPFILE$ 表將被截斷。

由於 PDB spfile 引數儲存在根 CDB 中的字典表中,所以“ ALTER   System   Reset ”命令只是從根中的 PDB_SPFILE$ 表中刪除 PDB 引數的行。這相當於從非 CDB 中的常規 spfile 中刪除引數。

當前不支援為常規的非多租戶資料庫重置記憶體中的引數,因此 PDB 也不支援這一點。

PDB 關閉時,用於設定 / 重置引數的 PDB Alter   System   Set/Reset. ’命令不能用作用域 = 記憶體執行。當讀取封閉 PDB 的引數時,我們需要提供引數的根值,因為 PDB 是從根繼承的。

 

 

 

 

在本例中, pdb2 中為 DDL_LOCK_TIMEOUT 引數設定了不同的值。 PDB 關閉再開啟後,更改的值會保留。 V$SYSTEM_PARAMETER 檢視中的新列 CON_ID 顯示每個容器(即根、 pdb1 pdb2 )中的 DDL_LOCK_TIMEOUT 值。





一、 Oracle12c多租戶CDB 與 PDB 引數檔案位置

CDB的引數檔案依然使用12c以前的SPIFLE,pdb的引數檔案不會出現在SPFILE中,而是直接從CDB中繼承,如果PDB中有privete Local parameter 會存在 CDB 的 PDB_SPFILE$字典表 中以con_id區別,當PDB UN-Plug時,PDB引數會寫入PDB的XML檔案中,當drop pluggable database後,pdb資訊和PDB_SPFILE$記錄也會被清除。再當PDB重新Plug-in到CDB時會重新載入回PDB, 但是由於一些PDB特殊引數在plug-in時會被遺棄。

實驗驗證:

SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT
SQL> show parameter spfile

NAME       TYPE   VALUE
------------------------------------ ----------- ------------------------------
spfile       string /home/oracle/app/oracle/produc
t/12.2.0/dbhome_1/dbs/spfilean
dycdb.ora
SQL> alter session set container=pdb01;

Session altered.

SQL> show parameter spfile

NAME       TYPE   VALUE
------------------------------------ ----------- ------------------------------
spfile       string /home/oracle/app/oracle/produc
t/12.2.0/dbhome_1/dbs/spfilean
dycdb.ora
到這一步驗證了:CDB的引數檔案依然使用12c以前的SPIFLE,pdb的引數檔案不會出現在SPFILE中,而是直接從CDB中繼承。

SQL> show parameter undo_retention

NAME       TYPE   VALUE
------------------------------------ ----------- ------------------------------
undo_retention       integer 900
SQL> alter system set undo_retention=901;

System altered.

SQL> show parameter undo_reten

NAME       TYPE   VALUE
------------------------------------ ----------- ------------------------------
undo_retention       integer 901

SQL> select pdb_uid,name,value$ from PDB_SPFILE$;

no rows selected
SQL> alter session set container=cdb$root;

Session altered.

SQL> select pdb_uid,name,value$ from PDB_SPFILE$;

   PDB_UID NAME      VALUE$
---------- ---------------------------------------- -------------------------
2550500229 undo_retention      901

SQL> select con_id,dbid,con_uid,guid from v$pdbs;

    CON_ID   DBID CON_UID GUID
---------- ---------- ---------- --------------------------------
2 2683777510 2683777510 4ECF66D93A6233B5E0531019640A6041
3 2550500229 2550500229 4ECF8621E3DA38EEE0531019640AA598

到這一步驗證了:如果PDB中有privete Local parameter 會存在 CDB 的 PDB_SPFILE$字典表 中以con_id區別

SQL>alter pluggable database pdb01 close immediate;
SQL>alter pluggable database pdb01 unplug into '/home/oracle/pdb01.xml';
[oracle@12c01 ~]$ pwd
/home/oracle
[oracle@12c01 ~]$ ll pdb01.xml 
-rw-r--r--. 1 oracle oinstall 7758 May  7 05:09 pdb01.xml
[oracle@12c01 ~]$ cat pdb01.xml 
<?xml version="1.0" encoding="UTF-8"?>
<PDB>
  <xmlversion>1</xmlversion>
  <pdbname>PDB01</pdbname>
  <cid>3</cid>
  <byteorder>1</byteorder>
  <vsn>203424000</vsn>
  <vsns>
    <vsnnum>12.2.0.1.0</vsnnum>
    <cdbcompt>12.2.0.0.0</cdbcompt>
    <pdbcompt>12.2.0.0.0</pdbcompt>
    <vsnlibnum>0.0.0.0.24</vsnlibnum>
    <vsnsql>24</vsnsql>
    <vsnbsv>8.0.0.0.0</vsnbsv>
  </vsns>
  <dbid>2550500229</dbid>
...省略
SQL> show pdbs   

    CON_ID CON_NAME    OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED    READ ONLY  NO
3 PDB01    MOUNTED
SQL> drop pluggable database pdb01 keep datafiles;

Pluggable database dropped.

SQL> show pdbs    

    CON_ID CON_NAME    OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED    READ ONLY  NO
SQL> select pdb_uid,name,value$ from PDB_SPFILE$;

no rows selected
到這一步驗證了:PDB un-plug後pdb parameter and spfile會先進xml檔案, 當drop pluggable database後,pdb資訊和PDB_SPFILE$記錄也會被清除。

SQL> create pluggable database pdb01 using '/home/oracle/pdb01.xml' nocopy;

SQL> show pdbs

    CON_ID CON_NAME    OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED    READ ONLY  NO
3 PDB01    MOUNTED
SQL> alter pluggable database pdb01 open;
Pluggable database altered.
SQL> select pdb_uid,name,value$ from PDB_SPFILE$;

   PDB_UID NAME      VALUE$
---------- ---------------------------------------- -------------------------
1196085469 undo_retention      901

到這一步驗證了:當PDB重新Plug-in到CDB時會重新載入回PDB, 但是由於一些PDB引數特殊原因在plug-in時會被遺棄。這裡因為沒有特殊引數,所以沒有丟失引數。

二、 CDB 與 PDB 不同值的相同引數

多租戶環境下,如果在設定引數時,cdb中設定CONTAINER=ALL,那麼PDB的引數也會繼承這個值,但可以通過ALTER SYSTEM在PDB container中修改 PDB local parameter,將覆蓋(優先)從CDB繼承的引數。有時候,我們有中需求,需要核實對比 PDB 中哪些引數與 CDB 不同。我們該怎麼辦,下面我們一起探討下。

例子: 查詢 名為 pdb01 的PDB 與 CDB 不同值的相同引數有哪些
1. 實驗環境檢視
SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT
SQL> show parameter undo_reten

NAME       TYPE   VALUE
------------------------------------ ----------- ------------------------------
undo_retention       integer 900
SQL> alter session set container=pdb01;
SQL> show parameter undo_reten

NAME       TYPE   VALUE
------------------------------------ ----------- ------------------------------
undo_retention       integer 901
2. 查詢 PDB 中哪些引數與 CDB 不同
SQL>  
set lin 300;
set pages 300;
col pdb_name for a30;
col parameter for a25;
col value$ for a20;
select v.dbid,v.name pdb_name,p.name parameter,p.value$
from pdb_spfile$ p,v$pdbs v
where p.pdb_uid=v.con_uid and v.name='PDB01' ;
      DBID PDB_NAME                       PARAMETER                 VALUE$
---------- ------------------------------ ------------------------- -------------
2550500229 PDB01                          undo_retention            901


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

在ORACLE 12C中引數檔案只是記錄了cdb的引數資訊,沒有記錄任何的pdb的資訊,那ORACLE是如何管理使得各個pdb有自己的引數,這裡通過試驗的出來ORACLE 12C CDB環境中是通過引數檔案結合PDB_SPFILE$來實現引數管理
資料庫版本

SQL>   select *   from v$version;
 
BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle   Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0
PL/SQL Release 12.1.0.1.0 - Production                                                    0
CORE    12.1.0.1.0      Production                                                        0
TNS   for Linux: Version 12.1.0.1.0 - Production                                            0
NLSRTL Version 12.1.0.1.0 - Production                                                    0

pdb資訊

SQL>    select PDB_NAME,CON_UID,pdb_id,status   from dba_pdbs;
 
PDB_NAME      CON_UID     PDB_ID STATUS
---------- ---------- ---------- -------------
PDB1       3313918585          3 NORMAL
PDB$SEED   4048821679          2 NORMAL
PDB2       3872456618          4 NORMAL
 
SQL>   select con_id,dbid, NAME ,OPEN_MODE   from v$pdbs;
 
     CON_ID       DBID   NAME                            OPEN_MODE
---------- ---------- ------------------------------ ----------
          2 4048821679 PDB$SEED                         READ ONLY
          3 3313918585 PDB1                             READ WRITE
          4 3872456618 PDB2                           MOUNTED

CDB$ROOT中修改引數

--指定container=all
SQL> show con_name
 
CON_NAME
------------------------------
CDB$ROOT
 
SQL>   alter system   set open_cursors=500 container= all ;
 
System altered.
 
SQL> show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      500
 
SQL>   alter session   set container=pdb1;
 
Session altered.
 
SQL> show con_name
 
CON_NAME
------------------------------
PDB1
 
SQL> show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      500
  
--在CDB$ROOT中修改不指定container參數列示全部pdb生效
SQL>   alter session   set container=CDB$ROOT;
 
Session altered.
 
SQL>   alter system   set open_cursors=100;
 
System altered.
 
SQL>  show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      100
 
SQL>   alter session   set container=pdb1;
 
Session altered.
 
SQL> show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      100
 
--指定container=current
SQL>   alter system   set open_cursors=120 container= current ;
 
System altered.
 
SQL> show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      120
SQL>   alter session   set container=pdb2 ;
 
Session altered.
 
SQL> show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      120

這裡可以看出來,在ROOT中修改引數,預設情況和指定container=all/current均是所有open的pdb都生效.
這裡有個疑問ORACLE的引數檔案只是記錄的cdb的sid的引數,並未記錄各個pdb的引數,那是如何實現cdb中各個pdb引數不一致的呢?繼續分析

修改pdb引數做10046

SQL> show con_name;
 
CON_NAME
------------------------------
PDB1
 
SQL> oradebug setmypid
Statement processed.
SQL> oradebug EVENT 10046 TRACE   NAME CONTEXT FOREVER,   LEVEL 12
Statement processed.
SQL> oradebug TRACEFILE_NAME
/u01/app/oracle/diag/rdbms/cdb/cdb/trace/cdb_ora_18377.trc
SQL>   alter system   set sessions=100;
 
System altered.
 
SQL> oradebug EVENT 10046 trace   name context   off
Statement processed.
 
--繼續修改pdb引數
SQL>   alter session   set container=pdb1;
 
Session altered.
 
SQL>  oradebug setmypid
Statement processed.
SQL> oradebug EVENT 10046 TRACE   NAME CONTEXT FOREVER,   LEVEL 12
Statement processed.
SQL>  oradebug TRACEFILE_NAME
/u01/app/oracle/diag/rdbms/cdb/cdb/trace/cdb_ora_20275.trc
SQL>   alter system   set sessions=101;
 
System altered.
 
SQL> oradebug EVENT 10046 trace   name context   off
Statement processed.

分析trace檔案

--第一次修改pdb引數值
insert into pdb_spfile$(db_uniq_name, pdb_uid, sid, name, value$, comment$)  values(:1,:2,:3,:4,:5,:6)
END OF STMT
PARSE   #140085118752824:c=3999,e=3397,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=99767937623
BINDS   #140085118752824:
  Bind #0
   oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=7fffcfaa5842  bln=32  avl=03  flg=09
   value= "cdb"
  Bind #1
   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
   oacflg=00 fl2=1000001 frm=00 csi=00 siz=24 off=0
   kxsbbbfp=7f681bbb2170  bln=22  avl=06  flg=05
   value=3313918585
  Bind #2
   oacdty=01 mxl=32(01) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=7fffcfaa46f8  bln=32  avl=01  flg=09
   value= "*"
  Bind #3
   oacdty=01 mxl=32(08) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=0bc220d8  bln=32  avl=08  flg=09
   value= "sessions"
  Bind #4
   oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=7fffcfaa474c  bln=32  avl=03  flg=09
   value= "100"
  Bind #5
   oacdty=01 mxl=32(00) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=00000000  bln=32  avl=00  flg=09
 
--第二次修改pdb引數值(相同引數)
update pdb_spfile$   set value$=:5, comment$=:6  where name=:1 and pdb_uid=:2 and db_uniq_name=:3 and sid=:4
BINDS   #140603847818408:
  Bind #0
   oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=7ffff6477dcc  bln=32  avl=03  flg=09
   value= "101"
  Bind #1
   oacdty=01 mxl=32(00) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=00000000  bln=32  avl=00  flg=09
  Bind #2
   oacdty=01 mxl=32(08) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=0bc220d8  bln=32  avl=08  flg=09
   value= "sessions"
  Bind #3
   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
   oacflg=00 fl2=1000001 frm=00 csi=00 siz=24 off=0
   kxsbbbfp=7fe0e2638320  bln=22  avl=06  flg=05
   value=3313918585
  Bind #4
   oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=7ffff6478ec2  bln=32  avl=03  flg=09
   value= "cdb"
  Bind #5
   oacdty=01 mxl=32(01) mxlc=00 mal=00 scl=00 pre=00
   oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0
   kxsbbbfp=7ffff6477d78  bln=32  avl=01  flg=09
   value= "*"

通過這裡我們發現在獨立修改pdb引數之時,其本質是在pdb_spfile$基表中插入或者修改相關記錄(第一次修改插入,後續修改是更新)

關於pdb_spfile$基表分析

SQL> SHOW CON_NAME;
 
CON_NAME
------------------------------
CDB$ROOT
 
SQL> COL OWNER   FOR A10
SQL>   select con_id,owner,object_type   from cdb_objects   where object_name= 'PDB_SPFILE$' ;
 
     CON_ID OWNER      OBJECT_TYPE
---------- ---------- -----------------------
          2 SYS          TABLE
          1 SYS          TABLE
          3 SYS          TABLE
 
SQL> COL DB_UNIQ_NAME   FOR A10
SQL> COL   NAME FOR A15
SQL> COL VALUE$   FOR A10
SQL>   SELECT DB_UNIQ_NAME,PDB_UID, NAME ,VALUE$   FROM PDB_SPFILE$;
 
DB_UNIQ_NA    PDB_UID   NAME             VALUE$
---------- ---------- --------------- ----------
cdb        3313918585 sessions        101
 
SQL>   ALTER SESSION   SET CONTAINER=pdb1;
 
Session altered.
 
SQL>    SELECT DB_UNIQ_NAME,PDB_UID, NAME ,VALUE$   FROM PDB_SPFILE$;
 
no rows selected

證明pdb中不同於root的引數是記錄在root的PDB_SPFILE$基表中.
整個CDB的工作原理是如果在PDB_SPFILE$中無相關引數記錄,則繼承cdb的引數檔案中值,如果PDB_SPFILE$中有記錄則使用該值覆蓋cdb引數檔案值.

刪除PDB_SPFILE$驗證

SQL> SHOW CON_NAME;
 
CON_NAME
------------------------------
CDB$ROOT
 
SQL> show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      100
 
SQL>    select con_id,dbid, NAME ,OPEN_MODE   from v$pdbs;
 
     CON_ID       DBID   NAME                            OPEN_MODE
---------- ---------- ------------------------------ ----------
          2 4048821679 PDB$SEED                         READ ONLY
          3 3313918585 PDB1                           MOUNTED
          4 3872456618 PDB2                             READ WRITE
 
SQL>   alter session   set container=pdb2;
 
Session altered.
 
SQL> show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      100
SQL>   alter system   set open_cursors=110;
 
System altered.
 
SQL> show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      110
 
SQL> conn /   as sysdba
Connected.
SQL>   select value$   from pdb_spfile$   where name = 'open_cursors' ;
 
VALUE$
--------------------------------------------------------------------------------
110
 
SQL>   delete from   pdb_spfile$   where name = 'open_cursors' ;
 
1 row deleted.
 
SQL>   commit ;
 
Commit complete.
 
SQL> startup
ORACLE instance started.
 
Total System   Global Area  597098496 bytes
Fixed   Size                   2291072 bytes
Variable   Size              272632448 bytes
Database Buffers          314572800 bytes
Redo Buffers                7602176 bytes
Database mounted.
Database opened.
SQL>   select value$   from pdb_spfile$   where name = 'open_cursors' ;
 
no rows selected
 
SQL> show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      100
SQL>   alter session   set container=pdb2 ;
 
Session altered.
 
SQL>   alter database open ;
 
Database altered.
 
SQL>  show parameter open_cursors;
 
NAME                                  TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                           integer      100

刪除PDB_SPFILE$中相關記錄,pdb的引數值會自動繼續繼承cdb中引數值
總結說明: 通過上述的一些列試驗證明cdb中引數關係,在cdb中修改,會預設所有pdb均自動繼承;如果在pdb中修改值會覆蓋cdb引數,而且只對當前pdb生效,並記錄在PDB_SPFILE$

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


多租戶資料庫中的初始化引數-常見問題和示例(文件ID 2101638.1)


在本檔案中


目的

問答

-PDB資料庫的SPFILE在哪裡?

-如何檢視PDB中引數的當前值?

-我只想更改PDB引數的值,但它失敗了,為什麼?

-我如何才能為我的RAC PDB例項中的一個設定引數?

-更改備用PDB的引數失敗,如何將引數設定為備用資料庫?

參考文獻


適用於:

Oracle資料庫-企業版-12.1.0.1及更高版本
本文件中的資訊適用於任何平臺。
*在2017年7月21日-2017年7月21日*

目的

這樣做的目的是在多租戶資料庫環境中提供“ALTERSystemSet/Reset.”命令的正確語法和有效示例。

對於接下來的問題/答案或示例,請考慮以下環境:


2節點RAC主群集和2節點RAC備用群集。

1 RAC容器DB(CDB_PRD)具有2個不同的RAC可外掛PDB(PDBP 1和PDBP 2),根的CDB有2個RAC例項,每個RAC節點上有一個例項,“邏輯”上每個PDB也有2個例項。

 

主群組:

節點1 節點2

CBD_PRD 1

(PDBP 1_I1)

(PDBP 2_I1)

CBD_PRD 2

(PDBP 1_I2)

(PDBP 2_I2)

 

待機組:

節點1 節點2

CBD_STBY 1

(PDBP 1_I1)

(PDBP 2_I1)

CBD_STBY 2

(PDBP 1_I2)

(PDBP 2_I2)


 

請注意,PDB的“邏輯”RAC例項的概念並不真正存在,為了便於理解這些概念,上面對它們進行了稀釋,在OS級別上,每個多租戶資料庫只會找到一個例項(對於CDB)。

上面的每個多租戶資料庫都有自己的DB_UNIQUE_NAME,對應於根的CDB、主資料庫的CBD_PRD和備用資料庫的CBD_stby。

 

For detailed explanation of how initialization parameters work on a multitenant database please read Doc ID 2101596.1

 

問答

-PDB資料庫的SPFILE在哪裡?


PDBs沒有init.ora檔案或SPFILE,只有根的CDB有一個。PDB的引數儲存在DB的字典中,儲存在PDB_SPFILE$表中。

-我在查詢PDB的PDB_SPFILE$表,它是空的,為什麼?


這是應該的,PDB修改後的引數的所有資訊都儲存在根CDB中的PDB_SPFILE$表中。
引數被複制到PDB自己的PDB_spfile$表中的唯一時間是在PDB拔出外掛期間,如果XML丟失,這將作為後盾。
當PDB插入另一個CDB後,PDB的PDB_SPFILE$表被截斷。

-如何檢視PDB中引數的當前值?


為了向後相容,在使用多租戶資料庫時,檢查引數的當前值不會改變。
在連線到PDB時顯示引數應該仍然有效。
可以查詢V$引數或V$System_Parameter。但是,除非安裝了bug#20700587的修復程式,否則不會列出隱藏引數或下劃線引數。
作為另一種選擇,如果沒有安裝bug#20700587的修復程式,您可以查詢CDB的PDB_SPFILE$TABLE。V$SPPARAMETER檢視也可以被查詢以在從PDB內部查詢時顯示PDB的SPFILE引數。

-我只想更改PDB引數的值,但它失敗了,為什麼?


並非所有引數都是可修改的。要確定可以為PDB修改哪些引數,必須為V$System_Parameters或V$引數檢視中的ISPDB可修改列。

-我如何才能為我的RAC PDB例項中的一個設定引數?

如果要將相同引數的不同值設定到RAC例項中,則需要新增SID子句,就像在普通而非互斥DB中所做的那樣,唯一的區別是所提供的SID是多租戶DB的SID:
ALTERSession SET容器=PDBP 1;
從PDBP 1‘Scope=spfile sid=’cbd_prd 1‘更改系統設定OPEN_遊標為RAC例項1=’CBD_PRD 1‘;
從PDBP 1‘Scope=spfile sid=’bbd_prd 2‘更改系統設定OPEN_遊標=250個註釋=’將OPEN_遊標設定為RAC例項2;

 

請注意,在連線到PDBP 1容器時,我們正在執行該命令。

-更改備用PDB的引數失敗,如何將引數設定為備用資料庫?


由於PDB的引數儲存在資料庫的字典中,因此任何更改都將被取消,因為備用DB不是在讀寫模式下開啟的。
從12.1.0.2開始,可以使用DB_UNIQUE_NAME子句執行ALTERSystemSet語句的語法增強。
此子句提供了一種修改系統引數的方法,其作用域=SPFILE在主資料庫的PDB中,但指定備用資料庫的db_UNIQUE_NAME,其中引數值應該真正生效。這種方法確保在主伺服器上執行DML,以便在備用伺服器上生效。
從主容器連線到正確的容器PDB執行:
ALTERSession SET容器=PDBP 1;
更改系統設定OPEN_遊標=150註釋=‘將OPEN_遊標設定為PDBP 1備用’Scope=spfile db_UNIQUE_NAME=‘cdb_stby’;
請注意上面語法中的“.db_UNIQUE_NAME=‘CDB_stby’.”,它指定備用資料庫的db_UNIQUE_NAME。

如果要將相同引數的不同值設定為需要新增SID子句的例項,如下所示:
更改系統設定OPEN_遊標=150個註釋=‘將OPEN_遊標設定為例項1(PDBP 1備用)範圍=spfile db_UNIQUE_NAME=’CDB_stby‘sid=’CBD_STBY 1‘;
更改系統設定OPEN_遊標=250個註釋=‘將OPEN_遊標設定為例項2從PDBP 1備用’SCOPE=spfile db_UNIQUE_NAME=‘CDB_stby’sid=‘CBD_STBY 2’;

請注意,在連線到PDBP 1容器DB時,我們正在執行來自主DB的命令,我們需要同時指定db_UNIQUE_NAME和SID。
還請注意,SID是多租戶備用DB的SID。

 

 

參考文獻

NOTE:2101596.1 -多租戶資料庫中的初始化引數-事實和附加資訊
NOTE:1511619.1 -Oracle多租戶選項-12c:常見問題


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

ALTER SYSTEM RESET DOESN'T UPDATE PARAM VALUE IN PDB_SPFILE$ (文件 ID 2287601.1)


In this Document


Symptoms

Cause

Solution

References


APPLIES TO:

Oracle Database - Version 12.2.0.1 to 12.2.0.1 [Release 12.2]
Information in this document applies to any platform.

SYMPTOMS

pdb_spfile$ not updated when alter system reset is issued for a parameter.

CAUSE

This issue is investigated in

bug 24423308 - SV12.2DBSA: ALTER SYSTEM RESET DOESN'T UPDATE PARAM VALUE IN PDB_SPFILE$@ROOT

Which is closed as not a bug.

pdb_spfile$ is an internal dictionary table, it should not be used to query the initialization parameters. To elaborate on the technical details, the row exists in pdb_spfile$ but it is marked as DELETED parameter. So existence of the row is internal implementation and not impact for the user.

 

SOLUTION

Check v$parameter, v$system_parameter, v$spparameter views 


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



Initialization parameters in a Multitenant database - Facts and additional information (文件 ID 2101596.1)



In this Document


Purpose

Scope

Details

References


APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.1.0.1 and later
Information in this document applies to any platform.

PURPOSE

 Provides a clear understanding of how we can set initialization parameters in a multitenant Oracle database and what to expect.

SCOPE

 This document is intended for database administrators which are using the new 12c feature Mutitenant databases.


 

DETAILS

Things to know when changing parameters in a plugable database.

 

Modifying Initialization Parameters in PDB, facts :

  • PDBs inherit parameter values from the root CDB unless they are overridden at PDB level.

  • The normal 'ALTER SYSTEM' command is used to modify PDB level parameters except that persistence mechanism is different.

  • PDB level initialization parameters are not stored in the SPFILE, instead they are stored in the data dictionary for the PDB. PDB's spfile parameters are stored in the PDB_SPFILE$ internal table.

  • There is only one phisical spfile for the entire CBD and all its PDBs. This spfile is read when the root CDB is opened.

  • The equivalent of an spfile for a PDB is the CDB's PDB_SPFILE$ table.

  • There is a PDB_SPFILE$ table for each one of the containers (cdb$root and all PDBs). However only the CDB's PDB_SPFILE$ table contains those parameters which have been specifically set for the PDBs.

  • SPFILE in PDBs is always enabled, as long as the root's CDB is open. This is true even if the CDB is not using a SPFILE, Oracle allows PDB to use SPFILE because PDBs do not have any other means for persistent parameters, (PDBs do not support PFILE or init.ora file).

  • Only a subset of the overall Oracle DB initialization parameters can be modified locally in the PDB. Look for those parameters with V$PARAMETER.ISPDB_MODIFIABLE = 'YES'.

  • PDB level parameters persist across database restarts and also across unplug/plug and even clone operations.

  • The root's PDB_SPFILE$ table is internally queried and the parameters are set accordingly when the pluggable database/instance is opened.

  • When connected as a privileged user to the root container DB, any ALTER SYSTEM command will, by default, be directed at just the root container.

  • The traditional ways of looking at an SPFILE or even the alert.log will only be useful for a CDB database. This is because the CDB is the root level that controls many of the items which are shared among the CDB and PDBs.

  • To see parameters for the CDB and all the PDB’s (except PDB$SEED), V$SYSTEM_PARAMETER can be queried. Hidden or underscore parameters are not listed there though unless fix for bug#20700587 is installed.

  • As an alternative for the above bullet you can query CDB's PDB_SPFILE$ table instead. V$SPPARAMETER view can also be queried to show PDB's SPFILE parameters when queried from inside the PDB.

  • In a non-CDB DB, the V$SPPARAMETER view reads the spfile and shows the parameters as a query result. The same view in a CDB reads the PDB_SPFILE$ table in ROOT and show the PDB's SPFILE parameters when inside a PDB.

  • In order to modify parameters at PDB level you need to be connected to the PDB container for which you want to make the modification. If you are connected at ROOT container the parameter modification will take place for entire CDB.

  • Every time when you open a PDB, if that particular PDB has its own values for some of the init parameters the values from the CDB's SPFILE are overwritten with the values from PDB_SPFILE$.

  • All initialization parameters can be set for the root CDB DB. For any initialization parameter that is not set explicitly for a PDB, the PDB inherits the root's parameter value.

  • Just like normal initialization parameters there are underscore parameters that cannot be modified at system level, or cannot be modified at PDB level, or parameters -hidden or not- that need to have the same value across all RAC instances.

  • The PDB_SPFILE$ table in each one of the PDB is truncated/empty, all the initialization parameters for each PDB are stored in the root's PDB_SPFILE$ table instead.

  • Parameters and their values are restored for the PDB when it is plugged into a new CDB.

  • When a PDB is unplugged its own initialization parameters will also be copied into the PDB's own PDB_SPFILE$ table, this is done as a fallback in case the XML is lost.

  • Once a PDB is plugged back into a CDB and all its parameters imported then the local PDB's PDB_SPFILE$ table is truncated.

  • Since the PDB's spfile parameters are stored in a dictionary table in the ROOT CDB, the 'ALTER SYSTEM RESET' command just deletes the row for the PDB's parameter from the PDB_SPFILE$ table in the ROOT. This is equivalent to removing the parameter from the regular spfile in a non CDB.

  • There is no current support for resetting in-memory parameters for regular non-multitenant database, and hence that is not supported for PDB either.

  • A PDB's 'ALTER SYSTEM SET/RESET ...' command to set/reset a parameter cannot be executed with scope=memory when the PDB is closed. When reading parameters for a closed PDB, we are expected to provide ROOT's values of the parameters, since the PDB inherits from ROOT.


Understanding the concept of parameter inheritance within the Oracle Database 12c:


Parameter Inheritance in Oracle Database 12c means that the value of a particular parameter in the root (CDB) is inherited by one or more PDBs. There are parameters that can be changed at the PDB level and override what is being inherited from the CDB. To identify which parameters can be modified for a PDB, the ISPDB_MODIFIABLE column in the V$SYSTEM_PARAMETER or V$PARAMETER views must be TRUE. If the ISPDB_MODIFIABLE column for that parameter is TRUE then the parameter inherits the value from the CDB until it is changed with an ALTER SYSTEM SET command at the PDB.

 

From documentation:

When the current container is a PDB, run the ALTER SYSTEM SET initialization_parameter statement to modify the PDB. The statement does not affect the root or other PDBs.
The following table describes the behavior of the SCOPE clause when you use a server parameter file (SPFILE) and run the ALTER SYSTEM SET statement on a PDB.

MEMORY :
The initialization parameter setting is changed in memory and takes effect immediately in the PDB. The new setting affects only the PDB.
The setting reverts to the value set in the root in the any of the following cases:
- An ALTER SYSTEM SET statement sets the value of the parameter in the root with SCOPE equal to BOTH or MEMORY, and the PDB is closed and re-opened. The parameter value in the PDB is not changed if SCOPE is equal to SPFILE, and the PDB is closed and re-opened.
- The CDB is shut down and re-opened.

SPFILE :
The initialization parameter setting is changed for the PDB in the SPFILE. The new setting takes effect in any of the following cases:
- The PDB is closed and re-opened.
- The CDB is shut down and re-opened.
In these cases, the new setting affects only the PDB.

BOTH :
The initialization parameter setting is changed in memory, and it is changed for the PDB in the SPFILE. The new setting takes effect immediately in the PDB and persists after the PDB is closed and re-opened or the CDB is shut down and re-opened. The new setting affects only the PDB.

- Note that in absence of the SCOPE clause in the alter system command. It should be determined on execute time based on the context of the current container. Default value of SCOPE clause in Alter System is SCOPE=BOTH.

 

 

Setting parameters for a PDB Data Guard Standby:

  • In 12.1.0.1, the ALTER SYSTEM SCOPE=SPFILE is disallowed on standby database because the standby DB is not opened in read-write mode and as such changes to the root's PDB_SPFILE$ table are not allowed.

  • In order to provide a way to solve the above limitation, there is a syntax enhancement in 12.1.0.2 to execute an ALTER SYSTEM SET statement with a DB_UNIQUE_NAME clause.

  • ER bug#16270497 implements the PDB SPFILE limitation on ADG above.

  • The DB_UNIQUE_NAME clause in the "ALTER SYSTEM SET/RESET ..." command will not be documented in 12.1. This clause provides a way to modify the system parameter with SCOPE=SPFILE inside the PDB on the primary database, but specify the db_unique_name of the standby database where the parameter value should really take effect. This approach ensures that the DML gets performed on the primary with the intention to take effect on the standby.

 

 

Setting parameters for a RAC PDB :

 

  • Setting parameters for a RAC PDB is the same as setting parameters for a non-Multitenant database, the only difference, and this is important, is that if you want to set a parameter to an specific instance of a RAC PDB database the SID provided needs to be from the CDB's instance name.

 

Review this Doc Id 2101638.1 for specific examples and correct syntax to use when changing parameters in a multitenant database.

 

REFERENCES


NOTE:2101638.1  - Initialization parameters in a Multitenant database - FAQ and Examples



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

Multitenant best Practice and Known issues (文件 ID 1604135.1)


In this Document


Purpose

Details

References


APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.1.0.1 to 12.1.0.1 [Release 12.1]
Information in this document applies to any platform.
***Checked for relevance on 04-Feb-2016***

PURPOSE

 Best Practices for Multiteenant option and general known issues and problems

DETAILS

  1.Tnsnames when connecting to either Container or Pluggable instance

The tnsnames.ora should be configured , for eg to add a tns entry for pluggable database PDB_OMF_1

PDB_OMF_1 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = MFarag-OEL)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = pdb_omf_1)
    )
  )

 Alternatively the easy connect syntax could be used as follow :

 

SYS@mfarag-oel/PDB_OMF_1>CONN A/A@mfarag-oel/PDB_OMF_1
Connected.
A@mfarag-oel/PDB_OMF_1>conn xx/xx@mfarag-oel/XX
Connected.
XX@mfarag-oel/XX>

 

Add the following entry to the glogin.sql script under $ORACLE_HOME/sqlplus/admin

 

set sqlprompt "_USER'@'_CONNECT_IDENTIFIER'>'"

 

2.Always use OMF pluggable Database when the Container is Pluggable :

SYS@CDB>create pluggable database pdbomf admin user a identified by a ;

 

 CREATE PLUGGABLE DATABASE pdb2 ADMIN USER pdb_adm IDENTIFIED BY Password1 FILE_NAME_CONVERT=('/u01/app/oracle/oradata/cdb1/pdbseed/','/u01/app/oracle/oradata/cdb1/pdb2/');

 

 Please note FILE_NAME_CONVERT( filename_pattern ,replacement_filename_pattern ) clause is required if you are not using OMF.  If you omit this clause, then the database first attempts to use Oracle Managed Files to generate file names. If you are not using Oracle Managed Files, then the database uses the PDB_FILE_NAME_CONVERT initialization parameter to generate file names. If this parameter is not set, then an error occurs.


 

SYS@CDB>select CON_ID,DBID,GUID,NAME,OPEN_MODE
    from V_$CONTAINERS ;

    CON_ID       DBID GUID
---------- ---------- --------------------------------
NAME                           OPEN_MODE
------------------------------ ----------
         1 1949193435 DD7C48AA5A4504A2E04325AAE80A403C
CDB$ROOT                       READ WRITE

         2 4075234582 EC25D0EC10347332E043CC8DAB0A7AE1
PDB$SEED                       READ ONLY

         3 3255612964 EC25E0FB670B76A8E043CC8DAB0A08D8
PDB                            READ WRITE


    CON_ID       DBID GUID
---------- ---------- --------------------------------
NAME                           OPEN_MODE
------------------------------ ----------
         4 3244820336 EC276A999A790163E043CC8DAB0AD357
PDBOMF                         MOUNTED

.
.
SYS@CDB>alter session set container=pdbomf ;

Session altered.

SYS@CDB>alter pluggable database open ;

Pluggable database altered.

 

 

3.Open the Pluggable Database in Restricted m ode before Renaming it

 

SYS@CDB>conn sys@pdb_omf_1 as sysdba 
Enter password:                      
Connected.                           
       
SYS@pdb_omf_1>alter pluggable database close ;


SYS@pdb_omf_1>alter pluggable database open restricted;


SYS@pdb_omf_1>alter pluggable database pdbomf rename  global_name to pdb_omf_1 ;

 

 4.unplug and Plug a Database  :

SYS@CDB1>alter pluggable database y close immediate ;

SYS@CDB1>alter pluggable database y unplug into '/home/oracle/XDESC.xml' ;

SYS@CDB1>drop pluggable database y ;

SYS@CDB1>create pluggable database y using '/home/oracle/XDESC.xml' nocopy ;

  

 5. startup the Pluggable database in single step  :

 

SYS@CDB>select CON_ID,GUID,NAME,OPEN_MODE
    from V$containers;                  

    CON_ID GUID                             NAME
---------- -------------------------------- ------------------------------
OPEN_MODE                                                                 
----------                                                                
         1 DD7C48AA5A4504A2E04325AAE80A403C CDB$ROOT                      
READ WRITE                                                                

         2 EC25D0EC10347332E043CC8DAB0A7AE1 PDB$SEED
READ ONLY                                           

         3 EC2B4C003E221F09E0438636AF0AA57B X
MOUNTED                                      


    CON_ID GUID                             NAME
---------- -------------------------------- ------------------------------
OPEN_MODE                                                                 
----------                                                                
         4 EC276A999A790163E043CC8DAB0AD357 PDB_OMF_1                     
MOUNTED                                                                   


SYS@CDB>alter pluggable database all open ;


SYS@CDB>select CON_ID,GUID,NAME,OPEN_MODE
    from V$containers               
                          

    CON_ID GUID                             NAME
---------- -------------------------------- ------------------------------
OPEN_MODE
----------
         1 DD7C48AA5A4504A2E04325AAE80A403C CDB$ROOT
READ WRITE

         2 EC25D0EC10347332E043CC8DAB0A7AE1 PDB$SEED
READ ONLY

         3 EC2B4C003E221F09E0438636AF0AA57B X
READ WRITE


    CON_ID GUID                             NAME
---------- -------------------------------- ------------------------------
OPEN_MODE
----------
         4 EC276A999A790163E043CC8DAB0AD357 PDB_OMF_1
READ WRITE

 

 Note : the startup of the Container CDB will place all the pdb in mount status by Defualt 

6.Use catcon perl script to run scripts for selective or all pluggable and container database  :

E.g Run the awrinfo script to have information about the awr usage under sysaux for all the databases :

$cd $ORACLE_HOME/rdbms/admin

$ perl catcon.pl -u SYS -U SYS -d $ORACLE_HOME/rdbms/admin -l '/home/oracle'  -b catblock_output awrinfo.sql

--Confirm that the script run against all the databases :

$cd /home/oracle
$ grep -i "CURRENT CONTAINER" *
catblock_output0.log:==== Current Container = CDB$ROOT ====
catblock_output0.log:==== Current Container = PDB$SEED ====
catblock_output1.log:==== Current Container = XX ====
catblock_output2.log:==== Current Container = PDB_OMF_1 ====

  

Note : use the -c option tpo specify certain databases to have this script run against

7.How to use non-seed template to create CDB + Pluggable database :

 

$ dbca -silent -createDatabase -templateName Custom_DB_.dbt -gdbName FOFO -sid FOFO -createAsContainerDatabase true -numberOfPDBs 1 -pdbName pdb_silent  -sysPassword <password> -systemPassword <password>   -listeners listener
Enter PDBADMIN

  Note : the above command used the non-seed Custome_DB_ template to create CDB names FOFO with a PDB database named pdb_silent in silent mode .


8. Modify the Value "_datafile_write_errors_crash_instance" to be FALSE

 

SQL>alter system set "_datafile_write_errors_crash_instance"=FALSE

 

**This has to be set at CDB level. This is to allow the Container CDB to continue running if one of its Pdb lost one of the datafiles for any reason

NOTE

 

9.How  To check if a parameter have been modified within the PDB?

 

SYS@CDB>column PDB_NAME format a20
SYS@CDB>column NAME format a20
SYS@CDB>column VALUE$ format a20
SYS@CDB>select p.PDB_NAME,s.name,s.value$
        from cdb_pdbs p , pdb_spfile$ s
        where p.CON_UID=s.PDB_UID


PDB_NAME               NAME                 VALUE$
-------------------- -------------------- --------------------
XX                    cursor_sharing       'SIMILAR'
YY_NEW                cursor_sharing       'SIMILAR'

 

**Note This could never be checked for non default pdb init parameters valunes using alertlog .

 

 

REFERENCES

NOTE:1516202.1  - How to Monitor Process Memory Usage on Pluggable Databases
NOTE:1575186.1  - Syntax Error Encountered During The Creation Of A Pluggable Database
NOTE:1511619.1  - Oracle Multitenant Option - 12c : Frequently Asked Questions 


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



多租戶資料庫中的初始化引數-事實和附加資訊(文件ID 2101596.1)




在本檔案中


目的

範圍

細節

參考文獻


適用於:

Oracle資料庫-企業版-12.1.0.1及更高版本
本文件中的資訊適用於任何平臺。

目的

清楚地瞭解如何在多租戶Oracle資料庫中設定初始化引數以及預期的內容。

範圍

此文件用於使用新的12c特性的資料庫管理員。


 

細節

在外掛資料庫中更改引數時要知道的事情。

 

修改PDB中的初始化引數,事實:

  • PDB從根CDB繼承引數值,除非它們在PDB級別被重寫。

  • 普通的“ALTERSystem”命令用於修改PDB級別的引數,但永續性機制不同。

  • PDB級別的初始化引數不是儲存在SPFILE中,而是儲存在PDB的資料字典中。PDB的spfile引數儲存在PDB_SPFILE$內部表中。

  • 對於整個CBD及其所有PDBs,只有一個phisical spfile。開啟根CDB時讀取此spfile。

  • 與PDB的spfile等價的是CDB的PDB_SPFILE$表。

  • 每個容器都有一個PDB_SPFILE$表(CDB$root和所有PDB)。但是,只有CDB的PDB_SPFILE$表包含為PDB專門設定的引數。

  • 只要根的CDB是開啟的,PDBs中的SPFILE總是被啟用的。即使CDB不使用SPFILE,Oracle也允許PDB使用SPFILE,因為PDB沒有任何其他方法用於持久引數(PDB不支援Pfile或init.ora檔案)。

  • 在PDB中只能在本地修改整個Oracle DB初始化引數的一個子集。使用V$PARAMETER.ISPDB_AUDIBE=‘YES’查詢這些引數。

  • PDB級別的引數在資料庫重新啟動的過程中持續存在,在拔出/外掛甚至克隆操作中也是如此。

  • 根的PDB_SPFILE$表是內部查詢的,在開啟可插拔資料庫/例項時會相應地設定引數。

  • 當以特權使用者的身份連線到根容器DB時,預設情況下,任何ALTERSystem命令都只指向根容器。

  • 傳統的檢視SPFILE甚至警報日誌的方法只對CDB資料庫有用。這是因為CDB是控制CDB和PDB之間共享的許多項的根級別。

  • 要檢視CDB和所有PDB的引數(PDB$SEED除外),可以查詢V$System_Parameters。但是,除非安裝了bug#20700587的修復程式,否則不會列出隱藏引數或下劃線引數。

  • 作為上述專案的替代方案,您可以查詢CDB的PDB_SPFILE$table。V$SPPARAMETER檢視也可以被查詢以在從PDB內部查詢時顯示PDB的SPFILE引數。

  • 在非CDBDB中,V$SPPARAMETER檢視讀取spfile並將引數顯示為查詢結果。CDB中的相同檢視讀取根中的PDB_SPFILE$表,並在PDB中顯示PDB的SPFILE引數。

  • 為了在PDB級別修改引數,您需要連線到要對其進行修改的PDB容器。如果在根容器中連線,引數修改將對整個CDB進行。

  • 每次開啟PDB時,如果特定的PDB對於某些init引數有自己的值,那麼CDB的SPFILE的值將被PDB_SPFILE$的值覆蓋。

  • 可以為根CDB DB設定所有初始化引數。對於沒有為PDB顯式設定的任何初始化引數,PDB繼承根的引數值。

  • 就像正常的初始化引數一樣,有些下劃線引數不能在系統級別修改,或者不能在PDB級別上修改,或者引數-隱藏的或不隱藏的-需要在所有RAC例項中具有相同的值。

  • 每個PDB中的PDB_SPFILE$表都是截斷/空的,每個PDB的所有初始化引數都儲存在根的PDB_SPFILE$表中。

  • 當PDB插入到新的CDB中時,引數及其值將被恢復。

  • 當一個PDB被拔出時,它自己的初始化引數也會被複制到PDB自己的PDB_SPFILE$表中,這樣做是為了防止XML丟失。

  • 將PDB插入到CDB並匯入其所有引數後,本地PDB的PDB_SPFILE$表將被截斷。

  • 由於PDB的spfile引數儲存在根CDB中的字典表中,所以“ALTERSystemReset”命令只是從根中的PDB_SPFILE$表中刪除PDB引數的行。這相當於從非CDB中的常規spfile中刪除引數。

  • 當前不支援為常規的非多租戶資料庫重置記憶體中的引數,因此PDB也不支援這一點。

  • 當PDB關閉時,用於設定/重置引數的PDB‘AlterSystemSet/Reset.’命令不能用作用域=記憶體執行。當讀取封閉PDB的引數時,我們需要提供引數的根值,因為PDB是從根繼承的。


理解Oracle資料庫12c中引數繼承的概念:


Oracle資料庫12c中的引數繼承意味著根中特定引數(CDB)的值由一個或多個PDB繼承。有些引數可以在PDB級別上更改,並覆蓋從CDB繼承的內容。要確定可以為PDB修改哪些引數,必須為V$System_Parameters或V$引數檢視中的ISPDB可修改列。如果該引數的ISPDB_Modiable列為true,則該引數將繼承來自CDB的值,直到在PDB上使用ALTERSystemSet命令對其進行更改。

 

來自檔案:

噹噹前容器是PDB時,執行ALTERSystemSet初始化引數語句來修改PDB。該語句不影響根或其他PDB。
下表描述在使用伺服器引數檔案(SPFILE)並在PDB上執行ALTERSystemSet語句時Scope子句的行為。

記憶:
初始化引數設定在記憶體中更改,並在PDB中立即生效。新設定隻影響PDB。
在下列任何一種情況下,該設定返回到根中的值集:
-ALTERSystemSet語句設定根中引數的值,其作用域等於兩者或記憶體,PDB被關閉並重新開啟。如果範圍等於SPFILE,並且PDB關閉並重新開啟,則PDB中的引數值不會更改。
-國開行被關閉並重新開業。

SPFILE:
為SPFILE中的PDB更改初始化引數設定。新設定在下列任何情況下都生效:
-PDB已關閉,並重新開放。
-國開行被關閉並重新開業。
在這些情況下,新設定隻影響PDB。

兩者均:
初始化引數設定在記憶體中更改,對SPFILE中的PDB進行更改。新設定在PDB中立即生效,並在PDB關閉並重新開啟或CDB關閉並重新開啟之後繼續存在。新設定隻影響PDB。

-請注意,在ALTERSystem命令中沒有Scope子句的情況下。它應該根據當前容器的上下文根據執行時間來確定。ALTERSystem中Scope子句的預設值為Scope=二者。

 

 

設定PDB資料保護待機引數:

  • 在12.1.0.1中,在備用資料庫中不允許使用ALTERSystemScope=SPFILE,因為備用DB不是在讀寫模式下開啟的,因此不允許對root的PDB_SPFILE$表進行更改。

  • 為了提供解決上述限制的方法,12.1.0.2中有一個語法增強,可以使用DB_UNIQUE_NAME子句執行ALTERSystemSet語句。

  • Erbug#16270497在上面的ADG上實現了PDBSPFILE限制。

  • 在12.1中不會記錄“ALTERSystemSet/Reset.”命令中的DB_UNIQUE_NAME子句。此子句提供了一種修改系統引數的方法,其作用域=SPFILE在主資料庫的PDB中,但指定備用資料庫的db_UNIQUE_NAME,其中引數值應該真正生效。這種方法確保在主伺服器上執行DML,以便在備用伺服器上生效。

 

 

設定RAC PDB的引數:

 

  • 為RAC PDB設定引數與為非多租戶資料庫設定引數相同,唯一的區別是,如果要將引數設定為RAC PDB資料庫的特定例項,則SID提供的引數需要從CDB的例項名稱中設定。

 

檢查此DocID 2101638.1以獲得在多租戶資料庫中更改引數時要使用的特定示例和正確語法。

 

參考文獻


NOTE:2101638.1 -多租戶資料庫中的初始化引數-常見問題和示例







About Me

........................................................................................................................

● 本文作者:小麥苗,部分內容整理自網路,若有侵權請聯絡小麥苗刪除

● 本文在itpub( http://blog.itpub.net/26736162 )、部落格園( http://www.cnblogs.com/lhrbest )和個人weixin公眾號( xiaomaimiaolhr )上有同步更新

● 本文itpub地址: http://blog.itpub.net/26736162

● 本文部落格園地址: http://www.cnblogs.com/lhrbest

● 本文pdf版、個人簡介及小麥苗雲盤地址: http://blog.itpub.net/26736162/viewspace-1624453/

● 資料庫筆試面試題庫及解答: http://blog.itpub.net/26736162/viewspace-2134706/

● DBA寶典今日頭條號地址: http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826

........................................................................................................................

● QQ群號: 230161599 (滿) 、618766405

● weixin群:可加我weixin,我拉大家進群,非誠勿擾

● 聯絡我請加QQ好友 646634621 ,註明新增緣由

● 於 2018-11-01 06:00 ~ 2018-11-31 24:00 在魔都完成

● 最新修改時間:2018-11-01 06:00 ~ 2018-11-31 24:00

● 文章內容來源於小麥苗的學習筆記,部分整理自網路,若有侵權或不當之處還請諒解

● 版權所有,歡迎分享本文,轉載請保留出處

........................................................................................................................

小麥苗的微店 https://weidian.com/s/793741433?wfr=c&ifr=shopdetail

小麥苗出版的資料庫類叢書 http://blog.itpub.net/26736162/viewspace-2142121/

小麥苗OCP、OCM、高可用網路班 http://blog.itpub.net/26736162/viewspace-2148098/

小麥苗騰訊課堂主頁 https://lhr.ke.qq.com/

........................................................................................................................

使用 weixin客戶端 掃描下面的二維碼來關注小麥苗的weixin公眾號( xiaomaimiaolhr )及QQ群(DBA寶典)、新增小麥苗weixin, 學習最實用的資料庫技術。

........................................................................................................................

歡迎與我聯絡

 

 



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/26736162/viewspace-2213348/,如需轉載,請註明出處,否則將追究法律責任。

相關文章