Oracle 12c R2版本 Application Containers 特性(一)
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)的三种形式。