Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
Здравствуйте всем! DB2 WSE 9.7.6. На БД ночью проводилась реорганизация и в какой-то момент произошел сбой. Диск, подключенный к серверу от СХД, отвалился. База стала недоступной. С утра диск подключили. Но похоже какая-то таблица (вероятно та, на которой выполнялся reorg в момент сбоя) осталось заблокированной или в каком-то отложенном состоянии. В итоге я могу выполнить соединение с БД, а select на одной таблице не выполняется. Пишет, что из-за тупиковых ситуаций транзакция отложена. Где можно снать блокировку этой таблицы и привести БД в нормальное состояние? Спасибо С уважением, Семен Попов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 12:31 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
db2 load query table MYSCHEMA.MYTAB выдает, что состояние таблицы нормальное. Но первый же запрос sеlect к этой таблице после загрузки менеджера висит долгое время, а затем сообщает об откате транзакции. Остальные таблицы без проблем. Что это значит? Что происходит с таблицей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 12:51 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
Semen Popov, а логе что? и что видно по Код: sql 1. 2. 3. 4. 5. в какой стадии оборвался реорг? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 12:51 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
Semen Popovdb2 load query table MYSCHEMA.MYTAB выдает, что состояние таблицы нормальное. Но первый же запрос sеlect к этой таблице после загрузки менеджера висит долгое время, а затем сообщает об откате транзакции. Остальные таблицы без проблем. Что это значит? Что происходит с таблицей? Семен, очень похоже что сбой на этапе перестроения индекса. Пока он не перестроен, каждое обращение к таблице будет вызывать старт этого процесса. В логе должно быть однозначно указано начало процесса ребилда индекса. Если нет времени ребилдить - дропните их (индексы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 12:57 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
p.s. а отваливаться может из-за нехватки места. проверьте, достаточно ли места в соответствующем системтемптейблспейс, которое используется при ребилде. если индекс логируется, то проверьте достаточно ли места в журнале транзакций ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 13:00 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
m@mСемен, очень похоже что сбой на этапе перестроения индекса. Пока он не перестроен, каждое обращение к таблице будет вызывать старт этого процесса. В логе должно быть однозначно указано начало процесса ребилда индекса. Если нет времени ребилдить - дропните их (индексы) Про какой процесс Вы говорите? Если индексы дропнуть, то затем надо их создать. Тогда надо скрипты для создания индексов поискать. А место на диске достаточно. Это я первым делом проверил. Запустил сейчас reorg table из процессора командной строки. Но тот что-то завис. В db2diag.log было сообщение об удачном завершении reorg, а дальше какие-то непонятки Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 13:23 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
Semen PopovПро какой процесс Вы говорите? Про ребилд индекса Semen Popov2013-07-02-13.03.30.347000+240 E43358675F558 LEVEL: Warning PID : 984 TID : 3128 PROC : db2syscs.exe INSTANCE: DB2 NODE : 000 DB : CSERVICE APPHDL : 0-10 APPID: *LOCAL.DB2.130702090031 AUTHID : DB2ADMIN EDUID : 3128 EDUNAME: db2agent (CSERVICE) FUNCTION: DB2 UDB, data management, sqldIndexCreate, probe:1 MESSAGE : ADM5541W Rebuilding index with IID "1" in object with ID "6" and table space ID "2" on table "DB2ADMIN.R_COMPONENTS_VALUE". что дает: select * from sysibmadm.snaptab_reorg where tabname in ('R_COMPONENTS_VALUE') ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 13:34 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
m@mSemen Popov, а логе что? и что видно по Код: sql 1. 2. 3. 4. 5. в какой стадии оборвался реорг? select вернул 0 записей. А лог оборвался в момент сбоя на реорганизации индекса Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 13:35 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
m@mчто дает: select * from sysibmadm.snaptab_reorg where tabname in ('R_COMPONENTS_VALUE') ? 0 записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 13:36 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
Semen Popov, м.б. db2 list history reorg since 20130702 for db CSERVICE даст больше информации о причинах сбоя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 13:52 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
Может быть. Но сейчас запустил реорганизацию всех индексов таблицы reorg indexes for table <Tab> ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 13:54 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
После реорганизации индексов проблема ушла. Всем спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 15:34 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
m@mSemen PopovПро какой процесс Вы говорите? Про ребилд индекса У меня вопрос. Получается, что как только база переходила в активное состояние, то сразу начинался ребилд проблеммного индекса? И тогда всего лишь надо было подождать, пока этот процесс завершится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 15:53 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
Semen Popov, возможно, что как только было первое обращение к таблице, у которой был инвалидный индекс. если никаких помех для перестроения индекса не было, то можно было подождать. посмотрите, что в параметрах конфигурации (index re-creation). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 16:18 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
m@m, в базе установлен INDEXREC = SYSTEM (RESTART). Вы об этом параметре говорите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 16:52 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
Semen Popov, да, вроде он. Вы говорите база у вас падала и вы ее рестартовали - по идее при рестарте должно было начаться пересоздание индекса. У меня была схожая проблема без падения всей базы и перестроение начиналось только после обращения к таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 17:19 |
|
||
|
Сбой на реорганизации
|
|||
|---|---|---|---|
|
#18+
Вот, видите как. Всего лишь нужно было подождать. А у нас ведь всё хотят сразу :-) Пользователи меня живьем съели (но их тоже можно понять). В итоге, вместо 30 мин ожидания бился с проблемой около полудня. Опыт приходит с практикой :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2013, 17:43 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=38317067&tid=1601340]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
62ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 153ms |

| 0 / 0 |
