Выполняю по очереди 2 одинаковых (довольно сложных) запроса к регистру к одной и той же базе, отличаются они только заданными периодами (т.е. при прочих равных условиях).
1. Период - 1 месяц. Возвращается около 11000 строк. Время выполнения - около 3 минут.
2. Период - 1 день. Возвращается около 1000 строк. Время выполнеия - около 5 минут.
Количество записей в регистре за этот день (в случае 2) меньше чем количество записей за месяц (в случае 1).
Прогнал оба запроса через QA. В первом случае получил разбивку на этапы в процентах, а во втором все проценты равны 0.
Что же такого могло случиться с базой, что в другом периоде отчеты работают в сотню (а может тысячю) раз медленнее?
Тестирование и исправление ИБ делал - не помогло, при этом ошибок не было.

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

SELECT
$Рег.Товар as [Товар $Справочник.Номенклатура],
GROUPING ($Рег.Товар) as ИтогПоТовару

	,SUM($Рег.Количество) as Количество
	,SUM($Рег.СуммаБезНДС) as СуммаБезНДС
	,SUM($Рег.СуммаСНДС) as СуммаСНДС
	,SUM($Рег.НДС) as НДС
	,SUM($Рег.Доход) as Доход
	,SUM($Рег.СуммаБезСкидки) as СуммаБезСкидки
	,SUM($Рег.Скидка) as Скидка

,MAX(ПодзапросТовар.НаименованиеТовар) as НаименованиеТовар
,MAX(ПодзапросТовар.КоличествоТовар) as КоличествоТовар
,MAX(ПодзапросТовар.СуммаСНДСТовар) as СуммаСНДСТовар
,MAX(ПодзапросТовар.СкидкаТовар) as СкидкаТовар

FROM
	$Регистр.Остатки as Рег

LEFT JOIN
	$Справочник.Номенклатура as СпрТовары ON СпрТовары.ID  = $Рег.Товар

LEFT JOIN
(
SELECT

$Рег.Товар Товар,

SUM($Рег.Количество) as КоличествоТовар
,SUM($Рег.Скидка) as СкидкаТовар
,SUM($Рег.СуммаСНДС) as СуммаСНДСТовар
,MAX(СпрТовары.Descr) as НаименованиеТовар

FROM
	$Регистр.Остатки as Рег

LEFT JOIN
	$Справочник.Номенклатура as СпрТовары ON СпрТовары.ID  = $Рег.Товар

WHERE
   Рег.Date_Time_IDDoc BETWEEN :НачДата AND :КонДата~
	AND
	Рег.DEBKRED=1
GROUP BY

$Рег.Товар
WITH ROLLUP
) AS ПодзапросТовар
ON

ПодзапросТовар.Товар=$Рег.Товар
WHERE
   Рег.Date_Time_IDDoc BETWEEN :НачДата AND :КонДата~
	AND
	Рег.DEBKRED=1
	AND
GROUP BY
$Рег.Товар
	WITH ROLLUP
ORDER BY
ИтогПоТовару DESC,
НаименованиеТовар,
$Рег.Товар
 

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

kiruha писал(а) 19. Ноября 2007 :: 11:27:


Я не знаю как выделить время на выполнение подзапроса, но весь запрос в целом за более ранние периоды выполняется за 4-5 минут если брать период месяц (например июнь 2007г.) - это еще и с выводом таблицы на экран, а если взять период 01.11.2007-05.11.2007 то просто дождаться не возможно, приходится снимать задачу.
В справочнике номенклатура около 100000 позиций.
А размер бызы за период с июня по ноябрь вырос с 19Гб до 21Гб.

Какая цель запроса? Что-то не вкуривается никак... 

alex_gol писал(а) 20. Ноября 2007 :: 22:51:

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

ИХМО  надо сначало пересмотреть структуру регистра.

alex_gol писал(а) 20. Ноября 2007 :: 22:51:


Переделывай эту хрень срочно! Тупость полнейшая (имхо)
Заведи оборотный регистр продажи... и периоды там не нужны наверное все же...

Цитата:


На счет оборотного регистра - не получится, т.к. есть приход товара и в другом отчете расчитываются остатки. А вот убрать периоды - думаю идея хороша. Но как получить тогда нужное мне представление недели. Например: "№неделиВГоду НачНедели-КонНедели". Или делать это уже при выводе на экран?
И еще: не нашел применения функции DATEPART для полугодия.

+ или всё это один раз в Хранимую процедуру вынести и всё!

kiruha писал(а) 22. Ноября 2007 :: 08:04:


Будь добр, поясни свою мысль...

Если ты на счет объема базы, то попытаюсь пролить свет. База наполняется не пользователями, а втягивается автоматически в режиме онлайн. Есть торговая фирма, которая торгует через много торговых точек (ТТ). Сегодня их около 70, скоро возрастет до 200. Каждый день эти ТТ сливают свои данные о продажах и об остатках в офис. А база их автоматически втягивает в реальном времени (втягивание идет круглосуточно). Продажи получаются 50-100 позиций в день, а остатки 3000-50000 позиций в день по каждому магазину. Вот поэтому такой немаленький рост базы. Сейчас в ней данные за 2 года.

Цитата:


Такой регситр все-таки 1. Если говорить  о незакрытости, возможно ты прав, спорить не буду и измерения, связанные с временными интервалами повыкидываю. Но незакрытость может быть в таблице остатков "RG",  а я запрос строю к таблице с оборотами "RA". И все-таки, если вернуться к истокам: ведь база в таком состоянии уже давно и за одни периоды расчет происходит быстро, а за другие во много раз (несоизмеримо с ростом базы) медленнее. Вот в чем вопрос.

Вот и посмотри что там '     0   ' или NULL
Раз полез в прямые запросы - надоть представлять где что лежит и как закрывается (это, кстати, даже в тесте на спеца требуют)

Ура!!! Наконец-то разгадка. Нужно было просто переиндексировать базу. Но сделал я это средствами SQL-сервера. С помощью команды:

EXEC _1sp_DBReindex
 

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

Большое спасибо  всем монстрам за идеи , здоровую критику в мой адрес и стильное общение.
Все хорошие идеи я воплощу в жизнь.