Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
o-o
Guest
В связи с этим вопрос, вы что там перестраивали, оба раза одно и то же?
23 май 16, 15:25    [19208137]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
Nimua
Member

Откуда: Ростов-на-Дону
Сообщений: 344
o-o,

Извините не поняла что нужен еще раз кластерный, так как он был в описании вопроса.

CREATE CLUSTERED INDEX [IX_Table1_Date] ON [dbo].[Table1]
(
	[ForeignId] ASC,
	[DateUtc] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
GO


Я перестраивала оба раза и кластерный и некластерный. Оба раза кластерный перестраивался 2 часа 40 минут, а некластерный 50 минут.

Я думаю объяснение так долго потому что кластерный и потому что это влияет и тянет за собой изменение таблицы подойдет. Верно же?
23 май 16, 15:35    [19208205]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
ну просто привела скрипт одного индекса и забыла про другой... Но вопрос как получить не кластерный индекс по BigInt identity размером в 180+Гб....
23 май 16, 15:35    [19208206]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
iljy
Member

Откуда:
Сообщений: 8711
o-o
Кому не нравится, приводит доказательства обратного. Или хотя бы объясняет, зачем бы серверу хранить заполненность страниц индекса.


На самом деле правило звучит так: бред доказывает тот, кто его озвучил. Потому что ответ на вопрос "зачем бы серверу хранить заполненность страниц кучи" не менее загадочен.
23 май 16, 15:50    [19208310]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
iljy
Member

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

слушайте, а вы с какой целью для индекса, строящегося на IDENTITY, в принципе указываете FILLFACTOR, отличный от 100? У вас без специальных извращений вставок в середину этого индекса никогда не случится, зачем под них столько места резервировать?
23 май 16, 15:52    [19208323]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
TaPaK
Member

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

автор
Я думаю объяснение так долго потому что кластерный и потому что это влияет и тянет за собой изменение таблицы подойдет. Верно же?

Rebuild index - пересоздание индекса, для кластерного это как создать такую же таблицу с данными. Некластерный содержит в себе только ссылки и только того, что указано в индексе + include, кластерный на листьях содержит сами данные. На Rebuild будет влиять всё подряд - сколько ресурсов доступно, что делают с таблицей(при online on) и тп
23 май 16, 15:54    [19208337]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
iljy
Member

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

при наличии кластерного некластерный содержит не "ссылки", которые RID, а поля кластерного индекса. И уже дополнительно ко всему этому может содержать инклуды.
23 май 16, 16:04    [19208409]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
o-o
Guest
iljy
o-o
Кому не нравится, приводит доказательства обратного. Или хотя бы объясняет, зачем бы серверу хранить заполненность страниц индекса.

На самом деле правило звучит так: бред доказывает тот, кто его озвучил. Потому что ответ на вопрос "зачем бы серверу хранить заполненность страниц кучи" не менее загадочен.

заполненность страниц кучи нужна для того, чтобы понять,
на какую страницу поместить очередную вставляемую строку (на какой странице есть место).
для индекса такой вопрос не стоит, т.к. ключ индекса однозначно определяет место вставки
23 май 16, 16:05    [19208417]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
o-o
Guest
iljy
Nimua,

слушайте, а вы с какой целью для индекса, строящегося на IDENTITY, в принципе указываете FILLFACTOR, отличный от 100? У вас без специальных извращений вставок в середину этого индекса никогда не случится, зачем под них столько места резервировать?

скорее всего, у них просто серверный ФФ в 80 выставлен, а ручками они ничего не пишут
23 май 16, 16:07    [19208427]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
Nimua
Member

Откуда: Ростов-на-Дону
Сообщений: 344
o-o,

так и есть. 80 по умолчанию
23 май 16, 16:11    [19208446]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
Nimua
Member

Откуда: Ростов-на-Дону
Сообщений: 344
iljy,

спасибо! предложу.
23 май 16, 16:12    [19208453]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
o-o
iljy
пропущено...

На самом деле правило звучит так: бред доказывает тот, кто его озвучил. Потому что ответ на вопрос "зачем бы серверу хранить заполненность страниц кучи" не менее загадочен.

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

но разве там будет вставка в "середину" или к чему знать сколько на какой странице?
23 май 16, 16:15    [19208464]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
o-o
Guest
[quot Nimua
Я думаю объяснение так долго потому что кластерный и потому что это влияет и тянет за собой изменение таблицы подойдет. Верно же?[/quot]
не пойдет.
перестроение кластерного спровоцировало бы перестроение некластерного на 2000-ом (при неуникальном ключе),
но во времена 2000-ого не было онлайнового ребилда
23 май 16, 16:17    [19208470]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
o-o
Guest
TaPaK
o-o
пропущено...

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

но разве там будет вставка в "середину" или к чему знать сколько на какой странице?

там это где?
при вставке в куче вставит, куда попало.
где есть первое попавшееся достаточное свободное место
23 май 16, 16:19    [19208477]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
o-o
TaPaK
пропущено...

но разве там будет вставка в "середину" или к чему знать сколько на какой странице?

там это где?
при вставке в куче вставит, куда попало.
где есть первое попавшееся достаточное свободное место

сможете подтвердить чем либо, что в куче будет вставка не в конец? Я нахожу только, то как и думал

автор
When a table is created as a heap, SQL Server does not force where the new data pages are written. Whenever new data is written this data is always written at the end of the table or on the next available page that is assigned to this table. When data is deleted the space becomes free in the data pages, but it is not reused because new data is always written to the next available page.
23 май 16, 16:30    [19208522]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
o-o
Guest
TaPaK
o-o
пропущено...

там это где?
при вставке в куче вставит, куда попало.
где есть первое попавшееся достаточное свободное место

сможете подтвердить чем либо, что в куче будет вставка не в конец? Я нахожу только, то как и думал

автор
When a table is created as a heap, SQL Server does not force where the new data pages are written. Whenever new data is written this data is always written at the end of the table or on the next available page that is assigned to this table. When data is deleted the space becomes free in the data pages, but it is not reused because new data is always written to the next available page.
23 май 16, 16:49    [19208678]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
o-o,

и при чём здесь хранение и использование значения %заполнения ВСЕХ страниц?
23 май 16, 16:51    [19208696]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
invm
Member

Откуда: Москва
Сообщений: 9719
TaPaK
сможете подтвердить чем либо, что в куче будет вставка не в конец?
+ Подтверждение
declare @t table (id int identity, s char(4000));

insert into @t
select top (20)
 'a'
from
 master.dbo.spt_values;

select
 b.file_id, b.page_id, b.slot_id, t.s
from
 @t t cross apply
 (select %%physloc%%) a(pl) cross apply
 (
  select
   cast(cast(reverse(substring(a.pl, 1, 4)) as binary(4)) as int),
   cast(cast(reverse(substring(a.pl, 5, 2)) as binary(2)) as smallint),
   cast(cast(reverse(substring(a.pl, 7, 2)) as binary(2)) as smallint)
 ) b(page_id, file_id, slot_id)
order by
 b.file_id, b.page_id, b.slot_id;

delete from @t where id = 10;
insert into @t values ('bbbbb');

select
 b.file_id, b.page_id, b.slot_id, t.s
from
 @t t cross apply
 (select %%physloc%%) a(pl) cross apply
 (
  select
   cast(cast(reverse(substring(a.pl, 1, 4)) as binary(4)) as int),
   cast(cast(reverse(substring(a.pl, 5, 2)) as binary(2)) as smallint),
   cast(cast(reverse(substring(a.pl, 7, 2)) as binary(2)) as smallint)
 ) b(page_id, file_id, slot_id)
order by
 b.file_id, b.page_id, b.slot_id;
23 май 16, 17:02    [19208776]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
invm
Member

Откуда: Москва
Сообщений: 9719
TaPaK,

https://technet.microsoft.com/en-us/library/ms175195(v=sql.105).aspx
Page Free Space (PFS) pages record the allocation status of each page, whether an individual page has been allocated, and the amount of free space on each page. The PFS has one byte for each page, recording whether the page is allocated, and if so, whether it is empty, 1 to 50 percent full, 51 to 80 percent full, 81 to 95 percent full, or 96 to 100 percent full.

After an extent has been allocated to an object, the Database Engine uses the PFS pages to record which pages in the extent are allocated or free. This information is used when the Database Engine has to allocate a new page. The amount of free space in a page is only maintained for heap and Text/Image pages. It is used when the Database Engine has to find a page with free space available to hold a newly inserted row. Indexes do not require that the page free space be tracked, because the point at which to insert a new row is set by the index key values.
23 май 16, 17:06    [19208798]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
iljy
Member

Откуда:
Сообщений: 8711
o-o,

https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=8&ved=0ahUKEwilkOaTrfDMAhUsIpoKHbpYAyQQFghJMAc&url=http://www.sqlpass.org/EventDownload.aspx?suid=3646&usg=AFQjCNFAHtHlgHQlfVw2rGu7Es_99oCpbQ&sig2=ZQBCWQG9WWZJTTnSVlKrqg


Обратите внимание на PFS-страницы (это к вопросу о хранении заполненности).
23 май 16, 17:11    [19208823]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
TaPaK
Member

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

amount of free space = page fullness?
23 май 16, 17:12    [19208831]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
o-o
Guest
to TaPaK
dbcc checkdb кроме всего прочего сверяет хранящееся в заголовке страницы pct_full
с хранящимся в соответствующей странице PFS.
и если не совпадает, вываливает ошибку 8914.
ищите сами описание ошибки, или структуру PFS-страниц, или структуру заголовка страницы кучи
23 май 16, 17:16    [19208858]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
было
автор
Заполненность страниц хранится только для куч, а у вас индекс.

стало
o-o
to TaPaK
dbcc checkdb кроме всего прочего сверяет хранящееся в заголовке страницы pct_full
с хранящимся в соответствующей странице PFS.
и если не совпадает, вываливает ошибку 8914.
ищите сами описание ошибки, или структуру PFS-страниц, или структуру заголовка страницы кучи
23 май 16, 17:19    [19208870]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
o-o
Guest
iljy
o-o,

https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=8&ved=0ahUKEwilkOaTrfDMAhUsIpoKHbpYAyQQFghJMAc&url=http://www.sqlpass.org/EventDownload.aspx?suid=3646&usg=AFQjCNFAHtHlgHQlfVw2rGu7Es_99oCpbQ&sig2=ZQBCWQG9WWZJTTnSVlKrqg


Обратите внимание на PFS-страницы (это к вопросу о хранении заполненности).

и что вам не нравится-то?
цитату сюда можете вставить или почему это мне все это надо читать?
я в курсе организации PFS-страниц,
равно как и заголовков (HEADER) страниц данных.
и для индексов в pct_full бурда, для куч наоборот, поддерживаемая информация
23 май 16, 17:20    [19208872]     Ответить | Цитировать Сообщить модератору
 Re: Как понять почему Rebuild индекса делается столько времени  [new]
o-o
Guest
TaPaK
было
автор
Заполненность страниц хранится только для куч, а у вас индекс.

стало
o-o
to TaPaK
dbcc checkdb кроме всего прочего сверяет хранящееся в заголовке страницы pct_full
с хранящимся в соответствующей странице PFS.
и если не совпадает, вываливает ошибку 8914.
ищите сами описание ошибки, или структуру PFS-страниц, или структуру заголовка страницы кучи

вы меня достали своими претензиями, ищите сами.
вот вам и вот:
автор
For data pages in a heap, the free space count is checked against the corresponding byte in the
relevant PFS page. If the two don’t match, error 8914 is reported

на это ищите и на то что выше было дано.
и напишите уже сюда, где же то же самое для индексов хранится, поддерживается, сверяется
23 май 16, 17:24    [19208891]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить