спорадичеки попадались нам с Леонидом Борчуком в процессе выполнения стандартного 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 оптимистично неточно указано в докуметации)
Здравствуйте,
спасибо за пост. Очень важно и своевременно. Как раз собираюсь заняться подобным уменьшением redo логов, в случае моих баз данных, я оцениваю их уменьшение раз в 10, не меньше.
Получили ли Вы какой-либо ответ/рекомендацию из Oracle Support?
Заранее спасибо,
Михаил Сизенов
комментарий от Michael Sizenov — 13.10.2015 @ 18:50
Привет, Михаил,
SR по линии OEBS логично был переведён на Oracle database team, последние, к сожалению, только подтвердили правильность нами найденного простого решения через отключение фичи:
Поскольку проблема трудновоспроизводимая, и выигрыш от использования Temporary UNDO для нас не столь существенен, добиваться правильного решения мы не стали, ограничившись информированием поддержки
комментарий от Игорь Усольцев — 14.10.2015 @ 11:10
Спасибо за ответ.
У меня пока только одна база с temp_undo_enabled=TRUE, но она как раз самая «неинтересная», небольшая и малонагруженная. Поэтому проблем не замечено…
Буду потихоньку экспериментировать дальше. Если ORA-600 вылезет — придется открывать SR… и, что может быть действительно сложно — предоставлять им тест кейс.
Удачи,
Мизаил
комментарий от Michael Sizenov — 14.10.2015 @ 18:01
Михаил, технология новая и багов встретилось несколько. Но все они вылечились за исключением этого вот, который оказался трудновоспроизводимым и потому докопаться до причин пока что не удалось (мигрируем OeBS на новую версию и проблемы старой закрыли).
Кажется, почте все они включены в последний PSU Oct 2015
комментарий от leborchuk — 08.11.2015 @ 23:29