Советы по настройке DB2 для OLTP-приложений

В данной статье приведено несколько советов по настройке DB2, основанных на опыте выполнения тестов производительности Online Transaction Processing (OLTP) - TPC-C, TPC-W, Trade2 и др. На производительность приложения, работающего с базами данных, может влиять множество факторов. В данной статье внимание уделяется конфигурационным аспектам DB2 и не рассматриваются вопросы, связанные с планированием производительности, проектированием структуры базы данных или приложения за исключением некоторых кратких напоминаний.

Йонгли Эн, инженер по производительности DB2, IBM Toronto Lab

Йонгли Эн (Yongli An) - инженер и сертифицированный специалист IBM по DB2 UDB. Йонгли специализируется на оценке производительности TPC-C и в настоящее время занимается производительностью DB2 для WebSphere Advanced Server и приложений e-business.



Питер Шам, менеджер по производительности DB2 e-business, IBM Toronto Lab, Canada

Питер Шам (Peter Shum) работает менеджером по производительности DB2 e-business. Отвечает за производительность DB2 для TPC-C, TPC-W, WebSphere Advanced Server и CommerceSuite. До этого занимался разработкой DB2, а именно - поддержкой TP Monitor и архитектуры распределенных реляционных баз данных.



18.03.2008

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

Введение

DB2® Universal Database™ (UDB) - это первая мультимедийная, настроенная на работу с Web система управления реляционными базами данных, являющаяся достаточно мощной для удовлетворения требований крупных предприятий и достаточно гибкой для обслуживания предприятий малого и среднего размеров. Семейство программных продуктов DB2 совместно с интернет-технологиями обеспечивает легкую доступность и защиту информации для различных платформ. Решениям IBM для управления данными отдали предпочтение более 60 миллионов пользователей DB2 из более чем 300000 компаний, расположенных по всему миру.

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

Оперативная обработка транзакций (Online transaction processing - OLTP) - это класс приложений, ориентированных на работу с транзакциями (обычно транзакциями для записи и извлечения данных) в различных отраслях, включая банки, авиакомпании, почту, супермаркеты и другие предприятия. Обычно рабочая нагрузка OLTP состоит из нескольких параллельно выполняющихся коротких транзакций. Современная оперативная обработка транзакций нуждается в поддержке транзакций, распределенных по сети и, возможно, охватывающих более одной компании. По этим причинам новое программное обеспечение OLTP для работы на различных компьютерных платформах в сети использует технологию клиент/сервер и посредническое программное обеспечение.

Производительность является одним из самых важных факторов в системе управления базами данных любого типа. В данной статье внимание уделяется нескольким советам по настройке производительности DB2, основанным на опыте выполнения тестов производительности OLTP-типа (TPC-C, TPC-W, Trade2 и др.). Хотя на производительность приложения, работающего с базами данных, может оказывать влияние множество факторов, мы концентрируемся на конфигурировании и не рассматриваем вопросы планирования производительности, проектирования структуры базы данных и приложения.

Данная статья организована следующим образом:

Основы производительности.

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

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

Используя данные советы, вы можете обеспечить вашему OLTP-приложению достаточно хорошую производительность.


Основы производительности

  1. Наличие достаточного объема оперативной памяти.
    • Для 32-разрядной системы используйте как минимум 512 MB RAM на CPU (до 4 GB на машину) для поддержки буферных пулов, DB-агентов и других совместно используемых объектов, необходимых при большом количестве одновременно работающих пользователей (дополнительная информация по буферным пулам приведена в разделе "Размер буферного пула (BUFFPAGE)"). Больший объем памяти может понадобиться для поддержки приложений, выполняющихся локально или как хранимые процедуры. На AIX® файловым кэшем JFS может использоваться дополнительная оперативная память для поддержки буферного пула.
    • Для 64-разрядных систем буферные пулы могут иметь практически любой размер. Однако для большинства OLTP-приложений электронной коммерции, использующих большие базы данных, достаточно иметь буферный пул размером не более 8 GB. Больше все равно лучше, но в определенный момент вы столкнетесь с уменьшением производительности, связанным с достижением 98% использования памяти буферным пулом. Объем необходимой оперативной памяти определяется количеством одновременно работающих пользователей (влияющим на количество DB2-агентов).
    • Объем оперативной памяти, необходимый для каждого соединения пользователя с базой данных (то есть с DB2-агентом), зависит от природы SQL-выражения, выполняемого приложением - например, количество одновременно открытых указателей и объем необходимого пространства для сортировки и временной области. Для OLTP-приложений на объем пространства для сортировки и временной области должно тратиться меньше памяти, и в любой момент времени должно быть одновременно открыто только небольшое количество указателей.
    • Практическое правило: Используйте минимум 1 MB в UNIX и 500 KB в Windows для каждого DB2-агента. Если используются встроенные хранимые процедуры, каждое пользовательское соединение занимает два DB2-агента в дополнение к памяти, необходимой для выполнения самой хранимой процедуры.

  2. Наличие достаточной производительности обработки операций ввода/вывода (I/O).
    • Должно иметься достаточное количество дисковых накопителей для обеспечения необходимого параллелизма операций I/O, поддерживающих большой объем одновременных транзакций. Необходимо иметь, по крайней мере, от 5 до 10 дисков на CPU для средних рабочих нагрузок, и 20 дисков для больших рабочих нагрузок OLTP. Операционная система (включая область подкачки (paging)), DB2-журналы и пространство для DB2-таблиц должны располагаться на своих собственных выделенных дисках. Должно быть несколько дисков для DB2-журналов, таблиц и индексов.
    • Корректным способом оценки мощности обработки операций I/O, необходимой для хорошей производительности, является реальное прототипирование транзакций и определение необходимого для каждой транзакции количества операций ввода/вывода и количества транзакций в секунду. Затем нужно определить пропускную способность контроллера дисков и дисковой подсистемы для подсчета необходимого количества контроллеров и дисков.
  3. Наличие достаточной пропускной способности сети.

    Необходимо иметь достаточную сетевую пропускную способность для поддержки рабочих нагрузок. Убедитесь в том, что сеть и все промежуточные маршрутизаторы не ограничивают пропускную способность. Это особенно важно для поддержки удаленного доступа. Например, серия T1 поддерживает 1.544 Mbit/sec, что составляет только 0.193 MB/sec, в то время как обычная сеть 10 Mbit/sec Ethernet LAN может поддерживать шестикратную пропускную способность на 1.25 MB/sec. Используйте такие команды как netstat на UNIX для просмотра объемов трафика ваших соединений.

  4. Используйте программу DB2 Performance Configuration Wizard из DB2 Control Center для настройки начальных параметров DB2 Database Manager и Database Configuration.

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

  5. Индексируйте ответствующим образом столбцы ваших таблиц.
    • Индексируйте столбцы, вовлеченные в запросы.
    • Индексация столбцов, упоминающихся в выражениях ORDER BY и GROUP BY, может повысить производительность.
    • Данные, к которым часто производится обращение, тоже можно включить в индекс как столбцы INCLUDED.
    • Используйте Index Advisor (известный также под названием Index Wizard из DB2 Control Center), который поможет определить нужный набор индексов на основе используемых вами таблиц и SQL-запросов.
  6. Приложение должно использовать блокировки как можно более короткое время.
    • Когда действие пользователя порождает несколько взаимодействий, каждое взаимодействие должно подтверждать свою собственную транзакцию и освобождать все блокировки перед возвратом управления пользователю. Поддерживайте как можно меньшую продолжительность транзакции, выполняя ее первый SQL-запрос (начинающий транзакцию) как можно более позже и обновляя (операциями вставки, обновления и удаления, которые используют исключающие блокировки) как можно более ближе к стадии подтверждения транзакции (commit).
    • Использование параметра реестра DB2_RR_TO_RS может улучшить параллелизм путем исключения блокировки следующего ключа вставляемой или обновляемой строки. Это можно использовать в том случае, когда какой-либо программой, работающей с данным набором таблиц, не применяется уровень изоляции RR (Repeatable Read). Используйте DB2 Snapshot для мониторинга количества взаимных блокировок и блокировок, находящихся в состоянии ожидания.
  7. Используйте хранимые процедуры или составные SQL-запросы для минимизации использования сетевых ресурсов.
    • Минимизация объема сетевого трафика для SQL-запросов сократит сетевые задержки и время на переключения контекста, что может привести к более коротким периодам времени блокировки для приложений. Обычно хранимые процедуры должны использоваться для OLTP-транзакций, состоящих из более чем 4 или 5 запросов.
    • С другой стороны, если логика приложения требует сложной обработки, интенсивно использующей CPU, помещение ее в хранимую процедуру, выполняющуюся на сервере базы данных, может привести к излишним CPU-циклам за счет операций с базами данных. В этом случае либо вообще не используйте хранимую процедуру, либо выполняйте часть логики на стороне клиента, а часть в хранимой процедуре.
  8. Эффективно используйте SQL.
    • Не используйте несколько SQL-запросов там, где достаточно одного. При предоставлении в запросе более детализированных условий поиска большим количеством предикатов оптимизатор может сделать более удачный выбор. Вы также должны указывать в запросе более узкие условия выбора, для того чтобы сервер базы данных не возвращал больше строк и столбцов, чем это необходимо. Например, используйте SQL для фильтрации необходимых вам строк; не возвращайте все строки для последующей фильтрации приложением.
  9. Анализируйте план доступа.
    • Используйте программу Visual Explain или db2exfmt для анализа каждого SQL-запроса. Убедитесь в том, что используются соответствующие индексы для минимизации числа извлекаемых внутренне строк при выборке и соединении таблиц.

Обновление каталогизируемой статистики

Основы

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

  • Когда загружена таблица с данными, и были созданы соответствующие индексы.
  • При реорганизации таблицы с использованием инструментальной программы REORG.
  • Когда есть много операций по обновлению, удалению и вставке, которые влияют на таблицу и ее индексы ("много" в данном случае может означать воздействие на 10-20% данных таблиц и индексов).
  • Перед связыванием с прикладными программами, чья производительность является критически важным фактором.
  • Когда вы хотите сравнить новую статистику с предыдущей. Сбор статистики на регулярной основе позволяет обнаружить проблемы производительности на раннем этапе.
  • При изменении значения prefetch (предварительной выборки).
  • При использовании инструментальной программы REDISTRIBUTE NODEGROUP.

При оптимизации SQL-запросов принятые SQL-компилятором решения очень зависят от модели оптимизации содержимого базы данных. Эта модель используется оптимизатором для оценки стоимости альтернативных путей доступа, которые могут использоваться для выполнения конкретного запроса. Ключевым элементом модели данных является набор статистической информации, собранной о данных, содержащихся в базе данных, и хранящейся в системных таблицах catalog. К ней относятся статистика для таблиц, псевдонимов, индексов, столбцов и функций, определенных пользователем (user-defined functions - UDF). Изменение в статистике данных может привести к изменению плана доступа к необходимым данным, который должен быть максимально эффективным.

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

  • Количество страниц в таблице и количество непустых страниц.
  • Количество перемещений строк с их оригинальной страницы на другие страницы (переполнение).
  • Количество строк в таблице.
  • Статистическая информация о конкретных столбцах, например, количество отличающихся значений в столбце.
  • Уровень кластеризации индекса, то есть степень следования физической последовательности строк в таблице индексу.
  • Статистическая информация об индексе, например, число индексных уровней и число концевых страниц (leaf pages) в каждом индексе.
  • Число появлений часто используемых значений столбцов.
  • Распределение значений столбцов по диапазону значений, представленных в столбце.
  • Оценка затрат на функции, определенные пользователем (UDF).

Инструментальная программа RUNSTATS поможет определить, как производительность связана с изменениями в вашей базе данных. Статистика показывает распределение данных в таблице. При регулярном использовании RUNSTATS предоставляет данные о таблицах и индексах за период времени, позволяя таким образом идентифицировать тенденции изменения производительности для вашей модели данных. Перекомпонуйте приложения, использующие статические SQL-запросы, после использования RUNSTATS, для того чтобы оптимизатор запросов мог выбрать наилучший план доступа на основе новой статистики. Но для приложений, использующих динамические SQL-запросы (например, большинство приложений от производителей программного обеспечения), такая перекомпоновка не нужна, поскольку данные запросы будут оптимизироваться во время исполнения. При неточной информации о таблицах могут возникнуть проблемы в производительности. В наихудшем сценарии конкретный SQL-запрос может принудить DB2 к сканированию таблицы вместо индекса.

Как обновить статистику

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

  • Использование инструментальной программы RUNSTATS (run statistics).
  • Использование LOAD с указанием параметров сбора статистики.
  • Кодирование выражений SQL UPDATE, работающих с набором предопределенных представлений (views) catalog.
  • Использование команды "reorgchk update statistics".

Если вам не известны точно все названия таблиц или если их слишком много, самым простым способом выполнения RUNSTATS является использование команды "db2 reorgchk update statistics". Точный сценарий выглядит следующим образом:

 db2 -v connect to DB_NAME 
 db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes" 
 db2 -v reorgchk update statistics on table all 
 db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes" 
 db2 -v terminate

Выбранный нами пример не требует указания названий таблиц. Эта команда выполняет RUNSTATS для всех таблиц.

Напоминание: Не запускайте программу RUNSTATS, пока не заполнили данными базу данных.

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

 db2 -v runstats on table TAB_NAME and indexes all

Эта команда соберет статистику для таблицы и всех индексов (базовый уровень).

Проверка выполнения RUNSTATS

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

 db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"

Если RUNSTATS еще не была запущена, вы увидите "-1" для столбцов nleaf и nlevels, а для столбца stats_time - "-". Эти столбцы содержат действительные числа при выполнении RUNSTATS, а столбец stats_time будет содержать временную метку (timestamp) выполнения RUNSTATS. Если вы считаете, что время, указанное в stats_time слишком старое, пора выполнить runstats снова.


Мониторинг и настройка конфигурационных параметров базы данных

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


Размер буферного пула

Основы

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

По умолчанию используют буферный пул с названием IBMDEFAULTBP, который создается при создании базы данных. Конфигурационный параметр базы данных DB2 BUFFPAGE управляет размером буферного пула, когда для этого буферного пула значение NPAGES в системной таблице SYSCAT.BUFFERPOOLS равно -1. В противном случае параметр BUFFPAGE игнорируется, а буферный пул создается с числом страниц, указанным в параметре NPAGES.

Рекомендации

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

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

  • Для начала, при наличии достаточного объема оперативной памяти на вашей машине, установите BUFFPAGE в значение 40000 страниц (160 MB), или 10% от всего объема установленной памяти.
  • Для большой базы данных OLTP установите настолько большое значение памяти для буферного пула, насколько это возможно при сохранении стабильного функционирования системы. Для начала попробуйте 1.6 GB и поэкспериментируйте с более высокими значениями.

Как менять параметр

Выполните следующий сценарий с целью:

  1. Проверки значения catalog.
  2. Разрешения использования конфигурационного параметра BUFFPAGE.
  3. Обновления значения BUFFPAGE для всех баз данных.
 db2 -v connect to DB_NAME
 db2 -v select * from syscat.bufferpools
 db2 -v alter bufferpool IBMDEFAULTBP size -1
 db2 -v connect reset
 db2 -v update db cfg for dbname using BUFFPAGE bigger_value
 db2 -v terminate

Исследовательские этапы

Чтобы определить, используется ли параметр BUFFPAGE для размера буферного пула базы данных, выполните следующие команды:

 db2 -v connect to DB_NAME
 db2 -v SELECT * from SYSCAT.BUFFERPOOLS
 db2 -v connect reset
 db2 -v terminate

Проверьте результаты. Если все буферные пулы имеют значение NPAGES равное -1, тогда размер буферного пула управляется через параметр BUFFPAGE в конфигурации базы данных.

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

 db2 -v update monitor switches using bufferpool on 
 db2 -v get monitor switches db2 -v reset monitor all 
 -- выполните ваше приложение --
 db2 -v get snapshot for all databases > snap.out
 db2 -v get snapshot for dbm >> snap.out
 db2 -v get snapshot for all bufferpools >> snap.out
 db2 -v reset monitor all db2 -v terminate

Обязательно выполните команду "db2 -v get snapshot" до потери соединения с базой данных. Когда последнее приложение отключится от базы данных, она завершит работу, и вся статистика текущего состояния будет утрачена. Чтобы гарантировать наличие постоянного соединения, поддерживающего базу данных в активном состоянии, используйте один из следующих методов:

  • Поддерживайте одно отдельное соединение в окне, в котором собираете снимки состояния.
  • Используйте команду DB2 ACTIVATE DATABASE.

В полученной информации (либо в снимке состояния базы данных, либо в снимке состояния буферного пула) найдите записи "logical reads" и "physical reads", для того чтобы можно было вычислить коэффициент используемости буферного пула, который поможет в настройке ваших буферных пулов:

 -- Соответствующие строки из примера снимка текущего состояния буферного пула --
 Buffer pool data logical reads = 702033
 Buffer pool data physical reads = 0
 Buffer pool data writes = 414
 Buffer pool index logical reads = 168255
 Buffer pool index physical reads = 0

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

  (1 - (
    (buffer pool data physical reads + buffer pool index physical reads) 
     /
    (buffer pool data logical reads + pool index logical reads)
        )
   )
   * 100%

Это вычисление учитывает все страницы (индексов и данных), которые кэшируются буферным пулом. В идеальном случае это значение должно быть более 95% и насколько возможно более близким к 100%. Для увеличения коэффициента используемости буферного пула попробуйте следующее:

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

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


Размер буфера журналов регистрации (LOGBUFSZ)

Основы

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

  • Фиксация транзакции.
  • Заполнение буфера журнала регистрации.
  • Как результат какого-либо другого внутреннего события менеджера базы данных.

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

Как изменить параметр

Мы обнаружили, что значения по умолчанию для этого параметра, 8 (4KB страниц), обычно недостаточно для базы данных OLTP. Оптимальным значением LOGBUFSZ является 128, или 256 4KB страниц. Например, вы можете использовать приведенную ниже команду для изменения этого значения:

 db2 -v update database cfg for DB_NAME using LOGBUFSZ 256
 db2 -v terminate

Исследовательские этапы

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

 Log pages read = 0
 Log pages written = 12644

Обычно соотношение между "log pages read" и "log pages written" должно быть как можно меньше. Идеальным значением могло бы быть ноль прочитанных страниц журналов и большое число записанных страниц. При слишком большом значении "log pages read" необходимо увеличивать LOGBUFSZ.


Размер кучи приложения (APPHEAPSZ)

Основы

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

Как изменить параметр

Ниже приведены команды для изменения значения по умолчанию (128 4KB страниц для DB2 EE или 64 4KB страниц для DB2 EEE) на оптимальное значение:

 db2 -v update db cfg for DB_NAME using applheapsz 256
 db2 -v terminate

Исследовательские этапы

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


Размер кучи сортировки (SORTHEAP) и границы кучи сортировки (SHEAPTHRES)

Основы

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

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

  • Для приватных сортировок SHEAPTHRES является "мягким" (soft) граничным значением (для экземпляра) общего объема памяти, который может быть занят приватными сортировками в любой момент времени. Когда суммарная занимаемая приватной сортировкой память достигает этого предела, память, выделенная для дополнительных входящих запросов приватных сортировок, соответственно уменьшается.
  • Для разделяемых сортировок SHEAPTHRES является "жестким" (hard) граничным значением (для базы данных) суммарного объема памяти, занимаемой разделяемыми сортировками в любой момент времени. При достижении этого предела дальнейшие запросы памяти для разделяемых сортировок не разрешаются до тех пор, пока занимаемая память не уменьшится ниже предела, указанного в SHEAPTHRES.

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

Рекомендации

  • Используйте системный монитор базы данных для отслеживания активности операций сортировки.
  • Используйте соответствующие индексы для минимизации кучи сортировки.
  • При необходимости частых больших по размеру сортировок увеличьте значение SORTHEAP.
  • При увеличении SORTHEAP определите, не нужно ли настроить также параметр SHEAPTHRES в конфигурационном файле менеджера базы данных.
  • Размер кучи сортировки используется оптимизатором при определении способов доступа. Подумайте о перекомпоновке приложений (с использованием команды REBIND PACKAGE) после изменения данного параметра.
  • В идеальном случае вы должны установить параметр границы кучи сортировки (SHEAPTHRES) в приемлемое кратное значение для наибольшего параметра SORTHEAP, имеющегося в экземпляре вашего менеджера базы данных. Этот параметр должен быть, по крайней мере, в два раза больше наибольшего значения SORTHEAP, определенного для любой базы данных в экземпляре.

Как изменить параметры

Для изменения значений параметров SORTHEAP и SHEAPTHRES выполните следующие команды:

 -- SORTHEAP должен изменяться для конкретной базы данных --
 db2 -v update db cfg for DB_NAME using SORTHEAP a_value
 -- SHEAPTHRES является параметром менеджера базы данных --
 db2 -v update dbm cfg using SHEAPTHRES b_value
 db2 -v terminate

Исследовательские этапы

OLTP-приложения не должны выполнять большие сортировки. Они являются очень затратными по ресурсам CPU и I/O. Обычно адекватным значением является значение по умолчанию для SORTHEAP (256 4KB страниц). Фактически, для OLTP-транзакций с большой степенью параллелизма вам, возможно, придется уменьшить это значение. При необходимости дальнейших исследований вы можете выполнить следующую команду:

 db2 -v update monitor switches using sort on

Затем дайте вашему приложению немного поработать и введите команду:

db2 -v get snapshot for database on DBNAME

Просмотрите результаты работы, пример которых приведен ниже:

 Total sort heap allocated = 0
 Total sorts = 1
 Total sort time (ms) = 0
 Sort overflows = 0
 Active sorts = 0
 Commit statements attempted = 1
 Rollback statements attempted = 0
 Dynamic statements attempted = 4
 Static statements attempted = 1
 Binds/precompiles attempted = 0

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

 SortsPerTransaction = 
     (Total Sorts) 
      /
     (Commit statements attempted + Rollback statements attempted)  

 PercentSortOverflow = (Sort overflows * 100 ) / (Total sorts)

Практическое правило: Если значение SortsPerTransaction больше 5%, это может указывать на то, что имеется слишком много сортировок на транзакцию. Если значение PercentSortOverflow меньше 3%, возможно, происходят существенные и неожиданные большие сортировки. В этом случае увеличение SORTHEAP просто скрывает проблему производительности, но не устраняет ее. Правильным решением данной проблемы является улучшение плана доступа для проблематичных SQL-запросов путем добавления нужных индексов.


Количество агентов (MAXAGENTS, NUM_POOLAGENTS и NUM_INITAGENTS)

Основы

Конфигурационные параметры менеджера базы данных:

  • Параметр MAXAGENTS указывает максимальное количество агентов менеджера базы данных, доступных в любой момент времени для приема запросов от приложений. Значение MAXAGENTS должно быть равно как минимум сумме значений MAXAPPLS (максимальное число одновременно выполняющихся приложений) для всех баз данных, к которым осуществляется одновременный доступ. Если количество баз данных больше значения параметра NUMDB, самым безопасным путем является использование произведения NUMDB и наибольшего значения для MAXAPPLS. Каждый дополнительный агент требует некоторых служебных ресурсов, выделяемых во время начала работы менеджера баз данных.
  • Параметр NUM_POOLAGENTS является указателем значения, до которого может расти пул агентов. Если создается больше агентов, чем указано в этом параметре, они будут завершены принудительно после завершения выполнения их текущего запроса и не будут возвращаться в пул. Если значение этого параметра равно 0, будет создаваться столько агентов, сколько нужно, и они могут быть завершены после окончания выполнения их текущего запроса.

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

  • Параметр NUM_INITAGENTS определяет начальное число простаивающих агентов, создаваемых в пуле агентов во время DB2START. Указание существенного числа начальных агентов (хотя это и не обязательно) может ускорить время "прогрева" (warming-up) системы.

Рекомендации

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

Неплохим вариантом является оставить параметр NUM_INITAGENTS в значении по умолчанию.

Как изменить параметр

Для изменения параметров выполните следующие команды:

 db2 -v update dbm cfg using MAXAGENTS a_value
 db2 -v update dbm cfg using NUM_POOLAGENTS b_value
 db2 -v update dbm cfg using NUM_INITAGENTS c_value
 db2 -v terminate

Исследовательские этапы

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

 db2 -v get snapshot for database manager

и просмотреть следующие строки:

 High water mark for agents registered = 4
 High water mark for agents waiting for a token = 0
 Agents registered = 4
 Agents waiting for a token = 0
 Idle agents = 0
 Agents assigned from pool = 5
 Agents created from empty pool = 4
 Agents stolen from another application = 0
 High water mark for coordinating agents = 4
 Max agents overflow = 0

Если обнаружится, что записи "Agents waiting for a token" или "Agents stolen from another application" не равны 0, возможно, придется увеличить значение MAXAGENTS, чтобы менеджеру базы данных стало доступно большее число агентов.


Блокировки (LOCKLIST, MAXLOCKS и LOCKTIMEOUT)

Основы

Эти элементы управления, связанные с блокировками, являются конфигурационными параметрами базы данных:

  • LOCKLIST указывает объем памяти, выделяемой для списка блокировок. Существует один список блокировок на базу данных, который содержит блокировки, вызванные приложениями, одновременно подключенными к этой базе данных. Блокировка - это механизм, который применяется менеджером базы данных для управления одновременным доступом к данным нескольких приложений. Блокироваться могут как строки, так и таблицы. Каждая блокировка занимает в списке 32 или 64 байта в зависимости от того, имеет ли объект другие блокировки:
    • 64 байта необходимо для хранения записи о блокировке объекта, не имеющего других блокировок.
    • 32 байта необходимо для хранения записи о блокировке объекта, который уже имеет блокировку.
  • MAXLOCKS определяет процентное соотношение числа блокировок в списке, которого должно достичь приложение до выполнения менеджером базы данных процедуры расширения блокировок (lock escalation). Когда процентное соотношение блокировок, используемых одним приложением, в списке достигает значения MAXLOCKS, менеджер базы данных расширяет блокировки, что означает замену блокировок строк на блокировки страниц и, следовательно, уменьшение количества блокировок в списке. Когда число блокировок от одного приложения достигает общего размера списка, расширение блокировок выполняется для блокировок, используемых данным приложением. Процедура расширения блокировок может также активизироваться тогда, когда список блокировок превысит выделенный для него размер памяти. Менеджер базы данных определяет блокировки, которые нужно расширить, путем поиска в списке блокировок от конкретного приложения и определения таблицы с наибольшим числом блокированных строк. Если после замены их одной табличной блокировкой значение MAXLOCKS больше не превышается, процедура расширения блокировок прекращается. В противном случае она продолжается до тех пор, пока процентное соотношение блокировок в списке не снизится до значения, меньшего MAXLOCKS. Произведение значения параметра MAXLOCKS и значения параметра MAXAPPLS не может быть меньше 100.

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

Рекомендации по управлению размером блокировок таковы:

  • Часто выполняйте операцию фиксации транзакции для освобождения блокировок.
  • При выполнении большого количества обновлений, блокируйте всю таблицу на период транзакции перед обновлением (используя выражение SQL LOCK TABLE). При этом используется только одна блокировка и предотвращается взаимное влияние от других обновлений, но снижается параллелизм данных для других пользователей.
  • Используйте параметр LOCKSIZE выражения ALTER TABLE для управления методом блокировки, применяемым для конкретной таблицы на постоянной основе.
  • Проверьте уровень изоляции, используемый для приложения. Использование уровня изоляции Repeatable Read в некоторых случаях может привести к автоматической блокировке таблицы. Когда это возможно, используйте уровень изоляции Cursor Stability для уменьшения числа разделяемых блокировок. Если требования к целостности приложения не нарушаются, используйте уровень изоляции Uncommitted Read вместо Cursor Stability для дальнейшего уменьшения количества блокировок.

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

  1. Рассчитайте нижнюю границу для размера вашего списка блокировок: (512 * 32 * MAXAPPLS) / 4096, где 512 - это оценка среднего числа блокировок на приложение, а 32 - это количество байтов, требующихся для каждой блокировки объекта, уже имеющего блокировки.
  2. Рассчитайте верхнюю границу размера вашего списка блокировок: (512 * 64 * MAXAPPLS) / 4096, где 64 - это число байтов, требующихся для первой блокировки объекта.
  3. Оцените количество одновременно выполняющихся приложений, которые будут обращаться к данным, и выберите начальное значение, которое попадает в диапазон между рассчитанными нижней и верхней границами.

    Для настройки значения MAXLOCKS используйте системный монитор базы данных.

    При настройке MAXLOCKS учитывайте размер списка блокировок (LOCKLIST):

    MAXLOCKS = 100 * (512 блокировок на приложение * 32 байт на блокировку * 2) / (LOCKLIST * 4096 байт)

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

  4. LOCKTIMEOUT определяет количество секунд, в течение которых приложение будет ожидать получения блокировки. Этот параметр позволяет избежать глобальных взаимных блокировок для приложения.

    При установке этого параметра в 0 приложение не будет ожидать блокировку. В данном случае при недоступности блокировки во время запроса приложение немедленно получает код -911.

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

Рекомендации

Установите LOCKTIMEOUT для быстрого обнаружения ожиданий, возникших из-за ненормальной ситуации, например, из-за остановленной транзакции (возможно, как результат ухода пользователя со своей рабочей станции). Установите его в достаточно высокое значение, для того чтобы нормальные запросы на блокировку не заканчивались по тайм-ауту во время пиковых нагрузок, когда время ожидания блокировки увеличено.

В среде оперативной обработки транзакций (OLTP) начните со значения 30 секунд. В среде, в которой применяются только запросы, можно было бы начать с более высокого значения. В любом случае для настройки данного параметра используйте методы оценки производительности.

Как изменить параметры

Для изменения параметров блокировки выполните следующие команды:

 db2 -v update
 db cfg for DB_NAME using LOCKLIST a_number
 db2 -v update db cfg for DB_NAME using MAXLOCKS b_number
 db2 -v update db cfg for DB_NAME using LOCKTIMEOUT c_number
 db2 -v terminate

Исследовательские этапы

После заполнения списка блокировок производительность может снизиться, поскольку процедура расширения блокировок генерирует больше табличных блокировок и меньше строчных, что уменьшает уровень параллелизма разделяемых объектов базы данных. Кроме того, возможно возникновение большего числа взаимоблокировок между приложениями (поскольку все они ожидают ограниченное количество табличных блокировок), что приведет к откату транзакций. Когда число запросов блокировки для базы данных достигнет максимального значения, приложение получит SQLCODE -912. Если процедура расширения блокировок является причиной появления проблем производительности, возможно, придется увеличить значение параметра LOCKLIST или параметра MAXLOCKS. Вы можете использовать системный монитор базы данных, чтобы определить запуск процедуры расширения блокировок, а также отследить, сколько раз приложение (соединение) столкнулось с тайм-аутом ожидания блокировки или база данных обнаружила ситуацию тайм-аута для всех подключенных к ней приложений.

  1. Прежде всего, выполните следующие команды для включения монитора блокировок DB2:
     db2 -v update monitor switches using lock on
     db2 -v terminate
  2. Затем получите снимки текущего состояния базы данных:
     db2 -v get snapshot for database on DB_NAME
  3. В полученных результатах найдите следующие элементы:
     Locks held currently = 0
     Lock waits = 0
     Time database waited on locks (ms) = 0
     Lock list memory in use (Bytes) = 504
     Deadlocks detected = 0
     Lock escalations = 0
     Exclusive lock escalations = 0
     Agents currently waiting on locks = 0
     Lock Timeouts = 0
     Internal rollbacks due to deadlock = 0

Если показатель "Lock list memory in use (Bytes)" превышает 50% определенного размера LOCKLIST, увеличьте число 4KB страниц в конфигурационном параметре базы данных LOCKLIST. Расширения блокировок, тайм-ауты и взаимные блокировки укажут на определенные потенциальные проблемы в вашей системе или приложении. Проблемы блокировок обычно указывают на довольно значительные проблемы в уровне параллелизма приложений, которые должны быть решены до повышения параметра размера списка блокировок.


Максимальное количество активных приложений (MAXAPPLS)

Основы

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

Рекомендации

Для запуска OLTP-приложения нужно установить MAXAPPLS в корректное значение (достаточно большое, но не слишком) для поддержки максимального числа одновременных соединений. Для тех приложений, которые применяют пул соединений, мы предлагаем установить MAXAPPLS в размер пула соединений плюс один или два (только для случая, когда вам потребуется подключиться из командной строки для каких-либо действий).

Как изменить параметр

Для изменения значения MAXAPPLS выполните следующую команду:

 db2 -v update db cfg for DB_NAME using MAXAPPLS a_number
 db2 -v terminate

Исследовательские этапы

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

SQL1040N The maximum number of applications is already connected to 
the database. SQLSTATE=57030

Количество асинхронных очистителей страниц (NUM_IOCLEANERS)

Основы

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

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

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

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

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

Как изменить параметр

Для установки этого параметра в новое значение может использоваться следующая команда:

 db2 -v update db cfg for DB_NAME using NUM_IOCLEANERS a_number
 db2 -v terminate

Исследовательские этапы

Используйте системный монитор базы данных для настройки этого конфигурационного параметра при помощи информации из снимков текущего состояния (или монитора событий) об операциях записи из буферного пула.

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

 Buffer pool data writes = 0
 Asynchronous pool data page writes = 0 
 Buffer pool index writes = 0
 Asynchronous pool index page writes = 0 
 LSN Gap cleaner triggers    = 0
 Dirty page steal cleaner triggers  = 0
 Dirty page threshold cleaner triggers = 0

Как решить, когда нужно уменьшать или увеличивать NUM_IOCLEANERS?

Уменьшайте значение параметра NUM_IOCLEANERS при одновременном возникновении двух следующих ситуаций:

  • "Buffer pool data writes" примерно равен "Asynchronous pool data page writes".
  • "Buffer pool index writes" примерно равен "Asynchronous pool index page writes".

Увеличивайте значение параметра NUM_IOCLEANERS при возникновении одной из следующих ситуаций:

  • "Buffer pool data writes" намного больше, чем "Asynchronous pool data page writes".
  • "Buffer pool index writes" намного больше, чем "Asynchronous pool index page writes".

Счетчик "Dirty page steal cleaner triggers" сообщает число раз, когда был активизирован очиститель страниц из-за необходимости синхронной записи во время замены буфера для базы данных. Для улучшения времени реакции это число должно быть как можно более маленьким. С приведенными выше счетчиками можно использовать следующую формулу для вычисления процентного соотношения активизаций всех очистителей, представленных этим элементом:

 Dirty page steal cleaner triggers
 /
 (Dirty page steal cleaner triggers +
  Dirty page threshold cleaner triggers +
  LSN Gap cleaner triggers)

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


Количество серверов I/O (NUM_IOSERVERS)

Основы

Серверы I/O используются агентами базы данных для выполнения операций упреждающего ввода/вывода или асинхронных операций ввода/вывода для таких инструментальных программ как backup и restore. Этот конфигурационный параметр базы данных указывает количество серверов I/O для базы данных. В любой момент времени не может использоваться большее число операций предварительной выборки и сервисных программ для базы данных. Сервер I/O ожидает, пока не завершится операция ввода/вывода, которую он инициировал. Операции ввода/вывода, не использующие предварительную выборку, управляются непосредственно агентами базы данных и поэтому не ограничиваются параметром NUM_IOSERVERS.

Рекомендации

В OLTP-среде используйте значение по умолчанию.

Как изменить параметр

Используйте следующую команду для установки нового значения NUM_IOSERVERS:

 db2 -v update db cfg for DB_NAME using NUM_IOSERVERS a_number
 db2 -v terminate

Количество фиксаций транзакций для группы (MINCOMMIT)

Основы

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

Рекомендации

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

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

 MINCOMMIT * (используемый размер пространства для журналов, в среднем, на транзакцию)

Для настройки данного параметра можно использовать системный монитор базы данных следующим образом:

  • Вычислите пиковое число транзакций в секунду:

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

    В начале измерений выполните команду:

     db2 -v reset monitor for database db_name

    (Она не сбросит счетчики для верхних значений water mark.)

    2. В конце измерений выполните следующую команду:

     db2 -v get snapshot for database on db_name

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

     Last reset timestamp = 06-12-2001 14:51:43.786876
     Snapshot timestamp = 06-12-2001 14:56:27.787088
     Commit statements attempted = 1011
     Rollback statements attempted = 10
     Log space used by the database (Bytes) = 3990

    Пусть totalTransactions будет суммой "commit statements attempted" и "rollback statements attempted".

    Пусть totalElapsedTime (в секундах) будет разностью между "Last reset timestamp" и "Snapshot timestamp". Количество транзакций в секунду вычисляется так:

     NumOfTransPerSecond = totalTransactions / totalElapsedTime
  • Вычислите объем памяти журналов, используемой на транзакцию:

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

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

    db2 -v reset monitor for database db_name.

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

    db2 -v get snapshot for database on db2_name.

    3. Сгенерируется информация, аналогичная приведенной выше.

    4. Вычислите используемое пространство для журналов при помощи следующей формулы:

     LogSpaceUsedPerTrans = log_space_used / totalTransactions

Как изменить параметр

Для изменения значения параметра MINCOMMIT используется команда:

 db2 -v update db cfg for DB_NAME using MINCOMMIT a_number
 db2 -v terminate

Резюме

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

Ресурсы

Комментарии

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=295657
ArticleTitle=Советы по настройке DB2 для OLTP-приложений
publish-date=03182008