Основы DB2: Табличные пространства и буферные пулы

Эта статья поможет начинающим администраторам баз данных DB2® осознать важность табличных пространств и буферных пулов. В ней показано также, что их правильное проектирование и настройка может улучшить производительность баз данных. [Эта статья, первоначально написанная в 2002 году, обновлена с учетом возможностей IBM DB2 V9.7 для Linux®, UNIX® и Windows®.]

Ани Патель, специалист по углубленной технической поддержке DB2, IBM

Ани Патель (Ani Patel) работает в лаборатории IBM в Торонто аналитиком по углубленной поддержке DB2 второго уровня. Он занимается поддержкой DB2 более 7 лет и обладает опытом в сфере хранения данных, резервного копирования, восстановления, регистрации событий и в других областях. Он окончил университет Райерсон в Торонто, Канада, и имеет степень бакалавра вычислительной техники.



31.05.2010

Введение

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

В примерах для этой статьи используется версия DB2 9.7, Enterprise Server Edition. Большинство примеров, если нет других указаний, применимо также и к более ранним версиям.

В статье рассматриваются следующие темы:

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

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

Табличное пространство каталога
В базе данных может присутствовать только одно табличное пространство каталога, создаваемое в ходе выполнения команды CREATE DATABASE. В DB2 табличное пространство каталога называется SYSCATSPACE и содержит таблицы системного каталога. Это табличное пространство создается всегда при создании базы данных.
Обычное табличное пространство
Обычные табличное пространство содержит все постоянные данные, в том числе обычные таблицы и индексы. В этом пространстве можно хранить также и длинные данные, такие как большие объекты данных (Large Objects - LOB), если они не выделены в особое табличное пространство. Таблицу и ее индексы можно разделить на отдельные обычные табличные пространства, если это пространства, управляемые базой данных (DMS) для несекционированных таблиц или пространства, управляемые системой (SMS) для секционированных таблиц. DMS и SMS описаны в разделе Управление табличным пространством. Примером обычного табличного пространства служит табличное пространство каталога. По умолчанию это единственное обычное табличное пространство, которое создается при создании базы данных.
Табличное пространство длинных данных
В табличном пространстве длинных данных хранятся все постоянные данные, как и в пространстве обычных таблиц, включая объекты LOB. Такие табличные пространства должны иметь тип DMS, который присваивается им по умолчанию. Таблица, созданная в табличном пространстве длинных данных, может быть больше таблицы в обычном табличном пространстве. Такая таблица поддерживает более 255 строк на страницу данных, что улучшает использование страниц данных. При создании базы данных DB2 создает одно табличное пространство длинных данных с именем USERSPACE1.
Временные системные табличные пространства
Временные системные табличные пространства используются для хранения внутренних временных данных, необходимых для операций SQL, например, для сортировки, преобразования таблиц, создания индексов и объединения таблиц. База данных должна иметь хотя бы одно такое пространство. По умолчанию вместе с базой данных создается временное системное табличное пространство TEMPSPACE1.
Временные табличные пространства пользователя
Временные табличные пространства пользователя служат для хранения объявленных глобальных временных таблиц. При создании базы данных временные табличные пространства пользователя не создаются. Для определения декларированных временных таблиц требуется, чтобы существовало хотя бы одно временное табличное пространство пользователя. Временные табличные пространства пользователя не обязательны. По умолчанию они не создаются.

Управление табличными пространствами

Существует два способа управления табличными пространствами:

Пространство, управляемое системой (SMS)
Табличными пространствами SMS управляет операционная система. Контейнеры определяются как обычные файлы операционной системы, и доступ к ним осуществляется с помощью вызовов операционной системы. Это означает, что следующие операции выполняются с помощью обычных функций операционной системы:
  • операции ввода-вывода буферизуются операционной системой;
  • выделение пространства осуществляется в соответствии с соглашениями операционной системы;
  • табличное пространство автоматическое расширяется по мере необходимости.

Однако из табличных пространств SMS нельзя удалять контейнеры, а добавление новых контейнеров ограничено секционированными базами данных. Начиная с DB2 версии 9.1 единственным табличным пространством SMS, которое создается по умолчанию при создании базы данных, является TEMPSPACE1.

Пространство, управляемое базой данных (DMS)
Табличными пространствами DMS управляет DB2. Контейнеры можно определять как файлы (целиком занимающие размер, выделенный при создании табличного пространства) или как устройства. DB2 управляет вводом-выводом в той мере, в какой это позволяют метод выделения и операционная система. С помощью команды ALTER TABLESPACE контейнеры можно расширять. Неиспользуемые фрагменты контейнеров DMS можно освобождать (начиная с версии 8).

В листинге 1 показано, как увеличить размеры контейнера:

Листинг 1. Увеличение размера контейнера
ALTER TABLESPACE TS1 RESIZE (FILE '/conts/cont0' 2000, 
 DEVICE '/dev/rcont1' 2000, FILE 'cont2' 2000)

Для увеличения или сокращения размера контейнера можно использовать также такие параметры, как EXTEND или REDUCE.

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

При создании базы данных создаются три табличных пространства (SYSCATSPACE, TEMPSPACE1 и USERSPACE1). В листинге 2 показано, как создать базу данных с именем testdb, подключиться к ней и получить список табличных пространств с помощью командного окна DB2 или командной строки UNIX.

Листинг 2. Создание, подключение и вывод списка
CREATE DATABASE testdb 
CONNECT TO testdb 
LIST TABLESPACES

В листинге 3 приведен пример выходных данных команды LIST TABLESPACES.

Листинг 3. Выходные данные команды LIST TABLESPACES
  Tablespaces for Current Database

 Tablespace ID   = 0
 Name     = SYSCATSPACE
 Type     = Database managed space
 Contents    = All permanent data. Regular table space.
 State    = 0x0000
 Detailed explanation:
 Normal

 Tablespace ID   = 1
 Name     = TEMPSPACE1
 Type     = System managed space
 Contents    = System Temporary data
 State    = 0x0000
 Detailed explanation:
 Normal

 Tablespace ID   = 2
 Name     = USERSPACE1
 Type     = Database managed space
 Contents    = All permanent data. Large table space.
 State    = 0x0000
 Detailed explanation:
 Normal

В листинге 3 команда CREATE DATABASE автоматически создает три табличных пространства. Режим создания табличных пространств по умолчанию можно переопределить, включив в команду параметры табличных пространств, но в любом случае при создании базы данных необходимо создать табличное пространство каталога и хотя бы одно обычное или длинное и одно временное системное табличное пространство. Дополнительные табличные пространства любого типа (за исключением табличного пространства каталога) можно создавать с помощью команды CREATE DATABASE или, позднее, с помощью команды CREATE TABLESPACE.

Контейнеры

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

Параметры табличных пространств

Во время создания табличных пространств или позднее можно задать несколько параметров с помощью оператора ALTER TABLESPACE. Эти параметры перечислены в следующем списке.

Размер страницы
Определяет размер страниц, используемых для табличного пространства. Поддерживаются форматы 4K, 8K, 16K и 32K. Размер страниц ограничивает длину строк и число столбцов таблиц, которые можно разместить в табличном пространстве, в соответствии с предельными значениями, приведенными в таблице 1.
Таблица 1. Влияние размера страниц
Размер страницы Предельный размер строки Предельное число столбцов Максимальная емкость (табличное пространство DMS)
4 KБ4 00550064 ГБ
8 KБ8 1011 012128 ГБ
16 KБ16 2931 012256 ГБ
32 KБ32 6771 012512 ГБ

Табличные пространства ограничены 16384 страницами, поэтому, чем больше размер страницы, тем больше емкость табличного пространства.

Размер экстента
Число страниц в контейнере, при достижении которого осуществляется переход к следующему контейнеру. Система управления базой данных циклически перебирает контейнеры по мере записи данных. Этот параметр учитывается только при наличии для табличного пространства нескольких контейнеров.
Размер предварительной выборки
Количество страниц, считываемых из табличного пространства при выполнении предварительной выборки данных. Предварительная выборка заключается в считывании данных, необходимых для выполнения запроса, до того, как они будут указаны в запросе, чтобы не тратить время на операции ввода-вывода при обработке запроса. Предварительная выборка выполняется системой управления базы данных, когда та решает, что имеет место последовательный ввод-вывод и можно повысить производительность за счет предварительной выборки.
Непроизводительные издержки и скорость передачи данных
Определяет затраты на ввод-вывод при оптимизации запросов. Оба значения измеряются в миллисекундах и должны быть усреднены для всех контейнеров. Непроизводительные издержки - это время, связанное с операциями контроллера ввода-вывода, временем поиска данных на диске и задержкой вращения диска. Скорость передачи - время, необходимое для считывания в память одной страницы. По умолчанию для базы данных, созданной в DB2 версии 9, используются значения 7,5 мс и 0,06 мс соответственно. Для базы данных, перенесенной из предыдущей версии DB2, значения по умолчанию составляют 12,67 мс и 0,18 мс соответственно. Эти значения можно рассчитать, основываясь на спецификациях оборудования.

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

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

Листинг 4. Создание табличного пространства
CREATE TABLESPACE USERSPACE3 
PAGESIZE 8K 
MANAGED BY SYSTEM 
USING ('d:\usp3_cont1', 'e:\usp3_cont2', 'f:\usp3_cont3') 
EXTENTSIZE 64 
PREFETCHSIZE 32 
BUFFERPOOL BP3 
OVERHEAD 7.5 
TRANSFERRATE 0.06

Как просматривать атрибуты табличного пространства и контейнеров

Задание параметра SHOW DETAIL для команды LIST TABLESPACES приводит к отображению дополнительной информации: LIST TABLESPACES SHOW DETAIL.

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

Листинг 5. Выходные данные команды LlST TABLESPACES SHOW DETAIL
		Tablespaces for Current Database

 Tablespace ID   = 2
 Name     = USERSPACE1
 Type     = Database managed space
 Contents    = All permanent data. Large table space.
 State    = 0x0000
 Detailed explanation:
 Normal
 Total pages    = 8192
 Useable pages   = 8160
 Used pages    = 96
 Free pages    = 8064
 High water mark (pages)  = 96
 Page size (bytes)   = 4096
 Extent size (pages)   = 32
 Prefetch size (pages)  = 32
 Number of containers   = 1

Для отображения данных о контейнерах, необходимых для использования табличного пространства с идентификатором Tablespace ID из приведенного выше листинга, введите LIST TABLESPACE CONTAINERS FOR 2.

Листинг 6. Выходные данные команды LlST TABLESPACES CONTAINERS
		Tablespace Containers for Tablespace 2

Container ID = 0 
Name = C:\DB2\NODE0000\SQL00004\SQLT0002.0 
Type = Path

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

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

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

При создании базы данных по умолчанию создается буферный пул 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.

Листинг 7. Запрос SYSCAT.BUFFERPOOLS
SELECT * FROM SYSCAT.BUFFERPOOLS

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

1 record(s) selected.

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

Листинг 8. Запрос SYSCAT.TABLESPACES
SELECT TBSPACE, BUFFERPOOLID FROM SYSCAT.TABLESPACES

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

3 record(s) selected.

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

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

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

Рисунок 1. Табличные пространства и буферные пулы
На схеме показана база данных DB2 с пятью табличными пространствами и дисковыми контейнерами для каждого из них.

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

  • 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=*.

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


Перенос базы данных

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

Ситуация из реальной жизни: администратор баз данных скопировал хорошо настроенную базу данных с сервера Windows с 1 ГБ памяти в ноутбук с Windows и 256 МБ памяти. Сеанс, занимавший на сервере доли секунды, на ноутбуке занял 45 минут. Проблему удалось решить за счет сокращения размера буферного пула и настройки других параметров памяти.

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

  • Если копия базы данных предназначена для производственной эксплуатации, повторите процесс настройки.
  • Если база данных переносится на платформу z/OS®, обратитесь к соответствующим руководствам и справочникам IBM Redbooks®.
  • Для DB2 на платформе i физическая установка и настройка осуществляется вне среды базы данных. Проконсультируйтесь в руководствах по управлению системами IBM i.

Заключение

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

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

Автор благодарит Габора Визера и Дэвида Клайна, которые написали первоначальную версию этой статьи в 2002 году.

Ресурсы

Научиться

Получить продукты и технологии

  • Загрузите DB2 Express-C, бесплатную версию для сообщества разработчиков, которая предлагает все основные возможности по работе с данными платной версии DB2 Express Edtion и послужит надежной платформой для создания и внедрения приложений.
  • Используйте в своем следующем проекте ознакомительное программное обеспечение IBM , которое можно загрузить с DeveloperWorks.

Обсудить

Комментарии

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=493438
ArticleTitle=Основы DB2: Табличные пространства и буферные пулы
publish-date=05312010