Контрольный перечень задач администратора базы данных DB2 для платформ Linux, UNIX и Windows

Чтобы база данных исправно работала, необходимо периодически ее проверять. В этой статье содержится контрольный перечень задач по мониторингу базы данных DB2® для платформ Linux®, UNIX® и Windows®. Узнайте, какие задачи следует выполнять ежедневно, еженедельно и ежемесячно. Материал обновлен для версии DB2 9.

Дуэйн Сноу, старший менеджер по продуктам DB2, IBM

Дуэйн Сноу (Dwaine R. Snow) – старший менеджер по продуктам DB2 Data Server. Он помогает определить направление развития данного продукта и решает, какие функциональные возможности необходимо добавить, чтобы он соответствовал требованиям пользователей. До этого Дуэйн несколько лет работал в IBM в должности консультанта по эксплуатации DB2. В его задачи входили поддержка баз данных DB2 на рабочих местах и настройка производительности, планирование приложений, проектов и схем работы, разработка больших комплексных систем OLTP, систем поддержки принятия решений, баз данных и приложений, а также интеграция систем клиент/сервер и унаследованных систем. Дуэйн является автором и соавтором множества статей и книг по DB2, включая The Advanced DBA Certification Guide and Reference for DB2 Universal Database for Linux, UNIX, and Windows и Understanding DB2: Learning Visually with Examples, и выступал на многих конференциях по всему миру.



22.10.2010

Введение

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

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


Наблюдение за системой

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


Инструментарий для мониторинга

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

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

Сбор системной информации

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

Инструменты Linux и UNIX

Для получения информации о загрузке центрального процессора, памяти, а также других ресурсов операционной системы в UNIX или Linux используется команда vmstat.

Команды vmstat и iostat имеют следующие параметры.

Параметр 1 – периодичность сбора системной информации в секундах.
Параметр 2 – количество необходимых попыток сбора системной информации.

Для запуска утилит vmstat и iostat и получения снимков состояния системы с периодичностью в 5 минут (300 секунд) на протяжении 8 часов (28800 секунд) выполните следующие команды:

vmstat 300 28800 > vmstat.out
iostat -tx 300 28800 > iostat.out

Примечание. Команда iostat имеет полезный параметр –tx, который сохраняет временную метку создания снимка состояния. Однако этот параметр поддерживается не во всех версиях UNIX/Linux.

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

Инструменты Windows

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

Рисунок 1. Диспетчер задач Windows
Рисунок 1. Диспетчер задач Windows

Инструменты DB2

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

  • Монитор работоспособности / Центр работоспособности
  • Мониторы снимков / Функции SQL-снимков
  • Мониторы событий

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

  • Журнал административных уведомлений
    • В системах Linux и UNIX этот журнал представляет собой отдельный файл, тогда как в ОС Windows он является частью журнала событий.
  • Файл DB2DIAG.LOG
  • Модуль Memory Visualizer

1. Монитор работоспособности

В восьмой версии DB2 были представлены два новых компонента, помогающих наблюдать за состоянием систем DB2: монитор работоспособности Health Monitor и центр работоспособности Health Center. В DB2 версии V9 эти инструменты функционируют по принципу управления по отклонениям, предупреждая о потенциальных проблемах, которые могут повлиять на стабильную работу системы. Это позволяет администратору БД обращать внимание на отклонения в работе системы, не дожидаясь возникновения реальных проблем.

Модуль Health Monitor запускается и работает на сервере DB2 и непрерывно следит за работоспособностью экземпляра и баз данных DB2. Если Health Monitor обнаруживает отклонение какого-либо параметра от предельно допустимого значения (например, объем свободного места для хранения log-файлов стал меньше заданного значения) или отклонение состояния какого-либо объекта от нормы (например, экземпляр DB2 остановился), он выдает предупреждающий сигнал.

При этом происходит следующее:

  • Посылается уведомление о поступившем сигнале.
    • Уведомление может быть доставлено на электронный адрес или пейджер
  • Выполняются заранее определенные действия.
    • Может быть выполнен сценарий процессора командной строки (CLP) или задача модуля Task Center.

Индикатор работоспособности (health indicator) – это характеристика системы, которую проверяет Health Monitor. Монитор работоспособности поставляется с набором предопределенных пороговых величин для индикаторов работоспособности. Он сравнивает параметры состояния системы с этими величинами и определяет, когда необходимо послать предупреждающий сигнал. Используя модуль Health Center, а также различные команды и программные интерфейсы, можно изменять пороговые значения этих индикаторов и определять, кто из администраторов должен получать уведомления, и какой сценарий или задачу необходимо выполнить при наступлении определенного события.

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

2. Мониторы снимков / Функции SQL-снимков

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

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

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

Управлять переключателями мониторов в рамках сеанса можно с помощью команды UPDATE MONITOR SWITCHES или с помощью API-функции sqlmon().

Например, чтобы включить мониторинг буферных пулов, блокировок и SQL-операторов, установите переключатели мониторов в состояние on с помощью следующей команды:

update monitor switches using bufferpool on lock on statement on

Примечание. Для обновления состояния переключателей мониторов или получения снимков состояния DB2 вы должны обладать полномочиями SYSADM, SYSCTRL, SYSMAINT или SYSMON (новая роль в DB2 9) .

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

  • Запуск в командной строке команды GET SNAPSHOT
  • Вызов табличных функций SQL-снимков
  • Использование центра управления Control Center
  • Написание собственного приложения, осуществляющего вызов API-функции sqlmonss().

3. Мониторы событий

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

  • Подключение к базе данных или отключение от нее
  • Взаимоблокировка или таймаут блокировки
  • Выполнение оператора
  • Начало или завершение транзакции

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

Мониторы событий создаются с помощью оператора CREATE EVENT MONITOR и собирают информацию только тогда, когда находятся в активном состоянии. Активация и деактивация мониторов выполняется с помощью оператора SET EVENT MONITOR STATE. Функция EVENT_MON_STATE возвращает текущее состояние указанного монитора событий.

При выполнении оператора CREATE EVENT MONITOR создается определение монитора событий, которое хранится в следующих таблицах системного каталога:

  • SYSCAT.EVENTMONITORS: мониторы событий, определенные для базы данных.
  • SYSCAT.EVENTS: типы событий, мониторинг которых выполняется в базе данных.
  • SYSCAT.EVENTTABLES: имена целевых таблиц для табличных мониторов событий.

Инструменты операционной системы

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


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

Проверка рабочего состояния всех экземпляров

Выполнить такую проверку можно несколькими способами:

  1. Использовать центр работоспособности Health Center.
  2. Экспортировать или задать параметр DB2INSTANCE=имя_экземпляра
    • и выполнить команду db2start.
  3. Подключиться ко всем экземплярам.
  4. В системах UNIX или Linux выполнить команду ps -ef | grep db2sysc
    • Убедиться, что для каждого экземпляра выполняется по одному процессу db2sysc.
  5. В операционной системе Windows проверить, что для каждого экземпляра DB2 запущена соответствующая ему служба.

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

Перед использованием команды ps в системах UNIX и Linux сначала нужно подключиться к каждому серверу по протоколу telnet.

Проверка согласованности всех баз данных

Определение согласованности может оказаться непростым делом, а способ предоставления этой информации командой GET DB CFG часто приводит к возникновению вопросов.

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

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

Поиск новых записей в журнале Administration Notification Log и в файле DB2DIAG.LOG

Важно убедиться в том, что за прошедшую ночь в работе базы данных не возникло никаких проблем. Начиная с версии V8, DB2 записывает диагностические сообщения в два места: в журнал Administration Notification Log (сообщения для администраторов баз данных) и в файл DB2DIAG.LOG (сообщения для группы обслуживания DB2).

В операционной системе Windows диагностические сообщения записываются в журнал Application Event Log, который можно просмотреть через оснастку Event Viewer. Для этого нужно перейти в раздел Application log и найти все события, записанные приложением с именем DB2.

Рисунок 2. Просмотр событий Windows
Рисунок 2. Просмотр событий Windows

В системах Linux и UNIX журнал диагностики хранится в файле <ID_экземпляра>.nfy, расположенном в директории, которая указана в конфигурационном параметре DIAGPATH. Чтобы просмотреть этот файл, необходимо выполнить следующие действия:

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

Проверка успешности создания ежедневной резервной копии

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

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

list history backup all for имя_бд

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

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

Проверка успешности архивации журналов базы данных

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

Хотя архивация и проверка log-файлов необходимы преимущественно для восстановления базы данных, существует еще одна важная причина. Если журналы не архивируются, они остаются в директории LOGPATH. Обычно директория LOGPATH располагается в файловой системе фиксированного размера, и если не выполнять архивацию журналов, вновь создаваемые log-файлы могут заполнить файловую систему. Если такое произойдет, DB2 не сможет создавать дополнительные журналы и будет остановлена.

При вызове userexit-процедуры для архивации log-файлов информация записывается в два места. Первое из них – это журнал аудита userexit, в который для каждого запроса на архивацию вносится соответствующая запись. В случае возникновения ошибки в процессе работы userexit-процедуры сообщение о ней также будет занесено в журнал ошибок userexit. Эти журналы располагаются в директории LOGPATH и называются ARCHIVE.LOG и USEREXIT.ERR соответственно.

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

Проверка неизменности конфигурационных параметров базы данных и менеджера БД

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

get dbm cfg 
get db cfg for имя_бд

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

diff DB_DBM_CFG.07142006.out DB_DBM_CFG.07152006.out

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

<  Degree of parallelism                      (DFT_DEGREE) = 1
---
>  Degree of parallelism                      (DFT_DEGREE) = 4

Проверка наиболее важных показателей производительности

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

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

select substr(bp_name,1,20) as BP_NAME, 
int (( 1 - (decimal(pool_data_p_reads) / nullif(pool_data_l_reads,0)  )) * 100)
	as data_hit_ratio,
int (( 1 - (decimal(pool_index_p_reads) / nullif(pool_index_l_reads,0)  )) * 100)
	as index_hit_ratio,
int (( 1 - (decimal(pool_data_p_reads + pool_index_p_reads) / 
	nullif( (pool_data_l_reads + pool_index_l_reads),0) )) * 100)  as BP_hit_ratio,
int (( 1 - (decimal(pool_async_data_reads + pool_async_index_reads) / 
nullif( (pool_async_data_reads + pool_async_index_reads + direct_reads),0) )) * 100)
	as Async_read_pct,
int (( 1 - (decimal(direct_writes) / nullif(direct_reads,0) ))  * 100)  as Direct_RW_Ratio
	from table (snapshot_bp ('sample', -1) ) as snapshot_bp ;

Примечание. В вышеприведенном запросе функция nullif используется для возврата значения null, если число в скобках (т. е. pool_data_l_reads or pool_index_l_reads) равно нулю (0). В противном случае было бы выполнено деление на ноль, и запрос завершился бы с ошибкой.

Проверьте паттерны использования для таблиц базы данных с помощью следующего запроса.

select 
      substr(table_schema,1,8) as Schema,
      substr(table_name,1,30) as Table_Name,
      rows_read,
      rows_written, 
      overflow_accesses
from table (snapshot_table ('sample', -1) ) as snapshot_table;

Проверьте паттерны общего использования базы данных с помощью следующего запроса. В результате выполняются следующие проверки:

  • Количество прочитанных строк по сравнению с количеством выбранных строк
  • Число произошедших ожиданий блокировок, общее и среднее время ожидания блокировок
  • Количество обнаруженных взаимоблокировок и эскалаций блокировок
  • Число выполненных сортировок, общее и среднее время сортировок, процент сортировок с переполнением
select
   db_name,
   SNAPSHOT_TIMESTAMP,
   rows_read,
   rows_selected,
   lock_waits, 
   lock_wait_time,
   lock_wait_time/nullif(lock_waits,0) as avg_wt_time,
   deadlocks,
   lock_escals,
   total_sorts,
   total_sort_time,
   total_sort_time/nullif(total_sorts,0) as avg_sort_time,
   sort_overflows,
   sort_overflows/nullif(total_sorts,0) as pct_ovflow_sorts
   from table (snapshot_database (' ', -1) ) as snapshot_database;

Проверка автоматических выполненных действий DB2

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

Вы можете отслеживать изменения в распределении табличного пространства с помощью команды list tablespaces show detail. Изменения, производимые самонастраивающимся менеджером памяти, записываются в файлы с именами stmm.#.log, которые хранятся в директории stmmlog. Эта директория является дочерней по отношению к директории SQLLIB владельца экземпляра в системах Linux и UNIX и по отношению к директории SQLLIBInstance в операционной системе Windows.

Проверка наличия достаточного количества свободной памяти

Важным моментом является использование оперативной памяти системой DB2, а также самим сервером. В операционной системе Windows вы можете определить объем установленного ОЗУ с помощью оснастки My Computer, последовательно выбрав меню Help и About Windows.

В системах UNIX и Linux объем установленного в системе ОЗУ, а также текущую загрузку памяти можно определить при помощи команды free. В следующем примере видно, что на сервере установлено 1 ГБ физической памяти, из которых примерно 717 МБ используется работающими приложениями.

           total         used       free     shared    buffers     cached
Mem:       1036248     717240     319008          0      60200     430736
-/+ buffers/cache:     226304     809944
Swap:      1048784          0    1048784

Изучение DB2

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

Новостная группа comp.databases.ibm-db2 – это отличное место, в котором можно многому научиться, а также поделиться информацией с коллегами-администраторами БД.

Для получения более подробной информации также стоит ознакомиться с серией руководств DB2 Certification Guide, поскольку эти книги содержат большое количество ценной информации.


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

Проверка наличия новых объектов

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

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

Существует два способа проверки наличия новых объектов в системе:

  1. Еженедельный запуск утилиты db2look и создание на основе полученной информации файлов отчетов.
    • Сравнение файлов отчетов, созданных в разное время.
  2. Создание выборки имен объектов из SYSCAT.TABLES, SYSCAT.INDEXES, SYSCAT.PROCEDURES
    • Сравнение результатов выборок, полученных в разное время.

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

Проверка наличия новых или изменившихся приложений

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

Для поиска новых приложений можно использовать команду list applications show detail. Перенаправляя вывод этой команды в файлы и сохраняя их, впоследствии можно регулярно выполнять сравнение и смотреть, не появилось ли в списке новое приложение.

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

create table SQLstmts 
   (stmt varchar(200), 
    tstamp timestamp not null with default)

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

insert into SQlstmts (stmt) 
   select substr(stmt_text,1,200) as SQL_Stmt 
   from table (snapshot_dyn_sql ('sample', -1) ) 
   as snapshot_dyn_sql

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

select distinct stmt, 
   count(stmt),
   tstamp from sqlstmts 
   group by stmt, 
   tstamp

В полученном списке любой оператор со значением поля count(stmt) равным 1, и столбцом, содержащим текущую дату, будет являться оператором, который не выполнялся ранее.

Проверка наличия таблиц и индексов, требующих реорганизации

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

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

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

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

reorgchk update statistics on table user

Вывод этой команды следует перенаправить в файл с целью дальнейшего анализа.

Когда вы будете просматривать полученный вывод утилиты, найдите столбцы F1, F2 и F3, относящиеся к таблицам, и столбцы F4, F5, F6, F7 и F8, относящиеся к индексам. Если в каком-либо из этих столбцов присутствует знак звездочки (*), это означает, что параметры текущей таблицы или индекса в настоящий момент выходят за допустимые границы.

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

Утилита reorgchk вычисляет следующие значения:

F1: процент строк переполнения. Если значение этого параметра составляет более 5%, в столбце F1 будет отображен знак звездочки (*).

F2: процент используемого пространства, выделенного для страниц данных. Если значение этого параметра составляет менее 70%, в столбце F2 будет отображен знак звездочки (*).

F3: процент страниц с непустыми записями. Если значение этого параметра составляет менее 80%, в столбце F3 будет отображен знак звездочки (*).

F4: коэффициент кластеризации, т. е. процент строк в таблице, порядок расположения которых совпадает с порядком расположения в индексе. Если значение этого параметра составляет менее 80%, в столбце F4 будет отображен знак звездочки (*).

F5: процент свободного пространства на каждой индексной странице, предназначенного для хранения индексных ключей. Если значение этого параметра составляет менее 50%, в столбце F5 будет отображен знак звездочки (*).

F6: количество ключей, которые можно хранить на каждом уровне индекса. Если значение этого параметра составляет менее 100, в столбце F6 будет отображен знак звездочки (*).

F7: процент идентификаторов записей (record ID) на странице, помеченных как удаленные. Если значение этого параметра составляет более 20%, в столбце F7 будет отображен знак звездочки (*).

F8: процент пустых концевых страниц в индексе. Если значение этого параметра составляет более 20%, в столбце F8 будет отображен знак звездочки (*).

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

reorg table org index orgx

Чтобы выбирать оптимальные планы доступа для SQL-запросов, оптимизатор DB2 использует статистику базы данных. После каждого изменения большого объема данных или переупорядочивания данных в таблицах следует запускать утилиту runstats, чтобы обновить данные статистики и сохранить их в системных каталогах. Также не забывайте обновлять статистику каждый раз после создания новой таблицы или нового индекса.

Чтобы получить статистику для таблицы ORG и всех ее индексов, можно использовать следующую команду:

runstats on table <схема>.org with distribution and detailed indexes all

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

Проверка наличия таблиц и индексов, статистику которых необходимо обновить

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

select substr(name,1,30),substr(creator,1,10),stats_time 
   from sysibm.systables 
   where stats_time < ((current timestamp) - 7 days) 
   or stats_time is null

select substr(name,1,30),substr(creator,1,10),stats_time 
   from sysibm.sysindexes 
   where stats_time < ((current timestamp) - 7 days) 
   or stats_time is null

Поиск 10 наиболее активно используемых таблиц

При рассмотрении необходимости выполнения процедур reorg или runstats также следует выяснить, какие таблицы используются наиболее активно (этот критерий основан на количестве прочитанных строк). Для поиска 10 наиболее активно используемых таблиц выполните следующий запрос:

select substr(table_schema,1,10) as tbschema, 
   substr(table_name,1,30) as tbname, 
   rows_read,
   rows_written,
   overflow_accesses,
   page_reorgs 
   from table (SNAPSHOT_TABLE(' ',-1)) as snapshot_table
   order by rows_read desc
   fetch first 10 rows only

Чтобы найти 10 наиболее часто обновляемых таблиц (на основании записанных строк), выполните следующий запрос:

select substr(table_schema,1,10) as tbschema, 
   substr(table_name,1,30) as tbname, 
   rows_read,
   rows_written,
   overflow_accesses,
   page_reorgs 
   from table (SNAPSHOT_TABLE(' ',-1)) as snapshot_table
   order by rows_written desc
   fetch first 10 rows only

Найденные таблицы являются наиболее подходящими кандидатурами для выполнения процедур reorg и runstats, или, по крайней мере, runstats.

Архивация всех журналов оповещений и файлов DB2DIAG.LOG

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

В операционной системе Windows журнал событий можно экспортировать в файл с помощью оснастки Event Viewer, выбрав в меню Action команду Save Log File As. После этого можно очистить журнал событий, выбрав в меню Action команду Clear All Events.

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

Точно так же можно поступить и с файлом DB2DIAG.LOG в системах Linux и UNIX – заархивировать его и назвать по дате создания.

В системах Linux и UNIX можно поместить все файлы*.nfy и файл db2diag.log в один контейнер с помощью команды tar, а затем заархивировать его с помощью команды gzip или compress.

Проверка обновлений программного обеспечения

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

Одним из самых важных web-ресурсов, посвященных СУБД DB2, является страница технической поддержки DB2 для платформ Linux, UNIX и Windows:

http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2w/WINV8FP

Чтобы своевременно получать информацию о выходе новых пакетов исправлений DB2, можно подписаться на рассылку уведомлений на web-сайте:

http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/db2alert.d2w/report


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

Выявление признаков чрезмерного роста

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

Чтобы узнать размер табличного пространства, а также объем доступного пространства, выполните следующий оператор:

select substr(tablespace_name,1,120) as TBSPC_NAME, 
   used_pages, 
   free_pages,
   from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg

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

select tabname, 
   npages 
   from syscat.tables 
   where tabname not like 'SYS%'

Примечание. В случае отсутствия статистики для таблицы поле npages будет иметь значение -1.

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

Планирование производственных мощностей в соответствии с ожидаемым ростом БД

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

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

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


Приложение 1. Сценарий для получения информации о табличном пространстве

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

create table TablespaceInfo( 
timestmp timestamp, 
tablespace_name char(128), 
pct_free int,   	 	 
-- Процент свободного места в табличном пространстве
type char(5),    		 
-- SMS или DMS 
contents char(5), 
total_pages int, 		 
-- общее количество страниц
usable_pages int,		 
-- пригодные для использования страницы 
used_pages int,	 		 
-- количество использованных страниц
free_pages int,			 
-- количество свободных страниц
page_size int);			 
-- размер страницы

-- Добавление информации снимка состояния в таблицу tablespaceinfo для последующего ее анализа.

insert into tablespaceinfo 
select  
current timestamp, 
substr(tablespace_name,1,120) as TBSPC_NAME,  
(case   
-- Мы может подсчитать процент свободного места только для табличных пространств DMS,
-- поскольку для табличных пространств SMS этот оператор установит значение переменной
-- total_pages в 0. Поэтому проверяем, является ли табличное пространство
-- DMS-пространством, а затем вычисляем переменную pct_free как 1-
(used/total) * 100% 	
when tablespace_type = 0 then (int( (1- (decimal(used_pages) / 
decimal(total_pages))) * 100) ) 
-- Для табличных пространств SMS устанавливаем переменную pct_free в 100...
-- Можно присвоить ей любое числовое значение
else 100 
end) as pct_free, 
(case 
-- Отобразим тип табличного пространства (т. е. DMS или SMS) в виде строки
value in the info. 	
when tablespace_type = 0  then 'DMS' 	
when tablespace_type = 1  then 'SMS' 
-- ДОПУСТИМЫ только значения 0 и 1, поэтому в остальных случаях возвращаем ошибку
else	'Error' 
end) as Managed_By, 
(case 
-- Display the type of data that can stored in the table space, i.e. TEMP, 
LARGE/LOB OR ALL,     
not the numeric value in the info. 
-- Отобразим тип данных, хранимых в табличном пространстве,
-- т. е. TEMP, LARGE/LOB или ALL, в виде строки
when tbs_contents_type = 2 then 'TEMP' 	
when tbs_contents_type = 1 then 'LARGE' 	
when tbs_contents_type = 0 then 'ALL' end) as Data_Type, 
-- Возвратим также переменную total_pages, используя заголовок ALLOCATED PAGES
total_pages as allocated_pages,  
usable_pages, 
used_pages,  
free_pages, 
page_size 
from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg  
order by pct_free;  
select tablespace_name,  	
date(timestmp) as dte,  	
pct_free 
from tablespaceinfo  	
group by tablespace_name, pct_free, timestmp ;

Приложение 2. Сценарий для получения информации о контейнерах табличного пространства

-- Отчет о контейнерах каждого табличного пространства, их размере и типе

-- Группировка контейнеров выполняется по полю tablespace_name,
-- поскольку в результирующем отчете их имена будут уникальными

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

select  
substr(tablespace_name,1,12) as TBSPC_Name, 
substr(Container_name,1,67) as Cont_Name, 
(case 	
when container_type = 0 then 'SMS Directory' 	
when container_type = 6 then 'DMS File' 	
else 'DMS Device' 
end) as Container_Type, 
usable_pages 
from table (snapshot_container (' ', -1) ) as snapshot_container;

Приложение 3. Получение информации о буферных пулах и табличных пространствах

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

select substr(b.bpname,1,12) as BufferPool,  
b.npages as BP_Pages, 
substr(t.tbspace,1,12) as TableSpace, 
usable_pages as TBSPC_Pages 
from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg , 
syscat.tablespaces t, syscat.bufferpools b 
where t.bufferpoolid = b.bufferpoolid 
and t.tbspace = tablespace_name 
group by b.bpname,  t.tbspace, usable_pages, npages;

Ресурсы

Научиться

Получить продукты и технологии

  • Загрузите бесплатную пробную версию DB2 Enterprise 9.
  • Теперь вы можете использовать DB2 бесплатно. Загрузите DB2 Express-C – версию сервера баз данных DB2 Express, которая содержит весь основной функционал версии DB2 Express Edtion и является хорошей основой для разработки и развертывания приложений.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=555878
ArticleTitle=Контрольный перечень задач администратора базы данных DB2 для платформ Linux, UNIX и Windows
publish-date=10222010