Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток!!!! Объясните неграмотному, почему так.... CREATE TABLE A ( ONE INT, TWO CHAR(15), CONSTRAINT PK PRIMARY KEY CLUSTERED (ONE ) ) GO CREATE NONCLUSTERED INDEX IDX001 ON A( TWO ); GO INSERT INTO A VALUES(1, 'HELLO') GO SET SHOWPLAN_TEXT ON GO UPDATE A SET TWO = 'good-bye' WHERE ONE =1 Result: StmtText |--Clustered Index Update(OBJECT[od_Test].[dbo].[A].[PK]), SET[A].[TWO]=[Expr1004]), DEFINE[Expr1004]=Convert([@1])), WHERE[A].[ONE]=[@2])) Почему происходит UPDATE кластерного индекса? Это что - если есть кластерные индексы, то при изменении любого поля из любого другого индекса будет происходить update кластерного? Это ж X блокировки. Это ж тормоза.... Спасибо. Олег. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2002, 12:53 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
Я не знаю, как у них устроен кластерный индекс, но, если он, например, B+ дерево с листьями размером одна страница, то update любого некластерного поля может привести к переполнению страницы. Как следсвие, к ее расщеплению, вставке нового элемента в узел дерева (update индекса), а узел тоже может быть переполнен и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2002, 12:29 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
Причем тут расщепление? Человек вставил одну запись! Анализируем: До update: dbcc tab(6,1893581784) , где 6=db_id('northwind'),1893581784=object_id('a') дает -------------------------------------------------------------------------------- PageFID PagePID IAMFID IAMPID ObjectID IndexID PageType 1 420 NULL NULL 1893581784 1 10 1 419 1 420 1893581784 0 1 1 421 1 420 1893581784 1 2 1 418 NULL NULL 1893581784 2 10 1 417 1 418 1893581784 2 2 -------------------------------------------------------------------------------- После update: тоже самое.Страниц ни прибавилось ни убавилось.Можно посмотреть кластерный индекс: dbcc traceon(3604) dbcc page(6,1,421,1) Я СЧИТАЮ ЧТО ПОД ФРАЗОЙ CLUSTERED INDEX UPDATE подразумевается обновление страницы данных которая в случает кластерного индекса совпадает с ним (в понятии leaf). Т.е обновление кл.индекса=обновление данных с попутным изменением rowmodctr в sysindexes (select * from sysindexes where id=1893581784 and indid=1). Есть другие идеи ? Было бы интересно узнать... Думал про обновление заголовка страницы индекса (в части breference)-не может оно быть "100% estimated cost". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2002, 13:58 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
Насколько я знаю, в кластерных индексах последний уровень (leaf-level) СОВПАДАЕТ с самими данными (поэтому индекс и называется кластерным). Тем не менее мне малопонятно, почему при обновлении поля НЕ ВХОДЯЩЕГО в кластерный индекс, произошло какое-то там действие с кластерным индексом. Кто-нибудь может пролить свет? Единственный вариант, который я могу предложить: после обновления текстового поля запись перестала влазить на страницу, SQL Server распрелелил новую страницу и перенес на нее запись. Тогда кластерный индекс (уровни выше leaf), впрочем как и любой другой - придется обновлять. С другой стороны, поле в примере CHAR(15) т.е. всегда фиксированного размера... Еще один вариант: обновление поля, входящего в некластерный индекс, вызвало перестройку дерева некластерного индекса. В результате этой перестройки пришлось выделять новые страницы,.... см.выше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2002, 15:33 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
ДМИТРИЙ!ИНОГДА НАДО ЧИТАТЬ ОТВЕТЫ ДРУГИХ.Я ЖЕ ЯСНО ПИСАЛ ЧТО DBCC PAGE ПОКАЗЫВАЕТ ЧТО НИКАКОЙ ПЕРЕСТРОЙКИ СТРАНИЦ НЕ ПРОИСХОДИТ!!!ПРИЧЕМ С КАКОГО ОНИ БУДУТ ПЕРЕСТРАИВАТЬСЯ ПРИ УКАЗАННЫХ АВТОРОМ УСЛОВИЯХ (МЫ ИМЕЕМ ОДНУ ЗАПИСЬ НА ТАБЛИЦУ И ЗНАЕМ ДЛИНУ ЗАПИСИ. РАЗМЕР СТРАНИЦЫ 8 КБ).ВАМ ЗАДАЮТ КОНКРЕТНЫЙ ВОПРОС А ВЫ ПРО БОЛЬНУЮ МАМУ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2002, 07:54 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
2Ипатько Игорь: Во-первых, не надо тут ОРАТЬ (и в первом посте орал, и во втором). Во-вторых, Dimos человек мыслящий (судя по постам), поэтому нападать на него не надо. В-третьих, проблема требует большей проработки, т.к. ни один из постов не дал на нее ответа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2002, 08:10 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
Обновление записи происходит путем удаления записи и ее последующей повторной вставки ПРи вставке новой строки с тем же значением кластерного индекса, что и удаленной, она будет размещена на месте старой. (Автор строк - Винкоп). По-видимому, отсюда и Update ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2002, 10:45 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
2 Олег Насколько я себе представляю, кластерного индекса физически не существует. Это просто порядок по которому физически следуют записи. Собственно поэтому он может быть только один. Так что на мой взгляд проблема надумана и что тут можно прорабатывать мне совершенно не понятно. 2 Ольга Выкиньте эту книжку. Она содержит огромное количество неточностей и здесь это уже обсуждалось. В данном случае - что будет если новая запись требует больше места, чем занимала старая? Как новая строка разместиться тогда на месте старой? 2 bik_ Как там у Чехова: Культурный человек, это не тот, который заметит что его сосед... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2002, 11:26 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
блин, большой пардон, ерунду написал Clustered tables are tables that have a clustered index. The data rows are stored in order based on the clustered index key. The index is implemented as a B-tree index structure that supports fast retrieval of the rows based on their clustered index key values. The pages in each level of the index, including the data pages in the leaf level, are linked in a doubly-linked list, but navigation from one level to another is done using key values. ... SQL Server also supports up to 249 nonclustered indexes on each table or indexed view. The nonclustered indexes have a B-tree index structure similar to the one in clustered indexes. The difference is that nonclustered indexes have no effect on the order of the data rows. Так что ответ Ипатько Игоря был исчерпывающим. Переполнения страницы в данном примере быть не могло, т.к. запись имеет фиксированный размер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2002, 11:49 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
В данном случае и Ольга, и Винкоп правы (последний - на редкость). Существует 2 типа обновления. То, что описала Ольга и еще один, именуемый "на месте", это когда передвижек не происходит, а только заменяются значения изменяемых полей. В зависимости от структуры таблицы и самих данных в обновляемой строке, sql-сервер выбирает тот или иной способ обновления. Существует набор правил, соблюдение всех которых заставит sql-сервер обновлять по второму сценарию, менее затратному. Некоторые из правил: отсутствие поля timestamp, неизменность первичного ключа, не больше какого-то строго определенного процента nullable полей, не больше какого-то строго определенного процента с изменяемой длиной, все поля с изменяемой длиной должны быть после полей с неизменяемой длиной, суммарный размер данных после вставки не должен быть больше суммарного размера данных до вставки и т.д. Несоблюдение хоть одного из тех правил приводит к тому, что при update запись будет удаляться, а потом вставляться (пусть даже и то же место). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2002, 13:08 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
to Игорь Вы абсолютно правы. Я упустил, что запись всего одна. Судя же по содержимому sysindexes и соответсвующих страниц в данном случае весь кластерный индекс всего одна страница без всяких уровней дерева...Отсюда и update ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2002, 13:09 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
Приношу свои извинения 2 tmpnick если моя эмоциональность была воспринята как "крик". Причина этого была в одном: уход в сторону идеи расщепления-чего быть не могЁт... 2 _bik : хотел сказать что "Чехов прав..." но нехочу раздувать off-topic -вам здесь равных нет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2002, 09:35 |
|
||
|
Кластерные индексы и Update
|
|||
|---|---|---|---|
|
#18+
Приветствую! 2 г-н Dankov: Теория и книжки это хорошо,но то о чем вы говорите в данном случае не имеет место быть.Точнее имеет место но только по отношению к некластерному индексу.И проверить это довольно легко. Пусть имеем результаты dbcc tab: PagePID ObjectID IndexID PageType 420 1925581898 1 10 419 1925581898 0 1 421 1925581898 1 2 418 1925581898 2 10 417 1925581898 2 2 где страница страница 419-данные,421-класт.индекс,417-некл.индекс. Сделаем dbcc log и зафиксируем LSN до Update.Выполним Update. Сделаем dbcc log и посмотрим то что ниже зафиксированного LSN Operation Object Name Index Name Page ID Slot ID LOP_BEGIN_XACT NULL NULL NULL NULL нач.транзакции LOP_EXPUNGE_ROWS dbo.sysobjects (1) 0 0001:00000054 38 физ.удал.записи из sysobjects LOP_EXPUNGE_ROWS dbo.sysobjects (1) 0 0001:00000054 38 физ.удал.записи из sysobjects LOP_SET_FREE_SPACE dbo.ALLOCATION (99) 0 0001:00000001 0 экстент во free pool LOP_COMMIT_XACT NULL NULL NULL NULL конец транзакции LOP_BEGIN_XACT NULL NULL NULL NULL нач.транзакции LOP_DELETE_ROWS dbo.A (192558189 IDX001(2) 0001:000001a1 0 удаляем зап.в некл.индексе(1a1!!!!!) LOP_SET_FREE_SPACE dbo.ALLOCATION (99) 0 0001:00000001 0 экстент во free pool LOP_MODIFY_ROW dbo.A (192558189 0 0001:000001a3 0 Модиф-я записи в странице данных LOP_INSERT_ROWS dbo.A (192558189 IDX001(2) 0001:000001a1 0 Вставка записи в некл.индекс(1a1!!!!!) LOP_DELTA_SYSIND dbo.sysindexes (2) 0 0001:00000156 34 модиф-я записи в sysindexes LOP_COMMIT_XACT NULL NULL NULL NULL конец транзакции Как видим удаление-вставка происходит только для некл.индекса.Кластерный не затранивается.Запись в странице данных модифицируется на месте без всякого удаления-вставки как это происходит в других случаях. С уважением,Ипатько Игорь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2002, 05:22 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32029726&tid=1822791]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
52ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 267ms |
| total: | 388ms |
| 0 / 0 |
