Руководство администратора: Производительность

| | |

Утилита ограничения ресурсов

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

| |

Прим.:

Снимки запросов, создаваемые ограничителем ресурсов во время работы, могут |повлиять на производительность. Для увеличения производительности увеличьте интервал работы |ограничителя ресурсов - это уменьшит нагрузку на процессор.

Демоны ограничителей ресурсов генерируют при работе ЛОКАЛЬНЫЕ снимки в локальный экземпляр. |Поэтому, любые правила, содержащие условия setlimit, применяются к выводу от |ЛОКАЛЬНОГО снимка, а не к сводному результату от ГЛОБАЛЬНЫХ снимков.

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

| | |

Выбор способа реорганизации таблицы

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

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

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

Совет: Реорганизацию на месте следует выбирать, если система работает |непрерывно с минимальными перерывами на обслуживание.

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

Подробная информация по применению этих способов реорганизации приведена в |описании синтаксиса команды REORG TABLE.

| | |

Поддержка больших страниц для памяти FCM (AIX 5L, 64-битная)

В 64-битной системе AIX^(R) 5L переменная реестра DB2_LARGE_PAGE_MEM теперь поддерживает ключевое слово FCM.

По умолчанию в 64-битной системе AIX 5L^(TM) память FCM располагается в наборе памяти СУБД. Однако если включена переменная реестра DB2_FORCE_FCM_BP, память FCM располагается в своем собственном наборе памяти. В 64-битной системе AIX 5L переменная реестра DB2_LARGE_PAGE_MEM поддерживает спецификацию набора памяти СУБД. Если память FCM располагается в наборе памяти СУБД, |и для этого набора памяти включена поддержка больших страниц, память FCM будет располагаться |на больших страницах. Если же память FCM располагается в своем собственном наборе памяти, |чтобы включить для нее поддержку больших страниц, в переменную реестра DB2_LARGE_PAGE_MEM надо добавить |ключевое слово FCM.

В файле, указанном в переменной реестра DB2_RESOURCE_POLICY, можно использовать новый элемент

Начиная с DB2 Universal Database^(TM) (UDB) Версии 8.2.2 (эквивалентна Версии 8.1 FixPak 9), в файле конфигурации, заданном в переменной реестра DB2_RESOURCE_POLICY, можно использовать элемент SCHEDULING_POLICY. Элемент SCHEDULING_POLICY можно использовать на некоторых платформах для выбора:

Правил планировщика операционной системы, используемых сервером DB2 UDB
Прим.:

Возможность задавать правила планировщика операционной системы теперь есть и в DB2 for AIX^(R). Ранее эта возможность была доступна только в DB2 UDB for Windows^(R) (при помощи переменной реестра DB2NTPRICLASS).
Приоритетов операционной системы, используемых отдельными агентами сервера DB2

Переменные реестра DB2PRIORITIES и DB2NTPRICLASS можно использовать по отдельности для управления правилами планировщика операционной системы и задания приоритетов агентов DB2.

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

Пример 1

Выбор правил планировщика AIX SCHED_FIFO2 и повышение приоритета для процессов записи и чтения журнала db2:

<RESOURCE_POLICY>
   <SCHEDULING_POLICY>
      <POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
      <PRIORITY_VALUE>60</PRIORITY_VALUE>

      <EDU_PRIORITY>
         <EDU_NAME>db2loggr</EDU_NAME>
         <PRIORITY_VALUE>56</PRIORITY_VALUE>
      </EDU_PRIORITY>

      <EDU_PRIORITY>
         <EDU_NAME>db2loggw</EDU_NAME>
         <PRIORITY_VALUE>56</PRIORITY_VALUE>
      </EDU_PRIORITY>
   </SCHEDULING_POLICY>
</RESOURCE_POLICY>

Пример 2

Замена переменной DB2NTPRICLASS=H в Windows.

<RESOURCE_POLICY>
   <SCHEDULING_POLICY>
      <POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
   </SCHEDULING_POLICY>
</RESOURCE_POLICY>

Новые системные переменные среды (Linux)

В FixPak 8 добавлены системные переменные среды DB2_MAPPED_BASE и DB2DBMSADDR.

Использовать эти переменные реестра рекомендуется только опытным пользователям.

DB2_MAPPED_BASE

Имя переменной

DB2_MAPPED_BASE

Значения

0 ИЛИ шестнадцатеричный виртуальный адрес в 31-битном или 32-битном диапазоне адресов ИЛИ NULL (не задана)

Операционные системы

Linux на x86 и Linux на zSeries (31-битная)

Описание

Переменную реестра DB2_MAPPED_BASE можно использовать для увеличения размера непрерывного пространства виртуальных адресов, доступного для процесса DB2 Universal Database (UDB), изменив положение адреса подключения совместно используемых библиотек для конкретного процесса. Непрерывность пространства виртуальных адресов важна для максимизации доступного для DB2 UDB объема совместной памяти базы данных. Эта переменная действует только в дистрибутивах, содержащих файл mapped_base в каталоге идентификации процесса в файловой системе процесса.

Если эта переменная не задана, DB2 UDB попытается использовать для положения совместно используемых библиотек виртуальный адрес 0x10000000.

В этой переменной реестра можно также задать любой виртуальный адрес (в шестнадцатеричной форме) в диапазоне 31- и 32-битного адресного пространства.

Прим.:

Неверный адрес может вызвать серьезные проблемы с DB2 UDB - от невозможности запустить DB2 UDB до невозможности соединиться с базой данных. Неверный адрес - это адрес, попадающий в область памяти, которая уже используется или предназначена для другого использования. Чтобы исправить такую проблему, задайте для переменной DB2_MAPPED_BASE пустое значение следующей командой:

db2set DB2_MAPPED_BASE=

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

ADM0506I  DB2 has automatically updated the "mapped_base" 
kernel parameter from "0x40000000(hex) 1073741824(dec)" to 
the recommended value "0x10000000(hex) 268435456(dec)".
(ADM0506I  DB2 автоматически изменила значение параметра
ядра "mapped_base" с "0x40000000(hex) 1073741824(dec)" на
рекомендованное значение "0x10000000(hex) 268435456(dec)".)

Это сообщение выводится только при успешном задании переменной реестра; в нем указывается адрес, на который перемещены совместно используемые библиотеки.

DB2DBMSADDR

Имя переменной

DB2DBMSADDR

Значения

Виртуальные адреса в диапазоне от 0x09000000 до 0xB0000000 с шагом 0x10000

Операционные системы

Linux на x86 и Linux на zSeries (31-битная)

Описание

Задает адрес по умолчанию совместной памяти базы данных в шестнадцатеричном формате.

Прим.:

Неверный адрес может вызвать серьезные проблемы с DB2 UDB - от невозможности запустить DB2 UDB до невозможности соединиться с базой данных. Пример неверного адреса - адрес, попадающий в область памяти, которая уже используется или предназначена для другого использования. Чтобы исправить эту проблему, задайте для переменной DB2DBMSADDR пустое значение следующей командой:

db2set DB2DBMSADDR=

Эту переменную можно задавать вместе с DB2_MAPPED_BASE или отдельно для тонкой настройки адресного пространства процессов DB2 UDB. Эта переменная изменяет положение совместной памяти экземпляра с его текущего положения по виртуальному адресу 0x20000000 на заданное новое положение.

Новая переменная связи в реестре

В Версии 8.2 добавлена переменная реестра DB2TCP_CLIENT_RCVTIMEOUT.

Табл. 12. Переменные связи
Имя переменной	Операционные системы	Значения
Описание
DB2TCP_CLIENT_RCVTIMEOUT	Все	По умолчанию - 0 (не задано) Значения: от 0 до 32767 секунд
Задает срок в секундах ожидания клиентом получения данных программой приема TCP/IP. Сообщения об истечении срока не будет, если переменная реестра не задана или если задано значение 0. Если программа приема TCP/IP вернет данные до истечения заданного срока, прикладная программа продолжит работу как обычно. Если срок истечет до возврата данных, соединение будет закрыто. Прим.: Эта переменная реестра применима только к клиенту DB2 и на стороне клиента DB2. Она не применяется к серверу DB2.

Новая переменная производительности

В Версии 8.2 добавлена переменная производительности DB2_LARGE_PAGE_MEM.

Табл. 13. Переменные производительности
Имя переменной	Операционные системы	Значения
Описание
DB2_LARGE_PAGE_MEM	AIX 5.x (только 64-битная) Linux	По умолчанию - NULL Используйте *, чтобы указать, что все соответствующие регионы памяти должны использовать память с большими страницами, или перечислите через запятую конкретные регионы памяти. Доступные регионы зависят от операционной системы. В 64-битной AIX 5.x можно задать следующие регионы: DB, DBMS, PRIVATE. В Linux можно задать следующий регион: DB.
Память с большими страницами поддерживается только для DB2 Universal Database (UDB) for AIX 5L (64-битное издание) и DB2 UDB for Linux. Переменная реестра DB2_LARGE_PAGE_MEM используется для включения поддержки больших страниц при работе в AIX 5.x или в любой архитектуре Linux с соответствующей поддержкой ядра. Эта переменная реестра заменяет устаревшую переменную реестра DB2_LGPAGE_BP, которую можно использовать только для включения памяти с большими страницами для совместного региона памяти базы данных. Теперь это можно включить, задав переменную DB2_LARGE_PAGE_MEM=DB. Документацию, где упоминается включение больших страниц при помощи переменной реестра DB2_LGPAGE_BP, теперь следует читать как DB2_LARGE_PAGE_MEM=DB. Использование больших страниц предназначено в первую очередь для повышения производительности в программах с интенсивными вычислениями. Программы, часто обращающиеся к памяти и использующие большие объемы виртуальной памяти, при применении больших страниц могут работать производительнее. Чтобы включить использование больших страниц в DB2 UDB, надо сначала сконфигурировать использование больших страниц в операционной системе. Включение собственных больших страниц существенно увеличит использование памяти DB2 UDB, поскольку каждый агент DB2 UDB займет не менее 1 большой страницы физической памяти (16 Мбайт). Чтобы включить большие страницы для собственной памяти агента в 64-битной DB2 UDB for AIX (параметр DB2_LARGE_PAGE_MEM=PRIVATE), необходимо выполнение следующих условий, помимо конфигурирования больших страниц в операционной системе: Владелец экземпляра должен обладать возможностями CAP_BYPASS_RAC_VMM и CAP_PROPOGATE. Ядро должно поддерживать интерфейсы, которые допускают, чтобы процесс изменял свой размер страниц во время выполнения. . В 64-битной DB2 UDB for AIX включение этой переменной уменьшает размер сегмента совместной памяти, сводя к минимуму требования памяти для базы данных. По умолчанию создается сегмент 64 Гбайт: подробности смотрите в информации о параметре размера совместной памяти баз данных (параметр конфигурации базы данных database_memory). Использование этой возможности позволяет избежать выделения совместной оперативной памяти сверх ожидаемой потребности. При задании этой переменной будет ограничена возможность динамического изменения конфигурации, связанного с увеличением общего объема совместной памяти базы данных (например, увеличения размера пулов буферов). В Linux есть дополнительное требование - доступность библиотеки libcap.so. Чтобы эта опция работала, необходимо установить данную библиотеку. Если эта опция будет включена, а библиотеки в системе не будет, DB2 UDB выключит большие страницы ядра и продолжит работать, как раньше. В Linux для проверки доступности больших страниц ядра введите команду: cat /proc/meminfo Если возможность доступна, должны появиться следующие три строки (числа будут зависеть от объема памяти, сконфигурированного на вашем компьютере): HugePages_Total: 200 HugePages_Free: 200 Hugepagesize: 16384 KB Если вы не увидите этих строк, или если значение HugePages_Total - 0, требуется конфигурирование операционной системы или ядра.

Переменные компилятора SQL

Следующее изменение относится к теме "Переменные компилятора SQL" в Приложении A "Переменные реестра DB2 и среды" книги Руководство администратора: Производительность:

Если для одной или обеих переменных компилятора DB2 DB2_MINIMIZE_LISTPREFETCH и DB2_INLIST_TO_NLJN задано значение ON, эти переменные будут активны, даже если задано REOPT(ONCE).

Изменения в параметрах конфигурации

Ниже указаны изменения в документации по параметрам конфигурации:

authentication - Тип аутентификации

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

DATA_ENCRYPT
Сервер принимает зашифрованные схемы аутентификации типа SERVER и зашифрованные пользовательские данные. Аутентификация работает точно так же, как при типе аутентификации SERVER_ENCRYPT.

При этом типе аутентификации шифруются следующие пользовательские данные:
- Операторы SQL.
- Переменные данные программ SQL.
- Выходные данные сервера, обрабатываемые оператором SQL, включая описание этих данных.
- Некоторые или все данные набора ответов на запрос.
- Поток данных больших объектов (LOB).
- Дескрипторы SQLDA.
DATA_ENCRYPT_CMP
Сервер принимает зашифрованные схемы аутентификации типа SERVER и зашифрованные пользовательские данные. Кроме того, этот тип аутентификации обеспечивает совместимость с ранними продуктами, не поддерживающими тип аутентификации DATA_ENCRYPT. Этим продуктам разрешено устанавливать соединение с помощью типа аутентификации SERVER_ENCRYPT и без шифрования пользовательских данных. Продукты, поддерживающие новый тип аутентификации, должны использовать его. Этот тип аутентификации допустим только в файле конфигурации менеджера баз данных сервера; он недопустим в команде CATALOG DATABASE.

util_impact_lim - Правила влияния для экземпляра

Начиная с DB2 Universal Database Версии 8.2, значение по умолчанию параметра конфигурации менеджера баз данных Правила влияния для экземпляра (util_impact_lim) изменено со 100 на 10.

sysadm_group, sysmaint_group, sysctrl_group, sysmon_group

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

Имя группы с полномочиями администратора системы (sysadm_group)
Имя группы с полномочиями обслуживания системы (sysmaint_group)
Имя группы с полномочиями управления системой (sysctrl_group)
Имя группы с полномочиями мониторинга системы (sysmon_group)

Таблица в теме "Обзор параметров конфигурации менеджера баз данных" содержит неверные типы данных для этих параметров конфигурации менеджера баз данных. Правильный тип данных для всех этих параметров - char(30).

estore_seg_sz - Размер сегмента расширения памяти

Максимальный размер для параметра конфигурации базы данных Размер сегмента расширения памяти (estore_seg_size) на платформах на основе Windows равен 16777216.

hadr_timeout - Значение срока ожидания HADR

Правильное максимальное значение для параметра конфигурации базы данных Значение срока ожидания HADR (hadr_timeout) - 4294967295.

locklist - Максимальный объем списка блокировок

В документации сказано, что максимальное значение для параметра конфигурации базы данных Максимальный объем списка блокировок (locklist) для 64- и 32-битных серверов Windows, обслуживающих только локальных клиентов, равно 60000. Это неверное значение; правильное число - 524288.

num_db_backups - Число резервных копий базы данных

Неверно указан диапазон значений для параметра конфигурации базы данных Число резервных копий базы данных (num_db_backups). Правильный диапазон: 0 - 32767.

Файл параметров конфигурации базы данных SQLDBCONF

После перенастройки DB2 Universal Database (UDB) из Версии 8.1 в Версию 8.2, DB2 UDB использует новый файл параметров конфигурации базы данных с именем SQLDBCONF и размером 16 Кбайт. (В Версии 8.1 файл параметров конфигурации базы данных имел размер только 4 Кбайта и назывался SQLDBCON).

Изменение значения по умолчанию DB2_HASH_JOIN

В Версии 8.1 переменная реестра DB2_HASH_JOIN имела по умолчанию значение ON.

Используйте эту переменную хеш-объединения, настроив ее значение для оптимальной производительности.

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

Дополнительную информацию смотрите в теме "Методы объединения" в книге Руководство администратора: Производительность.

Переменная реестра DB2NTNOCACHE устарела

Функции DB2NTNOCACHE доступны теперь на уровне табличного пространства путем задания условия NO FILE SYSTEM CACHING в операторе CREATE TABLESPACE или ALTER TABLESPACE. Использование этого условия описано в справочнике SQL Reference. В следующем выпуске переменная реестра DB2NTNOCACHE будет удалена.

Таблицы объяснения и организация информации объяснений

Таблицы объяснения могут применяться совместно несколькими пользователями. Но задавать таблицы объяснения можно для одного пользователя, а для дополнительных пользователей для указания заданных таблиц использовать алиасы с тем же именем. Другой вариант - задать таблицы объяснения в схеме SYSTOOLS. Функция объяснения использует по умолчанию схему SYSTOOLS, если не найдено других таблиц объяснения или алиасов под ID сеанса пользователя для динамического SQL или ID авторизации оператора для статического SQL. Каждый пользователь, имеющий в совместном пользовании общие таблицы объяснения, должен иметь разрешение на вставку в эти таблицы. Следует также ограничить разрешения на чтение для общих таблиц объяснения - обычно можно ограничить теми пользователями, которые анализируют информацию объяснения.

Дополнительные коды возврата из API db2CfgGet, параметр collate_info

Параметр информации упорядочивания можно вывести только при помощи API db2CfgGet. Его нельзя вывести при помощи процессор командной строки или Центр управления.

Тип конфигурации: База данных
Тип параметра: Информационный

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

Последние 4 байта содержат внутреннюю информацию о типе последовательности упорядочения. Последние четыре байта collate_info - целое число. Это целое число зависит от порядка разделения на байты на данной платформе. Возможные значения:

0 - Последовательность содержит неуникальные веса
1 - Все веса последовательности уникальны
2 - Последовательность является последовательностью идентификации, строки которой сравниваются побайтно.
3 - Последовательность - NLSCHAR, используемая для сортировки в базах данных с тайским набором символов TIS620-1 (кодовая страница 874).
4 - Последовательность - IDENTITY_16BIT, реализующая алгоритм схемы "CESU-8 Compatibility Encoding Scheme for UTF-16: 8-Bit" (совместимая схема кодирования для UTF-16, 8-битная); ее спецификация включена в отчет Unicode Technical Report #26, доступный на сайте Unicode Technical Consortium http://www.unicode.org.
X'8001' - Последовательность - UCA400_NO, которая реализует алгоритм UCA (Unicode Collation Algorithm, Алгоритм упорядочивания Unicode), основанный на стандарте Unicode Standard версии 4.00 с неявно заданной нормализацией ON.
X'8002' - Последовательность - UCA400_LTH, которая реализует алгоритм UCA (Unicode Collation Algorithm, Алгоритм упорядочивания Unicode), основанный на стандарте Unicode Standard версии 4.00, и сортирует тайские символы, как принято в королевском тайском словаре (Royal Thai Dictionary).
X'8003' - Последовательность - UCA400_LSK, которая реализует алгоритм UCA (Unicode Collation Algorithm, Алгоритм упорядочивания Unicode), основанный на стандарте Unicode Standard версии 4.00, и правильно сортирует все словацкие символы.

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

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

Автоматическое задание размера предварительной выборки по умолчанию и значений по умолчанию для изменения

Начиная с DB2 Universal Database (UDB) Версии 8.2, можно использовать для табличного пространства размер предварительной выборки AUTOMATIC. DB2 UDB автоматически изменяет размер предварительной выборки, когда в табличном пространстве изменяется число контейнеров.

Синтаксис переменной реестра DB2_PARALLEL_IO расширен для возможности распознавания контейнеров с различными характеристиками параллелизма ввода-вывода. При использовании расширенного синтаксиса у контейнеров для различных табличных пространств могут быть различные характеристики ввода-вывода. Характеристика параллелизма ввода-вывода каждого табличного пространства используется, если для табличного пространства задается автоматический размер предварительной выборки (AUTOMATIC). Если переменная реестра DB2_PARALLEL_IO включена, но расширенный синтаксис, идентифицирующий конкретные характеристики параллелизма ввода-вывода, не используется, предполагается уровень параллелизма по умолчанию. По умолчанию используется уровень параллелизма RAID 5 (6+1).

Информация о размере предварительной выборки, используемая оптимизатором, обновляется только при выполнении оператора ALTER TABLESPACE, который изменяет размер предварительной выборки табличного пространства или число контейнеров (при помощи ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET). Если в параметрах реестра изменяется число физических дисков на контейнер, для обновления информации оптимизатора надо запустить оператор ALTER TABLESPACE <имя_табличного_пространства> PREFETCHSIZE AUTOMATIC (если только обновление информации оптимизатора не было уже задано в операторе ALTER TABLESPACE).

Если табличное пространство перенаправляется или восстанавливается для возможности использования другого числа контейнеров, обновите информацию оптимизатора при помощи оператора ALTER TABLESPACE <имя_табличного_пространства> PREFETCHSIZE AUTOMATIC. Если в табличном пространстве есть несколько наборов полос, для вычисления размера предварительной выборки используется максимальное число контейнеров по нескольким наборам полос. Если вычисленный размер предварительной выборки превышает максимальный размер (32767 страниц), в качестве размера предварительной выборки используется наибольшее кратное числа контейнеров, которое меньше этого максимума.

В среде DB2 UDB Enterprise Server Edition, если для табличного пространства используется автоматический размер предварительной выборки (AUTOMATIC), размеры предварительной выборки могут отличаться в разных разделах базы данных. Причина в том, что в разных разделах базы данных число контейнеров, используемое при вычислении размеров предварительной выборки, может быть различным. При генерации плана доступа для запроса оптимизатор использует размер предварительной выборки из первого раздела в группе разделов базы данных.

[ Начало страницы |Страница назад | Страница вперед | Содержание ]