Задачи администрирования баз данных

1.  Выбор и обоснование типа корпоративной СУБД

2.  Идентификация совместимости ОС н СУБД

3.  Определение ресурсов и сервисов необходимых для работы СУБД

4.  Обеспечение установки (миграции) СУБД на сервера и рабочие станции

5.  Обеспечение стабильной работы СУБД

6.  Обеспечение доступа к данным

7.  Разграничение прав доступа к данным

8. Обеспечение логической и физической целостности данных в базе

9.  Защита, резервное копирование, репликация и миграция данных

10.Выполнение «ремонтных» работ на базе данных
11. Стандартизация процедур доступа к данным

12.Разработка, внедрение и сопровождение фискального доступа к данным

13.Разработка, внедрение и сопровождение системы «откатов»

-------------------не из учебника, но точно помню, что он об этом говорил-------------------

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

1. Проверка активности СУБД

2. Просмотр регистрационных файлов СУБД

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

Пояснения:

(1) Проверить, активны ли ваши подведомственные БД (если их несколько). В Unix-команда ps  - состояние одного из обязательных фоновых процессов. Например, процесса PMON. Более универсальным является подключение с помощью SQL*Plus к каждой из СУБД, что должны иметься, от имени SYS и выдача чего-то вроде SELECT status FROM v$instance. Правильный ответ - 'OPEN'. Такую проверку удобно автоматизировать средствами ОС или Oracle Enterprise Manager. (В командном файле для Windows после обращения к SQL*Plus можно сделать проверку if {%ERRORLEVEL%} == {0} (…)).

(2) Для этого нужно:

-Подключиться по очереди ко всем машинам, на которых работают ваши СУБД.

-На каждой проверить последние файлы в каталогах bdump сброса журнальной (регистрационной) информации фоновых процессов СУБД. В первую очередь нужно просмотреть хвосты файлов с именами alert_SID.log или SIDalrt.log (в разных ОС названия могут варьироваться). Там могут возникнуть сообщения об ошибках с префиксом ORA. Разумное организационное решение: тексты этих ошибок можно перенести в специально созданный для этого файл, в котором администратор протоколировал бы сведения о возникающих с БД проблемах и собственные действия по восстановлению данных.
· Проверить успешность выполнения резервирования БД, если такое выполнение такого резервирования поставлено на регулярную основу (а это должно быть так!) например, прошел ли благополучно сброс архивов на магнитную ленту.

(3)

1. Убедиться в достаточности свободного места в табличных пространствах (ТП).

2. Проверить состояние сегментов отката (rollback segments). Обычное состояние сегментов отката - ONLINE. Это состояние, размеры и прочую статистику сегментов можно почерпнуть из таблиц словаря-справочника; в версиях 8 и 7 это DBA_ROLLBACK_SEGS и V$ROLLSTAT.

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

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

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

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

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

4. Просмотр сигнальной информации в журнальных файлах Oracle Net

Пояснения:

(1) Идея здесь проста. Будет правильно, если для своих рабочих баз вы сформулируете политику формирования имен, атрибутов хранения (storage), первичных ключей и прочего для объектов, создаваемых в БД. Так, в соответствии с этой политикой вы бы могли обязать, к примеру, все таблицы иметь суррогатные (искусственные) ключи (и, соответственно, правила формирования значений ключей); справочным таблицам могли бы вменить параметр блока PCTFREE = 0; индексы могли бы обязать храниться в отдельных ТП и так далее. Это организационные правила, напрямую не контролируемые СУБД, и поэтому их нарушения, возникающие по мере создания и изменения объектов, нужно выявлять самостоятельно.

(2)

1. При интенсивном использовании БД в хранимых объектах могут изредка возникать внутренние разрушения структуры. Лучше не дожидаться, пока эти внутренние разрушения проявятся при работе прикладной системы и обнаруживать их заранее. Например, для таблицы можно использовать команду ANALYZE TABLE emp VALIDATE STRUCTURE. Испорченный индекс можно восстановить командой ALTER INDEX REBUILD ONLINE.

2. Другие объекты могут быть не испорченными, но оказаться в нерабочем состоянии (например, после импорта). Это может касаться хранимых подпрограмм, триггеров и выводимых таблиц. Посмотреть их фактическое состояние можно в таблицах словаря-справочника, например в поле USER_OBJECTS.STATUS (должно быть 'VALID').

(3)

--Если в БД включен аудит, нужно выявить попытки перейти за рамки дозволенного по данным аудита. Если для компенсации отсутствующих в системных средствах аудита в Oracle возможностей (например, аудита изменения отдельных строк таблицы) у вас используется сбор информации в собственные журнальные таблицы (с помощью триггеров) нужно просмотреть их. Начиная с версии 9 стал реально работоспособен LogMiner, дающий возможность наблюдать все действия в БД по изменению данных, но нужно помнить, что без включенного в СУБД режима архивации его ценность невелика.

--Если у БД несколько хозяев, не мешает устроить проверку простых паролей, например system/manager или ctxsys/ctxsys.

--С той же целью полезно устроить очередную ревизию наличия у пользователей потенциально опасных прав (типа SELECT ANY TABLE) и ролей (типа EXP_FULL_DATABASE).

(4) Эти файлы позволяют проследить клиентские соединения с СУБД. Если вы не задавали иного в файле SQLNET.ORA, то места их нахождения - в каталогах %ORACLE_HOME%\network\log и %ORACLE_HOME%\network\trace. К сожалению, файлы могут быть очень объемны и неудобны для чтения, но зато они весьма подробны.

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

1. Рассмотреть возможность подстройки SGA

2. Попытаться найти и устранить проблемы ввода/вывода

3. Определить неблагоприятные тенденции производительности СУБД и предложить решения

Пояснения:

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

(2) Примерно то же со вводом/выводом. Например, увеличение со временем интенсивности изменений в БД может сделать разумным перенос файлов с сегментами отката на другие диски.

(3) Основанием для принятия таких решений могут послужить наблюдения за использованием СУБД процессора, оперативной памяти и сетевых соединений, сделанные как средствами Oracle, так и ОС.

Друзья! Приглашаем вас к обсуждению. Если у вас есть своё мнение, напишите нам в комментарии.