Краткий справочник по настройке DB2 Universal Database EEE

В данной статье рассматриваются технические приемы настройки DB2 Extended Enterprise Edition (EEE), включая использование оперативной памяти, буферных пулов и инструментальных средств настройки. Предоставлены Perl-сценарии, которые помогут собрать и проанализировать данные о текущем состоянии DB2, выработать рекомендации по улучшению производительности базы данных.

Сурендра Парлапалли, разработчик, IBM

Сурендра Парлапалли (Surendra Parlapalli) имеет восьмилетний опыт работы в IT-индустрии и степень магистра по вычислительной технике. Он является сертифицированным специалистом по IBM DB2 DBA, Application Developer и разработке решений Microsoft для Windows NT. Связаться с ним можно по адресу sparlapalli@us.ibm.com.



22.02.2008

© 2002 International Business Machines Corporation. Все права защищены.

Введение

В данной статье рассматриваются технические приемы настройки производительности DB2® Universal Database™ Extended Enterprise Edition (EEE). Затронуты такие темы, как основы DB2 EEE, использование оперативной памяти DB2, рекомендации по настройке и другие. Предоставлены Perl-сценарии, которые помогут собрать и проанализировать данные о текущем состоянии DB2, выработать рекомендации по улучшению производительности базы данных. Примеры, приведенные в данной статье, в основном относятся к платформе Windows®.


Что такое DB2 EEE?

Версия Extended Enterprise Edition из семейства продуктов DB2 поддерживает распределение данных по кластерам компьютеров с высокой степенью параллелизма. Распределенная база данных может поддерживать очень большой объем данных и предоставляет возможности для работы новых приложений. DB2 EEE можно установить на несколько разделов одной системы (логические узлы) или распределить ее по нескольким системам в качестве физических узлов. Менеджер базы данных на каждом узле управляет частью базы данных. Архитектура DB2 EEE может улучшить производительность систем поддержки принятия решений и систем оперативной обработки транзакций.

Архитектура без разделения ресурсов
DB2 EEE работает в архитектуре, не предусматривающей разделения ресурсов, на операционных системах Windows®, UNIX® и Linux. На рисунке 1 изображена архитектура без разделения ресурсов DB2 EEE.

Рисунок 1. Разделы DB2 EEE на аппаратном обеспечении без разделения ресурсов

Рисунок 1. Разделы DB2 EEE на аппаратном обеспечении без разделения ресурсов

Часть базы данных, содержащая свои собственные данные, индексы, конфигурационные файлы и журналы транзакций, называется разделом базы данных (database partition).

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

Параллелизм
DB2 EEE поддерживает два типа параллелизма: внешний и внутренний (inter-partition и intra-partition) по отношению к разделам.

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

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

Модель DB2 EEE процесс/поток на раздел
Экземпляр DB2 EEE в операционной системе Windows запускается как служба при выполнении команды db2start. При этом запускается процесс db2syscs.exe для каждого раздела в узле. Данные процессы взаимодействуют через сообщения, используя IPC или TCP/IP. Каждое приложение назначается агенту, который работает от имени приложения.

Активизация базы данных запускает регистратор для регистрации действий и детектор взаимных блокировок для их обнаружения. Менеджер лицензий DB2 запускается как отдельный процесс и следит за использованием лицензий.


Как DB2 использует оперативную память

Оперативная память DB2 распределяется на различных этапах. На рисунке 2 изображено распределение памяти DB2 EEE.

Глобальный блок управления
Память, необходимая для работы менеджера базы данных. Эта память распределяется при запуске менеджера базы данных. Поддержку взаимодействия для DB2 EEE обеспечивает Fast Communication Manager (FCM). В этой области памяти размещаются буферы FCM.

Глобальная память базы данных
Память, необходимая для работы базы данных. Эта память распределяется при активизации базы данных. Число сегментов памяти ограничено конфигурационным параметром numdb (количество баз данных). Общий размер глобальной памяти базы данных определяется конфигурационными параметрами, перечисленными в таблице 1.

Таблица 1. Конфигурационные параметры базы данных, влияющие на размер глобальной памяти базы данных

ПараметрОписание
buffpageВлияет на буферные пулы, размер которых установлен в значение -1
pckcacheszРазмер пакетного кэша
util_heap_szРазмер служебной кучи
dbheapКуча базы данных
locklistМаксимальное пространство для блокировок

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

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

Таблица 2. Меньшие параметры maxappls и maxagents ограничивают сегменты памяти

ПараметрОписание
maxapplsОбщее максимальное число приложений для всех активных баз данных.
maxagentsМаксимальное количество агентов.

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

Таблица 3. Конфигурационные параметры, влияющие на максимальный размер приватной памяти

ПараметрОписание
agent_stack_szРазмер стека агента
udf_mem_szРазмер разделяемой памяти UDF
applheapszРазмер кучи для приложения
sortheapРазмер кучи для сортировки
stmtheapРазмер кучи для выражений
stat_heap_szРазмер кучи для статистики
query_heap_szРазмер кучи для запросов
drda_heap_szРазмер кучи для DRDA

Разделяемая память агента/приложения
Эта память разделяется между агентами, работающими для одного и того же приложения.

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

Таблица 4. Конфигурационные параметры, влияющие на разделяемую память агента

ПараметрОписание
aslheapszРазмер кучи уровня поддержки приложения
rqrioblkРазмер блока ввода/вывода клиента

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

Таблица 5. Конфигурационные параметры, влияющие на разделяемую память приложения.

ПараметрОписание
applheapszРазмер кучи для приложения
agent_stack_szРазмер стека агента
stat_heap_szРазмер кучи для статистики
udf_mem_szПамять для UDF
sortheapРазмер кучи для сортировки
rqrioblkРазмер кучи для запросов
query_heap_szРазмер блока ввода/вывода клиента
drda_heap_szРазмер кучи для DRDA

На рисунке 2 изображена схема использования оперативной памяти системой DB2. Дополнительная информация приведена в разделе "Настройка DB2 для использования всей памяти".

Рисунок 2. Использование памяти DB2
Рисунок 2. Использование памяти DB2

Создание базы данных

В DB2 EEE база создается путем выполнения простой команды в приглашении процессора командной строки DB2 Command Line Processor (CLP). В следующем примере создается база данных mydb.

             CREATE DATABASE mydb

После выполнения этой команды в каталоге instance появляется база данных mydb.

Табличные области

Табличная область (tablespace) представляет собой логический уровень между базой данных и контейнерным объектом, который фактически хранит данные. DB2 EEE поддерживает два типа табличных областей: область, управляемая системой (system-managed space - SMS), и область, управляемая базой данных (database-managed space - DMS). В SMS область хранения распределяется и управляется файловым менеджером операционной системы. Контейнерами, используемыми в SMS, должны быть каталоги. В DMS областью хранения управляет менеджер базы данных. Контейнером, используемым в DMS, должен быть заранее распределенный файл или физическое устройство, например, жесткий диск. DBA могут выбирать тип табличной области для таблиц catalog, temporary и user.

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

  • System - Для хранения информации о каталоге в системных таблицах. Каталог содержит информацию об определениях объектов базы данных (например, таблиц, представлений, индексов и пакетов) и информацию о системе защиты - типе доступа, который имеют пользователи к этим объектам.
  • Temporary - Для хранения системных временных таблиц, создаваемых во время обработки базы данных.
  • User - Для хранения таких объектов базы данных как таблицы и индексы, созданные пользователем.

В следующем примере демонстрируется, как администратор может создать базу данных, используя оба типа табличных областей - DMS и SMS. Здесь создается база данных tested с управляемой системой табличной областью catalog и управляемыми базой данных табличными областями temporary и user.

	CREATE DATABASE tested 
	CATALOG TABLESPACE 
	PAGESIZE 4096 
	MANAGED BY DATABASE USING 
	(FILE 'C:\DATA\CAT1.DAT' 3000, 
	FILE 'D:\DATA\CAT1.DAT' 3000) 
	EXTENTSIZE 12 
	PREFETCHSIZE 16 
	TEMPORARY TABLESPACE 
	MANAGED BY SYSTEM USING 
	('C:\DATA\TEMP1' , 'D:\DATA\TEMP2') 
	USER TABLESPACE 
	MANAGED BY DATABASE USING 
	('\\.\PhysicalDrive1' 4096, 
	'\\.\PhysicalDrive2' 4096)

PAGES: Строки табличных данных организованы в блоки, называемые страницами. DB2 поддерживает размеры страниц 4 KB, 8 KB, 16 KB и 32 KB. Вы можете выбирать различные размеры страниц для различных табличных областей на основе типа используемого приложения. По умолчанию DB2 использует 4 KB страницы.

PAGESIZE: Для табличной области catalog указан размер страниц 4 KB.

EXTENT: Несколько страниц группируются в размещаемые модули, называемые экстентом (extent). В приведенном выше примере EXTENTSIZE определяет 12 4 KB страниц для группировки в экстент.

PREFETCH: Это метод, позволяющий DB2 читать данные заранее, снижая время ожидания при их извлечении.

PREFETCHSIZE: Определяет число страниц, которые могут быть предварительно выбраны.

Команда LIST TABLESPACES SHOW DETAILS отображает приведенную выше информацию и дополнительные сведения, в том числе общее количество страниц, количество пригодных к использованию страниц, количество использованных страниц, количество свободных страниц и т.д.

После обнаружения идентификатора (ID) табличной области с использованием команды LIST TABLESPACES, можно найти дополнительную информацию о контейнерах при помощи команды LIST TABLESPACE CONTAINERS FOR 2 SHOW DETAIL. 2 - это ID табличной области. Данная команда выводит список контейнеров для указанной табличной области. Для каждого контейнера отображается его ID, название, тип, общее число страниц, число пригодных к использованию страниц и признак доступности контейнера в текущий момент времени.

В DB2 можно разместить индексы и данные в отдельных табличных областях. Использование различных дисков для контейнеров снижает уровень конкуренции за ресурсы ввода/вывода. В следующем примере создается таблица employee. Обычные данные помещаются в табличную область TBS1, а индексы - в табличную область TBS2.

	CREATE TABLE employee( 
	E_NO INT NOT NULL, 
	E_NAME CHAR(20) NOT NULL ) 
	IN TBS1 INDEX IN TBS2

Создание буферных пулов

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

	CREATE BUFFERPOOL bp1 
	SIZE 4000 
	PAGESIZE 4096

Приведенный выше SQL-запрос создает буферный пул bp1 с 4000 4KB страниц (4000*4K = 16000K).

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

	ALTER TABLESPACE emp BUFFERPOOL bp1

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

  • Все приложения отсоединяются от базы данных.
  • В буферный пул необходимо считать новую страницу.
  • Менеджером базы данных активизируется очиститель страниц (page cleaner).

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


Конфигурирование экземпляра базы данных

Экземпляр DB2 EEE или менеджер экземпляра размещается в узле catalog. Владеющий экземпляром компьютер (то есть, узел 0) владеет разделяемым каталогом, в котором хранится эта информация. Говорят, что другие серверы распределенной базы данных, добавленные к экземпляру, причастны к экземпляру.

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

Логические узлы
Наличие более одного сервера с разделенной базой данных на одной и той же машине называется конфигурацией с несколькими логическими узлами (multiple logical nodes - MLN). MLN использует преимущества SMP-архитектуры. Для создания MLN-конфигурации используется команда db2ncrt для добавления узлов серверов разделенной базы данных (логический узел) к экземпляру.

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

db2ncrt /n:1 /u:BENCH\db2inst1,bmdb2 /I:BENCH /m:node1 /p:1 /h:node1

Группы узлов
Именованный набор из одного или нескольких разделов базы данных называется группой узлов (nodegroup). Подмножество, состоящее из нескольких разделов базы данных, называется группой узлов с несколькими разделами (multi-partition nodegroup). Группы узлов с несколькими разделами могут существовать только внутри разделов базы данных, принадлежащих одной и той же базе данных.

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

	CREATE NODEGROUP allnodes ON ALL NODES

Следующий пример создает группу узлов snodes, содержащую только узлы от 0 до 3 и 5:

CREATE NODEGROUP snodes ON NODE (0 TO 3, 5)

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

	CREATE TABLESPACE org 
	IN NODEGROUP s_nodes 
	MANAGED BY DATABASE 
	USING (DEVICE '\\.\PhysicalDrive1' 2000)   ON NODE(0) 
	USING (DEVICE '\\.\PhysicalDrive1' 2000)   ON NODE(1) 
	USING (DEVICE '\\.\PhysicalDrive1' 2000)   ON NODE(5)

На рисунке 3 изображена взаимосвязь между объектами базы данных для данного раздела.

Рисунок 3. Диаграмма взаимосвязей объектов DB2 для конкретного раздела базы данных

Рисунок 3. Диаграмма взаимосвязей объектов DB2 для конкретного раздела базы данных


Рекомендации по настройке

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

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

Разрешение специального регистра EXPLAIN SNAPSHOT
Установите специальный регистр CURRENT EXPLAIN SNAPSHOT в значение YES для снимка текущего состояния динамических SQL-запросов. Следующее выражение можно встроить в прикладную программу или выполнить его в интерактивном режиме. После установки специального регистра снимок текущего состояния с пояснительной информацией будет формироваться для всех последующих динамических SQL-запросов.

	SET CURRENT EXPLAIN SNAPSHOT YES

Сбор пояснительных снимков текущего состояния для SQL-процедур
Хранимые процедуры должны устанавливать регистр EXPLSNAP в значение ALL или YES для сбора информации о планах доступа.

db2 PREP <procedure name="name"> EXPLSNAP {YES / ALL / NO } 
                               YES = static SQL 
                               ALL = static and dynamic 
                               NO = No snapshot</procedure>

При подготовке пакета с использованием EXPLSNAP YES или ALL можно получить план для всего пакета.

Инструментальная программа db2expln описывает план доступа, выбранный для статических SQL-запросов в пакете, хранящемся в системных таблицах catalog, а инструментальная программа dynexpln описывает план доступа для динамических SQL-запросов.

В следующем примере используется db2expln для извлечения плана доступа для пакета neword в базе данных mydb, созданного пользователем myuser, в выходной файл output.file.

db2expln -d mydb -p neword -c myuser -o output.file

Инструментальные программы, связанные с производительностью
DB2 предоставляет различные инструментальные программы (например, RUNSTATS, REORG и REORGCHK) для повышения производительности базы данных.

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

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

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

Примеры

В следующем примере RUNSTATS собирает всю возможную статистику на основе индексов:

RUNSTATS ON TABLE bench.neword WITH DISTRIBUTION AND DETAILED INDEXES ALL

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

               REORG TABLE bench.customer USING TEMPSPACE1

Следующая команда REORGCHK проверяет необходимость выполнения REORG и обновляет статистическую информацию по таблице bench.customer:

                REORGCHK UPDATE STATISTICS ON TABLE bench.customer

Минимизация I/O

Уменьшите интенсивность операций ввода/вывода (I/O), используя преимущества индексов, кэширования, сокращенного журналирования, итоговых таблиц и уменьшенной выборки данных.

Используйте индексы
Создание правильных индексов улучшает производительность запроса. Специальная программа - консультант по индексам DB2 (index adviser) предоставляет помощь в разработке индексов для таблиц. Она полезна в следующих ситуациях:

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

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

После создания индексов используйте инструментальные программы Explain для гарантии использования их системой DB2.

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

  • Буфер журнала заполнился.
  • Выполнилась операция фиксации транзакции или группы транзакций.

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

Вот команды для изменения этих параметров кэширования:

	db2 update db cfg for mydb using logbufsz 4096 
	db2 update db cfg for mydb using catalogcache_sz 1024 
	db2 update db cfg for mydb using pckacchesz 4096

Повышение уровня параллелизма операций ввода/вывода
Ниже приведены рекомендации для повышения уровня параллелизма операций ввода/вывода:

  • Распределяйте данные по нескольким жестким дискам для уменьшения времени ожидания операций ввода/вывода.
  • Разделяйте индексы и данные по различным табличным областям для улучшения производительности приложений OLTP и OLAP из-за уменьшения соревнования за ресурсы I/O.

В качестве практического правила для OLTP-приложений используйте табличные области DMS с несколькими устройствами. Табличные области temporary и catalog должны иметь тип SMS.

Размещение log-файлов
Для OLTP-приложений очень важно поместить log-файлы на отдельном физическом устройстве, где их интенсивность не скажется отрицательно на других задачах.

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

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

	db2 update dbm cfg using intra_parallel YES

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

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

Внешний параллелизм разрешается автоматически при разделении базы данных по нескольким узлам.

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

Как данные распределяются по разделам
Ключ разделения (partitioned key) - это столбец или группа столбцов, используемая для определения раздела, в котором будет храниться конкретная строка данных. Ключ разделения для таблицы определяется в выражении CREATE TABLE. Если ключ разделения для таблицы в табличной области, распределенной по нескольким разделам базы данных в группе узлов, не указывается, DB2 создает его по умолчанию из первого столбца первичного ключа. Если первичный ключ не указан, ключом разделения по умолчанию является определенный в таблице первый столбец с полем, отличным от типа long.

	CREATE TABLE customer( 
	C_ID INTEGER NOT NULL, 
	C_FIRST VARCHAR(20) NOT NULL, 
	C_MIDDLE VARCHAR(20) NOT NULL) 
	IN CUSTOMER 
	INDEX IN CUSTOMER_IDX 
	PARTITIONING KEY(C_ID) USING HASHING;

Настройка с использованием мониторов снимков текущего состояния базы данных

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

  • SORT - Объем использованной кучи, переполнений и выполненных сортировок.
  • LOCK - Количество хранящихся блокировок, взаимных блокировок и расширений блокировок.
  • TABLE - Измеряет активность (чтения и записи строк).
  • BUFFERPOOL - Операции физического чтения, логического чтения и информация о синхронизации.
  • STATEMENT - Количество фиксаций и откатов транзакций, выборок и неудач.

Для управления монитором эти ключи можно использовать в следующих командах:

	GET MONITOR SWITCHES 
	UPDATE MONITOR SWITCHES USING <switch-name> ON/ OFF 
	RESET MONITOR ALL/ FOR DATABASE <dbname>

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

	(1- ((pool_data_p_reads + pool_index_p_reads) / 
	(pool_data_l_reads + pool_index_l_reads))) * 100

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

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

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

	100%*piped_sorts_accepted/piped_sorts_requested

Маленькое процентное соотношение указывает на то, что производительность может быть улучшена путем увеличения параметра sortheapthres.

Настройка кэша пакета (pckcachesz)
Коэффициент используемости кэша пакета может быть рассчитан по следующей формуле:

	(1 - (Package cache inserts / package cache lookups)) * 100

Маленькое значение указывает на то, что параметр pckcachesz должен быть увеличен.

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

	(1 - (Catalog cache inserts / catalog cache lookups)) * 100

Маленькое значение указывает на то, что параметр catalogcache_sz должен быть увеличен.

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

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

Fast Communications Manager (FCM)
DB2 может использовать FCM для взаимодействия агентов, работающих над одним и тем же запросом. Настраиваемыми параметрами для FCM являются fcm_num_anchors, fcm_num_buffers, fcm_num_connect и fcm_num_rqb. При росте числа разделов будет увеличиваться количество элементов соединения (fcm_num_connect) и BQS RQB (fcm_num_rqb). При увеличении числа блоков запроса увеличивается количество буферов FCM (fcm_num_buffers). При росте числа подсекций (то есть сложности запроса) будет расти число BDS RQB (fcm_num_rqb) и точек привязки (anchors) сообщений (fcm_num_anchors).

В MLN-среде установите DB2_FORCE_FCM_BP в значение YES, что позволяет DB2 создавать буферы FCM в отдельном сегменте памяти. Когда буферы FCM создаются в отдельном сегменте памяти, взаимодействие между демонами FCM различных логических разделов одного и того же физического узла происходит через разделяемую память.

Запрещайте кэширование файловой системы для Windows
Кэширование файловой системы выполняется следующим образом:

  • Для файловых контейнеров DMS (и всех SMS-контейнеров) операционная система может кэшировать страницы в кэш файловой системы.
  • Для табличных областей устройств-контейнеров DMS операционная система не кэширует страницы в кэше файловой системы.

Для Windows NT® переменная реестра DB2NTNOCACHE указывает, будет или нет DB2 открывать файлы базы данных с параметром NOCACHE. Если DB2NTNOCACHE=ON, кэширование файловой системы запрещено. Если DB2NTNOCACHE=OFF, операционная система кэширует файлы DB2. Это касается всех данных за исключением файлов, содержащих поля LONG FIELDS или LOBS. Запрет системного кэширования позволяет сделать доступным больший объем памяти, для того чтобы можно было увеличить буферный пул или кучу для сортировки. Для запрета кэширования файловой системы установите переменную реестра DB2NTNOCACHE в значение ON:

	db2set DB2NTNOCACHE=ON

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


Примеры Perl-сценариев для настройки DB2 в операционных системах Linux, UNIX и Windows

enable_snap.pl - Разрешает все снимки текущего состояния DB2 (то есть BUFFERPOOLS, TABLES, LOCKS и т.д.).

perl gather_stats.pl <dbname> <time_in_secs> - Этот сценарий собирает информацию из всех снимков текущего состояния DB2 в файл dbrun.snap.

perl buffhitratio.pl dbrun.snap - Этот сценарий отображает коэффициент используемости страниц данных и индексов каждого буферного пула.

$ perl buffhitratio.pl dbrun.snap 
BP Name      Logical Rd Physical Rd  Writes Async Rds Async Wrts Hit Ratio% 
------------------------------------------------------------------------------ 
              DATA    1538     133      19     117       0  91.35% 
              INDX    3084      38       2       0       0  98.77% 
 IBMDEFAULTBP DATA    1538     133      19     117       0  91.35% 
 IBMDEFAULTBP INDX    3084      38       2       0       0  98.77% 
 IBMDEFAULTBP DATA    1538     133      19     117       0  91.35% 
 IBMDEFAULTBP INDX    3084      38       2       0       0  98.77% 
 
HINT : 
It is good have high hit ratio; if not increase your bufferpool size.

perl cathitratio.pl dbrun.snap - Этот сценарий отображает коэффициент используемости кэша каталога.

$ perl cathitratio.pl dbrun.snap 
 
        Cache Inserts             Cache Lookups      % Hit Ratio 
        ------------------------------------------------------- 
         10                   20                     50% 
HINT : 
If hit ratio is less than increase catalog cache size

perl packhitratio.pl dbrun.snap - Этот сценарий отображает коэффициент используемости кэша пакета.

$ perl packhitratio.pl dbrun.snap 
 
Package Cache Inserts      Package Cache Lookups      % Hit Ratio 
 -------------------------------------------------------------- 
         1                 244                         99% 
 
 HINT : 
Increase the catalog cache size if the hit ratio is less

perl sortthresh.pl dbrun.snap - Этот сценарий отображает количество обработанных сортировок и количество отклоненных сортировок.

$ perl sortthresh.pl dbrun.snap 
 
Piped sorts requested      Piped sorts accepted       % Serviced    Num Sorts Rejected 
 -------------------------------------------------------------------------------- 
         1                   1                      100%                    0 
 
 HINT : 
 If % Serviced is low then increase sheapthresh 
 If Num Sorts Rejected is higher then increase sortheap or sheapthreash is too small

perl sorttime.pl dbrun.snap - Этот сценарий отображает среднее затраченное время на сортировку.

$ perl sorttime.pl dbrun.snap 
 
Total Sort Time (ms)      Total Sorts  Average Elapsed Time per sort 
 ----------------------------------------------------------------- 
        100                  10         10 
HINT : 
As the performance improves, this average will decrease

perl tbs_usage.pl <dbname> - Этот сценарий отображает свободное и используемое пространство для всех табличных областей указанной базы данных.

$ perl tbs_usage.pl tpcd 
connect to ebuis 
 
   Database Connection Information 
 
 Database server        = DB2/LINUX 7.2.2 
 SQL authorization ID   = EBUIS 
 Local database alias   = EBUIS 
 
 
Ts_Id      Ts_Name       Total   Used     Free    Number_of_files 
------------------------------------------------------------------ 
  0          SYSCATSPACE      10M      10M       0M  1 
  1           TEMPSPACE1       0M       0M       0M  1 
  2           USERSPACE1       0M       0M       0M  1 
  3            BENCHTEMP    1000M       0M     999M  2 
  4          ORDERS_DATA    1000M      95M     903M  2 
  5         ORDERS_INDEX    1000M      18M     981M  2 
  6        LINEITEM_DATA    1000M     398M     600M  2 
  7       LINEITEM_INDEX    1000M     138M     861M  2 
  8            BENCHINDX    1000M      22M     977M  2 
  9            BENCHDATA    1000M      94M     905M  2

perl locklist.pl dbrun.snap <dbname> - Этот сценарий отображает общий список блокировок, средний список блокировок и среднюю степень используемости списка блокировок.

$ perl locklist.pl dbrun.snap ebuis 
 
   Locklist (4K Page)          Lock_list_in_use(4K Page)      Lock list utilization 
 -------------------------------------------------------------------------------- 
       100                   6                        6% 
 
 HINT : 
 If Lock list utilization is low then decresae the locklist 
 If Lock list utilization is more then increase the locklist

Загрузка

ОписаниеИмяРазмер
Образец кодаdb2_tune.ZIP12KB
Образец кодаdb2_tune.tar64KB
Спецификацияreadme.txt2KB

Ресурсы

Комментарии

developerWorks: Войти

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


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


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

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

 


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

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

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



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

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

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

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

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

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=291028
ArticleTitle=Краткий справочник по настройке DB2 Universal Database EEE
publish-date=02222008