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

С уважением,
Валерий Башкатов

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

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

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

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

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

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

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

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

Поддержка и мониторинг базы данных

CPU – манипулирование данными и запуск программ
Диски и контроллеры – чтение и запись данных базы
Память – хранение данных для быстрого доступа при выполнении операций
Механизмы операционной системы – распределение и использование системных ресурсов
Сеть – обмен данными между клиентом и сервером

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

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

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

Инструменты мониторинга производительности

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

Утилита PROMON
Виртуальные системные таблицы
Windows Performance

Утилита PROMON

Утилита PROMON (OpnEdge Monitor) позволяет контролировать активность и производительность базы данных. Дополнительно, у утилиты имеется расширенная способность глубокого контроля производительности базы данных (R&D).

Виртуальные системные таблицы

Виртуальные системные таблицы (VST) поддерживаются как ABL так и SQL приложениями и предоставляют информацию о работе базы. На основе этих данных работает PROMON. Эти таблицы не имеют постоянных физических записей, записи генерируются менеджером базы данных во время ее работы. Это позволяет приложениям получать необходимую информацию на текущий момент времени.

Windows Performance

Windows Performance это графическое средство, поддерживаемое Windows, позволяющее контролировать производительность как локальной так и удаленной рабочих станций. Этот инструмент измеряет производительность объектов станции, таких как процессы и память, используя определенные наборы счетчиков. Эти наборы весьма обширны, и предоставляют информацию начиная с количества работающих пользователей, заканчивая количество записанных и считанных записей из базы данных. Счетчики являются производными от утилиты PROMON, опция Summary из Activity, они информируют о состоянии и производительность конкретной базы данных. Это средство не в коем случае не заменяет утилиты PROMON, а только обеспечивает дополнительный механизм проверки производительности.

Для получения дополнительной информации по использованию Windows Performance обратитесь к документации – Windows Performance help.

Показатели производительности сервера

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

Использование CPU
Disk I/O, before-image и after-image I/O.
Блокировки записей
Использование памяти
Фрагментация данных и индексов

Использование CPU

Большую часть времени процессоры вашей системы должны быть заняты, это говорит о том, что система работает, так сказать, «в полный рост». Низкая производительность процессоров или их простой указывает на наличие узкого места. Для мониторинга процессоров используются утилиты операционной системы, такие как, например, vmstat или top.

Если замечается понижение производительности и при этом имеется простой процессоров, это обычно говорит о том, что они ожидают завершении работы некоего ресурса. Необходимо определить это ресурс и принять меры для устранения узкого места и улучшения производительности CPU. Используйте PROMON для мониторинга активности базы данных. Очень часто, в подобных ситуациях, узким местом выступают диски, о дисковом использовании можно получить информацию в “Disk I/O”.

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

Механизм spin lock работает следующим образом. Когда процесс обращается в shared-memory ресурсу, он пытается получит его исключительную блокировку. Когда он получает эту блокировку, он получает исключительный доступ к ресурсу. Все остальные попытки получить блокировку потерпят не удачу, пока текущий удерживающий процесс заблокировал ресурс. Дугой процесс обращается к ресурсу, он так же пытается получить блокировку. И продолжает эти попытки повторно, пока ресурс занят. Этот циклический процесс называется spinning. Если после определенного числа попыток получить блокировку так и не удалось, процесс приостанавливается или «засыпает» перед повторной попыткой. При многократном повторении этого процесса время «спячки» процесса постепенно увеличивается. Параметром Spin Lock Retries (-spin) можно регулировать количество попыток получить блокировку, прежде чем процесс «заснет».

Для использования системы семафоров и очередей, для контроля блокировок, установите значение –spin равным нулю.

Используйте PROMON R&D Adjust Latch Options в Administrative Functions чтобы изменять значение –spin на запущенной базе.

Disk I/O

Поскольку чтение и запись данных на диск это достаточно медленные операции, они являются потенциально узким местом в производительности. База данных выполняет три основные операции, связанные с чтением и записью:

Database I/O
Before-image I/O
After-image I/O (если after-imaging активирован)

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

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

Database I/O

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

Для устранения этого узкого места, можно использовать следующее:

Увеличить буфер базы данных (-B)
Изменить структуру базы данных (количество областей хранения данных)
Использовать частные буфера чтения
Использовать APW

Области хранения данных

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

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

Для улучшения производительности, можно расширить область хранения, размещая ее экстенты на более быстрых различных дисках. Добавлять экстенты можно в online.

Буфер базы данных

Буфер базы данных – это временная область хранения, размещенная в памяти и содержащая копии блоков базы данных. Когда происходит чтение записи базы данных, движок базы загружает в буфер блок, содержащий эту запись. Буферы базы данных сгруппированные в области памяти называется буферный пул. На рисунке показано как происходит чтение/запись в базе данных.

Чтение/Запись происходят следующим образом:

1.    Когда процессу необходимо прочитать запись, он запрашивает доступ к записи.
2.    Движок базы ищет запрашиваемую запись в буферном пуле
3.    Если блок обнаружен в буфере, движок считывает запись из него. Это называется – buffer hit. При правильной настройке, большинство записей должно обнаруживаться в буфере
4.    Если же запись не найдена в буферном пуле, движок считывает ее с диска и сохраняет в буфер, если существует доступный пустой буфер.
5.    Если пустого буфера нет, движок заменяет содержимое не пустого буфера.
6.    Если к этому моменту заменяемый буфер был изменен, то движок сначала сохранит изменения на диск. Этот процесс называется – eviction. Пока это происходит, процесс запросивший запись вынужден ждать. Поэтому, производительность будет лучше, если всегда будут доступны пустые буферы.

На следующем рисунке показано как происходит чтение записи в буфер базы данных.

Как происходит запись измененного буфера

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

Идеальным кандидатом для замены является не заблокированный и не измененный буфер. Замена такого буфера происходит только за один шаг: просто записывается новое содержимое. Если буфер содержит измененные данные, они должны сначала «выселены» (eviction) из него. «Выселение» данных происходит за два шага: содержимое буфера записывается на диск, после чего в буфер записывается новое содержимое. Это несомненно медленнее, и поэтому генерируется большая нагрузка.

При поиска кандидата на замену, сервер ищет максимум 10 буферов. Если поиск не дал результатов при поиске не заблокированного и не измененного буфера, сервер берет первый не заблокированный измененный буфер и работает с ним.

Мониторинг активности буфера базы данных

Buffer hit - это когда запись находится в буферном пуле и нет необходимости чтения ее с диска. Для определения эффективности работы буфера, необходимо проверить значение поля Buffer Hits в опции Activity утилиты PROMON. Наилучшая производительность достигается увеличением значения параметра Blocks in Database Buffers (-B), так чтобы значение buffer hits превышало 95 % или пока система не начнет свопинг.

Настройка буфера базы данных

Размер буферного пула базы данных определяется параметром –B. Каждый буфер это один блок базы данных. По умолчанию, значение этого параметра слишком мало. Нельзя дать каких-то конкретных рекомендации по его настройке, так как для каждой базы значение будет индивидуальным. Для начала можно отталкиваться от значения принятым как 10% от размера базы данных, далее его можно увеличивать или уменьшать контролируя параметр Buffer Hits. Единственно о чем можно предупредить, так это не увлекайтесь чрезмерным увеличением, так как в результате, из-за не хватки памяти, система может начать свопинг, что приведет к обратно пропорциональному результату – резкое снижение производительности всей системы.

Движок базы данных так же использует хеш-таблицы, для уменьшения времени размещения буфера базы данных. Параметр запуска Hash Table Entries (-hash) управляет количеством хеш-таблиц в буферном пуле. Движок базы данных определяет значение этого параметра как 25 % от количество буферов, установленных параметром –B. В большинстве случаев этого значения достаточно. Тем не менее, увеличение этого значения могло бы слегка уменьшить время, требуемое, чтобы найти блок в буферном пуле.

Использование частных буферов чтения

Буферный пул – это механизм улучшения ввода/вывода при многопользовательских обращениях. Буфер пул имеет предопределенный размер. Как только он заполняется, начинается замена буферов по принципу наименьшего использования (LRU – least recently used). Очень часто существуют приложения, которые последовательно считывают большие объемы данных, например, отчеты, тем самым они со временем монополизируют все имеющиеся буферы, и зачастую перезаписывая наиболее часто используемые. Тем самым, при обращении других процессов к одним и тем же записям, движок базы вынужден опять считывать данные с диска. Но можно указать некоторое количество буферов в буферном пуле как частные буфера только для чтения. Частные буфера не участвуют в алгоритме замены (LRU) основного буферного пула.

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

Когда приложение использует частные буфера только для чтения и нуждается в буфере для выполнения операции чтения, а буфер в свою очередь находится в наборе частных буферов, движок базы помечает его как наиболее недавно используемый (MRU – most recently used) и работает с ним. Если же буфер не входит в состав частных буферов, он берется из LRU цепочки и помещается в набор частных буферов. Если при работе приложения, весь частный буферный пул был исчерпан, он начинает перезаписываться. Алгоритм LRU для частных буферов идентичен алгоритму LRU для общего буферного пула.

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

Последовательное чтение использует индексы и также требует чтобы эти индексы размещались в памяти, т.к. используются регулярно. Следовательно можно запросить достаточное количество частных буферов для размещения индексов, по которым будет происходить поиск. Для определения необходимого количества частных буферов, посчитайте количество читаемых вами таблиц и определите используемые индексы. Затем, определите количество уровней в B-tree (balance tree) для каждого индекса и добавите 1 (для блоков записи). Например, необходимо запросить не менее пяти частных буферов, если вы читаете таблицу Customer используя индекс Cust-Name, т.к. индекс имеет 4 уровня в B-tree. Если же вы не знаете количество уровней у индекса, можно запросить 6 частных буферов и при этом получить хороший результат. Если одновременно происходит чтение с двух таблиц – установите 12 частных буферов. Если же система будет не в состоянии разместить запрошенное количество частных буферов, в лог базы данных будет записано соответствующее сообщение.

Количество частных буферов устанавливается параметром запуска Private Buffers (-Bp). Если параметр используется для сессии, он остается активным в течении всего сеанса работы, пока он не будет изменен или сессия не будет завершена. Каждое такое определение частных буферов уменьшает количество буферов в общем буферном пуле (-B), но совокупно не может быть более 25 % от общего буферного пула. Установить необходимое количество частных буферов можно так же и с помощью ABL или SQL. Для этого необходимо изменить значения поля _MyConn-NumSeqBuffers в виртуальной таблице (VST) _MyConnection. Как только таблица будет изменена, частные буфера будут динамически запрошены и станут доступны для приложения.

Следующий пример демонстрирует установку частных буферов с помощью ABL:

/*Устанавливаем 6 частных буферов для текущего приложения*/
FIND _MyConnection.
_MyConnection._MyConn-NumSeqBuffers = 6.

/*блок чтения данных*/
/*Отключаем частные буфера от приложения*/
FIND _MyConnection.
_MyConnection._MyConn-NumSeqBuffers = 0.

Следующий пример демонстрирует то же самое, но для SQL:

UPDATE pub."_MyConnection" SET "_MyConn-NumSeqBuffers" = 6.
UPDATE pub."_MyConnection" SET "_MyConn-NumSeqBuffers" = 0.

Использование APW для улучшения производительности

Для использования APW необходима лицензия Enterprise. APW крайне рекомендуют для улучшения производительности по следующим причинам:

Они гарантируют, что пустые буферы будут всегда доступны, и движку базы не нужно будет ждать пока буфер освободится.
Они уменьшают количество буферов, которые движок должен проверить, перед тем как записать измененные буфер на диск. Для сохранения активных буферов в памяти, движок записывает только наиболее давно используемые буферы на диск, а потому, ему необходимо тратить время на их поиск.
Они уменьшают нагрузку, связанную с checkpoint, поскольку на диск в момент checkpoint будет записано меньше измененных буферов.

APW должны быть запущены вручную. Запускать и останавливать их можно в любое время не прибегая к останову базы данных.

База данных может иметь один, более одного или вообще ни одного APW процесса. Их количество сильно зависит от ваших приложений и окружающей их среды. Для проверки можно использовать PROMON. Запустите один APW и посмотрите, если во время checkpoint будут сбрасываться буферы, добавьте еще один APW и проверьте заново. Если же ваши приложения не производят ни каких операций по изменению данных, то APW не нужны вообще.

Процессы APW являются самонастраивающимися. Это означает, что как только вы их запустите, не нужно производить настройку дополнительных параметров. Тем не менее, для улучшения скорости их работы можно увеличить размер BI кластера. Для этого можно использовать утилиту PROUTIL с классификатором TRUNCATE BI.

APW непрерывно записывают измененные буферы на диск, делая менее вероятным ожидание сервера при поисках неизмененных буферов. Для поиска измененных буферов, APW сканирует последовательность Block Table (BKTBL). Последовательность BKTBL – это список ссылок на структуры BKTBL, где каждая ссылка указывает на конкретный буфер базы данных. Каждая структура BKTBL содержит флаг, указывающий на то, что буфер изменен. Как только APW находит такой буфер, он немедленно сбрасывает его на диск. Следующий рисунок демонстрирует сканирование процессом APW последовательности BKTBL.

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

Когда движок базы данных записывает измененный буфер на диск, он помечает его как совсем недавно использованный. Это сделано потому, что вероятность того, что понадобятся более старые данные очень мала. Для поиска таких буферов, APW сканирует последовательность LRU. LRU (least recently used chain) это список ссылок на буферы в памяти, к который движок базы использует для получения доступа к ним. LRU цепочка это фиксированная структура которая указывает на начало и конец последовательности. Каждый раз, когда происходит обращение к буферу, сервер блокирует и изменяет LRU цепочку, перемещая буфер в ее конец. Следующий рисунок демонстрирует работу цепочки LRU.

Поскольку все процессы, обращающиеся к LRU, должны блокировать последовательность для изменения – между ними создается конкуренция. Что приводит к снижению производительности, особенно в сильно загруженных системах. APW снижает уровень конкуренции, периодически очищая измененные буферы. А следовательно при необходимости, движок базы данных всегда быстро может найти неизменный буфер.

Еще одна причина, это увеличение производительности за счет снижения нагрузки связанной с контрольными точками (checkpoints) для before-image.

Before-image разделен на кластеры. Когда кластер становится заполненным, возникает контрольная точка. Если информация в кластере к этому времени уже сохранена, кластер просто становится доступным для повторного использования. Многократное использование кластера, уменьшает размеры дискового пространства необходимого для работы BI. Контрольные точки гарантируют, что кластеры могут повторно использоваться и что в случае необходимости, база данных будет восстановлена в короткие сроки. Во время контрольной точки, движок базы записывает все измененные кластеры на диск. Это существенно увеличивает нагрузку, особенно, когда имеются большие BI кластера и большой буферный пул. APW минимизирует нагрузку, за счет постоянной записи измененных буферов на диск. Таким образом, во время контрольной точки, на диск будет записано меньшее количество буферов.

Мониторинг APW

На экране Page Writers Activity утилиты PROMON R&D отображается статистика работы APW процессов.

Не нулевое значение в поле Flushed at Checkpoint говорит о том, что APW не способен достаточно быстро записывать буферы, чтобы предотвратить утечку памяти. Увеличьте количество APW или увеличьте размер кластера, для предотвращения утечки памяти.

Мониторинг пользовательского I/O

Активность таблиц и индексов может быть проверена на уровне каждого пользователя. Такая детализация помогает понять деятельность конкретного пользователя и обеспечивает оценку эффективности запросов. Эти данные собираются VST таблицами _UserTableStat и _UserIndexStat. Для детального изучения которых можно обратиться к части Виртуальные системные таблиц (VST). Запрос к таблицам может быть сделан непосредственно или с помощью PROMON. Для мониторинга активности таблиц выберите PROMON -> R&D -> Other Display -> I/O Operations by User by Table. Для индексов - PROMON -> R&D -> Other Display -> I/O Operations by User by Index.

Существует способ оценки потребления памяти пользовательскими I/O. Для одной таблицы необходимо 32 байта на пользователя, и 40 байт на один индекс. Рассмотрим 500 пользователей работающих со 100 таблицами и 200 индексами. Общее значение необходимой памяти будет рассчитано следующим образом:

500 пользователей * 100 таблиц * 32 байта на таблицу = 1,600,000 байта памяти для таблиц
500 пользователей * 200 индексов * 40 байт на индекс = 4,000,000 байт памяти для индексов
1,600,000 + 4,000,000 = 5,600,000 байт, или приблизительно 5.3 MB

Диапазон области и база мониторинга таблиц и индексов для этих таблиц устанавливается при запуске сервера базы данных. По умолчанию мониторингу подвергаются первые 100 объектов базы данных.

Параметр	Назначение
-basetable n	Начать мониторинг с таблицы n. По умолчанию – 1. Изменить параметр можно в online, изменив значение поля _TableBase таблицы _StatBase
-tablerange n	Мониторинг n таблиц. По умолчанию – 100
-baseindex n	Начать мониторинг с n индекса. По умолчанию – 1. Изменить можно в поле _IndexBase таблицы _StatBase.
-indexrange n	Мониторинг n индексов. По умолчанию - 100

Параметры –basetable и –baseindex нельзя менять во время работы базы данных. Для уменьшения использования памяти, значение параметров –indexrange и –tablerange желательно устанавливать маленькими.

Before-image I/O

Before-imaging обеспечивает откат транзакций в случае, когда происходит сбой в базе данных. Этот механизм чрезвычайно важен для обеспечения надежности работы базы, но он так же генерирует значимую I/O нагрузку, которая влияет на производительность. Кроме того, before-image I/O обычно наиболее вероятный кандидат на узкой место. Движок базы данных всегда записывает изменения в BI файлы перед тем как записать их в базу данных и after-image файлы. Если BI активность создает высокую I/O нагрузку, это влияет на всю деятельность базы данных.

Уменьшить влияние BI на производительность можно:

Переместив BI файл на отдельный диск
Запустив процесс BIW, если установлена лицензия Enterprise
Увеличив количество BI буферов
Увеличив размер BI кластера
Увеличив размер BI блока
Отсрочив BI запись

Мониторинг BI активности

Для мониторинга I/O активности диска, на котором расположен BI файл, используются утилиты операционной системы. Для контроля определенной BI активность используется утилита PROMON. Для этого предназначена опция R&D BI Log Activity.

Обратите внимание на следующие потенциальные проблемы:

Ожидания занятых буферов (Busy buffer waits)
Ожидания пустых буферов (Empty buffer waits)
Большое количество записей в секунду
Большое количество частичных записей (partial write). Частичная запись возникает, когда движок базы вынужден записывать данные BI файла прежде, чем BI буфер будет заполнен. Это может произойти если:
      APW пытается записать блок базы данных, изменения которого зарегистрированы в BI буфере, но еще не записаны. Поскольку записи BI должны быть сброшены на диск прежде, чем записи AI, APW записывает их прежде чем BI буфер будет заполнен, давая возможность работы AI.
      Процесс AIW отрабатывает прежде процесса BIW. По той же причине, что и предыдущее поведение.
      Значение параметра –Mf истекает прежде чем буфер будет заполнен.

Размещение BI файла

Преимущества размещения файлов базы данных были описаны в части Disk I/O.

Вкратце можно сказать, размещая экстенты BI файла на отдельном диске, это сильно помогает балансировать I/O нагрузку.

Использование before-image writer (BIW)

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

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

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

Можно запустить только один процесс BIW. Его запуск осуществляется вручную. И запуск, и остановка процесса может быть выполнена в любое время без остановки базы данных.

Поддержка большого количества BI буферов

Увеличить количество буферов в буферном пуле bi можно с помощью параметра запуска Before-image Buffers (-bibufs). Увеличение буферов, увеличивает количество доступных пустых буферов для процессов и клиентов. Для начала, можно установить его равным 20. Дальнейшее увеличение будет зависеть от того, какое значение будет в поле Empty buffer waits в PROMON Activity или R&D Bi Log Activity – идеальный вариант 0.

Увеличение размера BI кластера

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

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

Большие размеры кластеров обычно улучшают производительность, но тем не менее, у них есть и свои недостатки:

Увеличивается дисковое пространство, используемое BI файлом
Период восстановления (crash recovery) длится дольше
Увеличивается интервал между контрольными точками (устраняется запуском дополнительного APW)

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

1. Остановите работу базы данных стандартными средствами, например, с помощью PROSHUT или PROMON Shutdown a Database
2. Введите команду:

proutil db-name -C truncate bi -bi size

Новый размер, size, должен быть указан в килобайтах. Значение должно быть кратно 16, в пределах от 16 до 262128 (16K – 256 MB). По умолчание размер кластера равен 512K. Обычно устанавливается размер от 512 до 16384.

С помощью этой же команды вы можете изменить и размер BI блока, о чем будет рассказано немного позже.

Увеличение количества BI кластеров

Когда вы создаете новую базу данных, по умолчанию создаются четыре BI кластера, каждый по 512K. Как только кластер заполняется, возникает checkpoint, а движок базы переключается на запись в следующий кластер цепочки. Следующий рисунок иллюстрирует первоначальное состояние BI кластеров:

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

Со временем, количество BI кластеров вырастает до необходимого, можно сказать оптимального, уровня. Но вы можете сами вычислить необходимое количество BI кластеров для вашей базы данных, разделив физический размер BI файла на размер BI кластера. Например, BI файл, имеющий физический размер 917504 и размер BI кластера равным 128K, будет содержать 7 BI кластеров.

Каждый раз, при усечении BI файла (truncate bi), необходимо устанавливать оптимальное количество BI кластеров перед перезапуском базы данных, тем самым за ранее предотвращая возможный рост количества кластеров движком базы. BI файл всегда усекается когда:

Запускается механизм after-imaging (RFUTIL AIMAGE BEGIN)
Запускается переиндексация (PROUTIL IDXBUILD)
Происходит ручное усечение (PROUTIL TRUNCATE BI)

Чтобы увеличить количество BI кластеров введите следующую команду:

proutil db-name -C bigrow n

Где, n, определяет количество BI кластеров, которое вы хотите создать для этой базы данных.

Увеличение размера BI блока

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

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

Для изменения размера блока необходимо:

1. Остановить базу данных (PROSHUT или PROMON Shutdown a Database)
2. Ввести следующую команду:

proutil db-name -C truncate bi -biblocksize size

Где, size, это новый размер блока указанный в килобайтах. Корректными значениями будут являться – 0, 1, 2, 4, 8 и 16.

Для получения более подробной информации по этой команде, обратитесь к части Утилита PROUTIL.

Задержка записи BI

При использовании параметра запуска Delayed By File Write (-Mf), который установлен в ноль, для улучшения производительности используйте технику Group Commit. Она предполагает, что для общего улучшения производительности, каждая транзакция может выполняться слегка дольше. Например, когда транзакция завершается и начинает записываться в BI файл, она ожидает короткое время пока не случится одно из двух: буфер будет заполнен и записан на диск или несколько других транзакций завершатся и запишутся в BI буфер, чтобы синхронно записаться на диск за один раз. Используете параметр запуска Group Delay (-groupdelay) чтобы установить время (в миллисекундах) ожидания транзакции.

Если техника Group Delay не поможет улучшить производительность, можно использовать параметр запуска –Mf, для задержки записи BI файла.

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

Установка параметра –Mf на время задерживает BI запись. Когда он установлен в положительное значение, последняя BI запись гарантирует запись на диск через определенное количество секунд. Запись записывается быстрее, если пользователь отключается или система выключается.

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

Установка порога BI

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

Используйте параметр Recovery Log Threshold (-bithold) для установки порогового значения, до которого BI файл может вырасти. Как только этот порог будет достигнут, база данных выполнит аварийный останов. Этот механизм, по крайне мере, гарантирует, что при восстановлении будет найдено достаточное количество дискового пространства. Все сообщения, связанные с достижением порогового значения, записываются в журнал базы данных (.lg).

Эти сообщения включают:

Значение порога
Предупреждающее сообщение, если порог установлен свыше 1000MB
Предупреждающее сообщение, когда BI файл расширен
Сообщение о выключении базы данных при достижении порога.

Рекомендуемый диапазон установки значения параметра, от 3 до 100 процентов самого большого возможного размера BI файла, округленного до ближайшей границы кластера. Если порог установлен больше 1000MB, движок базы данных записывает предупреждающее сообщение в журнал базы (.lg) и выводит его на экран. Система проверяет общий размер BI кластеров каждый раз, когда новый кластер помечается как используемый. Если используется параметр No Crash Protection (-i), то порог принимает значение по умолчанию (отсутствие порога), которое не может быть изменено.

Использование Threshold Stall

Конечно же вы наверное не захотели бы, чтобы база данных самостоятельно аварийно отключалась при достижении порогового значения. Параметр запуска Threshold Stall (-bistall) останавливает активность базы данных при достижении порогового значения BI файлом. Т.е. вместо не предвиденного отключения, база данных ждет вмешательства администратора. Это дает администратору некоторые преимущества, например, возможность увеличить дисковое пространство и значение порога. При использовании параметра, в журнал базы данных (.lg) будет записано соответствующее сообщение.

Использование PROQUIET для корректировки порогового значения BI

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

Для изменения порогового значения используйте:

1. Выполните команду PROQUIET для активации точки останова базы данных (quiet point):

proquiet db-name enable

После выполнения этой команды, вся файловая активность базы данных будет остановлена.

Любые процессы, которые попытаются начать транзакцию, будут ожидать, пока точка останова (quiet point) не будет деактивирована.

2. Измените значение, используя параметр –bithreshold:

proquiet db-name -bithreshold n

Где n, определяет новое пороговое значение.

3. деактивируйте точку останова (quiet point):

proquiet db-name disable

After-image I/O

After-imaging – это не обязательный механизм восстановления, который позволяет восстанавливать данные и транзакции, в случае, если сбой произошел на диске. AI файлы должны хранится на отдельном, от базы данных и BI файла, диске, поскольку таким образом I/O активность AI файлов не будет связана с активностью базы данных и BI файла. Тем не менее, after-imaging может создавать высокую дисковую активность, влияя тем самым на производительность в целом. Уменьшить это влияние можно следующим образом:

для систем с Enterprise лицензией, используйте After-Image Writer (AIW)
изменением размера AI блока

Мониторинг AI активности

С помощью утилит операционной системы определите величину I/O активности на диске где расположены AI файлы.

Для более подробных показателей используйте утилиту PROMON, опцию R&D AI Log Activity.

Использование AIW

AIW это фоновый процесс, пишущий AI буферы на диск после их заполнения. Если процесс работает эффективно, клиентские и серверные процессы редко должны редко ожидать пока измененный буфер будет записан на диск.

Буферный AI пул – это циклическая цепочка буферов. Движок базы данных заполняет их поочередно. Буфер, заполняемый движком базы данных это текущий выходной буфер. Любой буфер может становится текущим выходным, так как движок заполняет их двигаясь по кругу по цепочке. Если следующий буфер уже был изменен, движок должен ожидать пока этот буфер будет записан на диск.

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

Увеличение значения параметра запуска –aibufs, увеличивает количество буферов в буферном AI пуле, обеспечивая клиентские и серверные процессы доступными пустыми буферами. Устанавливайте значение –aibufs в 1.5 раза от значения –bibufs. Изменение этого параметра бессмысленно если процесс AIW не работает.

Увеличение размера AI блока

Как и с before-imaging, движок базы данных читает и записывает информацию в AI файлы по блокам. Увеличение размера AI блока позволяет движку читать и писать больше данных за один раз. Это может уменьшить I/O загрузку дисков на которых размещены AI файлы. Для систем с низкой транзакционной активностью, значение размера блока по умолчанию (8K) достаточно. Тем не менее, если мониторинг производительности показывает, что AI запись является узким местом и вы уверены, что ваша система может обеспечить большую эффективности по записи, увеличение размера AI блока может улучшить производительность. Больший размер блока так же мог бы улучшить эффективность при накате AI файлов в механизме Roll-Forward Recovery.

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

1. используйте команду PROSHUT или RPOMON Shutdown a Database для останова базы данных.
2. если after-imaging активирован, деактивируйте его с помощью следующей команды:

rfutil db-name -C aimage end

3. Усеките BI файл, чтобы обновить базу данных и BI файл, а также исключить какое-либо восстановление. Для этого воспользуйтесь следующей командой:

proutil db-name -C truncate bi- [ -bi size | -biblocksize size ]

Обычно, если вы меняете размер AI блока, вы должны изменить и размер BI блока. Если вы собираетесь это сделать, то можете сделать это сейчас.

4. Измените размер AI блока следующей командой:

rfutil db-name -C aimage truncate -aiblocksize size [ -a aifilename ]

Где size, определяет размер AI блока в килобайтах. Минимально возможное значение равно размеру блока базы данных. Корректными значениями являются – 0, 1, 2, 4, 8 и 16. Если будет определен 0, RFUTIL использует значение по умолчанию (8K).

5. Выполните полную резервную копию базы данных. Это не обходимо, поскольку копии базы и AI файлы созданные до изменения размера AI блока, теперь не будут корректными с новым установленным размером.

6. Активируйте after-imaging:

rfutil db-name -C aimage begin { buffered | unbuffered } -a ai-name

7. Перезапустите базу данных и продолжите работу.

Direct I/O

Движок базы данных может использовать технику I/O, которая вынуждает блоки писаться непосредственно из буферного пула на диск. Это не обязательная техника, которая предотвращает запись на диск от задержек связанных с буферным менеджером операционной системы.

Обычно Direct I/O используется если не достаточно памяти. Во многих случаях нормальная работы буферного менеджера обеспечивает хорошую производительность. Протестируйте влияние Direct I/O перед применением его на промышленной базе.

Чтобы использовать эту возможность, воспользуйтесь параметром запуска Direct I/O (-directio). Поскольку при использовании этого параметра, базе данных требуется большее время отработки APW, вам необходимо запустить дополнительный процесс APW для компенсации этого времени.

Использование памяти

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

Мониторинг использования памяти

Используйте следующие опции утилиты PROMON для мониторинга использования памяти:

Activity - отображает количество разделяемой памяти, используемой базой, и количество сегментов разделяемой памяти.
Shared Resources Status (an R&D option) – показывает количество размещенной разделяемой памяти.
Shared-memory Segments Status (an R&D option) – отображает номер ID, размер и количество используемой для каждого сегмента разделяемой памяти.

Контроль использования памяти

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

Параметр запуска	Предлагаемое использование
Blocks in Database Buffers (-B)	Увеличение размера буфера уменьшает дисковую активность, увеличивая количество буферов расположенных в памяти. Соответственно это увеличивает использование памяти. Увеличьте значение –B чтобы уменьшить дисковую активность. Или уменьшите значение параметра, если размеры памяти ограничены или начался «пайджинг» (paging)
Maximum Clients per Server (-Ma)¹	Если удаленные клиенты перегружают сервер или исчерпываются файловые дескрипторы системы, настройка этого параметра позволит ограничить количество таких клиентов.
Maximum Servers (-Mn) ¹	Если сервер с клиентами становится перегружен, установка этого параметра ограничивает количество серверов. Если вы увеличиваете этот параметр, вы так же должны увеличить параметр Minimum Clients per Server (-Mi)
Number of Users (-n)	Установите этот параметры в значение, достаточное для размещение всех локальных и удаленных клиентов
Pin Shared Memory (-pinshm)	Используйте этот параметр для предотвращения «свопинга» (swapping) разделяемой памяти на диск.

^1. актуально только для баз данных, работающих в режиме клиент/сервер

Распределение разделяемой памяти

В версиях 10.1B и выше, распределение разделяемой памяти происходит динамически. До этого сегменты разделяемой памяти были фиксированного размера, теперь же, оптимальный размер сегментов рассчитывается динамически во время работы базы данных. Брокер пытается разместить сегмент с наиболее возможным размеров и наименьшим количеством сегментов требуемых для разделяемой памяти. Результат – более эффективное распределением сегментов памяти с большим размером. К тому же, становится возможным создавать большее количество самообслуживающихся соединений с большой разделяемой памятью.

Максимальный размер сегмента разделяемой памяти может быть определен при старте базы данных. Увеличение размера сегмента уменьшает их количество. Размер определяется параметром запуска Shared memory segment size (-shmsegsize n).

Размеры разделяемой памяти определенной для базы данных зависит от вашей операционной системы и ограничено следующим образом:

Сервер базы данных не может создать сегменты разделяемой памяти больше чем это определено параметром операционной системы (Maximum Shared Memory Segment Size). Если параметр –shmsegsize определен больше чем установлено системой, будет использоваться настройка операционной системы. Не все платформы операционных систем могут устанавливать максимальный размер сегмента, например, Windows и AIX этого не делают. Для многих UNIX систем максимальный размер сегмента устанавливается параметром ядра SHMMAX
Сервер базы данных не может создать больше сегментов разделяемой памяти, чем разрешено операционной системой. Этот параметр не настраиваемый во всех операционных системах, за исключением некоторых UNIX платформ, в которых настройка происходит параметром ядра SHMSEG
Сервер базы данных не может создать разделяемые сегменты памяти превышающие возможное адресное пространство для системы. Для 32-битных систем теоретический максимум – 4GB, на практике это значение намного меньше, и зависит от многих факторов системы, например, запущенных на ней процессов, которые так же используют разделяемую память. Для 64-битных платформ, физические ограничения системы имеют практический максимум значительно ниже любого теоретически вычисленного максимума. Если запрашиваемое количество разделяемой памяти превышает способности системы, сервер просто не будет запущен.

Смотрите документацию по вашей операционной системе, для получения более подробной информации о настройке сегментов разделяемой памяти.

Ресурсы операционной системы

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

Процессы

Следующие функции работают как процессы:

Брокеры
Серверы
Клиенты
APW, BIW и AIW

Таблица пользователя определяет один процесс на каждого пользователя. Используйте параметр Number of Users (-n) для установления количества пользователей.

В UNIX, параметр NPROC ограничивает общее количество активных процессов в системе и обычно установлен между 50 и 200. Параметр MAXUP ограничивает количество параллельных процессов, которые могут быть запущены одним пользовательским ID и обычно установлен в промежутке от 15 до 25. Так же, если с одним пользовательским ID в системе зарегистрируется несколько пользователей, то MAXUP достаточно быстро будет превышен. Когда это предел превышен, необходимо искать следующие сообщения об ошибке:

Unable to fork process.

Если это сообщение повторяется многократно, необходимо перенастроить ядро системы.

Семафоры

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

Следующий рисунок демонстрирует процесс контроля семафорами доступа к разделяемому ресурсу:

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

Семафоры группируются в наборы семафоров. Каждый набор семафоров имеет уникальный идентификатор – semid. Внутри набора семафоров, каждый семафор нумеруется целым числом от нуля (0) до количество семафоров в наборе минус один.

Брокер OpenEdge пред распределяет семафору при запуске базы командой PROSERVE. Каждый процесс требует своего семафора. Но брокер непосредственно использует два дополнительных семафора. Движок базы данных использует следующую формулы для определения необходимого количества семафоров (#SEM):

#SEM = Max-possible-users (-n) + Max-possible-servers (-Mn) + 4

Следующая таблица содержит параметры ядра UNIX контролирующие количество и размеры наборов семафоров:

Параметр	Описание	Рекомендуемые настройки
SEMMNI	Максимальное количество наборов семафоров возможное в системе	Один на активную многопользовательскую базу данных. Если значение установлено слишком низким, движок базы сгенерирует ошибку номер 1131
SEMMSL	Максимальное количество семафоров в наборе семафоров.	(Max-local-users-on-any-databases + Max-#servers-on-any-databases + 4). Если значение будет недостаточным, движок сгенерирует ошибки 1093 и 1130
SEMMNS	Общее количество семафоров в системе	SEMMSL * количество активных баз данных Если значение будет недостаточным, движок сгенерирует ошибки 1093, 1131 или 1195
SEMMNU	Максимальное количество семафоров undo structures	Значение такое же как и у SEMMNS. Если значение будет недостаточным, движок сгенерирует ошибку 1081

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

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

С помощью PROMON и его опции R&D Shared Resources можно посмотреть количество используемых семафоров. Кроме того, при запуске брокера, будет выдано сообщение о доступных семафорах. При увеличении количества пользователей, движок базы может превысить максимальное число разрешенных семафоров, указанных параметром SEMMNS. В этом случае вам придется переконфигурировать параметры ядра системы. Вы можете повлиять на количество используемых семафоров, только уменьшая значения параметров запуска Number of Users (-n) и/или Maximum servers (-Mn).

Распределение семафоров

По умолчанию, движок базы данных использует один набор семафоров для всех семафоров, необходимых базе данных. При подключении к одной базе более 1000 пользователей, может возникнуть конкуренция за семафоры. Использование многочисленных наборов семафоров помогает улучшить положение. Параметр запуска брокера Semaphore Sets (-semsets) позволяет изменять количество наборов семафоров доступных для брокера OpenEdge.

Брокер использует две группы семафоров – Login и User. Login – семафоры используются для подключения к базе данных. User семафоры распределяются по одному на пользователя, количество пользователей определено параметром Number Of Users (-n). User – семафоры распределяются используя циклический механизм. Если вы определяете параметр Semaphore Sets, PROSERVE размещает один набор для Login – семафоров, а остальные наборы определяет как User – семафоры.

В следующем примере брокер использует два набора семафоров, один для Login – семафоров и один для User – семафоров:

proserve db-name -semsets 2 -n 10

А следующий пример демонстрирует использование трех наборов, один под Login – семафоры, и два набора по пять User – семафоров:

proserve db-name -semsets 2 -n 10

Spin locks

Во многопроцессорных системах, движок базы данных использует алгоритм spin lock для контроля доступа к памяти. Это алгоритм работает следующим образом: когда процессу требуется ресурс памяти, он пытается получить блокировку ресурса. Если блокировка не может быть получена, он повторяет попытку. Этот итеративный процесс называется spinning. Если через определенное количество попыток (spins) процесс не получит блокировку, он «засыпает», чтобы потом повторить все с начала. С каждой новой попыткой время «спячки» процесса увеличивается. Поэтому можно установить свое количество попыток прежде чем процесс «уснет», это делается с помощью параметра Spin Lock Retries (-spin).

Файловые дескрипторы

Файловые дескрипторы (file descriptor) это идентификатор назначаемые открытому файлу. Существует определенное ограничение на количество таких дескрипторов. Каждый процесс базы данных может использовать до 15 и более файловых дескрипторов. Соответственно, ограничение по количеству файловых дескрипторов в системе должно устанавливаться как минимум в 15 раз большее чем количество возможных процессов. Не забудьте, что для операционной системы так же необходимо как минимум 10 файловых дескрипторов.

Фрагментация базы данных

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

Анализ фрагментации базы данных

Для определение степени фрагментации таблиц базы данных используется утилита PROUTIL с классификатором TABANALYS:

proutil db-name -C tabanalys

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

Результат TABANALYS отображает следующую информацию:

Count – общее количество фрагментов записей найденных в каждой таблице базы данных.
Fragments Factor – степень фрагментации записей для каждой таблицы. Если значение 2.0 и более то необходима обязательная перезагрузка. Если же в районе 1.5 – перезагрузка не обязательна.
Scatter Factor – Степень расстояния между записями в таблице. Оптимальная величина зависит от базы данных и может меняться. Для определения оптимального значения запустите TABANALYS на только что перезагруженной базе данных. И в последствии основывайтесь на его результатах в качестве эталонных.

Следующий пример демонстрирует отрывок из PROUTIL TABANALYS:

Устранение фрагментации базы данных

Устранить фрагментацию таблиц базы данных можно двумя способами:

1. Перезагрузка базы данных (D&L). Перезагрузка базы данных создается новую стартовую версию базы и загружает в нее содержимое таблиц. В течении стадии загрузки, любые пространства оставленные удаленными записями, будут удалены, т.о. более эффективно распределяя дисковое пространство. Существует множество методов перезагрузки данных, которые будут описаны в отдельной части этой книги.

2. Перемещение отдельных таблиц и индексов. Для перемещения таблиц и индексов из одной области хранения в другую можно использовать PROUTIL с классификаторами TABLEMOVE и IDXMOVE, причем в online. В результате дисковое пространство будет более эффективно перераспределено.

Управление фрагментацией

Записи размещены в блоках, а блоки согласно определенным алгоритмам стремятся максимально использовать память и минимизировать фрагментацию. При размещении новой записи, движок базы сначала ищет свободное место в блоках RM цепочки. RM цепочка – это набор частично заполненных блоков. Если такой блок не найдется, то запись будет вставлена в блок из цепочки свободных блоков. Свободная цепочка (free chain) – это цепочка состоящая из empty - блоков. Если блок в начале RM цепочки содержит достаточное количество свободного пространства для сохранения записи, использован будет именно он. Если запись больше чем свободное место в блоке, то она разбивается на два или более фрагмента. При сохранении записи в блоке обязательно резервируется часть места, с целю дальнейшего возможного увеличения записи.

Имеются следующие ограничения по свободному пространству в блоках:

Create Limit – минимальное количество свободного пространства в байтах оставшееся в блоке после добавление записи. Этот предел должен быть больше 32 и меньше чем размер блока минус 128. Для размера блока 1K, предел равен 75. Для всех остальных размеров значение по умолчанию равно 150.
Toss Limit – минимальное количество свободного пространства в байтах, которое должно оставаться в блоке, чтобы не исключать его из RM цепочки. Как только в блоке останется меньше места чем определено в пределе, он будет удален из RM цепочки, а оставшееся свободное пространство будет использоваться для возможного расширения записей, уже находящихся в блоке. Для размера блока 1K, предел равен 150. Для всех остальных – 300.

Изменить Create и Toss Limits можно с помощью PROUTIL. Для областей хранения Type I они меняются на уровне областей. Для Type II – как на уровне областей, так и на уровне объектов. Общий синтаксис утилиты PROUTIL, для изменения этих пределов, следующий:

proutil db-name -C SET-obj-limittype-LIMIT object-idenitifer new-limit

В следующей таблице описаны классификаторы PROUTIL, предназначенные для изменения Create/Toss Limits:

Limit	Тип объекта	Классификатор
Create	Area BLOB Table	SETAREACREATELIMIT SETBLOBCREATELIMIT SETTABLECREATELIMIT
Toss	Area BLOB Table	SETAREATOSSLIMIT SETBLOBTOSSLIMIT SETTABLETOSSLIMIT

Для определения текущих значений этих пределом используйте команду PROUTIL DISPTOSSCREATELIMITS, с указанием конкретной области хранения.

Create/Toss Limits желательно изменять только в случае если у вас наблюдается высокая фрагментация данных или неэффективное использование пространства в блоках. В следующей таблице описаны возможные ситуации, приводящие к необходимости изменения пределов, и способы их решения:

Ситуация	Возможное решение
Фрагментация возникает при изменении существующих записей. Ожидался один фрагмент, а созданы были два.	Увеличьте Create Limit
Фрагментация возникает при изменении существующих записей или имеется множество RM блоков с недостаточным пространством для создания новой записи.	Увеличьте Toss Limit
Существует средняя фрагментация, но пространство блоков базы используется не эффективно, а существующие записи не предполагают изменение своего размера.	Уменьшите Create Limit и Toss Limit

Увеличение Create/Toss Limits позволяет записи расти больше в пределах блока прежде чем будет использован другой блок. Так как оба предела определяют резерв для роста существующих записей. Если проверка Create Limit покажет не достаточное пространство, новая запись будет размещена в другом блоке. Но остается вероятность, что в этот блок может быть помещена другая запись, меньшая по размеру, поэтому, по результатам проверки Create Limit, блок не удаляется из RM цепочки. Если же при проверке Toss Limit, при расширении записи, окажется что предел достигнут, блок будет удален из RM цепочки, и никакие новые записи не смогут быть включены в него.

Уменьшение Create/Toss Limits решает проблемы с неэффективным использованием пространства блока. Например, когда блоки имеют большое количество свободного пространства и при этом рост размеров существующих записей не предполагается. В этом случае, новые записи могут быть не добавлены в блок, поскольку проверки пределов этого не позволяют, а следовательно пределы можно уменьшить. Уменьшение Create Limit увеличивает вероятность, что новая запись может быть добавлена в блок, а уменьшение Toss Limit позволяет блоку оставаться в RM цепочке дольше.

Использование индексов

Поскольку блоки базы данных могут фрагментироваться, индексные блоки через определенное время так же становятся разобщенными. Оптимальная степень использования индексных блоков зависит от выполненного доступа к базе данных. Производительность приложений с интенсивным поиском намного выше, когда индексные блоки наиболее заполнены, поскольку движку базы данных необходимо обращаться к меньшему количеству блоков при формировании отчета. Чем больше индекс, тем выше вероятность улучшения производительности при его сжатии. Обратно этому, приложения интенсивно изменяющие данные, работают лучше с свободно размещенными индексами, поскольку в блоках остается пространство, позволяющее вставлять новый ключи без размещения новых блоков. Анализ индексов предоставляет необходимую информацию, для принятия решения по улучшению производительности. Необходимо найти некий баланс между сжатым и свободным размещением индексов, что несомненно зависит от имеющихся у вас данных и работающих с ними приложений. Для сжатия индексов можно использовать утилиту PROUTIL с классификатором IDXCOMPACT, о ней будет рассказано далее в этой части.

Анализ использования индексов

Используйте PROUTIL IDXANALYS для получения информации об индексных блоках и их использовании. Синтаксис команды следующий:

proutil db-name -C idxanalys

Где, db-name - это имя анализируемой базы.

IDXANALYS обеспечивает следующими данными:

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

IDXANALYS, так же можно запускать на работающей базе данных, но в этом случае результаты его работы будут приблизительными.

Наиболее важное поле в результате IDXANALYS - % Util. Это поле показывает степень использования индекса. Если индекс состоит из нескольких сотен блоков и процент индексного использования 85 или выше, это оптимальное значение. Существует два способы увеличения процента индексного использования:

Сжатие индекса в online или offline, с использованием PROUTIL IDXCOMPACT.
Переиндексация и сжатие индекса в offline, с помощью PROUTIL IDXBUILD.

Поле Levels показывает количество чтений индекса за один раз. Поля Blocks и Bytes отображают размер каждого индекса. Factor – это индексный показатель, сигнализирующий о необходимости перестройки индекса. Следующая таблица показывает допустимые значения индексного показателя и необходимые действия:

Значение Factor	Действие
1.0 - 1.5	Индекс в хорошем состоянии
1.5 – 2.0	Возможно индекс нуждается в уплотнении
2.0 и >	Требуется переиндексация индекса

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

Сжатие индексов

Если процент индексного использования оказывается в районе 60 и менее, то имеет смысл воспользоваться утилитой PROUTIL IDXCOMPACT, для уплотнения индекса в online. Уплотнение индекса увеличивает используемое пространство в индексном блоке. Например:

proutil db-name -C idxcompact [ owner-name.]table-name.index-name [n]

Уплотнение уменьшает количество блоков в b-дереве и возможно количество уровней в нем, что несомненно увеличивает производительность.

Уплотнение индекса происходит несколькими этапами:

Этап 1 – если индекс уникальный, то сканируется цепочка удаленных индексов и индексные блоки очищаются от удаленных ключей.
Этап 2 – не листовые уровни в b-дереве уплотняются, начиная с корня до листовых уровней.
Этап 3 – уплотняются листовые уровни.

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

Переиндексация

Классификатор IDXBUILD (Index Rebuild) утилиты PROUTIL используется для:

Сжатия индексных блоков с целью минимизации использования дискового пространства
Активации всех ранее деактивированных индексов в базе данных
Исправления поврежденных индексов в базе данных (о поврежденных индексах информируется соответствующими сообщениями).

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

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

Для запуска переиндексации используйте следующую команду:

proutil db-name -C idxbuild
[ all |
table [owner-name.]table-name |
area area-name | schema schema-owner |
activeindexes | inactiveindexes ]
[ -T dir-name ]|[ -SS sort-file-directory-specification ]
[ -TB blocksize ][ -TM n ] [ -B n ] [ -SG n ]
[-threads n ] [-threadnum n ]

Если команда будет запущена без параметров All, table, area или schema, на экране будет отображено следующее меню:

Index Rebuild Utility
Select one of the following:
All                    (a/A) - Rebuild all the indexes
Some               (s/S) - Rebuild only some of the indexes
By Area           (r/R) - Rebuild indexes in selected areas
By Schema     (c/C) - Rebuild indexes by schema owners
By Table          (t/T) - Rebuild indexes in selected tables
By Activation (v/V) - Rebuild selected active or inactive indexes
Quit        (q/Q) - Quit, do not rebuild
Enter your selection:

Параметр All используется для переиндексации всех индексов. Same – для конкретного индекса.

By Area – для переиндексации всех индексов определенных для одной или нескольких областей.

By Schema – для переиндексации индексов принадлежащих одному или более владельцам схемы.

By Table – переиндексация индексов конкретных таблиц.

By Activation – для выбора активных или неактивных индексов.

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

Для определения необходимого дискового пространства для сортировки индексов, используйте следующие формулы:

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

(size of one index entry) * (number of records in file) * 3

PROUTIL IDXBUILD отрабатывает в три этапа:

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

При работе IDXBUILD, сообщения выдаются в основном только в случае возникновения ошибки.

Для баз данных с Enterprise лицензией переиндексация по умолчанию является многопоточной. При этом, максимальное количество потоков можно задать используя параметр –threadnum n. Если же параметр не определен, то максимальное количество потоков будет равно количество CPU в вашей системе. Фактически, количество созданных потоков не будет превышать количество индексных групп в области, конечно же, если это значение меньше чем максимальное. Во время многопоточного выполнения, отдельные потоки назначаются каждой индексной группе на втором этапе. Как только основной процесс создаст все необходимые потоки на втором этапе, он немедленно приступает к формированию индексного дерева для третьего этапа. Допускается, что второй и третьи этапы могут работать параллельно. Если же в области будет находиться только один индекс, то при переиндексации потоки использоваться не будут.

Если же вы не хотите выполнять переиндексацию в многопоточном режиме, укажите значение параметра –threads равным нулю. Что укажет IDXBUILD об отсутствии необходимости работать в многопоточном режиме.

Если работа переиндексации по каким-либо причинам была прервана, список выбранных для индексации индексов сохраняется в файле dbname.xb. Этот файл используется утилитой при повторном запуске переиндексации. Нельзя вручную изменять список индексов в .xb файле.

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

При запуске переиндексации и использовании параметра Sort, вы можете столкнуться с проблемой нехватки свободного места на диске, что приведет к аварийному завершению работы. Во избежание этого, необходимо создать файл, содержащий определения каталогов и их размеров, которые будут использоваться файлами сортировки при переиндексации. Этот файл должен быть текстовым, иметь тоже название, что и база данных, но с расширением .srt (dbname.srt), и располагаться в том же каталоге, что и сама база данных. Кроме того, содержания файла должно соответствовать следующим правилам:

Описание каждого каталога должно располагаться на отдельной строке.
Размер каталога это максимальный размер файла до которого он может вырасти. Если размер установлен 0, то это говорит о том, что будет использовано все возможное дисковое пространство.
Описание каталога и его размера должны быть разделены как минимум одним пробелом.
Строка должна заканчиваться наклонной чертой (/), что говорит о ее завершении.
Для многопоточной переиндексации, распределите каталоги на столько различных устройств, на сколько это возможно. Каждый поток использует свой каталог по списку. Поэтому, если все каталоги будут находиться на одном диске, это значительно увеличит дисковую активность, тем самым понижая производительность переиндексации.

Например, при переиндексации базы sports для увеличения скорости сортировки мы используем 300K для диска /user2/db1/first, 400K в /user3/junk, и неограниченное пространство в /user4/last, в этом случае srt файл будет следующим:

Для UNIX:

300 /user2/db1/first/
400 /user3/junk/
0 /user4/last/

Для Windows:

300 d:\temp
400 e:\temp
0 f:\temp

Утилита переиндексации обращается к файлам в порядке, в котором они расположены в файле dbname.srt. Если указанное пространство окажется больше чем доступное, переиндексация будет прервана, и при этом следующий диск не будет использован. Т.е., если вы имеете 200K, а указали 300K, переиндексация будет прервана после использованных 200K. Кроме того, если размер установлен 0 (т.е. неограниченное использование пространства), и если место на диске закончится, то все каталоги, определенные после этого каталога, не будут использованы. Поэтому, обязательно убедитесь в наличии необходимого пространства перед начало переиндексации.

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

Temporary sort file at pathname used up to nK of disk space.

или:

Temporary sort file at:pathname will use the available disk space.

Предыдущее сообщение будет отображено даже при отсутствии srt файла.

По завершении сортировки будет выдано следующее сообщение:

Temporary sort file at pathname used nK of disk space.

В некоторых случаях, когда сортировка полностью проходила в памяти, может быть выдано просто «OK».

Если srt файл не используется, то по умолчанию, для сортировки будет использоваться либо текущий каталог, либо каталог определенный параметром «–T».

Улучшение производительности переиндексации

Для ускорения скорости переиндексации необходимо:

Ответить Yes при запросе о наличии необходимого пространства для сортировки.
Увеличить параметр Speed Sort (-TB) до 24K. (Если память ограничена, используйте значение 16K или 8K). Это увеличивает скорость сортировки, но при этом используется больше памяти и дискового пространства.
Увеличить параметр Merge Number (-TM) до 32 (если памяти не достаточно).
Используйте параметр Sort Grouping (-SG). Большое значение, этого параметра, требует большего количества памяти и файловых дескрипторов. Чтобы определить необходимый объем памяти (в килобайтах) для каждой индексной группы, прибавьте к Merge Number (-TM) единицу, и умножьте полученную сумму на размер блока сортировки (значение параметра –TB). Таким образом, потребляемая память для каждой индексной группы будет равна (-TM + 1) * -TB.
Изменить параметр Temporary Directory (-T), чтобы он указывал на отдельный диск.

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

1.    Читает поля ключа индекса и сохраняет в первый доступный блок в SRT файле.
2.    Размещает дополнительные блоки указанного размера в SRT файле, так чтобы обеспечить поддержку всех ключей индекса.
3.    Сортирует ключи в каждом блоке, а затем объединяет их в файле сортировки.

Подобная методика используется для сортировки записей, если отсутствует индекса для удовлетворения утверждения BY.

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

Для определения оптимальных значений, имеет смысл запустить переиндексацию несколько раз с разными параметрами, и выбрать наилучшие. Если наблюдается сильная нехватка памяти при работе, попробуйте установить размер блока равным единицы.

Для начала, попробуйте установить значение –TB 31, при наличии достаточно большого количества памяти и дискового пространства, конечно же. Если индексация будет прервана с ошибкой, попытайтесь последовательно уменьшить значение. При этом всегда помните, чем выше значение этого параметра, тем больше памяти будет использовано. Значение –TB осуществлено влияет на размеры SRT файлов. Размер SRT файла зависит от количества сеансов компиляции файлов и количества и размеров операций сортировки.

Использование памяти зависит от числа одновременно выполняющихся сортировок. Одновременные сортировки, это эквивалент вложенных FOR EACH. Определить количество используемой памяти можно по формуле:

M= sort-block-size * (number-of-simultaneous-sorts+Merge-Number (-TM) parameter)

Переиндексация всегда требует восемь одновременных сортировок, поэтому:

M = sort-block-size *(8+ (-TM) parameter)

А следовательно, в случае, использования по умолчанию:

M = (2*(8+5)) = 26K

Восстановление уникальных индексов

При восстановлении уникальных индексов, IDXBUILD при обнаружении дублирующих ключей выдаст следующее сообщение:

Fix RECID recid, table-name already exists with field-name value.

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

FOR EACH table-name USE-INDEX index-without-duplicate-keys:
UPDATE table-name.

Активация одного индекса

Индексы, добавленный в базу данных в online, остаются не активными пока их специально не активируют утилитой PROUITL IDXACTIVE.

proutil db-name -C idxactivate [owner-name.]table-name.index-name
[useindex table-name.index-name] [recs n] [refresh t]

Перед активацией, IDXACTIVE проверяет что не существует пользователей с временным штампом более ранним чем временной штамп индекса. Если такие пользователи имеются, то IDXBUILD не сможет приступить к работе. Вы можете выбрать опцию ожидания или завершить работу утилиты. Если будет решено ожидать, то необходимо дождаться, пока все пользователи с ранним временным штампом не отсоединятся от базы, или может самостоятельно отключить их с помощью утилиты PROSHUT. Контролировать блокированных пользователей можно обновляя экран статуса блокировки. Отображаемое на экране число, говорит времени обновления экрана в секундах.

Когда IDXACTIVE активирует и строит индекс, он использует транзакции. По умолчанию, в каждую транзакцию включается 100 записей. Это количество можно изменять опцией recs.

В следующем примере демонстрируется активация индекса tst_table.inact3 для базы данных doc_db. При этом ни какие дополнительные параметры не используются. Цикл по отсоединению пользователей со старым временным штампом выполняется дважды.

По завершению работы IDXACTIVE, индекс станет активным и доступным для всех пользователей.

Поддержка структуры базы данных

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

Утилита OpenEdge Structure

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

Утилита OpenEdge Structure Statistics

Утилита OpenEdge Structure Statistics (PROSTRCT STATISTICS) используется для мониторинга размеров базы данных и доступности свободных блоков для хранения данных. Например:

prostrct statistics db-name

Утилита отображает следующую информацию:

Имя базы данных
Размеры блоков primary data, before-image и after-image.
Области хранения и каждый их экстент
Общее количество активных блоков размещенных в каждой области.
Общее количество пустых боков для каждой области
Общее количество расширенных блоков (extent block) для каждой области.
Общее количество всех блоков для каждой области.
RPB (record per block) для каждой области.
Общее количество всех блоков в базе данных (active, data, free, empty, extent)
Дата и время последнего полной и инкрементальной копии.

Работа утилиты в online отображает снимок базы данных в текущий момент времени.

Следующий пример отображает результат работы PROSTRCT STATISTICS для базы данных /data/10/alm/alga/alga.db:

Storage Utilization Statistics
Database: /data/10/alm/alga/alga

Primary data block size: 8192
         BI block size: 16384
         AI block size: 16384

Database Physical structure information
Statistics for Area: Control Area

Files in Area: Control Area
    /data/10/alm/alga/alga.db 655360

Database Block Usage for Area: Control Area
Active blocks: 5
   Data blocks: 5
   Free blocks: 0
Empty blocks: 75
Total blocks: 80
Extent blocks: 1
Records/Block: 64
Cluster size: 1

Statistics for Area: Primary Recovery Area
Files in Area: Primary Recovery Area
    /data/10/alm/alga/alga.b1 33816576

Statistics for Area: Schema Area
Files in Area: Schema Area
    /data/10/alm/alga/alga.d1 82837504

Database Block Usage for Area: Schema Area
Active blocks: 10104
   Data blocks: 10097
   Free blocks: 7
Empty blocks: 8
Total blocks: 10112
Extent blocks: 1
Records/Block: 64
Cluster size: 1

Statistics for Area: After Image Area 1
Files in Area: After Image Area 1
    /data/10/alm/alga/alga.a1 262144
*
*
*
Files in Area: After Image Area 10
    /data/10/alm/alga/alga.a10 262144

Database Block Usage Summary

Active blocks: 10109
   Data blocks: 10102
   Free blocks: 7
Empty blocks: 83
Extent blocks: 2
Total blocks: 10192

Last full database backup on Wed Jan 2 21:55:21 2008. (6942)

Если полная резервная копия ни когда не была выполнена, появится сообщение "NO FULL BACKUP HAS BEEN DONE".

Утилита OpenEdge Structure List

Структурный файл (.st) должен всегда соответствовать текущей информации, находящейся в control area, чтобы гарантировать непрерывность и легкость управления базой данных. Следовательно, необходимо всегда корректировать структурный файл после изменения структуры базы данных (например, после удаления, перемещения или добавления экстентов областей). Для этого используется утилита Structure List (PROSTRCT LIST). Эта утилита формирует новый структурный файл для указанной базы данных на основании информации, хранящейся в Control Area. Запускать утилиту можно в online.

Синтаксис утилиты следующий:

prostrct list db-name [ structure-description-file ]

В этой команде, db-name определяет имя базы данных, а structure-description-file – указывает на имя структурного файла. Если последний параметр не определен, утилиты перезапишет существующий st файл, расположенный в каталоге базы данных.

Утилита OpenEdge Structure Add

Для добавления новых областей или экстентов к существующим областям используется утилита Structure Add (PROSTRCT ADD). Использование этой утилиты возможно только в offline, тем не менее существует утилита PROSTRCT ADDONLINE, для внесения изменений в online.

Для добавления новой области к существующей базе необходимо:

1. сформировать полную резервную копию.
2. Создать новый структурный файл, содержащий только информацию о добавляемой области, например:

# add.st
#
d "chris",128 . f 1024
d "chris" .

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

3. запустить утилиту PROSTRCT с классификатором ADD и указанием нового структурного файла:

prostrct add service add.st

PROSTRCT ADD добавит новую область и ее экстенты в базу данных и добавит их описание в Control Area, после чего отобразит следующую информацию:

Formatting extents:
size       area name           path name
1024         chris              /user/joe/service_9.d1      00:00:00
32              chris             /user/joe/service_9.d2      00:00:01

4. Обновите текущий структурный файл базы данных утилитой PROSTRCT LIST:

prostrct list service service.st

При работе PROSTRCT ADD, если вы указали в команде относительный путь к базе данных, он будут преобразован в абсолютный. Например, если добавить новую область в базу example1 без указания абсолютного пути к ней, и если после этого переформировать структурный файл, то там можно увидеть, что относительный путь к базе данных был заменен на абсолютный.

prostrct add example1 add.st
prostrct list example1

Area Name: Control Area, Type6, BlockSize 4096, Extents 1, Records/Block32,
Cluster Size 1
     Ext # 1, Type VARIABLE, Size 0, Name: /usr1/example1.db

Area Name: Primary Recovery Area, Type3, BlockSize 8192, Extents 1
     Ext # 1, Type VARIABLE, Size 0, Name: /usr1/example1.b1

Area Name: Schema Area, Type6, BlockSize 4096, Extents 1, Records/Block 32,
Cluster Size 1
     Ext # 1, Type VARIABLE, Size 0, Name: /usr1/example1.d1

Area Name: Employee, Type6, BlockSize 1024, Extents 2, Records/Block 32,
Cluster Size 8
     Ext # 1, Type FIXED , Size 320, Name: /usr1/example1_7.d1
     Ext # 2, Type VARIABLE, Size 0, Name: /usr1/example1_7.d2

Area Name: Inventory, Type6, BlockSize 1024, Extents 2, Records/Block 32,
Cluster Size 64
     Ext # 1, Type FIXED , Size 608, Name: /usr1/cmcguire/example1_8.d1
     Ext # 2, Type VARIABLE, Size 0, Name: /usr1/example1_8.d2

Area Name: Cust_Data, Type6, BlockSize 1024, Extents 2, Records/Block 32,
Cluster Size 64
     Ext # 1, Type FIXED , Size 320, Name: /usr1/example1_9.d1
     Ext # 2, Type VARIABLE, Size 0, Name: /usr1/example1_9.d2

Area Name: Cust_Index, Type 6, BlockSize 1024, Extents 2, Records/Block 32
     Ext # 1, Type FIXED , Size 320, Name: /usr1/example1_10.d1
     Ext # 2, Type VARIABLE, Size 0, Name: /usr1/example1_10.d2

Area Name: Order, Type6, BlockSize 1024, Extents 2, Records/Block 32, Cluster
Size 64
     Ext # 1, Type FIXED , Size 1280, Name: /usr1/example1_11.d1
     Ext # 2, Type VARIABLE, Size 0, Name: /usr1/example1_11.d2

Area Name: Misc, Type6, BlockSize 1024, Extents 2, Records/Block 32
     Ext # 1, Type FIXED , Size 320, Name: /usr1/example1_12.d1
     Ext # 2, Type VARIABLE, Size 0, Name: /usr1/example1_12.d2

Для добавления экстента к области базы данных необходимо:

1. Сформировать резервную копию базы.
2. Создать структурный файл с описание нового экстента:

# add.st
#
d "chris",128 .

3. запустить утилиту PROSTRCT с классификатором ADD и указанием нового структурного файла:

prostrct add service add.st

Formatting extents:
size area name path name
0 chris /user/joe/service_9.d3 00:00:01

4. Обновите текущий структурный файл базы данных утилитой PROSTRCT LIST:

prostrct list service service.st

Утилита OpenEdge Structure Add Online

Для добавления областей и экстентов в существующую базу данных в online используйте утилиту Structure Add Online (PROSTRCT ADDONLINE). Утилита позволяет администратору базу данных добавлять как новые области и экстенты, так и области before-image и after-image, не прибегая к останову базы данных.

PROSTRCT ADDONLINE имеет следующие ограничения:

Нельзя запускать более одной команды PROSTRCT ADDONLINE в один момент времени.
Все подключенные пользователи должны иметь достаточно привилегий чтобы получить доступ к вновь созданной области или экстенту. Если у пользователей нет соответствующих доступов, то они должны быть предварительно отключены.

PROSTRCT ADDONLINE работает в соответствии со следующей процедурой:

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

Usr   Name   Type   Pid
01     usr1      Usr     1234
102   usr2      Usr     5678
...
There exist connections to the database which will have
problems opening newly added extents.

These connections may abort adding extent online later.
Do you want to continue adding extents online? (y/n)

Ответьте Yes для продолжения или No для прекращения работы.

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

Usr     Name     Type     Pid
01      usr1        Usr       1234
102    usr2        Usr       5678
...
There exist connections to the database which will have
problems opening newly added extents.

Do you wish to recheck user permissions and continue adding extents
online?

Ответьте Y для перепроверки или N для завершения работы ADDONLINE.

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

4.    Блокирует область
5.    При добавлении экстента к существующей области, текущий экстент области конвертируется из переменной длины в фиксированную, закрепляя за ним текущий размер.
6.    добавляет новый экстент и его размер в область базы данных и Control Area.
7.    Разблокирует область.

При возникновении ошибки при работе ADDONLINE, вновь созданные файлы будут удалены.

При добавлении области хранения в существующую базу данных необходимо выполнить следующее:

1.    Создайте новый структурный файл содержащий информацию о новой области:

# FILE: add.st
#
# Add additional before-image extents
b . f 1024
b .
#
# Add additional extents to the “Employee” area
d "Employee":7,32;1 . f 4096
d "Employee":7,32;1 .
#
# Add after-image areas
a . f 512
a . f 512
a .

2. Проверьте ваш структурный файл

prostrct addonline service add.st -validate

С параметром –validate утилита проверит синтаксис содержимого структурного файла, без выполнения добавления.

3. Добавьте новую область и экстенты:

prostrct addonline service add.st

4. PROSTRCT ADDONLINE добавит новые области и экстенты, после чего выведет следующую и нформацию:

5. Обновите существующий структурный файл базы данных:

prostrct list service service.st

Нумерация областей

В OpenEdge база данных может иметь до 32 000 областей. Указывать номера областей не обязательно, а максимальное количество областей может регулироваться параметрами запуска.

Назначение номеров областям

Если при создании базы данных номера областей не были определены, то OpenEdge самостоятельно их пронумерует начиная с номера области 7. Следующий пример демонстрирует структурный файл без указания номеров областей:

#
b . f 1024
b .
#
d "Schema Area":6,32;1 .
#
#
d "First user data area",32;64 . f 4096
d "First user data area",32;64 .
#
d "Second user data area",32;64 . f 4096
d "Second user data area",32;64 .
#
d "Last user data area",32;64 . f 4096
d "Last user data area",32;64 .
#

PROSTRCT пронумерует области в порядке их расположения в структурном файле.

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

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

Следующий пример отображает структурный файл с тремя областями, которым были назначены номера 1000, 2000 и 3000:

#
b . f 1024
b .
#
d "Schema Area":6,32;1 .
#
#
d "First user data area":1000,32;64 . f 4096
d "First user data area":1000,32;64 .
#
d "Second user data area":2000,32;64 . f 4096
d "Second user data area":2000,32;64 .
#
d "Last user data area":3000,32;64 . f 4096
d "Last user data area":3000,32;64 .
#

PROSTRCT создаст области указанный в файле именно с той нумерацией, которая определена.

В этом случае массив областей будет выглядеть так:

Если уменьшение использования памяти является приоритетом, то можно ограничить используемую память для областей, отрезав нумерацию от 3001 до 32000, используя параметр запуска –maxAreas.

Триминиг неиспользуемой памяти областей

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

Если вы создаете структурный файл и указываете параметр –maxAreas 2000 результат размещения будет следующий:

#
b . f 1024
b .
#
d "Schema Area":6,32;64 .
#
#
d "First user data area":7,32;64 . f 4096
d "First user data area":7,32;64 .
#
.
.
.
#
d "Last user data area":2000,32;64 . f 4096
d "Last user data area":2000,32;64 .
#

Следующий рисунок демонстрирует размещение областей в массиве в этом случае:

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

Проверка структурного файла

Перед тем как производить изменение структуры базы данных с помощью утилиты PROSTRCT, необходимо проверить правильность структурного файла с помощью параметра –validate, который может использоваться с PROSTRCT CREATE, PROSTRCT ADD или PROSTRCT ADDONLINE. При использовании этого параметра, PROSTRCT проверяет структурный файл на правильность синтаксиса, правильность содержания для указанной операции, а также определяет наличие достаточного свободного пространства для создания новых экстентов. Любые возникшие ошибки будут выведены на экран. При этом, если ошибок не было обнаружено, изменения все равно не будут внесены в структуру.

Проверка структурного файла включает:

Проверяется каждая линия в файле, не зависимо, является ли она пустой, комментарием или описание экстента.
Проверяется, что каждая не пустая линия начинается с символа комментария (*,:,#) или с индикатора тип экстент (a,b,d,t).
Проверяется описание области каждого экстента, если начинается с имени области, то оно должно заключаться в кавычках (“ “).
Проверяется, что если для области определены: номер области, RPB, блок кластера, то они должны быть одинаковыми для всех экстентов определенных в области.
Проверяется наличие разделителей соответствующих следующим правилам:
      Двоеточие (:) – должно следовать за номером области.
      Запятая (,) – следует за RPB.
      Точка с запятой (;) – следует за количеством блоков в кластере.
Если размер кластера определен проверяется его значение, значение может быть только следующим: 0, 1, 8, 64, 512.
Проверяется наличие необходимого свободного пространства для каждого экстента.
Проверяется, что все каталоги, входящие в состав пути к экстенту, существуют.
Для PROSTRCT CREATE определяется наличие существующей базы.
Для PROSTRCT ADD и PROSTRCT ADDONLINE, нельзя добавлять экстенты в transaction log если two-phase commit активирован.

Утилита OpenEdge Structure Remove

Для удаления экстентов из областей хранения используется утилита Structure Remove (PROSTRCT REMOVE). После удаления всех экстентов из области, PROSTRCT REMOVE удаляет и саму область.

Для удаления экстента из области необходимо:

1. Если экстент принадлежит BI области, то необходимо сначала усечь BI область с помощью PROUTIL TRUNCATE BI:

proutil db-name -C truncate bi

Если область является прикладной, то необходимо использовать утилиту PROUTIL TRUNCATE AREA:

proutil db-name -C truncate bi

При удалении AI и TL экстентов предварительно необходимо отключить эти механизмы.

2. Для удаления экстента из области используйте PROSTRCT REMOVE:

prostrct remove db-name extent-type-token [area-name]

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

За один раз можно удалить только один экстент. После удаления последнего экстента из области, будет удалена и сама область. После удаления экстента выдается следующее сообщение:

solaris:100a$ prostrct remove service d chris
/user/joe/service_9.d3 successfully removed
solaris:100a$ prostrct remove service d chris
/user/joe/service_9.d2 successfully removed
solaris:100a$ prostrct remove service d chris
/user/joe/service_9.d1 successfully removed

3. Обновите структурный файл базы данных с помощью PROSTRCT LIST.

Поддержка индексов и таблиц

Добавлять таблицы и индексы в области хранения можно с помощью меню Data Dictionary -> Create Table / Create Index. Тем не менее, нельзя добавить таблицу в область с помощью Modify Table или Index property. Далее будет подробно описано как перемещать таблицы и индексы.

Перемещение таблиц

Для перемещения таблицы и всех связанных с ней индексов из одной области в другую на запущенной базе, используется утилита PROUTIL TABLEMOVE.

proutil db-name -C tablemove [owner-name.]table-name table-area [ index-area ]

Если параметр index-area будет опущен, то индексы связанные с таблицей не будут перемещены. Перемещение таблицы лишает все ее записи ROWID и индексации. Поэтому, индексы автоматически перестраиваются, не зависимо от того, перемещаете вы их или нет. Индексы также могут быть перемещены в отдельную от таблицы область хранения. Если необходимо переместить только индексы таблицы в отдельную область, используйте утилиту PROUTIL IDXMOVE.

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

Во время перемещения таблицы в online, доступ пользователей к ней будет закрыт. Утилита устанавливает на замок EXCLUSIVE LOCK на время перемещения. Приложения с указанием NO-LOCK могут прочитать данные, но обычно они будут получать неправильные результаты, поскольку во время перемещения происходит перестройка индексов. Поэтому выполнение перемещений лучше выполнять во время относительного простоя системы.

Утилита PROUTIL REMOVE работает в следующих фазах:

Фаза 1 – Записи перемещаются в новую область и строится новый уникальный индекс.
Фаза 2 – Строятся все оставшиеся индексы:
Если не указан параметр index-area, индексы перестраиваются в текущей области.
Если параметр index-area указан, то индексы перемещаются в новую область и перестраиваются.
Фаза 3 – Все записи в старой области удаляются.
Фаза 4 – Все старые индексы удаляются и обновляются записи в _StorageObject для индексов и таблицы.

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

Перемещение индексов

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

proutil db-name -C idxmove [owner-name.]indexname area-name

Утилита выполняется в двух фазах:

1. Фаза 1 – Новый индекс создается в новой области. Старый же индекс при этом остается в старой области, чтобы пользователи могли им пользоваться.
2. Фаза 2 – Старый индекс удаляется, а все используемые им блоки размещаются в свободной цепочке. Имейте ввиду, если индекс очень большой, эта процедура может занять значительное время. Во время работы этой фазы, все действия с индексом будут заблокированы, а пользователи работающие с ним будут испытывать зависание их приложений.

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

Использование виртуальных системных таблиц

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

IDXANALYS – отображает информацию по индексным блокам.
IDXCOMPACT – увеличения используемого пространства индексных блоков.
IDXFIX – обнаружение поврежденных индексов и записей.
IDXMOVE – перемещение индексов.
TABLEMOVE – перемещение таблиц.

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

Следующий код ABL демонстрирует, как можно контролировать перемещение индексов (PROUTIL IDXMOVE):

/* Monitor all "index move" processes every three seconds */
REPEAT:
   FOR EACH _UserStatus WHERE _UserStatus-Operation = "Index move":
       DISPLAY _UserStatus.
   END.
   PAUSE 3.
END.

То же самое можно выполнить с помощью SQL – запроса:

SELECT * FROM _UserStatus WHERE _UserStatus-Operation = "Index move";

Загрузка и выгрузка данных

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

Краткий обзор D&L (dump & load)

Необходимость D&L может понадобится в следующих случаях:

Создание новой версии базы данных.
Использование константной таблицы в нескольких базах.
С целью оптимального использования дискового пространства.
Конвертация базы данных в новую версию OpenEdge и для другой платформы операционной системы.
Загрузка измененных определений данных для модернизации схемы базы данных.

Перед тем как выгрузить данные, необходимо сначала выгрузить описание базы данных и таблиц, и только потом содержимое таблиц. Определения и содержание должны располагаться в различных файлах, и не могут быть выгружены за один раз. Выполнить эти процедуры можно используя Data Administration tool, если используется графический интерфейс, или Data Dictionary – для символьного интерфейса.

Так же перезагрузку можно выполнить с помощью утилиты PROUTIL. Он позволяет выполнять dump и load в двоичном (binary) формате.

Ограничения D&L

Существует три ограничения по использованию Dump и Load из OpenEdge Tools:

Перезагрузка данных из одной базы в другую, предполагает наличие в загружаемой базе одинаковой структуры с базой первоначальной. Т.е. схема базы должна быть полностью идентичная. В противном случае, необходимо написать свою собственную процедуру загрузки с использованием синтаксиса ABL, операторов INPUT FROM, CREATE и IMPORT.
Если в таблицах базы данных используются поля типа ROWID или RECID, значение ROWID будет выгружено как не определенное (?). Поэтому, для обеспечения выгрузки и загрузки таких таблиц необходимо так же писать собственную процедуру.
Если у вас нет привилегий Can-Create и Can-Write, вы всё равно можете выгружать данные и их определения. Вы также можете загружать определения таблиц в базу данных, но вы не сможете загрузить в них данные.

Выгрузка определения данных

Для выгрузки определения данных, используется Data Dictionary или Data Administration. Существует два способа выгрузки:

Выгрузить все описания базы данных, таблиц и полей
и выгружать отдельно каждую таблицу, секвенцию или записи авто-коннекта.

При выполнении выгрузки с помощью Data Dictionary или Data Administration, всегда создается файл с расширением - df. Этот файл содержит описания: таблиц, полей, индексов, секвенций, записей авто-коннектов, а так же все их характеристики. Но в зависимости от выбора типа выгрузки, т.е. выгружаете ли вы все данные, или данные конкретной таблицы, не все определения могут быть записаны в df – файл. Следующая таблица отображает, какие определения выгружаются в конкретных случаях:

Определения	Все таблицы	Выбранные таблицы
Таблицы, поля и индексы	Да	Да
Секвенции	Да	Нет
Авто-коннекты	Да	Нет
Collation	Нет	Нет
_User	Нет	Нет

Если вы выгружаете конкретные таблицы, то секвенции и авто-коннекты должны быть выгружены отдельно.

Для выгрузки определений базы данных или таблиц необходимо:

1.    Зайти в Data Dictionary.
2.    Обязательно убедиться, что вы находитесь именно в той базе данных, которую хотите выгрузить.
3.    Выбирете Admin -> Dump Data and Definitions -> Data Definitions (.df file). Отобразится список всех имеющихся таблиц в алфавитном порядке.
4.    Выберите таблицу которую вы хотите выгрузить или выберите All для выгрузки всех таблиц.

Если вы выберите All, то df-файл будет так же содержать секвенции и записи авто-коннектов, collation/conversion таблицы включены не будут. Имя файла, по умолчанию, будет предложено состоящее либо из имени выгружаемой таблицы, либо из имени базы данных, если производится полная выгрузка. При этом, если имя состоит более чем из 8 символов, оно будет урезано.

5.    Нажмите OK если вы сделали выбор таблицы и имени. Во время выгрузки на экране будет отображаться каждое выгружаемое в текущий момент объектное имя. По завершению выгрузки, будет выдано сообщение о статусе выгрузки и предложен запрос на продолжение.
6.    Выберите OK для возврата в основное меню.

Формат DF – файла

DF – файл всегда создается при выгрузки определений данных через Data Dictionary или Data Administration. Это файл используется для загрузки определений данных в базу данных. Следующий пример показывает файл определения для одной таблицы:

Если вы изменяете df – файл, то имейте ввиду, что таблицы, поля и индексы могут быть перемешаны, но только в пределах одной секции CREATE DATABASE. Тем не менее, не забывайте придерживаться следующего:

Определяйте таблицу перед полем содержащимся в ней.
Определяйте поле перед индексом его использующим.
Все определения должны принадлежать наиболее последнему ADD DATABASE или CREATE DATABASE в df – файле/

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

Поле	Описание
codepage=codepage	Это кодовая страница используемая базой данных.
Character count	Количество символов, содержащихся в файле. Это число всегда состоит из 10 цифр с ведущими нулями, если это необходимо.

Создание инкрементального DF – файла

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

Если тип данных в поле был изменен, то в df-файл будет записано утверждение DROP для удаления этого поля, после чего – утверждение ADD, для создания поля с новыми параметрами. При этом, когда поле будет удаляться, все данные, которые оно содержало, будут удалены. Для того чтобы сохранить эти данные, можно либо предварительно их выгрузить, а потом загрузить в измененное поле, либо новое поле назвать по другому, написать программу переноса на ABL, перенести данные из старого поле в новое, после чего можно использовать инкрементальный df-файл.

Для создания инкрементального df – файл выполните:

1.    Зайдите в Data Administration или Data Dictionary.
2.    Выберите исходную (source) базу данных в качестве текущей. Исходная база данных – это база, схема которой должна попасть в df-файл.
3.    Выберите Admin -> Dump Data and Definitions -> Create Incremental .df File. Будет отображен список подключенных баз данных.
4.    Если имеется более двух подключенных баз данных, выберите соответствующую целевую (target) базу. Целевая база – база схема которой должна быть изменена. Так же будет запрошено имя df-файла.
5.    Укажите желаемое имя df-файла. По умолчанию будет предложено имя delta.df. После чего начнется сравнение и выгрузка, при этом на экране будут отображаться все сравниваемые таблицы, поля, индексы и секвенции.
6.    По завершению сверки и формирования файла, вы вернетесь в основное меню.

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

Выгрузка описаний секвенций

Выгрузить определения секвенций и их значения можно любым инструментальным средством. Определения секвенций хранятся в отдельном df – файле, с определенным вами именем, а их значения сохраняются в файл _seqvals.d. Выгрузка определений секвенций и их значений может осуществляться раздельно.

Чтобы выполнить выгрузку необходимо:

1.    Зайдите в Data Administration или Data Dictionary.
2.    Убедиться, что текущая база именно та, секвенции которой вы хотите выгрузить.
3.    Выберите Admin-> Dump Data and Definitions-> Sequence Definitions. Будет запрошено желаемое имя файла для выгрузки определения секвенций. По умолчанию - _seqdefs.df.
4.    Укажите необходимое имя df-файла или оставьте значение по умолчанию. По завершению выгрузки на экране отобразится ее статус.
5.    Выберите OK для завершения. После чего вы выйдете в основное меню.

Выгрузка записей авто-коннектов

Выгрузка авто-коннектов аналогична выгрузки таблиц и секвенций:

1.    Зайдите в Data Administration или Data Dictionary.
2.    Выберите Admin-> Dump Data and Definitions-> Auto-connect Records Only. Будет запрошено желаемое имя файла для выгрузки записей авто-коннектов. По умолчанию - _auto.df.
3.    Укажите необходимое имя df-файла или оставьте значение по умолчанию. По завершению выгрузки на экране отобразится ее статус.
4.    Выберите OK для завершения. После чего вы выйдете в основное меню.

Выгрузка содержимого базы данных

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

Содержимое таблиц.
Значения секвенций.
Содержимое таблицы User
Содержимое SQL View File

OpenEdge RDBMS поддерживает два метода выгрузки содержимого базы данных: двоичная выгрузка с помощью PROUTIL или текстовая выгрузка с помощью Data Administration или Data Dictionary. При этом двоичная выгрузка с помощью PROUTIL выполняется во много раз быстрее.

Выгрузка содержимого таблиц с помощью PROUTIL

PROUTIL DUMP позволяет выполнять двоичную выгрузку данных из базы данных, находящейся как в online, так и в offline. Выгрузка в online может быть многопоточной, тем не менее, многопоточность доступна только при наличии лицензии Enterprise. При выгрузке используется индекс, если индекс не был специально оговорен, то, по умолчанию, используется первичный индекс (primary index). Индекс указывается его номером. Можно использовать PROUTIL IDXANALYS, для определения этого номера.

Используйте следующий синтаксис для выполнения offline или однопоточной online двоичной выгрузки:

proutil db-name -C dump [owner-name.]table-name directory [-index num]

Здесь,
db-name, определяет базу данных из которой будет происходить выгрузка;
owner-name, определяет владельца выгружаемой таблицы;
table-name, определяет имя таблицы, содержащей выгружаемые данные;
directory, определяет имя целевого каталога, в которые данные будут выгружены;
-index num, определяет индекс, используемый при выгрузке.

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

{[-thread n ] [-threadnum nthreads] [-dumplist dumpfile] }

Где,
-thread 0, индикатор однопоточной выгрузки, а –thread 1, индикатор многопоточной;
-threadnum nthreads, определяет максимальное количество создаваемых потоков;
-dumplist dumpfile, создает список сгенерированных файлов выгрузки.

Количество создаваемых потоков контролируется параметром –threadnum. Если же этот параметр не указан, количество потоков указывается равным количеству CPU. При этом, фактическое количество созданных потоков может быть меньше максимального. PROUTIL DUMP определяет оптимальное количество потоков на основе сложности указанного индекса.

Результаты двоичной выгрузки

Во время двоичной выгрузки данные из таблиц записываются в файлы. Имена этих файлов определяются в соответствии с именами выгружаемых таблиц. Если владельцем выгружаемых таблиц является PUB, то имя файла формирует из имени таблицы с расширением .bd. Например, tablename.db. Но если владелец отличается, то имя файла будет формироваться из имени владельца и имени таблицы, например, ownername_tablename.bd.

В системах с 2GB ограничением размеров файлов, однопоточный PROUTIL DUMP создает множество файлов для выгружаемой таблицы превышающей размер 2GB. Например, если выгружаются данные из таблицы с именем customer, размер которой 6.4 GB, PROUTIL DUMP создаст следующий двоичные файлы: customer.db, customer.bd2 и customer.bd3. Каждый файл приблизительно по 2GB, а последний – customer.bd4 будет размеров в 0.4 GB. PROUITL DUMP в каждый двоичный файл добавляет определенный заголовок. Поэтому, в результате, общий размер всех двоичных файлов немного больше чем размер выгружаемых данных.

В системах, в которых отсутствует ограничение на размер файла, однопоточный PROUTIL DUMP создает только один двоичный файл не зависимо от размера таблицы.

Многопоточный PROUTIL DUMP создает файл для каждого потока. Первый поток создаст файл tablename.bd; второй, tablename.bd2; все последующие потоки будут создавать файлы увеличивая их номера – tablename.bdn. Используйте параметр –dumpfile для генерации списка файлов созданных потоками. Это файл содержит список всех созданных потоками двоичных файлов, и может использоваться при загрузке с помощью PROUTIL LOAD. При этом, помните, если файл указанный параметром –dumpfile, существует, он будет перезаписан.

Формат выгруженного двоичного файла

Каждый двоичный файл содержит заголовок и описание каждой записи в таблице. Формат двоичного файла следующий:

Header

Record length

Table number

Binary record

Record CRC

Заголовок файла состоит из:

1.    Номер версии.
2.    Дата и время создания файла.
3.    Имя выгруженной таблицы.
4.    Номер выгруженной таблицы.
5.    CRC выгруженной таблицы.
6.    Количество полей в таблице.
7.    Имя базы данных, в которой расположена таблица.
8.    Номер части.
9.    Номер первой записи.
10.    Владелец таблицы.

Номер части, соответствует номеру двоичного файла выгружено многопоточным PROUTIL DUMP или однопоточным PROUTIL DUMP на системе с ограниченным размером файла. Например, Часть 1 соответствует файлу customer.bd, Часть 2 – customer.bd2 и т.д.

Для поддержки перезагрузки BLOB и CLOB полей, PROUTIL DUMP расширяет заголовок двоичного файла.

Выборочная выгрузка содержимого с помощью PROUTIL

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

proutil db-name -C dumpspecified
[owner-name.]table-name.field-name operator field-value directory

Где,
db-name, определяет базу данных;
owner-name, владельца таблицы;
table-name, имя выгружаемой таблицы;
field-name, имя выгружаемого поля;
operator, оператор сравнения для условия выборки;
field-value, определяет значение, по которому будет происходить выборка;
directory, определяет имя целевой директории, в которую будут выгружены файлы.

Operator может принимать одно из пяти значений:

EQ – Равно.
GT – Больше.
GE – Больше или равно.
LT – Меньше.
LE – Меньше или равно.

Следующий пример производит выборочную выгрузку всех данных с датой больше 02/03/02 из базы Sports2000:

proutil sports2000 -C dumpspecified order.order_date GT ’02-03-2002’

Следующий пример, выполняет выгрузку записей, полей цены которых меньше $25.90:

proutil sports2000 -C dumpspecified item.price LT 25.9

Выгрузка инструментальными средствами

Когда вы используете Data Administration или Data Dictionary для выгрузки содержимого базы данных, создается текстовый файл для каждой таблицы, который в последствии, используется для загрузки. Этот файл имеет расширение .d.

Чтобы выполнить выгрузку необходимо:

1.    Получить доступ в соответствующее инструментальное средство.
2.    Убедиться, что используется именно та базы, которая нужна.
3.    Выберите, Admin -> Dump Data and Definitions -> Table Contents (.d files). Появится список всех таблиц в алфавитном порядке.
4.    Пометьте таблицы для выгрузки. Вы можете использовать символ (*), выбрав Select Some или Deselect Some, для выбора групп таблиц. В символьном режиме можно использовать клавиши F5 и F6. Если вы выгружаете одну таблицу, то по умолчанию будет предложено имя, состоящее из имени таблицы и расширения .d. Если вы хотите определить иное имя, то введите его в поле Output file. Если выгружается множество таблиц, то будет запрошено имя каталога в который будет произведена выгрузка. Если каталог не будет определен, то выгрузка будет выполнена в текущий каталог. Создаваемые файлы так же будут иметь имена соответствующие выгружаемой таблице.
5.    Если база данных содержит LOB поля, установите флаг Include LOB в Yes.
6.    Если Include LOB равен Yes, укажите каталог для размещения LOB поля в LOB Directory.
7.    Если вы хотите использовать кодовую страницу, то установите ее и выберите OK. После этого начнется выгрузка, при этом на экране будет отображаться имя выгружаемой в текущий момент таблицы. По завершению, будет выведен статус выгрузки и предложение о продолжении работы.
8.    Выбрав OK вы вернетесь в основное меню.

Формат содержимого DF - файла

Ниже представлен пример содержимого файла.

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

Если база данных использует значения по умолчанию, то они не отображаются в файле. Следующая таблица объясняет эти переменные:

Поле	Описание
filename=table-name	Имя таблицы
records=num-records¹	Количество записей, содержащихся в файле
ldbname=logical-db-name	Логическое имя исходной базы данных
time stamp=time stamp	Временная метка базы данных
num format=¹ thousands-separator, fractional-separator	Символ числового значения, который разделяет тысячный разделитель и дробный разделитель, определенный в кодовой странице. Когда вы пытаетесь загрузить файл, то сессия и файл должны иметь одинаковые числовой формат. В противном случае, OpenEdge выдаст сообщение об ошибке в процессе выполнения загрузки.
dateformat=date-format¹	Формат даты используемый в содержании файла
map={MAP protermcap-entry \| NO-MAP}¹	Карта символов поддерживаемая опцией MAP в выражении INPUT FROM и OUTPUT TO. Вы можете определить карту между стандартами ASCII (7-bit) и (8-bit) из PROTERMCAP. PROTERMCAP используется для определения таблиц перекодировок. MAP определяет вход в PROTERMCAP для нахождения таблицы. Если установлено NO-MAP, символьное преобразование не будет использовано.
codepage=codepage	Кодовая страница, используемая базой данных
Character count	Количество символов, содержащееся в файле. Это число всегда состоит из 10 цифр с ведущими нулями, если это необходимо.

¹Информация используется при загрузке файла. Если эти значения будут определены не правильно, загрузка не будет выполнена.

Выгрузка значений секвенций инструментальными средствами

Выгрузка значений секвенций происходит так же как и выгрузка содержимого таблиц.

Для этого необходимо:

1.    Получить доступ в соответствующее инструментальное средство.
2.    Убедиться, что используется именно та базы, которая нужна.
3.    Введите Admin -> Dump Data and Definitions -> Sequence Values. Будет запрошено имя файла для выгрузки значений. По умолчанию указывается - _seqvals.d.
4.    Укажите необходимое имя файла или оставьте значение по умолчанию. По завершению выгрузки на экране отобразится ее статус.
5.    Выберите OK для завершения. После чего вы выйдете в основное меню.

Выгрузка таблицы _user инструментальными средствами

Выгрузка пользовательской информации происходит также как и выгрузка содержимого таблиц и значений секвенций.

Для этого необходимо:

1.    Получить доступ в соответствующее инструментальное средство.
2.    Убедиться, что используется именно та базы, которая нужна.
3.    Введите Admin -> Dump Data and Definitions -> User Table Contents. Будет запрошено имя файла для выгрузки значений. По умолчанию указывается - _user.d.
4.    Укажите необходимое имя файла или оставьте значение по умолчанию. По завершению выгрузки на экране отобразится ее статус.
5.    Выберите OK для завершения. После чего вы выйдете в основное меню.

Выгрузка SQL View

Выгрузка пользовательской информации происходит также как и выгрузка содержимого таблиц и значений секвенций.

Для этого необходимо:

1.    Получить доступ в соответствующее инструментальное средство.
2.    Убедиться, что используется именно та базы, которая нужна.
3.    Введите Admin -> Dump Data and Definitions -> Views. Будет запрошено имя файла для выгрузки значений. По умолчанию указывается - _view.d.
4.    Укажите необходимое имя файла или оставьте значение по умолчанию. По завершению выгрузки на экране отобразится ее статус.
5.    Выберите OK для завершения. После чего вы выйдете в основное меню.

Загрузка определения базы данных

Загрузить в базу можно либо все определения таблиц, либо только те в которых произошли изменения. Для загрузки определений используется df- файл, который содержит определения таблиц, полей и индексов.

Для загрузки df – файла в базу данных необходимо:

1.    Получить доступ в соответствующее инструментальное средство.
2.    Убедиться, что используется именно та базы, которая нужна.
3.    Введите Admin -> Load Data and Definitions -> Data Definitions (.df files). Будет запрошено имя файла для pзагрузки определения. По умолчанию указывается имя файла состоящее из имени текущей базы данных и расширения .df.
4.    Укажите файл и продолжите выполнение.
5.    Укажите, необходимо ли остановить загрузку в случае возникновения ошибки. Во время загрузки на экране отображается каждый загружаемый объект. В случае возникновения ошибки, будет выдано сообщений и запрошена необходимость продолжения работы. Не зависимо от того, что вы выберите, загрузка ошибочных определений будет все равно отменено.
6.    Выберите OK для завершения. После чего вы выйдете в основное меню.

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

Загрузка изменений определений данных

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

Для этого необходимо:

1.    Создайте копию базы данных, которую вы хотите изменить.
2.    Подключитесь к базе данных, содержащей изменения.
3.    Получить доступ в соответствующее инструментальное средство.
4.    Выберите Database -> Connect Database. Появится диалоговое окно Database Connect.
5.    Введите имя подключаемой базы данных и выберите OK. Произойдет подключение к базе, после чего вы выйдете в основное меню.
6.    Выберите Admin -> Dump Data and Definitions -> Create Incremental .df File. Появится диалоговое окно Create Incremental .df File. Создайте инкрементальный df-файл.
7.    Подключитесь к копии старой базы данных.
8.    Загрузите инкрементальный df-файл выбрав Admin -> Load Data and Definitions -> Data Definitions (.df files)
9.    Если загружаемые индексы были деактивированы, активируйте их используя PROUTIL IDXBUILD.
10.    Старая схема теперь соответствует новой, поэтому перекомпилируйте все r-code файлы и проверьте работу приложений.

Загрузка содержимого базы данных

Эта часть описывает способы загрузки следующих типов содержимого базы данных:

Содержимое таблиц
Содержимое таблицы _User
Содержимое SQL View
Значения секвенций

OpenEdge RDBMS поддерживает три метода загрузки содержимого таблиц. Вы можете загрузить двоичные данные командой PROUTIL LOAD. Текстовые данные могут быть загружены инструментальными средствами или командой PROUTIL BULKLOAD. Двоичную загрузку можно выполнить, только из файлов созданных двоичной выгрузкой.

Загрузка содержимого таблиц в двоичном формате

Для двоичной загрузки используется следующий синтаксис:

proutil db-name -C load [ filename | -dumplist dumpfile ]

Здесь,
db-name, определяет имя базы данных, в которую загружаются данные;
filename, используется для загрузки одного файла;
-dumplist dumpfile, используется для загрузки множества файлов, где dumpfile это список содержащий имена двоичных файлов;

Во время загрузки вы можете сразу строить индексы использовав параметр build indexes.

При загрузке многочисленных файлов, вы можете использовать файл созданный многопоточной двоичной выгрузкой, или же созданный вами вручную. Этот файл содержит список полных имен двоичных файлов. Пример такого файла (order.dmp_lst) приведен ниже:

/usr1/docsample/101A/bindump/order.bd
/usr1/docsample/101A/bindump/order.bd2
/usr1/docsample/101A/bindump/order.bd3
/usr1/docsample/101A/bindump/order.bd4
/usr1/docsample/101A/bindump/order.bd5
/usr1/docsample/101A/bindump/order.bd6

Для загрузки файлов из списка используйте следующую команду:

proutil newdb -C load -dumplist order.dmp_lst

Использование параметра –dumplist, аналогично следующим 6 отдельным командам:

proutil newdb -C load /usr1/docsample/101A/bindump/order.bd
proutil newdb -C load /usr1/docsample/101A/bindump/order.bd2
proutil newdb -C load /usr1/docsample/101A/bindump/order.bd3
proutil newdb -C load /usr1/docsample/101A/bindump/order.bd4
proutil newdb -C load /usr1/docsample/101A/bindump/order.bd5
proutil newdb -C load /usr1/docsample/101A/bindump/order.bd6

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

Восстановление после прерывания двоичной загрузки

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

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

1. Усечь область хранения.
2. Перезапустить операцию загрузки.

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

Binary load session started.
Record load phase started.
Record load phase completed.
Starting index build phase.
Index build phase completed.
Binary load session ended.

Загрузка содержимого таблиц инструментальными средствами

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

Для загрузки содержимого таблиц в базу данных необходимо:

1.    Получить доступ в соответствующее инструментальное средство. (Data Administration или Data Dictionary).
2.    Убедитесь, что текущая база данных является той базой, в которую вы хотите загрузить данные.
3.    Выберите Admin -> Load Data and Definitions -> Table Contents (.d files). Отобразится список таблиц в алфавитном порядке для текущей базы данных.
4.    Выберите таблицу которую вы хотите загрузить, выбрав Select Some или Deselect Some, для выбора групп таблиц. В символьном режиме можно использовать клавиши F5 и F6. После чего будет запрошен файл с содержимым таблицы.
5.    Определите имя каталога, имя файла или оставьте значение по умолчанию.

Если вы загружаете содержимое всей базы данных, введите каталог, в котором расположены файлы для загрузки. Если каталог не будет указан, по умолчанию будет использоваться текущий каталог. Каждая таблица загружается из соответствующего файла с именем table-dumpname.d. Если вы загружаете одну таблицу, по умолчанию будет предложено имя файла соответствующее имени таблицы.
6.    Укажите Include LOB, если вы загружаете LOB поля.
7.    Если LOB поля загружаются, в поле Lob Directory укажите каталог в котором расположено их содержимое. Если он не будет указан, используется текущий каталог.
8.    Определите допустимый показатель ошибок.

Во время загрузки, может случиться ситуация, когда данные не могут быть загружены. Например, загружаемая запись может содержать слишком длинной значение в поле, чем определенный для него формат. Загрузка такой записи будет не возможна. Если вы укажите показатель ошибок 10 %, то из 100 записей будет загружено в случае возникновения ошибок - 90.

9.    Установите Output Errors to Screen, если вы хотите видеть ошибки на экране, как только они возникают.
10.    Выберите OK для возврата в основное окно.

Загрузка пользовательской информации

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

Для этого выполните следующее:

1.    Получить доступ в соответствующее инструментальное средство. (Data Administration или Data Dictionary).
2.    Выберите Admin -> Load Data and Definitions -> User Table Contents. Будет запрошено имя файла, содержащего загружаемую информацию, по умолчанию это _user.d.
3.    Укажите необходимое имя или оставьте значение по умолчанию. После загрузки, будет выведен статус и запрошено продолжение процесса.
4.    Выберите OK для возврата в основное меню

Загрузка SQL View

Загрузка SQL View аналогично загрузки содержимого таблиц и пользовательской информации.

Для этого выполните следующее:

1.    Получить доступ в соответствующее инструментальное средство. (Data Administration или Data Dictionary).
2.    Выберите Admin -> Load Data and Definitions -> SQL View. Будет запрошено имя файла, содержащего загружаемую информацию, по умолчанию это _view.d.
3.    Укажите необходимое имя или оставьте значение по умолчанию. После загрузки, будет выведен статус и запрошено продолжение процесса.
4.    Выберите OK для возврата в основное меню

Загрузка значений секвенций

Загрузка значений секвенций происходит так же с помощью либо Data Administration, либо с помощью Data Dictionary. Имя загружаемого файла обычно - _seqvals.d.

Для осуществления загрузки выполните:

1.    Получить доступ в соответствующее инструментальное средство. (Data Administration или Data Dictionary).
2.    Выберите Admin -> Load Data and Definitions -> Sequence Current Values. Будет запрошено имя файла, содержащего загружаемую информацию, по умолчанию это _seqvals.d.
3.    Укажите необходимое имя или оставьте значение по умолчанию. После загрузки, будет выведен статус и запрошено продолжение процесса.
4.    Выберите OK для возврата в основное меню

Bulk loading

Утилита Bulk Loader осуществляет загрузку текстовых данных намного быстрее обычной утилиты загрузки поддерживаемой инструментальными средствами Data Dictionary или Data Administration.

Bulk Loader работает только с базами данных OpenEdge. Другие производители баз данных так же предлагают подобные утилиты. Если используете не OpenEdge базы данных и при этом утилита Bulk Loader для них отсутствует, вы можете воспользоваться стандартной загрузкой из Data Administration или Data Dictionary.

Создание файла описания для Bulk Loader

Перед началом работы утилиты Bulk Loader вам необходимо создать файл описания (description file). Для этого необходимо воспользоваться Data Administration или Data Dictionary. По умолчанию, имя созданного файла будет table-dumpname.df. Если будет выбрано более одной таблицы, то имя файла будет состоять из имени базы данных с расширением .fd. вся информация, необходимая утилите будет находиться в этом файле.

Для того чтобы создать файл описания необходимо:

1.    Получить доступ в соответствующее инструментальное средство. (Data Administration или Data Dictionary).
2.    Выберите Admin -> Create Bulk Loader Description File. Будет отображен список таблиц в алфавитном порядке.
3.    Выберите таблицы для которых вы хотите создать файл описания. Используйте кнопки Select Some и Deselect Some. После чего будет запрошено имя файла, по умолчанию, предлагается table-dumpname.fd.
4.    Выберите имя и продолжите работу.
5.    Для продолжения формирования файла описания нажмите OK. После его создания будет отображен статус и вопрос о продолжении.
6.    Выберите OK для возврата в основное меню.

Следующий рисунок отображает части созданного файла описания:

В этом примере, customer это имя таблицы базы данных, customer.d – имя файла с данными, customer.e – имя файла содержащего возникшие ошибки при работе Bulk Loader, далее перечислены поля таблицы customer.

Корректировка файла описания

Для изменения файла описания для Bulk Loader можно использовать любой текстовый редактор. Возможные действия с файлом указаны в следующей таблице:

Задача	Действие
Добавление комментариев в fd – файл	В начале каждой строки комментария вставляется знак решетки (#)
Добавление описания нескольких таблиц в один файл	Таблицы разделяются точкой на отдельной строке
Пропустить поле	Исключенные поля заменяются знаком (^)

По умолчанию, Bulk Loader добавляет расширения .d и .e к имени таблицы при формировании двух файлов, необходимых для работы. По умолчанию, имена обоих файлов (файл данных и файл ошибок) могут начинаться с имени таблицы. Вы можете заменить названия файла на вам необходимые.

Например, если вы выгружаете таблицу customer в файл cust.d вместо customer.d, вы должны изменить название файла в файле описания. Ниже приведен пример измененного файла описания:

#This is an example
customer cust.d cust.e
      Cust-num
      Name
      ^
      ^
      City
      St
      ^
      Phone
.
item
      Item-num
      Idesc
.
order
      Order-num
      ^
      Name

Загрузка содержимого таблицы с помощью Bulk Loader

Для загрузки содержимого таблицы используется утилита PROUTIL с классификатором BULKLOAD. Используя файлы описания (.fd) и содержания (.d), Bulk Loader осуществляет загрузку большого количества данных быстрее чем стандартные инструментальные средства Data Dictionary или Data Administration.

Bulk Loader игнорирует любые утверждения CREATE TRIGGER и деактивирует все индексы с которыми он сталкивается.

Для загрузки содержимого таблицы с помощью Bulk Loader необходимо:

1.    Создайте файл описания (.fd) с помощью Data Administration или Data Dictionary, или вручную.
2.    Убедитесь что описания таблиц соответствуют базе данных.
3.    Запустите утилиту Bulk Loader:

proutil db-name [ -yy n ] -C bulkload fd-file [ -B n ]

Здесь,
db-name, определяет базу данных для использования;
-yy n, указывает начало 100 летнего периода, в котором любое значение DATE определено двумя цифрами;
fd-file, указывает на файл описания;
-B n, определеяет количество блоков в буферном пуле/

В относительно не больших системах, при использовании Bulk Loader мы можете столкнуться с нехваткой памяти. В качестве решения этой проблемы, можно разбить файл описания на несколько более мелких файлов.

Bulk Loader перед началом работы определяет, какой файл с содержимым необходимо использовать для конкретной таблицы. При этом, порядок полей в файле описания (.fd), обязательно должен соответствовать порядку полей в файле с содержанием (.d). В противном случае, как минимум, вы получите не правильные данные в таблице.

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

Восстановление некорректно загруженных записей

Если во время работы Database Administration или Data Dictionary возникли ошибки – создается файл ошибок. Вы можете использовав файл ошибок и оригинальный загружаемый файл, для того чтобы сформировать новый файл, содержащий все некорректные записи.

Для создания такого файла необходимо:

1.    Получить доступ в соответствующее инструментальное средство. (Data Administration или Data Dictionary).
2.    Выбрать Admin -> Load Data and Definitions -> Reconstruct Bad Load Records. Откроется диалоговое окно Reconstruct Bad Load Records.
3.    Укажите имена оригинального загруженного файла, файла ошибок, имя нового файла и нажмите OK. По умолчанию, имя создаваемого файла будет error.d. После его создания, будет отображен статус выполнения.
4.    Выберите OK для возврата в основное меню.
5.    Воспользуйтесь текстовым редактором для редактирования созданного файла, с целью исправления некорректных записей. После чего, вы можете загрузить из снова.

Специальные методы перезагрузки данных

Далее будут пошагово описаны специализированные процессы перезагрузки данных.

Создание исходной версии базы данных

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

Для создания новой базы данных содержащей определения другой базы, используйте функцию Dump инструментальных средств, для выгрузки файла определение, а с помощью утилиты PRODB создайте пустую базу данных, после чего загрузите файл определений в созданную базу:

1.    Подключитесь к базе данных, которую вы хотите копировать.
2.    Выгрузите определения базы данных в файл определений.
3.    Создайте копию empty базы данных.
4.    Подключитесь к вновь созданной базе.
5.    Загрузите файл с определением данных.

Использование постоянной таблицы в нескольких базах

Вы можете, используя D&L, копировать существующую таблицу из одной базы в несколько. Например, вместо создания процедуры по вводу данных таблицы в новую базу данных, вы можете выгрузить содержимое таблицы и загрузить его в другую базу данных.

Для этого:

1.    Подключитесь к базе данных, которую вы хотите копировать.
2.    Выгрузите содержимое таблицы.
3.    Переключитесь с текущей базы на целевую.
4.    Загрузите файл с содержимым таблицы.

Оптимизация дискового пространства

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

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

Для оптимального использования дискового пространства необходимо:

1.    Подключитесь к базе данных, которую вы хотите перезагрузить.
2.    Выгрузите определения базы данных в df- файл.
3.    Выгрузите содержимое таблиц базы данных.
4.    Выгрузите значения секвенций.
5.    Создайте новую базу данных.
6.    Подключитесь к новой базе данных в качестве текущей.
7.    Загрузите df – файл в новую базу.
8.    Загрузите содержимое таблиц, любым известным вам способом.
9.    Загрузите секвенции.
10.    Удалите старую базу данных с помощью PRODEL.

Оптимизация данных для последовательного доступа

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

Для осуществления подобной загрузки необходимо:

1.    Используя утилиту PROUTIL IDXANALYS, определить средний размер записей для каждой таблицы базы данных.
2.    Выгрузить определения и содержимое таблиц.

При этом, Data Administration и Data Dictionary при выгрузке использует первичный ключ. Если доступ к записям осуществляется по другому индексу, то при выгрузке необходимо использовать именно его. Для этого можно воспользоваться следующей ABL процедурой для выгрузки по конкретному индексу:

OUTPUT TO table-name.D.
FOR EACH table-name BY index
EXPORT table-name.
END

Эта процедура выгрузит данные в соответствии с используемым индексом.

3.    Загрузите данные порциями по приблизительно 1000 байт, по порядке среднего размера записей. Используйте Data Administration или Data Dictionary для загрузки одной таблицы за раз, или воспользуйтесь утилитой Bulk Loader и файлом описания (.fd) для контроля порядка.
4.    Загрузите остальные, более большие таблицы в порядке среднего размера записей.

Оптимизация данных для случайного доступа

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

Эта техника также улучшает производительность загрузки относительно SMP платформ.

Для осуществления подобной загрузки необходимо:

1.    Выгрузите данные и определения таблиц.
2.    Загрузите определения в новую базу.
3.    В многопользовательском режиме запустите Before-Image Writer (BIW) и Asynchronous Page Writer (APW).
4.    Откройте сессии в соответствии количеством процессоров в вашей системе. Каждая сессия будет загружать свою таблицу. Для каждой сессии напишите следующую ABL процедуру:

/*Run this procedure after connecting to a database*/
DEFINE VAR RECCOUNT AS INT NO-UNDO.
DEFINE VAR NXT-STOP AS INT NO-UNDO.
DEFINE VAR i as INT NO-UNDO.
INPUT FROM tablename.d
TOP:
REPEAT TRANSACTION:
       NXT-STOP=RECCOUNT + 100
       REPEAT FOR table-name WHILE RECCOUNT < NXT-STOP
       ON ERROR UNDO, NEXT ON ENDKEY UNDO, LEAVE TOP:
               CREATE table-name.
               IMPORT table-name.
               RECCOUNT = RECCOUNT + 1.
       END.
END.

Одновременная загрузка, распределит данные по нескольким дискам. Что устранит так называемые «горячие точки» (hot spots), т.е. области, в которых концентрируются данные).

5. После загрузки данных, выполните полную переиндексацию с помощью PROUTIL IDXBUILD.

Ускорения загрузки в режиме no-integrity

PROUTIL значительно быстрее будет выполнять изменение данных, если он запущен в режиме no-integrity, чем при запуске в полноценном режиме, поддерживающим восстановление. Но здесь есть недостаток, если во время загрузки произойдет сбой, восстановление базы может быть возможным только из резервной копии.

Для активирования режима no-integrity, используйте параметр No Crash Protection (-i). Параметр особенно полезен для пакетных выполнений, на подобие bulk loading.

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

Экономия дискового пространство деактивацией индексов

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

Существует два пути деактивации индексов:

Деактивация конкретного или всех индексов через Data Administration или Data Dictionary.
Деактивация с помощью ABL процедуры.

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

Для активации индекса используется утилита PROUTIL IDXBUILD.

Как только индекс деактивирован, вы не сможете использовать его для получения записей на который он ссылался. Если вы попытаетесь использовать деактивированный индекс в операторах FOR, FOR EACH или CAN-FIND, работа приложения будет прервана. Тем не менее вы можете создавать, удалять или изменять записи таблицы с деактивированным индексом.

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

Для деактивации конкретного индекса или всех индексов необходимо:

1.    Получить доступ к Data tool.
2.    Выбрать Utilities -> Deactivate Indexes. Откроется диалоговое окно Index Deactivation.
3.    Выберите OK. Отобразится список таблиц базы данных.
4.    Выберите необходимый индекс или все индексы для деактивации. Будет задан вопрос о действительной необходимости деактивации.
5.    Проверьте, что вы действительно выбрали необходимые индексы, и продолжите выполнение.

Так же выполнить деактивацию можно из ABL процедуры. Найдите в таблице _Index деактивируемый индекс, после чего установите значение поля _Active в NO. Пример подобной процедуры следующий:

FIND _Index WHERE _Index-Name = "cust-num".
IF (_Index._Active) THEN
       _Index._Active = NO.
ELSE
       IF NOT(_Index._Active) THEN
               MESSAGE "The specified index is Deactivated.".

Регистрируемые данные

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

Журнал событий (.lg) OpenEdge 10
Управление размером журнала
Сохранение ключевых событий базы данных

Журнал событий (.lg) OpenEdge 10

Журнал событий (.lg) в OpenEdge – это текстовый файл, содержащий историю существенных событий базы данных и настроек параметров запуска. Он включает, настройки параметров запуска, дату и время запуска и остановки базы данных, системные ошибки, а также сообщения утилит. Это файл имеет расширение .lg. Информация, содержащаяся в нем может быть использована для определения причин возникновения сбойных ситуаций.

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

[yy/mm/dd@hh:mm:ss.uuushhmm] P-nnnnnn T-nnnnnn S name nnn: (nnnnn) Message

Все поля строки, за исключением Message, имеют фиксированную ширину. Ниже приведена таблица с описанием каждого поля:

Поле в журнале событий	Описание
yy/mm/dd	Дата в формате год/месяц/день
hh:mm:ss.uuu	Локальное время в часах, минутах, секундах и миллисекундах.
Shhmm	Временная зона относительно GMT, где, s – это +/-, а hhmm – часы и минуты. Например, значение -0600 обозначает 6 часовую временную зону до GMT, т.е. Казахстан
P-nnnnnn	ID процесса, сформировавшего сообщение. ID процесса пустой для удаленных клиентов. Возможный размер, максимум 10 цифр
T-nnnnn	ID потока, сформировавшего сообщение. В Window, идентификаторы потоков уникальны для всей системы; не существует никаких возможных отношений между ID потока и порядком создания потоков. В Unix, ID потока уникально относительно процесса. Идентификатор основного потока – 1, а дополнительных потоки будут пронумерованы по порядку. В ID потока может быть максимум 5 цифр.
S	Уровень значимости сообщения. Существует три уровня: I – информационное сообщение. W – Предупреждающее сообщение. F – критичное сообщение.
name nnn:	Имя пользователя и его номер. Эти два значения образуют единое поле для идентификации источника сообщения. Возможные значения включают: BROKER 0:, USR 5:, RPLS 5:, DBUTIL: и т.д. Для этого поля отведено 9 символов. Имя пользователя выравнивается по левому, а его номер по правому краю поля.
(nnnnn)	Номер сообщения. С помощью этого номера можно получить больше информации о сообщении, используя Help – Messages… из OpenEdge Desktop или используя Progress Knowledge Base (ProKb)
Message text...	Текст сообзщения

Управление размером журнала

Со временем, размер файла журнала событий растет. Если он становится слишком большим, можно удалить из него старые данные. Для этого можно использовать утилиту Log Maintenance (PROLOG) или текстовый редактор. Предварительно, желательно сохранить данные из журнала событий.

Следующая команда очищает журнал событий базы данных:

prolog database-name [ -online ]

Важно помнить, что утилита удаляет все данные из журнала.

Для очистки журнала базы данных, находящейся в online, используется параметр –online.

Сохранение ключевых событий базы данных

Сохранение ключевых событий, обеспечивает администратора базы данных или техническую поддержку Progress эффективными отчетами по истории событий в вашей базе данных. Далее описываются ключевые события и их обработка:

Определение ключевых событий
Сохранение ключевых событий
Активация сохранения ключевых событий
Деактивация сохранения ключевых событий
Таблица _KeyEvt

Определение ключевых событий

Под ключевыми событиями базы данных подразумеваются: старт базы данных, изменение структуры базы данных, запуск определенных утилит и возникающих событий. Как только такое событие возникает, его детали записываются в журнал событий (.lg) базы данных. Как только будут активированы ключевые события, информация помимо записи в журнал, будет сохраняться в таблицу базы данных _KeyEvt. Что обеспечивает детальное описание событий в критичные моменты.

Наличие детализированной информации о событии полезно пр диагностике проблемы. Сохранение этой информации в таблице _KeyEvt гарантирует, что он не будет потеряна, когда вы выполните очистку журнала событий (.lg). Так же это обеспечивает быстрый доступ к информации, в отличии от обычного журнала, который может содержать миллионы записей.

Сохранение ключевых событий

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

[2006/04/06@10:52:58.578-0400] P-6450 T-1 I KEVTRDR 5: (13658)
Starting the Save Key Events daemon.
[2006/04/06@10:52:58.578-0400] P-6450 T-1 I KEVTRDR 5: (2518)
Started.

Этот процесс также видим в PROMON. На экране User Control можно наблюдать следующее:

Новый тип процесса называется KERD.

Активация сохранения ключевых событий

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

Для активации необходимо выполнить следующее:

1. Определить дополнительную область для таблицы _KeyEvt и добавить ее в базу. Если этого не сделать, то таблица будет включена в Schema Area.
2. Активировать базу данных для сохранения ключевых событий утилитой PROUTIL ENABLEKEYEVENTS:

Следующие пример демонстрирует этот процесс:

# show the contents of add_keyevt.st
$ cat add_keyevt.st
#
# Add area for key event storage
#
d "Key Event Area":26,32;8 .
#
$ prostrct add mydb add_keyevt.st
$
$ proutil mydb -C enablekeyevents “Key Event Area”
OpenEdge Release 10.1A01 as of Thu Apr 6 20:40:49 EDT 2006
Key Events has been enabled for database mydb. (12479)
$

Если вы добавляете новую область в базу данных, не забудьте обновить структурный файл командой PROSTRCT LIST.

Деактивация сохранения ключевых событий

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

proutil mydb -C disablekeyevents

Сохраняемые ключевые события

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

Действия с базой данных	Сохраняемые ключевые события
Database startup.	Время и дата запуска; Параметры запуска, одна запись на параметр; Текущее значение high water mark;
Database shutdown.	Дата и время остановки
Lock table overflow.	Дата и время переполнения
Protrace generation.	Дата и время генерации protrace; Имя и расположение protrace файла
DBTOOL	Дата и время старта утилиты; Дата и время завершения утилиты
PROBKUP	Дата и время старта утилиты; Расположения файла копии; Размер файла копии; Дата и время завершения утилиты
PROCOPY	Дата и время запуска утилиты; Расположение исходной базы данных; Расположение целевой базы данных; Дата и время завершения утилиты
PROLOG	Дата и время старта утилиты
PROMON RESOLVE LIMBO TRANSACTION	Дата и время старта утилиты; ID транзакции; Действие (commit, abort)
PROREST	Дата и время старта; Расположение файла копии; Дата и время завершения
PROSTRCT ADD	Дата и время старта
PROSTRCT BUILDDB	Дата и время старта; Имя структурного файла (.st)
PROSTRCT CREATE	Дата и время старта
PROSTRCT REMOVE	Дата и время старта; Имя и расположение удаляемых экстентов
PROSTRCT REORDER	Дата и время запуска
PROSTRCT REPAIR	Дата и время запуска
PROSTRCT UNLOCK	Дата и время запуска
PROUTIL 2PHASE BEGIN	Дата и время запуска
PROUTIL 2PHASE COMMIT	Дата и время запуска
PROUTIL 2PHASE END	Дата и время запуска
PROUTIL 2PHASE MODIFY	Дата и время запуска
PROUTIL 2PHASE RECOVER	Дата и время запуска
PROUTIL BIGROW	Дата и время запуска; Количество кластеров; Указанные опции (-r); Дата и время завершения
PROUTIL BULKLOAD	Дата и время старта; Дата и время завершения
PROUTIL CONV910	Дата и время запуска
PROUTIL CONVCHAR (convert option only)	Дата и время старта; Указанная кодовая страница
PROUTIL CONVFILE (convert using option only)	Дата и время старта; Имя и расположение конвертируемого файла
PROUTIL DBAUTHKEY	Дата и время запуска
PROUTIL DISABLEAUDITING	Дата и время запуска
PROUTIL DISABLEKEYEVENTS	Дата и время запуска
PROUTIL DISABLEJTA	Дата и время запуска
PROUTIL DUMP	Дата и время старта; Имя выгружаемой таблицы; Целевой каталог для выгрузки; Дата и время заврешения
PROUTIL DUMPSPECIFIED	Дата и время старта; Имя выгружаемой таблицы; Имя индекса по которому происходит выборка; Целевой каталог для выгрузки; Дата и время завершения
PROUTIL ENABLEAUDITING	Дата и время старта
PROUTIL ENABLEKEYEVENTS	Дата и время старта
PROUTIL ENABLELARGEFILES	Дата и время старта
PROUTIL ENABLEJTA	Дата и время старта
PROUTIL ENABLEPDR	Дата и время старта
PROUTIL IDXACTIVATE	Дата и время старта
PROUTIL IDXBUILD	Дата и время старта; Определенные опции (-TB, -TM, -SG); Дата и время завершения
PROUTIL IDXCHECK	Дата и время старта
PROUTIL IDXCOMPACT	Дата и время старта; Имя обрабатываемой таблицы и индекса; Степень уплотнения; Дата и время завершения
PROUTIL IDXFIX	Дата и время старта; Дата и время завершения
PROUTIL IDXMOVE	Дата и время старта; Имя перемещаемой таблицы и индекса; Целевая область перемещения индекса; Дата и время завершения
PROUTIL LOAD	Дата и время старта; Имя загружаемого файла; Дата и время завершения
PROUTIL MVSCH	Дата и время старта
PROUTIL TABLEMOVE	Дата и время старта; Имя перемещаемой таблицы; Целевая область для таблицы; Целевая область для индекса, если определено перемещение индексов; Дата и время завершения
PROUTIL TRUNCATE AREA	Дата и время старта; Дата и время завершения
PROUTIL TRUNCATE BI	Дата и время старта; Указанные опции (-bi); Дата и время завершения
PROUTIL TRUNCATE BI –F (Force access to damaged database.)	Дата и время старта
PROUTIL UPDATEVST	Дата и время старта
RFUTIL AIMAGE BEGIN	Дата и время старта
RFUTIL AIMAGE END	Дата и время старта
RFUTIL AIMAGE AIOFF	Дата и время старта
RFUTIL AIMAGE EXTENT EMPTY	Дата и время старта; Номер экстента и полный путь к нему
RFUTIL AIMAGE EXTRACT	Дата и время старта; Имя ai – экстента; Дата и время завершения
RFUTIL AIMAGE NEW	Дата и время старта
RFUTIL AIMAGE TRUNCATE	Дата и время старта; Указанный размер блока (-aiblocksize)$ Дата и время завершения
RFUTIL MARK BACKEDUP	Дата и время старта
RFUTIL ROLL FORWARD	Дата и время старта; Имя используемого ai – файла; Указанные опции (-r); Дата и время завершения
RFUTIL ROLL FORWARD RETRY	Дата и время старта; Имя используемого ai – файла; Указанные опции (-r); Дата и время завершения

Таблица _KeyEvt

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

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

Следующий пример, демонстрирует, как происходит активация и добавление таблицы в Schema Area:

$ proutil my-db -C enablekeyevents

Таблица _KeyEvt состоит из следующих полей:

Имя поля	Описание	Тип данных	Формат
_KeyEvt-Date	Дата и время, формате DATETIME-TZ, возникновения события	DATETIME-TZ	99/99/9999 HH:MM:SS.SSS+HH:M
_KeyEvt-Procid	ID процесса, который зарегистрировал событие	INTEGER	->,>>>,>>>,>>9
_KeyEvt-ThreadId	ID потока, зарегистрировавшего событие	INTEGER	->,>>>,>>>,>>9
_KeyEvt-MsgId	Номер сообщения события	INTEGER	->,>>>,>>>,>>9
_KeyEvt-Usrtyp	Тип пользователя сгенерировавшего событие, например, BROKER, DBUTIL, KEVTRDR, Usr и т.п.	CHARACTER	X(32)
_KeyEvt-Usrnum	Номер пользователя	INTEGER	->,>>>,>>>,>>9
_KeyEvt-Event	Текстовое сообщение, связанное с событием	CHARACTER	X(200)

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

Table move – перемещение таблицы в новую область (PROUTIL TABLEMOVE).
Truncate area – удаление данных из таблицы (PROUTIL TRUNCATE AREA).
Index move – Перемещение индексов таблицы (PROUTIL IDXMOVE).
Record deletion – удаление записей из таблицы, используя ABL или SQL.

Follow @vbashkatov

© 2009 - 2011 Все права на материалы, находящиеся на сайте www.openedge.ru, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах.
При любом использовании материалов сайта ссылка на источник обязательна.