powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / Oracle.DataAccess.Client и latch: cache buffers chains
7 сообщений из 7, страница 1 из 1
Oracle.DataAccess.Client и latch: cache buffers chains
    #36865603
Korneychuk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вот, решился все таки спросить здесь.
Написал пакет, который делает слияние 4х выборок. Пока не суть.
Компилируется.
Запускается и отрабатывает из PLSqlDeveloper и toad.
Но стоит сделать выборку из .net - появляется latch: cache buffers chains.
Грешил было на пакетные функции, но нет же - исполняются.
Изначально использовался System.Data.OracleClient, затем родной Oracle.DataAccess.Client.
И самое неприятное - на тестовом сервере выборки проходят идеально.
Кто подскажет, в какую хоть сторону копать? Оговорюсь - я не супер знаток Oracle.
...
Рейтинг: 0 / 0
Oracle.DataAccess.Client и latch: cache buffers chains
    #36868163
-=APS=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не совсем понятно, в чем суть вопроса. Вас смущает появление latches, их количество или что-то другое? Или у вас возникает какая-то ошибка? Что означает ваша фраза "на тестовом сервере выборки проходят идеально" - вообще нет latches? Или их меньше? Или ваши запросы выполняются быстрее, чем на боевой? А что, у вас объемы данных и нагрузка на боевой и тестовой линиях абсолютно идентичны?

Т.е., по столь скудной информации, предоставленной вами, вряд ли кто-то сможет подсказать что-либо внятное. Смотрю, и на форуме Oracle вашим сообщением пока не заинтересовались :) Ибо вопрос поставлен в стиле "У меня в программе ошибка. Как исправить?" :)
...
Рейтинг: 0 / 0
Oracle.DataAccess.Client и latch: cache buffers chains
    #36869534
Korneychuk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
-=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.
WITH ranges AS
   (SELECT idxs.idx idx,
           n.id id,
           n.operator_id operator_id,
           n.area_go_id area_go_id,
           n.region_go_id region_go_id,
           n.status_id status_id,
           (least(n.range_end_full, idxs.re) - greatest(n.range_begin_full, idxs.rb) + 1) volume,
           n.numeration numeration
    FROM   ar_ranges n
    INNER  JOIN (SELECT to_number(v_range || lpad(to_char(LEVEL - 1), 2, '0')) idx,
                       rpad(v_range || lpad(to_char(LEVEL - 1), 2, '0'), 9, '0') rb,
                       rpad(v_range || lpad(to_char(LEVEL - 1), 2, '0'), 9, '9') re
                FROM   dual
                CONNECT BY LEVEL < 101) idxs
    ON     n.range_begin_full <= idxs.re AND n.range_end_full >= idxs.rb AND ((n.status_id < 5) OR (n.status_id = 7)) AND
           n.area_go_id <> 0)
  SELECT navigation_table_row(0,
                              3,
                              v_abc,
                              0,
                              0,
                              0,
                              0,
                              0,
                              0,
                              substr(fr.frtype, 0, 2000),
                              substr(num.numeration, 0, 2000),
                              substr(area.regions, 0, 2000),
                              0,
                              0,
                              0,
                              0,
                              CASE
                               WHEN (statuses.states IS NOT NULL) OR (ops.operators IS NOT NULL) THEN
                                substr(statuses.states || '<!SEPARATOR!>' || ops.operators, 0, 2000)
                               ELSE
                                ''
                              END) BULK COLLECT
  INTO   records
  FROM   (SELECT to_number(v_range || lpad(to_char(LEVEL - 1), 2, '0')) idx FROM dual CONNECT BY LEVEL < 101) rg
  LEFT   JOIN (SELECT idx, ltrim(MAX(sys_connect_by_path(region_go_id, '<!COMA!>')), '<!COMA!>') regions
               FROM   (SELECT rownum rn, idx, (region_go_id || '=' || g.short_name) region_go_id
                       FROM   (SELECT n.idx idx, n.area_go_id region_go_id, COUNT(*) c
                               FROM   ranges n
                               GROUP  BY n.idx, n.area_go_id
                               ORDER  BY n.idx, n.area_go_id) states
                       INNER  JOIN ref_geographic_units g
                       ON     g.id = states.region_go_id)
               CONNECT BY idx = PRIOR idx AND rn = PRIOR rn - 1
               GROUP  BY idx) area
  ON     area.idx = rg.idx
  LEFT   JOIN (SELECT idx, ltrim(MAX(sys_connect_by_path(state, ';')), ';') states
               FROM   (SELECT rownum rn, idx, state
                       FROM   (SELECT n.idx idx, to_char(n.status_id) || '=' || SUM(n.volume) state
                               FROM   ranges n
                               GROUP  BY n.idx, n.status_id
                               ORDER  BY n.idx, n.status_id

                               ) states)
               CONNECT BY idx = PRIOR idx AND rn = PRIOR rn - 1
               GROUP  BY idx) statuses
  ON     statuses.idx = rg.idx
  LEFT   JOIN (SELECT idx, ltrim(MAX(sys_connect_by_path(frtype, ';')), ';') frtype
               FROM   (SELECT rownum rn,
                              idx,
                              CASE
                               WHEN frtype = 2 THEN
                                'А'
                               ELSE
                                'Ц'
                              END frtype
                       FROM   (SELECT n.idx idx, f.fragment_type frtype
                               FROM   ranges n
                               INNER  JOIN ar_ranges_fragments f
                               ON     n.id = f.id
                               WHERE  n.status_id = 7
                               GROUP  BY n.idx, f.fragment_type
                               ORDER  BY n.idx, f.fragment_type) states)
               CONNECT BY idx = PRIOR idx AND rn = PRIOR rn - 1
               GROUP  BY idx) fr
  ON     fr.idx = rg.idx
  LEFT   JOIN (SELECT idx, ltrim(MAX(sys_connect_by_path(numeration, ',')), ',') numeration
               FROM   (SELECT rownum rn, idx, numeration
                       FROM   (SELECT n.idx idx, n.numeration numeration
                               FROM   ranges n
                               GROUP  BY n.idx, n.numeration
                               ORDER  BY n.idx, n.numeration

                               ) states)
               CONNECT BY idx = PRIOR idx AND rn = PRIOR rn - 1
               GROUP  BY idx) num
  ON     num.idx = rg.idx
  LEFT   JOIN (SELECT idx, ltrim(MAX(sys_connect_by_path(operators, '<!COMA!>')), '<!COMA!>') operators
               FROM   (SELECT rownum rn, idx, (operator_id || '=') operators
                       FROM   (SELECT n.idx idx, n.operator_id operator_id
                               FROM   ranges n
                               GROUP  BY n.idx, n.operator_id
                               ORDER  BY n.idx, n.operator_id

                               ) states)
               CONNECT BY idx = PRIOR idx AND rn = PRIOR rn - 1
               GROUP  BY idx) ops
  ON     ops.idx = rg.idx
  ORDER  BY rg.idx
...
Рейтинг: 0 / 0
Oracle.DataAccess.Client и latch: cache buffers chains
    #36870406
-=APS=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А чем в момент "подвисания" занимается сессия? Исполнением данного запроса? А трассировку снять пробовали? Было бы неплохо получить планы выполнения запросов, формируемые при запуске из-под PL/SQL Developer и сравнить с тем, что дает ODP - все-таки, совершенно разная среда...
Данные из пакетной функции (кстати, какую структуру она возвращает?) получаете с клиента каким образом - OracleReader/какой-либо ORM/еще что-нибудь? И еще по ходу вопрос - а почему эта логика размещена в пакетной функции, а не выставлена наружу через view - типа, там не все так тривиально?
"Внутренний голос" подсказывает, что, скорее всего, придется вплотную заняться адаптацией запроса (смущает такое количество иерархических запросов с группировками - хотя, понятное дело, тут что-либо сходу советовать трудно).
...
Рейтинг: 0 / 0
Oracle.DataAccess.Client и latch: cache buffers chains
    #36870648
Korneychuk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
-=APS=-,

в момент подвисания сессия занимается чтением из буффера (да, по данному запросу). Дождался 140 000 000 чтений и обрубил. Трассировку не синимал. планы запросов не должны отличаться, потому как конечный запрос вообще тривиален
Код: plaintext
1.
2.
3.
4.
5.
6.
SELECT nav_show_type_id,
       nav_service_type_id, nav_abc, nav_assigned_count, nav_planed_count,	
       nav_planed_requared_count, nav_equipped_count, nav_equipped_no_ass_count,
       nav_numbers_count, nav_fragment_string, nav_numeration_str, nav_title, 
       nav_abc_numeration, nav_ab_numeration, nav_ukrtelecom_count, 
       nav_operators_count, nav_statuses_str
FROM   TABLE(CAST(navigation.get_table('', 0, 0) AS navigation_table))
Вся логика внутри пакета. Данные из пакетной функции - Table of .. - ровно 100 строк. Логика такова, что подобных функций выполняется 5 штук, потом их результаты сливаются в конечную таблицу в зависимости от "типа строки"... там своя чехарда. Читается все DataReader. Иерархически запросы используются для того, чтобы развернуть результаты подзапросов в строки, хотя, конечно их можно немного оптимизировать.
Админы Oracle уже разводят руками, говорят, что вся проблема в .net, хотя я использовал разные провайдеры с одним и тем же результатом. Такое ощущение, что лажает именно сервер БД - для одного и того же запроса (функция пакета) строит разные планы. При этом план для запроса от .NET строится с какими-то бесконечными рекурсивными вызовами.
...
Рейтинг: 0 / 0
Oracle.DataAccess.Client и latch: cache buffers chains
    #36870790
-=APS=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так в том-то и дело, что нужно сравнить планы выполнения в разных средах именно внутреннего запроса.
А если попробовать (типа, с отчаяния :) ) поиграться с хинтами на этот длинный внутренний запрос?
...
Рейтинг: 0 / 0
Oracle.DataAccess.Client и latch: cache buffers chains
    #36870962
Korneychuk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
-=APS=-,
Завтра этим и буду заниматься))
Просто не пойму, почему такое разное поведение на один и тот же запрос. Думал, может, кто сталкивался с подобным.
...
Рейтинг: 0 / 0
7 сообщений из 7, страница 1 из 1
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / Oracle.DataAccess.Client и latch: cache buffers chains
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]