Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
omarushchak
Member

Откуда:
Сообщений: 16
Добрый день, всем!

Если имеется таблица с кластеризированным индексом, которая находится под нагрузкой (вставки и обновления). Как избежать разбиения страниц. Как вариант сделать низкий фактор заполнения страниц. Как мне кажется, это приведет к росту числа страниц и объему базы данных или я не прав?
22 июл 19, 14:42    [21931754]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
msLex
Member

Откуда:
Сообщений: 7730
omarushchak
Добрый день, всем!

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


Вставлять только в конец индекса, при апдейтах не увеличивать размер записи
22 июл 19, 14:46    [21931757]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
uaggster
Member

Откуда:
Сообщений: 767
А кластеризованный индекс у вас по полю какого типа?
22 июл 19, 16:13    [21931853]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
omarushchak
Member

Откуда:
Сообщений: 16
uaggster
А кластеризованный индекс у вас по полю какого типа?


varchar
22 июл 19, 16:25    [21931872]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30768
omarushchak
Как вариант сделать низкий фактор заполнения страниц. Как мне кажется, это приведет к росту числа страниц и объему базы данных или я не прав?
Да, размер увеличится, но зато не будет разбиения. И делать редилд кластерного индекса, когда страницы заполнятся.
Ну, или перепроектировать модель данных, если таблитца очень большая.
22 июл 19, 16:30    [21931876]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
uaggster
Member

Откуда:
Сообщений: 767
Нуу... Если бы стояла задача кровь из носу добиться снижения разбиения страниц, я бы:
1. Изменил бы ключ с varchar на int identity.
2. Построил бы уникальный индекс по "бывшему" ключевому полю varchar.
3. Но, предварительно, заменил бы все поля varchar на char.

... и тогда условия msLex - выполнятся автоматически.
:-)
22 июл 19, 16:36    [21931885]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
alexeyvg
omarushchak
Как вариант сделать низкий фактор заполнения страниц. Как мне кажется, это приведет к росту числа страниц и объему базы данных или я не прав?
Да, размер увеличится, но зато не будет разбиения. И делать редилд кластерного индекса, когда страницы заполнятся.
Ну, или перепроектировать модель данных, если таблитца очень большая.

и как часто вы предлагаете это делать? 3 инсёрта один ребилд? филфактор может помогать при достаточно распределённых вставках, и зачем тогда вообще такой кластарный?
22 июл 19, 16:37    [21931886]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
а varchar это вы так guid храните?
22 июл 19, 16:39    [21931888]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
msLex
Member

Откуда:
Сообщений: 7730
TaPaK
и как часто вы предлагаете это делать? 3 инсёрта один ребилд? филфактор может помогать при достаточно распределённых вставках, и зачем тогда вообще такой кластарный?


Ну, например, все обращения к данным идут по естественному ключу, распределение которого, по природе своей, равномерно; например, какой-либо хеш (md5, sha и т.п.)

Плюс ко всему, расщеплению подвержены не только кластерные индексы.
22 июл 19, 16:46    [21931904]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
omarushchak
Member

Откуда:
Сообщений: 16
TaPaK,

точно
22 июл 19, 16:47    [21931906]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
msLex
TaPaK
и как часто вы предлагаете это делать? 3 инсёрта один ребилд? филфактор может помогать при достаточно распределённых вставках, и зачем тогда вообще такой кластарный?


Ну, например, все обращения к данным идут по естественному ключу, распределение которого, по природе своей, равномерно; например, какой-либо хеш (md5, sha и т.п.)

Плюс ко всему, расщеплению подвержены не только кластерные индексы.

не корректно написал последнюю часть. Вопрос как к такому ключу пришли - избавлялись от войны за полслуднюю страницу как советуют переходом на int identity или просто решили что поле cityName будет ключём
22 июл 19, 16:48    [21931908]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30768
TaPaK
филфактор может помогать при достаточно распределённых вставках
Да, конечно, при распределённых. А иначе и разбиения не будет, если не распределённые (точнее, разбиение не будет мешать).
TaPaK
и как часто вы предлагаете это делать? 3 инсёрта один ребилд?
Когда средняя средняя заполненность страниц вырастет до некоего неприемлемого значения (определить интуитивно) :-)
TaPaK
и зачем тогда вообще такой кластарный?
Например, этот кластерный создан сторонней компанией-разработчиком, и придётся с этим жить. Ну, или полномочный менеджер должен издать приказ "я всё про***, приказываю переделать систему, а меня уволить".
22 июл 19, 16:50    [21931911]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
alexeyvg,

автор
Да, конечно, при распределённых. А иначе и разбиения не будет, если не распределённые (точнее, разбиение не будет мешать).

у тс guid и мешает?

вставка через NEWSEQUENTIALID ?
22 июл 19, 16:53    [21931913]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
msLex
Member

Откуда:
Сообщений: 7730
TaPaK
не корректно написал последнюю часть. Вопрос как к такому ключу пришли - избавлялись от войны за полслуднюю страницу как советуют переходом на int identity или просто решили что поле cityName будет ключём

Насчет кластерного согласен, что в большинстве случаев такой ключ будет не лучшим решение (хотя и тут есть исключения), но если все равно нужен доступ по такому полю - индекс нужен, и он тоже будет расщепляться.
22 июл 19, 16:54    [21931916]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
uaggster
Member

Откуда:
Сообщений: 767
alexeyvg
Например, этот кластерный создан сторонней компанией-разработчиком, и придётся с этим жить. Ну, или полномочный менеджер должен издать приказ "я всё про***, приказываю переделать систему, а меня уволить".

Что-то я сильно сомневаюсь, что там всё завязано на кластерный индекс. Скорее - кластерный индекс используется как первичный ключ.
Ну, пусть сделают первичный ключ - некластерным, а кластерный - по другим полям.
22 июл 19, 17:02    [21931929]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30768
uaggster
alexeyvg
Например, этот кластерный создан сторонней компанией-разработчиком, и придётся с этим жить. Ну, или полномочный менеджер должен издать приказ "я всё про***, приказываю переделать систему, а меня уволить".

Что-то я сильно сомневаюсь, что там всё завязано на кластерный индекс. Скорее - кластерный индекс используется как первичный ключ.
Ну, пусть сделают первичный ключ - некластерным, а кластерный - по другим полям.
Понятно, что первичный ключ.
И как его поменять, если это приложение не ваше?
Попробуйте, поменяйте ПК и ключи в базе 1С :-)
22 июл 19, 20:11    [21932080]     Ответить | Цитировать Сообщить модератору
 Re: Как избежать разбиение страниц при интенсивной транзакционной нагрузке на таблицу?  [new]
uaggster
Member

Откуда:
Сообщений: 767
alexeyvg, ну, во-первых, неприличными словами - не выражаться! А то полстраны уже скриптами из 1С - дьявола вызывают.
А во-вторых - ну, первичный то ключ и кластерный индекс даже в 1С можно разделить. Только а) зачем и б) до первого обновления конфигурации...
23 июл 19, 08:12    [21932292]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить