Цикл эксплуатации любой информационной системы включает в себя множество регулярных мероприятий. К регулярным мероприятиям относятся процессы и действия, которые выполняются на протяжении всего цикла эксплуатации системы с заданной периодичностью или должны быть выполнены при возникновении определенных условий. Примерами регулярных мероприятий являются действия по резервному копированию базы данных, контроль за свободным объемом устройств баз данных, управление пользователями и другие. Различные регулярные мероприятия могут выполняться как в ручном, так и в автоматическом режимах.
В рамках цикла эксплуатации системы администратор должен организовать ее сопровождение, которое обеспечивает выполнение требований к эксплуатации информационной системы со стороны пользователей и включает в себя следующие виды мероприятий.
планирование и организация автоматически выполняемых регулярных процессов;
планирование и организация регулярных действий системного администратора;
организация обновления программного обеспечения ONTARIO1;
изменение настроек системы ONTARIO1.
Рассмотрим перечисленные виды мероприятий более подробно.
Для организация автоматически выполняемых регулярных процессов в системе используется механизм Task Scheduler сервиса SQL Executive. Общие сведения и методика работы с данным механизмом приведены в главе 16 "Scheduling Task" книги [4].
К числу автоматически исполняемых регулярных процессов относятся:
регулярное копирование информации
проверка целостности базы данных
оптимизация использования индексов
Для минимизации риска потери данных необходимо спланировать и организовать регулярное резервное копирование информации. При этом следует представлять себе, что чрезмерно частое копирование приводит к уменьшению производительности SQL Server, а чрезмерно редкое - к увеличению риска потери данных между моментами времени их резервного копирования.
Средствами SQL Executive необходимо организовать регулярное выполнение процессов резервного сохранения БД. Перед этим необходимо ознакомиться с методикой копирования/восстановления данных, описанной в главе 12 “Backing Up and Restoring” [4]. Администратору необходимо решить две основных задачи:
Горячее резервное копирование журнала транзакций
Полное копирование БД
Таковым является процесс инкрементного дампирования журнала транзакций, который должен проводиться с приемлемым с целью оперативного восстановления данных в случае сбоя. Величину временного интервала следует выбирать из требований производительности и надежности. Так если копирование будет происходить слишком часто, то сервер будет постоянно занят этим процессом, что несомненно ухудшит производительность работы системы в целом. Если же копирование будет происходит с большим периодом, то при сбое в течение этого периода существует вероятность потерять все данных, которые были изменены в системе за этот период.
В большинстве случаев оптимальным может являться интервал в 30..60 минут в зависимости от интенсивности работы пользователей.
Пример организации процесса горячего копирования для БД с именем O1 с интервалом в 45 минут.
Создайте новое устройство на диске сервера БД для резервного копирования журнала транзакций и назовите его, например, O1_LOG_BACKUP. Проинициализируйте созданное устройство дампом текущего журнала транзакций, путем подачи команды:
dump transaction O1 to O1_LOG_BACKUP with INIT
с консоли SQL Server или из Enterprise Manager. Затем создайте новую задачу и запланируйте ее регулярное выполнение с периодичностью, например каждые 45 минут круглосуточно (в режиме 24х7), начиная с 00 часов 00 минут. В окне ввода Command следует записать вызов процедуры (тип команд - TSQL):
dump transaction O1 to O1_LOG_BACKUP
Полное резервное копирование БД является более длительным процессом, чем горячее копирование журнала транзакций, и потому может применяться только на более длительных интервалах. Перед полным копированием инициализируется журнал транзакций, все изменения фиксируется в БД и производится непосредственно резервное копирование БД.
В большинстве случаев оптимальным периодом могут являться сутки. При этом также следует учитывать выше обозначенное соотношение "частота копирование/производительность". По этой причине полное копирование рекомендуется проводить в конце рабочего дня или во время наименьшей активности пользователей.
Пример организации процесса полного копирования для БД с именем O1 с интервалом в 24 часа.
Создайте новое устройство на диске сервера БД для резервного копирования журнала транзакций и назовите его, например, O1_DATA_BACKUP. Создайте новую задачу и запланируйте ее регулярное выполнение с периодичностью “раз в сутки” начиная с 00 часов 10 минут (так как на 00-00 в предыдущем примере у нас уже было запланировано копирование журнала транзакций). В окне ввода Command следует записать вызов процедуры (тип команд - TSQL):
dump transaction O1 to
O1_LOG_BACKUP with INIT
dump database O1 to O1_DATA_BACKUP with INIT
Для профилактической проверки целостности БД достаточно с периодичностью раз в сутки производить полную проверку БД и проверку автоинкрементных счеткиков (IDENTITY) в следующих таблицах БД:
Objs
OpLog
RateList
Classes
ProcessObjs
Более подробно о проверке целостности БД описано в пункте "Database Consistency Checking" приложения "E" книги [4] и описании "DBCC Statement" книги [5].
Пример организации процесса проверки целостности для БД с именем O1 с интервалом в 24 часа.
Создайте новую задачу и запланируйте ее регулярное выполнение с периодичностью “раз в сутки” начиная с 00 часов 30 минут (так как на 00-10 в предыдущем примере у нас уже было запланировано копирование БД). В окне ввода Command следует записать вызов процедуры (тип команд - TSQL):
use master
dbcc checkdb( O1 )
use O1
dbcc checkident( Objs )
dbcc checkident( OpLog )
dbcc checkident( RateList )
dbcc checkident( RateList )
dbcc checkident( Classes )
dbcc checkident( ProcessObjs )
В связи с изменением объема и содержания БД, планы выполнения одних и тех же процедур БД (stored procedure) с течением времени могут изменяться. Для этого необходимо периодически обновлять статистику использования индексов при запросах к таблицам и производить перекомпиляцию процедур, использующих данные таблицы.
Более подробно эта тема освещена в описании "UPDATE STATISTICS Statement" книги [5].
Пример организации процесса оптимизации индексов для БД с именем O1 с интервалом в 24 часа.
Создайте новую задачу и запланируйте ее регулярное выполнение с периодичностью “раз в сутки” начиная с 00 часов 40 минут (так как на 00-20 в предыдущем примере у нас уже было запланировано проверка целостности БД). В окне ввода Command следует записать вызов процедуры (тип команд - TSQL):
declare @TableName varchar( 32 )
declare CTables insensitive cursor for
select name from sysobjects where type = 'U'
open CTables
fetch next from CTables into @TableName
while ( @@fetch_status != -1 ) begin
execute ( "update statistics " + @TableName )
execute ( "execute sp_recompile " + @TableName )
fetch next from CTables into @TableName
end
deallocate CTables
Регулярными действиями системного администратора, являются следующие мероприятия:
Методика визуального контроля над выполнением регулярных процессов приведена в разделе “Monitoring, Modifying, or Canceling a Scheduled Backup” главы 12 книги [4]. Если периодический визуальный контроль выполнения процессов не удовлетворяет требованиям оперативного разрешения возможных сбоев и отказов, то необходимо задействовать возможности оповещения о неудачном завершении процесса по электронной почте средствами SQL Scheduler. Методика организации приведена в разделе "Setting Backup Task Options" главы 12 книги [4]. Описанная методика успешно применяется ко всем вышеперечисленным процессам, созданных в предыдущем разделе главы.
Средствами механизма предупреждений
(SQL Alerter и Performance Monitor) необходимо организовать оперативное решение следующих задач:Для предупреждения переполнения базы данных и устройства необходимо воспользоваться механизмом предупреждений
Windows NT Performance Monitor. Общий алгоритм создания предупреждений на эти прикладные (изначально отсутствующие в системе) события выглядит следующим образом.Используя приведенный общий алгоритм, следует создать три сигнализатора критической ситуации, предназначенных для решения вышеназванных задач.
Для своевременного расширения устройства и самой базы данных
системы O1 необходимо выполнить действия и настройку по вышеприведенному алгоритму, который будет пересылать администратору сообщение сетевыми средствами Windows NT (применение команды NET SEND из командной строки средствами процедуры xp_cmdshell SQL Server) или средствами SQL Mail. Необходимо настроить Performance Monitor на превышение заполнения 80% от общего объема базы данных. В дальнейшем, при получении сигнала, администратор должен немедленно расширить устройство и саму базу данных на 20% от ее текущего объема. Расширение устройства и базы данных подробно описано в главе 5 “Managing Devices” и главе 6 “Managing Databases” книги [4].Аналогичным образом решается задача своевременного расширение устройства и базы данных
tempdb. При этом необходимо настроить Performance Monitor на превышение 75% от общего объема базы данных. При получении сигнала, администратор должен также немедленно расширить устройство и саму базу данных на 25% от ее текущего объема.Дополнительных настроек требует своевременное расширение устройства и самого журнала транзакций базы данных
системы O1. Необходимо также организовать пересылку сообщения администратору и настроить Performance Monitor на превышение 75% от общего объема журнала транзакций. При получении этого сообщения администратор должен немедленно расширить устройство и сам журнал транзакций на 25% от его текущего объема. Кроме пересылки сообщения администратору необходимо в соответствии пунктами 1 и 2 приведенного выше алгоритма настроить очистку журнал транзакций в момент его переполнения на случай, если не удастся своевременно увеличить его объем.Существует также альтернативный метод, при котором в случае переполнения журнала транзакций, можно просто увеличить частоту выполнения процесса его дампирования (регулярный процесс
dump transaction). При этом следует принимать во внимание, что частое дампирование журнала транзакций приведет к уменьшению производительности SQL Server для конечных пользователей. Поэтому решение о выборе того или иного пути принимается администратором опытным путем.Программное обеспечение ONTARIO1 имеет версию, которая обладает определенной функциональностью. Номер текущей версии можно увидеть, если открыть в главном меню клиентского приложения пункт "О программе...".
Рис.4.1. Окно вывода информации о системе и версии
На рис.4.1 отображена текущая версия ONTARIO1 в формате ##.##.##.##, где #-любая цифра. Первое число до запятой обозначает глобальную версию или серию всего продукта (мажорный номер версии). На сегодняшний день доступна система версии 1. Остальные числа обозначают текущий минорный номер версии продукта данной мажорной версии.
Производитель программного обеспечения ONTARIO1 оставляет за собой обязанность создавать новые версии программного обеспечения, которые обеспечивают устранение найденных ошибок и право создавать новые версии, реализующих дополнительную, по сравнению к предыдущей версии.
Переход от предыдущей версии к последующей производится путем установки обновления, поставляемого производителем ONTARIO1. Обновление поставляется в виде сжатого файла архива с названием sNNupMMM, где NN-номер глобальной версии продукта, а MMM-номер текущего обновления. Например, файл с названием s1up233 будет содержать обновление 233 системы версии 1.
В архив входят следующие файлы:
Каталог\файл | Описание |
SERVER\up???.osm | Файл обновления серверной части системы, где ???-номер обновления |
CLIENT\*.* | Исполняемые файлы клиентского приложения |
\readme.txt | Текстовый файл с дополнительной информацией |
Файл обновления серверной части устанавливается стандартным способом при помощи утилиты DBSetup.exe, входящей в поставку системы, как это было описано в разделе "Создание базы данных". При этом необходимо убедиться, что в системе установлено обновление предыдущей версии. Для этого следует запустить отчет "Список установленных модулей и обновлений", находящийся в папке "Отчеты" системы.
Рис.4.2. Папка, содержащая отчет об установленных модулях и обновлениях
Рис.4.3. Пример результатов запуска отчета об установленных модулях и обновлениях
После установки обновления серверной части необходимо обновить исполняемые файлы клиентского приложения. Для этого следует скопировать файлы из каталога CLIENT\ в каталог на рабочей станции, куда было установлено приложение. По умолчанию, это каталог C:\Program Files\ONTARIO System 1.
Это операцию легко автоматизировать, используя сетевые средства Windows NT. Достаточно организовать на сервере каталог для обновлений файлов клиентского приложения и сделать его доступным ресурсом для пользователей с правами "только чтение". Затем следует создать командный файл, который будет выполняться при входе пользователя в сеть (см. настройки сценариев входа в сеть в документации по Windows NT Server). В этом файле необходимо производить копирование файлов обновления из общедоступного каталога сервера на рабочую станцию.
Процесс обновления версии системы считается завершенным, если отчет "Установленные модули и обновления" показывает установленное обновление, а версия клиентского приложения в окне "О программе" показывает версию, указанную в файле readme.txt, входящий в состав обновления.