Тормозит выборка из таблицы

Димкин

Есть таблица хранения статуса задачи:
MANDT
CODE_TASK - задача
STATUS_TMS - время установки статуса
TASK_STATUS - статус задачи

Первые три поля - ключевые.
Нужно получить текущий (максимальный по времени установки) статус задачи.

Code:

      SELECT SINGLE * FROM ztask_stat AS t1 INTO wa WHERE
          code_task = in_code_task AND
          status_tms = ( SELECT MAX( status_tms ) FROM
                    ztask_stat WHERE code_task = t1~code_task).

Данных стало очень много и выборка стала тормозить.
Как-то можно ускорить? Индекс на STATUS_TMS поможет?
По одной задаче бывает 3-100 изменений статуса.
Или периодически перемещать старые статусы в ztask_stat_history?

Igor_34_rus

Думаю быстрее будет выбрать таблицу по задаче в сортированную по времени внутренностную таблицу(по убыванию), и считать первую строку.

LKU

Хранить текущий статус задачи в отдельной таблице с ключом MANDT/CODE_TASK
Пример в стандарте:
EDIDC-STATUS - текущий статус IDOC
EDIDS - таблица с историей статусов IDOC

skaa

Димкин написал(а):

Первые три поля - ключевые.
Нужно получить текущий (максимальный по времени установки) статус задачи.

Code:

      SELECT SINGLE * FROM ztask_stat AS t1 INTO wa WHERE
          code_task = in_code_task AND
          status_tms = ( SELECT MAX( status_tms ) FROM
                    ztask_stat WHERE code_task_wf = t1~code_task_wf).

А что за поле code_task_wf? и чем оно отличается от поля code_task?

Димкин

Цитата:

А что за поле code_task_wf? и чем оно отличается от поля code_task?

Это я сделал опечатку поле одно и то же (код задачи). На самом деле в таблице больше данных, но не хотел делать сообщение сложным для восприятия.
На самом деле вот почти вся таблица (жирным выделены ключевые поля):
MANDT
CODE_TASK_WF - код задачи
GJAHR - год
POPER - период
BUKRS - БЕ
STATUS_TMS - время установки статуса задачи
TASK_STATUS - статус задачи

Удав

Обычно историю изменений полей хранят отдельно, см. таблицы JEST и JCDS.

Kengur

База какая? Какая таблица по размеру? План запроса смотрели?

Димкин

ORACLE
Записей 32 млн
Вот план запроса.

Только я его не понимаю

Вроде сейчас смотрю не тормозит эта таблица. Может была нагрузка на базу большая

Kengur

Ну план запроса оптимальный, на мой взгляд. Таблица маленькая и скорей всего все равно будет в кеше сидеть. Можно попросить админов индекс пересобрать в оракле, если будет тормозить сильно.

UKY

Димкин написал(а):

На самом деле вот почти вся таблица (жирным выделены ключевые поля):
MANDT
CODE_TASK_WF - код задачи
GJAHR - год
POPER - период
BUKRS - БЕ
STATUS_TMS - время установки статуса задачи
TASK_STATUS - статус задачи

Я бы ещё попробовал перенести поле STATUS_TMS сразу после CODE_TASK_WF, а уже после них поставил бы GJAHR POPER BUKRS.
Но это если других запросов по текущему ключу нет.
Если другие запросы есть и менять их нельзя, то добавил бы индекс по CODE_TASK_WF и STATUS_TMS.

Удав

Вообще первичный индекс странный - поля GJAHR и POPER лишние, т.к. есть STATUS_TMS и получается, что за одну дату статус может храниться только один раз для одной БЕ...
И непонятно, код задачи может быть одинаковым для разных БЕ, или он уникальный?
По-хорошему нужно сделать короткий первичный ключ и несколько вторичных - например в одном указать БЕ, год, период, а во втором - дату.
Кроме этого, в подзапросе используется поле code_task_wf, а в основном запросе - code_task...

Rizor

Возможно, доп поля в ключе служат как раз чтобы ограничить область поиска максимального status_tms . Тогда есть резон эти поля тоже использовать в выборке. Что - то наподобие :

Code:

  SELECT * FROM ztask_stat INTO wa UP TO 1 ROWS
    WHERE code_task_wf = in_code_task
      AND bukrs = in_bukrs
    ORDER BY gjahr poper status_tms DESCENDING.
  ENDSELECT. 

Удав

Rizor написал(а):

Возможно, доп поля в ключе служат как раз чтобы ограничить область поиска максимального status_tms . Тогда есть резон эти поля тоже использовать в выборке.

Но не в первичном же индексе они должны быть :wink:

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

Тормозит выборка из таблицы

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