This content has been marked as final. Show 15 replies
Have a look at the following support note as mentioned in this thread:1 person found this helpful
Change in default storage model of XMLType to BINARY XML in 184.108.40.206.0
Ad 2) in principle if you set compatible (database parameter) back to 11.2.01 you will have not the problem (?) or build the object on a not ASSM specified tablespace. Doing this by heart, check the support note!
Ad 1,2) the solutions make a difference if there is a XML schema in place on which the binary XML is defined on.
What is the reason this customer wants to change to basic file CLOB instead of secure file ??? The default securefile change in 220.127.116.11 was/is based onnthe fact that it is way more efficient regarding performance and storage handling.
thank you for your response.
1. Well, idea to decrease compatible level or move data to non-ASSM does not inspiring me at all :)
2. seems there is no XML schema in tables:
select distinct XMLSCHEMA,ANYSCHEMA,NONSCHEMA from user_xml_tab_cols;
|XMLSCHEMA |ANY| NON
| | NO |YES
Any advices about conversion will be very preferable :)
Edited by: user7047453 on Mar 25, 2011 3:53 AM
1. Well, idea to decrease compatible level or move data to non-ASSM does not inspiring me at allCould be, but moving back to BASICFILE CLOB looks silly to me, from a XML viewpoint as well... WHY DOES the customer WANT this ? Is it a software vendor...?
Edited by: Marco Gralike on Mar 25, 2011 4:35 PM
We need to understand why the customer wants basicfile CLOB rather than the default of SECUREFILE binary XML.. This makes absolutely no sense..
To explicity force BASIC FILE CLOB you would do
create table T1
XMLTYPE XML STORE AS BASICFILE CLOB
But why you would do this beats me....
(Unless you are relying on the fact that streams based replication only supports XMLType store as BASICFILE LOB)
Also note, that the change in default only affects newly created XMLTYPE tables or columns, tables or columns in a database that has been upgraded from a pre 18.104.22.168.0 database will not be changed...
yes, this is software vendor. they tell that they have performance issues because of BINARY xml storage type.
In general XML stored as SECUREFILE BINARY XML should be as fast if not faster than XMLType store as CLOB. Can you or your customer please have open a support request with Oracle so we can investigate why they have a performance issue. We are going to depricate XMLTYPE STORE AS CLOB in the near future, so rather than ignoring the underlying problem we should solve it...
Sorry for delay with response.
Yes, I've asked vendor about SR opening as you've told. Will wait their answer.
Who is the vendor in this case...
We are considering the same possibility, for we need to replicate our primary database to logical standby in our dataguard settings.
XML stored as binary file is not supported by dataguard, logical standby.
Oracle Data Guard Concepts and Administration 11g Release 1 (11.1), C.1.2 Unsupported Datatypes in a Logical Standby Database,
Doing this by hart, but if I am not mistaken, it is in 11.2
I've run into the same issue, and in response to why I would want to revert back to CLOB storage; it's because there seems to be a 32k limit on the content in the XMLType column when using binary storage.
Previously in 22.214.171.124 we have no issues with this length of xml data stored in clob format but since moving one db to 126.96.36.199 the database completely dies when trying to read that column with >32k data length.
DB dies with either:
ORA-00600: internal error code, arguments: [kpolcsc1], , , , , , , , , , , 
ORA-00600: internal error code, arguments: [kpolcbLobRead1: invalid len & bufp], , , , , , , , , , , 
And I don't find any articles on MOS either searching the knowledge base or using the ora-600 lookup tool that aren't already fixed: kpolcsc1 was fixed in 188.8.131.52 according to ora-600 lookup tool.
I would prefer to keep binary storage, and not have to revert to clob, but if I can't found a solution to 32k limit then im going to have to revert storage type.
In case of a ORA-00600 error, you should always ask Oracle support for help via logging a Service Request...
I have submitted an SR. Just waiting for reply. Even if OLE DB does not support >32kb it shouldnt crash the instance.