Доброе время суток, коллеги. Справочник номенклатуры перевалил за 500 тыр. строк. Стали тормозить типовые отчеты(ведомость по товарам, анализ доступности) если указываешь в отборе номенклатуру в иерархии, т.е. с отбором отчет формируется более 30 минут. SQL 2005, сервер предприятия отдельно, сама база вести 150 Gb. Подскажите в какую сторону капать в плане оптимизации. В справочник добавляли поля только числовые и булевские?

Для начала надо смотреть по каким регистрам формируется отчет и индексировать номенклатуру в этих регистрах.

Что же вы такое монстроидальное учитываете?

Заменяй иерархию на линейный список (после "Сформировать", но перед собственно выполнением отчёта).

(1) Регистр "Товары на складах" там стоит индекс по номенклатуре

(2) готовая продукция уникальная, компания занимается оформлением изделий заказчиков
Ты предлагаешь все отчеты перепиливать, я думал что что то не так со справочником, или что то можно с ним сделать, самописные отчеты и обработки давно переделал

Скорее - доработать форму подбора ТМЦ.

(5) каким образом?

Получить из "В группе из списка" Группа1, ... ГруппаN, Деталь1 ... ДетальM - отбор "В списке" только из элементов.

переписать отчеты таким образом, чтобы получался плоский список первым запросом пакета, а дальше он использовался во втором списке. возможно потребуются извращения типа параметра "&ИспользоватьОтборПоНоменклатуре" и его установке на основании анализа отборов

(7) в случае отбора "не в группе" получится слишком большой список

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

(9) Наверное, я плохо объяснил свой вариант.

Смотри.

Есть группа "Болты" с элементами БолтМ3 ... БолтМ24, и группа Гайки с ГайкаМ3 ... ГайкаМ24.

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

(0) Добавить памяти SQL пробовали?

(12) 24 Gb стоит

(11) Выберут папку в которой 200 тыр. артикулов, и в форме получится список из 200 тыр артикулов

(14) Я предполагаю, что плоский список одинэска проглотит легче, чем такой отбор.

Ну и есть некоторые сомнения, что вы реально работаете с таким списком. Просто я знаю, что такое порядок на складе с 50К номенклатуры.


Толковый админ по SQL нужен для настройки?

вот тут есть немного:
v8: Как получить записи из первой таблицы которых нет во второй?

(15) 1. Ну пока согласен что только такой выход есть, переделывать отчеты
2. Есть папка в номенклатуре которая ежемесячно пополняется приблизительно на 2,7 тыр объектов, ее часто исключают из отчетов, также есть папка с пополнением в 5 тыр строк, которую анализируют, сварачивание номенклатуры не вариант, потомучто она нужна в отчетах за весь период существования учета
3. Компанию жмотится на бабло, спасибо за предложение

(17) характеристики для лохов, чтоли?

(18) Кстати, не для лохов.
У нас на 10 номенклатур - 5 миллионов характеристик, и в типовом виде УПП с такими данными работает не фонтан.

а регистр нормально закрывается? Нет остатков?

Сам запрос как быстро работает?

(20) Остатки есть, которые закрываются в течении месяца, и сам запрос долго отрабатывается в консоле

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

(20) При том нашел такую фигню, на 01.07 нормально все отрабатывается а вот на 01.08 уже тормозит

(23) А итоги на 31.07 рассчитаны?

(0) На SQL регламенты настроены (индексы, статистика)?

(24) Итоги стоят на 30.11.2012

(26) Пересчитай на 31.08

(25) Ни фига нет, у нас на серваке где стоит SQL винду меняли, после этого ни кто ни чего не настроил

(28) Вот и причина тормозов

В sql-студии выполни

USE <ИмяБазы>
GO
SET NOCOUNT ON;
DECLARE @objectid int;
DECLARE @indexid int;
DECLARE @partitioncount bigint;
DECLARE @schemaname nvarchar(130);
DECLARE @objectname nvarchar(130);
DECLARE @indexname nvarchar(130);
DECLARE @partitionnum bigint;
DECLARE @partitions bigint;
DECLARE @frag float;
DECLARE @command nvarchar(4000);
-- Conditionally select tables and indexes from the sys.dm_db_index_physical_stats function
-- and convert object and index IDs to names.
SELECT
    object_id AS objectid,
    index_id AS indexid,
    partition_number AS partitionnum,
    avg_fragmentation_in_percent AS frag
INTO #work_to_do
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED')
WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;

-- Declare the cursor for the list of partitions to be processed.
DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do;

-- Open the cursor.
OPEN partitions;

-- Loop through the partitions.
WHILE (1=1)
    BEGIN;
        FETCH NEXT
           FROM partitions
           INTO @objectid, @indexid, @partitionnum, @frag;
        IF @@FETCH_STATUS < 0 BREAK;
        SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name)
        FROM sys.objects AS o
        JOIN sys.schemas as s ON s.schema_id = o.schema_id
        WHERE o.object_id = @objectid;
        SELECT @indexname = QUOTENAME(name)
        FROM sys.indexes
        WHERE  object_id = @objectid AND index_id = @indexid;
        SELECT @partitioncount = count (*)
        FROM sys.partitions
        WHERE object_id = @objectid AND index_id = @indexid;

-- 30 is an arbitrary decision point at which to switch between reorganizing and rebuilding.
        IF @frag < 30.0
            SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE';
        IF @frag >= 30.0
            SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD';
        IF @partitioncount > 1
            SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10));
        EXEC (@command);
        PRINT N'Executed: ' + @command;
    END;

-- Close and deallocate the cursor.
CLOSE partitions;
DEALLOCATE partitions;

-- Drop the temporary table.
DROP TABLE #work_to_do;
GO



потом

USE <ИмяБазы>
GO
exec sp_updatestats


потом

USE <ИмяБазы>
GO
DBCC FREEPROCCACHE

(29) Щаз на тесте буду пробовать, спасиб.

(13) Добить хотя бы до 64гб не помешает.

(29) Мега респект тебе и уважуха, все получилось, заработало, огромное спасибо тебе!!! С меня магарыч, как будешь в Москве, обязательно проставлюсь. Да кстати в Москву не хочешь перебраться, у нас щаз как раз в отделе есть вакуха программиста 1С.

(31) В ближайшем времени планируется смена железа.