964183 wrote:Would also need database version (exact) to be more precise, but guessing because the path table and secondary index are so big, that you created the unstructured XMLIndex without using PATH SUBSETTING (include/exclude statements in the param section of the create/alter xmlindex syntax). This approach would be like indexing all columns on a relational table and then even add some more. The path table would have been much smaller if you would have, using path subsetting, only indexed the bits and pieces in the XML that actually was used a lot in predicates or other DML.
I am an Oracle dba new to xml db,we have binary storage with 4schemas ,Right now indexing on 2gb table takes like 20GB on Path table and secondary xml index.
I want to change the table storage without disturbing the application developement just the xmltype column into Object relational and merged all the 4xml schemas into master schema.Right now i want to insert the data from old tables which had different URlYou are comparing apples with oranges regarding XMLType implementation and use-cases. Have a look at the whitepaper on the XMLDB main page referencing "Oracle XML DB : Choosing the Best XMLType Storage Option for Your Use Case (PDF) Jan 2010".
.How I can improve performance wihtout having 20Gb on secondary index objects.Please advice me .