13.11.2007, 11:58 | #1 |
Участник
|
Nav 4, SP3, SQL 2005
Подскажите, что можно предпринять - В оборотной ведомости при переходе по дрилдауну из поля "Конечное сальдо (РУБ)" переодически подвисает Фин Книга Операций. В момент перехода присутствуют флоуфильтры - дата учета (месяц) и фин. счет (пара субсчетов). При успешном переходе кол-во отфильтрованных операций составляет от 0 до 100 В профайлере смотрел такого рода запросы - cpu -1200, duration 12000 мс, read 14000(могу написать более подробную трассировку), по этому запросу было отфильтрованно около 50 записей Таблица Но. Название таблицы Число Записей Размер записи Размер (KB) 17 G/L Entry 1522107 740 1100352 Схожие проблемы наблюдаются и в Товар и Стоимость Книги Операций при переходе из вычисляемого поля. Функционал по большей части стандартный. Такого рода проблемы появились около месяца назад, когда запустили фин учет себ за пол года (сейчас коррекция и фин учет себ делаются каждый день) |
|
13.11.2007, 14:24 | #2 |
Участник
|
В этой форме (12406 наверное) триггер OnDrillDown() не переписывали на поле Конечное Сальдо (РУБ)?
|
|
13.11.2007, 14:51 | #3 |
Участник
|
Цитата:
Вроде нет - Код: Balance Ending - OnDrillDown() DrillDownGLEntry(3); Код: DrillDownGLEntry(Show : 'StartBalance,Debit,Credit,EndBalance,NetChange') GLEntry.RESET; GLEntry.SETCURRENTKEY("Source Type","Source No.","G/L Account No.","Global Dimension 1 Code","Global Dimension 2 Code"); GLEntry.SETRANGE("Source Type",GLEntry."Source Type"::Customer); GLEntry.SETRANGE("Source No.","No."); GLEntry.SETFILTER("G/L Account No.",GETFILTER("G/L Account Filter")); GLEntry.SETFILTER("Global Dimension 1 Code",GETFILTER("Global Dimension 1 Filter")); GLEntry.SETFILTER("Global Dimension 2 Code",GETFILTER("Global Dimension 2 Filter")); GLEntry.SETFILTER("Posting Date",GETFILTER("Date Filter")); CASE Show OF Show::StartBalance: IF COPYSTR(GETFILTER("Date Filter"),1,2) <> '..' THEN BEGIN IF GETRANGEMIN("Date Filter") <> 0D THEN GLEntry.SETRANGE("Posting Date",0D,GETRANGEMIN("Date Filter") - 1); END ELSE EXIT; Show::Debit: GLEntry.SETFILTER("Debit Amount",'<>%1',0); Show::Credit: GLEntry.SETFILTER("Credit Amount",'<>%1',0); Show::EndBalance: IF GETRANGEMAX("Date Filter") <> 0D THEN // *** MBS ERROR >> // GLEntry.SETRANGE("Posting Date",0D,GETRANGEMAX("Date Filter") - 1) GLEntry.SETRANGE("Posting Date",0D,GETRANGEMAX("Date Filter")) // *** MBS ERROR << ELSE EXIT; Show::NetChange: GLEntry.SETFILTER(Amount,'<>%1',0); ELSE ERROR(''); END; FORM.RUN(0,GLEntry); |
|
13.11.2007, 15:42 | #4 |
Участник
|
Может включить Posting Date в используемый ключ?
|
|
13.11.2007, 16:48 | #5 |
Участник
|
Видимо SQL сервер в full scan таблицы сваливается.
Попробуйте на обновить статистику. |
|
13.11.2007, 16:54 | #6 |
Участник
|
|
|
14.11.2007, 09:04 | #7 |
Участник
|
Боюсь реорганизация индексов на статистику не повлияет. Посмотрите планы выполения запросов.
Другой способ проверить - сделать сиквельный бэкап, развернуть на другой базе и сравнить результаты. |
|
14.11.2007, 10:33 | #8 |
Участник
|
На самом деле, в этом ключе есть поле Posting Date. Видимо, когда объявляли функцию сортировки, последняя часть ключа не влезла в одну строчку кода. Но ключ же будет правильно инициализирован?
Сам ключ - Source Type,Source No.,G/L Account No.,Global Dimension 1 Code,Global Dimension 2 Code,Business Unit Code,Posting Date |
|
14.11.2007, 10:53 | #9 |
Участник
|
Цитата:
Сообщение от Ros
На самом деле, в этом ключе есть поле Posting Date. Видимо, когда объявляли функцию сортировки, последняя часть ключа не влезла в одну строчку кода. Но ключ же будет правильно инициализирован?
Сам ключ - Source Type,Source No.,G/L Account No.,Global Dimension 1 Code,Global Dimension 2 Code,Business Unit Code,Posting Date P.S. То что не влезло в одну строчку кода - не резон, так как всегда можно перейти на вторую. |
|
15.11.2007, 09:10 | #10 |
Участник
|
Цитата:
Обратите внимание - проблемы появились после коррекции себестоимости. Мои предположения - на основе статистики накопленной ДО коррекции себестоимости сервер выбирает неоптимальный индекс или сваливается в full scan таблицы. Проверить просто - забэкапить - развернуть - сравнить |
|
15.11.2007, 10:21 | #11 |
Участник
|
а вот тут возникла ошибка форума....
|
|
15.11.2007, 10:28 | #12 |
Участник
|
Цитата:
Сообщение от rmv
Ну на самом деле SQL серверу все равно какой ключ прописан в коде, поля ключа подставляются в Order By запроса, а вот какой индекс выберит SQL сервер - зависит от статистики на наверно чуть от random'a .
Обратите внимание - проблемы появились после коррекции себестоимости. Мои предположения - на основе статистики накопленной ДО коррекции себестоимости сервер выбирает неоптимальный индекс или сваливается в full scan таблицы. Проверить просто - забэкапить - развернуть - сравнить Короче: Попадает ли в данном случае поле Postind Date в Order By? Если не попадает то при SETRANGE по этому полю, по идее, SQL будет тормозить? |
|
15.11.2007, 12:41 | #13 |
Участник
|
Цитата:
Сообщение от rmv
Ну на самом деле SQL серверу все равно какой ключ прописан в коде, поля ключа подставляются в Order By запроса, а вот какой индекс выберит SQL сервер - зависит от статистики на наверно чуть от random'a .
Обратите внимание - проблемы появились после коррекции себестоимости. Мои предположения - на основе статистики накопленной ДО коррекции себестоимости сервер выбирает неоптимальный индекс или сваливается в full scan таблицы. Проверить просто - забэкапить - развернуть - сравнить |
|
15.11.2007, 13:00 | #14 |
Участник
|
Цитата:
declare @p1 int set @p1=180150801 declare @p3 int set @p3=16 declare @p4 int set @p4=1 declare @p5 int set @p5=0 exec sp_cursoropen @p1 output,N'SELECT * FROM "Tea"."dbo"."ЗАО компания$G_L Entry" WITH (READUNCOMMITTED) WHERE (("Source Type"=@P1)) AND (("Source No_"=@P2)) AND (("G_L Account No_"=@P3)) AND (("Posting Date">=@P4 AND "Posting Date"<=@P5)) AND (("Debit Amount"<>@P6)) AND "Source Type"=@P7 AND "Source No_"=@P8 AND "G_L Account No_"=@P9 AND "Global Dimension 1 Code"=@P10 AND "Global Dimension 2 Code"=@P11 AND "Business Unit Code"=@P12 AND "Posting Date"=@P13 AND "Entry No_"<@P14 ORDER BY "Source Type" DESC,"Source No_" DESC,"G_L Account No_" DESC,"Global Dimension 1 Code" DESC,"Global Dimension 2 Code" DESC,"Business Unit Code" DESC,"Posting Date" DESC,"Entry No_" DESC OPTION (FAST 5)',@p3 output,@p4 output,@p5 output,N'@P1 int,@P2 varchar(20),@P3 varchar(20),@P4 datetime,@P5 datetime,@P6 decimal(38,20),@P7 int,@P8 varchar(20),@P9 varchar(20),@P10 varchar(20),@P11 varchar(20),@P12 varchar(10),@P13 datetime,@P14 int',1,'К00287','62-100',''2007-10-01 00:00:00:000'',''2007-10-31 00:00:00:000'',0,1,'К00287','62-100','ЗАО КОМП.','','',''2007-10-02 00:00:00:000'',1343765 select @p1, @p3, @p4, @p5 попрубую вечером сделать ребилд и обновление статистики по этой таблице. |
|
15.11.2007, 14:27 | #15 |
Участник
|
я поменял на формах для больших таблиц и кое в чем мне это помогло.
If you are running on SQL Server, you must also be aware of a very specific performance problem that applies to forms: · Setting the SourceTablePlacement property to the default value (Saved) will often make opening forms that display data from tables that contain many records (1,000,000 or more), for example G/L entries, very slow. To fix this problem, set the SourceTablePlacement property to First in these forms. |
|
16.11.2007, 16:52 | #16 |
Участник
|
В таком случае Posting Date попадает в where условие запроса. Не думаю что оптимизатор настолько глуп чтобы анализировать только order by
|
|
21.11.2007, 10:39 | #17 |
Участник
|
Проблему удалось решить перестроением ключей на таблице "Стоимость Операция".
До этого ключи были оптимизированны с помощью сервисного задания "реорганизация", и результаты по мастер таблицам были хорошими -Total fragmentation 0,38 - 0,90%, а вот статистика нифига не обновлялась. В итоге работы пакетного задания "Коррекция себестоисоти" сразу за полгода таблица "Стоимость Операция" подросла раза в два. Больше сервер не сваливался в full scan. Всем спасибо за участие в разборе моей проблемы (как оказалось довольно тривиальной) |
|
21.11.2007, 15:48 | #18 |
Участник
|
Цитата:
Сообщение от Ros
До этого ключи были оптимизированны с помощью сервисного задания "реорганизация", и результаты по мастер таблицам были хорошими -Total fragmentation 0,38 - 0,90%, а вот статистика нифига не обновлялась. В итоге работы пакетного задания "Коррекция себестоисоти" сразу за полгода таблица "Стоимость Операция" подросла раза в два.
|
|
22.11.2007, 16:31 | #19 |
Участник
|
|
|
29.11.2007, 19:48 | #20 |
Участник
|
Только бещз обид - только ссылки:
Оптимизация SIFT индексов. Navision + MS SQL SQL2000 - вдруг начались сильные тормоза. Navision Performace Tips P.S. будет мало - пишите в личу- файлик старенький (пробегал уже здесь несколько раз, поэтому не выкладываю) вышлю... |
|