Ежедневные задачи:

• проверка активности СУБД;

• просмотр регистрационных файлов СУБД и протокола ее работы;

• выявление нежелательных тенденций роста объектов в БД.

Еженедельные задачи:

• выявление объектов БД, нарушающих принятые соглашения хранения;

• выявление некорректных с точки зрения СУБД или неработоспособных объектов БД;

• выявление реальных и возможных нарушений прав доступа;

• просмотр сигнальной информации в журнальных файлах.

Ежемесячные задачи:

• рассмотрение возможностей настройки БД (размеры буфера данных, буфера журнала БД и shared pool, др.);

• поиск и устранение проблем ввода/вывода;

• определение неблагоприятных тенденций производительности СУБД и подготовка предложений по решениям.

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

• приоритеты отдельных направлений развития системы;

• сроки создания новых или расширяющихся БД;

• ограничения по техническим и трудовым ресурсам;

• обязательства перед другими организациями;

• перспективные планы развития системы;

• возможные изменения структуры организации.

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

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

Повышение надежности работы БД

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

Чтобы не потерять данные АБД должен выполнять следующие рекомендации [5, 6]:

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

• используйте диски для однократной записи, применяемые форматы данных не будут иметь никакого значения, если физические носители, на которых они записаны, станут нечитаемыми или если технические компании перестанут поддерживать устройства, способные их читать, поэтому применяйте наиболее распространенные дисководы - CD и DVD;

• применяйте диски CD-R или DVD+R и воздержитесь от RW-носителей, R-диски стабильнее, чем RW;

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

• храните носители (оптические диски) в прохладном сухом месте подальше от прямых солнечных лучей;

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

Для структурированных данных используйте формат ASCII; для изображений - файлы с расширением .bmp, .tif и .jpg; текстов.txt,.doc, .html. Если изображение еще не переведено в формат .jpg, то лучше хранить его в несжатом tif-файле, так как это позволит сберечь больше деталей. Для реактора типа Word, используйте шрифт Times New Ruman. Для структурированных файлов очень важен и формат логического хранения данных. Во многих отраслях имеются стандарты на форматы хранения (для библиографии, финансовых документов, научных данных - NetCdf, описания персоны, проектов, др.). В связи с широким применением языка XML появились стандарты для новостной информации – RSS, описания интернет-ресурсов – Dublin Core, др.

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

• затраты на восстановление информации;

• затраты на восстановление работоспособности системы;

• ущерб, нанесенный имиджу компании;

• убытки от невосполнимых потерь информации.

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

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

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

• рассмотреть возможные последствия чрезвычайных ситуаций;

• определить, какие данные требуют частого создания резервных копий;

• определить целевую точку и время восстановления для каждого класса данных;

• определить, какие данные требуют репликации (удаленной или локальной) для обеспечения непрерывности бизнеса при чрезвычайных ситуациях или быстрого восстановления;

• планируя архитектуру, определить расстояние до альтернативных узлов и учесть факторы, влияющие на восстановление (извлечение данных с использованием сети или транспортировка лент с резервными копиями);

• определить основных участников процесса восстановления;

• при создании архивов на ленте, во вторичном хранилище или ассоциативных хранилищах данных необходимо позаботиться о их защите;

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

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

Резервное копирование и восстановление данных должно включать:

• соглашение об уровне обслуживания в части бесперебойного доступа к информации;

• периодичность резервного копирования, графики и автономный/оперативный доступ ко всем типам информации, классифицированным по значимости;

• определение целевой точки и целевого времени восстановления в совокупности с планом сохранения непрерывности бизнеса и восстановления в аварийной ситуации;

• графики сохранения данных на удаленной площадке;

• репликация данных на диске, определение необходимого количества копий;

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

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

• инструкции, определяющие, какая информация сохраняется и зачем;

• безопасность копий данных (физическая и логическая);

• правила для процедур сохранения и архивирования данных — как долго и на каких носителях хранится информация, каково время доступа и какие данные переносятся из первичной памяти во вторичную и почему;

• как защищается первичная, вторичная память, на каких носителях и с какой периодичностью;

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

• контрольные записи, подтверждающие надлежащее выполнение правил и процедур, следование стратегии.

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

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

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

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

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

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

Таблица 3 - Сравнительные характеристики систем хранения данных [CNews Analyticsъ

Характеристика	NAS (Network Attached Storage) – сетевая система хранения данных	SAS / DAS (Server Attached Storage/Direct Attach Storage), система хранения, подключенная к серверу	SAN (Storage Area Network), cеть хранения данных	TSM (Tivoli Storage Manager)
Протоколы передачи данных	CIFS, HTTP, NFS, FTP	SCSI, SSA	SCSI
Скорость передачи	не менее 100 МБ/с на один порт	несколько сот МБ/с	до 1 Гб/с на один порт
Сетевые протоколы	TCP/IP через Ethernet, FDDI, ATM, Gigabit Ethernet	SCSI-интерфейс сервера, сетевой протокол неприемлем	Fibre Channel, Gigabit Ethernet
Масштабирование	Качественное, но снижает пропускную способность сети	Ограничено количеством подключаемых устройств и производительностью единственного сервера	Самое эффективное
Миграция данных	Используются способы резервирования/ восстановления	Снижает производительность сервера	Обеспечивается построение систем хранения высокой готовности с возможностью дублирования в реальном времени	функция дедубликации, восстановление отдельных почтовых ящиков Microsoft Exchange и элементов каталога Active Directory

В чем нуждается администратор БД?

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

1) средства профилактического мониторинга, которые избавляют администратора от экстренных мер, разгружают администратора по вечерам и выходным, ускоряют приобретение опыта;

2) средства диагностики, позволяющие сконцентрироваться на других задачах;

3) средства анализа, помогающие при планировании роста БД и будущих затрат;

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

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

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

Базовые параметры - это набор параметров, отображающих поведение сервера и приложения в обычных условиях. Базовые параметры получаются как средние по результатам нескольких замеров, выполненных в одинаковых условиях; они являются ориентирами для сравнения, табл.4.

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

Таблица 4 - Метрики для определения базовых параметров

Объект и счетчик	Описание
Память (страниц/с)	Число страниц чтения или записи на диск в секунду. Этот счетчик - первичный индикатор типов ошибок, вызванных системными задержками или проблемами с производительностью
Трафик (бит/с)	Число бит, проходящих по сетевому интерфейсу в секунду
Скорость обмена между RAM и дисками (бит/с)	Оценка дисковых операций чтения/записи.
Загрузка процессора	Процентное соотношение времени, которое процессор тратит выполнение рабочего потока.
Рост файла транзакций	На сколько, для конкретной базы данных, вырос файл транзакций.
Процент записи файлов журналов	Процентное отношение свободного места в журнальном файле.
Макс число транзакций в очереди	Наблюдайте за тем, когда транзакции начинают выстраиваться в очередь, это указывает на то, что дисковый ввод/вывод может быть медленным
Число пользовательских подключений к серверу БД	Они могут указывать на сетевые проблемы и свидетельствовать о нагрузках и замедлении

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

Ранжировать инциденты нужно в зависимости от степени воздействия и критичности. Степень воздействия определяется убытками, возникшими из-за возникшего инцидента. Критичность является характеристикой качества исполнения бизнес-процессов. Например, в [2] предлагается 4 уровня критичности инцидентов, табл.5: максимально критично, критично, условно критично и не критично. Под устранением инцидента понимается предоставление "временного решения", которое позволит восстановить нормальное функционирование бизнеса.

Таблица 5 - Уровни критичности инцидентов (Источник: CBOSS, 2009)

Уровень	Описание
Максимально критично	Произошла остановка работы одного или нескольких основных бизнес-процессов компании. На момент обращения проблема влечет прямые финансовые потери для клиента. Решение требуется незамедлительно.
Критично	Проблемы, наличие которых представляет угрозу остановки работы основных бизнес-процессов компании, потенциально может повлечь финансовые потери либо нанести урон имиджу клиента.
Условно критично	Проблемы, решение которых необходимо компании в определенные сроки или к обозначенной дате (требуется подготовка отчетной документации)
Не критично	Проблемы, которые не приводят к остановке работы основных технологических процессов, их решение может быть отложено на срок более одного месяца.

Рекомендации по защите БД

Рекомендации, которые помогут АБД защитить БД.

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

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

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

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

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

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

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

Применяйте заповеди начинающего АБД [1].

1. Правильно устанавливайте журнальные файлы. Журнальный файл должен быть в оперативном состоянии и доступен все время, пока база данных функционирует, в противном случае база данных обрушится. Настоятельно рекомендуется использовать несколько журнальных файлов. Определите размер журнальных файлов так, чтобы они переключались каждые 30-60 минут.

2. Создайте специальное табличное пространство для временных сегментов.

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

4. Установите размер буфера памяти для БД примерно в 25% от общего объема памяти, но установка должна учитывать и число пользователей.

5. Установите значение параметра совместно используемого объема примерно от 50% до 75% от принятого значения буфера памяти для БД. Распределите основные файлы данных (табличное пространство системы, табличное пространство для временных сегментов, табличное пространство для сегментов отката, журнальные файлы (файлы логов), диск операционной системы, файлы БД, содержащие интенсивно используемые таблицы, файлы БД, содержащие интенсивно используемые индексы) между несколькими дисками. Следует помнить, что операции ввода/вывода с индексами и записями журналов весьма различны. Это важно, когда журнальные файлы и индексы размещаются на одном и том же диске. Журнальные файлы записываются последовательно относительно большими порциями. Индексы читаются и пишутся произвольным образом. Помещение индексных файлов на то же самое устройство, что и журналов, может снизить скорость операций записей в журнал.

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

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

8. Регулярно проверяйте размер табличных пространств и наличие свободного пространства.

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

10. Исключите фрагментацию таблиц, когда таблицы состоят из нескольких экстентов (участков); фрагментация строк имеет место, когда записи в таблицах обновляются, и блоки, в которых они содержались, не имеют достаточно места, чтобы сохранить измененные записи. Эта проблема известна, как "сцепление блоков"; фрагментация словаря БД имеет место, когда расширяются таблицы словаря данных.

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

12. Используйте утилиту EXPLAIN вместо трассировки, чтобы не ждать пока выполнится запрос. Используйте трассировку (ТРАСЕ) только для многозапросных пакетных работ, чтобы определить, какой из запросов является медленным.

13. Перемещайте файлы данных для балансировки файловых операций ввода/вывода.

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

15. Разработайте планы резервирования и восстановления, которые включают, как создание резервного образа базы данных, экспорт, так и архивирование файлов.

Выводы

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

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

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

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

Список литературы

1. XX заповедей начинающего Администратора БД20 TipsfortheBeginnerDBA,byRichard.Niemiec, (Ричард Дж. Нимиц ) "SELECT",vol. 2,No4,July95Copyright1995 Международной группы пользователейOracle(IOUG-A).

2. Белкин К. На ошибках учимся // Издательство "Открытые системы". Журнал "Директор ИС",N7, 2005. http://www.osp.ru/cio/2005/07/051.htm

3. Давыд Кравченко. ИТ-штат компании: размер имеет значение // Cnews. [Электронный ресурс]. – Режим доступа: http://www.cnews.ru/reviews/articles/index.shtml?2006/04/26/200578, свободный. – Загл. с экрана.

4. Мартин Дж. Организация БД в вычислительных системах. - М.: Мир. 1980. с. 653

5. Храмцовская Н. Как хранить электронные документы? Советы эксперта. 10.04.08.[Электронный ресурс]. – Режим доступа: http://www.cnews.ru/reviews/index.shtml?2008/04/10/296523_4, свободный. – Загл. с экрана.

6. ГОСТ Р /ISO/TR 15801:2009 Системы электронного документооборота. Управление документацией. Информация, сохраняемая в электронном виде: Рекомендации по обеспечению достоверности и надёжности. - М.- Стандартинформ. 2011. – 64 с.

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

1.Что такое план управления данными?

2.Что должен включать план управления данными?