Этот сайт посвящается администрированию баз данных OpenEdge Progress.
Не корысти ради, а познания для!

С уважением,
Валерий Башкатов
Сайт разработан при участии компании Progress Technologies, официального дистрибьютора Progress Software Corp. на территории стран СНГ и Латвии.

RSS RSS подписка на обновления сайта

Поиск по сайту

Лучшие материалы

Orphus System
На сайте функционирует система коррекции ошибок. Обнаружив неточность в тексте, выделите её и нажмите Ctrl+Enter



Результаты опроса: Нужны ли книги по Progress OpenEdge на русском языке? (опрос проводился с мая 2009 по ноябрь 2010)

Да, нужны. Потому что будет легче понять материал - 268
Нет, не нужны. Достаточно материалов на английском языке - 10
Не знаю, мне всё равно - 6

А знаете ли вы что..



Внимание! BUG!


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.





Главная |  Статьи |  Книги |  Гостевая |  Ссылки |  От автора |  Download ProKb


������ ᠩ� pr Online ProKB Blogger Welcome to Russian Progress Users Group at Facebook Welcome to Russian Progress Users Group at LinkedIn
© 2009 - 2011 Все права на материалы, находящиеся на сайте www.openedge.ru, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах.
При любом использовании материалов сайта ссылка на источник обязательна.