12c: ORA-600: [kdBlkCheckError] при использовании TEMPORARY UNDO в OEBS

спорадичеки попадались нам с Леонидом Борчуком в процессе выполнения стандартного Concurrent Processing-а при отсутствии всякой информации в логах на apps-ах и следующими замечаниями в alert.log:

Thu Oct 01 06:42:16 2015
Errors in file /opt/oracle/admin/diag/rdbms/oebs/OEBS2/trace/OEBS2_ora_30980.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kdBlkCheckError], [515], [2014592], [14508], [], [], [], [], [], [], [], []
Cannot recover, soft-corrupt the buffer.    --*
Thu Oct 01 06:42:16 2015
Corrupt Block Found
         CONT = 0, TSN = 284, TSNAME = TEMP --**
         RFN = 3, BLK = 2014592, RDBA = 14597504
         OBJN = 0, OBJD = 14597504, OBJECT = , SUBOBJECT =
         SEGMENT OWNER = , SEGMENT TYPE =
Errors in file /opt/oracle/admin/diag/rdbms/oebs/OEBS2/trace/OEBS2_ora_30980.trc  (incident=293623):
ORA-00603: ORACLE server session terminated by fatal error
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kdBlkCheckError], [515], [2014592], [14508], [], [], [], [], [], [], [], []
Incident details in: /opt/oracle/admin/diag/rdbms/oebs/OEBS2/incident/incdir_293623/OEBS2_ora_30980_i293623.trc

— первый аргумент ошибки [kdBlkCheckError] и (*) сообщают о проблемах восстановления блока временного файла [515] табличного пространства TEMP (**) при выполнении стандартного DML в Global Temporary Table, текст которого можно найти в incident-файле:

----- Current SQL Statement for this session (sql_id=0vjcg5zp30z2x) -----
MERGE /*+ use_hash(xal) */ INTO XLA_AE_LINES_GT XAL USING XLA_AE_HEADERS_GT XAH ...

Трейс отображает причины проблем:

*** 2015-10-01 06:37:00.659
*** SESSION ID:(1055.37976) 2015-10-01 06:37:00.659
*** CLIENT ID:(31843439) 2015-10-01 06:37:00.659
*** SERVICE NAME:(oebs) 2015-10-01 06:37:00.659
*** 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)
...
BH (0x1e3e94a6f0) file#: 515 rdba: 0x00debd80 (3/2014592) class: 33 ba: 0x1e39450000
  set: 72 pool: 3 bsz: 8192 bsi: 0 sflg: 0 pwc: 0,25
  dbwrid: 3 obj: 14597504 objn: 0 tsn: [0/284] afn: 515 hint: f
  hash: [0x2b8ded1670,0x2b8ded1670] lru: [0x1b9dcbf7e8,0x63e3aeb58]
  ckptq: [NULL] fileq: [NULL]
  objq: [0x2782062420,0x213e1c4e78] objaq: [0x2782062410,0x213e1c4e88]
  use: [0x2bf012a1b8,0x2bf012a1b8] wait: [NULL]
  st: XCURRENT md: EXCL fpin: 'ktswh81: ktsscfctl' fscn: 0x7e7.4d14ae8b tch: 20 le: 0x0
  flags: buffer_dirty mod_started temp_data
  change state: ACTIVE
  change count: 1
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
DUMP REDO                                            -- , далее делается попытка восстановления из REDO
 Opcodes *.*
 DBAs (file#, block#):
 (515, 2014592) .                                    -- блока типа TEMP UNDO (****)
 SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
 **NOTE: Only Dumping Redo less than 12 hours**      -- с погружением не более полусуток
 Times: 09/31/2015 18:38:00 thru 10/01/2015 06:38:00
...

, что непросто сделать при compatible -> 12.1.0.2 c разрешённым использованием нелогируемого Temporary UNDO:

SQL> @param TEMP_UNDO_ENABLED
 
NAME               VALUE  IS_DEF   DSC
------------------ ------ -------- -------------------------
temp_undo_enabled  TRUE   FALSE    is temporary undo enabled

— что было сделано не просто так, а в точном соответствии с рекомендациям Database Initialization Parameters for Oracle E-Business Suite Release 12 (Doc ID 396009.1):

# TEMP_UNDO_ENABLED is a new feature in 12c. it helps in reducing the amount of redo caused by DML
# on global temporary tables. If this parameter is set to TRUE it eliminates REDO on the permanent UNDO.
# Recommended value for TEMP_UNDO_ENABLED is TRUE
#
##########

temp_undo_enabled = true

, которые, в свою очередь, происходят ввиду активного использования разработчиками OEBS технологии хранения промежутоных результатов запросов/процедур в GTT, что, возможно, не совсем транзакционно, но заметно ускоряет и облегчает

Лёгким естественным решением является отключение фичи:

SQL> alter system set temp_undo_enabled = false;
System altered.

, тяжёлым и правильным решением будет заведение пары SR по части DB и OEBS

P.S. Default значение параметра temp_undo_enabled оптимистично неточно указано в докуметации)