Прим. редактора:
С тех пор прошло много лет и информация устарела. Более интересные данные можно получить в статье Безопасность OpenEdge-приложений - как есть.
Копирование БД
Для копирования БД можно использовать следующие основные приемы:
1. BACKUP/RESTORE – является штатной возможностью PROGRESS, может выполняться как для запущенной, так и для неиспользуемой БД. Гарантирует целостность копии. Имеется недостаток, бэкап может использоваться только совместимой версией PROGRESS, на совместимой ОС.
2. Копирование БД средствами ОС. Самая простая операция, но тем не менее, наиболее рискованная, т.к. целостность копии и ее работоспособность не гарантируется. Для минимизации риска при копировании БД, запущенной в многопользовательском режиме, средствами ОС, необходимо использовать команду PROQUIET ENABLE/DISABLE. Но даже при использовании этой команды, велик риск скопировать БД некорректно, особенно если она многотомная или используется параметр –g или –a. Имеется такой же недостаток как и в п.1.
3. PROCOPY – штатное средство копирования БД, которая находится в оффлайн. Учитывает структуру БД и ее размещение по дискам. Недостатки: БД не должна использоваться и несовместимость копии с другими версиями PROGRESS/ОС.
4. D&L (с использованием PROQUIET) обеспечивает целостность БД, платформо-независимость. Единственный недостаток – долгое время работы. Для сокращение времени дампирования необходимо использовать бинарный D&L.
Для корректного удаления БД лучше всего использовать команду PRODEL.
Сломанная БД
Часто при попытке законнектиться к БД, сервер БД сообщает о невозможности с ней соединится, по причине рассинхронизированности БД и BI файла.
Для решения этой проблемы необходимо использовать команду PROUTIL TRUNCATE BI –F, при этом БД будет помечена как поврежденная (tainted flag), но вы сможете получить к ней доступ. Если вы уверены, что ваша БД не является реально поврежденной, то для снятия пометки о повреждении, можно применить команду PROUTIL IDXBUILD и перестроить какой-нибудь один индекс в маленькой таблице (для 8-й версии, можно не перестраивать никакого индекса). Если ключ –F не помогает, то можно использовать параметр –RO для доступа к БД для чтения, а затем применить D&L.
На UNIX не редко бывают случаи когда сервер БД не удается остановить штатными средствами PROGRESS, как правило это связано с зомби-процессами, которые появляются при неправильно закрытой клиентской сессии. Эти процессы занимают определенный кусок разделяемой памяти, и не могут быть убиты брокером (или WATCHDOG), в этом случае можно использовать ключ –F с утилитами proshut и promon для получения доступа к БД и аварийному останову сервера. Аварийный останов может быть выполнен под root’ом.
Если в результате работы с БД вы получили сообщение: «SYSTEM ERROR: wrong dbkey in block. Found <dbkey>, should be <dbkey2> (1124)», то это означает, что физический адрес блока не совпадает с номером блока БД, записанным в его заголовке. Как правило, причина этой ошибки связана с ошибками в hardware и следует побеспокоится о перенесении БД на более надежную машину. Для устранения проблемы необходимо выявить, что за блок поврежден индексный или блок данных.
1. Прежде всего необходимо запомнить номер блока (dbkey)
2. Запустить утилиту PROUTIL DBRPR и сдампировать блок
3. 5-й байт блока указывает на его тип (правда, данная информация не всегда может быть корректна в сломанной БД, но тем не менее это последний шанс):
1. 1 – мастер блок
2. 2 – индекс блок
3. 3 – RM блок
4. 4 – free блок
5. 5 – индексный якорный блок
6. 6 – блок последовательностей
7. 7 – пустой блок
4. Если тип блока 2 или 5, то перестройка индексов поможет избавиться от проблемы сравнительно просто.
5. Если это блок 4, то его можно переформатировать.
6. Если это 1,3 или 6 блок, то для исправления ситуации необходим бэкап БД сравнительно недавний, восстанавливаем БД из бэкапа, дампируем блок и загружаем в сломанную БД утилитой DBRPR, иногда это помогает решить указанную проблему сравнительно безболезненно, но определенный риск при этом есть.
Иногда в БД возникает такая проблема, когда в уникальном индексе содержится неуникальное значение. Чаще всего причиной этого служит создание уникального индекса по «якобы» уникальному полю. В случае если индекс создается как активный, то проблемы особой не возникает, т.к. DATA DICTIONARY обнаружит эту проблему и откатит транзакцию. Проблема возникает когда индекс создается как неактивный и позднее перестраивается для активации. Данная проблема решается достаточно просто – удалением/изменением неуникального ключа. Для поиска неуникальной записи достаточно посмотреть информацию в LG файле, где будет указаны имя таблицы и RECID неуникальной записи, помогает также и поиск по другому индексу.
Последовательности
Последовательности имеют следующий большой недостаток, а именно когда значение последовательности превышает максимальное значение, и последовательность нецикличная (по умолчанию), то следующим значением последовательности будет «?», что не приведет к откату транзакции, но может сильно нарушить целостность БД. Для устранения этой проблемы рекомендуется устанавливать начальное значение последовательности как наименьшее отрицательное число и установить для нее свойство цикличности, первое - увеличит кол-во значений последовательности вдвое, а второе предотвратит нарушение целостности БД.
Отчеты
Как известно БД имеет кэш, размер которого задается параметром –B, в этом кэше располагаются блоки БД с которыми происходит наиболее активная работа, размер кэша как правило ограничен и вся БД физически не может в нем располагаться. Отчеты, как правило, строятся по данным, к которым происходит редкое обращение в обычном режиме работы, т.о. после запуска отчета наиболее используемые блоки БД вытесняются из кэша и в него попадают блоки, доступ к которым необходим единственному пользователю, запустившему отчет. Как правило такая ситуация сильно замедляет работу остальных пользователей и от нее необходимо избавляться для поддержания хорошей производительности приложения.
1. Основным способом решения это проблемы является создание (“warm”) копии БД (желательно на другой машине/диске), с которой могут работать пользователи, которым необходимы отчеты. Данная копия БД может быть запущена с ключом –i, который может значительно улучшить производительность при построении отчетов. Требует только административных и аппаратных затрат.
2. Создание специального интерфейса модуля отчетности, который бы не производил никакой транзакционной активности, и пользователи могли бы работать с ним с помощью ключа –RO. Данный ключ позволяет пользователям только читать данные без доступа к разделяемой памяти сервера и устанавливать им персональный размер кэша –B, что опять таки позволяет уменьшить время для построения отчетов. Требует разработки.
3. Использование Secondary Login Broker’а. Особенно полезно для клиент-серверных систем. Можно регулировать кол-во RCS для обычных пользователей и пользователей, работающих с отчетностью. Для обычных можно например установить соотношение 1 пользователь – 1 RCS, а для остальных - все пользователи – 1 RCS. Подходит для клиент-сервера.
4. Использование частных буферов в версии 9. В 9-й версии можно устанавливать для текущей сессии специальный «частный» буфер, в который будут считываться данные текущего пользователя, при этом остальной кэш не будет меняться. Для использования этой возможности можно использовать параметр –Bp, но это потребует специального входа для пользователя. Но управлять частными буферами можно и программно:
_MyConnection._MyConn-NumSeqBuffers = 10. Кол-во частных буферов не может превышать 25% от общего размера кэша. Требуется 9-ая версия.
D&L
Одна из самых распространенных операций с БД. Причины, когда D&L необходим:
1. Повреждение БД.
2. Сильная фрагментация БД для улучшения производительности.
3. Перенос БД на другую платформу, другую версию PROGRESS.
4. Изменение размера блока.
Dump
1. Использовать DATA DICTIONARY для выполнения операции. Преимущества: имеет простой интерфейс. Недостатки: не очень высокая скорость дампирования, ограничение в 2ГБ размер получаемых файлов. Перед дампированием БД лучше запустить PROUTIL DBANALYS для оценки размера получаемых файлов коэффициент составляет 1.6.
1. Не делать в клиент-сервере.
2. Использовать параметр –RO & -B
3. Дампировать параллельно несколько таблиц, при условии, что вас более одного CPU.
4. Не использовать -1, PROGRESS лучше работает в многопользовательском режиме.
2. Использовать BINARY DUMP. Преимущества: очень высокая скорость дампирования (8Х-10Х), нет ограничений на размер файлов. Недостатки: интерфейс командной строки, требуется задавать команду для дампирования каждой таблицы.
1. Использовать –RO & -B (без запуска сервера)
2. Дампировать параллельно.
Load
1. Использовать DATA DICTIONARY. Преимущества: имеет простой интерфейс. Недостатки: не очень высокая скорость.
1. Не делать в клиент-сервере.
2. Запустить сервер с параметром –i
3. Деактивировать индексы
4. Параллельная загрузка при наличии нескольких процессоров. Полезна для 9-й версии, где таблицы могут располагаться в отдельных областях.
2. PROUTIL BULKLOAD. Преимущества: высокая скорость загрузки. Недостатки: интерфейс командной строки, однопоточный процесс, нет возможности мониторить процесс загрузки, требуется перестройка индексов.
3. BINARY LOAD. Преимущества самая высокая скорость загрузки. Недостатки: интерфейс командной строки, для каждой таблицы своя команда загрузки, есть проблемы, связанные с удаление полей в БД (до версии 9).
1. Параллельная загрузка при наличии нескольких процессоров. Полезна для 9-й версии, где таблицы могут располагаться в отдельных областях.
Written by © Serguey Klimoff, 2003, Russia
Главная
