Migrate B-Tree Indexes of XML O-R Table to XMLIndex on Binary XML Table

We need slight help on how to migrate existing B-TREE Indexes from XML Obj-Rel Tables to XMLIndex on new XML Binary Tables
We use searches on Nested Collection Elements (defined unbounded in XSD)
and related DDL for XML Obj-Rel Tables is shown below:
CREATE TABLE TNMAB_AGREEMENT_XML
AGREEMENT_XML xmltype,
CREATE_BY     VARCHAR2(15) NULL ,
CREATE_DT_GMT     TIMESTAMP NULL ,
CREATE_CLIENT_ID VARCHAR2(65) NULL ,
UPDATE_BY     VARCHAR2(15) NULL ,
UPDATE_DT_GMT     TIMESTAMP NULL ,
UPDATE_CLIENT_ID VARCHAR2(65) NULL ,
PIC_VERSION_NUM     NUMBER(20) NULL
XMLTYPE COLUMN AGREEMENT_XML XMLSCHEMA "AB_Agreement_V1_XMLDB.xsd" ELEMENT "Agreement"
VARRAY AGREEMENT_XML.XMLDATA."SHIPPING_PARTY_GROUPS"
STORE AS TABLE SHIPPING_PARTY_GROUPS_NT
(PRIMARY KEY (NESTED_TABLE_ID, ARRAY_INDEX) ENABLE)
VARRAY SHIPPING_PARTIES
STORE AS TABLE SHIPPING_PARTIES_NT
(PRIMARY KEY (NESTED_TABLE_ID, ARRAY_INDEX) ENABLE)
VARRAY AGREEMENT_XML.XMLDATA."SALES_OFFICE_CODES"."STRING_WRAPPERS"
STORE AS TABLE SALES_OFFICE_CODES_NT
(PRIMARY KEY (NESTED_TABLE_ID, ARRAY_INDEX) ENABLE)
TABLESPACE TNMAB_XMLDB_ME_DATA;
Table has PK and Unique Index which for the Binary XML Table, it will be setup on Virtual Columns (to enforce
Unique Constraints)
We have 6 more Normal Indexes on this Table, some created on Nested Elements as shown below:
-- 4 Normal B-TREE Indexes on Leaf level Elements
create index TNMAB_AGREEMENT_XML_IDX1 on TNMAB_AGREEMENT_XML (AGREEMENT_XML.XMLDATA."AGREEMENT_VERSION")
tablespace TNMAB_XMLDB_ME_INDX;
create index TNMAB_AGREEMENT_XML_IDX2 on TNMAB_AGREEMENT_XML (AGREEMENT_XML.XMLDATA."LAST_UPDATED_BY")
tablespace TNMAB_XMLDB_ME_INDX;
create index TNMAB_AGREEMENT_XML_IDX3 on TNMAB_AGREEMENT_XML (AGREEMENT_XML.XMLDATA."LAST_UPDATED")
tablespace TNMAB_XMLDB_ME_INDX;
create index TNMAB_AGREEMENT_XML_IDX4 on TNMAB_AGREEMENT_XML (AGREEMENT_XML.XMLDATA."CREATION_DATE")
tablespace TNMAB_XMLDB_ME_INDX;
--2 Indexes created on Nested Table (Collection)
create index TNMAB_AGREEMENT_XML_NT_IDX1 on SALES_OFFICE_CODES_NT NT(NT.STR_VAL, NT.NESTED_TABLE_ID)
tablespace TNMAB_XMLDB_ME_INDX;
create index TNMAB_AGREEMENT_XML_NT_IDX2 on SHIPPING_PARTIES_NT NT(NT.CUSTOMER_HOLDER.SAP_ID, NT.NESTED_TABLE_ID)
tablespace TNMAB_XMLDB_ME_INDX;
Could you please let us know how we should migrate above Indexes to XMLIndex format.
Specifically, not sure how the last 2 Indexes on Nested Tables is to be defined.
Any help or resources pointing to this would be greatly appreciated.
Thanks for the help,
Auro

Can't tell due to using XMLDATA pseudocolumn. Would need a sample XML document structure that can be used to define the XPATH structure and ALSO need the database version you are using (ALL digits) to see if you would need / can use STRUCTURED or UNSTRUCTURED XMLINDEX indexes.
See the XML Index section (http://www.liberidu.com/blog/?page_id=441) on for guidance and/or of course the XMLDB Developers Guide for your database version
http://www.liberidu.com/blog/?page_id=441
XMLIndex (part 1) – The Concepts
XMLIndex (Part 2) – XMLIndex Path Subsetting
XMLIndex (Part 3) – XMLIndex Syntax Dissected
XMLIndex Performance and Fuzzy XPath Searches
Structured XMLIndex (Part 1) – Rules of Numb
Structured XMLIndex (Part 2) – Howto build a structured XMLIndex
Structured XMLIndex (Part 3) – Building Multiple XMLIndex Structures

Similar Messages

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

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

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

Binary XML lightest-weight transform?

Database 11.2.0.2.
I have a set of small XML documents stored in a schema-based binary XML column (pubdate, author, language, title, etc.).
I'm using the XML, combined with a bit of longer (blob-based) text to generate a text index using a user_datastore.
I have a requirement to (a) change the names of one or two XML tags (to help the indexer disambiguate between two elements, for example), and to change the case of one or two elements (to make the language all uppercase, for example).
What's the most efficient way to make these types of changes -- hopefully within PL/SQL, since that is what the current datastore procedure uses.
The procedure currently looks like:
create or replace procedure GenerateText(pRID in ROWID, pTextClob IN OUT NOCOPY CLOB) as
begin
    for x in (select docid, XMLSerialize(CONTENT docxml as clob) as xmldata
              from docs where rowid = pRID)
    loop
        dbms_lob.copy(pTextClob, x.xmldata, DBMS_LOB.LOBMAXSIZE);
        for y in (select doctext from doc_components where docid = x.docid and length(doctext) > 0)
         loop
          dbms_lob.append(pTextClob, y.doctext);
         end loop;
    end loop;
end GenerateText;XMLTRANSFORM looks like the appropriate method, but it's not something I've used before. If it's the best way, do you have any suggestions on a quick primer on how to build the appropriate XSLT?

#1. We need to see the code that is being used to invoke the stylesheet.
#2. We need to see the document that is being transformed...
It's most likely a bug in 9g which has been fixed in 11g...

Validating XML stored in CLOB without exceptions for malformed XML

Hello,
I have a CLOB column that should contain an XML which conforms to a registered XSD schema. However, there might also be cases, in which the CLOB content violates the XSD or is not even wellformed XML at all. Now I am trying to find a way to either
identify all records, for which the CLOB contains well-formed XML that validates against my schema (find all "good" records) , or
find all the other records (those with either no XML at all, malformed XML, or XML that does not validate against the XSD) (find all "exceptions")
The problem is that all XML-validation methods I know of (e.g. isXmlValid or XmlType.isSchemaValid) require an XmlType instance, and that records, for which no proper XmlType can be constructed from the CLOB, because the CLOB does not contain well-formed XML, will cause an exception, rather than just returning false or NULL or something else I could filter out.
Is there a way to do something like
SELECT * FROM MYTABLE where <MY_XML_COL is wellformed XML> and <MY_XML_COL validates against 'blabla.xsd'>
without getting an ORA-31011 or whatever other kind of exception as soon as there is a row that does not contain proper XML?
Thank you...

So here is my example - this will be quiet a long post now...
First, I create the table with the CLOBs
CREATE TABLE ZZZ_MINITEST_CLOB (
ID NUMBER(10,0) NOT NULL ENABLE,
XML_DOC CLOB,
REMARKS VARCHAR2(1000),
CONSTRAINT PK_ZZZ_MINITEST_CLOB PRIMARY KEY (ID)
) NOLOGGING;
Then I insert some examples
INSERT INTO ZZZ_MINITEST_CLOB VALUES (
10,
'<minitest_root>
<l2Node>
<l2Num>1</l2Num>
<l2Name>one.one</l2Name>
</l2Node>
<minitestId>1</minitestId>
<minitestName>One</minitestName>
</minitest_root>',
'Basic valid example');
INSERT INTO ZZZ_MINITEST_CLOB VALUES (
20,
'<minitest_root>
<l2Node>
<l2Num>1</l2Num>
<l2Name>two.one</l2Name>
</l2Node>
<minitestId>2</minitestId>

</minitest_root>',
'Invalid - minitestName element is missing');
INSERT INTO ZZZ_MINITEST_CLOB VALUES (
30,
'<minitest_root>
<l2Node>
<l2Num>1</l2Num>
<l2Name>three.one</l2Name>
</l2Node>

<minitestName>Three</minitestName>
<minitestId>3</minitestId>
</minitest_root>',
'Invalid - minitestName and minitestId are switched');
INSERT INTO ZZZ_MINITEST_CLOB VALUES (
40,
'<minitest_root>
<l2Node>
<l2Num>1</l2Num>
<l2Name>four.one</l2Name>
</l2Node>
<l2Node>
<l2Num>2</l2Num>
<l2Name>four.two</l2Name>
</l2Node>
<l2Node>
<l2Num>3</l2Num>
<l2Name>four.three</l2Name>
</l2Node>
<minitestId>4</minitestId>
<minitestName>Four</minitestName>
</minitest_root>',
'Valid - multiple l2Node elements');
INSERT INTO ZZZ_MINITEST_CLOB VALUES (
50,
'<minitest_root>
<l2Node>
<l2Num>1</l2Num>
<l2Name>five.one</l2Name>
</l2Node>
<l2Node>
<l2Num>2</l2Num>
<l2Name>five.two</l2Name>
</l2Node>
<minitestId>4</minitestId>
<minitestName>Five</minitestName>

<l2Node>
<l2Num>3</l2Num>
<l2Name>five.three</l2Name>
</l2Node>
</minitest_root>',
'Invalid - another l2Node node, but too far down');
INSERT INTO ZZZ_MINITEST_CLOB VALUES (
60,
'something that is not even xml',
'Invalid - something that is not even xml');
INSERT INTO ZZZ_MINITEST_CLOB VALUES (
70,
NULL,
'Invalid - good old NULL');
INSERT INTO ZZZ_MINITEST_CLOB VALUES (
80,
'<minitest_root>
<l2Node>
<l2Num>1</l2Num>
<l2Name>
<unexpected_node>
this one should not be here!
</unexpected_node>
</l2Name>
</l2Node>
<minitestId>8</minitestId>
<minitestName>Eight</minitestName>
</minitest_root>',
'Invalid - unexpected addl node');
INSERT INTO ZZZ_MINITEST_CLOB VALUES (
90,
'<something> that has tags but is no xml </either>',
'Invalid - something that has tags but is no xml either');
COMMIT;
Next I register the XSD...
BEGIN
DBMS_XMLSCHEMA.REGISTERSCHEMA(
'http://localhost/minitest.xsd',
'<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:oraxdb="http://xmlns.oracle.com/xdb" oraxdb:storeVarrayAsTable="true" oraxdb:schemaURL="http://localhost/minitest.xsd">
<xs:element name="minitest_root" oraxdb:SQLName="MINITEST_ROOT" oraxdb:SQLType="MINITEST_TYPE" oraxdb:defaultTable="" oraxdb:tableProps="NOLOGGING" oraxdb:maintainDOM="false">
    <xs:complexType oraxdb:SQLType="MINITEST_TYPE" oraxdb:maintainDOM="false">
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="l2Node" oraxdb:SQLName="L2_NODE" oraxdb:SQLType="L2_NODE_TYPE" oraxdb:SQLCollType="L2_NODE_COLL" oraxdb:maintainDOM="false"/>
        <xs:element ref="minitestId" oraxdb:SQLName="MINITEST_ID" oraxdb:SQLType="NUMBER" oraxdb:maintainDOM="false"/>
        <xs:element ref="minitestName" oraxdb:SQLName="MINITEST_NAME" oraxdb:SQLType="VARCHAR2" oraxdb:maintainDOM="false"/>
      </xs:sequence>
    </xs:complexType>
</xs:element>
<xs:element name="l2Node" oraxdb:SQLName="L2_NODE" oraxdb:SQLType="L2_NODE_TYPE" oraxdb:defaultTable="" oraxdb:tableProps="TABLESPACE CATALOG NOLOGGING" oraxdb:maintainDOM="false">
    <xs:complexType oraxdb:SQLType="L2_NODE_TYPE" oraxdb:maintainDOM="false">
      <xs:sequence>
        <xs:element ref="l2Num" oraxdb:SQLName="L2_NUM" oraxdb:SQLType="NUMBER" oraxdb:maintainDOM="false"/>
        <xs:element ref="l2Name" oraxdb:SQLName="L2_NAME" oraxdb:SQLType="VARCHAR2" oraxdb:maintainDOM="false"/>
      </xs:sequence>
    </xs:complexType>
</xs:element>
<xs:element name="l2Num" type="number10_0Type" oraxdb:SQLName="L2_NUM" oraxdb:SQLType="NUMBER" oraxdb:maintainDOM="false" />
<xs:element name="l2Name" type="varchar100Type" oraxdb:SQLName="L2_NAME" oraxdb:SQLType="VARCHAR2" oraxdb:maintainDOM="false" />
<xs:element name="minitestId" type="number10_0Type" oraxdb:SQLName="MINITEST_ID" oraxdb:SQLType="NUMBER" oraxdb:maintainDOM="false" />
<xs:element name="minitestName" type="varchar100Type" oraxdb:SQLName="MINITEST_NAME" oraxdb:SQLType="VARCHAR2" oraxdb:maintainDOM="false" />
<xs:simpleType name="varchar100Type">
    <xs:restriction base="xs:string">
      <xs:maxLength value="100"/>
    </xs:restriction>
</xs:simpleType>
<xs:simpleType name="number10_0Type">
    <xs:restriction base="xs:integer">
      <xs:totalDigits value="10"/>
    </xs:restriction>
</xs:simpleType>
</xs:schema>',
GENTABLES=>FALSE
END;
And then I create my XML tables - four different ones for four different test cases. I am trying unstructured binary XML and strucured OR-based XML, each with and without a trigger.
One with structured OR storage and no trigger
CREATE TABLE ZZZ_MINITEST_ORXML (
ID NUMBER(10,0) NOT NULL ENABLE,
XML_CONTENT XMLTYPE,
CONSTRAINT PK_ZZZ_MINITEST_ORXML PRIMARY KEY (ID)
) NOLOGGING
VARRAY "XML_CONTENT"."XMLDATA"."L2_NODE" STORE AS TABLE "ZZZ_OR_L2_NODE" (NOLOGGING) RETURN AS LOCATOR
XMLTYPE XML_CONTENT STORE AS OBJECT RELATIONAL XMLSCHEMA "http://localhost/minitest.xsd" ELEMENT "minitest_root";
One with structured OR storage which will also have a trigger added further down
CREATE TABLE ZZZ_MINITEST_ORXML_TRGR (
ID NUMBER(10,0) NOT NULL ENABLE,
XML_CONTENT XMLTYPE,
CONSTRAINT PK_ZZZ_MINITEST_ORXML_TRGR PRIMARY KEY (ID)
) NOLOGGING
VARRAY "XML_CONTENT"."XMLDATA"."L2_NODE" STORE AS TABLE "ZZZ_OR_L2_NODE_TRGR" (NOLOGGING) RETURN AS LOCATOR
XMLTYPE XML_CONTENT STORE AS OBJECT RELATIONAL XMLSCHEMA "http://localhost/minitest.xsd" ELEMENT "minitest_root";
One with unstructured binary XML in a SECUREFILE, no trigger
CREATE TABLE ZZZ_MINITEST_BINXML_TRGR (
ID NUMBER(10,0) NOT NULL ENABLE,
XML_CONTENT XMLTYPE,
CONSTRAINT PK_ZZZ_MINITEST_BINXML_TRGR PRIMARY KEY (ID)
) NOLOGGING
XMLTYPE COLUMN XML_CONTENT STORE AS SECUREFILE BINARY XML
(NOCOMPRESS NOCACHE NOLOGGING KEEP_DUPLICATES);
One with unstructured binary XML in a SECUREFILE, which will also have a trigger
CREATE TABLE ZZZ_MINITEST_BINXML (
ID NUMBER(10,0) NOT NULL ENABLE,
XML_CONTENT XMLTYPE,
CONSTRAINT PK_ZZZ_MINITEST_BINXML PRIMARY KEY (ID)
) NOLOGGING
XMLTYPE COLUMN XML_CONTENT STORE AS SECUREFILE BINARY XML
(NOCOMPRESS NOCACHE NOLOGGING KEEP_DUPLICATES);
Then I create the error logging tables
begin
DBMS_ERRLOG.CREATE_ERROR_LOG ('ZZZ_MINITEST_BINXML', 'ZZZ_MINITEST_BINXML_E', NULL, NULL, TRUE);
DBMS_ERRLOG.CREATE_ERROR_LOG ('ZZZ_MINITEST_BINXML_TRGR', 'ZZZ_MINITEST_BINXML_TRGR_E', NULL, NULL, TRUE);
DBMS_ERRLOG.CREATE_ERROR_LOG ('ZZZ_MINITEST_ORXML', 'ZZZ_MINITEST_ORXML_E', NULL, NULL, TRUE);
DBMS_ERRLOG.CREATE_ERROR_LOG ('ZZZ_MINITEST_ORXML_TRGR', 'ZZZ_MINITEST_ORXML_TRGR_E', NULL, NULL, TRUE);
END;
Now the two triggers
create or replace trigger TRG_ZZZ_MINITEST_BINXML
BEFORE UPDATE OR INSERT ON ZZZ_MINITEST_BINXML_TRGR
REFERENCING NEW AS NEW
for each row
BEGIN
:NEW.XML_CONTENT := :NEW.XML_CONTENT.createSchemaBasedXML('http://localhost/minitest.xsd');
:NEW.XML_CONTENT.SCHEMAVALIDATE();
END TRG_ZZZ_MINITEST_BINXML;
CREATE OR REPLACE TRIGGER TRG_ZZZ_MINITEST_ORXML
BEFORE UPDATE OR INSERT ON ZZZ_MINITEST_ORXML_TRGR
REFERENCING NEW AS NEW
for each row
BEGIN
:NEW.XML_CONTENT := :NEW.XML_CONTENT.createSchemaBasedXML('http://localhost/minitest.xsd');
:NEW.XML_CONTENT.SCHEMAVALIDATE();
END TRG_ZZZ_MINITEST_ORXML;
I also tried to just validate the XML using queries such as the below, since validating all without the WHERE also caused exception and abortion:
SELECT ID, DECODE(XMLISVALID(XMLTYPE(XML_DOC), 'http://localhost/minitest.xsd'), 1, 'Y', 0, 'N', '?') VALID
FROM ZZZ_MINITEST_CLOB WHERE ID=90;
The results are in column "VALID" in the below tables
I tried inserting all records from ZZZ_MINITEST_CLOB into the four test tables at once using a query such as
INSERT INTO ZZZ_MINITEST_ORXML_TRGR
SELECT ID, XMLPARSE(DOCUMENT XML_DOC WELLFORMED) FROM ZZZ_MINITEST_CLOB
LOG ERRORS INTO ZZZ_MINITEST_ORXML_TRGR_E REJECT LIMIT UNLIMITED;
I also tried different versions of creating the XML in the SELECT portion:
XMLPARSE(DOCUMENT XML_DOC WELLFORMED)
XMLPARSE(DOCUMENT XML_DOC WELLFORMED)
XMLTYPE(XML_DOC)
XMLTYPE(XMLDOC, 'http://localhost/minitest.xsd', 0, 1)
Almost all combinations of the four test tables with the four ways to instantiate the XML caused exceptions and query abortion despite the LOG ERRORS INTO clause.
In order to find the exact problems, I started inserting records one by one using queries like
INSERT INTO ZZZ_MINITEST_ORXML
SELECT ID, XMLPARSE(DOCUMENT XML_DOC) FROM ZZZ_MINITEST_CLOB WHERE ID=10
LOG ERRORS INTO ZZZ_MINITEST_ORXML_E REJECT LIMIT UNLIMITED;
or
INSERT INTO ZZZ_MINITEST_BINXML_TRGR
SELECT ID, XMLTYPE(XMLDOC, 'http://localhost/minitest.xsd', 0, 1) FROM ZZZ_MINITEST_CLOB WHERE ID=20
LOG ERRORS INTO ZZZ_MINITEST_BINXML_TRGR_E REJECT LIMIT UNLIMITED;
I captured the results of each in the below four tables. "1" and "0" are number of rows inserted. 0 means there was no record inserted and instead, there was an error logged in the ERROR LOGGING table.
The ORA-????? exception numbers mean that this error actually caused the INSERT to fail and abort rather than just being logged in the LOGGING TABLE.These are the most critical cases for me. Why do these exceptions "bubble up" forcing the query to be aborted rather than being logged in the error log as well???
This table is for INSERT of XMLs using XMLTYPE(XML_DOC)
Test case
VALID
Binary XML,
no trigger
Binary XML,
trigger
OR XML,
no trigger
OR XML,
trigger
10
Good
Y
1
1
1
1
20
no name
N
1
0
1
0
30
switched tags
N
1
1
1
1
40
Good
Y
1
1
1
1
50
L2 down
N
1
1
1
1
60
no xml
EX
ORA-31011
ORA-31011
ORA-31011
ORA-31011
70
NULL
EX
ORA-06502
ORA-06502
ORA-06502
ORA-06502
80
addl. Node
N
1
0
ORA-31187
ORA-31187
90
crappy xml
EX
ORA-31011
ORA-31011
ORA-31011
ORA-31011
This table is for INSERT of XMLs using XMLTYPE(XML_DOC, 'http://localhost/minitest.xsd', 0, 1)
Test case
VALID
Binary XML,
no trigger
Binary XML,
trigger
OR XML,
no trigger
OR XML,
trigger
10
Good
Y
1
1
1
1
20
no name
N
1
0
1
0
30
switched tags
N
1
1
1
1
40
Good
Y
1
1
1
1
50
L2 down
N
1
1
1
1
60
no xml
EX
ORA-31043
ORA-31043
ORA-31043
ORA-31043
70
NULL
EX
ORA-06502
ORA-06502
ORA-06502
ORA-06502
80
addl. Node
N
1
0
ORA-31187
ORA-31187
90
crappy xml
EX
ORA-31043
ORA-31043
ORA-31043
ORA-31043
This table is for INSERT of XMLs using XMLPARSE(DOCUMENT XML_DOC WELLFORMED)
Test case
VALID
Binary XML,
no trigger
Binary XML,
trigger
OR XML,
no trigger
OR XML,
trigger
10
Good
Y
1
1
1
1
20
no name
N
1
0
1
0
30
switched tags
N
1
1
1
1
40
Good
Y
1
1
1
1
50
L2 down
N
1
1
1
1
60
no xml
ORA-31061
0
ORA-31011
ORA-31011
70
NULL
1
0
1
0
80
addl. Node
N
0
0
ORA-31187
ORA-31187
90
crappy xml
ORA-31061
0
ORA-30937
ORA-30937
This table is for INSERT of XMLs using XMLPARSE(DOCUMENT XML_DOC) (same as above, but without "WELLFORMED")
Test case
VALID
Binary XML,
no trigger
Binary XML,
trigger
OR XML,
no trigger
OR XML,
trigger
10
Good
Y
1
1
1
1
20
no name
N
1
0
1
0
30
switched tags
N
1
1
1
1
40
Good
Y
1
1
1
1
50
L2 down
N
1
1
1
1
60
no xml
ORA-31011
ORA-31011
ORA-31011
ORA-31011
70
NULL
1
0
1
0
80
addl. Node
N
1
0
ORA-31187
ORA-31187
90
crappy xml
ORA-31011
ORA-31011
ORA-31011
ORA-31011
As you can see, different ways to instantiate the XML which is being inserted will cause different results for the most critical cases (60, 80 and 90). One will go through with an error logged in the logging table and no record inserted, others cause exceptions. Also, using XMLPARSE with or without WELLFORMED causes different ORA numbers for record 90...
It seems like the only way to not get any exceptions for my test records is inserting XMLs that were created using XMLPARSE (DOCUMENT ... WELLFORMED) into the trigger-protected binary XML table. However, that causes me to miss record number 80, which is one that I really need, because it is well formed and I could use XSLTs to fix the XML by removing the extra tags, as long as I know which ones those are.

Online Redefinition of Binary XML column not possible?

DB version 11.2.0.1 x64 (still working on upgrading to 11.2.0.3)
create table redef_test (
        id number(19,0) not null,
        xml XMLType,
        primary key (id)
    XMLTYPE COLUMN "XML" STORE AS CLOB;
table REDEF_TEST created.
exec dbms_redefinition.can_redef_table( 'USER', 'redef_test' );
anonymous block completed
drop table redef_test;
create table redef_test (
        id number(19,0) not null,
        xml XMLType,
        primary key (id)
    XMLTYPE COLUMN "XML" STORE AS BINARY XML;
table REDEF_TEST dropped.
table REDEF_TEST created.
exec dbms_redefinition.can_redef_table( 'USER', 'redef_test' );
Error starting at line 1 in command:
exec dbms_redefinition.can_redef_table( 'USER', 'redef_test' )
Error report:
ORA-12090: Kan de tabel "USER"."REDEF_TEST" online niet opnieuw definiëren.
ORA-06512: in "SYS.DBMS_REDEFINITION", regel 139
ORA-06512: in "SYS.DBMS_REDEFINITION", regel 1782
ORA-06512: in regel 1
12090. 00000 - "cannot online redefine table \"%s\".\"%s\""
*Cause:    An attempt was made to online redefine a table that is either a
           clustered table, AQ table, temporary table, IOT overflow table
           or table with FGA/RLS enabled.
*Action:   Do not attempt to online redefine a table that is a
           clustered table, AQ table, temporary table, IOT overflow table
           or table with FGA/RLS enabled.Also came across ORA-42040 on the internet while searching for a solution:
ORA-42040     cannot online redefine table "string"."string" with column of binary XML type
Cause:     Do not attempt to online redefine a table with a column of binary XML type.
Action:     An attempt was made to redefine a table with a column of binary XML type.
Why this limitation to binary xml? I was under the impression that binary xml was put forward by oracle as the 'format of the future'; yet an important feature as online redefinition cannot be used anymore it seems.
My reason for this question: I have a table that should have been partitioned (based on a virtual column derived from an xpath in the xml column) but isn't at this moment. I'm trying to use online redefinition to partition the existing table, but all the suggested ways of doing this don't seem to work.
Another thing i tried was a 'CTAS', but those seem to have problems with virtual columns.
CREATE TABLE d_new (
    id,
    xml,
    PRIMARY KEY (id)
XMLTYPE COLUMN xml STORE AS SECUREFILE BINARY XML
VIRTUAL COLUMNS
    timestamp AS (TO_TIMESTAMP(extractvalue(xml,'/e:d/c:dHeader/c:creationTime',
        'xmlns:e="http://www.example.com/myproject/schema/e/nl"
         xmlns:c="http://www.example.com/myunidoc/schema/common"'),'YYYY-MM-DD"T"HH24:MI:SS'))
PARTITION BY RANGE (timestamp)
    PARTITION p2010_09 VALUES LESS THAN (TO_DATE('1-10-2010','DD-MM-YYYY')),
    PARTITION p2012_05 VALUES LESS THAN (TO_DATE('1-6-2012','DD-MM-YYYY')),
    PARTITION px VALUES LESS THAN (MAXVALUE)
as
select id,xml from d_table;
Error at Command Line:40 Column:19
Error report:
SQL Error: ORA-54014: De resultatentabel van een CTAS-bewerking bevat een of meer virtuele kolommen.

I would have tested it myself but my current version (11.2.0.3) has a bug regarding virtual columns...
One thing you can try is :
1) Create your new empty partitioned table (D_NEW) with only one partition
2) Perform an ALTER TABLE EXCHANGE PARTITION between old and new tables
3) Drop old table
4) SPLIT PARTITIONs on the new table

How to get the tree index of a child node

Hi, I am loading a tree object from an XML source file (via
an XMLListCollection)
I can find the children on the currently selected node, like:
var children:XMLList =
XMLList(myTree.selectedItem).children();
for(var i:Number=0; i < children.length(); i++) {
trace("Child Found: " + children
.@caption);
But how can I determine the tree index for each of the
children? I would like to be able to grab and save the tree index
for each child, so that I can later just to do
"myTree.selectedIndex = (saved child index) (based on some form
action the user performs). I can't find any method of determining
what the tree index for a child is, other than walking down the
tree from the parent node and counting the number of nodes till I
hit each child. Is there a simple method?

Tree is hierarchical, index is linear. I have never seen
anyone successfully use selectedIndex with Tree.
You best bet is to put an id on each node and use e4x
expression to find that node when you want.
Tracy

Migrating a Sybase Index with ignore_dup_key

HI All,
I am involved with Sybase to Oracle migration.
I need to migrate a Index with ignore_dup_key.
I am currently inserting the data into the table and then deleting the duplicate enteries.
Can someone suggest me a better approach..
Thanks,
Riddhisha
Edited by: Riddhisha on Apr 13, 2012 3:18 PM

I think there is some confusion around ignore_dup_key functionality. Ignore_dup_key in Sybase essentially allows an application to continue without aborting a on-going transaction even if there was an attempt to insert duplicate values for columns that have a Unique index on them with ignore_dup_key clause. But (I emphasize) Sybase does not allow duplicate values in a column on which a unique index exists.
Typically when you try to insert duplicate values for columns with unique/primary indexes, you get a "unique constraint violation error". This error under normal conditions will result in the failure of the complete transaction. With IGNORE_DUP_KEY clause, the sybase database simply ignores that "INSERT/UPDATE" statement and continues with the rest of the transaction.
What that means is if you have a index on a table in Sybase with Ignore_dup_key clause then most likely that index is a UNIQUE index. So that means you shouldn't see duplicate values in the affected column(s). If you do see duplicate values then the implication is that the index is not a UNIQUE index and hence IGNORE_DUP_KEY clause does not really add value. Customer may have changed their schema design later realizing that those columns will have duplicate values but forgot to take out the IGNORE_DUP_KEY clause. Also if you already have duplicate values for a column, you cannot create a UNIQUE index even in Sybase with this clause.
Since you are seeing duplicate values in the table so I am guessing that it is a regular B*tree index so you can do the same in Oracle and ignore the IGNORE_DUP_KEY clause as Oracle does not offer such functionality.
If you really want to create a unique index in Oracle and not have the duplicate values then you will have to try couple of different approaches. Create an External table and use PL/SQL procedure/function to load the data using MERGE statements or INSERT INTO... SELECT FROM EXTERNAL_TABLE with the LOG ERROR Clause to reject the duplicate values without failing the overall data load.
Hope this helps..
Regards
Prakash

Bitmap index Vs B-Tree index

Hi All,
Could some one please let me know how Bitmap indexes are useful compared to B-Tree indexes on low-cardinality columns ?.
Thanks,
-Kumar.

>>
As Re: why oracle db 9i optimizer can't choose to use the bitmap index? there are a number of issues with bitmap indexes. Your best bet is to read these three articles by Jonathan Lewis.
It does pay us to understand how the optimizer works with bitmap indexes. I posted some Re: Cost-based optimizer behavior to show how indexes on even very low valued columns can be useful in certain circumstances.
Cheers, APC
Blog : http://radiofreetooting.blogspot.com/

Error in updating R-tree index

Hi,
I want to update a geometry column with a R-tree index on it with a statement like:
update xxx set xxx.geometry = (select yyy.geometry...
All geometries in the updated table are NULL before. I get the following error:
ORA-29877: failed in the execution of the ODCIINDEXUPDATE routine
ORA-13237: internal error during R-tree concurrent updates: [empty-node
encountered; rebuild index]
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 7
ORA-06512: at "MDSYS.SDO_IDX", line 86
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 83
ORA-06512: at line 1
What's wrong?
Joerg

Joerg,
This is a known bug in R-tree indexing.
When you create an R-tree index
on a table with no geometries, it gives
this error.
This is fixed in 8.1.7.
To get around this problem, make sure
that atleast one geometry is non-null
when you create the index.
For a performance reason, it is not
recommended that you create
index on spatial table with NULL
geometries.
Updates on such indexed table will
be very expensive compared to
creating the index on a fully
populated table.
null

Oracle Spatial 8.1.7 r-tree indexes

I don't think this problem is specific to r-tree indexes vs. quad-tree.
Even though I specify a tablespace other than the SYSTEM tablespace in Oracle Spatial Index Advisor when creating r-tree indexes, the index is still created in the SYSTEM tablespace. I don't want my spatial indexes in the SYSTEM tablespace!
select tablespace_name from user_indexes where index_name = 'GPS_IDX';
TABLESPACE_NAME
SYSTEM
Here is the sql statement that Spatial Index Advisor constructed:
create index gis.gps_idx on gis.gps (geometry) indextype is mdsys.spatial_index parameters ('sdo_indx_dims=2');
I was not able to issue this sql from worksheet with the tablespace option added. Is there a way to do that?
In Spatial Index Advisor, if I don't select the geometry column, then the sql is constructed with the tablespace option added, but when I select the geometry column, it removes it from the sql.
Can anybody shed some light on how to do this?
thanks
Dave

Spatial creates an index entry in the system tablespace but realy creates the spatial index in the tablespace you gave it. To verify it execute the select:
select table_name,tablespace_name
from user_tables
where table_name like 'spatial_table%';
It will return your table_name plus the spatial index table created for it.
The table_name will look something like this:
spatial_table_SX_FL10$.
spatial_tables beeing your spatial table.
You can query the same for the indexes built on that previous table.
select index_name,tablespace_name
from user_indexes
where table_name = 'SPATIAL_TABLE_SX_FL10$';
The two index names would look like:
spatial_table_sx_fl10$B1
spatial_table_sx_fl10$B2
They should be created in the tablespace mentionned in your tablespace clause when creating the spatial index.
Hope this helps

ERROR BUILDING SPATIAL R-TREE INDEX

I tried building an R-tree index on a spatial table containing latitude/longitude points. There are only 9000 records in the table.
I get the following error:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13200: internal error [Unsupported Type] in spatial indexing.
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 7
ORA-06512: at line 1
Can anyone help?

MY ORACLE version number is 9.0.1.0.0
My table name is GEOM_FIX, the column that I tried to index is FIX_NAME VARCHAR2, where FIX_NAME is a unique identifier.
My spatial index create script is:
CREATE INDEX NDX_GEOM_FIX ON GEOM_FIX (FIX_NAME)
INDEXTYPE IS MDSYS.SPATIAL_INDEX

Errors creating indexes on Binary XML Tables

Hi,
Oracle details are as follows:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
"CORE 11.2.0.2.0 Production"
TNS for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
I'm currently having an issue when attempting to create a suitable index on a binary xml table. I have a Binary xml table that stores a number of xml documents. I have created an index on this table as follows:
create index TEST_WQI_idx_1 on TEST_WEB_QUOTE_INDX1(OBJECT_VALUE)
INDEXTYPE IS XDB.XMLINDEX
PARAMETERS ('PATHS (INCLUDE
(/webPolicy/QuoteId))');
Querying the table with the following:
SQL> l
1 select xmlcast(xmlquery('/webPolicy/Sections/interopSection[1]/PolicyItems/item/Version/text()' PASSING OBJECT_VALUE RETURNING CONTENT)
2 as number) "VERSION",
3 xmlcast(xmlquery('/webPolicy/QuoteId/text()' PASSING OBJECT_VALUE RETURNING CONTENT)
4 as number) "QUOTEID"
5 FROM TEST_WEB_QUOTE_INDX1
6 where xmlcast(xmlquery('/webPolicy/QuoteId/text()' PASSING OBJECT_VALUE RETURNING CONTENT)
7* as number) = 22824
SQL> /
VERSION QUOTEID
1 22824
Execution Plan
Plan hash value: 3559428808
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 545 | 1071K| 1030 (1)| 00:00:19 |
| 1 | SORT AGGREGATE | | 1 | 3022 | | |
|* 2 | TABLE ACCESS BY INDEX ROWID | SYS895336_TEST_WQI__PATH_TABLE | 1 | 3022 | 2 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | SYS895336_TEST_WQI__PIKEY_IX | 1 | | 1 (0)| 00:00:01 |
|* 4 | FILTER | | | | | |
| 5 | TABLE ACCESS FULL | TEST_WEB_QUOTE_INDX1 | 545 | 1071K| 4 (0)| 00:00:01 |
| 6 | SORT AGGREGATE | | 1 | 3022 | | |
|* 7 | TABLE ACCESS BY INDEX ROWID| SYS895336_TEST_WQI__PATH_TABLE | 1 | 3022 | 2 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | SYS895336_TEST_WQI__PIKEY_IX | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(SYS_XMLI_LOC_ISTEXT("SYS_P0"."LOCATOR","SYS_P0"."PATHID")=1)
3 - access("SYS_P0"."RID"=:B1 AND "SYS_P0"."PATHID"=HEXTORAW('5E6C') )
4 - filter(CAST( (SELECT "SYS"."STRAGG"("SYS_P2"."VALUE") FROM
"WEB_STAGING"."SYS895336_TEST_WQI__PATH_TABLE" "SYS_P2" WHERE "SYS_P2"."PATHID"=HEXTORAW('5E6C') AND
"SYS_P2"."RID"=:B1 AND SYS_XMLI_LOC_ISTEXT("SYS_P2"."LOCATOR","SYS_P2"."PATHID")=1) AS number)=22824)
7 - filter(SYS_XMLI_LOC_ISTEXT("SYS_P2"."LOCATOR","SYS_P2"."PATHID")=1)
8 - access("SYS_P2"."RID"=:B1 AND "SYS_P2"."PATHID"=HEXTORAW('5E6C') )
Note
- dynamic sampling used for this statement (level=2)
- Unoptimized XML construct detected (enable XMLOptimizationCheck for more information)
However, I also need to add an additional field to this index to allow appropriate queries against the data in the table, version number. This field can be seen from the statement above (VERSION) which runs OK and returns the data I’d expect. However, when I attempt to add this index using the following statement I get an error returned and the index becomes corrupted:
alter index TEST_WQI_idx_1 rebuild
parameters ('PATHS (INCLUDE ADD
(/webPolicy/Sections/interopSection[1]/PolicyItems/item/Version))');
After some investigation, the issue seems to revolve around the use of the [1] condition in the statement /interopSection[1]. I can create the index by removing the [1] condition, but this does not return the expected result. In actual fact, as there are 2 interopSection elements in the xml file, both with a version number of 1, the statement returns 11, which would appear to be the two version numbers concatenated together. I need to be able to reference the version number from the first interopSection in the queries against the table, and I need to be able to index this column correctly for performance issues.
I'm unsure why this xpath statement is not working correctly in the alter index statement, but returns ok when used within the query against the table and was wondering if you would be able to help me to have a working index against this element.
Thanks in advance for any help you can provide in relation to this.

Sorry, here is the error:
Error starting at line 20 in command:
alter index TEST_WQI_idx_1 rebuild
parameters ('PATHS (INCLUDE ADD
(/webPolicy/Sections/interopSection[1]/PolicyItems/item/Version))')
Error report:
SQL Error: ORA-29858: error occurred in the execution of ODCIINDEXALTER routine
ORA-64131: XMLIndex Metadata: failure during the looking up of the dictionary
ORA-30968: invalid XPATH or NAMESPACE option for XML Index
29858. 00000 - "error occurred in the execution of ODCIINDEXALTER routine"
*Cause: Failed to successfully execute the ODCIIndexAlter routine.
*Action: Check to see if the routine has been coded correctly.

R-tree indexing: really 3d now?

Dear all,
after studying the Spatial Reference guide for 11g I am left wondering what the story is with the R-tree index. Does it really consider all three dimensions now? And all you have to do is set the sdo_indx_dims to 3. Does anyone know another reference about this index apart from the spatial reference guide?
Thanks,
B.

Check this link for a similar discussion
Re: SDO_RELATE with 3D geometry
The second edition of Pro Oracle Spatial has a good bit of detail on 11g 3d:
http://www.amazon.co.uk/Oracle-Spatial-Database-Experts-Voice/dp/1590598997/ref=sr_1_1?ie=UTF8&s=books&qid=1225907677&sr=8-1

R-Tree Index v's Quadtree Index

Hi,
In the 8.1.7 spatial documentation it says that R-Tree index may not be a good choice for a geometry table that has heavy update activity.
Can anyone define and quantify what heavy update is?
Thanks

There hasn't been a formal analysis of R-tree update performance. Some things that are known:
The spatial index create statement includes a percent free specification that allows free space to remain in the R-tree to accomodate future inserts.
If the data doesn't need to be kept on-line all the time, then the R-tree index can be rebuilt.
The performance associated with both R-tree index updates and quadtree index updates is dependent on the data being inserted. Updating point data seems to be faster with quadtrees. Updating simple geometries also seems to be faster with quadtrees. There is a point though where tiling complicated geometries dominates the quadtree index update time, and at some point of complexity it becomes faster to update R-tree indexes.
If anyone has info to add here it would be quite useful.
Hope this helps,
dan

R-tree index creation error

I'm getting the following error when trying to create an r-tree index:
create index new_gps_idx on gis.new_gps (geometry) indextype is mdsys.spatial_index PARAMETERS('TABLESPACE=INDX')
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-06512: at line 1
I get the error regardless of which tablespace I specify.
I can however create fixed quad-tree indexes with the following command, in the same tablespace:
create index new_gps_idx on gis.new_gps (geometry) indextype is mdsys.spatial_index PARAMETERS('SDO_LEVEL=4');
The error is defined as:
ORA-29855 error occurred in the execution of ODCIINDEXCREATE routine
Cause: Failed to successfully execute the ODCIIndexCreate routine.
Action: Check to see if the routine has been coded correctly.
I have created one r-tree index on a large spatial table, 5633 geometries, in the INDX tablespace. I am not able to create another one.
The INDX tablespace is only 2% used and its size is 200MB.
Any help would be greatly appreciated.
Dave
null

Hi David,
Can you try applying the patch (if you haven't already)? Unfortunately I can't rememeber the details of what the symptoms were, and although the patch kit describes a fix there is no corresponding bug in Oracle's bug database. If I remember correctly there was a bug in the values the r-tree code was using for intermediate (temporary) tables created during r-tree index creation.
Sorry I can't pin this down for you.
dan

Migrate B-Tree Indexes of XML O-R Table to XMLIndex on Binary XML Table

Similar Messages

Maybe you are looking for