1. 程式人生 > >【跟我學oracle18c】第十六天:Multitenant Architecture多租戶框架:2.1 Overview of Containers in a CDB(藍色感悟)

【跟我學oracle18c】第十六天:Multitenant Architecture多租戶框架:2.1 Overview of Containers in a CDB(藍色感悟)

容器是多租戶容器資料庫(CDB)中的模式、物件和相關結構的集合。在CDB中,每個容器都有唯一的ID和名稱

This section contains the following topics:

  • The CDB Root and System Container
    The CDB root, also called simply the root, is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong.
  • PDBs
    A PDB is a user-created set of schemas, objects, and related structures that appears logically to a client application as a separate database.
  • Data Dictionary Architecture in a CDB
    From the user and application perspective, the data dictionary in each container in a CDB is separate, as it would be in a non-CDB.
  • Current Container
    For a given session, the current container is the one in which the session is running. The current container can be the CDB root, an application root, or a PDB.
  • Cross-Container Operations
    cross-container operation is a DDL or DML statement that affects multiple containers at once.

Parent topic: Overview of the Multitenant Architecture

2.1.1 The CDB Root and System Container

CDB根(也稱為根)是所有PDBs所屬的模式、模式物件和非模式物件的集合.

每個CDB都有且只有一個名為CDB$ root的根容器。根儲存管理PDBs所需的系統元資料。所有PDBs都屬於根目錄。系統容器是CDB根

和所有屬於這個根的PDBs.

CDB根不儲存使用者資料。Oracle建議不要在根目錄中新增公共物件或修改Oracle提供的模式。但是,您可以為資料庫管理建立通用使用者和角色。具有必要特權的普通使用者可以在容器之間切換.

Oracle建議根字符集使用AL32UTF8。具有不同字符集的PDBs可以駐留在同一個CDB中,而不需要進行字符集轉換.

Example 2-1 All Containers in a CDB

The following query, issued by an administrative user connected to the CDB root, lists all containers in the CDB (including the seed and CDB root), ordered by CON_ID.

這個sql比較奇怪啊,剛開始我怎麼只能查出來pdb,沒出來cdb資料內容(試著建立了幾個pdb後才出來)

SQL> COL NAME FORMAT A15
SQL> SELECT NAME, CON_ID, DBID, CON_UID, GUID FROM V$CONTAINERS ORDER BY CON_ID;

NAME                CON_ID       DBID    CON_UID GUID
--------------- ---------- ---------- ---------- --------------------------------
CDB$ROOT                 1 1895287725          1 2003321EDD4F60D6E0534E40E40A41C5
PDB$SEED                 2 2795386505 2795386505 200AC90679F07B55E05396C0E40A23FE
SAAS_SALES_AC            3 1239646423 1239646423 200B4CE0A8DC1D24E05396C0E40AF8EE
SALESPDB                 4 3692549634 3692549634 200B4928319C1BCCE05396C0E40A2432
HRPDB                    5 3784483090 3784483090 200B4928319D1BCCE05396C0E40A2432

See Also:

Parent topic: Overview of Containers in a CDB

2.1.2 PDBs

PDB是使用者建立的一組模式、物件和相關結構,在客戶端應用程式看來,它們邏輯上是獨立的資料庫.

Every PDB is owned by SYS, regardless of which user created the PDB. SYS is a common user in the CDB.

This section contains the following topics:

  • Types of PDBs
    All PDBs are user-created with the CREATE PLUGGABLE DATABASE statement except for PDB$SEED, which is Oracle-supplied.
  • Purpose of PDBs
    From the point of view of an application, a PDB is a self-contained, fully functional Oracle database. You can consolidate PDBs into a single CDB to achieve economies of scale, while maintaining isolation between PDBs.
  • Proxy PDBs
    A proxy PDB refers to a remote PDB, called the referenced PDB.
  • Names for PDBs
    Containers in a CDB share the same namespace, which means that they must have unique names within this namespace.
  • Database Links Between PDBs
    By default, a user connected to one PDB must use database links to access objects in a different PDB. This behavior is directly analogous to a user in a non-CDB accessing objects in a different non-CDB.

Parent topic: Overview of Containers in a CDB

2.1.2.1 Types of PDBs

除了由oracle提供的PDB$SEED之外,所有PDBs都是使用者通過CREATE PLUGGABLE資料庫語句建立的。
您可以建立以下型別的PDBs.

Standard PDB

這種型別的PDB在執行CREATE PLUGGABLE資料庫時不會指定PDB作為種子、代理PDB或應用程式根。它的功能取決於建立它的容器:

  • PDB plugged in to the CDB root

    這個PDB屬於CDB根容器,而不是應用程式容器。這種型別的PDB不能使用應用程式公共物件。參見“應用程式公共物件”.

  • Application PDB

    應用程式PDB恰好屬於一個應用程式容器。與插入到CDB根目錄的PDBs不同,應用程式PDBs可以在應用程式容器中共享主應用程式定義。例如,應用程式根目錄中的usa_zipcodes表可能是一個數據連結的公共物件,這意味著它包含所有插入到這個根目錄的應用程式PDBs可以訪問的資料(這個應該是Application PDB區別於普通pdb資料庫的優勢所在。不駐留在應用程式容器中的PDBs不能訪問其應用程式公共物件。

可重新整理的克隆PDB是源PDB的只讀克隆,可以從源PDB接收增量更改。您可以配置克隆PDB來自動或僅手動接收更改.

快照複製PDB是使用儲存級快照建立的。與標準的PDB克隆不同,快照複製PDB不能斷開連線.

Application Root

將應用程式根作為特定於應用程式的根容器。它充當應用程式後端主定義(包括公共資料和元資料)的儲存庫。要建立應用程式根,請連線到CDB根,並在create PLUGGABLE資料庫語句中指定AS application CONTAINER子句。看到“應用程式根”.

Seed PDBs

與標準PDB不同,種子PDB不打算支援應用程式。相反,種子是建立支援應用程式的PDBs的模板。種子可以是下列任何一種:

  • Seed PDB plugged in the CDB root (PDB$SEED)

    您可以使用這個系統提供的模板在應用程式容器或系統容器中建立新的PDBs。系統容器只包含一個PDB種子。您不能刪除PDB$SEED,或向其中的物件新增物件或修改物件.

  • Application seed PDB

    為了加速在應用程式容器中建立應用程式PDBs,您可以建立一個可選的應用程式種子。應用程式容器包含零個或一個應用程式種子.

    You create an application seed by connecting to the application container and executing the CREATE PLUGGABLE DATABASE ... AS SEED statement. See "Application Seed".

Proxy PDBs

代理PDB是使用資料庫連結引用遠端CDB中的PDB的PDB。當PDB開啟時在代理PDB中發出一條語句時,該語句在引用的PDB中執行.

在連線到CDB根或應用程式根時,必須建立一個代理PDB。您可以修改或刪除代理PDB,就像您可以修改標準PDB一樣.

See Also:

"Overview of PDB Creation"

Parent topic: PDBs

2.1.2.2 Purpose of PDBs

從應用程式的角度來看,PDB是一個自包含的、功能完全的Oracle資料庫。您可以將PDBs合併為一個單獨的 CDB 節約資源, 同時保持PDBs之間的隔離。.

您可以使用PDBs來實現以下目標:

  • Store data specific to an application

    例如,銷售應用程式可以擁有自己的專用PDB,人力資源應用程式可以擁有自己的專用PDB。或者,您可以建立一個應用程式容器,它是一個命名的PDBs集合,用於儲存包含公共資料和元資料的應用程式後端(請參閱“關於應用程式容器”).

  • Move data into a different CDB

    資料庫是“可插入的”,因為您可以將其打包為一個自包含的單元,稱為不插電的PDB,然後將其移動到另一個CDB.

  • Perform rapid upgrades

    可以在較低的Oracle資料庫版本中從CDB中拔出PDB,然後在較高的版本中插入到CDB中.

  • Copy data quickly without loss of availability

    對於測試和開發,您可以在PDB保持開啟狀態時克隆它,將克隆儲存在相同或不同的CDB中。可選地,您可以將PDB指定為可重新整理的克隆PDB。或者,您可以使用oracle提供的種子PDB或使用者建立的應用程式種子來複制新的PDBs.

  • Reference data in a different CDB

    您可以建立一個引用不同PDB的代理PDB,可以在同一個CDB中引用,也可以在單獨的CDB中引用。當您在代理PDB中發出語句時,它們在引用的PDB中執行.

  • Isolate grants within PDBs

    具有適當特權的本地或普通使用者可以將模式物件上的執行特權授予單個PDB中的PUBLIC。

See Also:

Parent topic: PDBs

2.1.2.3 Proxy PDBs

A proxy PDB refers to a remote PDB, called the referenced PDB.

雖然在代理(引用)PDB中發出SQL語句,但是這些語句在引用的PDB中執行。在這方面,代理PDB大致類似於Linux中的符號連結檔案.

代理PDBs提供了以下好處:

  • Aggregate data from multiple application models

    代理PDBs使您能夠構建位置透明的應用程式,可以聚合來自多個源的資料。這些源可以位於同一個資料中心,也可以分佈在資料中心之間比物化檢視好,直接資料庫層次的refresh).

  • Enable an application root in one CDB to propagate application changes to a different application root

    假設CDBs cdb_prod和cdb_test具有相同的應用程式模型。在cdb_prod中的應用程式容器中建立一個代理PDB,它引用cdb_test中的應用程式根。當您在cdb_prod中的應用程式根中執行安裝和升級指令碼時,Oracle資料庫將這些語句傳播到代理PDB,後者將它們遠端傳送到cdb_test中的應用程式根。這樣,cdb_test中的應用程式根就變成了cdb_prod中的應用程式根的副本。

要建立代理PDB,使用AS proxy from子句執行create PLUGGABLE資料庫,其中FROM指定引用的PDB名稱和資料庫連結。建立語句只複製屬於系統和SYSAUX表空間的資料檔案.

Example 2-2 Creating a Proxy PDB

This example connects to the container saas_sales_ac in a local production CDB. The sales_admin common user creates a proxy PDB named sales_sync_pdb. This application PDB references an application root named saas_sales_test_ac in a remote development CDB, which it accesses using the cdb_dev_rem database link. When an application upgrade occurs in saas_sales_ac in the production CDB, the upgrade automatically propagates to the application root saas_sales_test_ac in the remote development CDB.

CONNECT [email protected]_sales_ac
Password: ***********

CREATE PLUGGABLE DATABASE sales_sync_pdb AS PROXY FROM [email protected]_dev_rem;

Note:

"Creating a Proxy PDB"

Parent topic: PDBs

2.1.2.4 Names for PDBs

CDB中的容器共享同一個名稱空間,這意味著它們必須在這個名稱空間中具有惟一的名稱。
下列容器的名稱不得在同一國開行中發生衝突:

  • The CDB root

  • PDBs plugged in to the CDB root

  • Application roots

  • Application PDBs

例如,如果同一個CDB包含應用程式容器saas_sales_ac和saas_sales_test_ac,那麼兩個名為cust1的應用程式PDBs不能同時駐留在兩個容器中。名稱空間規則還防止在CDB根中建立名為cust1pdb的PDB,以及在應用程式根中建立名為cust1pdb的PDB。

PDBs和應用程式根容器必須遵循與服務名稱相同的命名規則。此外,由於PDB或應用程式根具有具有自己名稱的服務,因此容器名稱必須在通過特定偵聽器公開服務的所有CDBs之間是唯一的。使用者建立的容器名稱的第一個字元必須是字母數字,其餘字元要麼是字母數字,要麼是下劃線(_)。因為服務名不區分大小寫,所以容器名不區分大小寫,即使使用分隔符指定也用大寫.

See Also:

Parent topic: PDBs

2.1.2.5 Database Links Between PDBs

預設情況下,連線到一個PDB的使用者必須使用資料庫連結訪問不同PDB中的物件。這種行為直接類似於非cdb中的使用者訪問另一個非cdb中的物件.(相當於物理隔絕的傳統資料庫之間的訪問,只能通過dblink方式

Figure 2-1 Database Link Between PDBs

在本例中,PDB管理員連線到名為hrpdb1的PDB。預設情況下,在此使用者會話期間,c##dba無法在hrpdb2中查詢emp2表,而無需指定資料庫連結.

Description of Figure 2-1 follows
Description of "Figure 2-1 Database Link Between PDBs"

Exceptions to the rule include:

  • 一個數據連結的公共物件,所有包含指向該物件的資料鏈接的應用程式PDBs都可以訪問它。例如,應用程式容器saas_sales_ac可能在其應用程式中包含資料鏈接表usa_zipcodes。在這種情況下,CDB使用者c##dba可以連線到這個容器中的應用程式PDB,然後查詢usa_zipcodes,即使實際的表駐留在應用程式根目錄中。在這種情況下,不需要資料庫連結.

  • 由CDB根或應用程式根發出的SQL中的CONTAINERS()子句。使用這個子句,您可以跨所有插入到根目錄的PDBs查詢資料。(這個得用例子跑一下,聽不懂的): SELECT * FROM CONTAINERS(sh.sales) ,我測試了一下,發現多了一個容器id 

SQL> select * from CONTAINERS(sys.test);
         A          B     CON_ID
---------- ---------- ----------
         1          1          3

SQL> select * from  (sys.test);
         A          B
---------- ----------
         1          1

SQL>  select con_id,name,open_mode,restricted from v$pdbs order by 1;
    CON_ID NAME       OPEN_MODE  RESTRICTED
---------- ---------- ---------- ----------
         3 ORCLPDB    READ WRITE NO

 

在建立代理PDB時,必須在CREATE PLUGGABLE資料庫的FROM子句中指定資料庫連結名…作為代理宣告。如果代理PDB和引用的PDB駐留在單獨的CDBs中,那麼資料庫連結必須在包含代理PDB的CDB根中定義。資料庫連結必須連線到遠端引用的PDB或遠端CDB的CDB根.

See Also:

Parent topic: PDBs

2.1.3 CDB中的資料字典體系結構

從使用者和應用程式的角度來看,CDB中每個容器中的資料字典是獨立的,就像在非CDB中一樣.

例如,每個PDB中的DBA_OBJECTS檢視可以顯示不同數量的行。這種字典分離使Oracle資料庫能夠分別管理PDBs和根目錄.

This section contains the following topics:

  • Purpose of Data Dictionary Separation
    In a newly created non-CDB that does not yet contain user data, the data dictionary contains only system metadata. For example, the TAB$ table contains rows that describe only Oracle-supplied tables, for example, TRIGGER$ and SERVICE$.
  • Metadata and Data Links
    The CDB uses an internal linking mechanism to separate data dictionary information.
  • Container Data Objects in a CDB
    A container data object is a table or view containing data pertaining to multiple containers or the whole CDB.
  • Data Dictionary Storage in a CDB
    The data dictionary that stores the metadata for the CDB as a whole is stored only in the system tablespaces.

Parent topic: Overview of Containers in a CDB

2.1.3.1 Purpose of Data Dictionary Separation

在新建立的尚未包含使用者資料的非cdb中,資料字典僅包含系統元資料。例如,選項卡$表包含只描述oracle提供的表的行,例如,觸發器$和服務$。
下圖描述了三個底層資料字典表,紅色的條表示描述系統的行.

Figure 2-2 Unmixed Data Dictionary Metadata in a Non-CDB

Description of Figure 2-2 follows
Description of "Figure 2-2 Unmixed Data Dictionary Metadata in a Non-CDB"

如果使用者在這個非cdb中建立自己的模式和表,那麼資料字典現在包含一些描述oracle提供的實體的行,以及其他描述使用者建立實體的行。例如,TAB$ dictionary表現在有一個描述員工的行和一個描述部門的行.

Figure 2-3 Mixed Data Dictionary Metadata in a Non-CDB

Description of Figure 2-3 follows
Description of "Figure 2-3 Mixed Data Dictionary Metadata in a Non-CDB"

在CDB中,資料字典元資料被劃分為根和PDBs。在下面的圖中,employee和departments表駐留在PDB中。這個使用者資料的資料字典也駐留在PDB中。因此,PDB中的TAB$表為employees表和departments表各有一行.(這個比較好理解,以前oracle10g裡面的最典型的dba_object或者source中各個使用者的資料都有,資料字典直接是個雜貨鋪子,18c裡的這個資料字典貌似有點像user_objects的概念了,僅僅自己的,資料字典小了,純淨了

Figure 2-4 Data Dictionary Architecture in a CDB

Description of Figure 2-4 follows
Description of "Figure 2-4 Data Dictionary Architecture in a CDB"

前面的圖形顯示了PDB中的資料字典包含指向根目錄中的資料字典的指標。在內部,oracle提供的物件(如資料字典表定義和PL/SQL包)只在根中表示。.這個體系結構實現了兩個主要目標:

  • 減少重複

    例如,與將DBMS_ADVISOR PL/SQL包的原始碼儲存在每個PDB中不同,CDB只將其儲存在CDB$ROOT中,這可以節省磁碟空間.

  • 資料庫升級的便捷性

    如果每個PDB中都存在資料字典表的定義,如果定義要在新版本中更改,那麼每個PDB都需要分別升級以捕獲更改。只在根目錄中儲存表定義一次就可以消除這個問題.

Parent topic: Data Dictionary Architecture in a CDB

2.1.3.2 Metadata and Data Links

 CDB 使用內部連結機制來分離資料字典資訊.

具體來說,Oracle資料庫使用以下自動託管指標:

  • Metadata links

    Oracle資料庫只在CDB根中儲存關於dictionary物件的元資料。例如,位於DBA_OBJECTS資料字典檢視之下的OBJ$ dictionary表的列定義僅存在於根目錄中。如圖2-4所示,每個PDB中的OBJ$表使用一種稱為元資料鏈接的內部機制來指向根目錄中儲存的OBJ$的定義.

    元資料鏈接對應的資料駐留在它的PDB中,而不是根中。例如,如果您在hrpdb中建立表mytable並向其新增行,那麼這些行將儲存在PDB資料檔案中。PDB和根中的資料字典檢視包含不同的行。例如,描述mytable的新行存在於hrpdb中的OBJ$表中,而不在CDB根中的OBJ$表中。因此,查詢CDB根中的DBA_OBJECTS和hrdpbobjects中的DBA_OBJECTS會得到不同的結果.

  • Data links

    Note:

    在Oracle資料庫12c版本1(12.1.0.2)中,資料鏈接被稱為物件連結。

    在某些情況下,Oracle資料庫僅在應用程式根中儲存物件的資料(不僅僅是元資料)一次。應用程式PDB使用一種稱為資料鏈接的內部機制來引用應用程式根中的物件。建立資料鏈接的應用程式PDB也儲存資料鏈接描述。資料鏈接繼承它引用的物件的資料型別.

  • Extended data link

    擴充套件資料鏈接是資料鏈接和元資料鏈接的混合。與資料鏈接類似,擴充套件資料鏈接引用應用程式根中的物件。但是,擴充套件的資料鏈接也引用了應用程式PDB中的相應物件。與元資料鏈接類似,應用程式PDB中的物件從應用程式根中的對應物件繼承元資料。
    在應用程式根中查詢時,擴充套件的資料鏈接物件僅從應用程式根獲取行。然而,當在應用程式PDB中查詢時,擴充套件的資料鏈接物件從兩個appli中獲取行.

oracle資料庫自動建立和管理到CDB$ROOT的元資料和資料鏈接。使用者不能新增、修改或刪除這些連結.

See Also:

Parent topic: Data Dictionary Architecture in a CDB

2.1.3.3 Container Data Objects in a CDB

容器資料物件是包含與多個容器或整個cdb相關的資料的表或檢視.

容器資料特權支援一個通用需求,其中多個PDBs駐留在一個CDB中,但是具有不同的本地管理需求。例如,如果應用程式dba不想在本地進行管理,那麼他們可以在適當的檢視上向普通使用者授予容器資料特權。在這種情況下,管理員可以訪問這些PDBs的資料。相反,不希望CDB管理員訪問其資料的PDB管理員不會授予容器資料特權.

容器資料物件的例子是oracle提供的以V$和CDB_開頭的檢視。所有容器資料物件都有一個CON_ID列。下表顯示了此列值的含義

Table 2-1 Container ID Values

Container ID Rows pertain to

0

Whole CDB, or non-CDB

1

CDB$ROOT

2

PDB$SEED

All Other IDs

User-created PDBs, application roots, or application seeds

在CDB中,對於每個DBA_檢視,都存在一個相應的CDB_檢視。CDB_檢視的所有者就是相應的DBA_檢視的所有者。下圖顯示了不同類別的字典檢視之間的關係:

Figure 2-5 Dictionary Views in a CDB(下面這個圖太經典了,必須瞭解

Description of Figure 2-5 follows
Description of "Figure 2-5 Dictionary Views in a CDB"

測試:

建立了3,4,5三個pdb,每個pdb中的sys使用者下建立test表(orclpdb中的test使用者下也建立了個test表),cdb中也建立了sys.test表

在根下查詢的層級關係如下圖

select 'CDB_',a.CON_ID,(select name from v$containers where con_id=a.CON_ID),a.* from cdb_tables  a where TABLE_NAME='TEST';
select 'DBA_',a.* from dba_tables  a where TABLE_NAME='TEST';
select 'ALL_',a.* from all_tables  a where TABLE_NAME='TEST';
select 'USER_',a.* from user_tables a where TABLE_NAME='TEST';

測試完畢。

 

噹噹前容器是PDB時,使用者只能檢視當前PDB的資料字典資訊。對於連線到PDB的應用程式,資料字典與非cdb一樣出現。但是,噹噹前容器是根容器時,普通使用者可以查詢CDB_檢視,以檢視根容器的元資料和該使用者有權使用的PDBs的元資料。

Note:

當查詢從根容器,CDB_和V $隱式轉換資料檢視AL32UTF8字符集。如果一個字符集需要更多位元組來表示一個字元轉換為AL32UTF8時,如果檢視列寬不能適應特定的PDB資料,那麼資料截斷是可能的.

下表顯示了涉及CDB_檢視查詢的場景。每行描述在前一行的操作之後發生的操作.

Table 2-2 Querying CDB_ Views

Operation Description
SQL> CONNECT SYSTEM
Enter password: ********
Connected.

The SYSTEM user, which is common to all containers in the CDB, connects to the root (see "Common Users in a CDB").

SQL> SELECT COUNT(*) FROM CDB_USERS 
WHERE CON_ID=1;

COUNT(*)
--------
      41

SYSTEM queries CDB_USERS to obtain the number of common users in the CDB. The output indicates that 41 common users exist.

SQL> SELECT COUNT(DISTINCT(CON_ID)) 
FROM CDB_USERS;
 
COUNT(DISTINCT(CON_ID))
-----------------------
                      4

SYSTEM queries CDB_USERS to determine the number of distinct containers in the CDB.

SQL> CONNECT [email protected]
Enter password: ********
Connected.

The SYSTEM user now connects to the PDB named hrpdb.

SQL> SELECT COUNT(*) FROM CDB_USERS;
 
  COUNT(*)
----------
        45

SYSTEM queries CDB_USERS. The output indicates that 45 users exist. Because SYSTEM is not connected to the root, the CDB_USERSview shows the same output as DBA_USERS. Because DBA_USERS only shows the users in the current container, it shows 45.

這個實驗比較好做,看一下就瞭解了

SQL> select count(*) from cdb_users;                       
  COUNT(*)                                                 
----------                                                 
       147                                                 
                                                           
SQL> select con_id,count(*) from cdb_users group by con_id;
    CON_ID   COUNT(*)                                      
---------- ----------                                      
         1         35                                      
         5         38                                      
         4         36                                      
         3         38                                      
                                                           
SQL> alter session set container=orclpdb;                  
Session altered                                            
                                                           
SQL> select con_id,count(*) from cdb_users group by con_id;
    CON_ID   COUNT(*)                                      
---------- ----------                                      
         3         38                                      
                                                           
SQL>                                              

 

See Also:

"About CDB and Container Information in Views" to learn more about container data objects

Parent topic: Data Dictionary Architecture in a CDB

2.1.3.4 Data Dictionary Storage in a CDB

The data dictionary that stores the metadata for the CDB as a whole is stored only in the system tablespaces.

儲存特定PDB元資料的資料字典儲存在專用於此PDB的自包含表空間中。PDB表空間包含應用程式後端的資料和元資料。因此,每一組資料字典表都儲存在自己的專用表空間集中.

See Also:

Parent topic: Data Dictionary Architecture in a CDB

2.1.4 Current Container

對於給定的會話,當前容器是會話執行的容器。當前容器可以是CDB根、應用程式根或PDB。
每個會話在任何時候都只有一個當前容器。由於每個容器中的資料字典是獨立的,Oracle資料庫使用當前容器中的資料字典進行名稱解析和許可權授權.

See Also:

"About the Current Container"

Parent topic: Overview of Containers in a CDB

2.1.5 Cross-Container Operations

跨容器操作是一個DDL或DML語句,同時影響多個容器。
只有連線到CDB根或應用程式根的公共使用者才能執行跨容器操作。

跨容器操作可能會產生影響:

  • The CDB itself

  • Multiple containers within a CDB

  • Multiple phenomena such as common users or common roles that are represented in multiple containers

  • A container to which the user issuing the DDL or DML statement is currently not connected

跨容器DDL操作的例子包括使用者系統通常授予另一個普通使用者特權(參見“在CDB中通常授予的角色和特權”),以及ALTER資料庫……適用於整個國開行的收回語句.

當您連線到CDB根或應用程式根時,您可以執行單個DML語句來修改容器中多個PDBs中的表或檢視。資料庫從DML語句中指定的CON_ID列的值推斷目標PDBs。如果沒有指定CON_ID,則資料庫使用ALTER PLUGGABLE資料庫容器預設目標語句指定的CONTAINERS_DEFAULT_TARGET屬性。

Example 2-3 Updating Multiple PDBs in a Single DML Statement

在本例中,您的目標是將country_name列設定為sh.salestable中的值USA。這個表存在於兩個單獨的PDBs中,容器id分別為7和8。兩個pdb都在名為saas_sales_ac的應用程式容器中。您可以作為管理員連線到應用程式根目錄,並按照如下方式進行更新:

CONNECT [email protected]_sales_ac
Password: *******

UPDATE CONTAINERS(sh.sales) sal 
  SET sal.country_name = 'USA' 
  WHERE sal.CON_ID IN (7,8);

In the preceding UPDATE statement, sal is an alias for CONTAINERS(sh.sales).

這個操作在Application Containers中操作,在普通cdb的pdbs之間沒任何影響,僅僅是處理自己的current表,已測試

後面測試Application pdb時,測試一下,目前還沒了解清楚

 

 

See Also: