This content has been marked as final. Show 15 replies
Have a look at the following support note as mentioned in this thread:
Change in default storage model of XMLType to BINARY XML in 126.96.36.199.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 188.8.131.52 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
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 184.108.40.206.0 database will not be changed...
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...
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,
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 220.127.116.11 we have no issues with this length of xml data stored in clob format but since moving one db to 18.104.22.168 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 22.214.171.124 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.