Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
вообще задача отгадать почему приложение с хибером после некоторой работы выдает на экран 10 строк, а не сколько я ожидаю, почему такое поведение лечится перегрузкой томката и помочь жава-программеру докапаться до истины. вот отрасировал все сессии и вроде нашел первый запрос где как мы и ожидаем фетчится 50 строк (5 раз по 10 фетчей) и второй, вероятно проблемный, но который я расшифровать не могу (запросы идентичны):


======================
PARSING IN CURSOR #8 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245585454359547 hv=3739417321 ad='3ea4a228'
длинный SQL заканчивается where rownum <= :3
END OF STMT
PARSE #8:c=0,e=58,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245585454359543
EXEC #8:c=0,e=34,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245585454359664
FETCH #8:c=1000,e=689,p=0,cr=11,cu=0,mis=0,r=10,dep=0,og=1,tim=1245585454360660
FETCH #8:c=0,e=547,p=0,cr=8,cu=0,mis=0,r=10,dep=0,og=1,tim=1245585454362344
FETCH #8:c=0,e=828,p=0,cr=12,cu=0,mis=0,r=10,dep=0,og=1,tim=1245585454364194
FETCH #8:c=999,e=792,p=0,cr=11,cu=0,mis=0,r=10,dep=0,og=1,tim=1245585454366012
FETCH #8:c=1000,e=903,p=0,cr=13,cu=0,mis=0,r=10,dep=0,og=1,tim=1245585454367934
STAT #8 id=1 cnt=50 pid=0 pos=1 obj=0 op='COUNT STOPKEY (cr=55 pr=0 pw=0 time=7283 us)'
STAT #8 id=2 cnt=50 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL TABLE1 (cr=55 pr=0 pw=0 time=6982 us)'
=====================
====================
PARSING IN CURSOR #9 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245585462574836 hv=3739417321 ad='3ea4a228'
длинный SQL заканчивается where rownum <= :3
END OF STMT
PARSE #9:c=0,e=59,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245585462574833
EXEC #9:c=2999,e=3556,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1245585462578471
FETCH #9:c=0,e=13,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245585462578987
STAT #9 id=1 cnt=0 pid=0 pos=1 obj=0 op='COUNT STOPKEY (cr=0 pr=0 pw=0 time=10 us)'
STAT #9 id=2 cnt=0 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL TABLE1 (cr=0 pr=0 pw=0 time=2 us)'
=====================

во втором запросе FETCH r=0, это значит, что запрос вернул 0 строк ?
если я вижу FETCH r=10 я могу быть уверен, что клиент забрал эти 10 строк ?
можно ли из трейса определить, что запрос возвращает больше строк чем фетчит клиент ?
2 июн 10, 16:34    [8878993]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
вот больше похожий на проблемный запрос, где фетчится 10 строк


PARSING IN CURSOR #2 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245585503287474 hv=3739417321 ad='3ea4a228'
длинный SQL заканчивается where rownum <= :3
END OF STMT
PARSE #2:c=0,e=77,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245585503287470
EXEC #2:c=0,e=34,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245585503287566
FETCH #2:c=1000,e=786,p=0,cr=12,cu=0,mis=0,r=10,dep=0,og=1,tim=1245585503288671
FETCH #2:c=0,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1245585503289854
STAT #2 id=1 cnt=10 pid=0 pos=1 obj=0 op='COUNT STOPKEY (cr=12 pr=0 pw=0 time=1427 us)'
STAT #2 id=2 cnt=10 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL TABLE1 (cr=12 pr=0 pw=0 time=1413 us)'
вот что тут значит r=0 во втором фетче, почему он мог бы быть 0 если я почти уверен, что такой запрос ровно 10 не должен был возвращать.
2 июн 10, 16:39    [8879050]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
r=0 означает, что записи в курсоре закончились.
После этого устанавливается атрибут курсора %NOTFOUND
PARSING IN CURSOR #2 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245585503287474 hv=3739417321 ad='3ea4a228'
длинный SQL заканчивается 
where rownum <= :3
END OF STMT
PARSE #2:c=0,e=77,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245585503287470
EXEC #2:c=0,e=34,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245585503287566
FETCH #2:c=1000,e=786,p=0,cr=12,cu=0,mis=0,r=10,dep=0,og=1,tim=1245585503288671
FETCH #2:c=0,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1245585503289854
Я почти уверен, что :3 было равно 10 :)
Чтобы убедиться - снимите трассировку level 4, оно покажет значения биндов.
Что касается "почему показывает меньше" - похоже, что клиент работает пачками по 10 записей.
Есть один ньюанс.
Если записей в курсоре не кратно 10, то на последнем фетче (к примеру, пусть там будет 3 записи r=3) у курсора уже будет выставлен атрибут %NOTFOUND.
Если выход из курсорного цикла построен на проверке данного атрибута - эти 3 записи скорее всего не будут отображены клиентом :)
2 июн 10, 17:53    [8879905]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
wildwind
Member

Откуда: Москва
Сообщений: 1296
dnater,

10 потому что в JDBC FetchSize по умолчанию 10.
На всякий случай проверьте, что версия JDBC драйвера соответствует версии сервера (или клиента, если OCI). Могут быть баги.
2 июн 10, 18:47    [8880391]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
проверил бинды, третий бинд 50

PARSING IN CURSOR #2 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245596741907715 hv=131164585 ad='407f047c'
select * from ( большой селект ) where rownum <= :3
END OF STMT
PARSE #2:c=0,e=78,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245596741907711
BINDS #2:
kkscoacd
Bind#0
oacdty=01 mxl=128(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=280 off=0
kxsbbbfp=f7af7590 bln=128 avl=07 flg=05
value="baltic%"
Bind#1
oacdty=01 mxl=128(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=0 off=128
kxsbbbfp=f7af7610 bln=128 avl=07 flg=01
value="baltic%"
Bind#2
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=01 csi=873 siz=0 off=256
kxsbbbfp=f7af7690 bln=22 avl=02 flg=01
value=50
EXEC #2:c=0,e=169,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245596741907945
FETCH #2:c=1000,e=785,p=0,cr=12,cu=0,mis=0,r=10,dep=0,og=1,tim=1245596741909445
FETCH #2:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1245596741919364
STAT #2 id=1 cnt=10 pid=0 pos=1 obj=0 op='COUNT STOPKEY (cr=12 pr=0 pw=0 time=1448 us)'
STAT #2 id=2 cnt=10 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL TABLE1 (cr=12 pr=0 pw=0 time=1425 us)'

а что такое cnt=10 тут ?
STAT #2 id=2 cnt=10 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL TABLE1 (cr=12 pr=0 pw=0 time=1425 us)'

почему cnt может отличатся от более ранего запроса с тем же hv=131164585 ?


PARSING IN CURSOR #3 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245596726901426 hv=131164585 ad='407f047c'
select * from ( большой селект ) where rownum <= :3
END OF STMT
PARSE #3:c=0,e=75,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245596726901422
BINDS #3:
kkscoacd
Bind#0
oacdty=01 mxl=32(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=88 off=0
kxsbbbfp=f7b4af3c bln=32 avl=07 flg=05
value="baltic%"
Bind#1
oacdty=01 mxl=32(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=0 off=32
kxsbbbfp=f7b4af5c bln=32 avl=07 flg=01
value="baltic%"
Bind#2
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=01 csi=873 siz=0 off=64
kxsbbbfp=f7b4af7c bln=22 avl=02 flg=01
value=50
EXEC #3:c=0,e=169,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245596726901653
FETCH #3:c=1000,e=785,p=0,cr=12,cu=0,mis=0,r=10,dep=0,og=1,tim=1245596726903145
FETCH #3:c=1000,e=1240,p=0,cr=17,cu=0,mis=0,r=10,dep=0,og=1,tim=1245596726914672
FETCH #3:c=1999,e=2013,p=0,cr=26,cu=0,mis=0,r=10,dep=0,og=1,tim=1245596726927061
FETCH #3:c=1000,e=1640,p=0,cr=22,cu=0,mis=0,r=10,dep=0,og=1,tim=1245596726951659
FETCH #3:c=1000,e=1125,p=0,cr=14,cu=0,mis=0,r=10,dep=0,og=1,tim=1245596726966388
STAT #3 id=1 cnt=50 pid=0 pos=1 obj=0 op='COUNT STOPKEY (cr=91 pr=0 pw=0 time=7475 us)'
STAT #3 id=2 cnt=50 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL TABLE1 (cr=91 pr=0 pw=0 time=7372 us)'

ощущение что на те же бинды именно оракл возвращает разный результат, но совсем не понятно почему лечится рестартом томката.
2 июн 10, 19:32    [8880632]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
dnater
ощущение что на те же бинды именно оракл возвращает разный результат, но совсем не понятно почему лечится рестартом томката.

Ощущение бредовое, но не невероятное.
Рестарт томката означает рестарт пула сессий DB.
Рестарт сессии означает повторную инициализацию сессии.
Т.е. сброс состояния сессии.
Дальше - показывайте свой "большой запрос".
И уточните у DBA, не шутит ли он над Вами посредством RLS :)
2 июн 10, 19:58    [8880700]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
функции дба выполняю я. конкретно эта база oracle XE, т.е. RLS там точно нет, но те же проблемы наблюдались и в другом офисе на 10.2.0.4 Standart edition. еще замечено, что проблема перемещается при пересборке исходников, т.е. до этого проблемы на этом запросе не было, но была на другом и теперь там рассосалась, а тут вылезла.
не тронутый моей цензурой кусок:

PARSING IN CURSOR #2 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245596741907715 hv=131164585 ad='407f047c'
select * from ( select party0_.ID as ID0_, party0_.CREATED_BY as CREATED3_0_, party0_.CREATED as CREATED0_, party0_.MODIFIED_BY as MODIFIED5_0_, party0_.MODIFIED as MODIFIED0_, party0_.IS_CLIENT as IS7_0_, party0_.CLIENT_CATEGORY_DATE as CLIENT8_0_, party0_.CLIENT_CATEGORY as CLIENT9_0_, party0_.CLIENT_CODE as CLIENT10_0_, party0_.CLIENT_COMMISSIONS as CLIENT11_0_, party0_.CLIENT_REGION_COMMISSIONS as CLIENT12_0_, party0_.CLIENT_PRIVATE_COMMISSIONS as CLIENT13_0_, party0_.CLIENT_PRIVATE_REG_COMMS as CLIENT14_0_, party0_.LEGAL_NAME as LEGAL15_0_, party0_.E_MAIL as E16_0_, party0_.FAX as FAX0_, party0_.PHONE as PHONE0_, party0_.WWW as WWW0_, party0_.FIRST_NAME as FIRST20_0_, party0_.LAST_NAME as LAST21_0_, party0_.LEG_STATUS_ID as LEG38_0_, party0_.ORIGIN_COUTRY_ID as ORIGIN39_0_, party0_.REGNO as REGNO0_, party0_.RISK_LEVEL as RISK23_0_, party0_.RISK_LEVEL_DATE as RISK24_0_, party0_.SOLVENCY as SOLVENCY0_, party0_.SOLVENCY_DATE as SOLVENCY26_0_, party0_.TRANSACTION_ID as TRANSAC27_0_, party0_.GENDER as GENDER0_, party0_.PASSPORT_ISSUE_DATE as PASSPORT29_0_, party0_.PERSON_PASSPORT_NR as PERSON30_0_, party0_.CERTIFICATE_CODE as CERTIFI31_0_, party0_.EDRPOU_CODE as EDRPOU32_0_, party0_.INN_CODE as INN33_0_, party0_.IS_BANK as IS34_0_, party0_.KPP_CODE as KPP35_0_, party0_.OGRN_CODE as OGRN36_0_, party0_.VATCODE as VATCODE0_, party0_.IS_LEGAL as IS1_0_ from PARTY_CARDS party0_ where party0_.ID=party0_.ID and (upper(party0_.LAST_NAME) like upper(:1) or upper(party0_.LEGAL_NAME) like upper(:2)) ) where rownum <= :3
END OF STMT
PARSE #2:c=0,e=78,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245596741907711
BINDS #2:
kkscoacd
Bind#0
oacdty=01 mxl=128(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=280 off=0
kxsbbbfp=f7af7590 bln=128 avl=07 flg=05
value="baltic%"
Bind#1
oacdty=01 mxl=128(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=0 off=128
kxsbbbfp=f7af7610 bln=128 avl=07 flg=01
value="baltic%"
Bind#2
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=01 csi=873 siz=0 off=256
kxsbbbfp=f7af7690 bln=22 avl=02 flg=01
value=50
EXEC #2:c=0,e=169,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245596741907945
FETCH #2:c=1000,e=785,p=0,cr=12,cu=0,mis=0,r=10,dep=0,og=1,tim=1245596741909445
FETCH #2:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1245596741919364
STAT #2 id=1 cnt=10 pid=0 pos=1 obj=0 op='COUNT STOPKEY (cr=12 pr=0 pw=0 time=1448 us)'
STAT #2 id=2 cnt=10 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL PARTY_CARDS (cr=12 pr=0 pw=0 time=1425 us)'


я правильно понимаю что строка
STAT #2 id=2 cnt=10 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL PARTY_CARDS (cr=12 pr=0 pw=0 time=1425 us)'
исключает причуды JDBC и хибера и говорит, что под условия выборки именно оптимизатор видит 10 записей ?
2 июн 10, 20:19    [8880755]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
dnater
именно оптимизатор видит 10 записей ?

Я Вам открою маленький секрет - оптимизатор вообще не видит записей, он работает с планом запроса и статистикой. Снимите 10053 - и подобные вопросы больше не появятся :)
То, что Вы видите в 10046 как STAT - это статистика фактического исполнения плана, выбранного оптимизатором для данного запроса.
И пользуйтесь пожалуйста тегом SRC.
2 июн 10, 20:36    [8880793]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
SRC растянет пост и будет только хуже, в 10053 ничего полезного не увидел. пересобрали апликуху, выставили в JDBC фетч = 15, теперь при "залипании" запрос выдает 15 записей:

*********************************
Апликуха FETCH=15 (после рестарта томката или базы)

PARSING IN CURSOR #2 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245613861744301 hv=3739417321 ad='3ea1f53c'
select * from ( select party0_.ID as ID0_, party0_.CREATED_BY as CREATED3_0_, party0_.CREATED as CREATED0_, party0_.MODIFIED_BY as MODIFIED5_0_, party0_.MODIFIED as MODIFIED0_, party0_.IS_CLIENT as IS7_0_, party0_.CLIENT_CATEGORY_DATE as CLIENT8_0_, party0_.CLIENT_CATEGORY as CLIENT9_0_, party0_.CLIENT_CODE as CLIENT10_0_, party0_.CLIENT_COMMISSIONS as CLIENT11_0_, party0_.CLIENT_REGION_COMMISSIONS as CLIENT12_0_, party0_.CLIENT_PRIVATE_COMMISSIONS as CLIENT13_0_, party0_.CLIENT_PRIVATE_REG_COMMS as CLIENT14_0_, party0_.LEGAL_NAME as LEGAL15_0_, party0_.E_MAIL as E16_0_, party0_.FAX as FAX0_, party0_.PHONE as PHONE0_, party0_.WWW as WWW0_, party0_.FIRST_NAME as FIRST20_0_, party0_.LAST_NAME as LAST21_0_, party0_.LEG_STATUS_ID as LEG39_0_, party0_.ORIGIN_COUTRY_ID as ORIGIN38_0_, party0_.REGNO as REGNO0_, party0_.RISK_LEVEL as RISK23_0_, party0_.RISK_LEVEL_DATE as RISK24_0_, party0_.SOLVENCY as SOLVENCY0_, party0_.SOLVENCY_DATE as SOLVENCY26_0_, party0_.TRANSACTION_ID as TRANSAC27_0_, party0_.GENDER as GENDER0_, party0_.PASSPORT_ISSUE_DATE as PASSPORT29_0_, party0_.PERSON_PASSPORT_NR as PERSON30_0_, party0_.CERTIFICATE_CODE as CERTIFI31_0_, party0_.EDRPOU_CODE as EDRPOU32_0_, party0_.INN_CODE as INN33_0_, party0_.IS_BANK as IS34_0_, party0_.KPP_CODE as KPP35_0_, party0_.OGRN_CODE as OGRN36_0_, party0_.VATCODE as VATCODE0_, party0_.IS_LEGAL as IS1_0_ from PARTY_CARDS party0_ where party0_.ID=party0_.ID and (upper(party0_.LAST_NAME) like upper(:1) or upper(party0_.LEGAL_NAME) like upper(:2)) ) where rownum <= :3
END OF STMT
PARSE #2:c=1000,e=95,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245613861744297
BINDS #2:
kkscoacd
Bind#0
oacdty=01 mxl=32(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=88 off=0
kxsbbbfp=f7b4d980 bln=32 avl=07 flg=05
value="baltic%"
Bind#1
oacdty=01 mxl=32(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=0 off=32
kxsbbbfp=f7b4d9a0 bln=32 avl=07 flg=01
value="baltic%"
Bind#2
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=01 csi=873 siz=0 off=64
kxsbbbfp=f7b4d9c0 bln=22 avl=02 flg=01
value=50
EXEC #2:c=0,e=167,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245613861744545
FETCH #2:c=1000,e=1210,p=0,cr=18,cu=0,mis=0,r=15,dep=0,og=1,tim=1245613861746815
FETCH #2:c=2999,e=2719,p=0,cr=36,cu=0,mis=0,r=15,dep=0,og=1,tim=1245613861763046
FETCH #2:c=2000,e=1931,p=0,cr=27,cu=0,mis=0,r=15,dep=0,og=1,tim=1245613861770523
FETCH #2:c=0,e=608,p=0,cr=9,cu=0,mis=0,r=5,dep=0,og=1,tim=1245613861776266
STAT #2 id=1 cnt=50 pid=0 pos=1 obj=0 op='COUNT STOPKEY (cr=90 pr=0 pw=0 time=7234 us)'
STAT #2 id=2 cnt=50 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL PARTY_CARDS (cr=90 pr=0 pw=0 time=7080 us)'

*********************************
Апликуха FETCH=15 => залипло

PARSING IN CURSOR #5 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245614117564665 hv=3739417321 ad='3ea1f53c'
select * from ( select party0_.ID as ID0_, party0_.CREATED_BY as CREATED3_0_, party0_.CREATED as CREATED0_, party0_.MODIFIED_BY as MODIFIED5_0_, party0_.MODIFIED as MODIFIED0_, party0_.IS_CLIENT as IS7_0_, party0_.CLIENT_CATEGORY_DATE as CLIENT8_0_, party0_.CLIENT_CATEGORY as CLIENT9_0_, party0_.CLIENT_CODE as CLIENT10_0_, party0_.CLIENT_COMMISSIONS as CLIENT11_0_, party0_.CLIENT_REGION_COMMISSIONS as CLIENT12_0_, party0_.CLIENT_PRIVATE_COMMISSIONS as CLIENT13_0_, party0_.CLIENT_PRIVATE_REG_COMMS as CLIENT14_0_, party0_.LEGAL_NAME as LEGAL15_0_, party0_.E_MAIL as E16_0_, party0_.FAX as FAX0_, party0_.PHONE as PHONE0_, party0_.WWW as WWW0_, party0_.FIRST_NAME as FIRST20_0_, party0_.LAST_NAME as LAST21_0_, party0_.LEG_STATUS_ID as LEG39_0_, party0_.ORIGIN_COUTRY_ID as ORIGIN38_0_, party0_.REGNO as REGNO0_, party0_.RISK_LEVEL as RISK23_0_, party0_.RISK_LEVEL_DATE as RISK24_0_, party0_.SOLVENCY as SOLVENCY0_, party0_.SOLVENCY_DATE as SOLVENCY26_0_, party0_.TRANSACTION_ID as TRANSAC27_0_, party0_.GENDER as GENDER0_, party0_.PASSPORT_ISSUE_DATE as PASSPORT29_0_, party0_.PERSON_PASSPORT_NR as PERSON30_0_, party0_.CERTIFICATE_CODE as CERTIFI31_0_, party0_.EDRPOU_CODE as EDRPOU32_0_, party0_.INN_CODE as INN33_0_, party0_.IS_BANK as IS34_0_, party0_.KPP_CODE as KPP35_0_, party0_.OGRN_CODE as OGRN36_0_, party0_.VATCODE as VATCODE0_, party0_.IS_LEGAL as IS1_0_ from PARTY_CARDS party0_ where party0_.ID=party0_.ID and (upper(party0_.LAST_NAME) like upper(:1) or upper(party0_.LEGAL_NAME) like upper(:2)) ) where rownum <= :3
END OF STMT
PARSE #5:c=0,e=61,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245614117564661
BINDS #5:
kkscoacd
Bind#0
oacdty=01 mxl=128(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=280 off=0
kxsbbbfp=f7b40354 bln=128 avl=07 flg=05
value="baltic%"
Bind#1
oacdty=01 mxl=128(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=0 off=128
kxsbbbfp=f7b403d4 bln=128 avl=07 flg=01
value="baltic%"
Bind#2
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=01 csi=873 siz=0 off=256
kxsbbbfp=f7b40454 bln=22 avl=02 flg=01
value=50
EXEC #5:c=0,e=168,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245614117564913
FETCH #5:c=1000,e=1222,p=0,cr=18,cu=0,mis=0,r=15,dep=0,og=1,tim=1245614117566785
FETCH #5:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1245614117570685
STAT #5 id=1 cnt=15 pid=0 pos=1 obj=0 op='COUNT STOPKEY (cr=18 pr=0 pw=0 time=2179 us)'
STAT #5 id=2 cnt=15 pid=1 pos=1 obj=60812 op='TABLE ACCESS FULL PARTY_CARDS (cr=18 pr=0 pw=0 time=2132 us)'

*******************************************
параллельно залипнувшей апликухи SQLDEVELOPER (FETCH выставил 17)

PARSING IN CURSOR #2 len=1534 dep=0 uid=42 oct=3 lid=42 tim=1245614442404354 hv=131164585 ad='451514e0'
select * from ( select party0_.ID as ID0_, party0_.CREATED_BY as CREATED3_0_, party0_.CREATED as CREATED0_, party0_.MODIFIED_BY as MODIFIED5_0_, party0_.MODIFIED as MODIFIED0_, party0_.IS_CLIENT as IS7_0_, party0_.CLIENT_CATEGORY_DATE as CLIENT8_0_, party0_.CLIENT_CATEGORY as CLIENT9_0_, party0_.CLIENT_CODE as CLIENT10_0_, party0_.CLIENT_COMMISSIONS as CLIENT11_0_, party0_.CLIENT_REGION_COMMISSIONS as CLIENT12_0_, party0_.CLIENT_PRIVATE_COMMISSIONS as CLIENT13_0_, party0_.CLIENT_PRIVATE_REG_COMMS as CLIENT14_0_, party0_.LEGAL_NAME as LEGAL15_0_, party0_.E_MAIL as E16_0_, party0_.FAX as FAX0_, party0_.PHONE as PHONE0_, party0_.WWW as WWW0_, party0_.FIRST_NAME as FIRST20_0_, party0_.LAST_NAME as LAST21_0_, party0_.LEG_STATUS_ID as LEG38_0_, party0_.ORIGIN_COUTRY_ID as ORIGIN39_0_, party0_.REGNO as REGNO0_, party0_.RISK_LEVEL as RISK23_0_, party0_.RISK_LEVEL_DATE as RISK24_0_, party0_.SOLVENCY as SOLVENCY0_, party0_.SOLVENCY_DATE as SOLVENCY26_0_, party0_.TRANSACTION_ID as TRANSAC27_0_, party0_.GENDER as GENDER0_, party0_.PASSPORT_ISSUE_DATE as PASSPORT29_0_, party0_.PERSON_PASSPORT_NR as PERSON30_0_, party0_.CERTIFICATE_CODE as CERTIFI31_0_, party0_.EDRPOU_CODE as EDRPOU32_0_, party0_.INN_CODE as INN33_0_, party0_.IS_BANK as IS34_0_, party0_.KPP_CODE as KPP35_0_, party0_.OGRN_CODE as OGRN36_0_, party0_.VATCODE as VATCODE0_, party0_.IS_LEGAL as IS1_0_ from PARTY_CARDS party0_ where party0_.ID=party0_.ID and (upper(party0_.LAST_NAME) like upper(:1) or upper(party0_.LEGAL_NAME) like upper(:2)) ) where rownum <= :3
END OF STMT
PARSE #2:c=0,e=67,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245614442404350
BINDS #2:
kkscoacd
Bind#0
oacdty=01 mxl=32(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=96 off=0
kxsbbbfp=f7af2b4c bln=32 avl=07 flg=05
value="baltic%"
Bind#1
oacdty=01 mxl=32(28) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=0 off=32
kxsbbbfp=f7af2b6c bln=32 avl=07 flg=01
value="baltic%"
Bind#2
oacdty=01 mxl=32(08) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=873 siz=0 off=64
kxsbbbfp=f7af2b8c bln=32 avl=02 flg=01
value="50"
EXEC #2:c=0,e=175,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1245614442404589
FETCH #2:c=2000,e=1702,p=0,cr=22,cu=0,mis=0,r=17,dep=0,og=1,tim=1245614442569675
FETCH #2:c=3000,e=3144,p=0,cr=40,cu=0,mis=0,r=17,dep=0,og=1,tim=1245614443673431
FETCH #2:c=1999,e=2130,p=0,cr=27,cu=0,mis=0,r=16,dep=0,og=1,tim=1245614444172148

чем все таки можно объяснить r=0 во втором фетче при залипании апликухи ?
3 июн 10, 00:27    [8881506]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7424
dnater,

OPTIMIZER_MODE во что выставлено?
3 июн 10, 00:45    [8881572]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
bash-3.2$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Jun 2 23:48:22 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> connect /as sysdba
Connected.
SQL> show parameter OPTIMIZER_MODE ;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
optimizer_mode string ALL_ROWS
3 июн 10, 00:57    [8881597]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
Jonathan Lewis
Guest
как мысль
3 июн 10, 01:38    [8881654]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
> чем все таки можно объяснить r=0 во втором фетче при залипании апликухи?

There is a theory explaining the experienced behavior. I guess it has nothing to do with the SELECT statement itself. Most probably the data in the table got deleted but the transaction has not been committed e.g. due to the problems with the error handling. Therefore you would be able to see old data in any newly fetched connection (seeing the old snapshot of the data); same is true if you do the same operation from SQLDEVELOPER. However, when the problematic connection is fetched and the SELECT is performed nothing is returned back. The very same theory can also cover the case of "залипание"... the application is stuck because the connection pool is exhausted because i.e. all connections are in use and probably waiting for the bad one to release the resources. Check v$lock and make sure that there is no TX leak. A couple of stack traces and heap dumps (on the client side) would help to get a bit more clear picture.
3 июн 10, 07:14    [8881780]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
Timur Akhmadeev
Member

Откуда:
Сообщений: 510
Запостите
connection#getMetaData()#getDriverVersion()
3 июн 10, 10:28    [8882623]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
транзакций модифицирующих имя или удаляющих записи в системе точно нет. это справочник компаний/клиентов, причем через аппликуху удалить такие карточки нельзя.
getDriverVersion спрошу у программера.
3 июн 10, 11:09    [8883124]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
На 10.2.0.4 пока не получается воспроизвести.
Приложите пожалуйста полный трейс - может, там что найдем...
3 июн 10, 11:42    [8883476]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
-2-
Member

Откуда:
Сообщений: 15330
Больше похоже на "особенности" работы с курсором в приложении. Что-то можно порыскать в коде.
3 июн 10, 11:49    [8883544]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
-2-
Больше похоже на "особенности" работы с курсором в приложении. Что-то можно порыскать в коде.

Не моделируется - r=0 не удается получить.
Разве что попробовать как-то между fetch-ами перепутать подключения... Но как конкретно подобное сделать - идей пока нет :)
3 июн 10, 11:53    [8883584]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
DВА
Member

Откуда:
Сообщений: 5439
Bug 5686711 Wrong cursor may be executed if schemas have objects with same names
3 июн 10, 12:13    [8883794]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
DВА
Bug 5686711 Wrong cursor may be executed if schemas have objects with same names


может кто-то скинет текст на ono (at) inbox (dot) lv
на 10.2.0.2 я точно фифект наблюдал, а вот 10.2.0.4 теперь начинаю сомневаться. но блин на XE патч же не поставишь ...

и еще, кто-то может объяснить такое:
SQL> select count(debt0_.ID) as col_0_0_ from DEBTS debt0_, PARTY_CARDS party1_ where debt0_.CLIENT_ID=party1_.ID and debt0_.ID=debt0_.ID and upper(party1_.REGNO)=upper('40003800940') ;

  COL_0_0_
----------
         2

SQL> select count(debt0_.ID) as col_0_0_ from DEBTS debt0_, PARTY_CARDS party1_ where debt0_.CLIENT_ID=party1_.ID and upper(party1_.REGNO)=upper('40003800940') ;

  COL_0_0_
----------
         0


разница в "and debt0_.ID=debt0_.ID"
3 июн 10, 12:21    [8883888]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
PS. Driver name: Oracle JDBC driver, version: 10.2.0.4.0
3 июн 10, 12:28    [8883963]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
DВА
Member

Откуда:
Сообщений: 5439
скидывать там нечего, если ли в базе одноименные объекты в разных схемах, например ваша табличка PARTY_CARDS ?
если нет, то не оно
3 июн 10, 12:29    [8883977]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
dnater
Guest
DВА
скидывать там нечего, если ли в базе одноименные объекты в разных схемах, например ваша табличка PARTY_CARDS ?
если нет, то не оно


похоже не мое
bash-3.2$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Jun 3 11:25:41 2010

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SQL> connect /as sysdba
Connected.
SQL> select count(*) from ALL_CATALOG where  table_name='PARTY_CARDS' ;

  COUNT(*)
----------
         1
3 июн 10, 12:38    [8884080]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
--Попрошайка--
Member

Откуда: АО "Попрошайка".
Сообщений: 13709
Блог
Смотри, как правильные парни делают, которые хотят уважать форумчан:

SELECT COUNT (debt0_.ID) AS col_0_0_
  FROM debts debt0_, party_cards party1_
 WHERE debt0_.client_id = party1_.ID
   AND debt0_.ID = debt0_.ID
   AND UPPER (party1_.regno) = UPPER ('40003800940');

  COL_0_0_
----------
         2

SELECT COUNT (debt0_.ID) AS col_0_0_
  FROM debts debt0_, party_cards party1_
 WHERE debt0_.client_id = party1_.ID
   AND UPPER (party1_.regno) = UPPER ('40003800940');

  COL_0_0_
----------
         0
3 июн 10, 13:05    [8884356]     Ответить | Цитировать Сообщить модератору
 Re: необработанный trace файл, что значит FETCH с r=0 ?  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
dnater
разница в "and debt0_.ID=debt0_.ID"

Это условие воспринимается оптимизатором как "debt0_.ID is not null"
Посмотрите планы в первом и втором случаях.
Если поменялся access path - к примеру, на индексный, то вероятна проблема с индексом - в этом случае поможет
alter index ... rebuild online
3 июн 10, 13:10    [8884391]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить