При создании базы данных, для целей 1С:Предприятия создаются 5 табличных пространств и соответствующие им буферные пулы, выполняющие роль кэша конкретного табличного пространства. Хотя DB2 позволяет использовать один буферный пул для кэширования нескольких табличных пространств, анализ производительности решений на базе 1С:Предприятия показал, что оптимальным является создание отдельного буферного пула на каждое табличное пространство.
Ниже приведено краткое описание предназначения пар «табличное пространство/буферный пул»
V81C_USERTEMP/V81C_USERTEMPBP | используются для временных таблиц. |
V81C_TEMPSPACE/V81C_SYSTEMPBP | используется для внутренних сортировок и join'ов |
V81C_LARGESPACE/V81C_LARGEBP | используются непосредственно для хранения данных, за исключением бинарных объектов. |
V81C_LOBSPACE/V81C_LOBBP | Используется для хранения бинарных объектов |
V81C_INDEXSPACE/V81C_INDEXBP | используется для индексов |
Версия 8.1 также создавала еще одну пару V81C_USERSPACE/V81C_USERBP, которая не использовалась и являлась резервной. В дальнейшем было принято решение от нее вообще отказаться, и в версии 8.2 этой пары нет.
DDL для создание буферных пулов и табличных пространств в новой базе данных выглядит следующим образом. (на момент написания статьи)
------------------------------------
-- DDL Statements for BUFFERPOOLS --
------------------------------------
CREATE BUFFERPOOL "V81C_USERTEMPBP" SIZE 8000 AUTOMATIC PAGESIZE 32768;
CREATE BUFFERPOOL "V81C_SYSTEMPBP" SIZE 1000 AUTOMATIC PAGESIZE 32768;
CREATE BUFFERPOOL "V81C_LARGEBP" SIZE 5000 AUTOMATIC PAGESIZE 32768;
CREATE BUFFERPOOL "V81C_LOBBP" SIZE 1000 AUTOMATIC PAGESIZE 16384;
CREATE BUFFERPOOL "V81C_INDEXBP" SIZE 16000 AUTOMATIC PAGESIZE 8192;
------------------------------------
-- DDL Statements for TABLESPACES --
------------------------------------
CREATE LARGE TABLESPACE "V81C_LOBSPACE" PAGESIZE 16384 MANAGED BY DATABASE
USING (FILE 'V81C_LOBSPACE\space.1' 2048,
FILE 'V81C_LOBSPACE\space.2' 2048)
EXTENTSIZE 2
PREFETCHSIZE AUTOMATIC
BUFFERPOOL V81C_LOBBP
AUTORESIZE YES
MAXSIZE NONE
FILE SYSTEM CACHING
DROPPED TABLE RECOVERY OFF;
CREATE USER TEMPORARY TABLESPACE "V81C_USERTEMP" PAGESIZE 32768 MANAGED BY DATABASE
USING (FILE 'V81C_USERTEMP\space.1' 256)
EXTENTSIZE 4
PREFETCHSIZE AUTOMATIC
BUFFERPOOL V81C_USERTEMPBP
AUTORESIZE YES
MAXSIZE NONE
NO FILE SYSTEM CACHING
DROPPED TABLE RECOVERY OFF;
CREATE LARGE TABLESPACE "V81C_LARGESPACE" PAGESIZE 32768 MANAGED BY DATABASE
USING (FILE 'V81C_LARGESPACE\space.1' 512,
FILE 'V81C_LARGESPACE\space.2' 512)
EXTENTSIZE 4
PREFETCHSIZE AUTOMATIC
BUFFERPOOL V81C_LARGEBP
AUTORESIZE YES
MAXSIZE NONE
NO FILE SYSTEM CACHING
DROPPED TABLE RECOVERY OFF;
CREATE LARGE TABLESPACE "V81C_INDEXSPACE" PAGESIZE 8192 MANAGED BY DATABASE
USING (FILE 'V81C_INDEXSPACE\space.1' 2048,
FILE 'V81C_INDEXSPACE\space.2' 2048)
EXTENTSIZE 8
PREFETCHSIZE AUTOMATIC
BUFFERPOOL V81C_INDEXBP
AUTORESIZE YES
MAXSIZE NONE
NO FILE SYSTEM CACHING
DROPPED TABLE RECOVERY OFF;
абличное пространство V81C_TEMPSPACE создается при создании базы данных, поэтому отдельного DDL описания на него нет.
Давайте на примере V81C_INDEXSPACE более подробно рассмотрим некоторые аспекты устройства табличного пространства и его месторасположение на диске.
У каждого табличного пространства есть т.н. контейнеры, т.е. место хранения данных. В случае 1С роль контейнеров выполняют файлы. Для V81C_INDEXSPACE создается два файла, начальным размером 2048 страниц каждый. Мы можем пересчитать это в байты: умножим размер страницы табличного пространства (8192 в данном случае) на 2048. Получается, что начальный размер файлов имеет размер 16 мегабайт.
По-умолчанию файлы контейнеров располагаются относительно корневого каталога базы данных на диске. Узнать их абсолютное месторасположение можно командой (нужно предварительно соединиться с базой)
F:\ >db2 list tablespace containers for 5
Tablespace Containers for Tablespace 5
Container ID = 0
Name = E:\DB2_02\NODE0000\SQL00008\V81C_INDEXSPACE\space.1
Type = File
Container ID = 1
Name = E:\DB2_02\NODE0000\SQL00008\V81C_INDEXSPACE\space.2
Type = File
Спросите, откуда взялась цифра 5? Это идентификатор табличного пространства в базе данных. Его можно получить из системных каталогов, о чем будет рассказано ниже. В принципе, поскольку порядок создания табличных пространств и буферных пулов у 1С:Предприятия всегда одинаков, достаточно запомнить пару табличек, приведенных ниже.
ТАБЛИЧНЫЕ ПРОСТРАНСТВА
ИМЯ | ID 1Cv8.2 | ID 1Cv8.1 |
---|
V81C_TEMPSPACE | 1 | 1 |
V81C_LOBSPACE | 2 | 2 |
V81C_USERTEMP | 3 | 3 |
V81C_LARGESPACE | 4 | 5 |
V81C_INDEXSPACE | 5 | 6 |
Таблица 1
БУФЕРНЫЕ ПУЛЫ
ИМЯ | ID 1Cv8.2 | ID 1Cv8.1 |
---|
V81C_USERTEMPBP | 2 | 2 |
V81C_SYSTEMBP | 3 | 3 |
V81C_LARGEBP | 4 | 4 |
V81C_LOBBP | 5 | 6 |
V81C_INDEXBP | 6 | 7 |
Таблица 2
Продолжим рассмотрение параметров табличного пространства.
Мы видим, что контейнеры могут автоматически менять размер (AUTORESIZE YES) и их размер фактически ограничен размером доступного места на файловой системе (MAXSIZE NONE). Также интересен тот факт, что у табличного пространства отключено кэширование на уровне файловой системы (NO FILE SYSTEM CACHING). Сделано это преднамеренно. Поскольку данные табличного пространства кэшируются буферными пулами, то кэширование на уровне файловой системы является избыточным. При этом следует отметить, что для табличного пространства V81C_LOBSPACE кэширование на уровне файловой системы включено. Это также сделано преднамеренно, поскольку бинарные объекты не кэшируются буферными пулами и всегда читаются напрямую с диска, то в данном случае кэширование на уровне файловой системы не является избыточным и позволяет повысить производительность системы.
Тогда зачем табличному пространству V81C_LOBSPACE отдельный буферный пул? Ведь можно было бы <прицепить> к нему один из существующих. Дело в том, что размер страницы буферного пула должен совпадать с размером страницы табличного пространства. Как мы видим, у нас кроме V81C_LOBSPACE нет табличного пространства с размером страницы 16К, поэтому и появился отдельный буферный пул, с размером в 1000 страниц.