CftClub.ru
Клуб специалистов ЦФТ-Банк

Медленное выполнение запроса
На страницу Пред.  1, 2
 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Разработка в PL/PLUS. Оптимизация запросов Oracle
Предыдущая тема :: Следующая тема  
Автор Сообщение
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 использовать..

Ладно, не понял, так не понял.
А про локейт вообще забудь и никогда не используй. никакой пользы, кроме вреда Sad
Random
Эксперт


Вступление в Клуб: 27.06.2011
СообщениеЧт Сен 19, 2013 11:23    Ответить с цитатой
Полезность: Нет оценки
Damir пишет:
Random пишет:
Профит в том, что выполнение запроса осуществляется только 1 раз.
Попробуй.

Привет, Random.
достаточно распространенный прием в цфт-системе - я уже заметил.
такие вот кэши забивают PGA, на мой взгляд.
Привет Smile Эмпирически - если табличка больше миллиона записей, не стоит её засасывать в память.
Приём хороший, почему б его и не использовать Smile

Damir пишет:
после вызова 1 такой функции (из отчета) остается кэш (коллекция) и фисит до конца сессии.
Да знаю. Необходимое зло. Стоило бы чистить кэши после себя, но кто б этим заморачивался.
Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима Sad
Damir пишет:

Конечно, можно сбрасывать кэш - после отработки запроса вызывать функцию очистки, но этим никто не заморачивается.
Вот-вот. А казалось бы, dbms_session.reset_package и всё, так нет...

Damir пишет:

Про PGA что-нить скажи - меня больше этот вопрос волнует.
Ваще ничего не знаю.

Damir пишет:
PS: если кэш не очищать перед выполнением запроса, то перечитывание данных не произойдет. Запустили отчет - не понравился - поправили документ. После повторного запуска отчета (в той же сессии) половина данных выберется запросом с диска, а часть - с кэша.
При запуске отчёта вызывай функцию init, в функции чисть переменные. Приседания, да, а кому легко?
devor
Профи


Вступление в Клуб: 13.02.2012
СообщениеЧт Сен 19, 2013 12:19    Ответить с цитатой
Полезность: 2
Random пишет:

Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима Sad


Еще как применима и отлично работает.


Random пишет:

Damir пишет:

Конечно, можно сбрасывать кэш - после отработки запроса вызывать функцию очистки, но этим никто не заморачивается.
Вот-вот. А казалось бы, dbms_session.reset_package и всё, так нет...

Нормально все с этим.
Вся ИБСа утыкана utils.free_memory
Сбрасывать состояния пакетов для очистки памяти - это как из пушки по воробьям. Да и не чистится память сессии от этого.
Random
Эксперт


Вступление в Клуб: 27.06.2011
СообщениеПт Сен 20, 2013 05:50    Ответить с цитатой
Полезность: Нет оценки
devor пишет:
Random пишет:

Знаешь, я пытался поставить PRAGMA SERIALLY_REUSABLE, но платформа развития так устроена, что эта прагма вообще неприменима Sad


Еще как применима и отлично работает.


Хм... Щас попробовал - всё пока хорошо.
Похоже, ядерщики наши устраняют потихоньку проблемы. А вот год-два назад что-то у меня не получилось.

Спасибо. А то б этот инструмент остался бы втуне Smile
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, но платформа развития так устроена, что эта прагма вообще неприменима Sad


Еще как применима и отлично работает.


Хм... Щас попробовал - всё пока хорошо.
Похоже, ядерщики наши устраняют потихоньку проблемы. А вот год-два назад что-то у меня не получилось.

Спасибо. А то б этот инструмент остался бы втуне Smile


Ну не знаю насчет ядерщиков. В дистрибутиве очень давно используется. Как минимум с 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 пишет:
Короче, не всё с этой прагмой гладко.


Говорят, что при большой нагрузке операция с данной прагмой виснет.
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Разработка в PL/PLUS. Оптимизация запросов Oracle Часовой пояс: GMT + 3
На страницу Пред.  1, 2
Страница 2 из 2

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru