|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Случился сабж. Проверил db2dart, получил: Table inspection start: DB2ADMIN.R_COMPONENTS_VALUE Data inspection phase start. Data obj: 6 In pool: 2 Data inspection phase end. Index inspection phase start. Index obj: 6 In pool: 2 Index inspection phase start. Index obj: 6 In pool: 2 Warning: Index object flags indicate invalid state, requires index be re-built, errors reported for this object may be due to this state. Page 1428642: Key 1 Error: Overlaps with Free Block Error: in page 1428642, pool page 1428642, of obj 6, in tablespace 2. Error: Page data will be dumped to report. Error: This phase encountered an error and did not complete. Error: Index page next leaf field 0 but pagetype (16777732) not last leaf Error: in page 1428736, pool page 1428736, of obj 6, in tablespace 2. Error: Page data will be dumped to report. Page 1428736: Key 1 Error: Overlaps with Free Block Error: in page 1428736, pool page 1428736, of obj 6, in tablespace 2. Error detected in index. Index inspection phase end. Table inspection end. Т.е., по моим нубским понятиям, данные целы, индекс накрылся. Индекс дропать не даёт, говорит таблица находится в таком суперблокированном состоянии, что индекс трогать никак нельзя. Видимо, Z - суперэксклюзивная. Видимо, как на реорганизацию в него (состояние) вошла, так и не вышла, в связи с ошибкой. Сейчас командой db2dart /DDEL выпиливаю данные. Вроде, выпиливаются успешно, уже за 2/3 прошло. Планирую дропнуть таблицу, пересоздать, залить из получаемого *.del обратно. Вопрос: А что делать, если не дропнется из-за того, что заблокирована? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 10:15 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Честный чайник, Какая ошибка возвращается на это? Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 11:05 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Дополнение: Не даёт дропнуть. Ругается: [IBM][CLI Driver][DB2/NT64] SQL0290N Обращение к табличному пространству не разрешено. SQLSTATE=55039 Объяснение: Была сделана попытка обратиться к табличному пространству, которое находится в неправильном состоянии, и данное обращение для него не разрешено. * Если табличное пространство находится в стабилизированном состоянии ("Quiesced: SHARE", "Quiesced: UPDATE" или "Quiesced: EXCLUSIVE"), только процессам, которые сохраняют табличное пространство в стабилизированном состоянии, разрешено обращаться к этому табличному пространству. * Если табличное пространство находится в каком-либо другом состоянии, то только процессу, который выполняет действие, вызвавшее это состояние, разрешено обращаться к этому табличному пространству. * Системное или пользовательское временное табличное пространство невозможно отбросить, если оно содержит активные системные временные таблицы, созданные временные таблицы или объявленные временные таблицы. * Вызов API SET CONTAINER не может использоваться для задания списка контейнеров, если табличное пространство не находится в состоянии отложенного восстановления. Действия пользователя: Возможные действия: * Если табличное пространство находится в стабилизированном состоянии, попробуйте перевести табличное пространство в состояние стабилизированного совместного использования или состояние стабилизированной модификации. Или попытайтесь отменить стабилизацию табличного пространства. * Если табличное пространство находится в каком-либо другом состоянии, прежде чем обращаться к табличному пространству, дождитесь возвращения табличного пространства в нормальное состояние. Дополнительную информацию о состояниях табличных пространств смотрите в руководстве администратораe. sqlcode: -290 sqlstate: 55039 ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 11:06 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Mark Barinstein, REORG INDEXES ALL FOR TABLE DB2ADMIN.R_COMPONENTS_VALUE; ругается так же, как на попытку дропнуть что-нибудь: SQL0290N Обращение к табличному пространству не разрешено. SQLSTATE=55039 ------------------------------ Введенные команды ------------------------------ REORG INDEXES ALL FOR TABLE DB2ADMIN.R_COMPONENTS_VALUE; ------------------------------------------------------------------------------ REORG INDEXES ALL FOR TABLE DB2ADMIN.R_COMPONENTS_VALUE SQL0290N Обращение к табличному пространству не разрешено. SQLSTATE=55039 SQL0290N Обращение к табличному пространству не разрешено. Объяснение: Была сделана попытка обратиться к табличному пространству, которое находится в неправильном состоянии, и данное обращение для него не разрешено. * Если табличное пространство находится в стабилизированном состоянии ("Quiesced: SHARE", "Quiesced: UPDATE" или "Quiesced: EXCLUSIVE"), только процессам, которые сохраняют табличное пространство в стабилизированном состоянии, разрешено обращаться к этому табличному пространству. * Если табличное пространство находится в каком-либо другом состоянии, то только процессу, который выполняет действие, вызвавшее это состояние, разрешено обращаться к этому табличному пространству. * Системное или пользовательское временное табличное пространство невозможно отбросить, если оно содержит активные системные временные таблицы, созданные временные таблицы или объявленные временные таблицы. * Вызов API SET CONTAINER не может использоваться для задания списка контейнеров, если табличное пространство не находится в состоянии отложенного восстановления. Действия пользователя: Возможные действия: * Если табличное пространство находится в стабилизированном состоянии, попробуйте перевести табличное пространство в состояние стабилизированного совместного использования или состояние стабилизированной модификации. Или попытайтесь отменить стабилизацию табличного пространства. * Если табличное пространство находится в каком-либо другом состоянии, прежде чем обращаться к табличному пространству, дождитесь возвращения табличного пространства в нормальное состояние. Дополнительную информацию о состояниях табличных пространств смотрите в руководстве администратораe. sqlcode: -290 sqlstate: 55039 ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 11:15 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
При попытке какой-нибудь запрос к таблице заслать, он молча повисает и висит, пока не срубишь, или не отвалится по таймауту. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 11:20 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Честный чайник, Какой статус у пространств, в котором лежит таблица? Покажите соответствующие записи из: db2 list tablespaces ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 11:49 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Mark BarinsteinЧестный чайник, Какой статус у пространств, в котором лежит таблица? Покажите соответствующие записи из: db2 list tablespaces Пространство одно, оно стабилизировано: SHARE. ------------------------------ Введенные команды ------------------------------ list tablespaces; ------------------------------------------------------------------------------ list tablespaces Табличные пространства текущей базы данных ID табличного пространства = 0 Имя = SYSCATSPACE Тип = Пространство, управл Содержимое = Все посто Состояние = 0x0000 Подробное объяснение: Нормальное состо ID табличного пространства = 1 Имя = TEMPSPACE1 Тип = Пространство, управл Содержимое = Системные временные данные Состояние = 0x0000 Подробное объяснение: Нормальное состо ID табличного пространства = 2 Имя = USERSPACE1 Тип = Пространство, управл Содержимое = Все посто Состояние = 0x0001 Подробное объяснение: Стабилизировано: SHARE ID табличного пространства = 3 Имя = SYSTOOLSPACE Тип = Пространство, управл Содержимое = Все посто Состояние = 0x0000 Подробное объяснение: Нормальное состо ID табличного пространства = 4 Имя = SYSTOOLSTMPSPACE Тип = Пространство, управл Содержимое = Пользовательские временные данные Состояние = 0x0000 Подробное объяснение: Нормальное состо ID табличного пространства = 5 Имя = TBSP32K0000 Тип = Пространство, управл Содержимое = Все посто Состояние = 0x0000 Подробное объяснение: Нормальное состо ID табличного пространства = 6 Имя = TBSP32KTMP0000 Тип = Пространство, управл Содержимое = Системные временные данные Состояние = 0x0000 Подробное объяснение: Нормальное состо ID табличного пространства = 7 Имя = TBSP32K0001 Тип = Пространство, управл Содержимое = Все посто Состояние = 0x0000 Подробное объяснение: Нормальное состо ID табличного пространства = 8 Имя = TBSP32KTMP0001 Тип = Пространство, управл Содержимое = Системные временные данные Состояние = 0x0000 Подробное объяснение: Нормальное состо ID табличного пространства = 9 Имя = ARCHIVESPACE Тип = Пространство, управл Содержимое = Все посто Состояние = 0x0000 Подробное объяснение: Нормальное состо ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 12:04 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Честный чайник, Что выдает: Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 12:35 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Mark Barinstein, Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 13:06 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Честный чайник, Надо подключиться к базе пользователем DB2ADMIN и выполнить для сброса quiesced состояния пространства: Код: plaintext
После этого статус пространства должен быть нормальным. Если так, то попробуйте сделать запрос на свою таблицу. Если индексы в нерабочем состоянии, они начнут перестраиваться. Это можно будет увидеть в db2diag.log. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 13:19 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Mark Barinstein, Статус пространства стал нормальным. При попытке переиндексировать или удалить индексы ругается по-новому и не мгновенно, а через несколько минут: SQL0911N Из-за тупиковой ситуации или из-за истечения срока был выполнен откат текущей транзакции. Код причины "68". SQLSTATE=40001 ------------------------------ Введенные команды ------------------------------ reorg indexes all for table DB2ADMIN."R_COMPONENTS_VALUE"; ------------------------------------------------------------------------------ reorg indexes all for table DB2ADMIN."R_COMPONENTS_VALUE" SQL0911N Из-за тупиковой ситуации или из-за истечения срока был выполнен откат текущей транзакции. Код причины "68". SQLSTATE=40001 SQL0911N Из-за тупиковой ситуации или из-за истечения срока был выполнен откат текущей транзакции. Код причины "68 ". Объяснение: Активная рабочая единица столкнулась с неразрешимым конфликтом при использовании объекта и должна быть откачена. Коды причины: 2 Выполнен откат транзакции из-за тупиковой ситуации. 68 Выполнен откат транзакции из-за истечения срока блокировки. 72 Откат транзакции выполнен из-за ошибки менеджера связей данных DB2 во время транзакции. 73 Откат транзакции выполнен из-за того, что порог очереди, такой как CONCURRENTDBCOORDACTIVITIES, привел к тупиковому состоянию двух или большего числа действий. Дополнительную информацию смотрите в разделе "Порог CONCURRENTDBCOORDACTIVITIES" в Информационном центре DB2. Выполнен откат до предыдущей точки принятия. Действия пользователя: Изменения, связанные с рабочей единицей, необходимо повторить. Тупиковых ситуаций или истечений срока блокировки для долго выполняющихся программ или для программ, где вероятны тупиковые ситуации, можно избежать, чаще выполняя операции COMMIT. Пользователи системы объединения: тупиковая ситуация могла произойти в системе сервера объединения или на источнике данных. Не существует механизма, который обнаруживал бы тупиковые ситуации, распространяющиеся на источники данных и потенциально на систему объединения. Можно определить, какой из источников данных не смог обработать требование (процедуру определения этого источника смотрите в руководстве по диагностике ошибок). Тупиковые ситуации часто обычны или ожидаемы для определенных сочетаний операторов SQL. Рекомендуется строить программы так, чтобы по возможности избегать подобных сочетаний. Если состояние тупиковой ситуации достигнуто из-за порога очереди, такого как CONCURRENTDBCOORDACTIVITIES, увеличьте значение этого порога. sqlcode: -911 sqlstate: 40001 Информация, связанная с данной: Параметр конфигурации locktimeout - срок ожидания блокировки ожидание блокировок и сроки ожидания управление блокировками Разрешение проблем с тупиковыми ситуациями После select * from db2admin.R_COMPONETS_VALUE задумался уже минут на 10. В винду выдано 3 события: 1. 1 или несколько индексов помечены как плохие и будут перестроены, (Это мы тут пометили в соответствие с https://www.ibm.com/developerworks/ru/library/dm-1208corruptiondb2/index.html командой "db2dart CService /MI /TSI 2 /OI 6") 2. перестраиваем 5 индексов 3. перестраиваем 1й индекс у таблицы 6 в пространстве 2. (цифрф правильные) Т.е., двойственное какое-то положение. То ли починится, то ли нет... Но индексы после запроса перестраивать пошёл. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 14:12 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Честный чайник, Это надо из другой сессии смотреть, в кого втыкается reorg, что он в конце концов lock timeout получает. См. SYSIBMADM.MON_LOCKWAITS Ну и разобраться, насколько важен этот виновник блокировки, что мешает reorg'у работать... ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 14:19 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Mark BarinsteinЧестный чайник, Это надо из другой сессии смотреть, в кого втыкается reorg, что он в конце концов lock timeout получает. См. SYSIBMADM.MON_LOCKWAITS Ну и разобраться, насколько важен этот виновник блокировки, что мешает reorg'у работать... Вроде, нет никого. Соединения только локальные. MON_LOCKWAITS пустой невооружённым взглядом... ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 14:29 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Честный чайникВроде, нет никого. Соединения только локальные. MON_LOCKWAITS пустой невооружённым взглядом...Так запустите еще раз и смотрите в вывод запроса время от времени. Ну или в EVENT MONITOR FOR LOCKING, если он у вас есть, смотрите. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 14:49 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Восстанавливай CSERVICE, это будет быстрее чем чем индексы на R_COMPONENTS_VALUE перестроить. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2017, 16:54 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Я около года назад перенёс эту таблицу в отдельное табличное пространство ... |
|||
:
Нравится:
Не нравится:
|
|||
05.12.2017, 22:58 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
После того, как индексы перестроились жизнь наладилась. Всё хорошо, всё заработало. Вся ерунда с неудаляемыми индексами прекратилась, чего хочешь удаляется, переиндексируется и т.д. Жизнь наладилась, спасибо Марку за нашу счастливую старость и даёшь переименование форума в его честь! НО! ...что-то меня останавливало от того. чтобы радостно отписаться. И вот через неделю при очередной реорганизации всё повисло на перестраивании индекса на той же таблице. Последствия уже, конечно, не те, вручную метить Остановили, перезапустились, проверили db2dart-ом - ругается. индексы, говорит помечены и нуждаются в перестройке. Перезагрузили, запустилась DB2 и сама без дополнительных действий с нашей стороны начала перестраивать индексы. Сообщений не было, мы по событиям в windows заметили, DB2 туда пишет. Перестроила - опять, вроде, всё наладилась. Таблица, конечно, из тех, за которые нужно в детстве репрессировать, но избавиться от неё нам не судьба, надо как-то жить. Лежат там атрибуты из документов. Документов много, атрибуты разные, тип поля один. Используется постоянно, в хвост и в гриву. 435 миллионов записей. Вот ddl: ALTER TABLESPACE USERSPACE1 PREFETCHSIZE AUTOMATIC OVERHEAD 12.670000 FILE SYSTEM CACHING TRANSFERRATE 0.180000; CREATE TABLE "DB2ADMIN"."R_COMPONENTS_VALUE" ( "ID" BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY ( START WITH +1 INCREMENT BY +1 MINVALUE +1 MAXVALUE +9223372036854775807 NO CYCLE NO CACHE NO ORDER ) , "COMPONENTS_ID_COMPONENTS_OID" BIGINT , "REGISTER_ID_OID" BIGINT , "VALUE" VARCHAR(1000) ) IN "USERSPACE1" ; ALTER TABLE "DB2ADMIN"."R_COMPONENTS_VALUE" ADD CONSTRAINT "R_COMPONENTS_M9_PK" PRIMARY KEY ("ID"); CREATE UNIQUE INDEX "DB2ADMIN"."R_COMPONENTS_NN" ON "DB2ADMIN"."R_COMPONENTS_VALUE" ("ID" ASC) INCLUDE ("COMPONENTS_ID_COMPONENTS_OID" ) COMPRESS NO ALLOW REVERSE SCANS; CREATE INDEX "DB2ADMIN"."R_COMPONENTS3L_N49" ON "DB2ADMIN"."R_COMPONENTS_VALUE" ("COMPONENTS_ID_COMPONENTS_OID" ASC) COMPRESS NO DISALLOW REVERSE SCANS; CREATE INDEX "DB2ADMIN"."R_COMPONENTS3L_N50" ON "DB2ADMIN"."R_COMPONENTS_VALUE" ("REGISTER_ID_OID" ASC) COMPRESS NO DISALLOW REVERSE SCANS; CREATE INDEX "DB2ADMIN"."R_COMPONENTS3L_N51" ON "DB2ADMIN"."R_COMPONENTS_VALUE" ("VALUE" ASC) COMPRESS NO DISALLOW REVERSE SCANS; Буду счастлив почитать мысли, куда ещё копать, чтобы победить это безобразие. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2017, 09:05 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Chumakov_JAЯ около года назад перенёс эту таблицу в отдельное табличное пространство А каким образом это помогает? Пространство потом как-то специально настраивается? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2017, 09:40 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Честный чайник, Сначала желательно посмотреть на вывод в момент возникновения проблемы: Код: plaintext
Посмотреть в систему - не начинает ли она свопиться, т.к. с Код: plaintext
Ну и если сами не сможете разобраться, тогда вызвать команду сбора информации о зависании (-hang full - если даже новые соединения не устанавливаются) и открыть PMR: Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2017, 12:48 |
|
2216N -1224 или "Сбой при реорганизации".
|
|||
---|---|---|---|
#18+
Честный чайникChumakov_JAЯ около года назад перенёс эту таблицу в отдельное табличное пространство А каким образом это помогает? Пространство потом как-то специально настраивается? а вы выполните запрос Код: sql 1. 2. 3. 4. 5. 6.
потом сложите весь объем данных далее у вас 4 к табличное пространство посмотрите максимальный объем табличного пространства при таком размере страницы и все. я ничего не настраивал кроме того что новое табличное пространство сделал 32К переносил командой call sysproc.admin_move_table(...........) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2017, 09:36 |
|
|
start [/forum/search_topic.php?author=lina007&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 488ms |
total: | 640ms |
0 / 0 |