Search code examples
oracleplsqlxmltypexmltable

Hanging process when inserting in xmltable


I'm using Oracle Database 12c (12.1.0.1.0 64Bit). Some time ago I wrote a piece of software in pl/sql to import several XML-files. This seemed to work very well, but then some problems occurred. Some files are 5 to 25 MB in size, so it takes one or two minutes to import them. But for some files the import never ends and the importing process even can't be stopped, I have to restart the server to get rid of it.

I traced the problem to the following row:

INSERT INTO SB_BUFFER_XML VALUES (XMLType(bfilename('XMLDATA', '840.xml'), nls_charset_id('AL32UTF8')));

The table SB_BUFFER_XML is of type xmltable and XMLDATA points to a local directoy. The command never finishes with the file 840.xml. But it finishes with the file 613.xml. Both are similar in size, the 613.xml is even bigger:

  • 840.xml: 6.329 KB
  • 613.xml: 6.905 KB

So I started to compare both files looking for the problem:

  • both files are UTF-8 without BOM
  • both contain the same structure, but different data
  • the xml-syntax check finished successful
  • even in a hex editor both files start and finish with the same characters (so theres no hidden BOM or something)
  • both files were created in the same system in the same version

So I simply started to delete content from 840.xml to reduce the complexity and I saw that it doesn't matter what I delete. As soon as I delete a specific amount of data, even if it is a comment, the import of this file works flawless.

The strange thing is that I already did import xml-files with the same structure from the same system with a file size of over 20 MB.

Do you have any idea what could cause this problem or what I could check next?


Solution

  • Oracle could reproduce our problem and pointed us to the following bug:

    Bug 22843562 - IMPORT OF A XML FILE WITH A COMMENT AT THE END FAILS WITH ORA-27163
    

    This bug is fixed in 12.2. In 12.1 you can try this workaround to activate the old parser:

    ALTER SESSION SET EVENTS '31156 trace name context forever, level 0x400';
    

    While the bug title didn't describe our problem, the workaround worked for us nevertheless.