Oracle 12c R2版本 Application Containers 特性(一)

“Application”

在Application Container特性下还有另一个概念，被命名为“Application”，我们可以把“Application”理解为一个区域，“Application”只能创建在Application root中，其内可以创建表、视图、函数等公共对象，然后可在Application PDBs中使用sync同步命令，来实现“Application”内的公共对象共享到Application PDBs中。

本篇文章中，通过"Application Root/PDBs"与"Application"的创建开始带你认识Application Container特性，在第二篇中将带你了解“Application”内的公共对象（Application Common Objects）,并通过实验让你对其有一个更加直观的认识。

Application root的创建

Application root与普通的PDB创建语句相似，在创建语句中需要指定“as application container”子句。

首先我们先设置db_create_file_dest：

创建一个名qdatacon1的Application root：

这样一个名为qdatacon1的Application root就已经成功创建 ，可以通过视图dba_pdbs.application_root字段查看是否是Application root，如下：

dba_pdbs.application_root字段为YES

将QDatacon1打开：

注意，当在使用Application Containers特性时需要使用数据文件的OMF的管理方式，虽然在不使用OMF管理时依然可以成功创建Application root以及Application PDBs，但当“Application”内包含表空间后，在Application PDBs中进行同步“Application”时会报ORA-01537错误，无法将“Application”内的表空间同步到Application PDBs中。错误代码如下：

Application root的基本管理与普通的PDB基本上没有区别, 包括Application root的cloning/unplug/plugin等。但需要注意as application container的使用，比如下面unplug/plugin的过程：

当然，如果你想将Application root拔出后，以普通PDB的方式插入CDB中，那么去掉

as application container子句即可。

Application PDBs的创建

Application PDB在创建时必须连接到相应Application root中，而不是CDB root，当连接到Application root中时，只需按照创建普通PDB的方式创建即可，无需额外子句指定，创建完成的PDB既是相应Application root中的Application PDB。

切换到Application root中创建Application PDB:qdcpdb1

切换到CDB中:

在CDB$root中通过show pdbs显示时，可以看到的Application PDB与普通的PDB并没有什么区别。

可以通过cdb_pdbs视图，来查看Application PDB属于哪个Application root

当Applicatoin PDB创建成功，可以使用sync命令将它与Application root中定义的Application进行同步。

alter pluggable database application all sync;

Applications

文章的开篇提到，可以把“Application”做为一个区域来理解，而“Application”只能在Application root中创建及管理，相关命令如下：

application_clauses::=

在“Application”的维护命令中可能最常用的就是install、patch、upgrade以及uninstall，下面对三个命令做简单描述。

Install an Application

当使用alter pluggable database带有begin install子句时，即开始一个“Application”的安装，这里可以理解为一个区域的开始，当安装完成后在Application PDB中使用sync命令同步相应的“Application”将会被自动安装在本PDB内。

QDatacon1:

这样我们开始了一个qdcon1_reg1的“Application”，使用end install命令封闭qdcon1_reg1，如下：

可以通过dba_applications视图查看，已经安装的Application，如下：

Application安装完成后，可以在该Application root下的Application PDB中使用sync命令来进行同步，如下:

查看dba_applications视图，确认qdcon1_reg1是否已经安装

可以看到qdcon1_reg1已经安装完成，安装完成后qdcon1_reg1中的公共对象会以特定的方式被共享到相应的Application PDB中，如下：

表tdata已经被共享到qdcpdb1中。

在Application root中可以通过dba_app_pdb_status视图，查看Application被安装到哪些Application PDB中，如下：

Patch an Application

在上面的小结中，当我们使用end install子句将“Application”封闭后，如果想再次在“Application”中创建对象(table/view/packages/sequence等)，以及对“Application”内已经存在的对象进行alter操作时，我们可以使用patch子句对现有的“Application”进行修补操作。

如下示例，开始一个patch，并且在application内创添加表以及更改现存表的表结构：

删除Application内的表:

删除失败

结束patch:

查看patch信息

在qdcpdb1中同步qdcon1_reg1

tdata的表结构与texte表均同步完成

Upgrade an Application

对“Application”我们可以使用patch来对其进行修补操作，但修补操作只限添加/更改等，无法对已经存在“Application”中的公共对象进行删除操作，如果我们想对公共对象进行删除操作，可以使用UPGRADE子句对现有的“Application”进行升级，在升级的过程中，Oracle会首先自动创建Application root的Clone版本，Clone版本创建完成后，Application PDBs将指向Clone版本的Application root，“Application”将继续执行升级操作，升级完成之后，Application root的Clone版本将继续被保留，并且为不同步“Application”的Application PDB提供服务，同步“Application”后的Application PDB将指向升级后的Application root。

升级现有的qdcon1_reg1:

F1956732192_4_1即为qdatacon1的clone版本

删除tdata表，并且创建新表tmeta：

结束升级，并查看版本信息：

在qdcpdb1中同步qdcon1_reg1

tdata被删除/tmeata的创建已同步到qdcpdb1中。

Uninstall an Application

“Application”的卸载后并不会从数据字典中将该“Application”删除，它会被标记为UNINSTALL，以便“Application”不可以进行upgrade/patch/uninstall等操作，当uninstall命令发出后，需要将该“Application”中包含的对象全部删除。

uninstall同样会产生clone版本的Application root

删除对象且结束uninstall：

因为对象并没有全部删除，导致end uninstall失败，下面继续drop用户和表空间：

查看被uninstall的qdcon1_reg1状态：

在qdcpdb1中查看公共对象情况：

表texte是extended data-linked方式，数据存储在Application root的qdata_tbs中，因为qdata_tbs已经被删除，所以在qdcpdb1中查询时报错，而tmeta为metadata-linked方式，数据存储在本地，所以可以在未做同步时可以查询。

同步qdcon1_reg1：

同步完成。

本篇文章先到这里，下一篇文章将讲解“Application”内公共对象(Application Common Objects)的三种形式。