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

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

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

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

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

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



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

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

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



Как определить, когда необходимо сделать D&L?




1. Использование dbanalys`а для определения необходимости D&L Progress OpenEdge базы данных
2. Что означает “Record Scatter Factor”, показанный в dbanalys`е?
3. Что означает “Index Factor” указанный в idxanalys`е?

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

Существует два ключевых показателя, на которые стоит опираться при принятии решения о перезагрузки данных, это Index factor и Scatter factor, полученные с помощью dbanalys`а:

proutil dbname -C dbanalys

Record Scatter Factor или Показатель фрагментации записей:

Показатель фрагментации таблицы это целочисленной значение, показывающее расположение записей таблицы по отношению друг к другу на диске. Значение 1.0 указывает на то, что записи находятся максимально близко друг к другу.

Более низкий показатель означает, что блок, содержащий запись таблицы будет содержать и другие записи той же таблицы.

Когда множество записей читаются с одной таблицы, более вероятно, что они будут обнаружены в буфере. Это соответствует общему утверждению, что наибольший показатель фрагментации, это более низкий буферный коэффициент совпадения, следовательно, более высокая дисковая активность и низкая производительность.

Показатель фрагментации является хорошим указателем качества фрагментации записей только тогда, когда его значение равно единице, или чем меньше это значение, тем лучше. Опыт показывает улучшение производительности после перезагрузки данных, когда значение показателя варьировалось между 4.0 и 4.5 в таблицах с количеством записей более 100.

Начиная с версии Progress 9.x в архитектуру базы данных были введены так называемые “Storage areas” или “Области памяти», которые позволяют влиять на показатель фрагментации таблицы выделяя ее в отдельную область и подбирая соответствующий RPB (Record per block). Подобное распределение позволяет вообще исключить необходимость в перезагрузке данных.

Index Factor или Показатель индексации:

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

Индексный показатель варьируется в следующих пределах:
1.0 - 1.5: Индекс в хорошем состоянии
1.5 - 2.0: Индекс возможно нуждается в уплотнении
2.0 и более: Индекс нуждается в уплотнение

Если индекс уплотнен, он занимает меньше пространства в базе данных и использует меньше памяти, т.к. все индексные блоки заполнены.
Количество индексных уровней должно уменьшиться после уплотнения. Это означает, что доступ к записи будет происходить быстрее, из-за меньшего количества обращений к базе данных.

Использование idxbuild не имеет значительного эффекта в уплотнении, поскольку в этот момент используются свободные блоки базы данных. В результате, уже использованные блоки ни когда не будут заполнены до конца.

Начиная с версий Progress 9.x появилась возможность online-уплотнения индексов, которая позволяет не прибегать к переиндексации, а следовательно, и к повторному созданию индекса:

proutil dbname -C idxcompact Table.Index [percentage]

Другое, не документированное, средство это:

proutil dbname -C idxblockreport PUB.tablename.indexname

Их можно использовать для индексов, которым необходимо уплотнение.

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

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

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

Башкатов В.Г. 2007 г.



Главная |  Статьи |  Книги |  Гостевая |  Ссылки |  От автора |  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, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах.
При любом использовании материалов сайта ссылка на источник обязательна.