AXForum  
Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 11.11.2009, 11:33   #1  
dmites is offline
dmites
Участник
Аватар для dmites
 
221 / 14 (1) ++
Регистрация: 10.08.2005
В учетных таблицах 32,5802,17 и т.д. использованиe диапазонов для отдельных филиалов вроде как оправдано и дает возможность работать без блокировок (именно этих таблицах) при учете да и необходимо при построении репликации без перписки учета.
Но с другой стороны - записи физически упорядоченны по Entry No. то есть там где заканчивается один диапазон тут же начинается другой (при FillFactor=100). Соответсвенно, для вставки записи в конец "верхнего" дипазона, то бишь в середину таблицы, надо "сдвинуть" записи в страничке, куда
вставляется запись. Т.к. страничка заполнена на 100 %, из неё выпихнется запись в следующую страницу и т.д. до конца..
Описание данного процесса находил в документации SQL, источник найти сейчас не могу, но вообщем категорически не рекомендуют выбирать кластерный ключ, приводящий к вставкам в середину таблицы ибо ужасным образом сказывается на производительности.
По идее, в таком случае хорошим будет кластерным ключ на целочисленном поле, заполняемым функцией DateTimeToInt т.е. новый записи в подавляющем своем кол-ве (учет задним числом не рассматриваем) будут попадать в конец таблицы.

Сказано - сделано. Но прироста ощутимого в производительности не ощутил.
Что не так ?

Кстати, удалось кому не будь победить блокировик при учете при помощи диапазонов таблиц ?
Старый 11.11.2009, 11:55   #2  
dmites is offline
dmites
Участник
Аватар для dmites
 
221 / 14 (1) ++
Регистрация: 10.08.2005
Нашел подтверждение "вредности" дипазонов
"...Относиться к выбору поля для кластерного индекса следует очень осторожно - например, если в эту таблицу часто производится вставка данных, а кластерный индекс наложен не на поле с автоприращением, то вполне может получиться так, что нам часто придется вставлять новые записи в середину таблицы. Результат - большое количество операций page split, фрагментация таблицы и, как следствие, серьезное падение производительности (за счет фрагментации и за счет того, что само по себе page split - достаточно ресурсоемкая операция...."
 


Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 09:42.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.