Delete schema based xml fails

Question

I am attempting to delete xml files through the following command:
delete from
(select 1 from resource_view
where UNDER_PATH(res, '/home/user1/forms', 1) = 1
order by depth(1) desc);
/home/user1/forms contains over 200,000 schema-based xml documents that I wish to drop. The schema-based documents previously were loaded properly and showed 0kb size. Their contents are accessible from views and can be used in sql statements.
The command has been running over 24 hours with the server's cpu maxed at 100%. The server is Windows Server 2003 and the database is 9.2.0.4. There are no relevant invalid objects in the database.
Could the command be failing (or simply taking a really, really long time) because I should not have loaded all the forms into a single folder? I have been able to run the above command on folders with 5 or ten xml documents in them.

Answer 1

Hi people,
Our results (YMMV - and if it does then tell us how) made us VERY reluctant to drop structures that weren't empty - period.
Try it for yourselves but our experience was basically any live dropping of XML schema structures has a fairly good chance of being incomplete or not allowing the same schema to be reconstituted in a lights-out environment... (ie. didn't completely remove types / tables from dictionary so we got "<name> already exists" errors on schema re-registration, requiring an instance restart - but with no guarantees ).
BTW : DELETE FROM gives MASSIVE amounts of redo ...and takes MASSIVE amounts of time with the hierarchy triggers enabled [I suspect the moderately evil UNDER_PATH operator is hidden in the delete hierarchy trigger] (hence the copy out stuff to be kept - then TRUNCATE option).
And with schema mapped hierarchy enabled structures - dropping the tables left dangling pointers from the resource entry to the now non-existent schema table structures. These dangling pointers destroyed access to that set of resources (and any resources PAST evaluation of those rows in RESOURCE_VIEW [a previous rant of mine on "exception objects" explains why]. (Until a dbms_xdb.deleteresource( <path>, dbms_xdb.*force) was used on each resource).
So to update or extend our hierarchy enabled schema our recipe became :
Disable receiver processes
Disable hierarchy triggers
for r in
( select *
from resource_view r
where r.any_path like || '<app_root>/%'
order by instr( r.any_path, '.' ) desc
-- hack to delete files before folders
loop
dbms_xdb.deleteresource(
r.any_path,
dbms_xdb.delete_resource
end loop;
Delete the rows from the xml type tables. (TRUNCATE each table from bottom up).
Drop the schema with dbms_xmlschema.delete_invalidate;
Drop all xml related user types and tables (by naming convention in our XML Schema xdb:SQLType* / xdb:SQLName* attributes).
Register new schema and transform / insert stored XML values into tables again.
NOTE : In our case we copy those rows / resources we need to keep to other CLOB based structures first and reconstitute them after the schema is back - thankfully our profile allows this.
Hope this helps,
Lachlan