Какие они все таки скоты безмозглые...

[zVlad]

Только что позвонили по поводу работы в NY описанной в моем заглавном сообщении. Чувак спрашивает "интересно ли тебе Владимир поработать...". Отвечаю, я на full time position у меня есть работа для этого, разве что в дополнительные часы. Нет, говорит, мы хотели бы чтобы это делалось в нормальные часы. Спасибо, не надо, досвидания.

[zVlad]

....
Вообще-то этот самый "замок" он же в девичестве lock всю жизнь до этого откликался на имя "блокировка". Но видимо на МФ как всегда все не как у людей. Ваши познания в алгоритмах работы коннекшн пулов тоже весьма впечатляют. Зачем и на что коннекция в пуле при инициализации вешает блокировку? Неиспользуемые коннекции в пуле обычно закрываются после определённого таймаута за ненадобностью и/или переодически закрываются и открываются заново чтобы сервер внезапно по своей инициативе не закрыл соединение по истечению своего таймаута на коннекцию с клиентом - в принципе есть разные стратегии и настройки коннекшн пулов для разных сценариев работы. Вообще-то при возвращении в пул на коннекции сам пул на всякий случай должен сделать роллбэк, а то мало ли что там клиент наворотил. Выдаст потом пул повторно такую коннекцию кому-нибудь ещё и при первом же коммите - привет, приехали.

Не надо меня даже пытаться учить терминологии и переводу с английского. Также, пожалуйста, избегайте оценивать и комментировать те мои знания и способности про которые Вы решительно ничего не знаете. Если попытаетесь продолжать уйдете в далекий, глубокий игнор. OK? Строго говоря Вы уже наговорили на бан, но я Вас прощаю на первый раз, хотя он скорее всего не первый уже, но я не злопамятный.

Вы видите эту проблему с точки зрения программиста, который рассуждает о том как бы он написал свой вариант, или как это еще можно было написать, переп[исать ии т.д.. А я вижу с точки зрения DBA, имея то что написано и используется в реальной конфигурации. Я ту программу не писал и менять не собираюсь, я говорю с программистами, которые тоже это не писали, им это дали готовым с заверениями что все там как надо сделано. Но мне видно что не как надо.

ДБ2 же эту проблему диагностирует вот так (в нашей конфигурации используется INACTIVE - подчеркнуто ниже):

00D3003B
Explanation
A distributed thread was canceled because one of the following values was exceeded:
The idle thread timeout value that is specified by DB2® subsystem parameter IDTHTOIN in macro DSN6FAC
The ATTRIBUTE2 value in a row with KEYWORD value MONITOR IDLE THREADS in the SYSIBM.DSN_PROFILE_ATTRIBUTES table, for a profile that monitors the thread
System action
The execution unit abends.

Operator response
Notify the system programmer.

System programmer response
The server thread was holding DB2 resources and the requester application did not make a request to the DB2 server thread for an extended period of time. The server thread is terminated to release resources that might affect other threads.

This usually occurs for one of these reasons:

The ACTIVE thread option was specified in the CMTSTAT subsystem parameter, which corresponds to the DDF THREADS field of the DSNTIPR installation panel. A requester application or its user did not make a request to the DB2 server for an extended period. This can happen due to a lengthy user absence. As a result, the server thread was canceled when the timeout value was exceeded.
Determine why the requester application has not made a request to the DB2 server in the specified time.

The INACTIVE option was specified for subsystem parameter CMTSTAT. One of the following situations occurred:
A requester application or its user failed to issue a commit operation before an extended dormant period, such as a user absence.
A requester application or its user issued a commit operation before an extended dormant period, but database resources were still being held because of other conditions.
As a result, the server thread could not be moved to the inactive state, and was canceled when the timeout value was exceeded.

Determine why the server thread was not moved to the inactive state.

If the design or use of the application requires additional time, take one of the following actions:

Increase the value of the IDTHTOIN subsystem parameter, or set it to zero to deactivate idle thread timeout.
If the server thread is monitored by profile tables, and the SYSIBM.DSN_PROFILE_ATTRIBUTES profile table contains a row with KEYWORD value MONITOR IDLE THREADS for a profile that monitors the server thread, increase the ATTRIBUTE2 value in the row, or set ATTRIBUTE2 to zero to deactivate monitoring.

[geek7]

Примерно так и есть. Коннекшен пул для вебсервисов после активации оставляет замок (написан, видимо, был под SQL Server в расчете на autocommit), ну и так далее... Ваши программы А и Б непричем потому что, еще раз, autocommit-a в DB2 for z/OS нет.
Autocommit in DB2, найденный Вами, это не про МФ, это про другие платформы.

пытался понять смысл фразы "Коннекшен пул для вебсервисов после активации" что такое "замок" в этом контексте тоже неясно ... но я до него недобрался раздумывая что такое активация "Коннекшен пул".
Ок. нашлась СУБД которая на одной платформе не имеет autocommit, а на другой имеет смелое решение (монополиста ). и программа корректно работавшая на одной платформе (скажем в девелопменте\тесте) загнулась\положила сервер на другой (скажем продакшен). а виновны в этом все остальные производители СУБД которые оный autocommit не обломились сделать ...
а почему виновны не админы которые не сконфигурили тест таким же образом как продакшен?

Никто никого не загнул и не положил. Замок этотперевод слова lock. Если Вы и lock не понимаете то о чем с Вами говорить?

если lock не понимал бы то можно было поговорить о транзакциях вообще и optimistic locking vs pessimistic locking в частности, но lock я понимаю, просто впервые сталкиваюсь с переводом "Замок" а не "блокировка".
на всякий - вышеперечисленные у Вас переводятся как скажем оптимистичный замок?
а как isolation level, Dirty Reads, Non-repeatable Reads и Phantom Reads?

Активация/инициализация происходит когда устанавливается коннекция. Потом созданная коннекция ждет работы, вызова версервиса.

что то я прямо тут споткнулся... обычно ээээээээ "устанавливается коннекция" не одна а сколько сконфигурено (скажем 10 начальных, рост до 20) и делается это как правило в момент создания пула - либо старт контейнера если пул имплементирован в нём (например JEE сервера типа вебсферы), либо загрузки приложения (например спринг)... может конечно и в момент первого обращения .. но это как-то defeat the purpose слегка.

Если работы нет и каннекция не активна, плюс ею создан lock,

простите, с какого хрена ею создан lock? чтобы протестировать ээээ "коннекцию" преред выдачей приложению обычно делают "SELECT 1" или если такой не поддерживается то из какой-нибудь системной (например "SELECT 1 FROM DUAL" для Oracle ) если такой нет то "SELECT 1 FROM any_existing_table WHERE 1=0" чтобы умудрится поиметь lock нужно isolation level выставить в "SERIALIZABLE" и сделать "SELECT ... FOR UPDATE" ... но тогда пул больше 1-й "коннекции" никогда не отдаст.
Короче как можно поиметь lock "Если работы нет и каннекция не активна" я не понимаю... на чём lock то?

то через некоторое время такая коннекция удаляется.

я тут даже не знаю что можно предположить... "Если работы нет" - значит не про connection pool shrinking... единственная другая причина удалить это если у"коннекции" её network connection загнулся (в частности для отслеживанияя чего вышеупомянутые SELECT и делаются)...
В любом случае у Вас то какая проблема от этого? не "мёртвый" же "замок" получается ?

Короче бардак полный. В головах естественно бардак. Я программистам чьи программы работают с моей ДБ2 все объяснил, но им как об стенку горох. Я так думаю они используют какие-то заготовки лезть в которые не хотят или не могут, и все.

я не занаю что и как Вы обяснили программистам, но лично я так и не понял в чём тут проблема с точки зрения DBA

Пожалуйста, ограничьтесь этим моим объяснением и продолжайте поддевать меня и приводить свои домыслы. Такие проблемы решаются в конкретной обстаноке конкретно, а не для болтовни. Спасибо.

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

[zVlad]

.... просто впервые сталкиваюсь с переводом "Замок" а не "блокировка".
на всякий - вышеперечисленные у Вас переводятся как скажем оптимистичный замок?
а как isolation level, Dirty Reads, Non-repeatable Reads и Phantom Reads?

....

Я больше трех лет в офисе с одним парнем общаюсь, он все слова английские переводит буквално, например, metting - собрание, ticket - билет, и т.д.. Видимо и меня это как то задело. Конечно изначально это, как процесс, называлось блокировка, но блок в отношении конкретного события блокирования как-то, на мой взгляд всегда, звужало не очень, ну и lock это все таки "замок" как не крути.

Нет в DB2 такого понятия "оптимистичный замок", i "оптимистичной блокировки" тоже. В DB2 есть поддержка конкурентного доступа к данным в базе. Реализуется это через использование различного вида "замков". Совместимость этих замков и их диапазон влияния определяется в том числе Isolation Level, которые: Repeatable Read (RR), Read Stability (RS), Cursor Stability (CS), Uncommited Read (UR).

я не понял, Вы что хотите с моей помощью изучить DB2 for z/OS?

[zVlad]

....

...Активация/инициализация происходит когда устанавливается коннекция. Потом созданная коннекция ждет работы, вызова версервиса.

что то я прямо тут споткнулся... обычно ээээээээ "устанавливается коннекция" не одна а сколько сконфигурено (скажем 10 начальных, рост до 20) и делается это как правило в момент создания пула - либо старт контейнера если пул имплементирован в нём (например JEE сервера типа вебсферы), либо загрузки приложения (например спринг)... может конечно и в момент первого обращения .. но это как-то defeat the purpose слегка.

...

Хорошо пусть будет "устанавливается", или хотите "создается". Но дело в том что те коннекции что вижу они, до того как уйти в ожидание, выполняют несколько операций в БД. Поэтому я и назвал это как активация, или инициализация. Что уже случилось и за этим конекция стала неактивной. Что переходу в неактивное состояние могло произойти? Может активация? Почему нет?

[zVlad]

.....
простите, с какого хрена ею создан lock? чтобы протестировать ээээ "коннекцию" преред выдачей приложению обычно делают "SELECT 1" или если такой не поддерживается то из какой-нибудь системной (например "SELECT 1 FROM DUAL" для Oracle ) если такой нет то "SELECT 1 FROM any_existing_table WHERE 1=0" чтобы умудрится поиметь lock нужно isolation level выставить в "SERIALIZABLE" и сделать "SELECT ... FOR UPDATE" ... но тогда пул больше 1-й "коннекции" никогда не отдаст.
Короче как можно поиметь lock "Если работы нет и каннекция не активна" я не понимаю... на чём lock то?

...

Все верно именно некоторые действия выполнялись и вот от них то и остались locks. Последний выполненный стэйтмент я вижу. Это: SELECT current timestamp FROM sysibm.sysdummy1. И остались 5 locks, и один claim:

Code: Select all

Type    Level        Resource                             Number
----    -----        ------------------------------------ ------
PSET       IS        DB=DSNDB06  PS=SYSEBCDC                   1
           IS        DB=DSNDB01  PS=SPT01                      1
TABL       IS        DB=DSNDB06  PS=SYSEBCDC                   1
           IS        DB=DSNDB01  PS=SPT01                      1
SKPT        S        N/A                                       1
                                                          ------
                                                  Total =      5
                   Claim Information
Type       Class     Resource
-------    -----     -------------------------------------------
TS         CS        DB=DSNDB06        PS=SYSEBCDC

Это shared, and intentional shared locks, они совместимы со многим если не со всем. Но это locks и по теории что я привел выше такой конекции наступает смерть через опеределенное время. Оптимизма, как видите, точно нет. Пессимизма, кстати, тоже нет, есть оператор commit и им надо пользоваться вовремя и правильно, не полагаясь ни на autocommit, ни на оптимизм.

Я догадываюсь что программа писалась не для DB2 for z/OS. Но тем програмистам/аналистам уже наши програмисты, с моей подачи, проблему описали. В ответ тишина, ступор. Трагического ничего не происходит: конекшн пул выхеривается каждые 5 минут и создается снова со стороны WebSphere. Ta WebSphere, кстати, не ма МФ. Вот если бы это было на Мф то я бы провентилировал вопрос в WebSphere, может там что-то надо подкрутить.

[zVlad]

....то через некоторое время такая коннекция удаляется.

я тут даже не знаю что можно предположить... "Если работы нет" - значит не про connection pool shrinking... единственная другая причина удалить это если у"коннекции" её network connection загнулся (в частности для отслеживанияя чего вышеупомянутые SELECT и делаются)...
В любом случае у Вас то какая проблема от этого? не "мёртвый" же "замок" получается ?

Короче бардак полный. В головах естественно бардак. Я программистам чьи программы работают с моей ДБ2 все объяснил, но им как об стенку горох. Я так думаю они используют какие-то заготовки лезть в которые не хотят или не могут, и все.

я не занаю что и как Вы обяснили программистам, но лично я так и не понял в чём тут проблема с точки зрения DBA

Пожалуйста, ограничьтесь этим моим объяснением и продолжайте поддевать меня и приводить свои домыслы. Такие проблемы решаются в конкретной обстаноке конкретно, а не для болтовни. Спасибо.

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

Возможо уже отвеченное выше помогло Вам понять что происходит. Я вижу и ценю что Вы действительно пытаетесь понять, хоть и домысливая. Но Вы это делаете в рамков Ваших знаний и опыта. Они не покрывают всего спектра возможных подходов и решений, казалось бы, обычных баз данных.
DB2 for z/OS была разработа с учетом высочайших требований надежности и защиты данных. Применения DB2 for z/OS были изначально и сохраняются в тех отраслях где требования очень жесткие ко всему. Я не хочу унизить другие БД, ни в коем разе, но мало кто станет спорить что в других случаях имеется некоторое пренебрежение к "мелочам". Ну упал MS SQl, ну перезапусти и поехали дальше. Ну оказались корумпированны данные в Оракл, ну восстановили что смогли ии поехали дальже. С DB2 for z/OS такои номера не проходят, все очень даже все не так. Поэтому Вам, и другим, трудно понять зачем оставлять замки после SELECT ... FROM DUMMY, и почему конекцию с шаред лоцкс необходило удалят. Непонятно, наверное, и зачем различать активные и неактивные конекции, плус remote-connections versa local.
В DB2 for Linux/Windows/Unix все опять же иначе и больше сходств в поведении с MS SQL, Oracle, etc... Тот же autocommit там есть уже.

[Flash-04]

WebSphere кстати IBMвский. Дрянь ещё та.

[zVlad]

WebSphere кстати IBMвский. Дрянь ещё та.

За базар надо отвечать.

[Flash-04]

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

[geek7]

Нет в DB2 такого понятия "оптимистичный замок", i "оптимистичной блокировки" тоже.

Сначала его собеседники объявили, что Бога нет, потом сказали, что и Евангелия лишены исторического содержания, наконец, заявили, что и дьявола тоже нет. На что Воланд «расхохотался так, что из липы над головами сидящих выпорхнул воробей.

- Ну, уж это положительно Интересно, — трясясь от хохота, проговорил профессор, — что же это у вас, чего ни хватишься, ничего нет! — Он перестал хохотать внезапно и, что вполне понятно при душевной болезни, после хохота впал в другую крайность — раздражился и крикнул сурово: — Так, стало быть, так-таки и нету?»

вот гугл мне говорит что с 2008-го в 9.5 есть... опять только для люмпенской платформы, а на бахородной таких некошерных нововведений не сделали?

Optimistic locking in DB2 9.5 improves scalability by minimizing the time for which a given resource is unavailable for use by other transactions. Because the database manager can determine when a row is changed, it can ensure data integrity while limiting the time that locks are held.Jan 17, 2008

В DB2 есть поддержка конкурентного доступа к данным в базе. Реализуется это через использование различного вида "замков". Совместимость этих замков и их диапазон влияния определяется в том числе Isolation Level, которые: Repeatable Read (RR), Read Stability (RS), Cursor Stability (CS), Uncommited Read (UR).

так Optimistic locking и нужен чтобы можно было понизить Isolation Level за счёт обработки конфликта на стороне клиента

я не понял, Вы что хотите с моей помощью изучить DB2 for z/OS?

нет, понять в чём вообще предполагаемая проблема и в частности чем Вы недовольны как DBA

[zVlad]

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

Вот когда разберется "какого хрена" и зачем тогда и проблемы исчезнут. Потому что станет понятно как сделать чтобы проблемы не "проистекали".

[Flash-04]

ну как бы в "нормальном" Apache такой проблемы нет. А в WebSphere какая-то дурная оптимизация включена по умолчанию.

[geek7]

.....
простите, с какого хрена ею создан lock? чтобы протестировать ээээ "коннекцию" преред выдачей приложению обычно делают "SELECT 1"...

Все верно именно некоторые действия выполнялись и вот от них то и остались locks. Последний выполненный стэйтмент я вижу. Это: SELECT current timestamp FROM sysibm.sysdummy1. И остались 5 locks, и один claim:
...
Это shared, and intentional shared locks, они совместимы со многим если не со всем. Но это locks и по теории что я привел выше такой конекции наступает смерть через опеределенное время. Оптимизма, как видите, точно нет. Пессимизма, кстати, тоже нет, есть оператор commit и им надо пользоваться вовремя и правильно, не полагаясь ни на autocommit, ни на оптимизм.
Я догадываюсь что программа писалась не для DB2 for z/OS. Но тем програмистам/аналистам уже наши програмисты, с моей подачи, проблему описали. В ответ тишина, ступор. Трагического ничего не происходит: конекшн пул выхеривается каждые 5 минут и создается снова со стороны WebSphere.

честно говоря не понял про какой оптимизм\пессимизм в данном контесте идёт речь, но оптимистично предположу что Вам всего-то надо не к программерам обращатся а админам WebSphere. Логику конекшен пула ваяли программеры IBM а совсем не ваши... мало того похоже IBM балуется разными имплементациями на разных платформах, а девелоперов вообще могли на какой WebSphere Liberty посадить.

Ta WebSphere, кстати, не ма МФ. Вот если бы это было на Мф то я бы провентилировал вопрос в WebSphere, может там что-то надо подкрутить.

а что мешает подкрутить WebSphere не на МФ?
Если Вас именно переодичность 5 минут напрягает то гугление даёт совет
https://www.ibm.com/developerworks/comm ... er?lang=en
Unused timeout, Aged timeout - можно хоть в 0 выставить и никто их прибивать не будет (до момента когда будут затребованы и только если network connection таки накрылся или закрыто RDBMS создаст новый).

Но вообще вот тут пишут

Deprecated feature
Connection validation by SQL query is deprecated. Use validation by JDBC Driver instead

https://www.ibm.com/support/knowledgece ... meout.html
так что этот танец с бубном нужен если только драйвер не поддерживает, иначе WebSphere админ просто должен переконфигурить пул с народной самодеятельности на драйвер.

[zVlad]

..... понять в чём вообще предполагаемая проблема и в частности чем Вы недовольны как DBA

По-моему я уже ясно, с картинками, обьяснил что не доволен я тем что из-за отсутствия commit-ов DB2 вынуждена терминировать конекции, которые открываться с целью их re-use, что вызвано желанием сократить накладныe расходы по созданию конекций, и эта благая цель не достигается и даже наоборот вместо экономии на создании конекций их, воможно, приходится создавать больше раз чем если не хотеть их re-use, а закрывать и открывать конекции по мере надобности.
Я как смотрю в системный протокол так вижу вот это:

Code: Select all

13:58:20.94 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 297
                 297 00000090             LUWID=GA005447.E794.D5F2CE23F20D=39942
                 297 00000090
                 297 00000090  THREAD-INFO=DGEWPPRD:10.0.84.71:dgewpprd:db2jcc_application
                 297 00000090             RECEIVED ABEND=04E
                 297 00000090             FOR REASON=00D3003B
13:58:20.94 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 298
                 298 00000090             LUWID=GA005447.ED61.D5F2CED000AB=45029
                 298 00000090
                 298 00000090  THREAD-INFO=DGEWPPRD:10.0.84.71:dgewpprd:db2jcc_application
                 298 00000090             RECEIVED ABEND=04E
                 298 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 299
                 299 00000090             LUWID=GA005447.ED3E.D5F2CECEBC2A=44988
                 299 00000090
                 299 00000090  THREAD-INFO=DGEWPPRD:10.0.84.71:dgewpprd:db2jcc_application
                 299 00000090             RECEIVED ABEND=04E
                 299 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 300
                 300 00000090             LUWID=GA00562F.O19B.D5F2C9802D72=8479
                 300 00000090
                 300 00000090  THREAD-INFO=ASDSRC:catou-ogdbpva13:ASDSRC:db2jcc_application
                                  300 00000090             RECEIVED ABEND=04E
                 300 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 301
                 301 00000090             LUWID=GA00562F.F831.D5F2C0581FFA=127558
                 301 00000090
                 301 00000090  THREAD-INFO=ASDSRC:catou-ogdbpva13:ASDSRC:db2jcc_application
                 301 00000090             RECEIVED ABEND=04E
                 301 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 302
                 302 00000090             LUWID=GA00562F.F758.D5F2BF1E5F6D=122059
                 302 00000090
                 302 00000090  THREAD-INFO=ASDSRC:catou-ogdbpva13:ASDSRC:db2jcc_application
                 302 00000090             RECEIVED ABEND=04E
                 302 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 303
                 303 00000090             LUWID=GA00562F.F82E.D5F2C0581785=127555
                 303 00000090
                 303 00000090  THREAD-INFO=ASDSRC:catou-ogdbpva13:ASDSRC:db2jcc_application
                 303 00000090             RECEIVED ABEND=04E
                 303 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 304
                 304 00000090             LUWID=GA005447.EF6A.D5F2CF078518=46530
                                  304 00000090
                 304 00000090  THREAD-INFO=DGEWPPRD:10.0.84.71:dgewpprd:db2jcc_application
                 304 00000090             RECEIVED ABEND=04E
                 304 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 305
                 305 00000090             LUWID=GA005447.EF3B.D5F2CEF934C1=46245
                 305 00000090
                 305 00000090  THREAD-INFO=DGEWPPRD:10.0.84.71:dgewpprd:db2jcc_application
                 305 00000090             RECEIVED ABEND=04E
                 305 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 306
                 306 00000090             LUWID=GA00562F.FA06.D5F2C24CCB84=137462
                 306 00000090
                 306 00000090  THREAD-INFO=ASDSRC:catou-ogdbpva13:ASDSRC:db2jcc_application
                 306 00000090             RECEIVED ABEND=04E
                 306 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL028I  -DB09 GA005447.E794.D5F2CE23F20D=39942 307
                 307 00000090             ACCESSING DATA FOR
                 307 00000090               LOCATION ::10.0.84.71
                 307 00000090               IPADDR ::10.0.84.71
13:58:20.95 STC71007 00000090  DSNL027I  -DB09 SERVER DISTRIBUTED AGENT WITH 308
                 308 00000090             LUWID=GA00562F.F84A.D5F2C085C2D2=128279
                  08 00000090
                 308 00000090  THREAD-INFO=ASDSRC:catou-ogdbpva13:ASDSRC:db2jcc_application
                 308 00000090             RECEIVED ABEND=04E
                 308 00000090             FOR REASON=00D3003B
13:58:20.95 STC71007 00000090  DSNL028I  -DB09 GA005447.ED61.D5F2CED000AB=45029 309
                 309 00000090             ACCESSING DATA FOR
                 309 00000090               LOCATION ::10.0.84.71
                 309 00000090               IPADDR ::10.0.84.71
13:58:20.96 STC71007 00000090  DSNL028I  -DB09 GA005447.ED3E.D5F2CECEBC2A=44988 310
                 310 00000090             ACCESSING DATA FOR
                 310 00000090               LOCATION ::10.0.84.71
                 310 00000090               IPADDR ::10.0.84.71
13:58:20.96 STC71007 00000090  DSNL028I  -DB09 GA00562F.O19B.D5F2C9802D72=8479 311
                 311 00000090             ACCESSING DATA FOR
                 311 00000090               LOCATION ::10.0.86.47
                 311 00000090               IPADDR ::10.0.86.47
13:58:20.96 STC71007 00000090  DSNL028I  -DB09 GA00562F.F831.D5F2C0581FFA=127558 312
                 312 00000090             ACCESSING DATA FOR
                 312 00000090               LOCATION ::10.0.86.47
                 312 00000090               IPADDR ::10.0.86.47
13:58:20.96 STC71007 00000090  DSNL028I  -DB09 GA00562F.F758.D5F2BF1E5F6D=122059 313
                 313 00000090             ACCESSING DATA FOR
                 313 00000090               LOCATION ::10.0.86.47
                 313 00000090               IPADDR ::10.0.86.47
13:58:20.96 STC71007 00000090  DSNL028I  -DB09 GA00562F.F82E.D5F2C0581785=127555 314
                 314 00000090             ACCESSING DATA FOR
                 314 00000090               LOCATION ::10.0.86.47
                 314 00000090               IPADDR ::10.0.86.47
13:58:20.96 STC71007 00000090  DSNL028I  -DB09 GA005447.EF6A.D5F2CF078518=46530 315
                 315 00000090             ACCESSING DATA FOR
                 315 00000090               LOCATION ::10.0.84.71
                 315 00000090               IPADDR ::10.0.84.71
13:58:20.98 STC71007 00000090  DSNL028I  -DB09 GA005447.EF3B.D5F2CEF934C1=46245 316
                 316 00000090             ACCESSING DATA FOR
                 316 00000090               LOCATION ::10.0.84.71
                 316 00000090               IPADDR ::10.0.84.71
13:58:20.98 STC71007 00000090  DSNL028I  -DB09 GA00562F.FA06.D5F2C24CCB84=137462 317
                 317 00000090             ACCESSING DATA FOR
                 317 00000090               LOCATION ::10.0.86.47
                 317 00000090               IPADDR ::10.0.86.47
13:58:20.99 STC71007 00000090  DSNL028I  -DB09 GA00562F.F84A.D5F2C085C2D2=128279 318
                 318 00000090             ACCESSING DATA FOR
                 318 00000090               LOCATION ::10.0.86.47
                 318 00000090               IPADDR ::10.0.86.47
                 
......

И это еще не все что выдалось по поводу выхереных конекций за одну секунду. Это ненормально, но устранить только возможностями DBA невозможно.
Обьяснение reason code 00D3003B дано выше.

[zVlad]

ну как бы в "нормальном" Apache такой проблемы нет. А в WebSphere какая-то дурная оптимизация включена по умолчанию.

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

[sp123]

Блокировки в DB2 - это да, неприятно. Одно дело, когда мы тут трепались на многостраничном топике, и совсем другое дело, когда спотыкаешься на них по работе.

Вот простой пример.

Сижу на большом datawarehouse под хадупом. Данные в него собираются из самых разных источников, в том числе баз данных. Очень разных. В какой-то момент пара десятков доселе безобидных заданий вдруг начинают сильно тормозить, причём случайным образом. Раньше все выполнялось за час, а теперь крутится уже полдня.

Первым делом лезу в хадуп, там обычно масса поводов для проблем. Но там все хорошо. Лезу в код. Код очень простой, внутри тривиальный SELECT, ничего хитрого, данные возвращает очень быстро. Источник - DB2. Да, на майнфрейм. К данной базе у меня DBA доступа, понятное дело, нет. Замечаю интересную закономерность: задание застревает строго после выборки пяти тысяч записей. Иногда не застревает. И где-то я уже эту цифру видел... Семен Семеныч, это размер буфера fetch в утилите. Явно кто-то блокирует, выполняя тот же SELECT. И я даже знаю, кто. Это еще один хадупный кластер, на который мы собираемся мигрировать. А пока он крутит те же задания параллельно, и в одно и то же время. Так надо. Результаты работы обеих реплик потом надо сравнить, и они должны совпасть. Иначе миграцию никто не утвердит.

Что делать? Вариантов два. Выявить все запросы к DB2 и добавить в конце ‘with UR’. То есть делать т.н. dirty read. Блокировок не будет, но и данные будут тоже dirty. Опять же, программ много, времени на изменения кода нет. Второй вариант - разнести задания по времени. Результаты будут слегка разные, придется каждый раз доказывать начальству, что все в пределах нормы, но кому сейчас легко? На том и порешили. Все опять заработало, но приобрелся дополнительный геморрой. Где-то так.




Sent from my iPhone using Tapatalk Pro

[geek7]

..... понять в чём вообще предполагаемая проблема и в частности чем Вы недовольны как DBA

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

а нельзя сконфигурировать, чтобы DB2 терминировала конекции чуть позже пула вебсферы? ну да кажется неэкономно, но насчёт цели "экономии на создании конекций" я подозреваю Вы подразумеваете что-то типа CPU\Network load... вообще эти расходы не существенные, а сыр бор из-за Latency - с этой ТЗ пусть конекций хоть 100 будет созданно и убито без толку, главное чтобы когда юзверь нажал на кнопочку уже была готовая и рабочая и сразу вернула ему взад результат.

[zVlad]

Блокировки в DB2 - ....

Как написаное Вами что-то вообще говорит о блокировках в DB2. Я этого не уловил. Может надо еще раз прочитать.
К чему было писать так много чтобы показать неправильный подход к решению задачи, возможно DBA вам помог бы лучше чем гадать на кофейной гуще. Ваше "явно" звучит очень не убедительно, как и "размер буфера fetch утилиты", какой утилиты, что за буфер, причем здесь другой хадуп. Почему вообще на основании этого делается вывод о блокировке ДБ2, а не об измечивости погоды на северном полюсе.

[sp123]

Блокировки в DB2 - ....

Как написаное Вами что-то вообще говорит о блокировках в DB2. Я этого не уловил. Может надо еще раз прочитать.
К чему было писать так много чтобы показать неправильный подход к решению задачи, возможно DBA вам помог бы лучше чем гадать на кофейной гуще. Ваше "явно" звучит очень не убедительно, как и "размер буфера fetch утилиты", какой утилиты, что за буфер, причем здесь другой хадуп. Почему вообще на основании этого делается вывод о блокировке ДБ2, а не об измечивости погоды на северном полюсе.

Согласен, вышло длинно и непонятно.

Утилита называется sqoop, параметр fetch-size. Задержки импорта данных в HDFS после выборок с числом записей, кратным размеру этого параметра, послужили косвенным признаком того, что проблема с блокировками на стороне базы данных. Да, гадание на кофейной гуще.

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

Да, DBA мог бы помочь. Но пока я до него доберусь через бюрократические процедуры и тикеты, а потом он еще и будет отбрыкиваться и переводить стрелки, меня уволят нах .


Sent from my iPhone using Tapatalk Pro

[Flash-04]

ну как бы в "нормальном" Apache такой проблемы нет. А в WebSphere какая-то дурная оптимизация включена по умолчанию.

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

мне не надо. пусть тот тим голову ломает

[zVlad]

Блокировки в DB2 - ....

Как написаное Вами что-то вообще говорит о блокировках в DB2. Я этого не уловил. Может надо еще раз прочитать.
К чему было писать так много чтобы показать неправильный подход к решению задачи, возможно DBA вам помог бы лучше чем гадать на кофейной гуще. Ваше "явно" звучит очень не убедительно, как и "размер буфера fetch утилиты", какой утилиты, что за буфер, причем здесь другой хадуп. Почему вообще на основании этого делается вывод о блокировке ДБ2, а не об измечивости погоды на северном полюсе.

Согласен, вышло длинно и непонятно.

Утилита называется sqoop, параметр fetch-size. Задержки импорта данных в HDFS после выборок с числом записей, кратным размеру этого параметра, послужили косвенным признаком того, что проблема с блокировками на стороне базы данных. Да, гадание на кофейной гуще.

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

Да, DBA мог бы помочь. Но пока я до него доберусь через бюрократические процедуры и тикеты, а потом он еще и будет отбрыкиваться и переводить стрелки, меня уволят нах .


Sent from my iPhone using Tapatalk Pro

Я гадать не буду, не умею. Но я бы понаблюдал за параллельным выполнением SELECT с двух кластеров в ДБ2, нашел бы причину замедления и соответственно решение как это ускорить.
Я, как Вы понимаете DBA, я реагирую на любой писк наших программистов немедленно без всяких тикетов. Просто я понимаю что с их возможностями и знаниями внутренней кухни бывает сложно разрешать такие проблемы и надо подключаться чтобы время не терялось. Может Вам все таки стоит попробовать обратиться к DBA, или хотя бы узнать нет ли у них Omegamon-a for DB2, и как к нему обратиться. Мои программисты такой доступ имеют и кое-что могут смотреть сами. Если находят и не могут понять то обращаютчя ко мне. Это нормальный процесс как должен быть. Гадание же про блокировки процесс неконструктивный.
Вы говорите два SELECT выполняется. По теории они не должны блокировать друг друга так как в общем случае им нужны shared locks. Но можно создать такую ситуацию, через isolation level, например, что будут оставаться locks на то что уже прочитанно. Но это будет выглядеть как что один селект шурует быстро, а второй вообще стоит и ждет. В ДБ2 есть таймаут для этого, по умолчанию 1 минута, и ждущий запрос будет просто убит по таймаут-у.
Для полногь и точного понимания не хватает конкретики. В первую очерпдь касаемо утилиты sqoop. Я про такую утилиту не слышал. Виду есть документ по ней на интернете, это open source, что уже плохо, использует удаленный доступ, remote connection, что тоже чревато проблемами. Для большиж объемов я бы предложил использовать утилиту DB2 UNLOAD в файл ftp файл в HDFS и импортировать из файла в hadoop. Тогда Вам бы не понадобилось грешить на блокировку, которая тоже полагаю на есть Ваша проблема. Я использую UNLOAD в параллель с продакшн OLTP, естественно with ur. В Вашем случае, если вам не хочется иметь uncommited data, возможно нужен другой подход, например репликация.
Я просмотрел документ по sqoop. Может оно и ничего, но я бы покрайней мере предусмотрел мониторинг в ДБ2, через тот же Omegamon, как и что собственно будет выполняться, какие задержки и из-за чего. Делая такие вещи вслепую может дать любой эффект вплодь до того что в z/OS где та DB2 не используют DDF и, следовательно, WLM полиси взято по умолчанию в котором сервис класс для DDF сконфигурирован в несколько периодов с деградацией важности, и даже не сильно важные работы (пакетные задания) могут превышать по важности DDF транзакцию. Сделано это из предположения, вполне разумного, что DDF используется для коротких, легких запросов, а тут может быть весьма объемная работа выполняться в одной транзакции.
Короче, надо мониторить и не только DB2. Для специалиста это делается в несколько минут чтобы понять причину и предложить решение.

[zVlad]

ну как бы в "нормальном" Apache такой проблемы нет. А в WebSphere какая-то дурная оптимизация включена по умолчанию.

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

мне не надо. пусть тот тим голову ломает

Тогда и сплетни распускать не надо.

[zVlad]

.....
честно говоря не понял про какой оптимизм\пессимизм в данном контесте идёт речь, но оптимистично предположу что Вам всего-то надо не к программерам обращатся а админам WebSphere. Логику конекшен пула ваяли программеры IBM а совсем не ваши... мало того похоже IBM балуется разными имплементациями на разных платформах, а девелоперов вообще могли на какой WebSphere Liberty посадить.

Ta WebSphere, кстати, не ма МФ. Вот если бы это было на Мф то я бы провентилировал вопрос в WebSphere, может там что-то надо подкрутить.

а что мешает подкрутить WebSphere не на МФ?
Если Вас именно переодичность 5 минут напрягает то гугление даёт совет
https://www.ibm.com/developerworks/comm ... er?lang=en
Unused timeout, Aged timeout - можно хоть в 0 выставить и никто их прибивать не будет (до момента когда будут затребованы и только если network connection таки накрылся или закрыто RDBMS создаст новый).

Но вообще вот тут пишут

Deprecated feature
Connection validation by SQL query is deprecated. Use validation by JDBC Driver instead

https://www.ibm.com/support/knowledgece ... meout.html
так что этот танец с бубном нужен если только драйвер не поддерживает, иначе WebSphere админ просто должен переконфигурить пул с народной самодеятельности на драйвер.

Это конечно очень здорово что у Вас так много идей и предложений есть для меня. Вот только я никого никогда не прошу, тем более когда меня это очень отдаленно касается и сам я достаточно отдален от некоторых ключевый элементов.
Был бы WebSphere на мф я бы стал с этим разбираться и если ноги растут и WAS, то и вылечил бы их как надо.
Никаких таймаутов, без выяснения всех обстоятельств, я менять не буду постольку поскольку у нас не одно это приложение использует удаленный доступ к ДБ2 и до недавних пор никакой такой диагностики не было. Тем не менее спасибо, я почитаю ссылки для общего развития, на будущее.
Liberty там нет, это в продакшн уже работает.

[geek7]

Никаких таймаутов, без выяснения всех обстоятельств, я менять не буду постольку поскольку у нас не одно это приложение использует удаленный доступ к ДБ2 и до недавних пор никакой такой диагностики не было. Тем не менее спасибо, я почитаю ссылки для общего развития, на будущее.
Liberty там нет, это в продакшн уже работает.

пулы ,как правило, для каждого приложения отдельные (хотя можно и share) . Я бы первым делом не таймауты менял, а убедился - стоит ли Connection validation by SQL query и если да то сменил на JDBC Driver и протестировал.
Liberty я помянул именно поттому что в продакшен может быть не он, а вот у девелоперов локально - он и соответственно они даже воспроизвести проблему локально не смогут и о чём Вы говорите им без понятия.