Медленное выполнение запроса
На страницу Пред. 1, 2
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
e.kha
Участник со стажем
Вступление в Клуб: 26.04.2012
|
 Чт Сен 19, 2013 09:27 |
 |
Полезность: Нет оценки
|
| а где такое выполнить? с помощью чего? |
|
 |
Damir
Участник - экстремал
Вступление в Клуб: 29.03.2013
|
| Чт Сен 19, 2013 09:53 |
|
Полезность: Нет оценки
|
| Random пишет: | Профит в том, что выполнение запроса осуществляется только 1 раз.
Попробуй.
|
Привет, Random.
достаточно распространенный прием в цфт-системе - я уже заметил.
такие вот кэши забивают PGA, на мой взгляд.
после вызова 1 такой функции (из отчета) остается кэш (коллекция) и фисит до конца сессии.
Конечно, можно сбрасывать кэш - после отработки запроса вызывать функцию очистки, но этим никто не заморачивается.
Про PGA что-нить скажи - меня больше этот вопрос волнует.
PS: если кэш не очищать перед выполнением запроса, то перечитывание данных не произойдет. Запустили отчет - не понравился - поправили документ. После повторного запуска отчета (в той же сессии) половина данных выберется запросом с диска, а часть - с кэша. |
|
|
Damir
Участник - экстремал
Вступление в Клуб: 29.03.2013
|
| Чт Сен 19, 2013 10:09 |
|
Полезность: Нет оценки
|
| maestro пишет: | | Странно, что у него стоимость больше. Интересно, что статистика говорит? Выполни plz запросы в SQLplus, как я писал выше. |
Ничего странного.
Ща умное слово скажу, которое сам плохо понимаю - селективность.
Т.е. сильно зависит от
1) размеров таблиц 1 и 2.
2) от селективности индексов (насколько хорошо они фильтруют записи).
3) в конце-концов от размера записи в таблицах 1 и 2. |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Чт Сен 19, 2013 11:10 |
|
Полезность: Нет оценки
|
| e.kha пишет: | | Random пишет: | Хотя... количество записей | Код: | select a(count(1))
in ::[TBL_ONE], ([TBL_TWO] all : b ) all
where b.[FIELD_NAME] = 'DOC_ID' and
-- b.[FIELD_VALUE] = doc_id and
b%collection = a.[FIELD_ARR] |
можешь сказать? |
В в каждой коллекции где то 30 записей,
этот селект выбирает только один результат,
наверно корректней тут locate использовать.. |
Ладно, не понял, так не понял.
А про локейт вообще забудь и никогда не используй. никакой пользы, кроме вреда  |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Чт Сен 19, 2013 11:23 |
|
Полезность: Нет оценки
|
| Damir пишет: | | Random пишет: | Профит в том, что выполнение запроса осуществляется только 1 раз.
Попробуй.
|
Привет, Random.
достаточно распространенный прием в цфт-системе - я уже заметил.
такие вот кэши забивают PGA, на мой взгляд.
|
Привет  Эмпирически - если табличка больше миллиона записей, не стоит её засасывать в память.
Приём хороший, почему б его и не использовать
| Damir пишет: | после вызова 1 такой функции (из отчета) остается кэш (коллекция) и фисит до конца сессии.
|
Да знаю. Необходимое зло. Стоило бы чистить кэши после себя, но кто б этим заморачивался.
Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима
| Damir пишет: |
Конечно, можно сбрасывать кэш - после отработки запроса вызывать функцию очистки, но этим никто не заморачивается.
|
Вот-вот. А казалось бы, dbms_session.reset_package и всё, так нет...
| Damir пишет: |
Про PGA что-нить скажи - меня больше этот вопрос волнует.
|
Ваще ничего не знаю.
| Damir пишет: | | PS: если кэш не очищать перед выполнением запроса, то перечитывание данных не произойдет. Запустили отчет - не понравился - поправили документ. После повторного запуска отчета (в той же сессии) половина данных выберется запросом с диска, а часть - с кэша. |
При запуске отчёта вызывай функцию init, в функции чисть переменные. Приседания, да, а кому легко? |
|
|
devor
Профи
Вступление в Клуб: 13.02.2012
|
| Чт Сен 19, 2013 12:19 |
|
Полезность: 2
|
| Random пишет: |
Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима
|
Еще как применима и отлично работает.
| Random пишет: |
| Damir пишет: |
Конечно, можно сбрасывать кэш - после отработки запроса вызывать функцию очистки, но этим никто не заморачивается.
|
Вот-вот. А казалось бы, dbms_session.reset_package и всё, так нет...
|
Нормально все с этим.
Вся ИБСа утыкана utils.free_memory
Сбрасывать состояния пакетов для очистки памяти - это как из пушки по воробьям. Да и не чистится память сессии от этого. |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Пт Сен 20, 2013 05:50 |
|
Полезность: Нет оценки
|
| devor пишет: | | Random пишет: |
Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима
|
Еще как применима и отлично работает.
|
Хм... Щас попробовал - всё пока хорошо.
Похоже, ядерщики наши устраняют потихоньку проблемы. А вот год-два назад что-то у меня не получилось.
Спасибо. А то б этот инструмент остался бы втуне |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Пт Сен 20, 2013 05:57 |
|
Полезность: Нет оценки
|
| devor пишет: | | Random пишет: |
| Damir пишет: |
Конечно, можно сбрасывать кэш - после отработки запроса вызывать функцию очистки, но этим никто не заморачивается.
|
Вот-вот. А казалось бы, dbms_session.reset_package и всё, так нет...
|
Нормально все с этим.
Вся ИБСа утыкана utils.free_memory
Сбрасывать состояния пакетов для очистки памяти - это как из пушки по воробьям. Да и не чистится память сессии от этого. |
utils.free_memory = dbms_session.free_unused_user_memory;
Возможно, я ошибся. reset_package для другого применяется.
Цитата:
Если сеанс выполнит операции, которые выделяют большой объем памяти в PGA или UGA, то эта память не будет возвращена до разъединений сеанса. Поскольку сеансы в соединении объединяются в пул, это может представлять проблему, если ими не управляют должным образом. Как понятно из названия, процедура FREE_UNUSED_USER_MEMORY, доступная начиная с Oracle 7, освобождает неиспользованную память в сеансе.
| Код: | CONN / AS SYSDBA
GRANT SELECT ON v_$mystat TO test;
GRANT SELECT ON v_$statname TO test;
CONN test/test
-- Create a package with a collection as a package variable.
CREATE OR REPLACE PACKAGE p1 AS
FUNCTION get_pga_size RETURN NUMBER;
PROCEDURE populate_tab;
PROCEDURE empty_tab;
END p1;
/
CREATE OR REPLACE PACKAGE BODY p1 AS
TYPE t_tab IS TABLE OF all_objects%ROWTYPE;
g_tab t_tab;
FUNCTION get_pga_size RETURN NUMBER AS
l_number NUMBER;
BEGIN
SELECT ms.value
INTO l_number
FROM v$mystat ms
JOIN v$statname sn ON sn.statistic# = ms.statistic#
WHERE sn.name = 'session pga memory';
RETURN l_number;
END get_pga_size;
PROCEDURE populate_tab AS
BEGIN
SELECT *
BULK COLLECT INTO g_tab
FROM all_objects;
END populate_tab;
PROCEDURE empty_tab AS
BEGIN
g_tab.delete;
END empty_tab;
END p1;
/
-- Check the current PGA size.
SELECT p1.get_pga_size FROM dual;
GET_PGA_SIZE
------------
3416168
SQL>
-- Populate the collection and retest.
EXEC p1.populate_tab;
SELECT p1.get_pga_size FROM dual;
GET_PGA_SIZE
------------
42279016
SQL>
-- Empty the collection and retest.
EXEC p1.empty_tab;
SELECT p1.get_pga_size FROM dual;
GET_PGA_SIZE
------------
42279016
SQL>
-- Free unused memory and retest.
EXEC DBMS_SESSION.reset_package;
SELECT p1.get_pga_size FROM dual;
GET_PGA_SIZE
------------
3285096
SQL> |
отсюда: http://www.deepedit.ru/dbmssession-upravlenie-sessiyami-v-oracle-databases.html |
|
|
devor
Профи
Вступление в Клуб: 13.02.2012
|
| Пт Сен 20, 2013 08:05 |
|
Полезность: Нет оценки
|
| Random пишет: | | devor пишет: | | Random пишет: |
Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима
|
Еще как применима и отлично работает.
|
Хм... Щас попробовал - всё пока хорошо.
Похоже, ядерщики наши устраняют потихоньку проблемы. А вот год-два назад что-то у меня не получилось.
Спасибо. А то б этот инструмент остался бы втуне |
Ну не знаю насчет ядерщиков. В дистрибутиве очень давно используется. Как минимум с 2008 года, а может и раньше. |
|
|
maestro
Профи
Вступление в Клуб: 12.10.2010
|
| Пт Сен 20, 2013 08:44 |
|
Полезность: Нет оценки
|
| Damir пишет: | | maestro пишет: | | Странно, что у него стоимость больше. Интересно, что статистика говорит? Выполни plz запросы в SQLplus, как я писал выше. |
Ничего странного.
Ща умное слово скажу, которое сам плохо понимаю - селективность.
|
Селективными в обоих случаях являются 2 столбца, Field_Value и Field_name. Т.е. кардиналити - одинаковый.
Я подозреваю, что 2й запрос выполнялся раньше первого, и имеет место ораклоовый кеш.
Поэтому и попросил статистику. |
|
|
maestro
Профи
Вступление в Клуб: 12.10.2010
|
| Пт Сен 20, 2013 08:48 |
|
Полезность: Нет оценки
|
| e.kha пишет: | | а где такое выполнить? с помощью чего? |
В папке bin есть файл sqlplusw.exe
У меня путь такой: c:\oracle\ora92\bin\sqlplusw.exe
Либо: Пуск->Программы->Oracle->SQLplus.
Там вводишь логин, пароль, и алиас схемы.
Затем тот код, что я писал...
В результате получишь план и статистику операций, которые выполнял Оракл (физические/логические чтения, рекурсивные вызовы и т.п.).
По этой статистике можно четко сказать какой запрос лучше!
Кост же не всегда отражает реальную картину. |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Пн Сен 23, 2013 06:16 |
|
Полезность: Нет оценки
|
| devor пишет: | | Ну не знаю насчет ядерщиков. В дистрибутиве очень давно используется. Как минимум с 2008 года, а может и раньше. |
Нашёл две операции, в которых использование pragma SERIALLY_REUSABLE началось в 6-м году. Третья операция, использующая эту прагму, написана в 12-м.
Странно, почему у меня не получилось... Видимо, потому что использовал в библиотеке, которая использовалась из операций, то и дело переходящих из ACTIVE в INACTIVE и обратно.
Короче, не всё с этой прагмой гладко. |
|
|
Эмиралька
Эксперт
Вступление в Клуб: 09.11.2015
|
| Чт Июн 08, 2017 12:52 |
|
Полезность: Нет оценки
|
| Random пишет: | | Короче, не всё с этой прагмой гладко. |
Говорят, что при большой нагрузке операция с данной прагмой виснет. |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
