Переход на Online DB2 для z/OS

Перенос DB2 для z/OS при активно работающих бизнес-приложениях

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

Джей Йотерс, старший технический сотрудник, IBM

Фото автораДжей Йотерс (Jay Yothers) ― архитектор DB2 для z/OS. Он участвует в разработке СУБД DB2 с самого первого выпуска DB2, и им спроектированы и разработаны многие важные функции DB2 для z/OS. У него более 20 патентов, связанных с работой над DB2 для z/OS. Он часто выступает на таких конференциях, как IDUG и IOD, семинарах, сеансах Web-трансляции, встречах с пользователями и брифингах, где делится своими знаниями и опытом.



29.07.2013

Введение

Заказчикам все чаще приходится держать свои приложения в онлайне с возможностью круглосуточного доступа. К счастью, существует специально разработанный процесс переноса DB2, позволяющий в процессе перехода продолжать работать с набором бизнес-приложений. Эта статья содержит советы и рекомендации, которые помогут сделать такой переход в онлайн безболезненным. Хотя общие моменты этой статьи применимы к переносу любой версии, начиная с V8, она специально посвящена переносу версии V10.

Прежде чем говорить о переносе в онлайн, надо отметить, что лучший способ избежать конфликтов с набором бизнес-приложений ― решение задач по переносу в то время, когда набор приложений не работает. Другими словами, если вы можете позволить себе сделать перерыв в работе приложений, рекомендуется использовать его для решения задач переноса, чтобы в это время больше ничего не работало. Для группы обмена данными такой перерыв означает полное отключение доступа ко всем данным. Работа одного члена в ACCESS(MAINT), когда другие решают свои обычные задачи, означает отсутствие всякого перерыва, а это значит, что перенос на самом деле совершается в процессе работы.

Кроме того, хотя когда говорят о переносе, все пользуются термином CATMAINT, я не буду этого делать. Сегодня утилита CATMAINT используется столь широко, что когда мне говорят о запуске CATMAINT, я вынужден спросить, о чем именно идет речь. Поэтому во избежание путаницы я здесь использую имена задач переноса. DSNTIJTC ― это первая задача, которая выполняется с новой версией при входе в режим Conversion Mode (СМ). DSNTIJEN ― это задача, которая выполняется для включения новой функции. В нее входит процесс ENFM.


Перенос в онлайн

В задачах переноса DSNTIJTC и DSNTIJEN используются обычный DDL и оперативная обработка REORG. Эти задачи рассчитаны на работу при активной нагрузке со стороны обычных бизнес-приложений в рабочее время. Предположительно это время пониженной активности, например, раннее воскресное утро. Когда обмена данными нет, необходимо остановить V8 или V9 и запустить V10 для выполнения DSNTIJTC. Однако при наличии обмена данными этого делать нельзя. Кто-то может (пере)запустить задачу в V10, где работает DSNTIJTC, тогда как остальная часть группы весь день работает с обычными бизнес-приложениями на системах нижнего уровня. С другой стороны, DSNTIJEN может работать как в отсутствие обмена данными, так и при его наличии, когда работает остальная часть системы. Под обычной рабочей нагрузкой я понимаю набор бизнес-приложений. Я не говорю о запущенных утилитах, DDL, GRANT или REVOKE, или же о планах или пакетах связывания: всего этого в процессе переноса следует избегать. На самом деле, во время процесса переноса следует избегать любой деятельности администраторов БД.

В обычной работающей системе DB2 большая часть того, что требуется для исполнения бизнес-приложений, кэшируется в памяти. Пул EDM — это кэш для статического SQL и кэш для динамических инструкций dynamic SQL. Для SQL-операций, которые не кэшируются, разрешен доступ к каталогам только для чтения ― с целью подготовки к выполнению статических и динамических SQL-операций. Этот доступ к каталогам быстротечен. Она прекращается до того, как приложение получит контроль для выполнения SQL. Во время переноса запущенный код DDL выполняется быстро, а операции REORG ― это SHRLEVEL REFERENCE. Заметного взаимного вмешательства между набором бизнес-приложений и процессом переноса быть не должно.


Как избежать ошибки -904 с кодом 00C900A6

При первом запуске версии V10 она отклоняет все запросы с сообщением "ресурс недоступен" SQLCODE -904 и кодом причины 00C900A6. Это означает, что задание DSNTIJTC еще не выполнено. Чтобы избежать этого, необходимо временно исключить тот член, на котором вы намерены запустить V10, из любого балансировщика нагрузки или схемы маршрутизации sysplex до тех пор, пока не произойдет успешный запуск задания DSNTIJTC. Это позволит предотвратить маршрутизацию приложения к члену V10 до его готовности нормально обрабатывать запросы. Следует также избегать запуска DDF на члене V10 до успешного завершения DSNTIJTC. Когда задание DSNTIJTC успешно выполнено, можно восстановить нормальное поведение балансировщика рабочей нагрузки или схемы маршрутизации sysplex и, если нужно, запустить DDF. Отметим, что если задание DSNTIJEN запускается для управления процессом ENFM, то изменять поведение балансировщика нагрузки или схемы маршрутизации sysplex и избегать DDF не обязательно.

Другой способ избежать необходимости выполнения рабочей нагрузки на V10 до завершения DSNTIJTC — запустить V10 в первый раз в режиме ACCESS(MAINT). Это не помешает другими членам, которые работают как обычно, продолжая обрабатывать нормальную бизнес-нагрузку для данного времени суток. После успешного завершения DSNTIJTC в режиме ACCESS(MAINT) этот член DB2 можно остановить и перезапустить в обычном режиме. Упомянув об ACCESS(MAINT), я вынужден повторить, что работа DSNTIJEN на члене обмена данными, запустившем ACCESS(MAINT), дает очень малый эффект. Так как существует одна копия каталогов, деятельность других членов будет оказывать такое же сильное влияние на процесс ENFM, и наоборот, как если бы они работали с той же DB2, что и DSNTIJEN. Запуск ENFM на члене, запущенном в режиме ACCESS(MAINT), на самом деле не что иное, как динамическая миграция, если другие члены группы обмена данными в это время работают под нагрузкой.


Наборы данных, управляемые SMS

V10 требует, чтобы все новые наборы данных для табличных пространств или индексов каталогов управлялись SMS. DB2 предполагает наличие службы ACS, которая назначает эти новые наборы данных классу устройств хранения с атрибутами Extended Function (EF) и Extended Addressability (EA). Обратите внимание, что в этот класс устройств хранения помещаются только новые наборы данных. Наборы данных из существующих табличных пространств и индексов каталогов, не затронутые процессом миграции, остаются там, где они были. Если нужно запустить REORG по отношению любому из этих табличных пространств в любом режиме V10, выходные наборы данных также будут помещены в устройства хранения класса SMS. Я рекомендую начинать определение размера этого класса с размера, который в настоящее время занимают каталоги. При необходимости этот размер можно будет отрегулировать уже в NFM.


А как насчет сбоев?

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

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

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

Те, кто хочет выявить потенциальные конфликты до запуска DSNTIJTC или DSNTIJEN, могут в рамках подготовки к переносу запустить обычный SHRLEVEL REFERENCE REORG по отношению к табличным пространствам каталогов, вызывающих сомнения, таких как SYSDBASE. Если утилита REORG не может прорваться к нормальной деятельности, то и задачи по переносу будут не в состоянии это сделать. В режиме ожидания REORG вы сможете определить процесс, который обращается к табличному пространству каталога и удерживает его, не беспокоясь о работе самой задачи по переносу. Кроме того, выполнение REORG по отношению к табличному пространству каталогов дает дополнительное преимущество, организуя данные таким образом, что по отношению к тем табличным пространствам, которые являются частью процесса ENFM, REORG сможет выполняться быстрее.

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

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


Остановка в середине ENFM

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


Соображения относительно CGTT

Несколько клиентов указывают на автоматическую перепривязку (rebinding) во время выполнения задачи DSNTIJEN. Должно быть, она вызвана статическими ссылками SQL на что-то в каталоге, что не должно быть запущено в рамках набора бизнес-приложений. Мы сузили эти действия до ссылок на созданные глобальные временные таблицы (Created Global Temporary Tables - CGTTs). CGTT имеет постоянное определение и, следовательно, строку в SYSTABLES. RI, связанная с SYSTABLES, требует наличия допустимого имени табличного пространства в столбце TSNAME, но так как у CGTT нет постоянного табличного пространства, нам пришлось выбирать такое табличное пространство, которое существует всегда. В предыдущих версиях мы выбирали SYSPKAGE. Но в V10 ввиду отсутствия ENFM в процессе SYSPKAGE мы выбрали SYSTSTAB.

Пока все в порядке. Однако мы также обнаружили, что в ссылках на CGTTs мы ошибочно записали зависимость от SYSPKAGE из-за содержимого столбца SYSTABLES TSNAME CGTT. Поэтому, когда DSNTIJEN исключает SYSPKAGE, все ссылки на CGTTs становятся недействительными, что при последующем использовании этих ссылок на CGTT вызывает перепривязку. В PM81189 это исправлено, так что мы больше не фиксируем зависимости табличных пространств от ссылок CGTT. Однако зависимости CGTT, зафиксированные до применения PM81189, остаются и по-прежнему вызывают автоматическую перепривязку в ходе процесса ENFM. Поэтому PM81189 содержит также изменение в задаче подготовки к переносу DSNTIJPM (DSNTIJPA) с добавлением отчета, в котором отражены зависимости SYSPKAGE. Эти пакеты можно перепривязать до запуска DSNTIJEN во избежание автоматической перепривязки при удалении SYSPKAGE.


Практические рекомендации

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


Заключение

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

Ресурсы

Научиться

Получить продукты и технологии

  • Оцените продукты IBM наиболее удобным для себя способом: загрузите пробную версию программного продукта или попробуйте поработать с ним в Интернете/облачной среде.

Комментарии

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=939028
ArticleTitle=Переход на Online DB2 для z/OS
publish-date=07292013