Xmlnamespaces clause of xmltable: Does it go over the internet for xsd?

Question

Hi,
I've got a query from xmltable passing an xmltype variable.
Something like this:
select id, name, data
From XMLTable(XMLNamespaces ('https://www3.somesite.es/bla/bla/bla/thexsd.xsd' as "n1" ,
                                    'https://www3.somesite.es/bla/bla/bla/otherxsd.xsd' as "co") ,
                     '/n1:some/tag' passing l_my_xmltype_var
COLUMNS id        NUMBER(20)      PATH '//n1:id' ,
                             name        VARCHAR2(9)     PATH '//n1:name' ,
                             data     VARCHAR2(125)   PATH '//co:datatxt') XThis query is run in a loop, and we are trying to improve its performance.
Dba tells me that everytime the query is run, it has to retrieve both xsd over the internet.
1. Is this true?
2. If it is ... Could I store the xsds local or even inside the database? (I've heard something about schema registering)
Thanks

Answer 1

julius wrote:
The actual query has over 75 columns. Its major consumption is spent on java, so I have to assume that is due to the underneath parsing process of xmltable.
You are OR doing something (horribly) wrong OR should upgrade to a database version bigger than or equal to 10.2.0.3.x
PLEASE post your database version (all digits!)
Do you mean that, even working with a local xmltable passing an xmltype variable (not an actual structured xml table), registering the schema will do good to the performance?Yep, for example avoiding those JAVA calls... validation via registered XML Schema's is optimized if not only due to its based kernel code, that is C - code
I suppose I would have to:
1. Register the xsd
2. Reference it when I create the xmltype variable (adding the second parameter to the xmltype function).
Correct.
Then, during the xmltable processing, the engine will be smart enough to use the registered xsd info to improve the query performance? Ok, I'm a bit skeptical, but will give it a try.
I will also try to help the processing by specifying the full tree path instead of using "//tag".
It will make a difference (providing you are at least on 10.2.0.3.x regarding using XMLTABLE, that is the XQuery engine...
As a curiosity, all this query optimization quest came when - after a modification - performance of the query dropped from 5 seconds to 90 seconds. Things went south when I added an * in the select list instead of refering the columns with their names. So it doesn't seem a good idea to use * with a high column number xmltableCould be, but can't tell. This kind of issues are depending on a lot of parameters and environment settings. It could be a bind issue or...or...
That's one of the reasons we need the database version to give you a better answer...
Edited by: Marco Gralike on Jun 8, 2011 11:17 AM