Медленное выполнение запроса
На страницу Пред. 1, 2
|
Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
e.kha Участник со стажем
Вступление в Клуб: 26.04.2012
|
Чт Сен 19, 2013 09:27   |
|
Полезность: Нет оценки
|
а где такое выполнить? с помощью чего? |
|
![](templates/subSilver/images/spacer.gif) |
Damir Участник - экстремал
Вступление в Клуб: 29.03.2013
|
Чт Сен 19, 2013 09:53   |
|
Полезность: Нет оценки
|
Random пишет: | Профит в том, что выполнение запроса осуществляется только 1 раз.
Попробуй.
|
Привет, Random.
достаточно распространенный прием в цфт-системе - я уже заметил.
такие вот кэши забивают PGA, на мой взгляд.
после вызова 1 такой функции (из отчета) остается кэш (коллекция) и фисит до конца сессии.
Конечно, можно сбрасывать кэш - после отработки запроса вызывать функцию очистки, но этим никто не заморачивается.
Про PGA что-нить скажи - меня больше этот вопрос волнует.
PS: если кэш не очищать перед выполнением запроса, то перечитывание данных не произойдет. Запустили отчет - не понравился - поправили документ. После повторного запуска отчета (в той же сессии) половина данных выберется запросом с диска, а часть - с кэша. |
|
![](templates/subSilver/images/spacer.gif) |
Damir Участник - экстремал
Вступление в Клуб: 29.03.2013
|
Чт Сен 19, 2013 10:09   |
|
Полезность: Нет оценки
|
maestro пишет: | Странно, что у него стоимость больше. Интересно, что статистика говорит? Выполни plz запросы в SQLplus, как я писал выше. |
Ничего странного.
Ща умное слово скажу, которое сам плохо понимаю - селективность.
Т.е. сильно зависит от
1) размеров таблиц 1 и 2.
2) от селективности индексов (насколько хорошо они фильтруют записи).
3) в конце-концов от размера записи в таблицах 1 и 2. |
|
![](templates/subSilver/images/spacer.gif) |
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 использовать.. |
Ладно, не понял, так не понял.
А про локейт вообще забудь и никогда не используй. никакой пользы, кроме вреда ![Sad](images/smiles/icon_sad.gif) |
|
![](templates/subSilver/images/spacer.gif) |
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, в функции чисть переменные. Приседания, да, а кому легко? |
|
![](templates/subSilver/images/spacer.gif) |
devor Профи
Вступление в Клуб: 13.02.2012
|
Чт Сен 19, 2013 12:19   |
|
Полезность: 2
|
Random пишет: |
Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима
|
Еще как применима и отлично работает.
Random пишет: |
Damir пишет: |
Конечно, можно сбрасывать кэш - после отработки запроса вызывать функцию очистки, но этим никто не заморачивается.
| Вот-вот. А казалось бы, dbms_session.reset_package и всё, так нет...
|
Нормально все с этим.
Вся ИБСа утыкана utils.free_memory
Сбрасывать состояния пакетов для очистки памяти - это как из пушки по воробьям. Да и не чистится память сессии от этого. |
|
![](templates/subSilver/images/spacer.gif) |
Random Эксперт
Вступление в Клуб: 27.06.2011
|
Пт Сен 20, 2013 05:50   |
|
Полезность: Нет оценки
|
devor пишет: | Random пишет: |
Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима
|
Еще как применима и отлично работает.
|
Хм... Щас попробовал - всё пока хорошо.
Похоже, ядерщики наши устраняют потихоньку проблемы. А вот год-два назад что-то у меня не получилось.
Спасибо. А то б этот инструмент остался бы втуне ![Smile](images/smiles/icon_smile.gif) |
|
![](templates/subSilver/images/spacer.gif) |
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 |
|
![](templates/subSilver/images/spacer.gif) |
devor Профи
Вступление в Клуб: 13.02.2012
|
Пт Сен 20, 2013 08:05   |
|
Полезность: Нет оценки
|
Random пишет: | devor пишет: | Random пишет: |
Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима
|
Еще как применима и отлично работает.
|
Хм... Щас попробовал - всё пока хорошо.
Похоже, ядерщики наши устраняют потихоньку проблемы. А вот год-два назад что-то у меня не получилось.
Спасибо. А то б этот инструмент остался бы втуне ![Smile](images/smiles/icon_smile.gif) |
Ну не знаю насчет ядерщиков. В дистрибутиве очень давно используется. Как минимум с 2008 года, а может и раньше. |
|
![](templates/subSilver/images/spacer.gif) |
maestro Профи
Вступление в Клуб: 12.10.2010
|
Пт Сен 20, 2013 08:44   |
|
Полезность: Нет оценки
|
Damir пишет: | maestro пишет: | Странно, что у него стоимость больше. Интересно, что статистика говорит? Выполни plz запросы в SQLplus, как я писал выше. |
Ничего странного.
Ща умное слово скажу, которое сам плохо понимаю - селективность.
|
Селективными в обоих случаях являются 2 столбца, Field_Value и Field_name. Т.е. кардиналити - одинаковый.
Я подозреваю, что 2й запрос выполнялся раньше первого, и имеет место ораклоовый кеш.
Поэтому и попросил статистику. |
|
![](templates/subSilver/images/spacer.gif) |
maestro Профи
Вступление в Клуб: 12.10.2010
|
Пт Сен 20, 2013 08:48   |
|
Полезность: Нет оценки
|
e.kha пишет: | а где такое выполнить? с помощью чего? |
В папке bin есть файл sqlplusw.exe
У меня путь такой: c:\oracle\ora92\bin\sqlplusw.exe
Либо: Пуск->Программы->Oracle->SQLplus.
Там вводишь логин, пароль, и алиас схемы.
Затем тот код, что я писал...
В результате получишь план и статистику операций, которые выполнял Оракл (физические/логические чтения, рекурсивные вызовы и т.п.).
По этой статистике можно четко сказать какой запрос лучше!
Кост же не всегда отражает реальную картину. |
|
![](templates/subSilver/images/spacer.gif) |
Random Эксперт
Вступление в Клуб: 27.06.2011
|
Пн Сен 23, 2013 06:16   |
|
Полезность: Нет оценки
|
devor пишет: | Ну не знаю насчет ядерщиков. В дистрибутиве очень давно используется. Как минимум с 2008 года, а может и раньше. |
Нашёл две операции, в которых использование pragma SERIALLY_REUSABLE началось в 6-м году. Третья операция, использующая эту прагму, написана в 12-м.
Странно, почему у меня не получилось... Видимо, потому что использовал в библиотеке, которая использовалась из операций, то и дело переходящих из ACTIVE в INACTIVE и обратно.
Короче, не всё с этой прагмой гладко. |
|
![](templates/subSilver/images/spacer.gif) |
Эмиралька Эксперт
Вступление в Клуб: 09.11.2015
|
Чт Июн 08, 2017 12:52   |
|
Полезность: Нет оценки
|
Random пишет: | Короче, не всё с этой прагмой гладко. |
Говорят, что при большой нагрузке операция с данной прагмой виснет. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
|
|