ArcGIS Help 10.2 - Минимизация конкуренции операций дискового ввода/вывода в DB2

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

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

Для временных табличных пространств пользователя используйте SMS; для всех других табличных пространств используйте DMS.
В DB2 есть два типа моделей табличного пространства: Пространство, управляемое системой (System Managed Space (SMS)) и Пространство, управляемое базой данных (Database Managed Space (DMS)). ESRI рекомендует использовать табличные пространства SMS для временных табличных пространств пользователя и DMS для остальных табличных пространств, чтобы оптимизировать производительность, особенно если предполагается регулярное увеличение объема данных.
Примечание:

В DB2 9 требуется дополнительная глобальная временная таблица DB2 (DECLARE GLOBAL TEMPORARY TABLE). Согласно документации DB2, для объявления глобальных таблиц temp необходимы "права доступа SYSADM или DBADM" или "права доступа USE в табличном пространстве USER TEMPORARY"

В версии DB2 9 можно использовать функции Automatic Storage для баз данных, а также встраивать атрибуты Automatic Sizing для табличных пространств. В DB2 9 табличные пространства DMS обладают свойством обеспечивать дополнительное пространство при увеличении требований к физическому пространству.
Настройте буферные пулы.
Настройка буферных пулов критична для производительности. По умолчанию в DB2 предусматривается единственный буферный пул, именуемый IBMDEFAULTBP. В DB2 9 размер буферного пула IBMDEFAULTBP по умолчанию настраивается автоматически. Менеджер базы данных меняет размер этого буферного пула в зависимости от рабочей нагрузки.

Для каждого табличного пространства следует создать отдельный буферный пул. Проверьте число операций физического считывания буферного пула для создания мгновенного снимка базы данных. Буферный пул должен быть достаточно большим для перерисовки карты небольшим числом операций физического считывания. Чтобы определить эффективность буферного пула, вычислите коэффициент попадания в буферный пул (buffer pool hit ratio (BPHR)). В идеале коэффициент BPHR должен превышать 90%. Формула имеет следующий вид:
```
BPHR (%) = (1 - (("Buffer pool data physical reads" 
+ "Buffer pool index physical reads")
 / ("Buffer pool data logical reads" 
+ "Buffer pool index logical reads"))) * 100
```
В другом методе определения коэффициентов попадания в буферный пул используется административный вид SYSIBMADM.BP_HITRATIO. Этот вид возвращает коэффициенты попадания, в том числе общий коэффициент попадания, коэффициент попадания данных, коэффициент попадания XDA и коэффициент попадания индексов для всех буферных пулов.
```
SELECT SUBSTR(DB_NAME,1,8) AS DB_NAME, 	
SUBSTR(BP_NAME,1,140) AS BP_NAME,
TOTAL_HIT_RATIO_PERCENT, 
DATA_HIT_RATIO_PERCENT, 	
INDEX_HIT_RATIO_PERCENT, 
XDA_HIT_RATIO_PERCENT, DBPARTITIONNUM
FROM SYSIBMADM.BP_HITRATIO
ORDER BY DBPARTITIONNUM
```
Установите пороговый размер таблицы.
Возьмите за правило хранить маленькие таблицы вместе в одном табличном пространстве, а большие таблицы – по отдельности, в индивидуальных табличных пространствах. Решите, каким должен быть размер таблицы для хранения ее в индивидуальном табличном пространстве. Пороговое значение обычно частично определяется максимальным размером контейнера. Таблицы, способные заполнить контейнер максимального размера, следует хранить в отдельном табличном пространстве. Это же может касаться и таблиц, размер которых близок к этому пределу. Придерживайтесь единых правил для индексов. Разделяйте таблицы и индексы на те, которые должны храниться в индивидуальных табличных пространствах, и те, которые должны группироваться вместе. Ни в коем случае не храните большие или часто используемые таблицы вместе с их индексами в одном табличном пространстве. Если вы используете DB2 9, подумайте о встраивании атрибутов Automatic Storage для табличных пространств.
Храните маленькие таблицы и индексы, исходя из частоты их использования.
Принимайте решение о том, какие маленькие таблицы должны храниться вместе в одном табличном пространстве, исходя из ожидаемой частоты их использования. Храните часто используемые таблицы в одном табличном пространстве, а редко используемые таблицы – в другом. Это позволяет размещать контейнеры часто используемых табличных пространств с редко используемыми контейнерами. Это же правило применяется к индексам. Их тоже следует разделять по частоте использования. Рекомендуется хранить журналы DB2 на других дисках, отдельно от индексов и данных. ESRI рекомендует использовать для параметра ядра операционной системы MAXUPROC значение, превышающее значение по умолчанию, чтобы обеспечить выполнение всех собственных процессов пользователей ArcSDE и экземпляра DB2 при их вызове.
В операционных системах AIX отключите db2set DB2_MMAP_READ и db2set DB2_MMAP_WRITE.
Для повышения производительности ESRI рекомендует отключить следующие переменные в AIX. В сочетании, эти переменные обеспечивают использование в DB2 многофункциональной, мультисервисной платформы доступа (multiservice access platform (MMAP)), как альтернативного метода ввода/вывода. Она используется, чтобы избежать блокировок операционной системы при записи нескольких процессов в различные секции одного и того же файла. Значением по умолчанию является ON.
```
db2set DB2_MMAP_READ=OFF
db2set DB2_MMAP_WRITE=OFF
```
Если вы широко применяете версионное редактирование, разделяйте системные табличные пространства ArcSDE STATES, STATE_LINEAGES и таблицы MVTABLES_MODIFIED и их индексы.
В системных табличных пространствах ArcSDE хранятся системные таблицы и индексы ArcSDE и базы геоданных, созданные командой sdesetup ArcSDE. Число и расположение табличных пространств определяются назначением базы данных ArcSDE. Расположение этих таблиц и их индексов задается параметрами хранения ключевого слова конфигурации DBTUNE DATA_DICTIONARY. Ключевое слово DATA_DICTIONARY используется исключительно для создания системных таблиц ArcSDE и базы геоданных. Версионные базы данных, поддерживающие приложения ArcGIS, имеют высокоактивное дерево состояния. В дереве состояния отражаются состояния всех операций редактирования, которые были выполнены с таблицами, зарегистрированными как версионные. Четыре системные таблицы ArcSDE – STATES, STATE_LINEAGES, MVTABLES_MODIFIED и VERSIONS – содержат транзакционную информацию дерева состояний версионной базы данных. В активно используемой версионной базе данных таблица STATES_LINEAGE может легко увеличиваться до размера более одного миллиона записей и занимать более 26 MB табличного пространства. Таблица STATES намного меньше и содержит приблизительно 5000 записей, занимающих около 2 MБ табличного пространства. Таблица MVTABLES_MODIFIED обычно содержит приблизительно 50000 записей, занимающих около 1 MБ табличного пространства. Таблица VERSIONS обычно довольно мала и содержит менее 100 строк, занимающих около 64 KБ. Для приложений ArcGIS с интенсивным редактированием данных таблицы STATES, STATE_LINEAGES и MVTABLES_MODIFIED и их индексы необходимо создавать в отдельных табличных пространствах и распределять их по всей файловой системе для минимизации конкуренции между операциями дискового ввода/вывода.
Примечание:

Если вы не собираетесь использовать версионную базу данных, сократите экстент таблиц STATE_LINEAGES, STATES и MVTABLES_MODIFIED и их индексов до 40 KБ. Создайте два табличных пространства размером 5 MБ на разных дисках: одно – для таблиц, другое – для индексов.
Создайте достаточно большие табличные пространства для растровых таблиц и отдельное табличное пространство для таблицы блоков растров (BLK).
Таблица блоков растров может быть довольно объемной. Позаботьтесь о создании отдельного, большого табличного пространства для хранения этой таблицы. Вы можете создать другое табличное пространство для остальных таблиц растров. При создании табличного пространства для таблицы блоков растров рекомендуется использовать размер экстента 64 KБ и размер страницы 32 KБ. Размер экстента определяет число страниц страничного размера, которые будут записаны в контейнер перед тем, как перейти к следующему контейнеру.
Внимание:

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

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

5/10/2014