Переодически подвисает Фин Книга Операций - NAV: Администрирование

Ros · 13.11.2007, 11:58

Nav 4, SP3, SQL 2005

Подскажите, что можно предпринять -

В оборотной ведомости при переходе по дрилдауну из поля "Конечное сальдо (РУБ)" переодически подвисает Фин Книга Операций. В момент перехода присутствуют флоуфильтры - дата учета (месяц) и фин. счет (пара субсчетов). При успешном переходе кол-во отфильтрованных операций составляет от 0 до 100

В профайлере смотрел такого рода запросы - cpu -1200, duration 12000 мс, read 14000(могу написать более подробную трассировку), по этому запросу было отфильтрованно около 50 записей

Таблица Но. Название таблицы Число Записей Размер записи Размер (KB)
17 G/L Entry 1522107 740 1100352

Схожие проблемы наблюдаются и в Товар и Стоимость Книги Операций при переходе из вычисляемого поля.

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

romeo · 13.11.2007, 14:24

В этой форме (12406 наверное) триггер OnDrillDown() не переписывали на поле Конечное Сальдо (РУБ)?

Ros · 13.11.2007, 14:51

Цитата:

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

В этой форме (12406 наверное) триггер OnDrillDown() не переписывали на поле Конечное Сальдо (РУБ)?

Разговор про форму 12406.

Вроде нет -

Код:

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);

romeo · 13.11.2007, 15:42

Может включить Posting Date в используемый ключ?

Ros · 14.11.2007, 10:33

Цитата:

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

Может включить Posting Date в используемый ключ?

На самом деле, в этом ключе есть поле Posting Date. Видимо, когда объявляли функцию сортировки, последняя часть ключа не влезла в одну строчку кода. Но ключ же будет правильно инициализирован?

Сам ключ - Source Type,Source No.,G/L Account No.,Global Dimension 1 Code,Global Dimension 2 Code,Business Unit Code,Posting Date

Fordewind · 14.11.2007, 10:53

Цитата:

Сообщение от 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. То что не влезло в одну строчку кода - не резон, так как всегда можно перейти на вторую.

rmv · 13.11.2007, 16:48

Видимо SQL сервер в full scan таблицы сваливается.
Попробуйте на обновить статистику.

Ros · 13.11.2007, 16:54

Цитата:

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

Видимо SQL сервер в full scan таблицы сваливается.
Попробуйте на обновить статистику.

У нас реорганизация индексов по всем таблицам раз в неделю делается. Я так понимаю, после этого задания статистика обновляется. Или я не о том?

rmv · 14.11.2007, 09:04

Боюсь реорганизация индексов на статистику не повлияет. Посмотрите планы выполения запросов.
Другой способ проверить - сделать сиквельный бэкап, развернуть на другой базе и сравнить результаты.

Ros · 15.11.2007, 13:00

Цитата:

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

чОрт! Адская ошибка форума сожрала мой длинный пост.
Короче: Попадает ли в данном случае поле Postind Date в Order By? Если не попадает то при SETRANGE по этому полю, по идее, SQL будет тормозить?

Попадает -

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

Цитата:

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

Перестрой ключи на таблице (когда пользователей не будет)

попрубую вечером сделать ребилд и обновление статистики по этой таблице.

Arshak · 15.11.2007, 14:27

я поменял на формах для больших таблиц и кое в чем мне это помогло.

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.

Ros · 21.11.2007, 10:39

Проблему удалось решить перестроением ключей на таблице "Стоимость Операция".

До этого ключи были оптимизированны с помощью сервисного задания "реорганизация", и результаты по мастер таблицам были хорошими -Total fragmentation 0,38 - 0,90%, а вот статистика нифига не обновлялась. В итоге работы пакетного задания "Коррекция себестоисоти" сразу за полгода таблица "Стоимость Операция" подросла раза в два.

Больше сервер не сваливался в full scan. Всем спасибо за участие в разборе моей проблемы (как оказалось довольно тривиальной)

RedFox · 21.11.2007, 15:48

Цитата:

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

До этого ключи были оптимизированны с помощью сервисного задания "реорганизация", и результаты по мастер таблицам были хорошими -Total fragmentation 0,38 - 0,90%, а вот статистика нифига не обновлялась. В итоге работы пакетного задания "Коррекция себестоисоти" сразу за полгода таблица "Стоимость Операция" подросла раза в два.

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

rmv · 22.11.2007, 16:31

Цитата:

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

Да и на SQL будете получать более точные значения в вычисляемых полях.

С этого места поподробнее пожалуйста.

RedFox · 29.11.2007, 19:48

Цитата:

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

С этого места поподробнее пожалуйста.

Только бещз обид - только ссылки:
Оптимизация SIFT индексов. Navision + MS SQL
SQL2000 - вдруг начались сильные тормоза.
Navision Performace Tips

P.S. будет мало - пишите в личу- файлик старенький (пробегал уже здесь несколько раз, поэтому не выкладываю) вышлю...

rmv · 30.11.2007, 16:28

Сходил по ссылкам.
Без обид - зря потерял время.
Нигде не встретил ситуации когда до оптимизации calcfieds и calcsums возвращал "неточное" значение X, а после оптимизации "точное" Y. Высылайте файлик

RedFox · 04.12.2007, 14:52

Цитата:

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

Сходил по ссылкам.
Без обид - зря потерял время.
Нигде не встретил ситуации когда до оптимизации calcfieds и calcsums возвращал "неточное" значение X, а после оптимизации "точное" Y. Высылайте файлик

Малеха недопонял что именно вы искали, но файл выкладываю

+
The following is an excerpt from SQL Server Books Online:
When you create an index in the database, the index information used by queries is stored in index pages. The sequential index pages are chained together by pointers from one page to the next. When changes are made to the data that affect the index, the information in the index can become scattered in the database. Rebuilding an index reorganizes the storage of the index data (and table data in the case of a clustered index) to remove fragmentation. This can improve disk performance by reducing the number of page reads required to obtain the requested data.

rmv · 05.12.2007, 00:41

Спасибо за книжку. С удовольствием прочел.
Цитирую Вашу фразу:

Цитата:

Да и на SQL будете получать более точные значения в вычисляемых полях.

По простоте душевной я понял что после до оптимизации calcfield возращает значение X, после оптимизации "более точное" значение Y. Или вы что то другое имели ввиду?

RedFox · 05.12.2007, 10:12

Цитата:

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

Спасибо за книжку. С удовольствием прочел.
Цитирую Вашу фразу:

По простоте душевной я понял что после до оптимизации calcfield возращает значение X, после оптимизации "более точное" значение Y. Или вы что то другое имели ввиду?

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

Arshak · 19.12.2007, 22:37

Коллеги, на ночь глядя посмотел умную презентацию про оптимизацию под SQL. если честно очень понравилось

но появилось пара вопросов
1 риторический- если в микрософте все знают то почему не делают сразу а оставляют все на откуп партнрам..
мне кажется риск ошибки партнера в этой тонкой сфере выше чем у разработчика

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

3 мне очень понравилась идея отключать SQLIndex для некоторых ключей,
вопрос- я правильно понимаю что если отключить SQLIndex то система при SETCURRENTKEY формально увидит этот ключ но при запросе на SQL этот факт будет проигнорирован но система не вылетит в ошбку об отсутствии ключа?
инресно будет выслушать мнение отечественных специалистов!

а то боюсь по аглицки я не все правильно понял