Содержание


Автоматическое обслуживание таблиц в DB2

Часть 1. Автоматический сбор статистики в DB2 для платформ Linux, UNIX и Windows

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

Серия контента:

Этот контент является частью # из серии # статей: Автоматическое обслуживание таблиц в DB2

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Автоматическое обслуживание таблиц в DB2

Следите за выходом новых статей этой серии.

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

Автоматический сбор статистики, также известный как auto-runstats, был представлен в DB2 версии 8.2 как часть функционала DB2 по автоматическому обслуживанию таблиц. При помощи автоматического сбора статистики вы можете позволить DB2 самостоятельно определять, когда необходимо обновлять статистику базы данных. DB2 будет автоматически запускать в фоновом режиме утилиту RUNSTATS, гарантируя, что всегда будет доступна самая актуальная статистика базы данных.

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

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

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

Включение функции автоматического сбора статистики

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

Листинг 1. Вывод сведений о конфигурации базы данных
GET DB CONFIG
...
 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_RUNSTATS должны быть установлены в ON.

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

CONNECT TO <имя БД>
UPDATE DB CONFIG USING AUTO_MAINT ON AUTO_TBL_MAINT ON AUTO_RUNSTATS ON

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

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

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

Настройка автоматического сбора статистики с помощью DB2 Control Center

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

  • Интервал онлайнового обслуживания – временной интервал, в течение которого автоматический сбор статистики выполнит сбор статистики для нужных таблиц.
  • Набор таблиц, для которых будет выполняться автоматический сбор статистики. Таблицы могут быть выбраны на основе имени, схемы или комментария.

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

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

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

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

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

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

    Рисунок 1. Запуск мастера настройки автоматического обслуживания
    Запуск мастера настройки автоматического обслуживания
    Запуск мастера настройки автоматического обслуживания
  3. На первой странице мастера содержится краткий обзор функций автоматического обслуживания. Для продолжения нажмите кнопку Next, расположенную внизу окна (рисунок 2).
    Рисунок 2. Мастер Configure automatic maintenance: страница Configure automatic maintenance
    Мастер Configure automatic maintenance: страница Configure automatic maintenance
    Мастер Configure automatic maintenance: страница Configure automatic maintenance
  4. Страница выбора режима работы позволяет вам продолжить настройку автоматического обслуживания или отключить эту функцию. Для продолжения настройки оставьте переключатель в положении Change automation settings и нажмите кнопку Next (рисунок 3). Обратите внимание, что отключение автоматического обслуживания просто обновит конфигурацию параметров базы данных, о которых говорилось в предыдущем разделе, установив их значения в OFF.
    Рисунок 3. Мастер Configure automatic maintenance: выбор режима работы автоматического обслуживания
    Мастер Configure automatic maintenance: выбор режима работы автоматического обслуживания
    Мастер Configure automatic maintenance: выбор режима работы автоматического обслуживания
  5. Страница настройки автоматического обслуживания.

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

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

    По умолчанию для всех баз данных DB2 устанавливается онлайновый интервал в режиме 24x7 (т. е. круглосуточно – все часы всех дней). Обычно этого достаточно для автоматического сбора статистики, поскольку таблицы остаются доступными для пользователей во время выполнения процессов runstats, а загрузку для этих процессов можно регулировать. Таким образом, можно управлять влиянием, оказываемым автоматическим сбором статистики на общую производительность системы. Для изменения онлайнового интервала нажмите кнопку Change, расположенную рядом с описанием Online maintenance window (рисунок 4).

    Рисунок 4. Мастер Configure automatic maintenance: задание расписания выполнения автоматического обслуживания
    Мастер Configure automatic maintenance: задание расписания выполнения автоматического обслуживания
    Мастер Configure automatic maintenance: задание расписания выполнения автоматического обслуживания

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

    Рисунок 5. Мастер Configure automatic maintenance: изменение свойств интервала обслуживания – создание расписания для онлайновых операций
    Мастер Configure automatic maintenance: изменение свойств интервала обслуживания – создание расписания для онлайновых операций
    Мастер Configure automatic maintenance: изменение свойств интервала обслуживания – создание расписания для онлайновых операций

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

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

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

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

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

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

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

    Рисунок 6. Мастер Configure automatic maintenance: управление списком уведомлений
    Мастер Configure automatic maintenance: управление списком уведомлений
    Мастер Configure automatic maintenance: управление списком уведомлений
  7. Страница настройки компонентов обслуживания.

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

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

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

    Рисунок 7. Мастер Configure automatic maintenance: страница Select a maintenance activity to configure
    Мастер Configure automatic maintenance: страница Select a maintenance activity to configure
    Мастер Configure automatic maintenance: страница Select a maintenance activity to configure

    В нижней части окна содержится описание параметров автоматического сбора статистики. Нажмите кнопку Configure Settings для открытия диалогового окна свойств.

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

    Рисунок 8. Мастер Configure automatic maintenance: оптимизация доступа к данным 1
    Мастер Configure automatic maintenance: оптимизация доступа к данным 1
    Мастер Configure automatic maintenance: оптимизация доступа к данным 1

    Вы можете снять флажок include system table. Это приведет к тому, что автоматический сбор статистики не будет выполняться для системных таблиц (рисунок 9).

    Рисунок 9. Мастер Configure automatic maintenance: оптимизация доступа к данным 2
    Мастер Configure automatic maintenance: оптимизация доступа к данным 2
    Мастер Configure automatic maintenance: оптимизация доступа к данным 2

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

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

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

    Рисунок 10. Мастер Configure automatic maintenance: просмотр параметров автоматического обслуживания
    Мастер Configure automatic maintenance: просмотр параметров автоматического обслуживания
    Мастер Configure automatic maintenance: просмотр параметров автоматического обслуживания
  9. Расширенная настройка.

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

    Рисунок 11. Мастер Configure automatic maintenance: оптимизация доступа к данным 3
    Мастер Configure automatic maintenance: оптимизация доступа к данным 3
    Мастер Configure automatic maintenance: оптимизация доступа к данным 3

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

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

    CREATE TABLE AUTO_RUNSTATS_CTL( TABSCHEMA VARCHAR(128), TABNAME VARCHAR(128))

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

    (TABSCHEMA, TABNAME) IN ( SELECT CTL.TABSCHEMA, 
    					CTL.TABNAME FROM AUTO_RUNSTATS_CTL AS CTL)

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

Настройка кучи для статистики STAT_HEAP_SZ

Параметр конфигурации базы данных STAT_HEAP_SZ определяет максимальный объем памяти, который будет использоваться при выполнении RUNSTATS. Это ограничение применяется как при ручном запуске RUNSTATS, так и при выполнении автоматического сбора статистики. Хотя значение по умолчанию (устанавливаемое при создании базы данных) во многих случаях оказывается достаточным, обычно оно слишком низкое для широких таблиц (таблиц, содержащих много столбцов). Всякий раз, когда выполнение команды RUNSTATS завершается с ошибкой из-за слишком низкого значения параметра STAT_HEAP_SZ, генерируется SQL-код SQL0973N. Когда автоматический сбор статистики не может выполнить команду RUNSTATS для таблицы из-за недостаточного количества памяти, выделяемого для кучи статистики, в журнал db2diag.log заносится следующая информация (листинг 2).

Листинг 2. Записи в журнале db2diag.log, указывающие на нехватку памяти для выполнения RUNSTATS
2007-03-23-23.49.33.244659-240 I1689777A368       LEVEL: Event
PID     : 1413486              TID  : 1286        PROC : db2acd
INSTANCE: popivan              NODE : 000
APPID   : *LOCAL.popivan.070324034939
FUNCTION: DB2 UDB, Automatic Table Maintenance, AtmTable::runstats, probe:500
START   : Automatic Runstats: runstats has started on table "SYSIBM  "."SYSTABLES"

2007-03-23-23.49.33.246227-240 I1690146A941       LEVEL: Error
PID     : 807008               TID  : 1           PROC : db2agent (A)
INSTANCE: popivan              NODE : 000         DB   : A
APPHDL  : 0-18                 APPID: *LOCAL.popivan.070324034939
AUTHID  : POPIVAN 
FUNCTION: DB2 UDB, relation data serv, sqlr_init_tstat, probe:160
MESSAGE : ZRC=0x8B120006=-1961754618=SQLR_STATS_HEAP_TOO_SMALL
          "Statistics heap size too small to begin with"
          DIA8328C No memory available in the statistics heap.
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
 sqlcaid : SQLCA     sqlcabc: 136   sqlcode: 0   sqlerrml: 0
 sqlerrmc: 
 sqlerrp : SQL09010
 sqlerrd : (1) 0x00000000      (2) 0x00000000      (3) 0x00000000
           (4) 0x00000000      (5) 0x00000000      (6) 0x00000000
 sqlwarn : (1)      (2)      (3)      (4)        (5)       (6)    
           (7)      (8)      (9)      (10)        (11)     
 sqlstate:      

2007-03-23-23.49.33.251552-240 I1691088A492       LEVEL: Error
PID     : 1413486              TID  : 1286        PROC : db2acd
INSTANCE: popivan              NODE : 000
APPID   : *LOCAL.popivan.070324034939
FUNCTION: DB2 UDB, Automatic Table Maintenance, AtmTable::runstats, probe:600
MESSAGE : ZRC=0xFFFFFC33=-973
DATA #1 : <preformatted>
AutoStats: Non zero code from Runstats
SQL0973N  Not enough storage is available in the "STAT_HEAP_SZ" heap to process 
the statement.  SQLSTATE=57011

2007-03-23-23.49.33.252357-240 I1691581A378       LEVEL: Event
PID     : 1413486              TID  : 1286        PROC : db2acd
INSTANCE: popivan              NODE : 000
APPID   : *LOCAL.popivan.070324034939
FUNCTION: DB2 UDB, Automatic Table Maintenance, AtmTable::runstats, probe:900

Хорошей практикой является упреждающее увеличение значения параметра STAT_HEAP_SZ. Исходя из нашего собственного опыта, значение, равное приблизительно 15,000, обеспечит достаточное количество памяти практически для всех случаев. Вы можете настроить параметр STAT_HEAP_SZ другим способом, выполнив ручной запуск RUNSTATS для самой широкой таблицы (таблицы, содержащей самое большое число столбцов). Сообщение об ошибке, возвращенное запущенной вручную командой RUNSTATS, содержит минимальное значение параметра STAT_HEAP_SZ, необходимое для выполнения RUNSTATS для данной таблицы.

Как же на самом деле работает auto-runstats (V8/V9)?

Счетчик UDI

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

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

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

DB2 сбрасывает счетчик UDI в конце каждой команды RUNSTATS. Таким образом, счетчик UDI является надежной единицей измерения того, насколько были изменены данные с момента последнего запуска RUNSTATS.

Текущее значение счетчика UDI можно проверить с помощью утилиты db2pd.

db2pd -db <имя БД> -tcbstats

В листинге 3 приведен пример вывода этой команды. Во втором разделе, TCB Table Stats, вы можете увидеть значения счетчика UDI для таблиц T1 и T2.

Листинг 3. Вывод команды db2pd
Database Partition 0 -- Database JITSDB -- Active -- Up 0 days 05:10:19

TCB Table Information:
Address            TbspaceID TableID PartID MasterTbs MasterTab TableName
0x0000002AD24FCED8 3         2       n/a    3         2         T1 
0x0000002AD24FBA58 3         3       n/a    3         3         T2

TCB Table Stats:
Address            TableName          Scans      UDI        
0x0000002AD24FCED8 T1                 1          3      
0x0000002AD24FBA58 T2                 1          3

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

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

Определение таблиц, для которых нужно собирать статистику

DB2 V8.2

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

  1. Проверка того, планируется ли оценка таблицы. Если оценка таблицы не планируется, то никакие дальнейшие действия не выполняются. Для отслеживания планирования оценки таблиц используется внутренняя таблица.
  2. Проверка того, производился ли доступ к таблице со стороны рабочей нагрузки.
  3. Проверка того, имеется ли статистика для таблицы. Если сбор статистики для данной таблицы никогда не выполнялся, для нее запускается RUNSTATS. Никаких дальнейших проверок не выполняется.
  4. Проверка того, превышает ли значение счетчика UDI число, равное 10% строк в таблице. Если нет, никакие действия для таблицы не выполняются.
  5. Проверка того, превышает ли значение счетчика UDI число, равное половине строк в таблице. Если да, выполняется запуск RUNSTATS.
  6. Запуск RUNSTATS, если таблица небольшая.
  7. Если таблица большая (содержит более 4000 страниц), она исследуется с целью принятия решения о необходимости выполнения RUNSTATS.
Рисунок 12. Блок-схема процесса определения таблиц, для которых необходимо собирать статистику в DB2 V8.2
Блок-схема процесса определения таблиц, для которых необходимо собирать статистику в DB2 V8.2
Блок-схема процесса определения таблиц, для которых необходимо собирать статистику в DB2 V8.2

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

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

Наоборот, если таблица не содержит изменений в статистике, ее оценка будет производиться реже. В DB2 V8.2 данная информация, связанная с историей и обслуживаемая функцией автоматического сбора статистики, является первичным фактором для определения того, должна ли та или иная таблица участвовать в процессе оценки. Если в соответствии с информацией об истории оценка таблицы не запланирована, автоматический сбор статистики не будет выполнять для нее какие-либо дальнейшие действия.

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

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

Если таблица содержит статистику, то следующим шагом выполняется проверка счетчика UDI. Сам по себе счетчик UDI не приносит большой пользы, поэтому автоматический сбор статистики рассматривает отношение UDI / Число элементов таблицы. Это отношение имеет большой смысл, поскольку по определению счетчик UDI представляет собой число UDI-операций, произошедших с момента выполнения последней команды runstats – момента, когда было подсчитано Число элементов таблицы. Существуют две важных величины: 10% и 50% (в будущем эти величины могут измениться). Если превышена последняя величина, статистика таблицы обновляется. С другой стороны, если число изменений меньше, чем нижняя величина (10%), принимается решение не запускать RUNSTATS, и автоматический сбор статистики переходит к следующей таблице.

Действия при попадании в "серую зону" (между 10 и 50%) зависят от размера таблицы. Автоматический сбор статистики различает большие и маленькие таблицы, размер которых определяется текущим числом физических страниц, выделенных для таблицы (это не значение из SYSCAT.TABLES.FPAGES, которое обновляется при каждом запуске RUNSTATS). Выполнение RUNSTATS для небольших таблиц обходится недорого, поэтому, если таблица небольшая, и для нее имеется более 10% изменений, RUNSTATS выполняется. В случаях больших таблиц необходимо собрать больше данных для выяснения необходимости обновления статистики. В этом случае автоматический сбор статистики исследует небольшую часть таблицы и собирает статистику для нее. RUNSTATS выполняется только тогда, когда статистика исследованной части существенно отличается от статистики таблицы.

DB2 9

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

  1. Проверка того, производился ли доступ к таблице со стороны рабочей нагрузки.
  2. Проверка того, имеется ли статистика для таблицы. Если сбор статистики для данной таблицы никогда не выполнялся, для нее запускается RUNSTATS. Никаких дальнейших проверок не выполняется.
  3. Проверка того, превышает ли значение счетчика UDI число, равное 10% строк в таблице. Если нет, никакие действия для таблицы не выполняются.
  4. Проверка того, превышает ли значение счетчика UDI число, равное половине строк в таблице. Если да, выполняется запуск RUNSTATS.
  5. Проверка того, планируется ли оценка таблицы. Если оценка таблицы не планируется, то никакие дальнейшие действия не выполняются. Для отслеживания планирования оценки таблиц используется внутренняя таблица.
  6. Запуск RUNSTATS, если таблица небольшая.
  7. Если таблица большая (содержит более 4000 страниц), она исследуется с целью принятия решения о необходимости выполнения RUNSTATS.
Рисунок 13. Блок-схема процесса определения таблиц, для которых необходимо собирать статистику в DB2 9
Блок-схема процесса определения таблиц, для которых необходимо собирать статистику в DB2 9
Блок-схема процесса определения таблиц, для которых необходимо собирать статистику в DB2 9

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

Начиная с DB2 9, автоматический сбор статистики проверяет, превышает ли коэффициент UDI / Число элементов таблицы 50% до того, как обратится к информации с историей. Таким образом, данный процесс может быстрее реагировать на массовые изменения в таблицах. Запуск RUNSTATS будет произведен в течение двух часов после того как коэффициент UDI превысит пороговое значение.

Модель процесса автоматического сбора статистики

Механизм оценки, по которому работает автоматический сбор статистики, представляет собой поток, выполняющийся в процессе Health Monitor на узле каталога. В DB2 V8.2 процесс Health Monitor назывался db2hmon, но в DB2 9 он был переименован в db2acd. Для каждой базы данных существует один поток автоматического сбора статистики, и он поддерживает подключение к базе данных на протяжении процесса оценки.

Автоматический сбор статистики в средах с функцией разбиения данных (Data partitioning feature, DPF)

RUNSTATS в среде DPF
Для таблиц, расположенных в разных разделах, RUNSTATS собирает статистику только в одном разделе. В конце собранная статистика экстраполируется, и при этом предполагается, что разделы единообразны. Например, если в разделе, в котором выполняется RUNSTATS, имеется 1000 страниц с данными (NPAGES), и если таблица распределена между пятью разделами, то RUNSTATS будет предполагать, что в сумме таблица имеет 5000 страниц, и это будет значением, хранящимся в столбце SYSCAT.TABLES.NPAGES.

Если при запуске RUNSTATS на выполнение таблица существует в разделе координатора (разделе, к которому подключен пользователь), то RUNSTATS будет выполняться в разделе координатора. Иначе сбор статистики будет выполняться в первом разделе таблицы.

Рассмотрим среду DPF с пятью разделами и таблицей, распределенной между тремя из них: разделами с номерами 2, 3 и 4. Если пользователь подключается к разделу 3 и запускает для этой таблицы RUNSTATS, то сбор статистики будет выполняться с использованием данных таблицы, расположенных в разделе 3. Однако если пользователь подключается к разделу 0, то RUNSTATS будет собирать статистику, используя данные таблицы, расположенные в разделе 2.

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

Базы данных могут быть активизированы либо явным образом (с использованием команды ACTIVATE DATABASE, которая в средах DPF активизирует базу данных на всех разделах), либо неявно (база данных активизируется при первом подключении и активна только на тех разделах, к которым подключаются приложения). Чтобы получить максимальную выгоду от использования автоматического сбора статистики в среде DPF, базу данных следует активизировать явным образом. Это можно сделать с помощью следующей команды:

ACTIVATE DATABASE <имя БД>

DB2 V8.2

При попытке проверить счетчик UDI для таблицы, которая определена в нескольких разделах, при наличии раздела, на котором база данных не активна, в DB2 V8.2 автоматический сбор статистики зафиксирует приведенную ниже ошибку. Данные сообщения об ошибках могут заполнить журнал db2diag.log и занять много места (в особенности, в системах с большим числом таблиц). Если вы обнаружите, что эти сообщения заполняют ваш журнал db2diag.log, подумайте над тем, чтобы активизировать вашу базу данных явным образом (листинг 4).

Листинг 4. Сообщения об ошибках в журнале db2diag.log, появляющиеся после проверки счетчика UDI и показывающие, что раздел, содержащий базу данных, не активен
2006-12-27-11.11.47.529451-360 I90873A383         LEVEL: Error
PID     : 3285062              TID  : 1           PROC : db2pdbc 3
INSTANCE: diedwi1              NODE : 003
FUNCTION: DB2 UDB, base sys utilities, sqleRunPdbSysCtlr, probe:67
MESSAGE : Request discarded by Controller at =
DATA #1 : Hexdump, 4 bytes
0x0FFFFFFFFFFF7F78 : 0000 000E                                  ....

DB2 9

В случае если некоторые из разделов таблицы не активизированы, в журнал db2diag.log не будут занесены никакие сообщения об ошибках.

Профиль RUNSTATS

Настройка профиля RUNSTATS

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

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

RUNSTATS ON TABLE DB2USER.EMPLOYEE WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50 
SET PROFILE

Для использования профиля используйте следующую команду:

RUNSTATS ON TABLE DB2USER.EMPLOYEE USE PROFILE

Вы можете запросить профиль, связанный с таблицей EMPLOYEE:

SELECT SUBSTR(STATISTICS_PROFILE, 1, 150) AS STATISTICS_PROFILE FROM SYSCAT.TABLES 
WHERE TABNAME = 'EMPLOYEE'

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

STATISTICS_PROFILE
-----------------------------------------------------------------------
RUNSTATS ON TABLE "DB2USER"."EMPLOYEE" ON ALL COLUMNS WITH DISTRIBUTION 
ON ALL COLUMNS DEFAULT NUM_FREQVALUES 50

Как автоматический сбор статистики применяет профиль

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

RUNSTATS ON TABLE DB2USER.EMPLOYEE WITH DISTRIBUTION AND SAMPLED DETAILED INDEXES ALL

Регулирование загрузки в RUNSTATS

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

Для настройки и применения регулирования загрузки нужно выполнить два шага.

  • Шаг 1. Настройка параметра конфигурации политики воздействия экземпляра:
    UPDATE DBM CFG USING UTIL_IMPACT_LIM 10

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

  • Шаг 2. Запуск утилиты с ненулевым приоритетом. Например:
    RUNSTATS ON TABLE DB2USER.EMPLOYEE WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50 
    UTIL_IMPACT_PRIORITY 60

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

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

Регулирование загрузки в процессе автоматического сбора статистики отличается от такового в случае с RUNSTATS. Автоматический сбор статистики использует фиксированный уровень воздействия, равный 7%, независимо от того, какое значение установлено в UTIL_IMPACT_LIM. Такой подход гарантирует, что автоматический сбор статистики не оказывает значительного воздействия на рабочую нагрузку, даже если он выполняется в рабочее время (рисунок 14).

Рисунок 14. Регулирование загрузки в процессе автоматического сбора статистики
Регулирование загрузки в процессе автоматического сбора статистики
Регулирование загрузки в процессе автоматического сбора статистики

Автоматический сбор статистики и временные таблицы

Таблица SYSCAT.TABLES содержит столбец под названием volatile. Значением по умолчанию для этого столбца является пробел. Другим единственным значением на сегодняшний день является 'C', что говорит DB2 о том, что таблица содержит ряд временных элементов. Другими словами, при выборе наилучшего доступа к таблице DB2 не должна полагаться на временную статистику. По этой же причине автоматический сбор статистики не выполняет сбор статистики для временных таблиц.

Мониторинг

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

Снимки состояния и индикатор состояния автоматического сбора статистики

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

Текущее значение индикатора состояния можно получить с помощью снимка состояния. В этой статье мы рассмотрим получение снимка состояния из командной строки.

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

GET HEALTH SNAPSHOT FOR DATABASE ON <ИМЯ БД>

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

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

Листинг 5. Вывод снимка состояния базы данных
GET HEALTH SNAPSHOT FOR DB ON SAMPLE

                          Database Health Snapshot

Snapshot timestamp                         = 04/10/2007 12:18:00.918375

Database name                              = SAMPLE
Database path                              = /home/ivannp/ivannp/NODE0000/SQL00004/
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_runstats_req
       Value                                   = 1
       Evaluation timestamp                    = 04/10/2007 12:17:44.662893
       Alert state                             = Attention

          Collection:

             Name                              = "DBUSER"."EMPLOYEE"
             Detail                            = RUNSTATS
             State                             = Automation failed
             Evaluation timestamp              = 04/10/2007 12:17:45.000000

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

Листинг 6. Вывод снимка состояния базы данных
Snapshot timestamp                         = 04/10/2007 12:18:00.918375

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

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

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

    Indicator Name                             = db.tb_runstats_req
       Value                                   = 1
       Evaluation timestamp                    = 04/10/2007 12:17:44.662893
       Alert state                             = Attention

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

Листинг 8. Снимок состояния, показывающий, что сбор статистики завершился с ошибкой
Name                              = "DBUSER"."EMPLOYEE"
Detail                            = RUNSTATS
State                             = Automation failed
Evaluation timestamp              = 04/10/2007 12:17:45.000000

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

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

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

GET HEALTH SNAPSHOT FOR DATABASE ON <ИМЯ БД> WITH FULL COLLECTION

Теперь вывод индикатора состояния db.tb_runstats_req содержит одну запись для каждой таблицы области, для которой назначен автоматический сбор статистики. Аналогично записям для таблиц, для которых требуется запуск runstats, из этого вывода вы можете узнать время, когда была выполнена последняя оценка таблицы на предмет необходимости выполнения RUNSTATS.

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

Листинг 9. Пример 1 – база данных не активна, никакая информация снимка состояния не возвращается
GET HEALTH SNAPSHOT FOR DB ON SAMPLE
SQL1611W  No data was returned by Database System Monitor
Листинг 10. Пример 2 – база данных активна, но автоматический сбор статистики еще не произвел оценку (например, база данных еще не была активна)
GET HEALTH SNAPSHOT FOR DB ON SAMPLE

             Database Health Snapshot

Snapshot timestamp                         = 04/10/2007 11:39:30.733561

Database name                              = SAMPLE
Database path                              = /home/ivannp/ivannp/NODE0000/SQL00004/
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
Листинг 11. Пример 3 – снимок состояния: автоматический сбор статистики работает правильно, ручной запуск RUNSTATS не требуется
GET HEALTH SNAPSHOT FOR DB ON SAMPLE

             Database Health Snapshot

Snapshot timestamp                         = 04/10/2007 11:53:30.741181

Database name                              = SAMPLE
Database path                              = /home/ivannp/ivannp/NODE0000/SQL00004/
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_runstats_req
       Value                                   = 0
       Evaluation timestamp                    = 04/10/2007 11:52:43.336809
       Alert state                             = Normal
Листинг 12. Пример 4 – снимок состояния: автоматический сбор статистики завершился с ошибкой
GET HEALTH SNAPSHOT FOR DB ON SAMPLE

                          Database Health Snapshot

Snapshot timestamp                         = 04/10/2007 12:18:00.918375

Database name                              = SAMPLE
Database path                              = /home/ivannp/ivannp/NODE0000/SQL00004/
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_runstats_req
       Value                                   = 1
       Evaluation timestamp                    = 04/10/2007 12:17:44.662893
       Alert state                             = Attention

          Collection:

             Name                              = "DBUSER"."EMPLOYEE"
             Detail                            = RUNSTATS
             State                             = Automation failed
             Evaluation timestamp              = 04/10/2007 12:17:45.000000

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

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

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

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

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

Настройка индикатора состояния db.tb_runstats_req

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

Листинг 13. Проверка конфигурации dbm с целью проверки статуса монитора состояния
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) =

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

UPDATE DBM CONFIG USING HEALTH_MON ON

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

Листинг 14. Проверка конфигурации alert с целью проверки статуса индикатора состояния
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_runstats_req
      Default                        = Yes     
      Type                           = Collection state-based
      Sensitivity                    = 0
      Actions                        = Disabled
      Threshold or State checking    = Enabled

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

UPDATE ALERT CONFIG FOR DATABASE ON <ИМЯ БД> USING db.tb_runstats_req 
SET THRESHOLDSCHECKED YES

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

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

Автоматический сбор статистики выводит сообщения запуска и останова каждый раз, когда для таблицы запускается RUNSTATS. Таким образом, неявным способом проверить, включен ли автоматический сбор статистики, служит поиск такого сообщения в журнале db2diag.log (листинг 15).

Листинг 15. Поиск сообщений RUNSTATS в журнале db2diag.log
2007-04-21-10.03.29.160856-240 I351795A369        LEVEL: Event
PID     : 332048               TID  : 1326        PROC : db2acd
INSTANCE: ayyang               NODE : 000
APPID   : *LOCAL.ayyang.070421140401
FUNCTION: DB2 UDB, Automatic Table Maintenance, AtmTable::runstats, probe:500
START   : Automatic Runstats: runstats has started on table "SYSIBM  "."SYSCONSTDEP"

2007-04-21-10.03.30.156007-240 I352165A380        LEVEL: Event
PID     : 332048               TID  : 1326        PROC : db2acd
INSTANCE: ayyang               NODE : 000
APPID   : *LOCAL.ayyang.070421140401
FUNCTION: DB2 UDB, Automatic Table Maintenance, AtmTable::runstats, probe:900
STOP    : Automatic Runstats: runstats completed successfully on table "SYSIBM  
"."SYSCONSTDEP"

Дополнительная информация

Распространенные сообщения об ошибках и предупреждения

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

Распространенные ошибки и предупреждения включают в себя сообщения SQL2314W, SQL0911N и SQL0973N.

SQL2314W

Некоторые данные статистики находятся в противоречивом состоянии. Вновь собранная статистика "<объекта1>" противоречит статистике существующего "<объекта2>".

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

Действия пользователя:

  1. Запустите RUNSTATS для сбора статистики как на уровне таблицы, так и на уровне индекса.
  2. Выполняйте сбор статистики, когда производится минимальное число операций вставки, обновления и удаления строк, либо когда они не производятся вообще. Если же параллельные операции вставки, обновления или удаления необходимы, запускайте RUNSTATS с опцией ALLOW READ ACCESS.
  3. Увеличьте объем выборки или, если команда RUNSTATS была запущена с опцией TABLESAMPLE SYSTEM, используйте вместо нее опцию TABLESAMPLE BERNOULLI.

SQL0911N (листинг 16).

Листинг 16. Сообщение об ошибке SQL0911N
2007-04-10-12.00.48.223887-240 I20011A505         LEVEL: Error
PID     : 1175872              TID  : 1060        PROC : db2acd
INSTANCE: ivannp               NODE : 000
APPID   : *LOCAL.ivannp.070410160045
FUNCTION: DB2 UDB, Automatic Table Maintenance, atmRefreshInfoTable, probe:300
MESSAGE : ZRC=0xFFFFFC71=-911
DATA #1 : <preformatted>
AutoStats: [IBM][CLI Driver][DB2/AIX64] SQL0911N  The current transaction has been rolled
 back because of a deadlock or timeout.  Reason code "68".  SQLSTATE=40001

Это новое сообщение в DB2 9. Во время обработки таблиц ожидание блокировки автоматическим сбором статистики может завершиться. Оценка, выполняемая автоматическим сбором статистики, запускается со временем ожидания блокировки, равным 5 секундам. Если время ожидания получения блокировки в процессе оценки превышает 5 секунд, возникает ошибка -911. Вы можете проигнорировать это сообщение, поскольку оценка выполняется каждые два часа, и сбор статистики может быть выполнен при последующих оценках.

SQL0973N (листинг 17).

Листинг 17. Сообщение об ошибке SQL0973N
2007-03-23-23.49.33.251552-240 I1691088A492       LEVEL: Error
PID     : 1413486              TID  : 1286        PROC : db2acd
INSTANCE: popivan              NODE : 000
APPID   : *LOCAL.popivan.070324034939
FUNCTION: DB2 UDB, Automatic Table Maintenance, AtmTable::runstats, probe:600
MESSAGE : ZRC=0xFFFFFC33=-973
DATA #1 : <preformatted>
AutoStats: Non zero code from Runstats
SQL0973N  Not enough storage is available in the "STAT_HEAP_SZ" heap to process the 
statement.  SQLSTATE=57011

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

Работа с операторами DDL

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

Заключение

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

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

Мы хотели бы выразить признание и благодарность Иоахиму Пфефферле (Joachim Pfefferle) за рецензирование этой статьи.


Ресурсы для скачивания


Похожие темы

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=398525
ArticleTitle=Автоматическое обслуживание таблиц в DB2: Часть 1. Автоматический сбор статистики в DB2 для платформ Linux, UNIX и Windows
publish-date=06222009