Автоматическое обслуживание таблиц в DB2 : Часть 2. Автоматическая реорганизация таблиц и индексов в DB2

Как же на самом деле работает auto reorg?

Автономные функции СУБД IBM® DB2® для платформ Linux®, UNIX® и Windows® снижают нагрузку на администратора базы данных и позволяют обеспечить максимальную производительность. В этой статье будет показано, как включить и настроить автоматическую реорганизацию, отслеживать ход этого процесса и выполнять поиск ошибок. Также в этой статье рассматривается процесс автоматической реорганизации, что поможет вам понять, как и когда система определяет, в каких случаях необходимо выполнить реорганизацию таблицы или индекса и какой тип реорганизации будет использован. В заключение приводится список лучших практик по использованию функции reorg. Эта статья является последней в серии из двух статей, в которых описывается обслуживание таблиц в DB2 при помощи автономных функций.

Иван Попиванов, разработчик программного обеспечения, WSO2 Inc

Иван Попиванов (Ivan Popivanov) – разработчик программного обеспечения в команде DB2 Optimizer и RUNSTATS, ранее работавший в команде Autonomic Computing, где являлся ведущим разработчиком Auto-Runstats. Имеет пятилетний опыт работы в IBM. До этого им в соавторстве написаны две статьи для конференций и несколько патентованных приложений. Иван имеет ученые степени в области вычислительной техники университета Торонто и университета Софии (Болгария).



Скотт Уокти, разработчик программного обеспечения, WSO2 Inc

Скотт Уокти (Scott Walkty) – разработчик программного обеспечения в команде DB2 Workload Management Team. До этого он на протяжении пяти лет работал в команде DB2 Tools Team, где являлся одним из разработчиков Automatic Table Reorganization. Скотт имеет ученую степень магистра в области вычислительной техники университета Манитоба.



Анжела Янг, разработчик программного обеспечения, WSO2 Inc

Анжела Янг (Angela Yang) – разработчик программного обеспечения в лаборатории IBM Toronto Lab. На протяжении последних трех лет она работала в нескольких областях разработки DB2, включая инструменты администрирования и runstats. В настоящее время Анжела работает в команде разработчиков DB2 Query Optimizer.



Бек Танг, разработчик программного обеспечения, WSO2 Inc

Бек Танг (Beck Tang) имеет шестилетний опыт работы в качестве члена IBM SAP Integration и Support Center в лаборатории IBM Toronto Lab. Сегодня в его задачи входят сертификационные испытания SAP NetWeaver в связке с IBM DB2 UDB, а также помощь заказчикам в анализе и устранении возникающих проблем. Бек Танг консультирует заказчиков, предоставляя индивидуальную поддержку крупным клиентам, работающим с SAP и DB2 UDB. Кроме того, он является сертифицированным специалистом по решениям DB2. Бек является соавтором книги "SAP Solutions on IBM DB2 UDB V8.2.2 Handbook" и документа "SAP/DB2 and High Availability on Sun Cluster 3.X". Вы можете связаться с ним по адресу электронной почты becktang@ca.ibm.com.



24.06.2009

Введение

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

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

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

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

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

Обратите внимание на то, что в этой статье в основном рассматривается автоматическая реорганизация в DB2 9. Различия автоматической реорганизации в DB2 9 и DB2 v.8.2 будут рассмотрены позже в этом разделе.

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


Включение и настройка автоматической реорганизации

Ключевыми этапами настройки автоматической реорганизации являются:

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

Включение и отключение автоматической реорганизации

Функция автоматической реорганизации включается или отключается с помощью параметра конфигурации базы данных AUTO_REORG, который является частью иерархической структуры параметров, отвечающих за автоматическое обслуживание базы данных. Эти параметры можно просмотреть с помощью команды GET DB CONFIG процессора командной строки (Command line processor, CLP), например, как показано в листинге 1.

Листинг 1. Вывод сведений о конфигурации базы данных
CONNECT TO <имя БД>
GET DB CONFIG
CONNECT RESET
...
Automatic maintenance                      (AUTO_MAINT) = ON
   Automatic database backup            (AUTO_DB_BACKUP) = OFF
   Automatic table maintenance          (AUTO_TBL_MAINT) = ON
     Automatic runstats                  (AUTO_RUNSTATS) = ON
     Automatic statistics profiling    (AUTO_STATS_PROF) = OFF
       Automatic profile updates         (AUTO_PROF_UPD) = OFF
     Automatic reorganization               (AUTO_REORG) = OFF

Данная иерархическая структура (показанная, начиная с нужного нам раздела параметров, выведенных в результате выполнения этой команды) позволяет администратору базы данных включать или отключать функции автоматического обслуживания таблиц выборочно или на групповой основе. Например, если параметр AUTO_MAINT установлен в OFF, то считается, что все остальные параметры автоматического обслуживания также имеют эффективное значение OFF независимо от их фактического значения. Точно также, если параметр AUTO_TBL_MAINT установлен в OFF, то считается, что параметры AUTO_RUNSTATS, AUTOSTATS_PROF, AUTO_PROF_UPD и AUTO_REORG имеют эффективное значение OFF.

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

Вы можете включить автоматическую реорганизацию, выполнив следующую команду (листинг 2).

Листинг 2. Включение автоматической реорганизации путем изменения конфигурации базы данных
CONNECT TO <имя БД>
UPDATE DB CONFIG USING AUTO_MAINT ON AUTO_TBL_MAINT ON AUTO_REORG ON
CONNECT RESET

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

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

Вы можете отключить автоматическую реорганизацию, выполнив следующую команду (листинг 3).

Листинг 3. Отключение автоматической реорганизации путем изменения конфигурации базы данных
CONNECT TO <имя БД>
UPDATE DB CONFIG USING AUTO_REORG OFF
CONNECT RESET

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

Для проверки того, включен ли параметр AUTO_REORG, используйте команду GET DB CONFIG в разделе каталога, как это было показано выше. Важно всегда проверять значения каждого из следующих параметров конфигурации: AUTO_MAINT, AUTO_TBL_MAINT и AUTO_REORG. Проверять значение только параметра AUTO_REORG недостаточно.

Настройка автоматической реорганизации

Работа автоматической реорганизации управляется через политику обслуживания. Эта политика определяет:

  • Автономный интервал обслуживания – временной интервал, во время которого автоматическая реорганизация будет выполнять автономную реорганизацию таблиц и индексов. Примечание: это единственная часть политики обслуживания, для которой не определено значение по умолчанию. Поскольку в рамках автономного интервала обслуживания таблицы будут переведены в автономный режим (во время фазы реорганизации REPLASE к таблицам не будет доступа на запись и чтение), то требования к расписанию этого интервала будут различными для каждого пользователя. Автономный интервал обслуживания должен быть определен для того, чтобы можно было использовать функцию автоматической реорганизации. Если этот интервал не определен и автоматическая реорганизация включена, каждая попытка DB2 выполнить автоматическую реорганизацию будет завершена с ошибкой. Уведомления об этих ошибках будут поступать через индикатор состояния автоматической реорганизации. Для получения детальной информации обратитесь к примеру 4 в разделе Снимки состояния и индикатор состояния реорганизации.
  • Набор таблиц, для которых будет выполняться автоматическая реорганизация. Эти таблицы могут быть ограничены по размеру или имени. По умолчанию автоматическая реорганизация выполняется для всех пользовательских таблиц независимо от их размера.
  • Ряд параметров, которые влияют на поведение реорганизации, когда она применяется к таблице (например, сохранять или перестраивать словари сжатия при выполнении реорганизации таблиц).
  • Интервал онлайнового обслуживания. В DB2 9 автоматическая реорганизация индексов может выполняться в онлайновом режиме (во время реорганизации разрешены запись и чтение индексов). Если настроена онлайновая автоматическая реорганизация индексов, то интервал онлайнового обслуживания – это временной интервал, в течение которого будет выполняться автоматическая реорганизация индексов.

Политику обслуживания можно обновить только с помощью графического интерфейса DB2 Control Center. Никаких других интерфейсов или инструментов командной строки для этого не существует.

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

Шаг 1. Запустите DB2 Control Center

Из командной строки DB2 выполните следующую команду:

db2cc

Шаг 2. Откройте мастер Configure automatic maintenance

Слева в главном окне Control Center раскройте дерево навигации и откройте каталог базы данных. Щелкните правой кнопкой мыши на базе данных, для которой вы настраиваете автоматическое обслуживание, и в контекстном меню выберите пункт Configure Automatic Maintenance, как показано на рисунке 1.

Рисунок 1. Запуск мастера настройки автоматического обслуживания из центра управления
Запуск мастера настройки автоматического обслуживания из центра управления

Шаг 3. Просмотр вводной страницы

На первой странице мастера содержится краткий обзор функций автоматического обслуживания. Для продолжения нажмите кнопку Next, расположенную внизу окна (рисунок 2).

Рисунок 2. Вводная страница мастера настройки автоматического обслуживания
Вводная страница мастера настройки автоматического обслуживания

Шаг 4. Настройки на странице выбора режима работы

Страница выбора режима работы позволяет вам продолжить настройку автоматического обслуживания или отключить эту функцию. Для продолжения настройки оставьте переключатель в положении Change automation settings и нажмите кнопку Next (рисунок 3). Обратите внимание, что отключение автоматического обслуживания просто обновит конфигурацию параметров базы данных, о которых говорилось в предыдущем разделе, установив их значения в OFF.

Рисунок 3. Страница выбора режима работы автоматического обслуживания
Страница выбора режима работы автоматического обслуживания

Шаг 5. Страница настройки автоматического обслуживания

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

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

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

Обратите внимание, что интервалы обслуживания используются для указания времени начала операций по автоматическому обслуживанию. Любая операция, выполнение которой выходит за границы интервала, будет продолжаться до своего завершения. Например, если задан интервал обслуживания с 19:00 до 5:00 для каждого рабочего дня, и реорганизация таблицы была запущена в 4:30, то этот процесс не будет остановлен при наступлении 5:00, а будет продолжаться до своего завершения.

По умолчанию для всех баз данных DB2 устанавливается онлайновый интервал в режиме 24x7 (т. е. круглосуточно – все часы всех дней), а автономный интервал не установлен (поскольку не существует расписания по умолчанию, которое подходило бы всем пользователям). Автономный интервал обслуживания ДОЛЖЕН быть определен для того, чтобы можно было использовать функцию автоматической реорганизации. Если этот интервал не определен и автоматическая реорганизация включена, каждая попытка DB2 выполнить автоматическую реорганизацию будет завершена с ошибкой. Уведомления об этих ошибках будут поступать через индикатор состояния автоматической реорганизации. Для получения детальной информации обратитесь к примеру 4 в разделе Снимки состояния и индикатор состояния реорганизации. Обратите внимание на то, что если вы настраиваете автоматическую реорганизацию индексов в онлайновом режиме, вам нужно изменить онлайновый интервал обслуживания таким образом, чтобы он не перекрывался с интервалом автономного обслуживания. Более подробно это будет рассмотрено в разделе Процесс автоматической реорганизации.

Для задания автономного интервала нажмите кнопку Change, расположенную рядом с описанием Online maintenance window (рисунок 4).

Рисунок 4. Страница задания расписания выполнения автоматического обслуживания
Страница задания расписания выполнения автоматического обслуживания

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

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

По завершении настройки интервала обслуживания закройте окно свойств и нажмите кнопку Next на странице настройки автоматического обслуживания.

Шаг 6. Обновление списка уведомлений

Страница списка уведомлений используется для создания списка адресов электронной почты тех пользователей, которые должны получать уведомления каждый раз, когда индикаторы состояния переходят в состояние тревоги. Монитор состояния содержит индикатор состояния db.tb_reorg_req, который переходит в состояние тревоги каждый раз, когда автоматическая реорганизация таблицы завершается с ошибкой (детально это будет обсуждаться в разделе Мониторинг автоматической реорганизации). Если вы хотите получать уведомления по электронной почте в случаях, когда происходят ошибки автоматической реорганизации (т. е. при неудачных попытках реорганизации таблиц), вам необходимо настроить список адресов электронной почты на этой странице. Обратите внимание на то, что нельзя настроить получение уведомлений от определенного индикатора состояния (например, только от индикатора состояния db.tb_reorg_req). Любой пользователь, настроивший получение уведомлений, будет получать уведомления от ЛЮБОГО из индикаторов состояния, переходящих в состояние тревоги.

Этот шаг является не обязательным. Вы можете нажать кнопку Next, чтобы закрыть эту страницу.

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

  1. Установить DB2 Administration Server. Эта задача выходит за рамки данной статьи. Для получения подробной информации обратитесь к документации по DB2.
  2. Обновить параметр конфигурации DB2 Administration Server SMTP_SERVER. Это можно сделать с помощью CLP-команды UPDATE ADMIN CONFIG, например, как показано в листинге 4.

    Листинг 4. Обновление конфигурации сервера администрирования
    UPDATE ADMIN CONFIG USING SMTP_SERVER myserver.domain.com

    Параметр конфигурации SMTP_SERVER должен указывать на SMTP-сервер, не требующий авторизации (DB2 Administration Server не поддерживает SMTP с авторизацией).

Полагая, что DB2 Administration Server установлен, и параметр SMTP_SERVER настроен должным образом, вы можете добавлять адреса электронной почты в список уведомления на соответствующей странице (рисунок 6). Нажмите кнопку Manage Contacts для создания новых контактов, которые будут добавлены в главный список контактов, хранящийся в DB2 Administration Server. После этого выберите адреса из списка контактов и нажмите кнопку с правой стрелкой, чтобы добавить эти контакты в список пользователей, которые будут получать по электронной почте уведомления о состоянии, генерируемые программой мониторинга. По завершении нажмите кнопку Next.

Рисунок 6. Страница списка уведомлений
Страница списка уведомлений

Шаг 7. Страница настройки компонентов обслуживания

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

Столбец Automate соответствует параметру конфигурации AUTO_REORG. Если флажок в этом столбце установлен, то автоматическая реорганизация включена (т. е. параметры AUTO_MAINT, AUTO_TBL_MAINT и AUTO_REORG установлены в ON, и эффективным значением параметра AUTO_REORG является ON). Если флажок в этом столбце не установлен, установите его, чтобы включить автоматическую реорганизацию. По умолчанию этот флажок не установлен (т. е. автоматическая реорганизация по умолчанию не включена).

Столбец Notify соответствует индикатору состояния db.tb_reorg_req. Этот индикатор состояния следит за ходом автоматической реорганизации. Если флажок в этом столбце установлен, индикатор состояния включен. Если флажок не установлен, индикатор состояния отключен. Если вы включаете автоматическую реорганизацию, настоятельно рекомендуется включить индикатор состояния (т. е. оставить установленным флажок в столбце Notify). Индикатор состояния является главным механизмом управления мониторингом, а также выявлением и устранением проблем. Более подробно индикатор состояния будет рассмотрен в разделе Мониторинг автоматической реорганизации. Обратите внимание на то, что установка этого флажка не включает отсылку уведомлений по электронной почте. Если вы хотите получать уведомления по электронной почте при переходе индикатора состояния db.tb_reorg_req в состояние тревоги, то нужно выполнить действия, описанные выше в шаге 6.

Рисунок 7. Страница настройки компонентов обслуживания
Страница настройки компонентов обслуживания

В нижней части окна содержится описание параметров автоматической реорганизации. Нажмите кнопку Configure settings для открытия диалогового окна свойств (рисунок 8).

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

  1. Имя.

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

  2. Размер.

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

Размер таблицы в пределах раздела оценивается по следующей формуле: (SYSSTAT.TABLES.CARD * SYSSTAT.TABLES.AVGROWSIZE) / (Число разделов в группе разделов табличного пространства, содержащего таблицу).

Рисунок 8. Настройка табличной области в диалоговом окне свойств
Настройка табличной области в диалоговом окне свойств

На второй вкладке диалогового окна вы можете настроить параметры, влияющие на работу автоматической реорганизации (рисунок 9). Здесь вы можете настроить три параметра:

  1. Опции использования системного временного табличного пространства.

    По умолчанию во время реорганизации таблицы ее рабочая копия хранится в табличных пространствах, в которых содержится эта таблица. Если в табличном пространстве недостаточно свободного места для хранения копии, и оно не определено как расширяемое (или определено как расширяемое, но заканчивается пространство файловой системы), реорганизация завершится с ошибкой. Когда включен параметр "use system temporary table space" (использовать системное временное табличное пространство), автоматическая реорганизация автоматически выберет временное табличное пространство с подходящим размером страницы, чтобы использовать его во время операций по реорганизации для хранения рабочей копии таблицы.

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

  2. Опции словаря сжатия.

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

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

  3. Опции режима выполнения реорганизации.

    С помощью этого параметра вы можете указать, когда должна выполняться реорганизация индексов – в течение онлайнового интервала, или же в течение автономного интервала. Если выбран режим онлайновой реорганизации, то команды по реорганизации будут выполняться с опцией ALLOW WRITE ACCESS, и пользователи смогут считывать и записывать данные в индекс во время его реорганизации. Для реорганизации индексов рекомендуется использовать онлайновый режим. Реорганизация в онлайновом режиме занимает больше времени, но зато она может выполняться в течение онлайнового интервала обслуживания, который, как правило, намного больше, чем автономный интервал обслуживания.

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

Рисунок 9. Настройка режима выполнения реорганизации в диалоговом окне свойств
Настройка режима выполнения реорганизации в диалоговом окне свойств

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

Шаг 8. Страница сводной статистики

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

Рисунок 10. Просмотр параметров автоматического обслуживания
Просмотр параметров автоматического обслуживания

Расширенная настройка

В диалоговом окне свойств автоматического сбора статистики вы можете выполнить фильтрацию таблиц, задав условие WHERE в операторе select, применяемом к параметру SYSCAT.TABLES (рисунок 11).

Рисунок 11. Задание табличной области с помощью условия WHERE
Задание табличной области с помощью условия WHERE

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

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

Листинг 5. Создание управляющей таблицы
CREATE TABLE ATM.AUTO_REORG_CTL( TABSCHEMA VARCHAR(128), TABNAME VARCHAR(128))

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

Листинг 6. Условие WHERE для политики реорганизации
(TABSCHEMA, TABNAME) IN (SELECT CTL.TABSCHEMA,
 CTL.TABNAME FROM ATM.AUTO_REORG_CTL AS CTL)

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


Как работает автоматическая реорганизация

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

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

Необходимость реорганизации таблиц определяется с использованием команды REORGCHK (в особенности, хранимых процедур REORGCHKREORGCHK_TB_STATS и REORGCHK_IX_STATS). REORGCHK проверяет набор из восьми выражений для таблицы и сравнивает полученные результаты с набором предопределенных пороговых значений. Если пороговые значения превышены, то для таблицы или ее индексов (в зависимости от того, какое именно значение было превышено) рекомендуется выполнить реорганизацию. В листинге 7 приведено краткое описание того, что измеряется с помощью каждого выражения. Для получения информации о точных выражениях и пороговых значениях, которые могут слегка отличаться в разных релизах, обратитесь к документации DB2.

Листинг 7. Выражения, используемые REORGCHK
F1: Проверяет процентное содержание строк переполнения в таблице
F2: Проверяет процентное содержание свободного места в таблице
F3: Проверяет процентное содержание пустых страниц в таблице
F4: Проверяет коэффициент кластеризации (уровень соответствия строк 
в таблице их порядку в индексе)
F5: Проверяет процентное содержание свободного пространства
на концевых страницах индекса
F6: Проверяет, можно ли понизить число уровней в индексе 
F7: Проверяет процентное содержание идентификаторов записей RID (Record IDs) 
в индексе, помеченных как удаленные
F8: Проверяет процентное содержание концевых страниц индекса, все
идентификаторы RID (Record IDs) которых отмечены как удаленные.

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

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

Если вы хотите знать, будет ли в процессе реорганизации выполнена реорганизация указанной таблицы или указанного индекса, вы всегда сможете вручную вызвать процедуру REORGCHK_TB_STATS (оценивает выражения F1 -> F3) или REORGCHK_IX_STATS (оценивает выражения F4 -> F8) и посмотреть результаты. Когда пороговое значение превышено, в позиции, соответствующей оцениваемому выражению, в столбце REORG возвращается знак звездочки (*), например, как показано в листинге 8.

Листинг 8. Вызов REORGCHK_TB_STATS
CONNECT TO <имя БД>
CALL REORGCHK_TB_STATS('T', 'ATM.TEST')"      


  Result set 1
  --------------

  TABLE_SCHEMA TABLE_NAME ...   F1          F2       
     F3          REORG
  ------------ ---------- ...   ----------- ----------- ----------- ----- 
  ATM          TEST       ...   0          17           25          -**   

  1 record(s) selected.

  Return Status = 0

В данном случае столбец REORG содержит значение -**, которое означает, что значения выражений F2 и F3 превышены. Чтобы проверить выражения F4 -> F8, вы могли бы вызвать хранимую процедуру REORGCHK_IX_STATS.

Какой тип реорганизации будет использоваться?

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

Таблица 1. Типы используемой реорганизации в зависимости от выражений REORGCHK
FormulaReorganization Applied
F1REORG TABLE <имя таблицы>
F2REORG TABLE <имя таблицы>
F3REORG TABLE <имя таблицы>
F4REORG TABLE <имя таблицы> INDEX <имя индекса> INDEXSCAN, где <имя индекса> – это имя кластерного индекса для таблицы (если он существует) или имя первого уникального индекса (или индекса первичного ключа), если кластерного индекса не существует
F5REORG TABLE <имя таблицы>
F6REORG TABLE <имя таблицы>
F7REORG TABLE <имя таблицы> CLEANUP ONLY ALL
F8REORG TABLE <имя таблицы> CLEANUP ONLY ALL

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

Таблица 2. Дополнительная модификация в зависимости от конфигурации автоматической реорганизации
ПараметрВыраженияМодификатор
Rebuild dictionaryF1, F2, F3, F4RESETDICTIONARY
Use system temporary table spaceF1, F2, F3, F4USE <имя табличного пространства>, где <имя табличного пространства> будет являться именем временного табличного пространства с подходящим размером страницы.
Reorganize indexes onlineF5, F6, F7, F8ALLOW WRITE ACCESS

Процесс автоматической реорганизации

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

Первый раз оценка выполняется по истечении двух часов с момента активизации базы данных, а затем – каждые два часа. При переходе от одной версии DB2 к другой этот двухчасовой интервал может меняться. Оценка происходит с тем же интервалом, что и индикатор состояния реорганизации (db.tb_reorg_req, за детальной информацией обратитесь к разделу Мониторинг автоматической реорганизации). Вы можете проверить текущий интервал оценки, выполнив следующий запрос (листинг 9), результат выводится в секундах.

Листинг 9. Проверка текущего интервала оценки
CONNECT TO <имя БД>
SELECT REFRESH_INTERVAL FROM TABLE
(HEALTH_GET_IND_DEFINITION('')) AS T 
WHERE NAME = 'db.tb_reorg_req'

REFRESH_INTERVAL    
--------------------
                7200

  1 record(s) selected.

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

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

Во время каждого процесса оценки при выполнении автоматической реорганизации происходит следующее (рисунок 12).

Рисунок 12. Схема процесса оценки при выполнении автоматической реорганизации
Схема процесса оценки при выполнении автоматической реорганизации

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

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

Сначала происходит вызов процедуры REORGCHK_TB_STATS для проверки того, требуется ли реорганизация таблицы (превышены пороговые значения выражений F1, F2 или F3). Если выполнение реорганизации таблицы требуется, применяется фильтр размера таблицы (если он был настроен).

Оценка размера таблицы в пределах раздела производится по следующей формуле: (SYSSTAT.TABLES.CARD * SYSSTAT.TABLES.AVGROWSIZE) / (Число разделов в группе разделов табличного пространства, содержащего таблицу). Если предполагаемый размер таблицы в пределах раздела меньше установленного ограничения, для нее планируется автономная реорганизация (все процессы по реорганизации таблицы происходят в течение автономного интервала обслуживания). Если же размер таблицы в пределах раздела превышает установленное ограничение, реорганизация таблицы не может быть выполнена, поэтому процесс автоматической реорганизации переходит к следующему шагу.

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

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

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

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

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

Рисунок 13. Реорганизация таблицы в автономном интервале обслуживания
Реорганизация таблицы в автономном интервале обслуживания

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

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

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

Автоматическая и ручная реорганизация

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

Автоматическая реорганизация при невозможности использования интервала автономного обслуживания

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

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

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

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

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


Мониторинг автоматической реорганизации

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

Снимки состояния и индикатор состояния реорганизации

Основным интерфейсом для мониторинга автоматической реорганизации является монитор состояния и индикатор состояния db.tb_reorg_req. Индикаторы состояния следят за состоянием определенных компонентов DB2. Индикатор состояния db.tb_reorg_req health переходит в состояние, требующее внимания (отличное от нормального), когда для таблицы необходимо выполнить ручную реорганизацию. В случае включенной функции автоматической реорганизации это означает, что автоматическая реорганизация для таблицы завершилась с ошибкой. Кроме того, в тех случаях, когда автоматическая реорганизация отключена, индикатор состояния может оказаться полезным, поскольку с его помощью запускается процесс оценки автоматической реорганизации, с помощью которого можно определить, когда необходимо выполнить реорганизацию таблиц.

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

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

Листинг 10. Снимок состояния
GET HEALTH SNAPSHOT FOR DATABASE ON <имя БД>

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

Вывод снимка состояния выглядит подобно приведенному в листинге 11 (заметьте, что для ясности здесь отображен только индикатор состояния db.tb_reorg_req, другие индикаторы состояния опущены).

Листинг 11. Пример снимка состояния
get health snapshot for db on reorgdb

             Database Health Snapshot 

Snapshot timestamp                         = 03/28/2007 10:26:53.217403

Database name                              = REORGDB
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00002/
Input database alias                       = REORGDB
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
Database highest severity alert state      = Attention

Health Indicators:

    Indicator Name                             = db.tb_reorg_req
       Value                                   = 1
       Evaluation timestamp                    = 03/28/2007 10:26:51.755071
       Alert state                             = Attention

          Collection:

             Name                              = "ATM"."SMALLTABLE"
             Detail                            = REORG TABLE USE TEMPTBSP; SQL22022
             State                             = Automation failed
             Evaluation timestamp              = 03/28/2007 10:26:52.000000

В заголовке снимка содержится информация о том, когда и для какой базы данных он был сделан (листинг 12). Значением параметра Database highest severity alert state является самый серьезный тип предупреждений, полученных от всех отслеживаемых индикаторов состояния базы данных, так что это не означает, что данное предупреждение относится непосредственно к автоматической реорганизации.

Листинг 12. Заголовок снимка состояния
Snapshot timestamp                         = 03/28/2007 10:26:53.217403

Database name                              = REORGDB
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00002/
Input database alias                       = REORGDB
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
Database highest severity alert state      = Attention

Раздел индикаторов состояния содержит информацию от всех отслеживаемых индикаторов базы данных. Для ясности здесь показана только информация индикатора состояния db.tb_reorg_req. Информация индикатора состояния верхнего уровня db.tb_reorg_req описывает состояние автоматической реорганизации в целом. Временная отметка показывает последнее время выполнения оценки автоматической реорганизации. Вспомните, что оценка – это процесс, во время которого автоматическая реорганизация проверяет необходимость реорганизации таблиц, выполняющейся приблизительно каждые два часа (на протяжении этого времени база данных остается активной). Состояние предупреждения для db.tb_reorg_req принимает одно из двух значений: Normal или Attention. Если значением является Normal, автоматическая реорганизация работает правильно. Ручная автоматическая реорганизация не требуется ни для одной из таблиц. Если значением является Attention (листинг 13), значит, по крайней мере, для одной таблицы требуется ручной запуск автоматической реорганизации (т. е. по какой-то причине автоматическая реорганизация таблицы завершилась с ошибкой).

Листинг 13. Снимок состояния, содержащий тип предупреждений "Attention" ("Внимание")
Health Indicators:

	Indicator Name                             = db.tb_reorg_req
	   Value                                   = 1
	   Evaluation timestamp                    = 03/28/2007 10:26:51.755071
	   Alert state                             = Attention

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

Листинг 14. Снимок состояния, показывающий, что автоматическая реорганизация завершилась с ошибкой
Name                              = "ATM"."SMALLTABLE"
Detail                            = REORG TABLE USE TEMPTBSP; SQL22022
State                             = Automation failed
Evaluation timestamp              = 03/28/2007 10:26:52.000000

Поле Detail показывает параметры реорганизации, которые использовались при попытке автоматической реорганизации, и SQL-код ошибки. В данном случае автоматическая реорганизация пыталась выполнить реорганизацию с параметром "use system temporary table space" (этот параметр будет присутствовать только в том случае, если он был включен при задании конфигурации базы данных). Кодом ошибки является SQL-код 22022 – интервал обслуживания не задан или слишком короткий. Скорее всего, в данном случае пользователь забыл задать автономный интервал обслуживания (вспомните, что реорганизация таблиц выполняется только в течение автономного интервала обслуживания).

Поле State показывает текущее состояние для таблицы. Для обычных снимков это поле может принимать значение Automation failed (Автоматизация завершилась с ошибкой) или Attention (Внимание). Значение Automation failed означает, что при попытке реорганизации таблицы произошла ошибка. Значение Attention означает, что требуется выполнить реорганизацию таблицы, но автоматическая реорганизация не предприняла попытки сделать это (например, размер таблицы превышает заданное ограничение или автоматическая реорганизация не включена).

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

По умолчанию информация снимка состояния для индикатора состояния db.tb_reorg_req содержит сведения только для тех таблиц, для которых требуется ручной запуск автоматической реорганизации. Для таблиц, для которых было установлено, что реорганизация не требуется (или же реорганизация требуется, но была автоматизирована), сведения не отображаются. Иногда оказывается полезным собрать информацию и об этих таблицах. С помощью условия WITH FULL COLLECTION вы можете изменить команду снимка состояния так, чтобы запрос информации производился для всех таблиц, например, как показано в листинге 15.

Листинг 15. Запрос снимка состояния для всех таблиц
GET HEALTH SNAPSHOT FOR DATABASE ON <имя БД> WITH FULL COLLECTION

Теперь вывод индикатора состояния db.tb_reorg_req содержит одну запись для каждой таблицы области, для которой назначена автоматическая реорганизация. Аналогично записям для таблиц, для которых требуется реорганизация, из этого вывода вы можете узнать время, когда была выполнена последняя оценка таблицы на предмет необходимости реорганизации (т. е. к таблице были применены выражения REORGCHK). В данном случае поле State примет одно из дополнительных значений: Not yet evaluated, Normal и Automated. Состояние Not yet evaluated означает, что автоматическая реорганизация еще не оценивала таблицу с помощью выражений REORGCHK (как правило, потому, что недоступна статистика для таблицы). Состояние Normal означает, что реорганизация таблицы не требуется. Состояние Automated означает, что реорганизация таблицы была запланирована и будет выполнена в течение предстоящего интервала обслуживания.

В целях демонстрации проще всего рассмотреть ряд наиболее распространенных примеров того, что вы можете увидеть при создании снимка состояния (листинги 16–22).

Пример 1. База данных не активна, никакая информация снимка состояния не возвращается

Листинг 16. Пример 1
GET HEALTH SNAPSHOT FOR DB ON SAMPLE

SQL1611W  No data was returned by Database System Monitor.

Пример 2. База данных активна, но автоматическая реорганизация еще не произвела оценку (т. е. база данных была активна менее 2 часов).

Листинг 17. Пример 2
GET HEALTH SNAPSHOT FOR DB ON SAMPLE

             Database Health Snapshot

Snapshot timestamp                         = 03/28/2007 13:07:04.794350

Database name                              = SAMPLE
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00001/
Input database alias                       = SAMPLE
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
Database highest severity alert state      = Not yet evaluated

Health Indicators:

   Not yet evaluated

Пример 3. Снимок состояния: автоматическая реорганизация работает правильно, ручного запуска реорганизации не требуется.

Листинг 18. Пример 3
			GET HEALTH SNAPSHOT FOR DB ON SAMPLE

             Database Health Snapshot

Snapshot timestamp                         = 03/28/2007 10:25:08.460731

Database name                              = SAMPLE
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00002/
Input database alias                       = SAMPLE
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
Database highest severity alert state      = Normal

Health Indicators:

    Indicator Name                             = db.tb_reorg_req
       Value                                   = 0
       Evaluation timestamp                    = 03/28/2007 10:25:07.529251
       Alert state                             = Normal

Пример 4. Снимок состояния: автоматическая реорганизация завершилась с ошибкой, не определен автономный интервал обслуживания. Как обсуждалось ранее в разделе Включение и настройка автоматической реорганизации, для правильной работы автоматической реорганизации необходимо задать автономный интервал обслуживания. Если этот интервал не определен, автоматическая реорганизация не сможет выполнять любые действия по реорганизации в автономном режиме (в частности, реорганизацию таблиц, которая всегда выполняется в автономном режиме), и индикатор состояния будет выдавать информацию об ошибках, приведенную ниже. Поле Detail содержит SQL-код -22022, говорящий о том, что автономный интервал обслуживания либо не был задан, либо недостаточно продолжителен.

Листинг 19. Пример 4
GET HEALTH SNAPSHOT FOR DB ON SAMPLE

             Database Health Snapshot

Snapshot timestamp                         = 03/28/2007 10:26:53.217403

Database name                              = SAMPLE
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00002/
Input database alias                       = SAMPLE
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
Database highest severity alert state      = Attention

Health Indicators:

    Indicator Name                             = db.tb_reorg_req
       Value                                   = 1
       Evaluation timestamp                    = 03/28/2007 10:26:51.755071
       Alert state                             = Attention

          Collection:

             Name                              = "ATM"."SMALLTABLE"
             Detail                            = REORG TABLE USE TEMPTBSP; SQL22022
             State                             = Automation failed
             Evaluation timestamp              = 03/28/2007 10:26:52.000000

Пример 5. Снимок состояния: автоматическая реорганизация не предприняла попытку реорганизации таблицы, размер которой превышает установленное ограничение.

Листинг 20. Пример 5
GET HEALTH SNAPSHOT FOR DB ON SAMPLE

             Database Health Snapshot

Snapshot timestamp                         = 03/28/2007 10:36:06.261868

Database name                              = SAMPLE
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00002/
Input database alias                       = SAMPLE
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
Database highest severity alert state      = Attention

Health Indicators:

    Indicator Name                             = db.tb_reorg_req
       Value                                   = 1
       Evaluation timestamp                    = 03/28/2007 10:36:04.844324
       Alert state                             = Attention

          Collection:

             Name                              = "ATM"."LARGETABLE"
             Detail                            = REORG TABLE; TABLE EXCEEDS OFFLINE 
REORG SIZE CRITERIA
             State                             = Attention
             Evaluation timestamp              = 03/28/2007 10:35:40.000000

Пример 6. Снимок состояния с параметром "with full collection": для таблицы employee не было собрано никакой статистики, поэтому ее оценка еще не проводилась (отсутствие статистики означает, что выражения reorgchk невозможно оценить). В данном случае таблица не содержит временной отметки об оценке, поскольку автоматическая реорганизация еще не выполняла оценку таблицы (индикатор состояния не содержит временной отметки об оценке, потому что процесс оценки выполнился для всех таблиц заданной области, но для этой конкретной таблицы выражения REORGCHK могли быть еще не оценены).

Листинг 21. Пример 6
GET HEALTH SNAPSHOT FOR DB ON SAMPLE WITH FULL COLLECTION

             Database Health Snapshot

Snapshot timestamp                         = 03/28/2007 12:52:48.477502

Database name                              = SAMPLE
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00001/
Input database alias                       = SAMPLE
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
Database highest severity alert state      = Alarm

Health Indicators:

    Indicator Name                             = db.tb_reorg_req
       Value                                   = 0
       Evaluation timestamp                    = 03/28/2007 12:52:46.460665
       Alert state                             = Normal

          Collection:

             Name                              = "DBUSER"."EMPLOYEE"
             State                             = Not yet evaluated

Пример 7. Снимок состояния с параметром "with full collection": ручной запуск реорганизации не требуется ни для одной таблицы; таблица DBUSER.EMPLOYEE находится в состоянии Automated, что означает, что для нее требуется и запланирована реорганизация (произойдет при наступлении автономного интервала обслуживания); таблица DBUSER.CL_SCHED находится в состоянии Normal (реорганизация не требуется; датой последней проверки таблицы DBUSER.CL_SCHED (т. е. были применены выражения reorgchk) процессом автоматической реорганизации является Mar 28, 2007 at 11:57:16. В случаях с обеими таблицами нет необходимости предпринимать какие-либо действия.

Листинг 22. Пример 7
GET HEALTH SNAPSHOT FOR DB ON SAMPLE WITH FULL COLLECTION

             Database Health Snapshot

Snapshot timestamp                         = 03/28/2007 12:52:48.477502

Database name                              = SAMPLE
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00001/
Input database alias                       = SAMPLE
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
Database highest severity alert state      = Alarm

Health Indicators:

    Indicator Name                             = db.tb_reorg_req
       Value                                   = 0
       Evaluation timestamp                    = 03/28/2007 12:52:46.460665
       Alert state                             = Normal

          Collection:

             Name                              = "DBUSER"."EMPLOYEE"
             State                             = Automated
             Evaluation timestamp              = 03/28/2007 11:57:16.000000


             Name                              = "DBUSER"."CL_SCHED"
             State                             = Normal
             Evaluation timestamp              = 03/28/2007 11:57:16.000000

Как было упомянуто ранее, существует ряд других интерфейсов для получения информации снимков состояния. В их число входят API-функция db2GetSnapshot языка C, графический интерфейс Health Center, а также ряд следующих интерфейсов SQL:

  • HEALTH_DB_HI – информация по индикаторам состояния.
  • HEALTH_DB_HIC – информация по отдельным таблицам.

Заметьте, что здесь представлен эквивалент опции WITH FULL COLLECTION, встроенный в интерфейс SQL.

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

  • Время последней оценки, выполненной в процессе автоматической реорганизации.
  • Список таблиц, для которых требуется ручной запуск реорганизации (а также причину неудачного выполнения автоматической реорганизации, когда это возможно).
  • Список таблиц, для которых реорганизация не требуется (если указана опция FULL COLLECTION, ищите таблицы в состоянии Normal).
  • Список таблиц, для которых в текущий момент запланирована реорганизация (если указана опция FULL COLLECTION, ищите таблицы в состоянии AUTOMATED).

По умолчанию монитор состояния и индикатор состояния db.tb_reorg_req включены. Статус монитора состояния вы можете проверить с помощью команды GET DBM CONFIG (листинг 23).

Листинг 23. Проверка статуса монитора состояния
GET DBM CONFIG 

          Database Manager Configuration

     Node type = Database Server with local clients

 Database manager configuration release level            = 0x0c00
...

   Statement                              (DFT_MON_STMT) = OFF
   Table                                 (DFT_MON_TABLE) = OFF
   Timestamp                         (DFT_MON_TIMESTAMP) = ON
   Unit of work                            (DFT_MON_UOW) = OFF
Monitor health of instance and databases   (HEALTH_MON) = ON
 SYSADM group name                        (SYSADM_GROUP) =

Если монитор состояния отключен, вы можете динамически включить его с помощью следующей команды (листинг 24).

Листинг 24. Включение монитора состояния
ATTACH TO <имя узла>
UPDATE DBM CONFIG USING HEALTH_MON ON IMMEDIATE

Вы можете проверить, включен ли индикатор состояния db.tb_reorg_req, с помощью команды GET ALERT CONFIG (листинг 25).

Листинг 25. Проверка статуса индикатора состояния db.tb_reorg_req
GET ALERT CONFIG FOR DATABASE ON <имя БД>

            Alert Configuration

  Indicator Name                     = db.db_op_status
      Default                        = Yes     
      Type                           = State-based
      Sensitivity                    = 0
      Formula                        = db.db_status;
      Actions                        = Disabled
      Threshold or State checking    = Enabled
...

  Indicator Name                     = db.tb_reorg_req
      Default                        = Yes     
      Type                           = Collection state-based
      Sensitivity                    = 0
      Actions                        = Disabled
     Threshold or State checking  = Enabled

Если индикатор состояния db.tb_reorg_req отключен, вы можете включить его с помощью следующей команды (листинг 26).

Листинг 26. Включение индикатора состояния db.tb_reorg_req
UPDATE ALERT CONFIG FOR DATABASE ON <имя БД> USING DB.TB_REORG_REQ 
	SET THRESHOLDSCHECKED YES

Регистрация информации диагностики

Автоматическая реорганизация регистрирует события в журнале db2diag.log по мере обработки таблиц на этапе выполнения (т. е. в те моменты, когда непосредственно выполняется реорганизация таблиц во время интервала обслуживания). Каждый раз, когда начинается или заканчивается реорганизация таблицы, в журнал заносятся соответствующие события, которые регистрируются всегда, независимо от значения параметра конфигурации базы данных DIAGLEVEL. В случае возникновения ошибки событие "stop" будет содержать SQL-код возникшей ошибки (листинг 27).

Листинг 27. Пример событий, связанных с автоматической реорганизацией
2007-03-28-10.26.57.436904-240 I8286391A371       LEVEL: Event
PID     : 1155132              TID  : 1293        PROC : db2fmp
INSTANCE: swalkty              NODE : 000
EDUID   : 1293                 EDUNAME: db2acd
FUNCTION: DB2 UDB, Automatic Table Maintenance, db2AutoReorgExec, probe:10
START   : Automatic reorg has started on table REORGDB ."ATM     "."SMALLTABLE"


2007-03-28-10.26.58.174382-240 I8295995A424       LEVEL: Event
PID     : 1155132              TID  : 1293        PROC : db2fmp
INSTANCE: swalkty              NODE : 000
APPID   : *LOCAL.swalkty.070328142710
EDUID   : 1293                 EDUNAME: db2acd
FUNCTION: DB2 UDB, Automatic Table Maintenance, 
db2AutoReorgExec, probe:10
STOP    : Automatic reorg has completed successfully on table REORGDB ."ATM     "."SMALLTABLE"

Когда значение параметра конфигурации базы данных DIAGLEVEL установлено равным 4 (запись всех событий), автоматическая реорганизация также будет регистрировать время начала и окончания процесса оценки (т. е. приблизительно каждые два часа; как вы помните из раздела Как работает автоматическая реорганизация, оценка – это часть процесса автоматической реорганизации, выполняющаяся с регулярной периодичностью и проверяющая необходимость выполнения реорганизации таблицы). Как правило, в регистрации этих событий нет необходимости, поскольку они регистрируются довольно часто и занимают много места в журнале регистрации. Тем не менее, если вы подозреваете, что в процессе оценки во время автоматической реорганизации содержатся ошибки (например, база данных активна более двух часов, индикатор состояния db.tb_reorg_req включен, но не появляется в снимках состояния), вы можете временно установить параметр DIAGLEVEL равным 4 и поискать в журнале эти события.

События, занесенные в журнал, выглядят подобно приведенным в листинге 28.

Листинг 28. События, связанные с оценкой
2007-03-28-10.25.01.920756-240 I8320776A361       LEVEL: Event
PID     : 1155132              TID  : 1038        PROC : db2fmp
INSTANCE: swalkty              NODE : 000
EDUID   : 1038                 EDUNAME: db2acd
FUNCTION: DB2 UDB, Automatic Table Maintenance, db2HmonEvalReorg, probe:10
START   : Automatic reorg evaluation has started on database REORGDB

2007-03-28-10.26.57.462995-240 I8287958A375       LEVEL: Event
PID     : 1155132              TID  : 1036        PROC : db2fmp
INSTANCE: swalkty              NODE : 000
EDUID   : 1036                 EDUNAME: db2acd 
FUNCTION: DB2 UDB, Automatic Table Maintenance, 
db2HmonEvalReorg, probe:20
STOP    : Automatic reorg evaluation has finished successfully on database REORGDB

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

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

Диагностика проблем автоматической реорганизации

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

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

  1. Запустить команду GET DB CONFIG и убедиться, что автоматическая реорганизация включена. В частности, параметры AUTO_MAINT, AUTO_TBL_MAINT и AUTO_REORG должны быть установлены в ON.
  2. Запустить мастер Configure automatic maintenance из центра управления DB2 Control Center и убедиться, что задан автономный интервал обслуживания.
  3. Проверить ограничения на имена и размер таблиц в мастере Configure automatic maintenance и убедиться, что таблицы, для которых вы хотите выполнять автоматическую реорганизацию, попадают под эти критерии.

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

Листинг 29. Проверка состояния активизации базы данных
GET SNAPSHOT FOR DB ON <имя БД>

              Database Snapshot

Database name                              = SAMPLE
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00001/
Input database alias                       = SAMPLE
Database status                            = Active
Catalog database partition number          = 0
Catalog network node name                  =
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
First database connect timestamp       = 03/28/2007 16:41:59.082095
Last reset timestamp                       =
Last backup timestamp                      =

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

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

Листинг 30. Снимок состояния для всех таблиц
GET HEALTH SNAPSHOT FOR DB ON <имя БД> WITH FULL COLLECTION

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

Листинг 31. Поиск состояния таблицы
             Name                              = "DBUSER"."EMPLOYEE"
             State                             = Automated
             Evaluation timestamp              = 03/28/2007 11:57:16.000000

Если таблица находится в состоянии "not yet evaluated", вероятно, ее статистика устарела. Выполните следующий запрос (листинг 32).

Листинг 32. Проверка последнего времени обновления статистики
SELECT STATS_TIME FROM SYSCAT.TABLES WHERE TABNAME = 'table' AND TABSCHEMA = 'schema'

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

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

Если таблица находится в состоянии Normal, значит, система считает, что реорганизацию этой таблицы выполнять не нужно. Вы можете убедиться в этом, вручную запустив хранимые процедуры REORGCHK_TB_STATS и REORGCHK_IX_STATS и проверив значения флагов в столбце REORG.

Если REORGCHK показывает, что необходимо выполнить реорганизацию таблицы, и таблица все еще находится в состоянии Normal, снова проверьте для нее значение STATS_TIME. Статистика могла быть обновлена недавно, и в этом случае вам просто нужно дождаться начала следующего интервала оценки. Например, в снимке состояния вы можете увидеть следующее (листинг 33).

Листинг 33. Проверка временных отметок
GET HEALTH SNAPSHOT FOR DB ON SAMPLE WITH FULL COLLECTION

             Database Health Snapshot

Snapshot timestamp                         = 03/28/2007 12:52:48.477502

Database name                              = SAMPLE
Database path                              = /home/swalkty/swalkty/NODE0000/SQL00001/
Input database alias                       = SAMPLE
Operating system running at database server= AIX 64BIT
Location of the database                   = Local
Database highest severity alert state      = Alarm

Health Indicators:

    Indicator Name                             = db.tb_reorg_req
       Value                                   = 0
    Evaluation timestamp                  = 03/28/2007 12:52:46.460665
       Alert state                             = Normal

          Collection:

             Name                              = "DBUSER"."CL_SCHED"
             State                             = Normal
        Evaluation timestamp              = 03/28/2007 11:57:16.000000

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

В данном примере:

  • Следующий интервал оценки для автоматической реорганизации начнется 03/28/2007 12:52:46 + 2 часа (т. е. 03/28/2007 14:52:46).
  • Время последней оценки таблицы DBUSER.CL_SCHED – 03/28/2007 11:57:16.

Если STATS_TIME для таблицы содержит время, более раннее, чем 03/28/2007 11:57:16 (время последней оценки таблицы), повторная оценка таблицы НЕ будет производиться во время следующего интервала оценки, который наступит 03/28/2007 14:52:46.

Однако если STATS_TIME содержит время, более позднее, чем 03/28/2007 11:57:16 (предположим, например, что статистика таблицы была обновлена 03/28/2007 12:58:00), повторная оценка таблицы будет выполнена во время следующего интервала оценки, который наступит 03/28/2007 14:52:46 (т. е. во время этого интервала выражения REORGCHK будут повторно применены).

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

Сообщения, вводящие в заблуждение

Если вы работаете в DB2 v8.2 или значением параметра DIAGLEVEL является 4, вы увидите сообщения об оценке, производящейся в процессе автоматической реорганизации, даже если параметр конфигурации AUTO_REORG отключен. В этом случае автоматическая реорганизация НЕ работает. Этап оценки выполняется для того чтобы определить, для каких таблиц требуется ручная реорганизация, и сообщить об этом через индикатор состояния the db.tb_reorg_req, однако реорганизация в данном случае НЕ будет автоматизирована.

Работа с непредвиденными ошибками

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

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


Отличия автоматической реорганизации в DB2 V8.2 и DB2 9

Примечание. При миграции из DB2 v8.2 в DB2 9 рассмотрите вопрос обновления политики автоматической реорганизации, чтобы получить все преимущества от использования новых параметров конфигурации.

Следующие параметры конфигурации являются новыми в DB2 9:

  • Ограничение по размеру. В DB2 v8.2 отфильтровывать таблицы, для которых будет выполняться автоматическая реорганизация, можно было только на основе имени (фильтрация таблиц производилась только на основе имени, схемы и комментария; таблицы нельзя было отфильтровывать по размеру).

  • Опция использования временного табличного пространства. При реорганизации таблицы в DB2 v8.2 ее рабочая копия хранится в табличном пространстве, содержащем эту таблицу. В этом случае вы должны обеспечить наличие свободного места в табличном пространстве, достаточного для хранения копии (или же определить табличное пространство как расширяемое), в противном случае автоматическая реорганизация завершится с ошибкой. В отличие от DB2 9, в DB2 v8.2 не существует опции использования системного временного табличного пространства для хранения рабочей копии таблицы во время ее реорганизации.

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

  • Режим реорганизации индексов. В DB2 v8.2 реорганизация индексов выполнялась в автономном режиме (с блокировкой доступов на запись и чтение) в рамках автономного интервала обслуживания. В DB2 9 вы можете задать для реорганизации индексов онлайновый режим (доступы на запись и чтение не блокируются), при котором выполнение реорганизации происходит в рамках онлайнового интервала.

Вторым отличием автоматической реорганизации в DB2 v8.2 и DB2 9 является регистрация информации диагностики. В DB2 9 события, относящиеся к оценке, выполняемой во время автоматической реорганизации, фиксируются в журнале диагностики DB2 (db2diag.log) только тогда, когда параметр DIAGLEVEL имеет установленное значение 4 (запись любых событий). В DB2 v8.2 события данного типа фиксируются во время каждого интервала оценки независимо от уровня регистрации событий (примеры событий вы можете посмотреть в разделе Мониторинг автоматической реорганизации). Это означает, что в DB2 v8.2 приблизительно каждые два часа (каждый раз, когда проверяется необходимость реорганизации таблиц) в журнал диагностики записываются два события. Вследствие этого со временем db2diag.log может переполниться и, таким образом, при включенной автоматической реорганизации вам может потребоваться очищать его чаще, чем при работе с DB2 9.


Лучшие практики по автоматической реорганизации

  1. Активируйте и поддерживайте вашу базу данных в активном состоянии. Рекомендуется выполнять явную активацию с помощью команды ACTIVATE DATABASE. Оценка, производящаяся в процессе автоматической реорганизации, выполняется с регулярным интервалом, начиная с момента времени db activation только тогда, когда база данных активна. Если база данных беспорядочно активизируется и деактивизируется (это может происходить при неявной активации во время выполнения запросов CONNECT), автоматическая реорганизация не будет выполняться так часто. Особенно важно, чтобы база данных была активна на протяжении временного интервала, который задан в качестве автономного интервала обслуживания – тогда процесс автоматической реорганизации сможет подключиться к базе данных и выполнить реорганизацию. Если во время автономного интервала обслуживания база данных не активна, автоматическая реорганизация не выполняется.

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

  3. Убедитесь, что включен монитор состояния, а также индикатор состояния db.tb_reorg_req health. Индикатор состояния db.tb_reorg_req является основным источником информации, связанной с ходом выполнения автоматической реорганизации. Если этот индикатор не включен, вы не сможете отслеживать работу автоматической реорганизации или обнаруживать возникающие проблемы. Рекомендуется периодически проверять данные этого индикатора состояния с целью убедиться в том, что автоматическая реорганизация работает без ошибок. Используйте возможность получения по электронной почте уведомлений при переходе индикатора состояния в состояние тревоги.

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

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

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

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


Заключение

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


Благодарности

Мы хотели бы выразить признание и благодарность Джессике Эскотт (Jessica Escott) за рецензирование этой статьи.

Ресурсы

Научиться

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

  • Загрузите бесплатную пробную версию DB2 Enterprise 9.
  • Теперь вы можете использовать DB2 бесплатно. Загрузите DB2 Express-C – бесплатную версию DB2 Express Edition для сообщества, которая предлагает все те же базовые возможности по работе с данными, что и DB2 Express Edtion, и предоставляет основу для написания и развертывания приложений.
  • Загрузите пробные версии продуктов IBM и освойте инструменты разработки приложений и межплатформенного программного обеспечения, входящие в состав DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.

Обсудить

Комментарии

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=399219
ArticleTitle=Автоматическое обслуживание таблиц в DB2 : Часть 2. Автоматическая реорганизация таблиц и индексов в DB2
publish-date=06242009