Буферные пулы

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

При создании базы данных по умолчанию создается буферный пул IBMDEFAULTBP, общий для всех табличных пространств. Добавить буферные пулы можно с помощью оператора CREATE BUFFERPOOL. По умолчанию размер буферного пула равен размеру, заданному параметром конфигурации базы данных BUFFPAGE, но его можно переопределить при помощи ключевого слова SIZE команды CREATE BUFFERPOOL. Подходящий размер буферного пула - важный параметр для обеспечения высокой производительности базы данных, поскольку он позволяет сократить количество наиболее продолжительных по времени операций ввода-вывода на диск и с диска. Большие буферные пулы влияют и на оптимизацию запросов, так как большая часть работы выполняется в памяти.

Блочные буферные пулы

Начиная с версии 8 DB2 позволяет выделить участок буферного пула (до 98%) для блочной предварительной выборки. Блочный ввод-вывод повышает эффективность предварительной выборки за счет считывания блока в непрерывную область памяти, вместо распределения по отдельным страницам. Размер блоков должен быть единым для всего буферного пула, он управляется параметром BLOCKSIZE. Его значение задает размер блока в страницах от 2 до 256, значение по умолчанию равно 32.

Пример оператора CREATE BUFFERPOOL

В качестве примера использования оператора CREATE BUFFERPOOL введите: CREATE BUFFERPOOL BP3 SIZE 2000 PAGESIZE 8K

Этот буферный пул назначается табличному пространству USERSPACE3 из примера CREATE TABLESPACE из этой статьи и создается до создания табличного пространства. Обратите внимание, что размеры страниц буферного пула и табличного пространства одинаковы и равны 8K. Если табличное пространство создается после создания буферного пула, в оператор CREATE TABLESPACE можно не включать синтаксис BUFFER POOL BP3. Вместо этого можно добавить буферный пул к существующему табличному пространству при помощи команды ALTER TABLESPACE, набрав ALTER TABLESPACE USERSPACE3 BUFFERPOOL BP3.

Просмотр атрибутов буферного пула

Информацию о буферных пулах можно распечатать, обратившись к системному представлению SYSCAT.BUFFERPOOLS, как показано в листинге 7.

SELECT * FROM SYSCAT.BUFFERPOOLS

BPNAME BUFFERPOOLID DBPGNAME NPAGES PAGESIZE ESTORE NUMBLOCKPAGES BLOCKSIZE
------------ ------------ -------- ------ -------- ------ ------------- ---------
IBMDEFAULTBP 1 - 1000 4096 N 0 0

1 record(s) selected.

Для отображения буферных пулов, назначенных табличным пространствам, выполните запрос, приведенный в листинге 8.

SELECT TBSPACE, BUFFERPOOLID FROM SYSCAT.TABLESPACES

TBSPACE BUFFERPOOLID 
----------- ------------
SYSCATSPACE 1 
TEMPSPACE1 1 
USERSPACE1 1

3 record(s) selected.

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

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

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

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

• BP1 (4K) для SYSCATSPACE и USERSPACE2
• BP2 (8K) для USERSPACE1
• BP3 (32K) для LARGESPACE и SYSTEMP1

В начало

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

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

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

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

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

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

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

Организация табличных пространств

Каждая таблица, в зависимости от того, как к ней обращаются чаще всего, имеет набор максимально эффективных значений параметров табличного пространства: PAGESIZE, EXTENTSIZE и PREFETCHSIZE.

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

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

Например, таблица с длиной строк 12 байт, размещенная в табличном пространстве с размером страницы 32K, будет использовать всего около 10% каждой страницы (((255 строк * 12 байт) + 91 байт служебных данных) / 32K (размер страницы) = ~10%). Этот эффект стоит учитывать лишь в случае больших таблиц, когда теряется значительное пространство. При этом операции ввода-вывода и буферизация становятся менее эффективными, поскольку фактически используемое содержимое каждой страницы мало.

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

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

Параметр PREFETCHSIZE указывает количество страниц, считываемых из табличного пространства при предварительной выборке данных. Предварительная выборка выполняется системой управления базы данных, когда та определяет, что имеет место последовательный ввод-вывод и можно повысить производительность за счет предварительной выборки (обычно при сканировании больших таблиц). Полезно явно установить значение PREFETCHSIZE, кратное произведению значения EXTENTSIZE для данного табличного пространства и числа контейнеров табличного пространства. Например, если EXTENTSIZE составляет 32 и имеется четыре контейнера, правильно будет выбирать значения PREFETCHSIZE 128, 256 и т.д. Если для одной или нескольких интенсивно используемых таблиц требуется другой набор параметров, разместите эти таблицы в отдельном табличном пространстве, чтобы повысить общую производительность.

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

Использование буферного пула

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

Цель настройки буферного пула – помочь DB2 оптимально использовать память, доступную для буферов. Общий размер буфера оказывает значительное влияние на производительность DB2, поскольку значительно сокращается число операций ввода-вывода для большого количества страниц. Но если общий размер буфера окажется слишком велик, и для его размещения не хватит места, для каждой страницы выделяется минимальный буферный пул, что ведет к резкому ухудшению производительности. Для расчета максимального размера буфера DB2 учитывает степень использования всей остальной памяти, а также операционную систему и другие приложения. Когда общий доступный размер буфера определен, эту область для улучшения использования можно разделить на буферные пулы. При наличии табличных пространств с разным размером страниц для каждого размера страниц следует выделить хотя бы один буферный пул.

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

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

В DB2, начиная с версии 8, размер буферного пула можно менять, не закрывая базу данных. Оператор ALTER BUFFERPOOL с параметром IMMEDIATE выполняется сразу же, за исключением тех случаев, когда в общей памяти базы данных зарезервировано недостаточно места для выделения нового пространства. Эту функцию можно применять для настройки производительности базы данных в соответствии с периодическими изменениями характера использования, например, при переключении с дневной интерактивной работы на ночную работу в пакетном режиме. Начиная с версии 9.1, DB2 позволяет полностью автоматизировать управление размером буферного пула. Этим процессом автоматизации управляет функция DB2 self-tuning memory manager (STMM).

Организация физической памяти

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

Чтобы сократить накладные расходы по расширению контейнеров SMS на одну страницу за раз, выполните командуdb2empfa. Она устанавливает значение параметра конфигурации базы данных MULTIPAGE_ALLOC равным YES.

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

Для RAID-устройств имеются отдельные рекомендации. Параметр EXTENTSIZE должен быть равным или кратным размеру блока RAID. PREFETCHSIZE должен равняться размеру блока RAID, умноженному на число параллельных устройств RAID (или быть кратным этому произведению), и быть кратным значению EXTENTSIZE. В DB2 имеются собственные переменные системного реестра, позволяющие расширить определенную среду. Выполните следующую команду, чтобы разрешить параллелизм ввода-вывода для отдельного контейнера: db2set DB2_PARALLEL_IO=*.

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