Запросы SQL: правильный ли вывод из фактов?

[Arahnid]

Факты:
1. Есть консолидированная база на SQL
2. Суть консолидации - синхронизация базы с другими базами
3. Консолидированная база синхронит данные с 19 другими базами по 20 таблицам

4. Пишу запрос к одной из таблиц: суммируй стоимость за 2 недели продаж. Никаких join с другими таблицами нет. Результат выполнения вижу через 00:01:59

5. Пишу запрос к одной из таблиц: суммируй стоимость за 1 день продаж. Аналог запроса в п.4, только период всего лишь 1 день. Результат выполнения вижу через 00:02:45

6. Пишу тот же запрос за 31.12.2010. Данных нет. Запрос вначале выполняется за 0:01:49. Повторно 0:00:11 или 0:0:01.

Можно ли из данных фактов сделать вывод, что проблема - это я прошу ответить, а он меня ставит в очередь. Очередь возникает из-за постоянной синхронизации. И проблема лежит не в самом запросе (оптимальность кода: код построен на select sum() from)

[_scorp_]

Похоже у вас после синхронизации сильно меняется распределение данных и статистика становится неактуальной, следовательно, выбираются неоптимальные планы исполнения запросов. Попробуйте сразу после синхронизации запускать пересчет статистики.

[Arahnid]

Ограниченность доступа не позволила обновить статистику, но
Я получила, что
Статистика по полю, которое я суммирую, обновилось последний раз вчера? Это плохо или это не о чем не говорит?

Как определить когда была завершена синхронизация?

[samolalex]

Попробуйте очистить кэш выполнения запросов вашей СУБД.

[gl00mie]

Цитата:

Сообщение от Arahnid

Статистика по полю, которое я суммирую, обновилось последний раз вчера? Это плохо или это не о чем не говорит?

Ни о чем не говорит. Оптимизатору запросов скорее интересна статистика по полям, позволяющим сузить выборку, т.е. используемым в запросе для фильтрации записей.

[Arahnid]

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

[kornix]

Ну по вашему описанию явно читается закономерность неравномерного выполнения одних и тех же запросов => СУБД явно занята обработкой чего-то сложного. Наверняка, что за день, что за месяц, время выборки плавает одинаково. А у вас какая СУБД используется? Oracle? или MSSQL? И если MSSQL - то какой, и как вы настроили синхронизацию 20-ти баз? какими-то стандартными средствами SQL?

[cacadu]

Цитата:

Сообщение от Arahnid

6. Пишу тот же запрос за 31.12.2010. Данных нет. Запрос вначале выполняется за 0:01:49. Повторно 0:00:11 или 0:0:01.

Цитата:

Сообщение от Arahnid

Статистика по полю, которое я суммирую, обновилось последний раз вчера? Это плохо или это не о чем не говорит?

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

Ваш случай (запрос данных за 31.12.2010) напоминает тот, что был у меня.

Таблица, на которой были проблемы - постоянно растущий лог, 40 млн. записей.
Запрос выбирал записи за текущий день. Сервер не обновлял статистику автоматически, т.к. "считал", что изменения таблицы за день незначительны, и в %-ом отношении так и было - лог за 3 года, изменения за день составляли ~0,1%.

В результате из-за "кривой" статистики сервер не "видел", что за текущую дату данных очень мало, и делал FULL SCAN таблицы. При этом первое выполнение запроса приводило к загрузке большей части таблицы с диска в память (что занимало несколько минут), а последущие выполнения этого же запроса занимало существенно меньше времени (данные уже были в памяти). Через некоторое время данные из памяти (кеш) исчезали, и запрос снова начинал выполняться долго.
При этом же такой же запрос, но за другую дату, выполнялся моментально, т.к. на эту дату была корректная статистика, и вместо FULL SCAN использовался INDEX SEEK.

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