Экспертная система Delphi.int.ru

Сообщество программистов
Общение, помощь, обмен опытом

Логин:
Пароль:
Регистрация | Забыли пароль?

Delphi.int.ru Expert

Другие разделы портала

Переход к вопросу:

#   

Статистика за сегодня:  


Лучшие эксперты

DNK
I. DNK
Баллы: 5

Подробнее »



Вопрос # 1 604

/ вопрос открыт /

Здравствуйте, уважаемые эксперты!
Имеется база данных oracle и вней таблица в ней более 2 млн записей
При выборке по дате и связиванию с другой таблицей выборка осуществляется крайне медленно.
А при использование dbEx компонента и при передаче параметров запроса через params итого хуже,
С чем это связано?

Раджабов Амин Вопрос ожидает решения (принимаются ответы, доступен мини-форум)

Вопрос задал: Раджабов Амин (статус: Посетитель)
Вопрос отправлен: 21 мая 2008, 08:42
Состояние вопроса: открыт, ответов: 1.

Ответ #1. Отвечает эксперт: Косолапов Дмитрий Юрьевич

Здравствуйте, Раджабов Амин!
В принципе, 2 млн. записей, как мне кажется - веская причина, чтобы запрос работал не слишком быстро. Возможно также, что поле "Дата" не проиндексировано. В вопросе не сказано, связаны ли таблицы именно по полю дата, или какому-либо еще, возможно, связь не определена на уровне базы данных. Также возможно, что сервер не слишком производительный, или сеть. Еще вариант, хотя точно не знаю, есть ли это в Оракле, но в MS SQL оптимизатор запросов ориентируется на статистику; если Оракл устроен так же, то желательно заняться сервисным обслуживанием БД (обновить статистику, пеериндексировать и т.д.)

Ответ отправил: Косолапов Дмитрий Юрьевич (статус: 8-ой класс)
Время отправки: 21 мая 2008, 10:20
Оценка за ответ: 4

Комментарий к оценке: Да действительно индекса ка и связи нет к сожалению я не разрабочик и не имею права вносить изменения в структуру БД а сервак нормальный(2х4 хеон sata raid м-в) единственный момент база весить 3Г а оперативы всего 2Г ну ана счет переиндексации не знаю база ценная боюсь напартачить

Мини-форум вопроса

Всего сообщений: 9; последнее сообщение — 22 мая 2008, 23:18; участников в обсуждении: 3.
Вадим К

Вадим К (статус: Академик), 22 мая 2008, 00:11 [#1]:

Во первых, сколько записей отбирается за одну выборку.
во вторых, каким методом выбираются данные (компоненты)
в третих, а что такое "медленно"? иногда и два часа - быстро.
Галочка "подтверждения прочтения" - вселенское зло.
Раджабов Амин

Раджабов Амин (статус: Посетитель), 22 мая 2008, 08:23 [#2]:

Если пользоватся sql plusом то минута dbEx со со вписаннымы в sql параметрами запроса полторы dbEx с передачей параметров через params 5 мин
а записи не отбираются а выводится сумма сгрупированная по одмому из полей
Косолапов Дмитрий Юрьевич

Косолапов Дмитрий Юрьевич (статус: 8-ой класс), 22 мая 2008, 09:22 [#3]:

Ничего ж себе... Медленно...
Вадим К

Вадим К (статус: Академик), 22 мая 2008, 09:52 [#4]:

Сколько записей в результате получается?
Какой процент записей отбирается или все?
Галочка "подтверждения прочтения" - вселенское зло.
Вадим К

Вадим К (статус: Академик), 22 мая 2008, 09:55 [#5]:

Да, кстати, этот вопрос не связан с предыдущим о сохранении в xls и отображением?
Галочка "подтверждения прочтения" - вселенское зло.
Раджабов Амин

Раджабов Амин (статус: Посетитель), 22 мая 2008, 16:33 [#6]:

первое условие это дата отбирается 5%-10 от всего обема
по второму условию отбирается от 10 до 40% от полученного послепервого
получается от 8 до 20
я подумал может связ мешает и удалил ее
во запрос

SELECT GENERAL_ARH.TYPE_DOC, SUM(GENERAL_ARH.SUMMA)/100 AS SUM, GENERAL_ARH.CASH_CODE
FROM GENERAL_ARH
WHERE GENERAL_ARH.V_DATE between to_date(:DATE1,'dd.mm.yyyy')
and to_date(:DATE2,'dd.mm.yyyy')
AND
(GENERAL_ARH.ACC_CL like '10%'
OR
GENERAL_ARH.ACC_CL like '19903%')
AND
general_arh.acc_co like :STR
AND
general_arh.state=3
GROUP BY
GENERAL_ARH.TYPE_DOC, GENERAL_ARH.CASH_CODE
Раджабов Амин

Раджабов Амин (статус: Посетитель), 22 мая 2008, 16:34 [#7]:

может запрос надо както подаптимизировать
Косолапов Дмитрий Юрьевич

Косолапов Дмитрий Юрьевич (статус: 8-ой класс), 22 мая 2008, 22:13 [#8]:

Надо было с самого начала давать текст запроса...
Очень много условий like, которые, очень вероятно, как раз и снижают производительность. Для эксперимента можно эти условия убрать и сравнить производительность запроса...
Вадим К

Вадим К (статус: Академик), 22 мая 2008, 23:18 [#9]:

Давайте сделаем оценку. в худшем случае получается результат 0.1*0.4*2000000 = 80000. 80 тыс записей. это около тысячи страниц. Вопрос - кто будет это смотреть? ответ - никто.
БОльшая часть времени тратиться как раз на передачу результата. Надо думать либо о более узких условий. Либо использовать лимиты. Для оракла, начиная с 8i версии это выглядит так
  SELECT * from T WHERE ROWNUM <= 10
В результате будут отданы только первые 10 записей. Остальные можно подгружать по мере надобности. Лучше пусть просто кликает пользователь по кнопке "далее" и в течении 2-3 секунд подгружаются следующие записи, чем ждать 5 минут.

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

по поводу оптимизации запроса
general_arh.acc_co like :STR
это можно заменить на просто сравнение.
также в второй половине условия (после OR) можно попробывать попереставлять записи. я бы general_arh.state=3 вынес на первое место - это условие быстро отработает. Да и вообще поменял местами две половинки условия.

Также, в запросе есть одна плохая штука - названия поля совпадает с функцией (я о sum) - так не рекомендуется делать и часто можно получить по пальцам.

В целом, попробуйте поиграть "в перестановки" и посмотреть на скорость.
Ну и не забываем, что у оракла есть свой планировщик запроса, который всё это может и сам сделать, но он может и ошибаться.
Галочка "подтверждения прочтения" - вселенское зло.

Чтобы оставлять сообщения в мини-форумах, Вы должны авторизироваться на сайте.

Версия движка: 2.6+ (26.01.2011)
Текущее время: 21 августа 2017, 13:14
Выполнено за 0.04 сек.
Рейтинг@Mail.ru