Month: Август 2023

ORA-600 [6109] «Cannot get space to grow the ITL in an EMPTY block !!». Oracle 19

Krotov KonstantinОставьте комментарий

Из серии «никогда такого не было, и вот опять». Данная ошибка по сути является багом и её не должно быть. Первые упоминания о исправлении данной ошибки датируются версией 7.3.3(да, да, очень старая) и заканчиваются на отметке версии 10.1.0.2. Но как бы не так, данная ошибка воспроизводится(не всегда, но достаточно часто) в 19.3 и 19.19. Стоит отметить, что ошибка нашлась при синтетических тестах.

Для воспроизведения ошибки, нужно:

create table t1(
id varchar2(4000));
alter table t1 add constraint idpk primary key(id);
create sequence t1seq cache 5000;

Сам тест:

Запустить 5-10 конкурентных сессий, без использования PL/SQL, используя только sql:

next_val_seq_id_bind=t1seq.nextval||rpad(‘X’,3980,’R’)

insert into t1 values(:next_val_seq_id_bind);
commit;
delete from t1 where t1.id= :next_val_seq_id_bind;
commit;

Сам тест, является неким граничным/частным случаем, когда на один блок, приходится одна строка.

SR я завёл.

Беспричинный рост размера таблицы. Oracle 19.19, bug 30265523.

Krotov KonstantinОставьте комментарий

Дано: Oracle 19.19, RHEL8, размер блока 8к

После установки DBRU19.19 на 19.9, одна таблица стала линейно подрастать. Таблица буферная, в неё идёт вставка и практически стразу идёт удаление, в таблице постоянно находится порядка 1000 строк, но каждый день таблица прибавляет в объёме.  При поиске на oracle support был найдет Bug 30265523 — blocks are not marked as free in assm after delete — 12.2 and later (Doc ID 30265523.8) .

Выполнив дамп блока первого уровня битовой карты свободного места в экстете(first level bitmap block) вижу вот такую картину:

  --------------------------------------------------------

  DBA Ranges :

  --------------------------------------------------------

   0x04000080  Length: 64     Offset: 0     

  

   0:Metadata   1:Metadata   2:FULL   3:FULL
   4:FULL   5:FULL   6:FULL   7:FULL
   8:FULL   9:FULL   10:FULL   11:FULL
   12:FULL   13:FULL   14:FULL   15:FULL
   16:FULL   17:FULL   18:FULL   19:FULL
   20:FULL   21:FULL   22:FULL   23:FULL
   24:FULL   25:FULL   26:FULL   27:FULL
   28:FULL   29:FULL   30:FULL   31:FULL
   32:FULL   33:FULL   34:FULL   35:FULL
   36:FULL   37:FULL   38:FULL   39:FULL
   40:FULL   41:FULL   42:FULL   43:FULL
   44:FULL   45:FULL   46:FULL   47:FULL
   48:FULL   49:FULL   50:FULL   51:FULL
   52:FULL   53:FULL   54:FULL   55:FULL
   56:FULL   57:FULL   58:FULL   59:FULL
   60:FULL   61:FULL   62:FULL   63:FULL

  --------------------------------------------------------
  ktspfsc -
  nro:62 ncmp:0 nff:62 nxo:1 lastxs:30 nxid:1 ff:30
  clntime: 1689652737 addtime:0 spare1:0 spare2:0
  ro: rejection opcode, xo: xid offset List
  0. ro:0 xo:-1  1. ro:0 xo:-1  2. ro:3 xo:-1  3. ro:3 xo:-1
  4. ro:3 xo:-1  5. ro:3 xo:-1  6. ro:3 xo:-1  7. ro:3 xo:-1
  8. ro:3 xo:-1  9. ro:3 xo:-1  10. ro:3 xo:-1  11. ro:3 xo:-1
  12. ro:3 xo:-1  13. ro:3 xo:-1  14. ro:3 xo:-1  15. ro:3 xo:-1
  16. ro:3 xo:-1  17. ro:3 xo:-1  18. ro:3 xo:-1  19. ro:3 xo:-1
  20. ro:3 xo:-1  21. ro:3 xo:-1  22. ro:3 xo:-1  23. ro:3 xo:-1
  24. ro:3 xo:-1  25. ro:3 xo:-1  26. ro:3 xo:-1  27. ro:3 xo:-1
  28. ro:3 xo:-1  29. ro:3 xo:-1  30. ro:3 xo:-1  31. ro:3 xo:-1
  32. ro:3 xo:-1  33. ro:3 xo:-1  34. ro:3 xo:-1  35. ro:3 xo:-1
  36. ro:3 xo:-1  37. ro:3 xo:-1  38. ro:3 xo:-1  39. ro:3 xo:-1
  40. ro:3 xo:30  41. ro:3 xo:-1  42. ro:3 xo:-1  43. ro:3 xo:-1
  44. ro:3 xo:-1  45. ro:3 xo:-1  46. ro:3 xo:-1  47. ro:3 xo:-1
  48. ro:3 xo:-1  49. ro:3 xo:-1  50. ro:3 xo:-1  51. ro:3 xo:-1
  52. ro:3 xo:-1  53. ro:3 xo:-1  54. ro:3 xo:-1  55. ro:3 xo:-1
  56. ro:3 xo:-1  57. ro:3 xo:-1  58. ro:3 xo:-1  59. ro:3 xo:-1
  60. ro:3 xo:-1  61. ro:3 xo:-1  62. ro:3 xo:-1  63. ro:3 xo:-1

Наблюдаем rejectioncode 3, ну и все блоки FULL. Что полностью совпадает с описанием бага, который как бы исправлен. Если сделать дамп блока с данными, то в нём будет всего одна строка, которая имеет пометку, что она удалена(—HDFL—). Стоит отметить, что проблемная таблица имеет несколько полей varchar2(4000), из которых под завязку заполняется всегда 2 поля, а иногда 3 поля, остальные поля всегда null, связанных и смигированных(chained and migrated rows) строк таблица не имеет.

Дальнейшие эксперименты показали, что:

  1. Не помогает или делает хуже _enable_rejection_cache = false
  2. Не помогает _assm_segment_repair_bg=false
  3. Комбинация _enable_rejection_cache = false и _fix_control=’32075777:ON’, не помогает.
  4. Потенциальным решением(костылём) может является только установка одного параметра _fix_control=’32075777:ON’.

Выставив _fix_control=’32075777:ON’,  можно удержать таблицу в нормальных рамках размера. При постоянной нагрузке, таблица остановила свой рост. При одинаковой нагрузке, в 19.9 таблица имелеа размер в пару сотен мегабайт, в 19.19 с _fix_control=’32075777:ON’, рост остановился на отметке в 1Гб. Также при установки _fix_control=’32075777:ON’, появилась не нулевая метрика ASSM_bg_slave_fix_state, которая по видимому увеличивается после того, как фиксится статус блоков в битовой карте, и стала заполнятся x$ktsp_repair_list(я так понимаю, здесь отображён список сегментов, по которым сработал механизм починки сегмента). SR я завёл.

Ну и в целом, как изменилась работа ASSM. До 06/21 бд работала на DBRU 19.9, после 6/20 на 19.19: