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

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

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

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

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)


Почему удаление записей в таблице приводит к фрагментации индексов?

Вернуться к списку постов

13.11.2010

Когда происходит удаление записей, дерево индексов не перестраивается. Таким образом, всё B-дерево остается неповрежденным. Такая работа механизма была введена в версии Progress 9.x, где элементы индексной блокировки не удалялись в конце транзакции.

Во время транзакции, когда удаляются записи, если существует уникальный индекс, признак удаления записи помещается вместо RECID удаляемой записи. В конце транзакции эти признаки преобразуются в отрицательное число и помещаются вместо RECID в индексе, т.е. Progress обрабатывает такие элементы указателя индекса во время последующих операций чтения. Конечно же, блоки, на которые указывают такие элементы указателя индекса, не могут быть прочитаны, т.к. эти RECID выше, чем любое возможное значение High Water Mark (HWM) в области. Тем не менее, это всё еще логический запрос. Таким образом, со временем удаление  большого количества записей может привести к возникновению высокой индексной фрагментации, что в свою очередь может значительно повлиять на производительность. Поэтому, после удаления большого количества данных, для сокращения количества индексных блоков и увеличения производительности, необходимо выполнить одно из следующих действий: idxbuild или idxcompact.

В идеальном случае лучше выполнить перестройку индексов с помощью PROUTIL IDXBUILD, но эта операция может быть выполнена только в offline. Поэтому с другой стороны можно использовать PROUTIL IDXCOMPACT, которая может выполняться как в offline, так и в online, и позволяет сократить количество блоков в B-дереве и даже количество его уровней. Здесь хотелось бы особенно отметить, что использование этой утилиты до версии Progress 10.1С04 или 10.2A01 не рекомендуется, поскольку в более ранних версиях имели место некоторые проблемы в работе этой утилиты, например, её использование приводило к чрезмерному росту BI-файла из-за области видимости транзакции, т.е. уплотнение выполнялось в одной большой транзакции.

Что же даст нам уплотнение индексов:

  • При уникальном индексе сканируется цепочка удалений, индексные блоки очищаются путем удаления таких указателей.
  • Нелистовые уровни B-дерева уплотняются, начиная от корня до листового уровня.
  • Уплотняется листовой уровень.

Иными словами, помимо уплотнения индекса эта утилита выполняет чистку «мертвых» указателей, оставленных после их удаления из уникального индекса. Но помните, что с работой IDXCOMPACT в online могут возникнуть проблемы (устраненные в более поздних версиях). Настоятельно рекомендуется, прежде чем запускать утилиту, обновить свою версию Progress до 10.1С04/10.2A01 или до позднейшей.

Командная строка для уплотнения индекса выглядит следующим образом:

 

proutil dbname-C idxcompact tablename.indexname


Скрипт уплотнения индексов по всем таблицам базы данных может быть создан с помощью следующего просто ABL-кода:

DEF VAR mydb AS CHAR FORMAT "X(10)" INITIAL "./sports".
OUTPUT TO VALUE("all-idxcompact.sh").
For each _file where _file-number > 0 AND NOT _file-name BEGINS "SYS":
   for each _index OF _file:
       PUT UNFORMATTED
           "proutil " mydb " -C idxcompact " _file._file-nam "."
                     _index._index-Name " 80" SKIP.
   End.
END.
OUTPUT CLOSE.

Внимание! Перед выполнением уплотнения индексов убедитесь, что у вас есть работоспособная резервная копия базы данных, т.к. в случае возникновения сбоя во время работы утилиты работоспособность базы данных не гарантирована.

В результате вы получите скрипт, в котором будет содержаться примерно следующий код:

proutil ./sports -C idxcompact Invoice.Cust-Num 80
proutil ./sports -C idxcompact Invoice.Invoice-Date 80
proutil ./sports -C idxcompact Invoice.Invoice-Num 80
proutil ./sports -C idxcompact Invoice.Order-Num 80
proutil ./sports -C idxcompact Customer.Comments 80
proutil ./sports -C idxcompact Customer.Country-Post 80
proutil ./sports -C idxcompact Customer.Cust-Num 80
proutil ./sports -C idxcompact Customer.Name 80
proutil ./sports -C idxcompact Customer.Sales-Rep 80
proutil ./sports -C idxcompact Item.Cat-Description 80
proutil ./sports -C idxcompact Item.Item-Name 80
proutil ./sports -C idxcompact Item.Item-Num 80
proutil ./sports -C idxcompact Order.Cust-Order 80

Если процедура удаления данных из таблицы — это характерная черта приложения, требующего полной очистки таблицы, например, в конце рабочего дня, то вместо выполнения IDXCOMPACT в качестве альтернативного метода рекомендуется переместить такую таблицу вместе со всеми ее индексами в отдельную область хранения. После чего к ней можно применять команду усечения области PROUTIL TRANCATE AREA, которая выглядит следующим образом:

proutil dbname -C truncate area <area name>

Этот способ более эффективен, чем обычное удаление таблицы и последующее уплотнение индексов.


Добавить свой комментарий

Ваше имя*:
Ваш E-mail*:
Ваш комментарий*:

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