|
|
|
Oracle.DataAccess.Client и latch: cache buffers chains
|
|||
|---|---|---|---|
|
#18+
Вот, решился все таки спросить здесь. Написал пакет, который делает слияние 4х выборок. Пока не суть. Компилируется. Запускается и отрабатывает из PLSqlDeveloper и toad. Но стоит сделать выборку из .net - появляется latch: cache buffers chains. Грешил было на пакетные функции, но нет же - исполняются. Изначально использовался System.Data.OracleClient, затем родной Oracle.DataAccess.Client. И самое неприятное - на тестовом сервере выборки проходят идеально. Кто подскажет, в какую хоть сторону копать? Оговорюсь - я не супер знаток Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2010, 18:58 |
|
||
|
Oracle.DataAccess.Client и latch: cache buffers chains
|
|||
|---|---|---|---|
|
#18+
Не совсем понятно, в чем суть вопроса. Вас смущает появление latches, их количество или что-то другое? Или у вас возникает какая-то ошибка? Что означает ваша фраза "на тестовом сервере выборки проходят идеально" - вообще нет latches? Или их меньше? Или ваши запросы выполняются быстрее, чем на боевой? А что, у вас объемы данных и нагрузка на боевой и тестовой линиях абсолютно идентичны? Т.е., по столь скудной информации, предоставленной вами, вряд ли кто-то сможет подсказать что-либо внятное. Смотрю, и на форуме Oracle вашим сообщением пока не заинтересовались :) Ибо вопрос поставлен в стиле "У меня в программе ошибка. Как исправить?" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2010, 15:23 |
|
||
|
Oracle.DataAccess.Client и latch: cache buffers chains
|
|||
|---|---|---|---|
|
#18+
-=APS=-, Извините, не видел ответа. 1. Объемы данных на тестовой базе и проме абсолютно идентичны. 2. Пром - кластер из 8ми серверов, тест - один сервер. Нагрузка, конечно, разная, но можно найти момент простоев, поэтому можно считать, что одинакова. 3. На самом деле здесь тестовый или пром даже не суть. Вопрос в том, в чем может быть причина того, что при вызове функции пакета на проем, например, из plSQLDeveloper данные возвращаются, при тех же манипуляциях c использованием ODP появляется бесконечное ожидание цепочек со 100% загрузкой процессора. В сессии программно проставляется только формат даты. Замечено, что проблема появляется при использовании именованных подзапросов (WITH clouse). Просто наш DBA ушел в отпуск, а решать проблему нужно :) Пример запроса Код: plaintext 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. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2010, 11:35 |
|
||
|
Oracle.DataAccess.Client и latch: cache buffers chains
|
|||
|---|---|---|---|
|
#18+
А чем в момент "подвисания" занимается сессия? Исполнением данного запроса? А трассировку снять пробовали? Было бы неплохо получить планы выполнения запросов, формируемые при запуске из-под PL/SQL Developer и сравнить с тем, что дает ODP - все-таки, совершенно разная среда... Данные из пакетной функции (кстати, какую структуру она возвращает?) получаете с клиента каким образом - OracleReader/какой-либо ORM/еще что-нибудь? И еще по ходу вопрос - а почему эта логика размещена в пакетной функции, а не выставлена наружу через view - типа, там не все так тривиально? "Внутренний голос" подсказывает, что, скорее всего, придется вплотную заняться адаптацией запроса (смущает такое количество иерархических запросов с группировками - хотя, понятное дело, тут что-либо сходу советовать трудно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2010, 16:17 |
|
||
|
Oracle.DataAccess.Client и latch: cache buffers chains
|
|||
|---|---|---|---|
|
#18+
-=APS=-, в момент подвисания сессия занимается чтением из буффера (да, по данному запросу). Дождался 140 000 000 чтений и обрубил. Трассировку не синимал. планы запросов не должны отличаться, потому как конечный запрос вообще тривиален Код: plaintext 1. 2. 3. 4. 5. 6. Админы Oracle уже разводят руками, говорят, что вся проблема в .net, хотя я использовал разные провайдеры с одним и тем же результатом. Такое ощущение, что лажает именно сервер БД - для одного и того же запроса (функция пакета) строит разные планы. При этом план для запроса от .NET строится с какими-то бесконечными рекурсивными вызовами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2010, 17:44 |
|
||
|
Oracle.DataAccess.Client и latch: cache buffers chains
|
|||
|---|---|---|---|
|
#18+
Так в том-то и дело, что нужно сравнить планы выполнения в разных средах именно внутреннего запроса. А если попробовать (типа, с отчаяния :) ) поиграться с хинтами на этот длинный внутренний запрос? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2010, 18:38 |
|
||
|
|

start [/forum/topic.php?fid=17&gotonew=1&tid=1351060]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
148ms |
get topic data: |
7ms |
get first new msg: |
4ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 460ms |

| 0 / 0 |
