Как определить, не приведет ли моя программа COBOL, использующая DB2 CICS, к взаимоблокировкам для других транзакций?

В настоящее время я работаю над системой, которая использует COBOL для подключения к DB2. Пример просмотра будет инициирован следующим оператором:

       EXEC SQL
         DECLARE <cursor name> CURSOR FOR
         SELECT
             <field names>
         FROM <table name>
         WHERE
             <conditions>
         ORDER BY
             <key fields>
         FOR FETCH ONLY
         OPTIMIZE FOR 1 ROW
       END-EXEC.

       EXEC SQL
            OPEN <cursor name>
       END-EXEC.

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

       EXEC SQL
         FETCH <cursor name>
         INTO
             <variable names>
       END-EXEC.

Если, например, я просматриваю таблицу и возвращаемый набор результатов составляет около 100 000 строк, на обработку уйдут часы. Это было бы нормально, если бы я мог гарантировать, что другие пользователи системы не столкнутся с взаимоблокировками (-911), если они обрабатывают ту же таблицу, которую просматриваю я (обработка будет означать выбор, обновление и, возможно, удаление записей).

Как я могу определить, может ли операция просмотра, которую я выполняю, привести к взаимоблокировкам для других пользователей?

(ПРИМЕЧАНИЕ: я не делаю никаких обновлений, просто извлекаю данные)


person heisenbergman    schedule 15.10.2014    source источник
comment
Вы работаете на мейнфрейме. С какой стати вы думаете, что на это уйдут часы? Попробуйте на тестовой БД. Поговорите со своими коллегами. Спросите своего администратора баз данных. В ситуациях, когда могут возникнуть тупиковые ситуации, они будут знать, как вам следует поступать с этим, и они смогут лучше продемонстрировать, где тупиковая ситуация может отсутствовать.   -  person Bill Woodger    schedule 15.10.2014
comment
В CICS должны ли обрабатываться 100 000 строк за одну транзакцию? Я бы беспокоился о том, что это будет помечено как длительная транзакция, как только она начнет проходить через несколько секунд. В этих случаях все еще может происходить укрупнение блокировки. На первый взгляд, с UR или даже CS вы, скорее всего, станете жертвой. Если это архитектурная задача, может ли она выполняться траншами из интервального контроля? Или из партии? Есть ли логика, которую можно выполнить в запросе? Пейджинг?   -  person mckenzm    schedule 29.03.2015


Ответы (4)


Одним из инструментов, помогающих найти потенциальные проблемы взаимоблокировки, является вывод команды EXPLAIN. Поговорите со своими администраторами баз данных.

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

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

person cschneid    schedule 15.10.2014
comment
Я думаю, что спрашивающий использует просмотр в смысле CICS — как в STARTBRowse, наборе данных процесса, ENDBRowse — а не как в пользовательском просмотре. Это похоже на фоновую обработку, а не на экран. - person Joe Zitzelberger; 28.11.2014

В среде мэйнфреймов производительность — ЭТО ВСЕ! Мы можем игнорировать требования к производительности не потому, что мейнфреймы быстрые.

В программе ОНЛАЙН я рекомендую использовать

FETCH FIRST N ROWS ONLY 

где размер пользовательской страницы равен N-1. Если вы успешно извлекаете строку N в своем курсоре, есть больше страниц, и вы каким-то образом уведомляете своего пользователя.

в ваших ЗАПРОСАХ DB2;

Если вы работаете с пакетной обработкой, вам лучше ВЫГРУЗИТЬ ваши данные с помощью утилиты DB2 или DFSORT/ICETOOL/SYNCSORT, передав ваш SQL-запрос с соответствующим DD SORTDBIN.

person Anderson Marques    schedule 16.10.2014
comment
Не совсем ВСЕ, но, безусловно, более важно, чем количество данных, а прямая стоимость обработки (плата за процессор / ввод-вывод) отсутствует. Изначально я пропустил тег CICS. Если это какой-то процесс суммирования в программе CICS, то суммирование должно выполняться вне CICS, чтобы значение было удобно использовать. 100 000 обращений к БД для одной транзакции CICS — это нехорошо. Ваш первый голос. - person Bill Woodger; 16.10.2014
comment
О, и SORTDBIN — это только для SyncSORT. - person Bill Woodger; 16.10.2014
comment
Разве удаление данных из базы данных для их обработки не противоречит цели наличия базы данных? - person Joe Zitzelberger; 28.11.2014
comment
@JoeZitzelberger Ни в коем случае. Затем он возвращается обратно. Хотя язык команд БД может делать все, что нужно, иногда это невозможно сделать без неоправданного использования ресурсов (включая время). Если выгрузка/манипулирование/перезагрузка дает те же результаты, но быстрее... Это обычный способ для мейнфреймов. В любом случае, я не уверен, что вопрос так уж хорош. - person Bill Woodger; 28.11.2014

Если вы просто выполняете операцию просмотра, предложение «ТОЛЬКО ДЛЯ ВЫБОРКИ» (также известное как ТОЛЬКО ДЛЯ ЧТЕНИЯ) очень полезно. Вы также можете изучить предложение «SKIP LOCKED DATA» и уровень изоляции «WITH UR» (незафиксированное чтение), если это позволяет уровень изоляции, установленный в привязке вашего пакета.

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

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

person Joe Zitzelberger    schedule 28.11.2014

Если таблица содержит 100 000 строк, скорее всего, вы будете «фильтровать» FETCH для выбора для представления. Если возможно, включите информацию о «фильтрации» в SQL SELECT. Статистика транзакций, которую видит администратор базы данных, определит, улучшат ли выполнение транзакции дополнительные операторы INDEX BY.

person R. Whiteside    schedule 28.03.2017