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

Откуда: Кишинёв
Сообщений: 6724
Правильно ли я понимаю?:
  • Балансировки индекса срабатывает на момент вставки (не фоново)
  • Если при очередной вставке данных срабатывает условие балансировки индекса, то он естественно должен захватить все страницы которые попали в балансировку
  • Соответственно параллельные вставки блокируются этим процессом

    Fill Factor кардинально уменьшает вероятность?
    Нужно периодически ручками (Job) приводить его в соответствие?

    Рассматриваемый случай: на фоне большого числа мелких однострочных операций запускается (Job) одна операция с большим числом строк.
    Serialize чтение большого куска данных не даёт вставить новые строки: Range-S (IO wait) <- IX(N потоков) <- IX(N2 потоков)
    Если я правильно понял
  • 17 июн 11, 16:13    [10829624]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    1d0
    Member

    Откуда: инфа100%
    Сообщений: 2521
    Mnior
    Правильно ли я понимаю?:
  • Балансировки индекса срабатывает на момент вставки (не фоново)
  • Если при очередной вставке данных срабатывает условие балансировки индекса, то он естественно должен захватить все страницы которые попали в балансировку
  • Соответственно параллельные вставки блокируются этим процессом

    Fill Factor кардинально уменьшает вероятность?
    Нужно периодически ручками (Job) приводить его в соответствие?

    Рассматриваемый случай: на фоне большого числа мелких однострочных операций запускается (Job) одна операция с большим числом строк.
    Serialize чтение большого куска данных не даёт вставить новые строки: Range-S (IO wait) <- IX(N потоков) <- IX(N2 потоков)
    Если я правильно понял


  • балансировка - это в смысле reorganize \rebuild

    при вставке индексы лучше всего отключать
    17 июн 11, 16:18    [10829685]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    1d0
    балансировка - это в смысле reorganize \rebuild
    Нет.
    Индексы в РСУБД сбалансированны (см. красно-чёрные деревья, высота дерева, доки по физике индексов).

    Сообщение было отредактировано: 17 июн 11, 21:50
    17 июн 11, 16:21    [10829733]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда:
    Сообщений: 37254
    Mnior
    Fill Factor кардинально уменьшает вероятность?
    Рассуждать о том, что fillfactor уменьшит количество сплитов страниц при вставке данных (а это и есть, собственно, и вся балансировка при вставке), лучше все-таки зная характер индекса и характер вставляемых данных.
    17 июн 11, 16:39    [10829970]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    Гавриленко Сергей Алексеевич
    характер индекса и характер вставляемых данных.
    PK_Table по IDENTUTY(1,1).
    17 июн 11, 16:53    [10830111]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда:
    Сообщений: 37254
    Mnior
    PK_Table по IDENTUTY(1,1).

    Отвечая на вопрос по FF: он тут ничем не поможет, даже наоборот, чем меньше FF, тем больше сплитов. Но. Сплитится будет всегда последняя страница, поэтому влияние сплита на скорость вставки минимальна.

    А про блокировки я как-то не понял, если честно, как вы их сюда хотите привязать.
    17 июн 11, 17:12    [10830347]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    Гавриленко Сергей Алексеевич
    А про блокировки я как-то не понял, если честно, как вы их сюда хотите привязать.
    Ну я так понимаю, что для операции сплит, KEY блокировка должна расширится до уровня PAGE (нескольких). Нет разве?
    17 июн 11, 17:30    [10830535]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда:
    Сообщений: 37254
    Mnior
    Гавриленко Сергей Алексеевич
    А про блокировки я как-то не понял, если честно, как вы их сюда хотите привязать.
    Ну я так понимаю, что для операции сплит, KEY блокировка должна расширится до уровня PAGE (нескольких). Нет разве?
    Я тут пример сделал, чтобы посмотреть, до чего она расширяется...

    -- На страницу влезает 8 ключей, заполняем 8 страниц. При добавлении следующей записи появится 9я страница и еще 1 уровень в дереве.
    if @@trancount > 0 rollback
    go
    if exists(select * from information_schema.tables where table_schema = 'dbo' and table_name = 'TestSplit')
    	drop table dbo.TestSplit
    go
    create table dbo.TestSplit(
        [key]   binary (900)    not null
        , primary key (
            [key]
        )
    )
    go
    insert dbo.TestSplit (
        [key]
    )
                select 0x00
    union all   select 0x01
    union all   select 0x02
    union all   select 0x03
    union all   select 0x04
    union all   select 0x05
    union all   select 0x06
    union all   select 0x07
    union all   select 0x08
    union all   select 0x09
    union all   select 0x10
    union all   select 0x11
    union all   select 0x12
    union all   select 0x13
    union all   select 0x14
    union all   select 0x15
    union all   select 0x16
    union all   select 0x17
    union all   select 0x18
    union all   select 0x19
    union all   select 0x20
    union all   select 0x21
    union all   select 0x22
    union all   select 0x23
    union all   select 0x24
    union all   select 0x25
    union all   select 0x26
    union all   select 0x27
    union all   select 0x28
    union all   select 0x29
    union all   select 0x30
    union all   select 0x31
    union all   select 0x32
    union all   select 0x33
    union all   select 0x34
    union all   select 0x35
    union all   select 0x36
    union all   select 0x37
    union all   select 0x38
    union all   select 0x39
    union all   select 0x40
    union all   select 0x41
    union all   select 0x42
    union all   select 0x43
    union all   select 0x44
    union all   select 0x45
    union all   select 0x46
    union all   select 0x47
    union all   select 0x48
    union all   select 0x49
    union all   select 0x50
    union all   select 0x51
    union all   select 0x52
    union all   select 0x53
    union all   select 0x54
    union all   select 0x55
    union all   select 0x56
    union all   select 0x57
    union all   select 0x58
    union all   select 0x59
    union all   select 0x60
    union all   select 0x61
    union all   select 0x62
    union all   select 0x63
    
    go
    
    begin tran
    insert dbo.TestSplit([key]) values(0x64)
    exec sp_lock
    select * from sys.dm_db_index_physical_stats(DB_ID(), object_id('dbo.TestSplit'),null,null,'sampled')
    --rollback


    Сообщение было отредактировано: 18 июн 11, 00:07
    17 июн 11, 17:36    [10830598]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда:
    Сообщений: 37254
    Mnior
    Ну я так понимаю, что для операции сплит, KEY блокировка должна расширится до уровня PAGE (нескольких). Нет разве?
    По факту, выходит, что нет. Интент на две страницы, и экслюзивная на вставленный ключ.

    З.Ы. В, общем, в мой скрипт вначале надо вставить if @@trancount > 0 rollback, а то при повторном запуске скрипта фигня будет. :)
    17 июн 11, 18:07    [10830898]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    Гавриленко Сергей Алексеевич, Спасибо!
    begin tran
    select * from sys.dm_db_index_physical_stats(DB_ID(), object_id('dbo.TestSplit'),null,null,'sampled')
    insert dbo.TestSplit([key]) values(0x64)
    exec sp_lock
    select * from sys.dm_db_index_physical_stats(DB_ID(), object_id('dbo.TestSplit'),null,null,'sampled')
    rollback
    select * from sys.dm_db_index_physical_stats(DB_ID(), object_id('dbo.TestSplit'),null,null,'sampled')
    
    database_idobject_idindex_idindex_depthpage_countrecord_countavg_record_size_in_bytes
    252305754512864907

    spiddbidObjIdIndIdTypeResourceModeStatus
    72200DB[ENCRYPTION_SCAN] SGRANT
    7225230575450TAB IXGRANT
    7225230575451KEY(64008ccccc0d) XGRANT
    7225230575451PAG1:163715 IXGRANT
    7225230575451PAG1:163712 IXGRANT

    database_idobject_idindex_idindex_depthpage_countrecord_countavg_record_size_in_bytes
    252305754513965907

    database_idobject_idindex_idindex_depthpage_countrecord_countavg_record_size_in_bytes
    252305754513964907
    Получается что неправда. Блокировки логические, и физика индекса на это не влияет. Притом хоть дофига параллельно процессов заливают, блокировок нет.

    Тогда перед вставкой параллельно запустим:
    begin tran
    SELECT * FROM dbo.TestSplit WITH(Serializable)
    WHERE [key] BETWEEN 0x00 AND 0x63
    Тогда будет блокировка, хотя 0x64 не входит в диапазон. Но если заменить в BETWEEN на 0x63, то всё нормально - блокировок нет. Serializable, получается локирует краевых "соседей"(ffffffffffff):
    + sp_lock
    spiddbidObjIdIndIdTypeResourceModeStatus
    56212430601101KEY(570017afb7c4) RangeS-SGRANT
    56212430601101KEY(12003976b382) RangeS-SGRANT
    56212430601101KEY(23004a5bcb25) RangeS-SGRANT
    56212430601101PAG1:405 ISGRANT
    56212430601101PAG1:404 ISGRANT
    56212430601101PAG1:407 ISGRANT
    56212430601101PAG1:406 ISGRANT
    56212430601101PAG1:400 ISGRANT
    56212430601101PAG1:403 ISGRANT
    56212430601101PAG1:499 ISGRANT
    56212430601101KEY(420071ee48e9) RangeS-SGRANT
    56212430601101KEY(ffffffffffff) RangeS-SGRANT
    56212430601101PAG1:163899 ISGRANT
    56212430601101PAG1:163896 ISGRANT
    56212430601101KEY(45003d9a4c6c) RangeS-SGRANT
    56212430601101KEY(00001343482a) RangeS-SGRANT
    56212430601101KEY(5900ce41ce15) RangeS-SGRANT
    56212430601101KEY(3100606e308d) RangeS-SGRANT
    56212430601101KEY(3200fc8732d4) RangeS-SGRANT
    56212430601101KEY(4600a1734e35) RangeS-SGRANT
    56212430601101KEY(03008faa4a73) RangeS-SGRANT
    56212430601101KEY(27009ac6cdf9) RangeS-SGRANT
    56212430601101KEY(6200b41fc9bf) RangeS-SGRANT
    56212430601101KEY(5300c732b118) RangeS-SGRANT
    56212430601101KEY(1600e9ebb55e) RangeS-SGRANT
    56212430601101KEY(3500b0f33651) RangeS-SGRANT
    56212430601101KEY(18003005cc8f) RangeS-SGRANT
    56212430601101KEY(4100ed074ab0) RangeS-SGRANT
    56212430601101KEY(29004328b428) RangeS-SGRANT
    56212430601101KEY(0400c3de4ef6) RangeS-SGRANT
    56212430601101KEY(4800789d37e4) RangeS-SGRANT
    56212430601101KEY(2000d6b2c97c) RangeS-SGRANT
    56212430601101KEY(54008b46b59d) RangeS-SGRANT
    56212430601101KEY(1100a59fb1db) RangeS-SGRANT
    56212430601101KEY(6300c0b8c888) RangeS-SGRANT
    56212430601101KEY(2600ee61ccce) RangeS-SGRANT
    56212430601101KEY(17009d4cb469) RangeS-SGRANT
    56212430601101KEY(5200b395b02f) RangeS-SGRANT
    56212430601101KEY(07005f374caf) RangeS-SGRANT
    56212430601101KEY(36002c1a3408) RangeS-SGRANT
    56212430601101KEY(50005bdbb341) RangeS-SGRANT
    56212430601101KEY(3800f5f44dd9) RangeS-SGRANT
    56212430601101KEY(15007502b707) RangeS-SGRANT
    56212430601101KEY(2400062fcfa0) RangeS-SGRANT
    56212430601101KEY(090086d9357e) RangeS-SGRANT
    56212430601101KEY(610028f6cbe6) RangeS-SGRANT
    56212430601101KEY(3300882033e3) RangeS-SGRANT
    56212430601101KEY(0200fb0d4b44) RangeS-SGRANT
    56212430601101KEY(4700d5d44f02) RangeS-SGRANT
    56212430601101KEY(49000c3a36d3) RangeS-SGRANT
    56212430601101KEY(2100a215c84b) RangeS-SGRANT
    56212430601101KEY(1000d138b0ec) RangeS-SGRANT
    56212430601101KEY(5500ffe1b4aa) RangeS-SGRANT
    56212430601101KEY(190044a2cdb8) RangeS-SGRANT
    56212430601101KEY(3400c4543766) RangeS-SGRANT
    56212430601101KEY(0500b7794fc1) RangeS-SGRANT
    56212430601101KEY(400099a04b87) RangeS-SGRANT
    56212430601101KEY(2800378fb51f) RangeS-SGRANT
    56212430601101KEY(06002b904d98) RangeS-SGRANT
    56212430601100TAB ISGRANT
    56212430601101KEY(4300054949de) RangeS-SGRANT
    56212430601101KEY(370058bd353f) RangeS-SGRANT
    56212430601101KEY(13004dd1b2b5) RangeS-SGRANT
    56212430601101KEY(56006308b6f3) RangeS-SGRANT
    56212430601101KEY(22003efcca12) RangeS-SGRANT
    56212430601101KEY(010067e4491d) RangeS-SGRANT
    56212430601101KEY(4400493d4d5b) RangeS-SGRANT
    56212430601101KEY(5800bae6cf22) RangeS-SGRANT
    56212430601101KEY(300014c931ba) RangeS-SGRANT
    56212430601101KEY(140001a5b630) RangeS-SGRANT
    56212430601101KEY(51002f7cb276) RangeS-SGRANT
    56212430601101KEY(390081534cee) RangeS-SGRANT
    56212430601101KEY(0800f27e3449) RangeS-SGRANT
    56212430601101KEY(60005c51cad1) RangeS-SGRANT
    56212430601101KEY(25007288ce97) RangeS-SGRANT
    60200DB[ENCRYPTION_SCAN] SGRANT
    72212430601101KEY(ffffffffffff) RangeIn-WAIT
    72212430601100TAB IXGRANT
    72212430601101PAG1:163899 IXGRANT


    Ok. Буду копать дальше по своей ситуации (добыть больше инфы по блокировкам).
    17 июн 11, 18:57    [10831334]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    Очепятка:
    Mnior
    Тогда будет блокировка, хотя 0x64 не входит в диапазон. Но если заменить в BETWEEN с 0x63 на 0x62, то всё нормально - блокировок нет.
    17 июн 11, 21:13    [10831828]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда:
    Сообщений: 37254
    Гавриленко Сергей Алексеевич
    Mnior
    PK_Table по IDENTUTY(1,1).

    Отвечая на вопрос по FF: он тут ничем не поможет, даже наоборот, чем меньше FF, тем больше сплитов. Но. Сплитится будет всегда последняя страница, поэтому влияние сплита на скорость вставки минимальна.
    Яркий пример того, что в пятницу после обеда думать надо запретить законодательно. :)

    В общем, тут я чушь написал. При последовательной вставке в конец индекса сплитов не будет вообще. Странички что на листовом уровне, что выше, будут последовательно заполняться и все. Ну и FF тут тоже не при чем, он вообще поддерживается сервером только во время ребилда или пересоздания индекса.
    19 июн 11, 09:51    [10835998]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда:
    Сообщений: 37254
    Но при реальном сплите картина по блокировкам та же:
    -- На страницу влезает 8 ключей, заполняем 8 страниц. При добавлении следующей записи появится 9я страница и еще 1 уровень в дереве.
    if @@trancount > 0 rollback
    go
    if exists(select * from information_schema.tables where table_schema = 'dbo' and table_name = 'TestSplit')
    	drop table dbo.TestSplit
    go
    create table dbo.TestSplit(
        [key]   binary (900)    not null
        , primary key (
            [key]
        )
    )
    go
    insert dbo.TestSplit (
        [key]
    )
                select 0x00
    union all   select 0x01
    union all   select 0x02
    union all   select 0x03
    union all   select 0x04
    union all   select 0x05
    union all   select 0x06
    union all   select 0x07
    union all   select 0x08
    union all   select 0x09
    union all   select 0x10
    union all   select 0x11
    union all   select 0x12
    union all   select 0x13
    union all   select 0x14
    union all   select 0x15
    union all   select 0x16
    union all   select 0x17
    union all   select 0x18
    union all   select 0x19
    union all   select 0x20
    union all   select 0x21
    union all   select 0x22
    union all   select 0x23
    union all   select 0x24
    union all   select 0x25
    union all   select 0x26
    union all   select 0x27
    union all   select 0x28
    --union all   select 0x29
    union all   select 0x30
    union all   select 0x31
    union all   select 0x32
    union all   select 0x33
    union all   select 0x34
    union all   select 0x35
    union all   select 0x36
    union all   select 0x37
    union all   select 0x38
    union all   select 0x39
    union all   select 0x40
    union all   select 0x41
    union all   select 0x42
    union all   select 0x43
    union all   select 0x44
    union all   select 0x45
    union all   select 0x46
    union all   select 0x47
    union all   select 0x48
    union all   select 0x49
    union all   select 0x50
    union all   select 0x51
    union all   select 0x52
    union all   select 0x53
    union all   select 0x54
    union all   select 0x55
    union all   select 0x56
    union all   select 0x57
    union all   select 0x58
    union all   select 0x59
    union all   select 0x60
    union all   select 0x61
    union all   select 0x62
    union all   select 0x63
    union all   select 0x64
    
    go
    
    begin tran
    insert dbo.TestSplit([key]) values(0x29)
    exec sp_lock
    select * from sys.dm_db_index_physical_stats(DB_ID(), object_id('dbo.TestSplit'),null,null,'sampled')
    --rollback
    
    spid   dbid   ObjId       IndId  Type Resource                         Mode     Status
    ------ ------ ----------- ------ ---- -------------------------------- -------- ------
    ...
    55     5      1704977421  1      PAG  1:717                            IX       GRANT
    55     5      1704977421  1      KEY  (29004328b428)                   X        GRANT
    55     5      1704977421  1      PAG  1:2827                           IX       GRANT
    55     5      1704977421  0      TAB                                   IX       GRANT
    
    19 июн 11, 09:58    [10836001]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    Гавриленко Сергей Алексеевич
    При последовательной вставке в конец индекса сплитов не будет вообще.
    Это почему?
    В первом примере видно что при ROLLBACK страниц осталось 9. Вроде всё логично, последняя 8-ая страница разделилась пополам на 9-ую. Откатив строку всё так пополам и осталось, разве avg_page_space_used_in_percent разве об этом не говорит? (сейчас не могу посмотреть повторно)

    Но вообще конечно логично - меньше разделений/переноса/слияний.

    Вот только у меня опять проблема в понимании (примеров больше надо). С параллельной вставкой проблем нет, т.к. PAG:IX разных процессов не блокируют друг друга. Так? Нужен пример со вставкой не одной строки, а сразу в несколько PAG-ов.

    Допустим кто-то заблокировал всю страницу PAG:(X,S,RangeS-S), а параллельно кто что-то сделал в соседней странице (добавил, удалил) и типа должен сработать сплит/мердж. Что будет делать скуль?
  • Будет блокировка
  • Преобразует PAG в набор KEY
  • мердж не сработает, хоть по одной строке будет на страницах, сплит не сработает - создаст с одной строкой без переноса

    Во всех примерах были только KEY уровня локировки с соответствующими им PAG. (KEY без PAG не бывает). Нужен пример с чистым PAG, без из KEY-ев. (жаль скуля пока нет под рукой)
  • 19 июн 11, 14:15    [10836416]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда:
    Сообщений: 37254
    Mnior
    Гавриленко Сергей Алексеевич
    При последовательной вставке в конец индекса сплитов не будет вообще.
    Это почему?
    В первом примере видно что при ROLLBACK страниц осталось 9. Вроде всё логично, последняя 8-ая страница разделилась пополам на 9-ую. Откатив строку всё так пополам и осталось, разве avg_page_space_used_in_percent разве об этом не говорит? (сейчас не могу посмотреть повторно)
    Надо, короче, dbcc page посмотреть (мне еще песня про 907 байт нравится :). Но, по идее, не должно быть сплита, потому как при последовательной вставке получалось бы, что все страницы останутся наполовину заполненными (каждая - после своего сплита). И мы бы об этом знали. ;)

    Mnior
    Вот только у меня опять проблема в понимании (примеров больше надо). С параллельной вставкой проблем нет, т.к. PAG:IX разных процессов не блокируют друг друга. Так?
    Интенты между собой совместимы, да.

    Насчет остального - посмотрю завтра на работе.

    Сообщение было отредактировано: 19 июн 11, 17:52
    19 июн 11, 17:51    [10836950]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Гадя Петрович
    Member

    Откуда: планета Плюк, 215 в тентуре, галактика Кин-дза-дза в Спирали
    Сообщений: 52912
    Гавриленко Сергей Алексеевич,

    немного оффтоп: есть на примете книжки как и почему строятся B-tree применительно к сиквелу?
    ну или статьи :)
    19 июн 11, 19:03    [10837191]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    Гадя Петрович, Design SQL Server: Индексы, Теоретические основы
    sql.ru это не только форум
    и зачем обращаться лично, это же форум
    19 июн 11, 22:47    [10837762]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mind
    Member

    Откуда: Лучший город на Земле
    Сообщений: 2322
    Гавриленко Сергей Алексеевич
    Гавриленко Сергей Алексеевич
    пропущено...

    Отвечая на вопрос по FF: он тут ничем не поможет, даже наоборот, чем меньше FF, тем больше сплитов. Но. Сплитится будет всегда последняя страница, поэтому влияние сплита на скорость вставки минимальна.
    Яркий пример того, что в пятницу после обеда думать надо запретить законодательно. :)

    В общем, тут я чушь написал. При последовательной вставке в конец индекса сплитов не будет вообще. Странички что на листовом уровне, что выше, будут последовательно заполняться и все. Ну и FF тут тоже не при чем, он вообще поддерживается сервером только во время ребилда или пересоздания индекса.

    Ага, физически сплитов не будет, а формально будут. Если посмотреть в Perf Monitor, то каждое такое создание новой страницы считается сплитом. Что делает этот счетчик весьма мутным для анализа, потому что непонятно, то ли в системе куча реальных сплитов, то ли просто идут большие вставки в таблицу.

    И кстати не только при последовательной вставке в конец индекса не будет сплитов. Но и в середину тоже, при определенных условиях. Например если есть индекс по слабо селективном полю, например DocumentTypeID (+ кластерный индекс естественно), которое скажем принимает значения от 1 до 5, то с большой вероятностью, около 5 сплитов будет только в начале добавления данных в этот индекс, и то сплиты будут не 50/50 как написано в книжках, а четко по границе DocumentTypeID. После чего у индекса появится 5 "хвостов", которые будут последовательно заполнятся. Будет конечно фрагментация, но реальных сплитов больше не будет.
    5 янв 12, 21:12    [11863102]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    andrey odegov
    Member

    Откуда:
    Сообщений: 473
    при балансировке возможно расщепление страниц не конечного уровня (leaf level)?
    5 янв 12, 23:21    [11863425]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    Mind, вы это где-то прочитали или экспериментом?

    andrey odegov
    при балансировке возможно расщепление страниц не конечного уровня (leaf level)?
    10836001

    Mnior, топик про логирование, также подсказывает, что логика блокировок не затрагивает физику страниц и индексов в частности.
    6 янв 12, 00:29    [11863605]     Ответить | Цитировать Сообщить модератору
     Re: Блокировки, балансировка индекса  [new]
    Mind
    Member

    Откуда: Лучший город на Земле
    Сообщений: 2322
    Mnior
    Mind, вы это где-то прочитали или экспериментом?


    Экспериментом. Скриптов я уже наверное не найду, но там ничего сложного.
    Причем там некоторые хитрые условия. Если скажем в индекс по DocumentTypeId вставляются данные в таком порядке:

    4
    3
    3 <-- при всавке этого значения место на странице кончилось, то страница будет разделена четко по границе значений 3 и 4.

    Если же вставка была такая:
    3
    4
    3 <-- то страница будет поделена 50/50, что не совсем хорошо, потому что на одной из получившихся страниц будет микс из значений 3 и 4, что в дальнейшем приведет опять к сплиту.

    Судя по всему если 2 последних вставленных значения были одинаковые то сервер может отследить закономерность и сделать более правильный сплит. Но я нигде не нашел описание такого поведения. Except that Paul S. Randal has mentioned it in his blog: "You can try this yourself if you want: I changed the code to have a CHAR (10), inserted values 1, 2, 3, 4, 6, 7, then inserted 256 key values of 8 and then 2 of 5. The resulting page had only 6 rows - it split after the key value 5 - the Storage Engine doesn't always do a 50/50 page split."

    http://www.sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx
    7 янв 12, 01:24    [11866856]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить