We have a SQL query that accepts WHERE clause parameters of date range. 1 year, 2 years, all work predictably. When I use a very large date range (i.e. "everything"), the Oracle dedicated server process crashes.
From the trace file:
*** 2016-05-20 22:06:12.735
*** SESSION ID:(630.42649) 2016-05-20 22:06:12.735
*** CLIENT ID:() 2016-05-20 22:06:12.735
*** SERVICE NAME:(SYS$USERS) 2016-05-20 22:06:12.735
*** MODULE NAME:(rix) 2016-05-20 22:06:12.735
*** CLIENT DRIVER:() 2016-05-20 22:06:12.735
*** ACTION NAME:(prepare_series(a)) 2016-05-20 22:06:12.735
Block Checking: DBA = 8236992, Block Type = Unlimited undo segment header
ERROR: Undo Segment Header Corrupted. Error Code = 14508
ktu4shck: starting extent(0xffff8000) of txn slot #0x6b is invalid.
Searching Google brought up a Russian blog page, that seems to be citing exactly the same issue:
*** MODULE NAME:(e:AR:bes:oracle.apps.xla.accounting.extract) 2015-10-01 06:37:00.659 -- станд.модуль OEBS
Block Checking: DBA = 14597504, Block Type = Unlimited undo segment header -- проверка UNDO
ERROR: Undo Segment Header Corrupted. Error Code = 14508 -- падает со специфичной для ANALYZE ошибкой (***)
ktu4shck: starting extent(0xffff8000) of txn slot #0x21 is invalid.
valid value (0 - 0x8000)
The gist of the post seems to indicate that they are using Oracle 126.96.36.199 and had set TEMP_UNDO_ENABLED=TRUE (a new feature in 12c).
This is interesting because we set this parameter true also, in our code.
Google Translate failed to come through with a useful translation, but it could be that they set this parameter FALSE in order to resolve the problem.
Previously, our test failed after ~2 hours. So far, having made the change to the parameter, it is still running after 4 hours. So, we're optimistic.