СЕКРЕТЫ OPENEDGE: УПРАВЛЕНИЕ БАЗАМИ ДАННЫХ OPENEDGE ПРИ ПОМОЩИ OPENEDGE MANAGEMENT

РАЗДЕЛЕНИЕ (ПАРТИЦИОНИРОВАНИЕ) ДАННЫХ

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

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

МИГРАЦИЯ НА ОБЛАСТИ ХРАНЕНИЯ ТИПА II

Переход на области хранения Типа II должен быть выполнен только тогда, когда он имеет смысл для бизнеса. Необходимо знать, как работать с такими областями, и уметь пользоваться их преимуществами. Существует довольно много способов такой миграции. Самый очевидный способ — это полная выгрузка ваших данных из существующей базы данных, создание новой базы с областями хранения Типа II и загрузка данных в эту базу. Есть и другие способы оперативной миграции. Все эти способы подразумевают простои в работе базы данных Наша цель — сделать такие простои минимальными. Самый очевидный подход (выгрузка и загрузка) влечет за собой самый длительный перерыв в работе. Есть способы постепенного перехода, которые сводятся к сериям относительно коротких перерывов. К примеру можно использовать триггеры базы данных для сохранения промежуточных изменений, но такой подход выходит за рамки данной книги.  Этот способ — самый действенный для тех случаев, когда простой БД должен быть сведен к минимуму. (например — proD&L от BravePoint Software, прим /dmi)

КРАТКИЙ ПЛАН ДЛЯ ВЫГРУЗКИ И ЗАГРУЗКИ ДАННЫХ.

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

Важное замечание: Большинство приложений обычно используют таблицу _User и последовательности (sequences). Если ваше приложение тоже использует эти таблицы, то не забудьте выгрузить таблицу _User и текущие значения последовательностей при выгрузке базы данных. (кроме того, могут быть использованы скрытые таблицы — Hidden Tables. Как пример — линейка Syteline ERP 6.x. Выгружайте такие таблиы используя галку «show hidden tables» , прим /dmi)

1. Выполнить dbanalys перегружаемой базы данных
2. Сделать резервную копию базы данных и проверить её
3. Сделать файл описания структуры основываясь на данных dbanalys (или использовать старый, если мы не делаем никаких изменений в расположении, типе, количестве или размере областей хранения)
4. Выгрузить файл словаря данных (df-файл)
5. Выгрузить данные (о способах выгрузки — читайте ниже)
6. Привести df-файл к соответствию со структурой базы данных (если необходимо)
7. Скопировать правильную empty базу данных в директорию, где расположен файл структуры (возможно, придется стереть предыдущую базу данных)
8. Загрузить df-файл определения данных
9. Проверить, что все сделано правильно (используя Data Dictionary или dbanalys)
10. Загрузить данные (способы описаны ниже)
11. Проверить загрузку утилитой dbaanlys
12. Сделать резервную копию базы данных

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

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

Скорее всего еще понадобится отредактировать файл словаря данных (df-файл). Если у вас уже есть области Типа I и вы просто переходите на области Типа II, то как правило никаких изменений делать не нужно. Однако, при необходимости сделать такие изменения совсем просто — нужно  открыть df-файл в любом текстовом редакторе и поискать слово «AREA«. Как правило у начинающих администраторов все объекты лежат в «Schema Area«. Как мы знаем из предыдущих глав — это неправильно и Schema Area должна содержать только схему.

Замечание: Если в названии области есть пробел, то такое название должно быть заключено в кавычки в параметрах утилит. Поэтому, если возможно, избегайте пробела и используйте вместо него значок «_». Возьмем, к примеру наименования : «Data Area» и Data_Area. Оба этих варианта имеют право на жизнь, но со вторым наименованием проще работать. Этот совет кажется поначалу банальным, однако вы его впоследствии оцените.

ВЫГРУЗКА И ЗАГРУЗКА ДАННЫХ

Выгрузить данные можно множеством способов. Самый простой способ — использование Data Administration. В секции Admin необходимо выбрать необходимые таблицы и директорию для выгрузки. Проблема в том, что выгрузка и загрузка в этом случае будут выполнены последовательно для каждой таблицы, причем будут использованы промежуточные текстовые файлы для выгружаемых (и соответственно загружаемых таблиц). Можно немного доработать процесс и использовать BUFFER-COPY из одной базы данных в другую, но это требует места для копии базы данных.

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

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

Самый простой способ уменьшения времени на перегрузку базы данных — это распараллеливание процессов выгрузки и загрузки. Как правило в существующих базах данных есть ряд больших таблиц, выгрузку которых можно выполнять параллельными процессами. В результате должно работать по одному процессу на большие таблицы и один процесс на выгрузку остальных таблиц. Проведите тестирование и определите, сколько одновременных процессов выгрузки может работать на вашем сервере — это число, естественно, варьируется на каждом отдельном сервере. Можно написать свой код для выгрузки большой таблицы частями множеством потоков и потом склеить выгруженные части при загрузке. Полезным может оказаться и использование private buffers (-Bp) для каждого процесса выгрузки, тем самым процессы буду работать со своими частными буферными пулами, и не будут претендовать на весь буферный пул базы данных.

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

• Выполнять загрузку в многопользовательском режиме
• Увеличить размер кластера BI до 128MB или больше
• Вернуть размер кластера BI обратно после загрузки
• Запускать процесс BIW и оптимальное количество процессов APW
• Выключить журналирование After-Image или не включать его пока загрузка не будет завершена.

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

УТИЛИТА BULK LOADER

Утилита массовой загрузки записей Bulk Loader удобна в использовании, но является однопоточной и требует перестройки индексов после своего завершения. Пользоваться этой утилитой имеет смысл только для баз размером до 1 Гб или тогда, когда простота процесса — это самое главное. Нужно выгрузить содержимое таблиц, определение структуры БД и создать файл для описания процесса массовой загрузки (bulk load). После завершения дампа необходимо создать новую БД, скопировать туда базу empty и загрузить описание структуры БД. Следующий шаг — запуск утилиты Bulk Load и перестройка индексов после её завершения. В конце необходимо произвести сравнение исходной и полученной баз данных.

УТИЛИТА ДВОИЧНОЙ ВЫГРУЗКИ И ЗАГРУЗКИ (BINARY DUMP & LOAD)

Возможность binary dump & load присутствует в Progress достаточно давно, причем сначала эта возможность была недокументированной. В OpenEdge 10 эта утилита получила много новых возможностей: выгрузка данных по любому индексу или выгрузка определенных записей, описанных в параметре dumpspecified. Этот параметр позволяет выгружать большую таблицу по частям в многопоточном режиме. Затем эти части последовательно загружаются утилитой двоичной загрузки. Загружать таблицу следует в однопоточном режиме, ведь многопоточная загрузка увеличит логическую фрагментацию данных. Детальное описание параметра можно найти в книге OpenEdge Data Management: Database Administration.

Так же, как и в предыдущих способах необходимо:

• Увеличить размер кластера before-image
• Выполнять процесс загрузки в многопользовательском режиме, 1 тред на область
• Запустить Before-Image Writer
• Запустить достаточное количество процессов Asynchronous Page Writer
• Убедиться, что  After Image выключен
• Сравнить исходную и полученную БД после процедуры загрузки

---