Главная » 2016»Июль»11 » Транзакционная обработка последовательных наборов
Транзакционная обработка последовательных наборов
22:44
Интересный и красивый момент.
В рамках миграции с DB2 на IMS DB встаёт задача перемещения немаленьких объёмов данных.
Выгружаются данные из нужных таблиц утилитой DSNTIAUL (она и описание формата выгруженных в набор данных формирует, которые можно использовать для обрабатывающих программ), на выходе PS набор данных. Каждая строка набора соотносится со строкой таблицы. Есть другая таблица, в которой хранятся LOB',ы, каждой строке нашего выгруженного набора соответсвует один LOB.
Программа пакетной обработки читает запись из входного набора, из содержимого некоторых полей формирует имя набора данных, добавляет его к записи и пишет в выходной набор данных, и попутно вызывает SQL для выгрузки соответствующего LOB в набор данных со сгенерированным именем.
Упасть пакетная программа может по множеству причин, и вероятность достаточно высокая. То VTOC или индекс VTOC закончился, то с ICF каталогом что-то, да мало ли причин. А учитывая количество данных (много, так много, что входной и выходной наборы на лентах), начинать каждый раз сначала непродуктивно, разбивать входной набор на куски - реально, но блин, это же мейнфрейм...
Пользуясь тем, что IMS subsystem под рукой, поступаем следующим образом.
Описываем входные и выходные наборы данных в IMS (как фейковую, вернее, GSAM DBD, в которой самое главное указать имя DD карты, которач будет использоваться в JCL в будущем джобе, затем создаём PSB). Можно так описать или PS или VSAM, в нашем случае PS. В обрабатывающей программе не работает непосредственно с наборами данных (не открываем и не читаем/пишем). Открывает за нас IMS. А читаем/пишем вызовами API IMS (вещь унифицированная для очередей, баз данных, и внешние наборы).
В обрабатывающей программе используем symbolic Checkpoint - вызов, который подтверждает все изменения во все источники, то есть в базы, а так же во внешнеие наборы данных, сохраняя позицию в них, а так же даёт возможность сохранить до 7 областей памяти, в которых можно хранить, что там надо для успешного рестарта после сбоя. Ну, там, счётчики циклов и прочие нужные переменные, которые меняются в цикле.
Так же используется XRST (extended restart), который, собственно, и позволяет перезапустить джобик после какого-либо сбоя обрабатывающей программы, указав конкретный checkpoint, с которого надо продолжить работу, или просто LAST если с последнего. В результате после рестарта джобика получаем восстановленные позиции во входном и выходном наборах данных, получаем восстановленные нужные переменные, и можем начинать обрабатывать входной набор - читать с него. И писать в выходной набор - запись продолжиться непосредственно после записи, на которой был вызван checkpoint.
IBM советует для таких восстановимых джобиков даже SYSOUT определять таким вот образом, чтобы и он продолжался после рестарта. Я этого делать не стал, не критично. Но можно попробовать.
Работает усешно, и в случае использования наборов на лентах. Да, вот так получается, простой набор PS, и транзакционная обработка. Может, какие косяки и всплывут в процессе эксплуатации. Посмотрим. Главное - обеспечить наличие журналов, в которых писались checkpoint. Ну это понятно, само собой.
Хороший вопрос, немного дискуссионный Можно и UNLOAD наверняка, особенно на этапе первоначального переноса данных, когда самая большая выгрузка, с целью экономии ресурсов. Но потом будет, скорее всего, этап потоянного пополнения баз IMS из постоянно пополняющихся баз DB2, будут выгрузки только свежих данных, поступивших за какой-то прошедший период, то есть выгрузка будет результатоми SQL запроса, который пока даже не сформулировался, поскольку в эксплуатации одновременно несколько версий структур дб2, немного отличающихся между собой, идёт плавное переползание старых версий на новые, что там будет в реальности на момент постоянного переноса даных между дб2 и IMS пока непонятно... И показалось, что с DSNTIAUL будет возможность гибче подстроится... Опять же, при регулярном пополнении IMS баз из дб2 базы переносится будут не такие большие порции, и full tablespace scan при UNLOAD выглядит затратнее по ресурсам, чем SQL запрос DSNTIAUL. Хотя, повторюсь, на первоначальном этапе можно и UNLOAD, на наших объёмах может быть значительная экономия по ресурсам. А спецификацию полей выгружаемых данных на UNLOAD можно взять ту же, что и для DSNTIAUL.
"full tablespace scan при UNLOAD выглядит затратнее по ресурсам, чем SQL запрос DSNTIAUL." замкчу, что DSNTIAUL - не утилита, а демонстрационный пример, равно как и DSNTEP2/4, DSNTIAD. Насколько я понимаю, UNLOAD оперирует непосредственно с табличным пространством, то есть работает существнно быстрее, и возможностей у UNLOAD значительно больше. Только одного UNLOAD ... FORMAT DELIMITED достаточно
кстати, о UNLOAD/LOAD, извиняюсь за некоторый оффтопик. Техника, описанная здесь пост #43 применима и для UNLOAD/LOAD, так что возможно выполнить выборку из таблицы/таблиц и загрузку результата в целевую таблицу без промежуточного набора данных. Функционально это эквивалент cross-load, но для cross-load требуется конфигурированное соединение DRDA, а для техники с использованием fifo-файла - нет.
Э-э, а не проще ли написать программку, которая одной ногой в DB2, а другой в IMS ... ? Объемы-то реально какие? Может и не стоят они тех чекпойнтов, пишем каждый раз заново и всё.
Я по секрету скажу, что это именно такая программка и есть. IMS через соответствующий attachment facility коннектится к дб2. Иначе никакой возможности через SQL Lob reference вытащить содержимое LOB поля в dataset. LOB'ов в перспективной архитектуре не будет как класса, вместо них документы в наборах данных. Поначалу так и было сделано - пишем каждый раз заново и всё. Но это реально не вариант - хотя бы вот 130 миллионов датасетов из LOB'ов вынуть заново - не вариант, а это всего лишь малая часть данных. Это примерно соответствует 600 ГБ входному файлу и столько же выходному. И ещё раз повторю, это где-то одна восьмая, на вскидку, ну или одна шестая всех данных. Так что овчинка стоит выделки, тем более, если не забывать, что этот ящик полон всяких других маразматических с нашей точки зрения, но более важных с пользовательской точки зрения задач. У нас прецедент был. Мелкомягкие коллеги грузили исторические данные в дб2. На вопрос не поставить ли их табличные расписания в регулярный бекап ответили гордым отказом - "перезальём, если что". Через три месяца работы, когда "всё пропало", и встала речь, что надо перезаливать, схватились за голову - три месяца работы насмарку. Так что стоит оно того, стоит. Уж лучше 1000 записей по-новой обработать (и, соответсвенно, удалить 1000 датасетов, приготовившись к их повторному распределению) чем 130 миллионов умножить пусть даже на шесть раз.
Если вопрос о том, что можно было бы читать из DB2 и сразу писать в IMS, вместо того, чтобы из db2 выгружать в PS набор, то так сделано сознательно. В IMS создано несколько структур (баз), для наиболее эффективно загрузки в каждую надо бы иметь входные данные сортированные в порядке иерархии сегментов. По сути, это пришлось бы открывать на каждую структуру IMS свой курсор в db2, с нужной сортировкой. Перерасход ресурсов, дб2 стараемся грузить как можно меньше, ибо чревато последствиями. А выгрузив в PS набор, можно сортировать как угодно и подавать на вход программе загрузки в IMS. Могу на примитивном примере нарисовать, почему так удобнее. Опять же, можно в разные структуры (базы) IMS можно грузить параллельно если на вход набор данных. В случае с чтением курсором из дб2 можно, конечно, попытаться сделать параллелизм, но явно заморочистей и перерасход ресурсов. А учитывая, что структуры IMS партиционированы (DEDB area) то можно грузить отдельно в каждую area, не мешая друг другу и не пересекаясь по блокировкам и другим ресурсам (отсортировав на входе записи для каждой area моим любимым DFSORT), в пределе количество потоков это количество баз умножить на количетсво партиций, но это перебор, надо будет подобрать экспериментально по результатам мониторинга. Я сейчас не беру общие случаи, в общем случае можно много потоков в одну area грузить, в нашем конкретном случае, при использовании своих рандомайзеров, когда есть понятие, какой ключ пойдёт в какую area, можно спокойно разводить потоки с данными по разным area устранив любые конфликты по блокировкам. Вообще IBM'у вместо чего попало в маркетинге надо бы подробнее разьяснять такие фичи, например, как рандомайзер, это же жуть как здорово! Я уже писал про рандомайзеры но про них стоит каждый раз упоминать, одно это перевесит очень многое при выборе платформы. Когда будет в более высокой степени готовности - я обязательно подробнее опишу, и роль рандомайзеров в том числе, а она, бесспорно, ключевая.
можно ещё добавить, что позиция в курсоре дб2 не сохраняется при ims checkpoint, и, стало быть, не происходит репозиционирования после рестарта. А значит придётся сортировать запрос для курсора, сохранять в save area при выполнении checkpoint значение уникального ключа записи дб2, а потом, при рестарте, получив значние уникального ключа в save area, открывать курсор начиная с этого значения ключа. Каждая лишняя сортировка в дб2 это... Куда как проще в последовательный набор выгрузить с наименьшим вовлечением таких пожирателей ресурсов, как дб2. Уж последовательный набор репозиционируется при рестарте отлично by design, без дополнительного кодирования. Убогая эта дб2, ну что с неё взять
Уф! Еле осилил, нельзя человеку, вышедшему из отпуска, читать такие вещи Вопрос был в большей степени риторический. Я не зря спросил про объемы, а 130 млн. датасетов это конечно круто и безусловно лучше помнить что уже переписал, а что нет. А насчет убогости, у меня с недавних пор сложилось мнение, что IT в целом - это великий обман человечества
Что-то от лукавого в ИТ есть, соглашусь, и чем дальше, тем больше, особенно в потребительском секторе, в автоматизации промышленности оно, скорее всего, получше будет. 130 млн датасетов это не круто, это примерно один год. Круто эту кучу запихнуть в дб2 в LOb'ы.... и иметь через это кучу проблем.
недавно разговаривал с иноземцем, они размазывали 500 млн файликов (размер от 10 кбайт до 500 мегабайт, преимущественно 1-5 мегабайт) по распределенной файловой системе, на базе около 20 реальных линуксовых серверов, 5 дисковых систем разного класса. ну понятно, балансировщики нагрузки, фронт-енд сервера для обработки ftp-запросов на вход, ДНС с раунд-робином, чтобы поставить несколько балансировщиков, инкрементальный размазанный архив и все дела. в общем, у них получилось, но проектировали и допиливали больше двух лет. подробностей иноземец сказал мало, сидят в штатах, работают на розничную сеть. вопрос мейнфрейма тоже стоял, но был зарублен по политическим и ценовым соображениям. так вот BLOB у них тож проверялся, но умер, не пройдя нагрузочное тестирование.
Всегда тоже был за возможность не использовать "LOBстеры и BLOBстеры". Фактически информация это всегда объективные цифры, частично объективный текст, а остальное рюшечки и плюшечки в виде графики и изображения суть вещь необъективная, каждый видит то что хочет видеть. По этому всю информацию в текстово-числовой формат, подвергнуть компрессу и в VARCHAR её родимую.
ИТ, как и, например, мебель или автомобили, могут быть функциональным делом, предметом имиджа или капризом. у нас в стране, например, редко ИТ обеспечивает конкурентное преимущество кому-то зачем-то. но, побывав в МФЦ, я пришел к выводу, что иногда ИТ может принести реальную пользу. Ну и не забывайте - теперь можно кино смотреть прямо в автобусе. Это и есть триумф ИТ!
Так я и не спорю об этом, а поворчать таки хочется.. Есть у меня дома отдельно стоящий пятнадцатилетний компьютер, ничего на нем не было и нет кроме файерфокса, так вот раньше на нем все летало, а теперь еле шевелится, так не обман ли это?
Ох, елки-палки, как красиво! Жалко только, что маааалееенький чертик скрывается вот в этих строках:
Цитата
"... Описываем входные и выходные наборы данных в IMS.... А читаем/пишем вызовами API IMS ..."
Жаль, что у меня нет IMS))). Если бы было побольше людей, у которых IMS таки есть, я бы предложил написать Григорию более развернутую статью. А так - отлично, хорошая возможность и хорошо использована.
