|
|
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Есть такая ситуация: В пакете обычная процедура и стоит логирование вызова, внутри процедуры только select. Суть проблемы в том, что в непредсказуемый момент эта процедура перестает вызываться и лог вызова по ней так же перестает писаться, однако клиент думает что с процедурой все хорошо и продолжает возвращать какие-то данные причем не корректные. Преднамеренно создать такую ситуацию не представляется возможным. Если отключиться от базы и полностью выключить клиент затем заново подключиться, бага сохранится в неизменном виде. Лечение только одно, нужно развалить пакет, и удалить эту процедуру (например добавить 1 к названию) скомпилить с единицей, затем удалить единицу и скомпилить в том виде как изначально было, тогда лечится проблема мгновенно без перезапусков чего либо. Этот баг с клиентом думаю не связан, так как даже если выполнить скрипт с вызовом процедуры в окне PL\SQL Developer будут те же не корректные данные и тоже отсутствие лога, а после "слома" пакета все сразу корректно становится. Кто-то сталкивался с там? Проблема распространяется не на пакет в целом, а на отдельно взятые процедуры, причем ни чем не отличающиеся от других. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 12:40 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Zalmобычная процедураНе result_cache функция? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 13:41 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Zalm.. в непредсказуемый момент эта процедура перестает вызываться и лог вызова по ней так же перестает писаться, однако .. продолжает возвращать .. поясните ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 13:55 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
текст бы посмотреть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 13:57 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
orawishZalm.. в непредсказуемый момент эта процедура перестает вызываться и лог вызова по ней так же перестает писаться, однако .. продолжает возвращать .. поясните Я вызываю на клиенте процедуру (или в окне pl/sql developer), в итоге мне приходит какой-то результат (чаще всего тот, который ничего не имеют общего с действительностью), и при этом лог вообще не записывается pf_json_error('test','profile'); хотя он записывается ВСЕГДА и везде, но только не тут когда случается такой залип. Я могу даже написать pf_json_error('test','profile_lala'); перекомпилить пакет, перезапустить клиент и тд, ничего не изменится, всегда будет мусор в ответе, и только когда я сделаю что пакет стал инвалидным, затем скомпилю снова, тогда все ошибки и баги пропадают даже клиент перезапускать не нужно. ElicZalmобычная процедураНе result_cache функция? Нет, это процедура andreymxтекст бы посмотреть Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 14:23 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Zalm, В pf_json_error ошибки не глотаются? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 14:35 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
AlexFF__|Zalm, В pf_json_error ошибки не глотаются? Нет, она просто в автономной транзакции пишет 1 строку в таблицу без индексов, больше ничего не происходит сейчас пока тестировал снова такая бага возникла, что не пытался сделать - все безтолку, только инвалидация пакета спасает... эту ситуацию очень тяжело поймать в рабочем процессе, я даже не знаю как, разве что ошибку обработки словить на клиенте и все Причем если скомпилить валидный пакет в это время - ничего не происходит, баг не пропадает, опять же повторюсь что с клиентом это не связано, так как клиент не нужно перезапускать что бы все начало норм работать, надо ток сломать пакет и собрать заново ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 14:42 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Почему вы думаете, что процедура не вызывается? Потому что pf_json_error не вызывается? Ну, так до него много чего происходит, например, объявление курсора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 14:45 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
ValergradПочему вы думаете, что процедура не вызывается? Потому что pf_json_error не вызывается? Ну, так до него много чего происходит, например, объявление курсора. 1) Думаю так потому что pf_json_error('test','profile'); перестает работать 2) Потому что процедура начинает отдавать невменяемые данные не связанные с реальностью (если взять тот же селект и выполнить, будут совершенно другие данные) 3) + еще так думаю потому, что инвалидация пакета решает только проблему, почему тогда только это помогает? 4) Если через pf_json_error('test','profile'); проверять вызов не корректно, каким еще способом проверить вызывается ли она? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 15:05 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Zalm, Попробуй вывод информации через dbms_output ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 16:08 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
похоже на какой-то пакет с глобальной переменной, в котором есть обращение к указанной процедуре ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 18:47 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
AlexFF__|Zalm, Попробуй вывод информации через dbms_output в момент залипухи dbms_output тоже ничего не выводит, это я проверял когда еще впервые сталкивался с этой проблемой...( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 19:03 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
ZalmAlexFF__|Zalm, Попробуй вывод информации через dbms_output в момент залипухи dbms_output тоже ничего не выводит, это я проверял когда еще впервые сталкивался с этой проблемой...( Глобальных переменных нет ни где ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 19:03 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
ИМХО - ТС хитро настроил transparent failover и теперь троллит публику, рассказывая как он подключается то к одной, то к другой БД с одного дескриптора :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 19:07 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousИМХО - ТС хитро настроил transparent failover и теперь троллит публику, рассказывая как он подключается то к одной, то к другой БД с одного дескриптора :) Другой вариант - ТС не видит реальную проблему, поскольку задавил ее в довольно своеобразном when others. Рекомендация: убрать when others и посмотреть, что на самом деле происходит при вызове. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 19:24 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousandrey_anonymousИМХО - ТС хитро настроил transparent failover и теперь троллит публику, рассказывая как он подключается то к одной, то к другой БД с одного дескриптора :) Другой вариант - ТС не видит реальную проблему, поскольку задавил ее в довольно своеобразном when others. Рекомендация: убрать when others и посмотреть, что на самом деле происходит при вызове. Говорю же, ничего не происходит, не доходит туда вызов когда пакет так залипает ни dbms_output ни другие мои процедуры логирования не срабатывают в проблемной процедуре до момента инвалидации пакета и новой сборки andrey_anonymousИМХО - ТС хитро настроил transparent failover и теперь троллит публику, рассказывая как он подключается то к одной, то к другой БД с одного дескриптора :) про эту настройку я ничего не слышал, и работаю я с одной базой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 20:38 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
ZalmГоворю же, ничего не происходит, не доходит туда вызов когда пакет так залипает... Не верим ( C ) Станиславский(е) Не бывает такого. Вам уже сказали: исправьте свой говно код, уберите "exception when others" или, на худой конец, реализуйте его по человечески. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2016, 20:44 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
А клиент использует dedicated соединение? Никакие пулы сессий, случайно, не используются? И секции инициализации точно нет в конце пакета? (про переменные понятно). По поведению, все-таки, похоже, что-то переинициализируется после изменения спецификации пакета. Кстати, текст процедуры был приведен в конце сообщения , если вдруг кто-то не заметил... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 11:29 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Еще бы текст pf_json_error было бы хорошо привести... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 11:32 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Деев И.Еще бы текст pf_json_error было бы хорошо привести... Да лучше наверное неформатированную (raw) трассу 10046 level 4 по проблемной сессии... Хоть вызов увидим и рекурсивные курсоры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 13:28 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Деев И.А клиент использует dedicated соединение? Никакие пулы сессий, случайно, не используются? И секции инициализации точно нет в конце пакета? (про переменные понятно). По поведению, все-таки, похоже, что-то переинициализируется после изменения спецификации пакета. Кстати, текст процедуры был приведен в конце сообщения , если вдруг кто-то не заметил... В основном использую dedicated да, но но проблема повторяется как с клиента PL\SQL Developer так и с dedicated соединения на клиенте Деев И.Еще бы текст pf_json_error было бы хорошо привести... Код: plsql 1. 2. 3. 4. 5. 6. 7. andrey_anonymousДеев И.Еще бы текст pf_json_error было бы хорошо привести... Да лучше наверное неформатированную (raw) трассу 10046 level 4 по проблемной сессии... Хоть вызов увидим и рекурсивные курсоры. Самое главное как я и говорил, проблема не в конкретной сессии, когда залипает процедура, то можно выключать\включать клиент, можно PL\SQL Developer включить\выключить, ничего не поменяется, процедура так и будет залипшей, лечится исключительно инвалидацией пакета, других методов пока не нашел, вот это и есть основная проблема, если увидеть что она залипла - можно развалить пакет и снова собрать и все будет идеально, можно даже ни где не переподключаться Ошибку эту никак не отследить, кроме как глазами увидеть что упало что-то на клиенте, и то, по факту ничего не падает, просто данные отдаются совсем не те, что есть в базе в текущий момент и логирования не происходит этой процедуры, вот только по этим двум признакам можно определить залипуху ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2016, 09:33 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Zalm, и это только с одним пакетом такое творится? Чем он такой особенный, интересно. Постоянно ли такое было с этим пакетом или началось ни с того ни с сего? Бывало такое несколько раз, что возникали какие-то необъяснимые явления на базах, где многие разработчики или тестировщики активно накатывали изменения и т.п. Лечилось топорно - сбросом библиотечного кеша или перезагрузкой инстанса. Может, попробовать? Вдруг поможет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2016, 17:52 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Zalm andrey_anonymousпропущено... лучше наверное неформатированную (raw) трассу 10046 level 4 по проблемной сессии... Хоть вызов увидим и рекурсивные курсоры. Самое главное как я и говорил, проблема не в конкретной сессии, когда залипает процедура, то можно выключать\включать клиент, можно PL\SQL Developer включить\выключить, ничего не поменяется, процедура так и будет залипшей, лечится исключительно инвалидацией пакета, других методов пока не нашел ... Ошибку эту никак не отследить Мсье противоречит сам себе. Если проблемное состояние стабильно - то подключаетесь, включаете трассировку и делаете вызов. В трассе смотрите - кто, кого, как, когда и зачем позвал. Или не позвал. Или позвал, но не только того, кого ожидалось ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2016, 16:17 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Прямо в Pl/sql developer есть Pl/sql трассировка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2016, 16:53 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
xtenderПрямо в Pl/sql developer есть Pl/sql трассировкадля этого надо пакет с отладочной инфой перекомпилить, ситуация уйдёт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2016, 17:05 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevZalmГоворю же, ничего не происходит, не доходит туда вызов когда пакет так залипает... Не верим ( C ) Станиславский(е) Не бывает такого. Вам уже сказали: исправьте свой говно код, уберите "exception when others" или, на худой конец, реализуйте его по человечески. IMHO +1 насколько я помню, NO_DATA_FOUND пролетает мимо в непонятно куда , если его не ловить явно ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2016, 18:10 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
andreymxxtenderПрямо в Pl/sql developer есть Pl/sql трассировкадля этого надо пакет с отладочной инфой перекомпилить, ситуация уйдёт Сейчас как раз снова столкнулся с проблемой, как спрашивали уже, это не связано с конкретным пакетом и процедурой, это может в любом пакете в любой процедуре проявиться Вот самый свежий пример, пока разбирался попробовал посмотреть что в сессии происходит: У этих курсоров были залипухи, затем я открыл новое окно PL/SQL и выполнил там что-то вроде( чисто для теста , с теми же параметрами): Код: plsql 1. 2. 3. 4. 5. 6. И увидел что там: Оказалось что оно работает, затем я включил клиент, убил все сессии которые только могли быть, запускаю клиент, снова залипуха! Решил вернуться к старому дедовскому методу, сломать и собрать пакет снова, не помогло . И тут я подумал, что я делаю операции все только с BODY , а спецификацию вообще не трогаю, так как в ней ничего не меняется. Решил перекомпильнуть спецификацию одну, и о чудо! все снова заработало без каких-либо перезагрузок и переподключений в итоге вопроса 2: 1) Почему выполняя по сути один и тот же SQL код на клиенте не срабатывает логирование (косвенно понимаю что не происходит вызова), а при выполнении из другого окна PL/SQL срабатывает? 2) Почему именно перекомпиляция спецификации вылечила ситуацию? может периодически в JOB перекомпиливать все спецификации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2016, 01:50 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Zalm, 1. Картинки приводили и выделяли цветом зря, это нормально, так и должно быть 2. Приведите, в конце концов, полный текст пакета и как конкретно вызываете процедуру: 1) из клиента, 2) из плскл девелопера; (если не хотите светить публично, отправьте на мыло в профиле); 3. Отдебажьте ваши проблемные/нормальные вызовы либо через Код: plsql 1. либо через иерархический профайлер ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2016, 02:45 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Пока подозрения на clob сессионный и проглоченный где-то exception.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2016, 02:59 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
[quot Zalm]andreymxпропущено... ... 2) Почему именно перекомпиляция спецификации вылечила ситуацию? может периодически в JOB перекомпиливать все спецификации? скорее всего есть ещё один способ. было один в один. спасала только или перекомпиляция или точно такая же процедура но немного видоизменённая по коду, причём если запускать процедуру повторно - то она "вешалась" приходилось запускать процедуры чередованием. так и запускались процедуры поочереди - сначала одна, потом другая, потом опять первая пока я искал причины. решение было простое - я переписал процедуру поиски каких либо ошибок... анализ трассировок... все впустую. логического объяснения причины я тогда не нашёл и для себя решил, что это говнокод. мой говнокод. который я успешно переписал. а выходит всё же что то другое... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2016, 16:40 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
[quot Alex URS]Zalmпропущено... скорее всего есть ещё один способ. было один в один. спасала только или перекомпиляция или точно такая же процедура но немного видоизменённая по коду, причём если запускать процедуру повторно - то она "вешалась" приходилось запускать процедуры чередованием. так и запускались процедуры поочереди - сначала одна, потом другая, потом опять первая пока я искал причины. решение было простое - я переписал процедуру поиски каких либо ошибок... анализ трассировок... все впустую. логического объяснения причины я тогда не нашёл и для себя решил, что это говнокод. мой говнокод. который я успешно переписал. а выходит всё же что то другое... Пока только это и спасает, переписывать нет смысла ничего, так как это не помогает, причины другие какие-то Это не связано с конкретными процедурами, это связано с пакетами в целом, были совершенно не предсказуемые ситуации и неожиданные, например когда запрос уходит в другую схему на такую же процедуру, как это происходит я так и не понял, но перекомпиляция все вылечивает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2016, 09:32 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
Zalmкогда запрос уходит в другую схему на такую же процедуруКто на ком стоял? Zalmкак это происходит я так и не понялБаги по перепутыванию схем бывали. Но какая у тебя версия? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2016, 09:51 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
ElicZalmкогда запрос уходит в другую схему на такую же процедуруКто на ком стоял? Zalmкак это происходит я так и не понялБаги по перепутыванию схем бывали. Но какая у тебя версия? Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production По поводу кто нам ком стоял я не понял вопрос ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2016, 14:01 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
ZalmПо поводу кто нам ком стоял я не понял вопросФункции не могут вызывать процедуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2016, 15:29 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
ElicZalmПо поводу кто нам ком стоял я не понял вопросФункции не могут вызывать процедуры. Ы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2016, 15:32 |
|
||
|
Непредсказуемое кеширование
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousElicпропущено... Функции не могут вызывать процедуры. Ы?Запросы конечно же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2016, 15:42 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1887153]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
177ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 187ms |
| total: | 454ms |

| 0 / 0 |
