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

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

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

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

196158, Санкт-Петербург,
Пулковское шоссе, д. 30,
корп. 4, Лит. А, офис 203

Тел: +7 812 414 95 41

Москва

129085, г. Москва, проезд Ольминского, д. 3а, стр. 3, офис 706

Тел: +7 495 616 00 53

Блог

26.08.2015

Progress OpenEdge: промышленные средства репликации данных в Oracle и MS-SQL

Progress OpenEdge Pro2 Replication

Читать далее →




Десять причин перехода на новые версии OpenEdge (Progress)


Основы баз данных с OpenEdge (Администрирование)

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

Администрирование баз данных

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

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

  • Роль администратора базы данных
  • Обеспечение доступности системы
  • Сохранность данных
  • Поддержка системы
  • Ежедневные задачи мониторинга
  • Периодические задачи администрирования
  • Периодические административные события
  • Профилирование работы системы
  • Заключение

Роль администратора базы данных

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

  • Обеспечение доступности системы. Администратор должен понимать состояние системы в любой момент времени, т.е. знать как, что и когда происходит с точки зрения использования ресурсов, чтобы обеспечить надежную и доступную среду для пользователей. Это означает, что нужно знать больше чем просто как она работает. Нужно иметь более глубокое понимание тенденций в области использования системы во времени. Также, необходимо понимание бизнеса в целом, чтобы своевременно предоставлять бизнесу необходимую информацию. Эта связь должна быть двусторонней, т.е. администратор не просто сообщает о состоянии системы, но и участвует в процессе планирования развития бизнеса в части возможностей расширения информационной среды.
  • Обеспечение устойчивости системы, в плане противостояния или восстановления после различных сбоев. Администратор должен предусмотреть все потенциально возможные проблемы и определить, как они могут быть исправлены, включив возможные способы решения в план аварийного восстановления. Пункты по решению возможных проблем, очень важны в таком документе. Так как основное внимание в плане должно уделяться именно восстановлению, а не процессу резервного копирования, поскольку резервная копия будет бесполезна, если вы не сможете восстановить систему из неё.
  • Обеспечение надежности системы. Пользователи должны понимать, как много времени им понадобится на выполнение задачи, чтобы осуществлять планирование работы. Приложение играет немаловажную роль для производительности. Тем не менее, работа администратора заключается в том, чтобы контролировать время выполнения таких задач каждый день, учитывая используемые ими ресурсы, чтобы своевременно устранять узкие места в системе.
  • Выполнение технического обслуживания. Такая задача, возможно, будет выполняться только раз в году, но она всё равно должна быть включена в административный план. Мелкие детали каждой задачи могут меняться во время выполнения, но общий процесс должен быть заранее описан.

Обеспечение доступности системы

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

Работа ресурсов является второй наиболее вероятной причиной сбоя системы (аппаратный сбой является наиболее распространенным). Требуется постоянно обеспечивать максимальную доступность системы. Осуществление этого и есть роль администратора базы данных.

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

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

Возможности хранения данных в базе

Важно понимать не только то, как много данных в базе на сегодняшний день, но и насколько можно ожидать их роста. В существующих базах данных необходимо следить за high-water mark областей хранения данных. «High-water mark» устанавливается по количеству форматированных блоков в области. В области с большим количеством empty-блоков данных, данные размещаются в эти блоки, прежде чем система расширит пространство последнего экстента в этой области. Задача заключается в том, чтобы не использовать переменные экстенты, но последний экстент должен быть всегда переменного размера, на случай резкого роста количества данных.

Планирование избыточной емкости базы данных должно выполняться так, чтобы ее хватило, по крайней мере, на время полезной работы системы. Различные среды имеют различное рабочее время. Некоторые системы могут останавливаться каждый вечер, в то время как системы в режиме 24×7, могут останавливаться только один раз в году на техническое обслуживание. При правильном планировании можно обеспечить работу базы данных в течение длительных периодов времени, без необходимости остановки. В большинстве случаев базу данных OpenEdge не обязательно останавливать для технического обслуживания.

Операционная система для обслуживания и обновления, возможно, будет останавливаться более часто, чем ваша база данных. Примерами этого вида обслуживания могут служить: очистка памяти, установка дополнительного оборудования, или внесении изменений в параметры ядра операционной системы. В Windows, в основном необходимо перезагружать систему каждые 30 — 90 дней, чтобы избежать проблем, в то время как на большинстве UNIX/LINUX систем это можно делать один раз в год. Вы должны предусмотреть возможность роста количества данных в течение всего периода работы своей системы.

Нагрузка на систему

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

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

Системная память

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

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

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

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

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

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

Тестирование для предупреждения проблем

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

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

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

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

Сохранность данных

Устойчивость (Resiliency) —  это способность восстановления в случае возникновения аварийной ситуации. Цель такого восстановления заключается в том, чтобы вернуться в состояние до возникновения сбоя так, как будто ничего не произошло. Последствия невозможности восстановления системы могут быть достаточно серьезными, самый простой пример этому — сбой web-сайта, если клиент или потенциальный клиент не сможет получить доступ к вашему сайту, то этот клиент может быть утрачен навсегда. OpenEdge поддерживает множество функций для улучшения доступности ваших данных в случае сбоев системы, как, например, поддержка failover cluster и OpenEdge Replication, но основными элементами стратегии восстановления являются хорошая резервная копия и отлаженный процесс восстановления из неё.

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

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

Зачем нужно делать резервные копии?

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

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

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

  • Кто выполняет резервное копирование?
  • Какие данные необходимо резервировать?
  • Где должны храниться архивы?
  • Когда будет выполняться резервное копирование?
  • Как резервное копирование должно выполняться?
  • Как часто текущая резервная стратегия должна тестироваться и пересматриваться?

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

Создание полноценной стратегии резервного копирования и восстановления

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

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

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

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

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

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

Кто формирует резервные копии?

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

Что должно быть включено в резервную копию?

Приложение может состоять из множества различных компонентов, включая базы данных, прикладной код, пользовательские файлы, входные файлы, файлы сторонних приложений и так далее. Помните, что ваше приложение построено на вашей OpenEdge-инсталляции с соответствующими обновлениями (Service Packs), исходными кодами и объектами приложения, вспомогательными программами, например такими как AppServer, и связанными со всем этим файлами операционной системы.

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

  • Системы которые сейчас включены и работают
  • Файлы приложений
  • Данные, используемые внутри процесса

Где хранить копии?

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

При использовании ленты (tape) должны рассматриваться возможности ее совместимости. Поскольку может понадобиться ее использование в различных системах. Это позволит выполнять резервное копирование на одной системе, и, в случае сбоя, восстанавливать копию на другой системе. Многие платформы поддерживают Digital Linear Tape (DLT), что позволяет без труда перемещать данные от одной системы в другую или восстанавливать их из архива.

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

Как маркировать резервные копии?

Правильная маркировка резервных носителей очень важна при их использовании. Каждая метка должна содержать:

  • Имена конкретных элементов, хранимых на носителе. Просто метка «ночная копия» не имеет смысла без списка объектов, которые вошли в эту ночную копию.
  • Дата и время создания копии. Это позволит идентифицировать необходимый носитель для выполнения восстановления — найти самую последнюю копию, или же копию на конкретный момент времени.
  • Для гарантирования качества резервной копии необходимо указывать имя и инициалы сотрудника, который ее выполнял, и несет за нее ответственность.
  • На носителе должны быть подробные инструкции по восстановлению архивов. Они должны быть легки для понимания, и могут включать в себя конкретные команды для работы.
  • Порядковый номер носителя, и общее количество носителей — метка должна читаться как «Носитель n из m».

Когда выполнять резервное копирование?

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

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

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

Использование для копирования утилиты PROBKUP вместо утилит операционной системы

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

Понимание утилиты PROBKUP

Утилита OpenEdge PROBKUP была создана для копирования базы данных OpenEdge. У нее есть много хороших характеристик, которые делают ее полезной:

  • PROBKUP хорошо «знает» базу данных. Это означает, что утилита распознает структуру и формат базы данных. Утилита PROBKUP во время процесса резервного копирования гарантирует правильность формата, выполняя сканирование каждого блока данных. Сканирование занимает больше времени, но проверка целостности наиболее редко используемых блоков, не значительно влияет на производительность.
  • PROBKUP имеет опцию ONLINE. Наличие этой опции позволяет вам выполнять резервное копирование базы данных даже тогда, когда она запущена и доступна пользователям. Утилита PROBKUP «знает» когда структура базы данных изменяется, независимо от количества дисков, областей и экстентов. Следовательно, синтаксис команды не нужно изменять после изменения структуры базы данных.

Как PROBKUP работает?

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

  • Устанавливается замок (latch) на базу данных (только в online)
  • Выполняется псевдо контрольная точка (только в online)
  • Переключаются AI файлы (если необходимо)
  • Выполняется копирование области Primary Recovery (только в online)
  • С базы данных снимается замок (только в online)
  • Выполняется резервное копирование базы данных.

Копирование базы данных происходит до уровня High-water mark. Для сохранения пространства, свободные (Free) блоки сжимаются. Online — копия, представляет собой базу данных на момент запуска резервного копирования. Все транзакции, которые будут начаты после запуска утилиты, не войдут в копию, т.е. после восстановления такой копии, их не будет в базе данных.

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

Дополнение PROBKUP утилитами операционной системы

Утилита PROBKUP копирует базу данных и область Primary Recovery. Но она не выполняет копирование After-image файлов или журнала событий базы данных (.lg).

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

Работа с After-Imaging

Механизм After-imaging обеспечивает дополнительный уровень защиты базы данных. В каждой системе высокой доступности должен быть включен этот механизм. Но перед началом его использования у вас должен быть разработан и хорошо отлажен план резервного копирования и восстановления.

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

Первичная причина необходимости использования after-image, это защита от потери носителя. Это означает потерю базы данных, потерю области Primary Recovery, или ленты с резервной копией. В случае, если была потеряна последняя резервная копия, вы можете воспользоваться предыдущей копией, восстановив ее и последовательно, с помощью AI-файлов, восстановить базу до любого момента времени. Именно такая ситуация объясняет необходимость хранения AI-файлов на отдельном носителе, отличном от того, на котором хранится основная резервная копия базы данных.

Механизм After-imaging также позволяет вам организовать «горячее копирование» (warm standby copy) вашей базы данных. Такая копия может храниться в той же системе, где и первичная копия. Тем не менее, для обеспечения максимальной безопасности её лучше размещать в отдельной системе. Корпорация Progress Software разработала и поддерживает возможность репликации базы данных с помощью продукта OpenEdge Replication, но с помощью After-Imaging вы можете разрабатывать собственные решения по копированию баз данных. При использовании After-Imaging вы может периодически изменять вашу «горячую копию» базы данных, выполняя перемещение AI-файлов от первичной базы данных к вторичной базе, с последовательным их накатом на резервную копию. Таким образом, в случае системного сбоя, вам останется только накатить на резервную базу данных последние  AI-файлы, и вы сможете использовать ее для полноценной работы. Если по каким-либо причинам, последние AI-файлы не могут быть использованы, то вы потеряете только те данные, которые были внесены после последнего наката AI-файлов на резервную копию. Наличие «горячей» копии базы данных обычно обеспечивает значительно меньшее время простоя системы в случае системного сбоя, чем если бы вы восстанавливали базу данных из обычной резервной копии.

Тестирование стратегии восстановления

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

Как часто вы должны тестировать копии? Если для копирования вы используете утилиты операционной системы, то тестирование нужно выполнять каждый раз после изменения структуры промышленной базы данных. Поскольку PROBKUP хорошо «знает» базу данных, то в тестирование при изменении её структуры нет необходимости. Тем не менее, нет ничего страшного в выполнении тестирования по крайней мере два раза в год.

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

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

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

Поддержка системы

Не позволяйте удобству эксплуатации баз данных OpenEdge расслаблять вас в плане поддержки вашей системы. Ее «здоровье» должно проверяться каждый день. А это можно делать как с помощью стандартных инструментальных средств, например, с помощью OpenEdge Management, так и с помощью самописных скриптов.

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

Ежедневные задачи мониторинга

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

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

Мониторинг журнала базы данных (.lg)

Журнал базы данных (лог-файл или .lg) содержит массу информации о деятельности базы данных. База OpenEdge размещает в нем не только информацию о подключении и отключении пользователей, но и достаточно много других полезных данных. Например, когда база данных стартует, то информация обо всех параметрах запуска помещается в этот файл. Они могут использоваться, например, для проверки вашего файла параметров (.pf) или файла conmgr.properties.

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

Журнал базы данных должен регулярно усекаться, позволяя поддерживать его размер в приемлемом состоянии. С этой целью была создана утилита PROLOG. Но ее использование должно всегда выполняться только после резервного копирования лог-файла.

Существует возможность включения записи ключевых событий из журнала в таблицу базы данных _KeyEvt. Это позволит вам сохранять историю возникновения критических событий, которые были связаны с ней. Когда такая возможность активирована, создается дополнительный фоновый процесс, который периодически сканирует журнал базы данных, и, в случае идентификации ключевого события, создает записи в таблице _KeyEvt. Для детального изучения этой возможности обратитесь к книге «Администрирование Progress OpenEdge для начинающих».

Мониторинг заполнения областей

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

Мониторинг buffer hit rate

Buffer hit rate показывает отношение количества чтений записей из памяти относительно их чтений с дисков. Для обеспечения хорошей производительности и с целью своевременного вмешательства, мониторинг этого значения должен осуществлять в течение всего дня. Хорошим показателем работы системы является значение Buffer Hit Rate равное 95%.

Мониторинг сброса буферов во время контрольных точек

Сброс буферов в контрольных точках (buffer flushed at checkpoint) это хороший индикатор  работы APW и эффективности контрольной точки. Работа APW заключается в обеспечении маленького количества записываемых буферов в контрольных точках. Также не должно быть частых контрольных точек, при которых база данных и память синхронизируются. Если вы заметили увеличение количества сбрасываемых буферов во время обычного периода работы, и если это увеличение не связано с формирование резервных копий, то вам определенно следует внести корректировки в настройку системы.

Мониторинг системных ресурсов (диски, память и CPU)

Системные ресурсы, работу которых необходимо ежедневно контролировать, могут меняться от системы к системе. Но такие показатели как, заполнение дисков, потребление памяти и использование процессоров, являются стандартными для мониторинга в любых системах. Собственно говоря, память и CPU являются менее важными ресурсами, поскольку обычно их чрезмерное использование приводит только к проблемам производительности. А вот проблемы, которые возникают с дисками, могут привести к простою системы.

Периодические задачи администрирования

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

Периодическими административными задачами в OpenEdge считаются:

  • Анализ базы данных
  • Перестройка индексов
  • Уплотнение индексов
  • Исправление индексов (fixing indexes)
  • Перемещение таблиц
  • Перемещение индексов
  • Усечение и наращивание BI-файлов
  • Перезагрузка данных (dump/load)

Анализ базы данных

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

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

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

Перестройка индексов

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

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

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

Уплотнение индексов

Уплотнение индексов с помощью утилиты PROUTIL IDXCOMPACT — это online-альтернатива утилите перестройки индексов. Используйте ее когда вы видите, что индекс не настолько эффективен, как ожидалось, и когда остановка базы данных невозможна. Неэффективность индекса можно определить по чтению из базы данных или по результатам выполнения утилиты анализа индексов.

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

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

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

Утилита исправления индекса, PROUTIL IDXFIX, позволяет корректировать листовые уровни поврежденного индекса на запущенной базе данных, и с минимальным влиянием на производительность. Используйте её, если будет получено сообщение указывающее на проблемы с индексом. Но если индекс поврежден на уровне перехода (branch level), а не на листовом уровне (leaf level), то вы должны воспользоваться утилитой перестройки индекса чтобы исправить эту проблему.

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

Цель утилиты перемещения таблиц, PROUTIL TABLEMOVE, это перемещение таблицы из одной области хранения в другую. Это позволяет балансировать нагрузку ввода-вывода или организовывать таблицы в группы. Вы можете использовать утилиту когда пользователи имеют доступ к базе данных, но если они попытаются обратиться к перемещаемой таблице, они будут заблокированы на время выполнения перемещения. Утилита требует значительного количества информационного пространства. Это влияет на области Primary Recovery и After-Image. В области Primary Recovery будет использовано в три — четыре раза больше пространства, чем занимаемого непосредственно самой таблицей. Если вы не правильно спланируете процесс перемещения, то вы рискуете повредить базу данных из-за недостатка места в области Primary Recovery. Поэтому всегда сначала протестируйте процесс перемещения на копии базы данных, прежде чем выполнять перемещение на промышленной базе.

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

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

Усечение и наращивание BI-файлов

Файл Before-Image или область Primary Recovery, в зависимости от транзакций в вашей системе, может меняться в размере. Иногда, вы можете наблюдать ненормальный рост этой области, как например, когда вы вносите изменения в схему или выполняете множественные изменения в таблице базы данных рамках одной большой транзакции. В итоге, это приводит к необходимости усечения BI-файла для восстановления использованного пространства. Для этого вы можете воспользоваться утилитой PROUTIL TRUNCATE BI.

Но вы не должны излишне усекать BI. Когда по каким-либо причинам вы его усекаете, OpenEdge вынужден переформатировать его, чтобы сделать пригодным для использования. Если форматирование будет выполняться во время работы системы, это может привести к существенной потере производительности. Следовательно, вы должны измерить BI-файл, чтобы обеспечить его нормальный рост. Расширить его пространство можно с помощью утилиты PROUTIL BIGROW, указав необходимое количество кластеров, которые будут предварительно отформатированы. Это исключит необходимость форматирование новых кластеров во время работы системы, и тем самым позволит исключить потерю производительности.

Перезагрузка данных

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

Очень важна скорость выполнение перезагрузки данных, поскольку во время этого процесса база данных не будет доступна пользователям. Также перед выполнением перезагрузки обязательно необходимо сделать резервную копию базы данных. Что в случае возникновения каких-либо проблем во время процесса перезагрузки, позволит вернуть базу данных в исходное состояние.

Существует три основные методики перезагрузки:

  • С помощью Data Dictionary
  • С помощью Bulk loader`а
  • Бинарная перезагрузка.

Перезагрузка с помощью Data Dictionary

Этот метод существует с момента зарождения Progress, и если придерживаться определенных правил, он все еще жизнеспособный:

  • Как выгрузка, так и загрузка данных должны выполняться в многопоточном режиме. Вы можете добавлять количество сессий так много, пока не столкнетесь с узким местом в системе.
  • Чтобы достичь максимальной производительности, равномерно используйте все диски системы. Например, вы можете задействовать диски, которые используются для BI-файлов, поскольку во время процесса выгрузки они будут простаивать.
  • Оставьте индексы активированными во время перезагрузки. Это не улучшит их эффективность из-за их разброса во время процесса загрузки, но поскольку индексы будут строиться в тоже время, когда данные будут загружаться, то вы сможете воспользоваться преимуществом многопоточной природы OpenEdge. А после завершения перезагрузки вы сможете их реорганизовать с помощью утилиты уплотнения индексов.

Перезагрузка с помощью Bulk loader`а

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

Бинарная перезагрузка

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

Периодические административные события

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

Периодические события могут состоять из:

  • Ежегодное резервное копирование
  • Архивирование
  • Изменение приложений
  • Переход на новые версии OpenEdge

Ежегодное резервное копирование

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

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

Архивирование

В хорошем вычислительном центре всегда есть полноценная стратегия архивирования. Вообще то, это не обязательно, чтоб обеспечить доступность бизнес в течение длительных периодов времени. В большинстве случаев, 13 месячный хронологический цикл достаточен. Но ситуация может меняться в зависимости от приложения и от самой компании. Поэтому вы должны в полной мере знать правила приложения и требования бизнеса для того, чтобы правильно принять решение относительно того, когда и какие данные архивировать. Иногда вы будете должны сохранять старые данные в offline, на случай их надобности. В этих случаях, у вас должны быть разработаны процедуры выгрузки и чистки данных для экспорта в ASCII. Это формат всегда более удобен в случае изменения окружения или если понадобится загрузить часть данных в другое приложение, например, в Microsoft Excel. Всегда проверяйте наличие работоспособной копии данных перед выполнением их чистки в базе. Архивирование и чистка данных значительно улучшают производительность, поскольку в системе будет оставаться меньшее количество записей, которые будут просматриваться при выполнении поиска.

Изменение приложений

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

Выполнение изменений схемы

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

Выполнение изменений кода приложения

Количество времени, которое может понадобиться на внедрении измененных программ, можно существенно сократить, выполнив их компиляцию на базе данных, CRC которой будет полностью соответствовать CRC вашей промышленной базы данных. Чтобы обеспечить совместимость CRC, создайте пустую базу данных, которая будет содержать только описание схемы, т.е. без пользовательских данных. Описание схемы (.df) можно взять с промышленной базы данных. Используйте эту базу как промежуточное звено между тестовой базой разработки и промышленной базой данных. Некоторые называют такую базу данных «эталонной». Таким образом, у вас должно быть три базы: тестовая база разработки, промышленная база данных и эталонная база данных.

Поскольку разработка ведется на тестовой базе данных, то промышленная и эталонная базы не будут изменяться. Когда ваши изменения схемы будут готовы к внедрению в промышленную базу, тогда перед этим вам нужно сделать инкрементальный дамп определения данных с помощью OpenEdge Data Dictionary, с целью сравнения схем эталонной и тестовой баз данных. Полученный инкрементальный дамп, может быть загружен в эталонную базу данных, после чего вы сможете скомпилировать свое приложение на ней. После чего, вы, используя этот инкрементальный дамп, загружаете изменения в промышленную базу данных в любое удобное время (после выполнения тестирования, конечно же). И пока эти изменения загружаются, вы можете выполнить перемещение r-кодов, которые вы создали на эталонной базе данных, в промышленную среду. Тем самым исключается дополнительное время простоя, которое связанно с необходимостью перекомпиляции программ.

Замена версий OpenEdge

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

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

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

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

Профилирование производительности системы

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

Установка базового уровня производительности

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

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

В состав таких задач должны входить:

  • Задачи, которые выполняются много раз в течении дня (такие как формирование заказов, их контроль и ввод данных)
  • Задачи, которые важны для пользователей (запросы к WEB-сайту, поддержка клиентов, обработка заказов)

Не стоит включать в список такие задачи как:

  • Периодически выполняющиеся (например, еженедельные или ежемесячные отчеты)
  • Малоиспользуемые части вашего приложения
  • Отчетность, которая попадает под обе эти категории. А так же отчетность, которая формируется внерабочее время.

Сбор статистики базового уровня

Как только вы определитесь с элементами, эффективность работы которых нужно отслеживать, вы можете приступить к планированию стратегии сбора статистики.

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

Анализ собранной статистики

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

Как говорилось ранее, установку базовых уровней лучше выполнять тогда, когда никаких отчетов не формируется, и нет никаких проблем в системе. Это позволит определить параметры нормального режима работы системы. Если пользователи будут сообщать вам о каких-либо проблемах, у вас будет возможность сравнить данные базовых временных выборок с аналогичными текущими временными выборками за тот же период. Если будут обнаружены отклонения текущих данных от базовых, то вы можете дополнительно запустить анализ производительности системы с помощью специализированных инструментальных средств. Например, с помощью PROMON, VST (Virtual System Tables), OpenEdge Management, а так же различных статистических утилит операционной системы.

Методология настройки производительности

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

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

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

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

Заключение

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

Искренне Ваш,
Валерий Башкатов




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

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

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