We have found the cause of the problem. If populate the varray for a row with 100
values, copy that data to a temporary table and then perform split and exchange
partition operations everything is fine. However if we populate the varray with 1000
values for a row and then perform the same
Hi!
If even Oracle hasn't seen this error, then probably we can't help much here
either. Just a wild guess, try to move this partition to another location
and select from it then (although koxsisz1 isn't a data layer error as far
as I understand). Try to read using index if available, then using
The error was first discovered when we tried to move a partition. ( alter table
archive_wave_i move partition SEP1103 tablespace CHANARCH_NLC_2003_09_DATA). The
table was renamed to OLD_archive_wave_i once it was determined that no new varray data
was accessible. My theory is that this is
Hi!
I'm on thin ice here, but I think KO means some sort of object layer (KOC is
Kernel-Object-Cache module as far as I understand), so koxsisz1 has probably
something to do with objects as well (thus not caching, x might mean execute
or transaction or anything else:). On the other hand, varrays
Ian,
I was going to recommend to try exporting your problematic partition with
direct=y, that way normal SQL query processing layer is bypassed in Oracle
kernel all data belonging to segment is read directly (thus hopefully
avoiding the koxsisz1 crash) ... but I'm not sure whether varrays don't
The varray data is stored in a LOB. So I expect direct export will not work. But
I'll give it a try.
Ian
-Original Message-
Sent: Thursday, September 18, 2003 1:35 PM
To: Multiple recipients of list ORACLE-L
Ian,
I was going to recommend to try exporting your problematic
