Инструменты DB2: Усовершенствования пакета DB2 Utilities Suite for z/OS

Недавно представленные новые возможности и функции пакета IBM® DB2® Utilities Suite for z/OS® позволяют этому набору инструментов лучше удовлетворять потребности заказчиков и ускоряют окупаемость их инвестиций в СУБД DB2. В данной статье подробно описываются новые параметры утилиты LOAD, новые опции утилиты REPAIR и новые гибкие возможности утилиты REORG.

Мэри Петрас, специалист-консультант по проектированию продуктов, IBM

Мэри Петрас (Mary Petras) работает в группе технической поддержки по инструментам и утилитам для продукта DB2 for z/OS. М. Петрас стала сотрудником IBM в 1996 г. и после этого совместно с заказчиками занималась миграцией совместно используемых данных DB2. Она неоднократно выступала с докладами на конференциях International DB2 Users Group (IDUG) и IBM Information On Demand (IOD). Кроме того, она является соавтором шести публикаций в серии IBM Redbooks, посвященных следующим темам: производительность DB2, инструментов для повышения производительности продукта DB2 for z/OS, совместное использование данных DB2.



15.01.2013

Обзор

Недавние усовершенствования пакета DB2 Utilities Suite for z/OS (DB2 Utilities Suite) наглядно демонстрируют, что IBM продолжает развивать этот пакет, а также повышать стратегическую значимость данной платформы. Многие из этих усовершенствований были реализованы как способы решения различных проблем, впервые описанных заказчиками. IBM непрерывно анализирует поступающую информацию о проблемах заказчиков. Поскольку соответствующие усовершенствования были бы полезны всему сообществу DB2, лаборатория разработки выделила рабочее время и ресурсы на создание решений, которые оказались бы полезными множеству пользователей утилит DB2. Эти усовершенствования не только улучшат такие показатели, как производительность, удобство использования и доступность, но и наглядно продемонстрируют, что группа по разработке DB2 Utilities в лаборатории Silicon Valley Lab стремится повысить окупаемость инвестиций заказчиков.

Перечисленные ниже усовершенствования пакета DB2 Utility Suite касаются технического обслуживания.

  • Утилита LOAD/UNLOAD — параметр NUMRECS
  • Утилита LOAD — параметр PRESORTED
  • Утилита LOAD/UNLOAD — параметр FORMAT INTERNAL
  • Опции REPAIR SET — RBDP и PAGE SET RBDP — и новые усовершенствования утилиты LOAD в области поведения
  • Утилита REORG — параметр PARALLEL YES | NO

Утилита LOAD/UNLOAD — параметр NUMRECS

Утилита LOAD сможет более эффективно определить размеры подлежащего выделению рабочего пространства для сортировки, если она заранее будет знать приблизительное количество нуждающихся в сортировке записей, особенно если входной набор данных размещен на ленте. В прошлом для предоставления утилите LOAD этой информации требовался параметр SORTKEYS. Формула в документе DB2 Utility Guide and Reference описывает, как оценивается количество ключей для сортировки. Определение корректного значения параметра SORTKEYS может оказаться сложной задачей, а в вычислениях можно легко сделать ошибку. Пользователи сообщили о наличии нескольких проблем при определении значения SORTKEYS. Во-первых, вышеупомянутая формула весьма сложна. Кроме того, получаемое значение является не реальным количеством загружаемых пользователем записей, а количеством загружаемых записей, умноженным на количество индексов в таблице. Если в вашей в таблице имеются RI-отношения, необходимо учесть это обстоятельство при задании надлежащего значения SORTKEYS. К счастью, когда вы выгружаете данные в таблицу, утилита UNLOAD предоставляет корректное значение параметра SORTKEYS в управляющем операторе утилиты LOAD, который она генерирует.

С другой стороны, пользователь могжет выгрузить эту таблицу в производственную среду, количество индексов в которой не совпадает с количеством индексов в вашей среде тестирования. Как результат, использование числа, генерированного утилитой UNLOAD, может оказаться большой ошибкой. Кроме того, пользователь вполне мог создать несколько дополнительных индексов после выгрузки данных. Непринятие во внимание этих дополнительных индексов может привести к выделению некорректного количества наборов данных для сортировки и к неудачному завершению работы утилиты UNLOAD с ошибками SORT CAPACITY EXCEEDED (превышение ресурсов, выделенных для сортировки).

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

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

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

Усовершенствование в виде нового параметра NUMRECS для утилит UNLOAD и LOAD в версиях DB2 V8, 9, 10 реализуется пакетами технического обслуживания (APAR) под номерами PK88970, PK88972 и PK88974.

Утилита LOAD — параметр PRESORTED

Используйте опцию LOAD PRESORTED в тех случаях, когда данные уже отсортированы согласно индексу кластеризации. Это позволяет избежать сортировки по индексу кластеризации. Если у вас имеется несколько индексов, то вследствие параллельного построения индексов вы не получите выигрыша с точки зрения общего затраченного времени, однако до некоторой степени снизите потребление процессорных ресурсов. Конечно, если в таблице имеется лишь один индекс, а ваши данные уже отсортированы заранее, вы сможете пропустить этап индексной сортировки, что позволит сократить затраченное время (фактическую продолжительность). С точки зрения доступности необходимо отметить следующее обстоятельство. Если опция LOAD REPLACE применяется к сегментированному табличному пространству, то в процессе ее исполнения доступ к данным отсутствует. Соответственно, если у вас есть возможность заранее обработать данные с целью их сортировки согласно порядку кластеризации, то тем самым вы сможете уменьшить продолжительность исполнения LOAD REPLACE. И действительно, простои в процессе исполнения LOAD REPLACE сокращаются, что повышает степень доступности базовой таблицы (underlying table).

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

Утилита LOAD/UNLOAD — параметр FORMAT INTERNAL

Утилиты LOAD и UNLOAD способны задействовать новый параметр FORMAT INTERNAL. Данные таблиц DB2 хранятся на диске во внутреннем проприетарном формате DB2. В процессе выгрузки этот внутренний формат преобразуется во внешний формат в наборе данных SYSREC. Во время последующего процесса загрузки это внешнее представление данных преобразуется обратно во внутренний формат DB2 в рамках страницы данных. Выполнение этого преобразования данных задействует процессорные ресурсы и время исполнения утилит LOAD и UNLOAD.

Утилита REORG уже использует процесс, который выгружает данные, а затем перезагружает эти данные в проприетарном внутреннем формате DB2. Если вы выгружаете данные из таблицы TABLEA и перезагружаете данные в таблицу TABLEB (при условии, что определения столбцов у таблиц TABLEA и TABLEB эквивалентны), то использование усовершенствования в виде нового параметра FORMAT INTERNAL для утилит UNLOAD и LOAD позволяет сэкономить значительные процессорные ресурсы и сократить продолжительность исполнения обеих вышеупомянутых утилит. Пользователь должен убедиться в том, что определения столбцов совпадают, однако у него нет необходимости волноваться о различающихся атрибутах (сжатие, трансляция идентификаторов объектов данных (OBID), размеры сегмента, формат реорганизованных строк, базовый формат строк).

В версии DB2 9 параметр FORMAT INTERNAL может оказаться полезным в тех случаях, когда необходимо изменить какой-либо атрибут табличного пространства, например, DSSIZE. Выгрузите данные из таблицы TABLEA, удалите табличное пространство для таблицы TABLEA, повторно создайте табличное пространство с новым атрибутом DSSIZE, а затем перезагрузите данные в таблицу TABLEA и в случае необходимости заново задайте индексы, разрешения, триггеры и RI-отношения. В версии DB2 10 этот процесс может быть упрощен с помощью команды ALTER, после которой следует REORG. Эта отложенная команда ALTER применяется только к табличным пространствам, описанным в DB2 10 как UTS.

В некоторых случаях мы наблюдали возможности для потенциально сокращения потребления процессорных ресурсов и уменьшения фактической продолжительности исполнения UNLOAD на величину до 85%; для утилиты LOAD процессорные ресурсы могли быть сокращены на величину до 56%, а фактическая продолжительность исполнения — на величину до 77%. Различия между показателями для утилит UNLOAD и LOAD обуславливаются количеством индексов, кроме того, эти различия несомненно зависят от базовых данных. Чем больше индексов в вашей таблице, тем меньше относительное сокращение потребления процессорных ресурсов и продолжительности исполнения утилиты LOAD, что обусловлено необходимость индексной сортировки.

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

В следующем примере показан оператор UNLOAD, использующий параметр FORMAT INTERNAL.

UNLOAD TABLESPACE DBB.TSS FORMAT INTERNAL

В следующем примере показан оператор LOAD, использующий параметр FORMAT INTERNAL.

LOAD INDDN SYSREC REPLACE
FORMAT INTERNAL
INTO TABLE "SYSADM"."TBB"

Новые опции PRESORTED и FORMAT INTERNAL для утилит UNLOAD и LOAD реализуются посредством пакета APAR PM19584 и доступны для версий DB2 9 и DB2 10.

Опции REPAIR SET — RBDP/PAGE SET RBDP — и новые усовершенствования утилиты LOAD в области поведения

При пакетных вставках большая часть процессорных ресурсов тратится на техническое обслуживание индекса. Когда исполняется оператор SQL INSERT, СУБД DB2 должна вставить ключ индекса, разделить конечные страницы и т. д. Пользователи освоили методику для быстрого выполнения пакетных вставок. Во многих случаях они удаляют индексы перед исполнением пакетного задания. Затем они исполняют задание по пакетной вставке и после этого воссоздают индексы. Это уменьшает совокупное потребление процессорных ресурсов и сокращает общую продолжительность процесса пакетной вставки.

Имеется ряд усовершенствований, способных оказать содействие в этом процессе. До появления усовершенствованных опций REPAIR SET утилита REPAIR была способна восстанавливать только ограниченные состояния. Теперь утилиту REPAIR можно использовать для задания ограниченного состояния индекса, а именно, состояния RBDP (RBDP) или PAGE SET RBDP (PSRBD). Если вы запустите утилиту REPAIR, чтобы установить состояние RBDP перед исполнением своей программы пакетной вставки, то задание пакетной вставки не будет вставлено в индекс, поскольку предполагается, что индекс не является UNIQUE. Если индекс является UNIQUE, то задание пакетной вставки потерпит неудачу. Теперь можно осуществлять вставку в набор страниц даже в том случае, когда индекс находится в состоянии RBDP. С помощью этой функции можно установить состояние RBDP, выполнить свое задание пакетной вставки, а затем исполнить утилиту REBUILD INDEX. В зависимости от конкретной ситуации исполнение утилиты REBUILD INDEX может оказаться весьма полезным, поскольку позволяет устранить этап удаления индексов и этап повторного связывания планов и пакетов, ассоциированных с данной таблицей.

С другой стороны, удаление индексов позволяет повысить производительность операции LOAD PARTITION. До того, как появилось это усовершенствование, если в логическом разделе имелся индекс в состоянии RBDP, то операция LOAD завершалась неудачей. Теперь даже при наличии в разделе индекса в состоянии RBDP операция LOAD REPLACE на уровне PART успешно работает, поскольку в любом случае будет восстановлен весь индекс. Тем не менее, если вы применяете к этому разделу операцию LOAD RESUME, то операция LOAD закончится неудачей. Аналогично, если в таблице имеются неразделенные вторичные индексы (NPSI), находящиеся в состоянии RBDP, то операция LOAD также закончится неудачей.

Вместо того чтобы удалять индексы перед операцией LOAD для повышения производительности LOAD PARTITION, рассмотрите целесообразность использования новой опции INDEXDEFER для утилиты LOAD. Этот опция откладывает построение индекса, особенно в случае операций LOAD PART. При частичном построении индекса или отсрочке части индекса, индекс оставляется в состоянии RBDP. Когда исполнение LOAD завершится, запустите операцию REBUILD INDEX. Конечно, если индекс является UNIQUE, вам может потребоваться этот индекс для принудительного достижения однозначности. Другая опция состоит в использовании ключевого слова NONUNIQUE и откладывании только тех индексов, которые не являются UNIQUE.

Усовершенствованные опции REPAIR SET реализуются посредством APAR-пакетов под номерами PM27962, PM08585, PM27962.

Утилита REORG — параметр PARALLEL YES | NO

Новое ключевое слово PARALLEL утилиты REORG позволяет указать, следует ли обрабатывать разделы параллельно с помощью опции PARTLEVEL, когда они поступают на вход утилиты REORG в списке LISTDEF. В DB2 9 можно применить операцию REORG к нескольким диапазонам разделов. Например, если вам необходимо реорганизовать разные фрагментированные разделы 3-4, 10 и 12, выполните следующий оператор.

REORG table-space-name PART (3-4,10, 12)

Разделы обрабатываются параллельно на этапах UNLOAD и LOAD.

Аналогично, если использовать LISTDEF для разделов 3-4, 10 и 12, то операция REORG будет применена к этим разделам. При наличии каких-либо неразделенных вторичных индексов (NPSI) они обрабатываются поочередно, при этом для каждого NPSI-индекса теневая копия создается три раза.

Маловероятно, что пользователи пожелали бы обрабатывать каждый NPSI-индекс поочередно. По этой причине реорганизация всех разделов осуществляется параллельно, а каждый NPSI-индекс обрабатывается лишь один раз. Это усовершенствование реализовано в пакете APAR PK87762.

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

Ключевое слово PARALLEL реализуется посредством пакета APAR PM25525. Опция PARALLEL YES обеспечивает более эффективную обработку, более высокую степень параллелизма, уменьшенное потребление процессорных ресурсов, сокращение продолжительности исполнения и повышение доступности, поскольку NPSI-индексы обрабатываются однократно. Тем не менее, при ограниченной доступности дисковых ресурсов более предпочтительной может оказаться опция PARALLEL NO. По умолчанию ключевое слово PARALLEL имеет значение YES, при котором обеспечивает наиболее эффективная обработка. С другой стороны, выбор опции PARALLEL YES после применения PTF-исправлений может вызвать проблемы, если новое поведение не является приемлемым. С целью предотвращения этих проблем был создан новый параметр ZPARM для руководства ключевым словом PARALLEL на уровне подсистемы. Это усовершенствование реализовано посредством пакета APAR PM37293. Если вас интересует параллельная обработка разделов утилитой REORG после применения пакета APAR PM25525, дополнительно примените пакет APAR PM37293.

Ключевое слово PARALLEL для REORG реализовано посредством пакета APAR PM25525 и доступно для версий DB2 9 и 10. Возможность применения REORG к разделам, состоящим из нескольких несмежных фрагментов, реализована посредством пакета APAR PK87762 и доступна для версий DB2 9 и 10. Возможность замены значения по умолчанию для ключевого слова PARALLEL на уровне подсистемы реализована посредством пакета APAR PM37293 и доступна для версий DB2 9 и 10.

Заключение

Поддержание свой информированности о новых возможностях и функциях, предоставляемых DB2 с целью проведения технического обслуживания, имеет большое значение для заказчика, особенно если эти сведения способны решить проблему, имеющуюся в его среде. В данной статье описывается множество усовершенствований пакета DB2 Utilities Suite, который и в дальнейшем будет улучшать окупаемость инвестиций заказчиков в применение 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=855045
ArticleTitle=Инструменты DB2: Усовершенствования пакета DB2 Utilities Suite for z/OS
publish-date=01152013