Вход в личный кабинет:

Забыли пароль? | Регистрация

Адреса компании:

Санкт-Петербург

196158, Санкт-Петербург,
Пулковское шоссе, д. 30,
корп. 4, Лит. А, офис 203

Тел: +7 812 414 95 41

Москва

129085, г. Москва, проезд Ольминского, д. 3а, стр. 3, офис 706

Тел: +7 495 616 00 53

Блог

26.08.2015

Progress OpenEdge: промышленные средства репликации данных в Oracle и MS-SQL

Progress OpenEdge Pro2 Replication

Читать далее →




Десять причин перехода на новые версии OpenEdge (Progress)


Внимание! BUG!

30.05.2013

Software Bug

Баг # OE00225722:

65536: maximum number of sub-transactions

Transaction not completely rolled back when more than 65,536 sub-transactions http://knowledgebase.progress.com/articles/Article/000036325

OpenEdge 10.2B05, 10.2B06, 10.2B07, 11.0, 11.1

The fix for this issue is expected to be in the upcoming release 10.2B08.
As of 4/5/2013, release 10.2B08 is scheduled to be released in Q4, 2013 subjected to changes.

Пример такой транзакции:
Код:

do transaction:
  for each table where ...: 
    update table.
  end.
end.

Статья говорит о неполном откате таких транзакций, но ситуация на самом деле хуже. Транзакция с большим числом субтранзакций может успешно завершиться, оставив после себя поврежденные данные, которые будут восприниматься как поврежденные индексы.

Ошибки:

SYSTEM ERROR: Index in for recid could not be deleted. (1422)
**  already exists with . (132)

Причем ошибка 132 может выдаваться для неуникального (!!!) индекса.

На самом деле индексные ключи содержат правильные значения (соответсвующие последним изменениям, сделанным в рамках транзакции), а вот изменения в самих записях могут оказаться потерянными. Из сотен тысяч записей, измененных в рамках большой транзакции, поврежденными могут оказать единицы, а могут и десятки тысяч записей.

Баг исправлен в hotfix’е, который ставится поверх сервис-пака 10.2B07.

Лечение базы

Логично предположить, что для устранения ошибок нужно перестроить индексы в базе. Но это неправильное решение. Индексы будут построены для записей, в которых были потеряны последние изменения. Например, в одном случае баг проявил себя в большой транзакции, в рамках которой создавались новые записи. Как известно оператор CREATE создает «голенькую» запись — копию template записи, в которой все поля имеют значения по умолчанию. Из-за бага в базе появилось огромное число таких «голеньких» записей. Перестройка индексов удалит индексные ключи, содержавшие актуальные значения полей и проиндексирует никому ненужные пустышки. Физическое состояние базы будет корректным, чего, к сожалению, нельзя будет сказать о логической консистентности базы. Удалить пустышки и потом перестроить индексы? Но это потеря «части» транзакции, а транзакция, как известно, по определению не может завершиться лишь частично. Нужно разбираться, есть ли возможность повторно выполнить операцию только для этих записей или нужно откатить все изменения, сделанные в рамках проблемной транзакции. Т.е. лечение базы, поврежденной этим багом, — задача нетривиальная.

На вашем месте я бы в срочном порядке запросил Hot Fix.


Вернуться к списку новостей
Компьютерные системы для бизнеса
© 2010 - 2017 Все права на материалы, находящиеся на этом сайте, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах. При любом использовании материалов сайта ссылка на источник обязательна.