Issues faced with XML (Objt-Rel) - Plan to move to Binary XML (schema-less)

Question

Hi All,
Our Production DB has Oracle XMLDB implementation using 9 XMLDB Object-Relational
Tables. These have been implemented almost since a year, and we faced several issues,
have listed some of the most important ones:
Obviously it is Object-Relational implementation, so we have 4-5 XSDs to start with that
support the Object-Relational schema
1) copyEvolve Issues : Due to changing Business Requirements constantly, we had to constantly
and continuously modify/upgrade XSDs and then use "copyEvolve" to apply new XSDs
Encountered several issues with CopyEvolve
2) "Home-grown" solution to evolve XSD/Schema:
We came up with our own Solution to migrate/evolve XSD schema.
a) Backup all data from 9 XML DB Tables to 9 CLOB Tables (data is thus "dereferenced" and "delinked"
from underlying XSDs
b) Since data is backed up to CLOB Tables, go ahead and drop the entire schema and register
new XSDs and recreate Tables. (GRANTS and PUBLIC SYNONYMS reappled, needless to say)
c) Reload data from backed up CLOB Tables to newly created XMLDB (Obj-Relational) Tables
Above approach (without "copyEvolve") has worked fine so far and helped in each Release/ every migration
With our data sets becoming increasingly huge, downtime is not sufficient to follow this successful, home-grown
approach and as a result we would like to get away from Object-Relational XMLDB Tables altogether.
3) Our Application currently uses XPath heavily on all 9 XMLDB Tables and we understand XPath is already
deprecated by Oracle (as of 11.2.0.2)
We are seriously considering doing the following:
1) Migrate all 9 XMLDB Tables and modify underlying Storage from "Object-Relational" to Binary XML (Schema-less)
2) Modify Appln code with all XPath replaced by corresponding XQuery constructs
3) Replace existing "B-TREE" based Indexes in Object-Relational XMLDB Tables with either a) Indexes on Virtual DB Columns to enforce Primary Key and Unique Constraints and b) XMLIndex on all other Non-Unique Columns instead of
the corresponding "B-TREE" based Indexes
What we hope to achieve with the above:
1) Eliminate XSD Usage completely (and copyEvolve nightmares thereby)
2) Eliminate Usage of XPath totally
3) Better Performance overall :-)
Would like to get some advice and feedback on our Proposed Plan and mainly are we taking the
right direction especially in respect of Performance, Point 3) listed above
Any feedback or tips would be truly appreciated
Regards and Thanks
Auro

Answer 1

WRT to XPATH Vs XQuery.
1. XPATH is a subset of XQuery.. Any XPATH expression is, by definition, an example of simple XQuery expression, so XPATH is not depricated.
2. What we are depricateing are the older, oracle specific XML operators (EXTRACT(), EXTRACTVALUE(), EXISTSNODE()), that ONLY support XPATH. We are depricating these in favour of the new SQL/XML operators (XMLTABLE, XMLQUERY, XMLEXISTS) defined by the SQL standards committee. These operators provide support for the full XQquery standard, and implicitly all of the XPATH expressions that were supported by the older operators. This menas we strongly recommned that new code, developed to work with 11g make use of nrw newer operators. Personally I cannot see a point where we would ever consider de-supportting the older operators, we are well aware of how much code makes use of them.
What this means is that any code that is written using the older operators will continue to work, unmodified. However should a bug surface in the use of the older operators, we would strongly recommend that the code in question be migrated to the new operators as part of the remidiation process.
Also, once the initial pain of learning the new syntax is overcome, I truely believe that the new operators result in much more efficient and mantainable code, so taking the time to do code renevation when possible will probably pay off in the long term...
WRT to moving away from Schema-Based OR storage, I would look at the kind of changes you have made to the XML Schema. If they are the kind of changes that would be supported by in-place evolution in 11g then you might want to re-consider this. If, on the other hand you are regularly making changes to the XML schema that are not backwardsly compatable with your older XML Schema then Schema-Based binary XML storeage (which is more flexible than Schema-Based Object-Relational storage) or even non-schema based Binary XML may be a better choice for your applicaiton..
I would experment by registering the oldest version of your XML Schema in 11gR2, and then testing each of the evolutions you have gone through to see if 11GR2 inplace evolution would have managed them. Also, ask yourself do you expect your XML Schema to keep changing so drastically moving forward, or were some of these changes the results of the growing pains associated with learning how to use XML schema effectively. BTW the approach you outline is effectively what CopyEvolve is doing under the covers...
Bear in mind that for the use-cases Object-Relational storage addesses, when all of the XPATH expressions are correctly re-written into SQL operations on the underlying tables, and where the majority of queries end up accessing or updating leaf-level nodes in the XML, it is unlikely that a Binary XML / Unstructured XML Index combination will deliver similar performance. If you are only accesss a small subset of the leaf-level nodes, creating structured XML Indexes that project out the nodes in question may be able to deliver similar performance to an Object-Relational storage model, but you will need to get the index definitions correct.
-Mark
Edited by: mdrake on Mar 7, 2011 7:40 PM