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

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: простой

Дэвид Клайн, специалист технической поддержки программы PartnerWorld for Developers, IBM
Габор Визер, специалист технической поддержки программы PartnerWorld for Developers, IBM

05.06.2007

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

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

Статья соответствует IBM DB2 Universal Database^TM для Linux, UNIX® и Windows®.

Введение

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

В упражнениях будет использоваться DB2 версии 8.1, Enterprise Server Edition. Большинство примеров также применимы к предыдущим версиям программы. Если пример относится только к версии 8.1, то приводится соответствующее указание.

В разделе 1 будут определены типы табличных пространств и показано, как DB2 хранит в табличных пространствах данные. Будут рассмотрены параметры конфигурации и представлен процесс создания и управления табличным пространством. Далее будут рассмотрены буферные пулы, что представляет собой буферный пул, его создание и использование. В разделе 2 эти два понятия будут объединены и будет показано, как следует организовать табличные пространства и буферные пулы для максимального увеличения производительности.

В начало

Раздел 1: Определения

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

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

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

В базе данных может находиться только одно табличное пространство каталога, создаваемое при вызове команды CREATE DATABASE. В DB2 табличное пространство каталога называется SYSCATSPACE и содержит таблицы системного каталога. Данное табличное пространство всегда создается при создании базы данных.

Пространства регулярных таблиц

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

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

Табличные пространства длинных данных применяются для хранения столбцов таблиц с длинными данными или объектами LOB, эти пространства должны находиться в табличных пространствах DMS. В них также могут хранится столбцы структурированного типа или данные индекса. Если табличное пространство длинных данных не определено, объекты LOB будут сохраняться в пространствах регулярных таблиц. Табличные пространства длинных данных являются дополнительными, по умолчанию они не создаются.

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

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

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

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

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

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

Пространство, управляемое системой (SMS)

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

Пространство, управляемое базой данных (DMS)

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

Рассмотрим пример увеличения размера контейнера (поддерживается в версиях 7 и 8):

ALTER TABLESPACE TS1 RESIZE 
			(FILE '/conts/cont0' 2000, DEVICE '/dev/rcont1' 2000, FILE 'cont2' 2000)

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

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

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

CREATE DATABASE testdb CONNECT TO testdb LIST TABLESPACES

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

Листинг 1. Выходные данные команды LIST TABLESPACES

				Tablespaces for Current Database

				Tablespace ID = 0 Name = SYSCATSPACE Type = System
				managed space Contents = Any data 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 = System
				managed space Contents = Any data State = 0x0000
				Detailed explanation: Normal
			

Контейнеры

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

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

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

Размер страницы

Размер страниц, используемых для табличного пространства. Поддерживаемые размеры -- 4K, 8K, 16K и 32K. Размер страницы ограничивает длину строки и количество столбцов таблиц, размещаемых в табличном пространстве в соответствии со следующими данными:

Таблица 1. Влияние размера страницы

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

Следующий оператор служит для создания пространства регулярных таблиц. Для иллюстрации представлены все рассмотренные выше параметры.

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 24.1 
TRANSFERRATE 0.9

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

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

LIST TABLESPACES SHOW DETAIL

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

Листинг 2. Вывод команды LlST TABLESPACES SHOW DETAIL

Tablespaces for Current Database

Tablespace ID = 2 Name = USERSPACE1 Type = System
managed space Contents = Any data State = 0x0000
Detailed explanation: Normal Total pages = 336 Useable
pages = 336 Used pages = 336 Free pages = Not
applicable High water mark (pages) = Not applicable
Page size (bytes) = 4096 Extent size (pages) = 32
Prefetch size (pages) = 16 Number of containers = 1
			

LIST TABLESPACE CONTAINERS FOR 2

Листинг 3. Вывод команды LIST TABLESPACE CONTAINERS

Tablespace Containers for Tablespace 2

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

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

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

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

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

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

Длительное хранение

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

Пример оператора 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:

SELECT * FROM SYSCAT.BUFFERPOOLS


BPNAME BUFFERPOOLID NGNAME NPAGES PAGESIZE ES
------------------ ------------ ------------------
----------- ----------- -- IBMDEFAULTBP 1 - 250 4096 N

1 record(s) selected.
			

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

SELECT TBSPACE, BUFFERPOOLID FROM
SYSCAT.TABLESPACES

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

3 record(s) selected.
			

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

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

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

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

В данном сценарии буферные пулы можно назначить следующим образом:
BP1 (4K) для SYSCATSPACE и USERSPACE2
BP2 (8K) для USERSPACE1
BP3 (32K) для LARGESPACE и SYSTEMP1

В начало

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новая функция в версии v8 предоставляет возможность изменения размеров буферных пулов без закрытия базы данных. Оператор ALTER BUFFERPOOL с параметром IMMEDIATE вступает в силу сразу же, за исключением случаев недостаточности свободного места в общей памяти базы данных. Данную функцию можно использовать для настройки производительности базы данных в соответствии с периодическими изменениями в использовании, например, при переключении с дневного интерактивного использования на ночную работу в пакетном режиме.

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

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

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

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

db2set DB2_PARALLEL_IO=*

Другая переменная реестра DB2_STRIPED_CONTAINERS=ON изменяет размер тега контейнера с одной страницы до максимального, что позволяет выравнивать экстенты табличных пространств с полосами RAID.

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

Перемещение баз данных

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

Данная проблема усложнаяется в случае различных платформ. Даже в случае UNIX и Windows то, что оптимально на одной системе, не подходит для другой. Если копия базы данных предназначена для реальной эксплуатации, необходимо повторить процесс настройки. Если необходимо переместить базу данных на zSeries^TM, некоторые из данных рассуждений будут неприменимы, следует просмотреть соответствующие руководства и красные книги (Redbooks). На системе iSeries физическая настройка выполняется полностью вне среды базы данных, поэтому следует просмотреть руководства по системному управлению iSeries^TM .

В начало

Заключение

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

Ресурсы

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

Справочник по SQL:

• Примите участие в обсуждении материала на форуме.
  
  
• Команда CREATE DATABASE;
  
  
• Оператор CREATE TABLESPACE;
  
  
• Оператор ALTER TABLESPACE;
  
  
• Оператор CREATE BUFFERPOOL;
  
  
• Оператор ALTER BUFFERPOOL.
  

Другие справочники по табличным пространствам и буферным пулам:

• Как DB2 использует память;
  
  
• Проектирование и выбор табличных пространств;
  
  
• Управление буферным пулом базы данных
  

Статьи с DB2 Developer Domain:

• Хранение в DB2 -
  http://www.ibm.com/developerworks/db2/library/techarticle/adamache/0621_adamache.html
  
  
• Настройка для оперативной обработки транзакций и создания хранилищ данных -
  http://www.db2mag.com/db_area/archives/2002/q3/hayes.shtml
  

Подробнее о программе PartnerWorld for Developers можно узнать на сайте http://www.developer.ibm.com/.

Примите участие в форуме по Information Management;

Об авторах

		Дэвид Клайн (David Kline) работает представителем службы технической поддержки DB2 для программы PartnerWorld for Developers. Вместе с другими 10 членами группы Дэвид помогает независимым разработчикам программного обеспечения (ISV) решать различные проблемы, связанные с разработкой и администрированием. Дэвид является сертифицированным специалистом по разработке и администированию приложений в DB2. Большую часть своего времени он помогает независимым разработчикам решать проблемы, связанные с DBA (администрирование баз данных). Подробнее о программе PartnerWorld for Developers можно узнать на сайте http://www.developer.ibm.com/.

		Габор Визер (Gabor Wieser) занимается информационными технологиями около тридцати лет. В прошлом году он вступил в организацию PartnerWorld for Developers и предоставляет разработчикам DB2 услуги, связанные с техническим обслуживанием и поддержкой. Габор работал системным программистом в сфере суперкомпьютеров и разработчиком программ. В последние десять лет он занимался разработкой, обслуживанием и настройкой баз данных на различных платформах. В настоящее время он занимается поддержкой разработчиков, использующих DB2 UDB на ОС Windows/UNIX и DB2/400 на iSeries. Он специализируется в администрировании баз данных, средствах расширения и взаимосвязи систем. С Габором можно связаться по электронной почте: gaborw@us.ibm.com

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало