Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Физическая запись в файлы данных  [new]
Raskolnikov
Member

Откуда:
Сообщений: 52
Приветствую!

У базы стоит полная модель восстановления. По какому-то событию (CHECKPOINT, например) данные сначала пишутся в журнал транзакций, а потом переносятся в файл дынных? Или в оба файла сразу? Можно незамысловато объяснить как проходит этот процесс?

И ещё, добавлю связанный вопросик. Везде где я читал, пишется о том, что фиизческая запись на диск происходит не сразу. Данные сначала сидят в памяти, потом перекидываются файл(ы) данных. А что будет, если в момент между записью файлов на диск потухнет свет, то все, что было в памяти уходит в никуда?
8 июн 13, 21:42    [14410414]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
гологоловый гога
Guest
"...И ещё, добавлю связанный вопросик. Везде где я читал, пишется о том, что фиизческая запись на диск происходит не сразу...."

данные читаются блоками, хранятся блоками и т. п.. записываться должны блоками. запись рандомная блоками - медленно. потому БД старается как можно реже выгружать их на диск.

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

"...А что будет, если в момент между записью файлов на диск потухнет свет, то все, что было в памяти уходит в никуда? ..."

все будет чики пуки. при старте бд накатит redo логи и все закоммиченные транзакции будут восстановлены, не закоммиченные откачены. в результате бд останется консистентной.
8 июн 13, 21:54    [14410434]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Raskolnikov
Member

Откуда:
Сообщений: 52
данные читаются блоками, хранятся блоками и т. п.. записываться должны блоками. запись рандомная блоками - медленно. потому БД старается как можно реже выгружать их на диск.

Это "как можно реже" - это время на самом деле измеряется секундами/долями секунд или же это минуты и более? Просто везде где читал, тоже пишут мол сервер старается как можно реже писать данные на физическое устройство, т.к. это тормоза. И у меня постоянно возникал вопрос как редко?

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

Что такое redo? Я считал, что redo - это фаза, когда SQL сервер восстанавливает базу после краха и накатывает транзакции с какого-то недавнего момента времени (кстати, я был бы очень рад узнать с какого, т.к. более точно, увы, не в курсе). Мы говорим об одном и том же? Если да, то я не понял что куда и когда пишется. И так же не понял как журнал защищает данные в оперативке. :(

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

А где эти redo логи находятся (физически)?
8 июн 13, 22:14    [14410468]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
invm
Member

Откуда: Москва
Сообщений: 9785
Raskolnikov
По какому-то событию (CHECKPOINT, например) данные сначала пишутся в журнал транзакций
Неверно. Читать про Write-ahead logging (WAL) и Writing Pages
Raskolnikov
Это "как можно реже" - это время на самом деле измеряется секундами/долями секунд или же это минуты и более? Просто везде где читал, тоже пишут мол сервер старается как можно реже писать данные на физическое устройство, т.к. это тормоза. И у меня постоянно возникал вопрос как редко?
Частота checkpoint'тов рассчитывается сервером исходя из значения параметра recovery interval, который означает сколько минут может потратить сервер на startup recovery одной БД. Значение 0 (по-умолчанию) значит автоматическую конфигурацию.
Raskolnikov
Что такое redo
В терминах MS SQL, redo - это фаза применения к БД зафиксированных изменений при накате резервной копии журнала или активной части журнала при startup recovery. Соответственно undo - фаза отката незафиксированных изменений.
Raskolnikov
когда SQL сервер восстанавливает базу после краха и накатывает транзакции с какого-то недавнего момента времени (кстати, я был бы очень рад узнать с какого, т.к. более точно, увы, не в курсе).
Сервер при восстановлении БД при старте применяет к ней активную часть журнала. Размер активной части журнала определяется самой старой незавершенной транзакцией. Соответственно, чем больше активный журнал, тем дольше восстанавливается БД при старте.
8 июн 13, 23:19    [14410582]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Raskolnikov
это время на самом деле измеряется секундами/долями секунд или же это минуты и более
Зачем вам такие подробности, это никак не влияет на принцип функционирования.
Чем дольше не выгружать на диск кеш лога (файл данных) тем дольше восстанавливать при сбое.
Raskolnikov
И у меня постоянно возникал вопрос как редко?
Мне кажется вы на таких слухах начинаете придумывать невероятной всякой ерунды. Поправьте если я не прав.
Raskolnikov
Если да, то я не понял что куда и когда пишется. И так же не понял как журнал защищает данные в оперативке. :(
Вы идею совершенно не вкурили. Вот тут разжёвывается идея, самое что ни наесть её серцевина.
Raskolnikov
А где эти redo логи находятся (физически)?
Есть две вещи:
- Логи (лог файл) - самое дорогая и важная часть.
- Данные (кеш лога данных на недавний момент)

Максимальная скорость записи на энерго-независимый носитель (диски) - это последовательная непрерывная запись.
Это и есть логи (забейте на всякие мелочи и названия типа REDO, это не суть, это мишура). В логах тупо пишется все действия. Вставка и изменения данных (старое и новое значение), последовательно и чётко.
Из логов можно получить данные на любой момент времени, от создания базы, до текущего момента.

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

Всё!

Как восстанавливать кеш данных? Просто, в логах есть всё, и когда были сброшены те или иные данные на диск (это тоже пишется - CheckPoint), если небыли сброшены, то данные восстанавливаются из логов (скурпулёзно считываются по кусочкам, последовательно читая лог). Транзакции без коммита - вычищаются (считываются старые значения).
8 июн 13, 23:23    [14410591]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Alexander Titkin
Member

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

Советую для ознакомления - ответы на ваши вопросы
8 июн 13, 23:32    [14410612]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Raskolnikov
Member

Откуда:
Сообщений: 52
invm, Mnior, я не пойму следующего. В литературе пишут о том, что данные не пишутся моментально на диск, а сначала держатся в кеше и только в определенный момент пишутся на диск, при этом в какой-то момент времени данные в кеше и в логе могут отличаться. Причем, вот процитирую со ссылки invm (все цитировать не буду, т.к. зачем копипастить?):

Операции ввода-вывода, выполняемые экземпляром компонента Database Engine, включают в себя операции логической и физической записи. Логическая запись выполняется при изменении данных страницы в буферном кэше. Физическая запись производится при записи страницы из буферного кэша на диск.


и вот ещё кусочек:

«Грязная» страница записывается на диск одним из трех способов.
Отложенная запись
...
Активная запись
...
Контрольная точка


Так вот я все не могу понять: что же случится, если в тот момент, когда записи сидят в каком-то кеше и ещё не записались на диск потухнет свет? Или же данные в журнал транзакций пишутся моментально (как я понял из сообщения Mnior-а; кстати лог и журнал транзакций -это ж мы об одном и том же говорим? :) )?

Alexander Titkin вот как раз на досуге ознакомился. Кое какие вопросы пропали, кое какие появились (в результате чего вы сейчас читаете эту тему и, возможно, будете читать другие :) ).
8 июн 13, 23:49    [14410636]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Raskolnikov, зачем гуманитарию это знать? Зачем троллить нас и делать вид что вам интересно понять смысл?
Вы тупо проигнорировали что тут было написал, чуть менее чем полностью. Спасибо за ваш эгоизм. Побольше смайликов - они типа украшают (FP.JPG).
Если господин Raskolnikov перейдёт на "ведите себя прилично", то точно гуманитарий.
Raskolnikov
В литературе пишут о том, что данные не пишутся моментально на диск
Нормальный, логически мыслящий человек, понимает такое банальнейшее понятие, как контекст.
Слово "данные" не имеют никакого смысла в отрыве от контекста.
Логические, первичные данные - в логе, сбрасываются на диск первыми и сразу. Как только записался лог на диск, транзакция логически завершена. А то что логические данные, физически представлены ещё в форме таблиц, индексов, статистики и других формах не были ещё сброшены в "файл данных" (лучше было назвать "файл кеша", чтоб такие как вы путались в 3х соснах) - это уже второстепенно.
Raskolnikov
Так вот я все не могу понять: что же случится, если в тот момент, когда записи сидят в каком-то кеше и ещё не записались на диск потухнет свет?
Да хоть удалите все "файлы кеша" ("файлы данных") полностью - из полного лога (файла лога и его бекапов) можно восстановить всё до бита.
Вы понимаете каков был контекст? Про что там имели ввиду "сброс кеша"? Это не про лог (файл лога).
Raskolnikov
Или же данные в журнал транзакций пишутся моментально
Какая разница, моментально или микросекунда или 2 дня. Я вам дал ссылку и первый же пост всё отвечает. Команда коммит срабатывает только после того как всё сброшено в файл лога (диск послал сообщение: "данные лога записаны"). И только удачное завершение коммита означает что команда завершена. Удачно. Нет коммита, значит и небыло никаких действий, логически. В моментальности нет смысла, всё во вселенной основывается на порядке событий, связанных одной точкой.
Raskolnikov
кстати лог и журнал транзакций -это ж мы об одном и том же говорим?
Вот вот, кого-то тянет понять смысл, а ого-то как оно внешне выглядит, и как оно называется. Да лог один, и называйте его хоть протерианским - фиолетово. Вы сначала должны понять основу, показать нам что вы поняли, а потом лишь можете приступать к второстепенным деталям.
В логах всё, и лог транзакций (любые действия над данными и есть транзакция), и лог манипуляций с внутренними структурами базы.
9 июн 13, 02:26    [14410920]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Raskolnikov
Member

Откуда:
Сообщений: 52
Mnior
Raskolnikov, зачем гуманитарию это знать? Зачем троллить нас и делать вид что вам интересно понять смысл?
Вы тупо проигнорировали что тут было написал, чуть менее чем полностью. Спасибо за ваш эгоизм. Побольше смайликов - они типа украшают (FP.JPG).

Я ничего не проигнорировал, прочитал тему, на которую вы дали ссылку, но в ней ровным счетом для себя ничего не вынес: часть людей считают что записи в лог попадают по checkpoint, часть их обливает помоями и говорит о том, что данные туда пишутся сразу. Причем, в теме на которую вы дали ссылку человек ссылаясь на сайт Майкрософта пытается что-то доказать, а ему другой в ответ говорит "то перевод кривой, на самом деле это не так". А потом такие как вы говорят, что все вокрух муд*ки, эгоисты и "игнористы". Ёпата, а я на самом то деле читаю кучу информации, но она до меня не доходит или же все кагбэ понятно с точки зрения изложения, но не понятно как оно, в принципе, таким образом вообще работает.

Mnior
В моментальности нет смысла, всё во вселенной основывается на порядке событий, связанных одной точкой.

У меня складывается такое впечатление, что вас сейчас разорвет от злости (смайлик не ставлю, обойдемся без "украшательств"), но я все же спрошу: в физический файл ldf данные (под "данными" сейчас подразумеваются не физические записи в таблицу базы данных, а запись о какой-то операции, пускай даже просто о том, что открылась какая-то транзакция) пишутся все и сразу?

Mnior
Вы сначала должны понять основу, показать нам что вы поняли, а потом лишь можете приступать к второстепенным деталям.

Поймите, я задаю, с вашей точки зрения, глупые невменяемые вопросы, потому что не доходит до меня. Возможно это трудности перевода, возможно это от недостатка какой-то базы знаний, но я ничего поделать с этим не могу. Мне это интересно и я хочу с этим разобраться. Тем более однозначных ответов на вопросы, которые меня интересуют я не нашел: каждый считает по своему и даже ссылки на офсайт ничего не доказывают.

Mnior, и можно ещё личный вопрос? Вы по жизни злой или это я вас довожу до такого состояния?
9 июн 13, 14:43    [14411320]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
Raskolnikov
в физический файл ldf данные (под "данными" сейчас подразумеваются не физические записи в таблицу базы данных, а запись о какой-то операции, пускай даже просто о том, что открылась какая-то транзакция) пишутся все и сразу?
Да, только не при любой операции, а при закрытии транзакции; следующие операции не выполнятся, пока не придёт сообщение, что запись в лог завершена.
(За исключением того, что контроллер может закешировать запись у себя.)
9 июн 13, 17:35    [14411605]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Raskolnikov
Member

Откуда:
Сообщений: 52
alexeyvg
Да, только не при любой операции, а при закрытии транзакции;

При закрытии транзакции - это имеется ввиду при COMMIT-е?

alexeyvg
следующие операции не выполнятся, пока не придёт сообщение, что запись в лог завершена.

Следующие операции - это имеется ввиду следующие записи журнала?

alexeyvg
(За исключением того, что контроллер может закешировать запись у себя.)

Это, честно говоря, вообще не понял.
9 июн 13, 17:41    [14411619]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
Raskolnikov
alexeyvg
Да, только не при любой операции, а при закрытии транзакции;

При закрытии транзакции - это имеется ввиду при COMMIT-е?
Или при явном коммите, или при неявном коммите, т.е. при завершении команды, которая не обёрнута в явную транзакцию.
Raskolnikov
alexeyvg
следующие операции не выполнятся, пока не придёт сообщение, что запись в лог завершена.

Следующие операции - это имеется ввиду следующие записи журнала?
Это следующие команды в том же коннекте, или команды в других коннектах, которые ждут освобождения блокровок, наложенных этой командой.
Raskolnikov
alexeyvg
(За исключением того, что контроллер может закешировать запись у себя.)

Это, честно говоря, вообще не понял.
Некоторые контроллеры умеют "обманывать" MSSQL, отсылая продтверждение записи до её физического завершения, называется Write-Back Cache
9 июн 13, 20:32    [14411983]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Raskolnikov
Member

Откуда:
Сообщений: 52
alexeyvg
Или при явном коммите, или при неявном коммите, т.е. при завершении команды, которая не обёрнута в явную транзакцию.

Тогда не пойму следующего: если в лог попадают только зафиксированные транзакции, для чего тогда фаза undo при восстановлении базы? Ведь она как раз откатывает незафиксированные транзакции, которые были накатаны из журнала фазой ранее.

alexeyvg
Это следующие команды в том же коннекте, или команды в других коннектах, которые ждут освобождения блокровок, наложенных этой командой

alexeyvg
Некоторые контроллеры умеют "обманывать" MSSQL, отсылая продтверждение записи до её физического завершения, называется Write-Back Cache

Понял, спасибо!
9 июн 13, 20:39    [14411997]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3413
Raskolnikov
alexeyvg
Или при явном коммите, или при неявном коммите, т.е. при завершении команды, которая не обёрнута в явную транзакцию.

Тогда не пойму следующего: если в лог попадают только зафиксированные транзакции, для чего тогда фаза undo при восстановлении базы? Ведь она как раз откатывает незафиксированные транзакции, которые были накатаны из журнала фазой ранее.
Либо вы не совсем правильно понимаете, либо те, кто вам объясняет. Изменения в журнал транзакций попадают сразу же в те моменты, когда вызываются соотв. инструкции. Поэтому и существует фаза undo - откатить то, что на момент завершения бэкапа лога не было закоммичено. Т.е. незакрытые транзакции.

Одним из неприятных последствий такого дизайна системы является то, что если у вас в транзакции вместо коммита происходит роллбэк, то он тоже пишется в лог, таким образом транзакция в логе занимает двойной объем, хотя выглядит как будто ее никогда и не было. Про это надо помнить и стараться не попадаться в неприятные ловушки, например когда вы апдейтите таблицу на 100 млн. записей и в конце происходит ошибка и все начинает откатываться, и в журнале транзакций вдруг кончается место... один раз увидите - на всю жизнь запомните.
9 июн 13, 21:57    [14412194]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
invm
Member

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

Inside the SQL Server Transaction Log
9 июн 13, 22:27    [14412293]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Raskolnikov
в физический файл ldf данные пишутся все и сразу?
Да. Но "сразу" неправильное слово.
Правильно - первым по очереди. (между 2мя тактами процессора могут пройти годы, пауза на виртуалке)
Raskolnikov
каждый считает по своему и даже ссылки на офсайт ничего не доказывают.
Вам что гуманитарный авторитет нужен или аргументированная логика. Вы должны сами себе модель выстроить, практически придумать с нуля.
Raskolnikov
Вы по жизни злой или это я вас довожу до такого состояния?
Не, не злой, использую не те механизмы воздействия. Не люблю ошибки в мышлении и расхлябанности в точности фраз.
Совет, попробуйте поиграть в КО - описать нам всю модель досконально. Стандартный учительский приём. Преподают не для обучения других, а для прояснения собственного восприятия задачи.
Raskolnikov
Тогда не пойму следующего: если в лог попадают только зафиксированные транзакции,
Плять, туда всё попадает. Ничего не фильтруется, тупо всё подряд, последовательно.
Raskolnikov
для чего тогда фаза undo при восстановлении базы?
Когда стоит задача "максимально быстро восстановить базу", используется всё что можно.
К примеру, некая транзакция изменила данные в таблице, но потом отвалилась (не зафиксировалась). Вот тогда из лога накатывают старые данные, построчно. Если восстанавливать страницы данных с нуля - это жесть.
Raskolnikov
Ведь она как раз откатывает незафиксированные транзакции, которые были накатаны из журнала фазой ранее.
1. Какая разница какова стратегия восстановления?
2. Всё зависит от эффективности. Если лог быстрее восстанавливать от некоторой макрофиксации (чекпоинт) потоково, не важно что при этом строка данных может 100500 раз перезаписаться в памяти, то значит так выгодно.

Вы определитесь сначала в пирамиде модели важность тех или иных предпосылок. Как база восстанавливается конкретно в деталях - никак не влияет на основной принцип лога.

Ennor Tiegael
Одним из неприятных последствий такого дизайна системы является то, что если у вас в транзакции вместо коммита происходит роллбэк, то он тоже пишется в лог, таким образом транзакция в логе занимает двойной объем
А вот тут по подробнее пожалуйста.
Почему нельзя просто указать в логе команду RollBack, а далее пусть при восстановлении лог читается обратно.
Неужели выгодно повторить данные, лишь бы лог читался стримом (FastForvard :) )?

И плохо то, что стратегия работы с данными зависит от задачи. Вот допустим у меня мироринг, плевать я хотел на быстрое восстановление базы, а вот объёмы важны. Поэтому лучше вырубить такую стратегию. Ща набегут оракаклы.
Это не говоря о InMemoryDB, где вообще диски второстепенны (коммит подтверждается мирорингом, так?).
9 июн 13, 23:05    [14412408]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
Raskolnikov
alexeyvg
Или при явном коммите, или при неявном коммите, т.е. при завершении команды, которая не обёрнута в явную транзакцию.

Тогда не пойму следующего: если в лог попадают только зафиксированные транзакции, для чего тогда фаза undo при восстановлении базы? Ведь она как раз откатывает незафиксированные транзакции, которые были накатаны из журнала фазой ранее.
1. Незафиксированные тоже попадают.
2. Для зафиксированных тоже нужно восстановление, на тот случай, если они не попали в файл данных.
10 июн 13, 00:16    [14412537]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Гость333
Member

Откуда:
Сообщений: 3683
alexeyvg
Raskolnikov
в физический файл ldf данные (под "данными" сейчас подразумеваются не физические записи в таблицу базы данных, а запись о какой-то операции, пускай даже просто о том, что открылась какая-то транзакция) пишутся все и сразу?
Да, только не при любой операции, а при закрытии транзакции

То есть SQL Server копит в буфере записи лога и скидывает их на диск только по коммиту, несмотря на длину транзакции? Ну это ерунда, поскольку это противоречит концепции write-ahead log (или, по-русски, журнала транзакций с упреждающей записью). Эта концепция описана здесь, и она гласит, что грязные страницы не могут быть сброшены из буфера на диск (в файл данных), если предварительно не записаны в журнал транзакций соответствующие записи лога.

Если идёт длительная транзакция, то до её завершения некие "грязные" страницы данных, относящиеся к транзакции, будут сброшены на диск (в файл данных) по чекпойнту, либо их вытеснит из буфера lazy writer. А так как у нас write-ahead log, то сперва будут сброшены на диск соответствующие записи журнала транзакций. То есть записи в журнале будут появляться постепенно, а не возникнут там по мановению коммита.

Другое дело, что команда COMMIT вызывает синхронную запись на диск ещё не записанных остатков лога, соответствующего текущей транзакции. То есть, пока диск не отрапортует об успешной записи всех этих остатков, команда COMMIT не будет считаться завершённой. Для коротких транзакций это будет выглядеть как "все и сразу".
10 июн 13, 02:53    [14412724]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Гость333
Для коротких транзакций это будет выглядеть как "все и сразу".
От я тормоз.
Да, да, "все и сразу" фтопку.
Целостность не определяется "всё или ничего", она определяется последовательностью и только последовательностью.
10 июн 13, 03:26    [14412738]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
Гость333
alexeyvg
Да, только не при любой операции, а при закрытии транзакции

То есть SQL Server копит в буфере записи лога и скидывает их на диск только по коммиту, несмотря на длину транзакции? Ну это ерунда, поскольку это противоречит концепции write-ahead log (или, по-русски, журнала транзакций с упреждающей записью).
...
Другое дело, что команда COMMIT вызывает синхронную запись на диск ещё не записанных остатков лога, соответствующего текущей транзакции. То есть, пока диск не отрапортует об успешной записи всех этих остатков, команда COMMIT не будет считаться завершённой. Для коротких транзакций это будет выглядеть как "все и сразу".
Ну я это и имел в виду, синхронизация при COMMIT-е
Тут вопрос был не в времени записи самом по себе, а в её синхронности.
10 июн 13, 10:07    [14413320]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Гость333
Member

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

Имели в виду одно — по факту вышло совсем другое :)
ТС понял так, что только commit и пишет в лог, отчего у ТСа, совершенно логично, и возник этот вопрос:
Raskolnikov
Тогда не пойму следующего: если в лог попадают только зафиксированные транзакции, для чего тогда фаза undo при восстановлении базы?
10 июн 13, 10:13    [14413353]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3413
Mnior
Ennor Tiegael
Одним из неприятных последствий такого дизайна системы является то, что если у вас в транзакции вместо коммита происходит роллбэк, то он тоже пишется в лог, таким образом транзакция в логе занимает двойной объем
А вот тут по подробнее пожалуйста.
Почему нельзя просто указать в логе команду RollBack, а далее пусть при восстановлении лог читается обратно.
Неужели выгодно повторить данные, лишь бы лог читался стримом (FastForvard :) )?
Ну, вообще-то этот вопрос не ко мне, а скорее к Джиму Грею - если вы владеете навыками проведения спиритических сеансов, конечно :).

Думаю, тут дело не в стремлении к непрерывному стриму, а в обеспечении целостности. Не знаю... ну например - вы делаете point in time restore и вам надо попасть внутрь непосредственно роллбэка. Если его не писать в лог как есть, то хрен вы в него попадете. Опять-таки, транзакция из 10 стейтментов может проводиться 0,5 сек, а откатываться, по какой-то причине, полчаса. Все это время у вас висят локи, ну и т.д.

Видимо, потому архитекторы и предпочли перезаложиться, чем потом постоянно обтанцовывать эти грабли кругом. Я бы на их месте так же сделал бы, наверное.
10 июн 13, 13:19    [14414594]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
роллбэк
Guest
[quot Ennor Tiegael]
Mnior
пропущено...
А вот тут по подробнее пожалуйста.
Почему нельзя просто указать в логе команду RollBack, а далее пусть при восстановлении лог читается обратно.
Неужели выгодно повторить данные, лишь бы лог читался стримом (FastForvard :) )?


лог и так читается обратно при роллбэке.
и читая обратно, на каждую запись отменяемой транзакции генерируется новая анти-запись,
к-ая тоже в журнал же и пишется.
поэтому он в начале транзакции и резервирует двойной объем в логе.
а чего нелогичного-то?
какая разница в какую сторону идем?
ну записаны уже данные на диск, а теперь отменяем.
логируем отмену.
чем принципиально отличается, отмена это или накат?
в обоих случаях данные меняем, и перед изменением в лог пишем эти изменения
10 июн 13, 13:52    [14414872]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Ennor Tiegael
Не знаю... ну например - вы делаете point in time restore (PTR) и вам надо попасть внутрь непосредственно роллбэка. Если его не писать в лог как есть, то хрен вы в него попадете. Опять-таки, транзакция из 10 стейтментов может проводиться 0,5 сек, а откатываться, по какой-то причине, полчаса. Все это время у вас висят локи, ну и т.д.
Не понял проблемы.
Ну к примеру я пойму, что если не писать данные rollback-а явно (ссылаться на давний лог), а транзакция висит на дофига чекпоинтов, то это увеличивает разрыв небэкапируемого лога и VLF-ы тогда немодульны/зависимы.
Но при чём тут конкретно PTR? Подымаю я базу или рестор делают или ещё - механизмы теже.
Почему пессимистическая модель? В большинстве случаев транзакции, и соответственно ролблеки, малы и старые данные всё ещё в текущем VLF-е.

А может так оно и есть? Может лог наполняется ролбеком только при смене VLF-а? На что вы и нарвались.

Ennor Tiegael
Видимо, потому архитекторы и предпочли перезаложиться, чем потом постоянно обтанцовывать эти грабли кругом. Я бы на их месте так же сделал бы, наверное.
От блин, как обычно в индустрии. Вместо того чтобы разработать Парадигму/Язык/IDE/Архитектуру способствующую к сложным и оптимальным внутрях и простым и контролируемым снаружи. Ан нет - плюшек никому не видать. "Компании" всегда самое неэффективная хрень.
10 июн 13, 14:45    [14415299]     Ответить | Цитировать Сообщить модератору
 Re: Физическая запись в файлы данных  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
роллбэк
а чего нелогичного-то?
Тупо: А зачем?
Все эти данные точная копия лога до этого. Ну разве что в обратном порядке/действии.
10 июн 13, 14:48    [14415324]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить