Чт, 28.03.2024, 22:49
Приветствую Вас Гость | RSS
Главная | Блог | Регистрация | Вход
Форма входа
Логин:
Пароль:
Поиск

Меню сайта

Категории раздела
Техническое [29]
Все о мейнфреймах и не только о них, но все-таки крепко связанное с техникой и инженерными моментами.
Разговорчики [25]
Обо всем остальном, не относящемся к технике.

Календарь
«  Июль 2016  »
ПнВтСрЧтПтСбВс
    123
45678910
11121314151617
18192021222324
25262728293031

Архив записей

Наш опрос
О регистрации на сайте с помощью соцсетей.
Всего ответов: 24

Метки
EGL ODM бизнес правила программирование SOA arcati блоги журналы Каталог мейнфреймы журнал z/os Freeware VM bigdata nosql zOS MVS OS SLES zLinux мейнфрейм Хабрахабр 50лет документы хранилище Java EE liberty WebSphere z/VM Share history GitHub OS/VS S/379 сообщение Форум DFSORT Hercules VSAM отчётность Linux Analytics Accelerator Netezza IMS IBM IDC продажа CHKPT GSam XRST гипервизор KVM Shutdown #hollywar mainframe Вакансии Санкт-Петербург видео Выступления Dis нагрузка пример Assembler VM/ESA НИЦЭВТ Docker Sie Kubernetes OpenShift Environment RedBook RedHat рынок LHI vs XR instruction to clear GPR z Seies CPU performance семинар впечатление доступность ЦБ цены аутсорсинг BMC CMS ZVM санкции Rockwell история z13 мобильность DB2 Java Coupling Facility Parallel Sysplex WebSphere AS MVT ОС ЕС ссср Tape VTL Вакансия БЛОГ Линукс Новое статьи Люксофт Польша Работа Москва

Статистика

Главная » 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. Ну это понятно, само собой. 

Категория: Техническое | Просмотров: 2544 | Добавил: ggv | Теги: GSam, CHKPT, XRST, IMS | Рейтинг: 0.0/0 |


Всего комментариев: 19
14 Gregory  
0
а почему DSNTIAUL а не UNLOAD?

15 ggv  
0
Хороший вопрос, немного дискуссионный smile
Можно и UNLOAD наверняка, особенно на этапе первоначального переноса данных, когда самая большая выгрузка, с целью
экономии ресурсов.
Но потом будет, скорее всего, этап потоянного пополнения баз IMS из постоянно пополняющихся баз DB2, будут выгрузки только свежих данных, поступивших за какой-то прошедший период, то есть выгрузка будет результатоми SQL запроса, который пока даже не сформулировался, поскольку в эксплуатации одновременно несколько версий структур дб2, немного отличающихся между собой, идёт плавное переползание старых версий на новые, что там будет в реальности на момент постоянного переноса даных между дб2 и IMS пока непонятно... И показалось, что с DSNTIAUL будет возможность гибче подстроится... Опять же, при регулярном пополнении IMS баз из дб2 базы переносится будут не такие большие порции, и full tablespace scan при UNLOAD выглядит затратнее по ресурсам, чем SQL запрос DSNTIAUL.
Хотя, повторюсь, на первоначальном этапе можно и UNLOAD, на наших объёмах может быть значительная экономия по ресурсам. А спецификацию полей выгружаемых данных на UNLOAD можно взять ту же, что и для DSNTIAUL.

16 Gregory  
0
"full tablespace scan при UNLOAD выглядит затратнее по ресурсам, чем SQL запрос DSNTIAUL."
замкчу, что DSNTIAUL - не утилита, а демонстрационный пример, равно как и DSNTEP2/4, DSNTIAD. Насколько я понимаю, UNLOAD оперирует непосредственно с табличным пространством, то есть работает существнно быстрее, и возможностей у UNLOAD значительно больше. Только одного UNLOAD ... FORMAT DELIMITED достаточно biggrin

17 ggv  
0
Да всё так, тут спорить не о чем.
Будет время - можно будет замерить разницу на выгрузке небольшого объёма данных из большой таблицы.

18 Gregory  
0
кстати, о UNLOAD/LOAD, извиняюсь за некоторый оффтопик. Техника, описанная здесь пост #43 применима и для UNLOAD/LOAD, так что возможно выполнить выборку из таблицы/таблиц и загрузку результата в целевую таблицу без промежуточного набора данных. Функционально это эквивалент cross-load, но для cross-load требуется конфигурированное соединение DRDA, а для техники с использованием fifo-файла - нет.

19 ggv  
0
через fifo оно и работает на порядок быстрее, чем через cross-loader, если указать FORMAT INTERNAL
Правда, делали в рамках одной машины, без ftp.

2 AKonev  
Э-э, а не проще ли написать программку, которая одной ногой в DB2, а другой в IMS ... ?
Объемы-то реально какие? Может и не стоят они тех чекпойнтов, пишем каждый раз заново и всё.

4 ggv  
0
Я по секрету скажу, что это именно такая программка и есть.
IMS через соответствующий attachment facility коннектится к дб2.
Иначе никакой возможности через SQL Lob reference вытащить содержимое LOB поля в dataset. LOB'ов в перспективной архитектуре не будет как класса, вместо них документы в наборах данных.
Поначалу так и было сделано - пишем каждый раз заново и всё.
Но это реально не вариант - хотя бы вот 130 миллионов датасетов из LOB'ов вынуть заново - не вариант, а это всего лишь малая часть данных. Это примерно соответствует 600 ГБ входному файлу и столько же выходному.
И ещё раз повторю, это где-то одна восьмая, на вскидку, ну или одна шестая всех данных.
Так что овчинка стоит выделки, тем более, если не забывать, что этот ящик полон всяких других маразматических с нашей точки зрения, но более важных с пользовательской точки зрения задач.
У нас прецедент был. Мелкомягкие коллеги грузили исторические данные в дб2. На вопрос не поставить ли их табличные расписания в регулярный бекап ответили гордым отказом - "перезальём, если что". Через три месяца работы, когда "всё пропало", и встала речь, что надо перезаливать, схватились за голову - три месяца работы насмарку.
Так что стоит оно того, стоит. Уж лучше 1000 записей по-новой обработать (и, соответсвенно, удалить 1000 датасетов, приготовившись к их повторному распределению) чем 130 миллионов умножить пусть даже на шесть раз.

5 ggv  
0
Если вопрос о том, что можно было бы читать из DB2 и сразу писать в IMS, вместо того, чтобы из db2 выгружать в PS набор, то так сделано сознательно.
В IMS создано несколько структур (баз), для наиболее эффективно загрузки в каждую надо бы иметь входные данные сортированные в порядке иерархии сегментов. По сути, это пришлось бы открывать на каждую структуру IMS свой курсор в db2, с нужной сортировкой. Перерасход ресурсов, дб2 стараемся грузить как можно меньше, ибо чревато последствиями.
А выгрузив в PS набор, можно сортировать как угодно и подавать на вход программе загрузки в IMS. Могу на примитивном примере нарисовать, почему так удобнее.
Опять же,  можно в разные структуры (базы) IMS можно грузить параллельно если на вход набор данных. В случае с чтением курсором из дб2 можно, конечно, попытаться сделать параллелизм, но явно заморочистей и перерасход ресурсов.
А учитывая, что структуры IMS партиционированы (DEDB area) то можно грузить отдельно в каждую area, не мешая друг другу и не пересекаясь по блокировкам и другим ресурсам (отсортировав на входе записи для каждой area моим любимым DFSORT), в пределе количество потоков это количество баз умножить на количетсво партиций, но это перебор, надо будет подобрать экспериментально по результатам мониторинга.
Я сейчас не беру общие случаи, в общем случае можно много потоков в одну area грузить, в нашем конкретном случае, при использовании своих рандомайзеров, когда есть понятие, какой ключ пойдёт в какую area, можно спокойно разводить потоки  с данными по разным area устранив любые конфликты по блокировкам.
Вообще IBM'у вместо чего попало в маркетинге надо бы подробнее разьяснять такие фичи, например, как рандомайзер, это же жуть как здорово! Я уже писал про рандомайзеры но про них стоит каждый раз упоминать, одно это перевесит очень многое при выборе платформы. Когда будет в более высокой степени готовности - я обязательно подробнее опишу, и роль рандомайзеров в том числе, а она, бесспорно, ключевая.

6 ggv  
0
можно ещё добавить, что позиция в курсоре дб2 не сохраняется при ims checkpoint, и, стало быть, не происходит репозиционирования после рестарта.
А значит придётся сортировать запрос для курсора, сохранять в save area при выполнении checkpoint значение уникального ключа записи дб2, а потом, при рестарте, получив значние уникального ключа в save area, открывать курсор начиная с этого значения ключа.
Каждая лишняя сортировка в дб2 это... 
Куда как проще в последовательный набор выгрузить с наименьшим вовлечением таких пожирателей ресурсов, как дб2. Уж последовательный набор репозиционируется при рестарте отлично by design, без дополнительного кодирования.
Убогая эта дб2, ну что с неё взять smile

7 AKonev  
Уф! Еле осилил, нельзя человеку, вышедшему из отпуска, читать такие вещи biggrin biggrin
Вопрос был в большей степени риторический. Я не зря спросил про объемы, а 130 млн. датасетов это конечно круто и безусловно лучше помнить что уже переписал, а что нет. А насчет убогости, у меня с недавних пор сложилось мнение, что IT в целом - это великий обман человечества cry

8 ggv  
0
Что-то от лукавого в ИТ есть, соглашусь, и чем дальше, тем больше, особенно в потребительском секторе, в автоматизации промышленности оно, скорее всего, получше будет.
130 млн датасетов это не круто, это примерно один год.
Круто эту кучу запихнуть в дб2 в LOb'ы.... и иметь через это кучу проблем.

9 akost  
0
недавно разговаривал с иноземцем, они размазывали 500 млн файликов (размер от 10 кбайт до 500 мегабайт, преимущественно 1-5 мегабайт) по распределенной файловой системе, на базе около 20 реальных линуксовых серверов, 5 дисковых систем разного класса. ну понятно, балансировщики нагрузки, фронт-енд сервера для обработки ftp-запросов на вход, ДНС с раунд-робином, чтобы поставить несколько балансировщиков, инкрементальный размазанный архив и все дела.
в общем, у них получилось, но проектировали и допиливали больше двух лет. подробностей иноземец сказал мало, сидят в штатах, работают на розничную сеть. вопрос мейнфрейма тоже стоял, но был зарублен по политическим и ценовым соображениям.
так вот BLOB у них тож проверялся, но умер, не пройдя нагрузочное тестирование.

11 AKonev  
Всегда тоже был за возможность не использовать "LOBстеры и BLOBстеры".
Фактически информация это всегда объективные цифры, частично объективный текст, а остальное рюшечки и плюшечки в виде графики и изображения суть вещь необъективная, каждый видит то что хочет видеть.
По этому всю информацию в текстово-числовой формат, подвергнуть компрессу и в VARCHAR её родимую.

13 ggv  
0
Так еще надо исходить из того, кто и как будет пользоваться сжатыми данными из этого varchar поля. Я вот для нашего проекта никакой пользы не вижу.

10 akost  
0
ИТ, как и, например, мебель или автомобили, могут быть функциональным делом, предметом имиджа или капризом. у нас в стране, например, редко ИТ обеспечивает конкурентное преимущество кому-то зачем-то. но, побывав в МФЦ, я пришел к выводу, что иногда ИТ может принести реальную пользу.
Ну и не забывайте - теперь можно кино смотреть прямо в автобусе. Это и есть триумф ИТ!

12 AKonev  
Так я и не спорю об этом, а поворчать таки хочется..
Есть у меня дома отдельно стоящий пятнадцатилетний компьютер, ничего на нем не было и нет кроме файерфокса, так вот раньше на нем все летало, а теперь еле шевелится, так не обман ли это? biggrin

1 akost  
0
Ох, елки-палки, как красиво! Жалко только, что маааалееенький чертик скрывается вот в этих строках:
Цитата
"... Описываем входные и выходные наборы данных в IMS....  А читаем/пишем вызовами API IMS ..."
Жаль, что у меня нет IMS))).
Если бы было побольше людей, у которых IMS таки есть, я бы предложил написать Григорию более развернутую статью. А так - отлично, хорошая возможность и хорошо использована.

3 ggv  
0
Да, фишка в том, что нужны журналы IMS и само собой, сервис по ведению-чтению журналов от IMS. Больше там, собственно, ничего не задействовано от IMS

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]


Яндекс.Метрика