Когда включена переменная реестра DB2_FORCE_FCM_BP, остается на один сегмент |меньше совместно используемой памяти для прочих нужд, в частности, для пулов буферов баз данных. Таким образом, включение переменной реестра DB2_FORCE_FCM_BP уменьшает максимальный размер пулов буферов баз данных. Обратите внимание на то, что поскольку в 64-битной среде доступно много сегментов |совместно используемой памяти, уменьшение их числа является проблемой только в 32-битных средах.
| | |При первом создании таблицы для статистики системного каталога задается |значение -1, означающее, что для этой таблицы нет статистики. До сбора статистики DB2 UDB использует при компиляции и оптимизации операторов SQL значения по умолчанию. | Обновление статистики таблицы или индекса может завершиться неудачно, если новые значения не соответствуют значениям по умолчанию. Поэтому перед тем, как вручную обновлять статистику для таблицы или индекса, |надо вызывать команду runstats для этой таблицы или индекса.
| | |У сообщения об ошибке SQL SQL1169N введен новый код причины 5, означающий, что столбец таблицы объяснений слишком мал.
|Следующий текст является обновлением главы |Руководство администратора: Производительность, Глава 6. |Компилятор SQL.
|Развертывание MDC можно использовать, даже если в план оптимизации включен |индекс RID, независимо от наличия условия WHERE в операторе DELETE. |В результате из списка условий, выполнение которых позволяет использовать |развертывание и более эффективный способ удаления строк, надо убрать условие |"Индекс RID не был выбран оптимизатором для поиска строк, которые надо |удалить, если оператор DELETE содержит условие WHERE".
|Далее, можно определить, действует ли развертывание MDC, по выводу |db2expln, содержащему словосочетание "Cell Delete". | Обратите внимание на то, что db2exfmt не показывает этой информации.
|Следующий текст - обновление для приложения Приложение A. |Переменные реестра и среды DB2:
|Надо изменить описание DB2_MDC_ROLLOUT, убрав из списка условие "Индекс RID |не был выбран оптимизатором для поиска строк, которые надо удалить, если |оператор DELETE содержит условие WHERE".
| | |При изменении значений параметров конфигурации |newlogpath, mirrorpath или overflowlogpath в среде |DB2 UDB Enterprise Server Edition к имени пути будет приписан номер узла, независимо от числа узлов в системе. Это относится и к однораздельным, и к многораздельным системам в среде DB2 UDB Enterprise Server Edition.
| | |Значение DB2_COLLECT_TS_REC_INFO по умолчанию - ON. В DB2 UDB Версии 8.1 FixPak 7 значение по умолчанию переменной реестра |DB2_COLLECT_TS_REC_INFO было изменено на ON. В текущей документации ошибочно указано, что значение по умолчанию для этой |переменной - OFF.
Экземпляр ограничителя ресурсов состоит из утилиты-клиента и одного или нескольких демонов. Каждый запускаемый экземпляр ограничителя ресурсов связан с определенным экземпляром менеджера баз данных. По умолчанию при запуске ограничителя ресурсов соответствующий демон запускается в каждом разделе многораздельной базы данных. Однако, можно запустить демон только в одном из разделов.
Каждый демон ограничителя ресурсов собирает информацию о прикладных программах, работающих с базой данных. Затем демон ограничителя ресурсов проверяет, соответствует ли эта информация правилам, указанным в файле конфигурации ограничителя ресурсов.
При оценке применения реорганизации таблицы на месте (вместо классической реорганизации) учтите, что для реорганизации таблицы на месте требуется больше пространства журнала.
Так как в процессе реорганизации на месте все операции регистрируются в журнале для восстановления в случае непредвиденного сбоя, то для ее выполнения требуется больше пространства журнала, чем для классической реорганизации.
Размер пространства журнала, необходимого для реорганизации на месте может в несколько раз превышать размер реорганизованной таблицы. Объем необходимого пространства зависит от числа перемещаемых строк и числа и размера индексов таблицы.
Совет: Реорганизацию на месте следует выбирать, если система работает непрерывно с минимальными перерывами на обслуживание.
Во время динамической реорганизации таблицы DMS можно запустить оперативное резервное копирование табличного пространства, в котором располагается эта таблица. На стадии усечения для операции реорганизации может иметь место ожидание блокировок.
Подробная информация по применению этих способов реорганизации приведена в описании синтаксиса команды REORG TABLE.
В 64-битной системе AIX(R) 5L переменная реестра DB2_LARGE_PAGE_MEM теперь поддерживает ключевое слово FCM.
По умолчанию в 64-битной системе AIX(R) 5L(TM) память FCM располагается в наборе памяти СУБД. Однако если включена переменная реестра DB2_FORCE_FCM_BP, память FCM располагается в своем собственном наборе памяти. В 64-битной системе AIX 5L(TM) переменная реестра DB2_LARGE_PAGE_MEM поддерживает спецификацию набора памяти СУБД. Если память FCM располагается в наборе памяти СУБД, и для этого набора памяти включена поддержка больших страниц, память FCM будет располагаться на больших страницах. Если же память FCM располагается в своем собственном наборе памяти, чтобы включить для нее поддержку больших страниц, в переменную реестра DB2_LARGE_PAGE_MEM надо добавить ключевое слово FCM.
Начиная с DB2 Universal Database(TM) (UDB) Версии 8.2.2 (эквивалентна Версии 8.1 FixPak 9), в файле конфигурации, заданном в переменной реестра DB2_RESOURCE_POLICY, можно использовать элемент SCHEDULING_POLICY. Элемент SCHEDULING_POLICY можно использовать на некоторых платформах для выбора:
Переменные реестра DB2PRIORITIES и DB2NTPRICLASS можно использовать по отдельности для управления правилами планировщика операционной системы и задания приоритетов агентов DB2.
Однако если задать элемент SCHEDULING_POLICY в файле конфигурации правил управления ресурсами, в нем можно задать как правила планировщика, так и приоритеты соответствующих агентов.
Выбор правил планировщика 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>
Замена переменной DB2NTPRICLASS=H в Windows.
<RESOURCE_POLICY> <SCHEDULING_POLICY> <POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE> </SCHEDULING_POLICY> </RESOURCE_POLICY>
В FixPak 8 добавлены системные переменные среды DB2_MAPPED_BASE и DB2DBMSADDR.
Использовать эти переменные реестра рекомендуется только опытным пользователям.
Если эта переменная не задана, DB2 UDB попытается использовать для положения совместно используемых библиотек виртуальный адрес 0x10000000.
В этой переменной реестра можно также задать любой виртуальный адрес (в шестнадцатеричной форме) в диапазоне 31- и 32-битного адресного пространства.
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)".)
Это сообщение выводится только при успешном задании переменной реестра; в нем указывается адрес, на который перемещены совместно используемые библиотеки.
db2set DB2DBMSADDR=
Эту переменную можно задавать вместе с DB2_MAPPED_BASE или отдельно для тонкой настройки адресного пространства процессов DB2 UDB. Эта переменная изменяет положение совместной памяти экземпляра с его текущего положения по виртуальному адресу 0x20000000 на заданное новое положение.
В Версии 8.2 добавлена переменная реестра DB2TCP_CLIENT_RCVTIMEOUT.
В Версии 8.2 добавлена переменная производительности DB2_LARGE_PAGE_MEM.
Имя переменной | Операционные системы | Значения |
---|---|---|
Описание | ||
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), необходимо выполнение следующих условий, помимо конфигурирования больших страниц в операционной системе:
В 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" в Приложении A "Переменные реестра DB2 и среды" книги Руководство администратора: Производительность:
Если для одной или обеих переменных компилятора DB2 DB2_MINIMIZE_LISTPREFETCH и DB2_INLIST_TO_NLJN задано значение ON, эти переменные будут активны, даже если задано REOPT(ONCE).
Ниже указаны изменения в документации по параметрам конфигурации:
Параметр конфигурации менеджера баз данных Тип аутентификации (authentication) может также иметь следующие значения:
Сервер принимает зашифрованные схемы аутентификации типа SERVER и зашифрованные пользовательские данные. Аутентификация работает точно так же, как при типе аутентификации SERVER_ENCRYPT.
При этом типе аутентификации шифруются следующие пользовательские данные:
Сервер принимает зашифрованные схемы аутентификации типа SERVER и зашифрованные пользовательские данные. Кроме того, этот тип аутентификации обеспечивает совместимость с ранними продуктами, не поддерживающими тип аутентификации DATA_ENCRYPT. Этим продуктам разрешено устанавливать соединение с помощью типа аутентификации SERVER_ENCRYPT и без шифрования пользовательских данных. Продукты, поддерживающие новый тип аутентификации, должны использовать его. Этот тип аутентификации допустим только в файле конфигурации менеджера баз данных сервера; он недопустим в команде CATALOG DATABASE.
Начиная с DB2 Universal Database Версии 8.2, значение по умолчанию параметра конфигурации менеджера баз данных Правила влияния для экземпляра (util_impact_lim) изменено со 100 на 10.
Все следующие параметры конфигурации менеджера баз данных могут на всех платформах содержать имена групп (длиной до 30 байтов):
Таблица в теме "Обзор параметров конфигурации менеджера баз данных" содержит неверные типы данных для этих параметров конфигурации менеджера баз данных. Правильный тип данных для всех этих параметров - char(30).
Максимальный размер для параметра конфигурации базы данных Размер сегмента расширения памяти (estore_seg_size) на платформах на основе Windows равен 16777216.
Правильное максимальное значение для параметра конфигурации базы данных Значение срока ожидания HADR (hadr_timeout) - 4294967295.
В документации сказано, что максимальное значение для параметра конфигурации базы данных Максимальный объем списка блокировок (locklist) для 64- и 32-битных серверов Windows, обслуживающих только локальных клиентов, равно 60000. Это неверное значение; правильное число - 524288.
Неверно указан диапазон значений для параметра конфигурации базы данных Число резервных копий базы данных (num_db_backups). Правильный диапазон: 0 - 32767.
После перенастройки DB2 Universal Database (UDB) из Версии 8.1 в Версию 8.2, DB2 UDB использует новый файл параметров конфигурации базы данных с именем SQLDBCONF и размером 16 Кбайт. (В Версии 8.1 файл параметров конфигурации базы данных имел размер только 4 Кбайта и назывался SQLDBCON).
В Версии 8.1 переменная реестра DB2_HASH_JOIN имела по умолчанию значение ON.
Используйте эту переменную хеш-объединения, настроив ее значение для оптимальной производительности.
Оптимальная производительность хеш-объединения обеспечивается в том случае, если удается избежать хеш-циклов и переполнения с записью на диск. Для повышения производительности хеш-объединения оцените максимальный объем доступной памяти для параметра sheapthres и настройте значение параметра sortheap. Увеличьте его значение в пределах ограничения, заданного параметром sheapthres, чтобы исключить как можно больше хеш-циклов и переполнений с записью на диск.
Дополнительную информацию смотрите в теме "Методы объединения" в книге Руководство администратора: Производительность.
Функции DB2NTNOCACHE доступны теперь на уровне табличного пространства путем задания условия NO FILE SYSTEM CACHING в операторе CREATE TABLESPACE или ALTER TABLESPACE. Использование этого условия описано в справочнике SQL Reference. В следующем выпуске переменная реестра DB2NTNOCACHE будет удалена.
Таблицы объяснения могут применяться совместно несколькими пользователями. Но задавать таблицы объяснения можно для одного пользователя, а для дополнительных пользователей для указания заданных таблиц использовать алиасы с тем же именем. Другой вариант - задать таблицы объяснения в схеме SYSTOOLS. Функция объяснения использует по умолчанию схему SYSTOOLS, если не найдено других таблиц объяснения или алиасов под ID сеанса пользователя для динамического SQL или ID авторизации оператора для статического SQL. Каждый пользователь, имеющий в совместном пользовании общие таблицы объяснения, должен иметь разрешение на вставку в эти таблицы. Следует также ограничить разрешения на чтение для общих таблиц объяснения - обычно можно ограничить теми пользователями, которые анализируют информацию объяснения.
Данные объяснения собираются, если эта опция указана при компиляции оператора SQL. Перед тем, как включить эту опцию, подумайте, как будет использоваться собранная информация.
Информация объяснения захватывается в следующих ситуациях:
Параметр информации упорядочивания можно вывести только при помощи API db2CfgGet. Его нельзя вывести при помощи процессор командной строки или Центр управления.
Этот параметр содержит 260 байт информации об упорядочении для базы данных. Первые 256 байтов задают последовательность упорядочения базы данных, где байт "n" содержит вес сортировки кода символа с десятичным представлением "n" в кодовой странице базы данных.
Последние 4 байта содержат внутреннюю информацию о типе последовательности упорядочения. Последние четыре байта collate_info - целое число. Это целое число зависит от порядка разделения на байты на данной платформе. Возможные значения:
Если вы используете эту внутреннюю информацию, то при ее передаче на другую платформу необходимо выполнить реверсирование байтов.
Последовательность упорядочения можно задать во время создания базы данных.
Начиная с 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), размеры предварительной выборки могут отличаться в разных разделах базы данных. Причина в том, что в разных разделах базы данных число контейнеров, используемое при вычислении размеров предварительной выборки, может быть различным. При генерации плана доступа для запроса оптимизатор использует размер предварительной выборки из первого раздела в группе разделов базы данных.
[ Начало страницы |Страница назад | Страница вперед | Содержание ]