Блокировка источника данных iSeries

Question

На моем AS400 (iSeries) настроен источник данных, и когда Cognos обращается к нему через драйвер ODBC клиентского доступа, он блокирует файлы на AS400. Даже если отчет закрывается, файлы остаются заблокированными в течение некоторого времени. Это вызывает проблемы с обновлением источника данных, реорганизацией файлов, очисткой записей и т. Д. Должен быть способ заставить драйвер ODBC снять блокировку при получении данных... или, по крайней мере, контролировать время, которое это держит его. Любое направление будет с благодарностью.

Благодарю.

Cognos 10.1.0.... iSeries V7R1M0

Бак, спасибо, что нашли время комментировать.... однако, я уверяю вас, на самом деле мой iSeries работает под управлением V7R1M0, и я никогда не говорил, что у меня была блокировка записи. Я сказал, что файл остается заблокированным. Я почти уверен, что мой вопрос действительно представляет собой особый сценарий, в котором Cognos обращается к файлам AS400 через драйвер ODBC клиентского доступа и блокирует файл. Затем удерживает блокировку в течение определенного времени. У меня был вопрос, есть ли способ помешать Cognos сохранить эту блокировку для файла. Я могу предоставить сообщения об ошибках для случайного доступа к файлу в iSeries после того, как эта блокировка произошла, но, поскольку я искал способ снять блокировку до того, как произошли эти ошибки, я не увидел ее актуальности... но я уверен, что Я получил бы ошибку CPF3203, говорящую мне, что он не может выделить объект.

Answer 1

IBM i 7.1 не работает на оборудовании AS/400 или iSeries. Это не семантическая гнида: поиск в сети ODBC и AS400 вернет древние и бесполезные результаты.

Вопрос не включает в себя конкретное сообщение об ошибке или конкретный сценарий, где эта ошибка возникает. Я предполагаю, что вы видите объектную блокировку (не блокировку записи) на CLRPFM, Если это так, основная причина в том, что менеджер баз данных не полностью закрывает курсоры; он мягко закрывает их (иногда называемые псевдо-закрытием) по соображениям производительности.

Если у вас есть не-SQL-процесс, который нуждается в эксклюзивной блокировке таблицы (например, SAVOBJ, CLRPFM, DLTF, RGZPFMи т. д.), то вы можете включить ALCOBJ команда с параметрами, установленными для принудительного закрытия любых псевдо-закрытых курсоров. ALCOBJ OBJ((SOMSCHEMA/SOMETABLE *FILE *EXCL)) WAIT(1) CONFLICT(*RQSRLS)

Если я угадал, пожалуйста, отредактируйте вопрос, чтобы показать действие, предпринимаемое на стороне IBM i, которая выдает ошибку, и точный идентификатор сообщения об ошибке.

РЕДАКТИРОВАТЬ: лучше объяснить блокировки

Любой доступ ODBC, любой доступ на уровне записи RPG, любой процесс, открывающий таблицу для ввода, приводит к блокировке таблицы. Если запрос ввода-вывода предназначен только для чтения, уровень блокировки равен *SHRRD (общий для чтения). Если запрос ввода-вывода включал обновление, уровень блокировки *SHRUPD (общий для обновления). Это нормальное и желаемое поведение, которое нельзя отключить, потому что оно происходит глубоко в операционной системе и находится в ДНК IBM i.

Эти блокировки объектов обеспечивают общий доступ; если ваш процесс Cognos имеет блокировку * SHRUPD для таблицы, тогда моя RPG-программа может одновременно открывать, читать, записывать и обновлять записи в одной и той же таблице. Так работают все современные базы данных.

Как правило, когда возникают подобные вопросы, возникает серверный процесс, который требует эксклюзивной (*EXCL) блокировки таблицы. Типичными операциями на стороне сервера являются CLRPFM, RGZPFM, SAVOBJ. Если Cognos открывает таблицу с помощью блокировки *SHRUPD (WRKOBJLCK сообщит вам об этом), то процесс на стороне сервера, такой как CLRPFM, не сможет получить блокировку * EXCL и выдаст CPF3203 - Невозможно выделить объект для файла.

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

• ODBC соединение
• Открыть курсор
• получить набор результатов
• закрыть курсор
• ODBC отключить

Со стороны DB2 можно ожидать, что при выполнении шага "закрытие курсора" блокировка * SHRUPD снимается. Это не обязательно происходит, потому что DB2 выполняет псевдо-закрытие, оставляя курсор в памяти на следующий раз, когда Cognos делает тот же самый доступ (за исключением, скажем, другого клиента). Для большинства операций это не проблема - кому нужна блокировка * EXCL для таблицы в тот день, когда Cognos может запросить доступ в любой момент? Но наше наследие не так просто, и у большинства из нас все еще есть процессы на стороне сервера, которые выполняют быструю CLRPFM для очистки пакета из рабочего стола. И вот где происходит CPF3203.

Поскольку менеджер баз данных удерживает блокировку (а не процесс Cognos, который отключился!), Мы должны сказать DB2, что мы хотим выполнить жесткое закрытие, прежде чем делать CLRPFM. ALCOBJ CONFLICT(*RQSRLS) - это то, как мы это делаем. Это необходимо добавить в программу CL, выполняющую CLRPFM. Другой способ обойти это - использовать SQL для очистки таблицы. На 7.1 мы можем выдавать команды SQL в программе на CL, поэтому вместо CLRPFM TEMPFILE мы можем выполнить RUNSQL "удалить из временного файла" - будучи SQL, он не требует блокировки * EXCL для таблицы.

РЕДАКТИРОВАТЬ: RGZPFM

Некоторый фон по RGZPFM, вероятно, в порядке. Очень старые приложения не удаляли записи в таблицах: они устанавливали байт "удаленной записи", который приложение должно было проверить. Со временем в таблицах накапливалось все больше записей, помеченных как удаленные или неактивные. Диск был дорогим, эти записи были лишними, поэтому реорг родился. Обычно это был двухэтапный процесс: скопировать файл во временную копию, а затем скопировать обратно, пропуская "удаляет". Это работало хорошо, потому что перезапуски обычно выполнялись ночью как часть обработки в конце дня, когда интерактивные пользователи были вне системы. Дополнительным преимуществом было размещение записей физически в порядке первичного ключа; это увеличило производительность при чтении программ по ключу.

Более современные приложения могли выполнять фактическую физическую операцию DELETE для строки, но эта строка все еще занимала место. Диск все еще был дорогим, и так родился RGZPFM. RGZPFM по-прежнему нуждался в исключительном доступе к таблице по тем же причинам, что и двухступенчатый CPYF. Многие из этих процессов RGZPFM были просто унаследованы без учета необходимости фактической реорганизации на более новом (более быстром) оборудовании с гораздо большим количеством диска. Некоторые приложения выполняют реорг, потому что "мы всегда так делали".

Это 2014 год, и аппаратное обеспечение действительно быстрое, а диск довольно дешевый. Таблицы могут быть созданы для повторного использования удаленных записей - это по умолчанию для таблиц, созданных с CREATE TABLEи, за очень немногими исключениями, работает без проблем с производительностью - и производительность была основной причиной RGZPFM. Еще есть место для RGZPFM, и это для использования с большими таблицами со многими удаленными записями - разреженной таблицей. Если у вас есть SQL SELECT, который приводит к полному сканированию таблицы, это будет снижение производительности. Вообще говоря, таких таблиц немного; Если у вас есть многомиллионная таблица строк, это, вероятно, файл истории, и он не видит много действий DELETE. Но об этом стоит подумать в тех немногих ситуациях, когда разреженная таблица имеет миллионы строк и не имеет индекса goot.