大家下午好，最近在网上认识一个妹子，叫XDB，偏偏她和我闹别扭，失效了。所以我通过去她老家MOS，多次明察暗访，研究了一些她的资料，大致摸清她的星座性格之后，得出了重建XDB的大致流程。以下是把我的研究过程与大家一起分享：
首先，就我的理解，和大家简单说说XDB是啥东东。根据官档的概述：
XDB又叫XML DB,主要的作用是用来高效率地处理XML类型的数据，提供本地的XML支持，包含存储、创建、访问、搜索、转换等功能。从oracle 9.2版本开始引进XDB概念与相关技术。
通常我们查询dba_registry视图，可喵到XDB这字眼，她姓Oracle，名XML Database。我也是这段时间才认识她，不过不够深入了解，来"日"方长……
同时在dba_users视图中，又邂逅她了，XDB Schema就是XDB 组件对应的用户，其用来存储相关对象。
又是套用了官档的说明，同时盗用了官网的XDB结构图，我才透过她的衣服，看到她的三围，这里贴出来跟大家一起YY……
在oracle中，XDB主要包含两个部分，一个是用来存储XML类型的表和视图，当然也可以对这些对象执行创建与DML操作；一个叫XDB仓库，是用来存放任何类型的documents，主要存放与XDB用户相关联的XML documents。然后这些documents可以通过HTTP 、WebDAV或FTP协议来操作，也可以JDBC方式来操作。
好了，欣赏完XDB的五官和三围，有性趣的我们可以看一下怎么调教XDB，下面我主要分享的就是ORACLE 10g怎么重建XDB。
额，差点忘记说明在什么情况下需要重建XDB，当然要有原因有证据啦，不然人家XDB会以为你性骚扰她，没事动她干嘛！证据主要也是藏在dba_registry视图中，若发现这个妹子的STATUS是INVALID的，那要小心了，你不动她都不行。
对了，因为XDB存储着与XMl相关类型的数据，这些对象会注册到XDB仓库中，所以XDB无效将可能导致其他依赖性的组件失效。比如ORDIM组件，因为Oracle Multimedia组件的信息是保存在XDB Schemas中的，所以XDB无效，也会导致Multimedia 组件无效。
接下来回归主题，重建XDB主要有两种方式：一种是Reload XDB。一种是Deinstalling and Reinstalling XDB。根据官档的说法，首先推荐的就是第一种--Reload XDB。
Reload 过程将重建所有的PL/SQL 包和类型，Reload 比removal和reinstall 更具有优势。在考虑重建之前可以先尝试Reload。同时因为xdbreload.sql 在xdbpatch.sql脚本中会自动调用，所以可以运行xdbreload.sql脚本，也可以运行xdbpatch.sql 来创建所有的XDB 关联包。
当然，每个工程操作都具备风险，调教XDB也不例外，以下是此重建XDb工程实施过程中的以下前提说明、风险分析规避与回退等。
1、如果XDB的功能特性已经被使用，那在remove过程中，与XML相关的数据便会丢失，所以事先的备份与误操作之后的恢复是必须的。因为remove过程中会执行catnoqm.sql脚本，该脚本将会有如下操作：
a、删除所有存在XDB仓库中的信息和XDB用户。
b、导致这些注册到XDB用户里面的相关的XML类型的表或列永久失效，而且无法recover回来。
2、在第1点中也提到如果XDB的功能特性已经被使用。那怎么知道XDB已经不是处子之身了呢？这个很关键呀。莫慌，甲骨文为oracle 10g专门提供一个脚本，可验XDB之身，证XDB之名。这个sql脚本叫xdbusage10gcheck.sql，具体内容如下：
抱歉哈，这脚本有点长，要不咋们忽略脚本的内容，关注脚本的执行结果就好了伐。脚本执行完毕后会再当前目录生成一个SRDC_XDB_USAGE_CHECK_10G_%ORACLE_SID%_日期_时间.htm文件。用浏览器打开该文件发现主要有以下方面内容：
XDB Status/Version、OTHER DATABASE FEATURES、XDBCONFIG INFORMATION、XMLTYPE Tables、XMLTYPE Columns、XMLTYPE Views、Items built with XML API's、XML SCHEMAS、Repository Resources。Htm文件也太长，其实我们主要关注后面几个内容就行：
在XMLTYPE Columns的方框中，已经发现3个普通用户使用了该XDB功能。
在Items built with XML API's中，有两个包体使用了XDB。
综上所述，这XDB已经是二手货了喂！！！所以不建议使用removal和reinstall方式重建XDB。
3、第三点也就是刚才第一点中提到的，甲骨文强烈建议在执行removing/reinstalling XDB之前要做一个数据库全备。XDB仓库的信息被保存在XDB用户的几张内部表中，同时XDB用户还保存与其他用户XML类型相关的数据，所以这是一个有效的措施来进行回退操作。那备份XDB的方式有几种：
a、毋庸置疑，rman做一个全备是首选的途径
b、刚才前面也提到，XDB的相关数据可以通过http、ftp或者WebDAV协议来访问，那也可以使用折中方式来备份XDB 仓库里面的文件，可以连接XDB仓库并把相关文件复制到一个安全的路径进行冗余保存。(嘿嘿，这个尚未接触过)
c、可以通过物理Standby的方式来备份XDB的相关文件资源，比如利用dataguard为oracle做一个镜像数据库，不过dataguard 备库的也是通过rman工具进行初始化数据库的，所以第三个方式与第一个大同小异。
这里或许还会有人想到，oracle为啥没提到逻辑备份工具(export)，官档中也有说明，因为expdp或impdp的执行文件不支持XDB的数据，无法导出XDB仓库结构或这些元数据表和表结构，就是export备份full database，XDB用户的数据也会被跳过。
4、如果是在一个rac集群环境中，重建XDB操作中所有节点必须重启，否则可能导致实例内存结构不一致的问题。为啥还会与实例内存配置有关呢？我再细看一下XDB的特性，如下截图提到：
以上大致意思就是XDB可通过最优化的方式来减少对内存的请求，实现对实例内存结构进行管理并优化的功能。(在这里抛砖引玉哈，渴望大神解答)。
5、需经常关注XDB组件版本的兼容性与database一致，确保XDB的功能可用。
6、在决定重建XDB之前，要确认LD_LIBRARY_PATH / LIBPATH / SHLIB_PATH这三个环境变量设置正确，并确保$ORACLE_HOME/lib这个值处于环境变量的首位。那么以上这三个变量是否都要设置呢？下图可以得到答案(PS：需重启数据库与监听才能生效)：
7、XDB用户必须要对DBMS_LOB, UTL_FILE, DBMS_JOB, UTL_RAW 和 DBMS_SQL 这些包拥有执行权限。以上包默认是被赋予public，所以XDB用户自动获得执行权限，如果处于安全原因，以上包的public权限被去除，在重建XDB过程中将会报错并导致部分XDB对象失效。所以在重建XDB之前，以上包确保被赋予public，并在重建XDB成功之后，甲骨文推荐把以上包直接赋予给XDB并去除public权限。
8、在重建前需确保无以XDB命名的表和无任何同义词指向XDB的对象。否则，将可能导致报类似"ORA-01422: exact fetch returns more than requested number of rows"错误。详情可看文章ID 1332182.1。
(Doc ID 1332182.1) ORA-01422 from DBMS_XS_PRINCIPAL_EVENTS_INT DBA|ALL|USER_XSC_* and DBA|ALL|USER_XDS_*
好了，前面提到各种注意事项，做好充分准备之后，下面就可以理直气壮的调教XDB了，先讲甲骨文推荐的reload方式，再接着removal和reinstall的方式。(都基于10g)
1、reload方式比较简单，主要执行xdbrelod.sql脚本在重新编译对象完事儿。
spool xdbreload.log
connect / as sysdba
set echo on;
shutdown immediate;
startup upgrade;
@?/rdbms/admin/xdbrelod.sql
shutdown immediate;
startup;
@?/rdbms/admin/utlrp.sql
spool off
2、第二种removal和reinstall的方式则复杂很多。
a、首先确保数据库中不存在以下3个对象：
针对以上三个对象存在会导致removal和reinstall XDB报错的原因，官方解释如下：
以上几个对象是为了追踪对象的创建过程，在重建XDB过程中，如果以上对象未被删除，任何被记录到触发器里面的对象，不管是否与XDB有关，都将被删除。
甲骨文专门提供以下脚本来确认以上3个对象是否存在并返回删除对象的命令，视情况执行即可。
b、重建XDB之前，确保JAVA Virtual Machine (JVM)和XDK为VALID状态。
c、确保存储XDB信息的表空间有只是350M以上的空闲空间，以下存储过程可以鉴定：
d、确保SHARED_POOL_SIZE 和JAVA_POOL_SIZE参数值在250M以上。
接下来就是正式重建过程：
首先执行catnoqm.sql 脚本Removal XDB
然而，在执行以上脚本过程中，sys用户里面一些与XDB相关的对象不会被删除，比如SYS.KU$_%视图会被置成失效状态。同时CATALOG和CATPROC组件也会失效。如下图：
官档中提到这是正常情况，这些对象的状态或者定义在XDB重装过程中会被改变，但依然存在，因为这些对象也被其他组件使用，比如DBMS_METADATA。在Removal XDB之后，需运行catmeta.sql来修复。
在Removal XDB之后，接下来要做的就是执行catqm.sql脚本重新安装XDB
执行这个脚本需要带3个参数，第一是XDB的密码，第二是XDB默认的表空间(不可指定SYSTEM, UNDO 和 TEMP为默认表空间，表空间必须已经存在，如果希望XDB参数存储更多数据，可以独立创建一个名为XDB的表空间并指定)。第三个是XDB临时表空间(可以默认TEMP)。以下为重新安装XDB的例子：
spool xdb_install.log
set echo on;
connect / as sysdba
shutdown immediate;
startup;
@?/rdbms/admin/catqm.sql xdb XDB TEMP
@?/rdbms/admin/utlrp.sql
spool off
最后，使用removal和reinstall方式重建XDB之后，与XDB相关的Multimedia/interMedia和Spatial也须被重建，其实就是把这些信息再次注册到XDB。可遵循以下命令进行注册：
最终为验证阶段，
set echo on;
connect / as sysdba
set pagesize 1000
col comp_name format a36
col version format a12
col status format a8
col owner format a12
col object_name format a35
col name format a25
select comp_name, version, status from dba_registry;
以上status结果为VALID。
检查失效对象
select owner, object_name, object_type, status
from dba_objects
where status = 'INVALID'
and owner in ('SYS', 'XDB');
如果仍有失效对象，可执行utlrp.sql脚本进行编译，如果执行编译过程中报类似
PLS-00201: identifier *** must be declared的错误。可把***的权限赋予给XDB用户在重新编译即可。比如：
SQL> GRANT EXECUTE ON DBMS_LOB TO XDB;SQL> GRANT EXECUTE ON UTL_FILE TO XDB;
SQL> @?/rdbms/admin/utlrp.sql
报告组织，我的分享完毕，请批评。
(PS：这是一份研究性分享，设计过程与原理颇多，我认识XDB这个妹子也不久，如果大家和我一样有性趣，千万别跟我请教哈，我只能和大家一起探讨)！！！
Q&A
1、Xdb算不算oracle 的冷技术？
@华春_事业部PM 第一个问题，按照对官档的理解，XDB Repository的内容可以通过FTP等方式访问，并在web 浏览器中以文件或者文件夹的形式体现出来。参考下图：
而且文中也提到XDB Repository的备份可以通过RMAN cold database backup或者FTP等协议访问XDB repository并手动复制文件到其他目录。所以我觉得算是冷技术。
2、你这个case 中Xdb 有问题的现象是怎么样的呢
@华春_事业部PM 第二个问题，其实刚才我在分享开头部分提到了一下，不过可能没有着重说明，真抱歉！！这是以下刚才分享说明的问题现象
类似的现象有如下：
