Текущее время: Чт, июл 24 2025, 00:32

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 8 ] 
Автор Сообщение
 Заголовок сообщения: SELECT
СообщениеДобавлено: Пт, сен 12 2008, 10:17 
Специалист
Специалист

Зарегистрирован:
Ср, мар 21 2007, 14:32
Сообщения: 158
Господа!
есть select из mseg который выполняется долго первый раз. Во второй - намного быстрее. Понятно что что-то куда-то кешируется. Вопрос как отключить кеширование, чтобы запрос всегда выполнялся как и в первый раз?
пробовал в запросе использовать BYPASSING BUFFER - не помогает.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SELECT
СообщениеДобавлено: Пт, сен 12 2008, 10:37 
Специалист
Специалист

Зарегистрирован:
Чт, мар 22 2007, 14:40
Сообщения: 142
Пол: Мужской
_gary_ написал(а):
Господа!
есть select из mseg который выполняется долго первый раз. Во второй - намного быстрее. Понятно что что-то куда-то кешируется. Вопрос как отключить кеширование, чтобы запрос всегда выполнялся как и в первый раз?
пробовал в запросе использовать BYPASSING BUFFER - не помогает.


А можно полюбопытствовать, что Вас именно смущает ?;))
Вы хотите чтобы второй запрос работал так же долго как и первый или же он просто не вытаскивает какие то данные ???
какова цель ??

что касается буферизации, то MSEG не буфиризируемая таблица. (это можно посмотреть в ее технический данных). BYPASSING BUFFER работает, на сколько мне не изменяет память, только для буферезируемых типов.

Скорее всего скорость связана либо со статистикой, либо с индексами, если вы их используете в запросе?, (хотя могу и ошибаться конечно же).


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, сен 12 2008, 11:01 
Специалист
Специалист

Зарегистрирован:
Ср, мар 21 2007, 14:32
Сообщения: 158
да. нужно чтобы второй раз выполнялся так же долго.
нужно оптимизировать такой запрос
Code:
  select ...
  from ( mkpf
         inner join mseg on mseg~mblnr = mkpf~mblnr and   
                        mseg~mjahr = mkpf~mjahr
  )
  into corresponding fields of table _it
  where mkpf~budat in _budat
        and mseg~bwart in _bwart
        and MSEG~BUKRS = '1000'

st05 выдает что для MKPF используется индекс MANDT+BUDAT+MBLNR
а для MSEG - MANDT+MBLNR+MJAHR
я не долго думая добавил индекс в MSEG - MANDT+MBLNR+MJAHR+BWART+BUKRS
не помогло
чего делать дальше не знаю.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, сен 12 2008, 11:18 
Младший специалист
Младший специалист

Зарегистрирован:
Вт, июл 08 2008, 09:30
Сообщения: 55
Ну кешироваться может и в самой базе данных... Перезапускать систему, конечно, никто не даст...


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, сен 12 2008, 11:28 
Старший специалист
Старший специалист

Зарегистрирован:
Пн, авг 28 2006, 11:24
Сообщения: 292
Пол: Мужской
_gary_ написал(а):
да. нужно чтобы второй раз выполнялся так же долго.
нужно оптимизировать такой запрос


Вы уж определитесь, чего вы хотите, а то вы какие-то противоречивые требования высказываете.

Про оптимизацию:
Цитата:
добавил индекс в MSEG - MANDT+MBLNR+MJAHR+BWART+BUKRS

Очень сомнительный индекс. Посмотрите DB05, скорее всего не даст он никакого прироста производительности.

Сейчас у вас как выглядит план запроса? Сначала выбираются MKPF потом MSEG?

Если уж так хочется поменять их местами, то можно попробовать создать индекс MSEG MANDT BWART BUKRS.

А вообще, прежде чем плодить индексы неплохо было бы проанализировать, на каком этапе отсекается наибольшее число лишних записей и добиваться, чтобы этот этап стоял первым в плане выполнения и использовал какой-нибудь хороший индекс.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, сен 12 2008, 11:56 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
_gary_ написал(а):
да. нужно чтобы второй раз выполнялся так же долго.

Во второй раз выполняется быстрее, потому что выбранные первый раз записи попадают в кеш сервера БД. ;)
Оптимизацию лучше проводить так: первый запуск - просто так, для помещения информации в кеш.
2, 3 и далее - оптимизировать выборку.
По поводу что раньше выбрать - сложный вопрос.
Когда данных мало - оптимизатор может выбрать первой таблицей MSEG, т.к. по виду движения и БЕ можно отсечь больше записей.
Через несколько лет критичным станет период выборки и отсечение записей будет происходить по MKPF.

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, сен 12 2008, 12:11 
Модератор
Модератор
Аватара пользователя

Зарегистрирован:
Пт, июн 16 2006, 00:43
Сообщения: 1686
Откуда: Москва <-> Красноярск
Пол: Мужской
Для постоянной скорости в конец добавляем:
%_HINTS ORACLE '&REPARSE& NO_BUFFER'.
:)


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, сен 12 2008, 18:56 
Президент
Президент

Зарегистрирован:
Пт, апр 28 2006, 22:39
Сообщения: 2514
Откуда: North Taxolina, USA
Пол: Женский
Пономарев Артем написал:
%_HINTS ORACLE '&REPARSE& NO_BUFFER'.


"Нихт ферштеен". MS SQL Server (c) :)

В первый раз вижу, чтобы кому-то не нравилось, что запрос выполняется быстро... Юзеры жалуются на излишнее быстродействие? :?

_________________
"One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important." Bertrand Russell


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 8 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB