Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Как на самом деле работает ротация transaction log?  [new]
MSSQLBug
Guest
Доброе утро.
Тема выделена из этой: https://www.sql.ru/forum/1134324/kogda-shrink-loga-deystvitelno-pomogaet .

Вопрос в том, что в BOL написано одно (http://technet.microsoft.com/en-us/library/ms179355(v=sql.105).aspx), а при тестировании получается другое:

  • However, if the end of the logical log does reach the start of the logical log ... the file is extended by the amount specified in growth_increment and the new log records are added to the extension.
    А в тесте видно, что рост происходит заранее.
  • When the end of the logical log reaches the end of the physical log file, the new log records wrap around to the start of the physical log file.
    А здесь видно, что вовсе не "to the start of the physical log file".

    Я тут повторю пример из той темы:

    CREATE DATABASE [Test] ON PRIMARY (
       NAME = N'Test', FILENAME = N'D:\testbase\Test.mdf',
       SIZE = 131072KB, FILEGROWTH = 65536KB
       ) LOG ON (
       NAME = N'Test_log', FILENAME = N'D:\testbase\Test_log.ldf',
       SIZE = 1024KB, FILEGROWTH = 1024KB
       )
    GO
    use Test;
    GO
    CREATE TABLE dbo.LogTable (RowID decimal(10,4), Data char(1024))
    GO
    --------------------------------------
    -- Затем:
    INSERT INTO LogTable VALUES (ROUND((RAND()* 1000000),0), SPACE(1024))
    GO 200
    
    --------------------------------------
    -- Потом:
    INSERT INTO LogTable VALUES (ROUND((RAND()* 1000000),0), SPACE(1024))
    GO 200
    CHECKPOINT
    DBCC LOGINFO
    
    -- Результат --- последний VLF активен:
    

    RecoveryUnitIdFileIdFileSizeStartOffsetFSeqNoStatusParityCreateLSN
    022539528192340640
    02253952262144350640
    02253952516096360640
    02278528770048372640


    -- Для заполнения VLF-ов:
    BEGIN TRANSACTION
    -- Заполнить 3 VLF-а:
    INSERT INTO LogTable VALUES (ROUND((RAND()* 1000000),0), SPACE(1024))
    GO 400
    DBCC LOGINFO
    


    -- Результат:
    RecoveryUnitIdFileIdFileSizeStartOffsetFSeqNoStatusParityCreateLSN
    0225395281923821280
    022539522621443921280
    02253952516096360640
    02278528770048372640


    -- И наконец-то начинается самое интересное: ;)
    INSERT INTO LogTable VALUES (ROUND((RAND()* 1000000),0), SPACE(1024))
    GO 100
    DBCC LOGINFO
    


    RecoveryUnitIdFileIdFileSizeStartOffsetFSeqNoStatusParityCreateLSN
    0225395281923821280
    022539522621443921280
    02253952516096360640
    02278528770048372640
    02253952104857600039000000003100035
    02253952130252800039000000003100035
    02253952155648000039000000003100035
    02286720181043200039000000003100035

    Т.е. здесь лог вырос, хотя VLF c StartOffset = 516096 ещё свободен!
    -- Но дальше больше:
    INSERT INTO LogTable VALUES (ROUND((RAND()* 1000000),0), SPACE(1024))
    GO 100
    DBCC LOGINFO
    

    Заполняется не этот VLF, а один из новых добавленных:
    RecoveryUnitIdFileIdFileSizeStartOffsetFSeqNoStatusParityCreateLSN
    0225395281923821280
    022539522621443921280
    02253952516096360640
    02278528770048372640
    0225395210485764026439000000003100035
    02253952130252800039000000003100035
    02253952155648000039000000003100035
    02286720181043200039000000003100035


    -- Ну и так далее:
    INSERT INTO LogTable VALUES (ROUND((RAND()* 1000000),0), SPACE(1024))
    GO 200
    DBCC LOGINFO
    


    RecoveryUnitIdFileIdFileSizeStartOffsetFSeqNoStatusParityCreateLSN
    0225395281923821280
    022539522621443921280
    02253952516096360640
    02278528770048372640
    0225395210485764026439000000003100035
    0225395213025284126439000000003100035
    02253952155648000039000000003100035
    02286720181043200039000000003100035


    -- Теперь завершить эту транзакцию, очистить LOG:
    COMMIT
    CHECKPOINT
    DBCC LOGINFO
    


    RecoveryUnitIdFileIdFileSizeStartOffsetFSeqNoStatusParityCreateLSN
    0225395281923801280
    022539522621443901280
    02253952516096360640
    02278528770048370640
    0225395210485764006439000000003100035
    0225395213025284126439000000003100035
    02253952155648000039000000003100035
    02286720181043200039000000003100035


    А теперь можно посмотреть, в каком порядке будут использоваться VLF-ы, повторяя:

    INSERT INTO LogTable VALUES (ROUND((RAND()* 1000000),0), SPACE(1024))
    GO 100
    CHECKPOINT
    DBCC LOGINFO
    


    У меня это доходит до:
    RecoveryUnitIdFileIdFileSizeStartOffsetFSeqNoStatusParityCreateLSN
    0225395281923801280
    022539522621443901280
    02253952516096360640
    02278528770048370640
    0225395210485764006439000000003100035
    0225395213025284106439000000003100035
    0225395215564804206439000000003100035
    0228672018104324326439000000003100035

    А следующий ход:

    RecoveryUnitIdFileIdFileSizeStartOffsetFSeqNoStatusParityCreateLSN
    0225395281923801280
    022539522621443901280
    022539525160964421280
    02278528770048370640
    0225395210485764006439000000003100035
    0225395213025284106439000000003100035
    0225395215564804206439000000003100035
    0228672018104324306439000000003100035


    Как это на самом деле работает?
  • 9 янв 15, 09:32    [17095979]     Ответить | Цитировать Сообщить модератору
     Re: Как на самом деле работает ротация transaction log?  [new]
    o-o
    Guest
    MSSQLBug,
    вы так все желание с вами общаться нафиг отобьете.
    ведь пишу [видимо, для стен] (еще в той прежней теме): он не "заранее лог нарастил" от нефиг делать, а просчитал, сколько места надо под роллбэк, на мелких транзакциях не видно, на больших зато заметно.
    другое дело, что потом то место не использовал, т.к. роллбэка не было.
    но если бы вы его рост ограничили сразу, та ваша транзакция бы просто обломалась по причине 9002.
    т.к. под любую транзакцию он резервирует минимум вдвое больше места, чем надо.
    вопрос совсем не в этом на самом деле, а в том, почему он перешел после приращения сразу к использованию вновь добавленного,
    а тут у меня пока идей нет, т.е. есть, но надо еще время подумать/проверить, а если у вас времени хоть отбавляй,
    возьмите HEX-editor и вручную посмотрите, не закакал ли он попутно заодним то место, что резервировал.
    9 янв 15, 11:27    [17096111]     Ответить | Цитировать Сообщить модератору
     Re: Как на самом деле работает ротация transaction log?  [new]
    MSSQLBug
    Guest
    o-o
    MSSQLBug,
    вы так все желание с вами общаться нафиг отобьете.

    Взаимно.

    o-o
    ведь пишу [видимо, для стен] (еще в той прежней теме): он не "заранее лог нарастил" от нефиг делать, а просчитал, сколько места надо под роллбэк, на мелких транзакциях не видно, на больших зато заметно.


    Видимо, для стен: А вы здесь не один, и ту тему могли читать не все.
    И, кроме того, получается, что в официальной документации описано неправильно (или упрощённо).

    o-o
    другое дело, что потом то место не использовал, т.к. роллбэка не было.
    но если бы вы его рост ограничили сразу, та ваша транзакция бы просто обломалась по причине 9002.
    т.к. под любую транзакцию он резервирует минимум вдвое больше места, чем надо.
    вопрос совсем не в этом на самом деле, а в том, почему он перешел после приращения сразу к использованию вновь добавленного,

    Этот момент тоже непонятен.

    o-o
    а тут у меня пока идей нет, т.е. есть, но надо еще время подумать/проверить, а если у вас времени хоть отбавляй,
    возьмите HEX-editor и вручную посмотрите, не закакал ли он попутно заодним то место, что резервировал.

    К сожалению, времени у меня тоже не вагон, поэтому и спрашиваю --- может, кто-то и так знает.

    Мне лично более интересно вот это:
    MSSQLBug
    А здесь видно, что вовсе не "to the start of the physical log file".
    9 янв 15, 11:47    [17096164]     Ответить | Цитировать Сообщить модератору
     Re: Как на самом деле работает ротация transaction log?  [new]
    o-o
    Guest
    MSSQLBug
    o-o
    MSSQLBug,
    вы так все желание с вами общаться нафиг отобьете.

    Взаимно.

    а я вас где-то невнимательно читаю, делаю вид, что писали совсем не мне,
    изображаю, что написана чушь, ничем не подкрепленная?
    в общем отлично, договорились, на том и разойдемся, мне что-то слишком больше всех надо в последнее время

    P.S.
    MSSQLBug
    И, кроме того, получается, что в официальной документации описано неправильно (или упрощённо).

    да, вот именно. про лог -- далеко не все и упрощенно.
    если я делюсь ссылками на прочитанное, то чтобы кому-то сэкономить время на поиски.
    но если по ним и ходить не желают, то уж извините, со стенами беседовать -- на форум ходить не надо,
    в наличии вокруг меня и без того имеются.
    9 янв 15, 12:03    [17096211]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить