pkarklin
Apexгрязные страницы в этом случае СУБД скидывает?

Не понял вопрос.
Checkpoints and the Active Portion of the LogThe active log must include every part of all uncommitted transactions. An application that starts a transaction and does not commit it or roll it back prevents the Database Engine from advancing the MinLSN.
Это касательно лога. А грязные страницы сбасываются при чекпоинте или кэш обязан пухнуть вместе с логом?

>pkarklin

Похоже наша дискуссия заходит в тупик.
Итак, все началось с того, что я прицепился к мгновенности операции отсоединения бд, поскольку и правда не знал, что при этом происходит и исренне полагал, что СУБД при этом сбросит согласованные на момент отключения данные в файлы.
Но Вы сказали, что это не так, посмольку в этом нет необходимости, т.к. есть лог.
pkarklin Apex
И все это происходит мгновенно? А как на счет сброса согласованных данных в файл? :)


Полагаю, Вы не знакомы с физической архитектурой сиквел сервера, ибо тогда бы не возникло такого вопроса. У бд на MS SQL как минимум два файла - файл данных и файл лога (write-a-head) поэтому в любой момент времени, все транзакции, после которых прошел чекпоинт находятся в логе и закомиченные применены к файлу бд, и все транзакции (закомиченные и откаченные) после чекпоинта находятся в файле лога. Поэтому отсоединение бд происходит мгновенно.
ОК. Нет проблем, вроде бы все встало на свои места. Но YO отвесил следующий коментарий
йот.е. аттач потом вынужден востанавливать вырубленую на ходу бд ... забавное решение, даже для МС Не будем придираться к остальным выражениям, ключевой момент здесь ВОССТАНАВЛИВАТЬ. Действительно, зачем же еще нужно переносить лог вместе с остальными файлами бд, а для того, чтобы восстанавливать. Но
pkarklin...эмоции поскипаны...
Аттач ни чего не восстанавливает, ибо восстанавливать нечего.
Как же это восстанавливать нечего, если сброс грязных станиц уже закомиченных транзакицй при отключении не происходит? Зачем же тогда лог?

Оказывается
pkarklinСуществует возможность присоединить файл данных и без файла лога (в случаи если он недоступен).
и даже более того
pkarklinЕсли Вы присоедините бд без лога, то запрос вернет данные, которые были на момент отсоединения в файле данных.
Такое поведение возможно в двух случаях:
1) При каждом чекпоинте сбрасываются только изменения уже закомиченных транзакций. Страницы которые еще содержат данные незакомиченных транзакций висят в памяти и не сбрасываются даже при чекпоинте. В этом случае при отключении бд и подключении ее без лога , мы сделав запрос и правда можем получить согласованные на какой-то момент в прошлом (до отключения) даные.
2) Грязные страницы любой транзакции (как закомиченной, так и незакомиченной) сбрасываются в файл при очередном чекпоинте. Вопрос: как в этом случае и без лога отличить данные, которые уже зафиксированы, от тех, которые еще были не зафиксированы? Ответ: нужна версионность, например как в FireBird.

Первый вариант - полный идиотизм. Второй вариант не применим к MS SQL, т.к. известно, что она использует блокировочную модель (про юконы сейчас не будем, не о том речь).

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

pkarklinМне, кажется, что я приводил ссылку на то, что происходит при чекпоинте.

А написано там следующее
Checkpoint Operation....
Writes all dirty log and data pages to disk.
....

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

Apex
pkarklin
Аттач ни чего не восстанавливает, ибо восстанавливать нечего.
pkarklinСуществует возможность присоединить файл данных и без файла лога (в случаи если он недоступен).

pkarklinЕсли Вы присоедините бд без лога, то запрос вернет данные, которые были на момент отсоединения в файле данных.

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

Кажется я понял в чем недоразумение... Детач на ходу не делается, так? Все дело в этом?
-------------------------------------------------------
Автор благодарит алфавит за любезно предоставленные ему буквы.

pkarklin ApexДетач на ходу не делается, так? Все дело в этом?
На каком ходу?
Этот вопрос можете проигнорировать:) Это уже меня понесло.

Что можете сказать про остальное?

Yo.!
2Apex
вы имхо не стого бока заходите, вам нужно вытянуть с чего это pkarklin решил, что деатач не сбрасывает содержимое буферов в вайлы данных, как это делает любая другая субд, тогда уже открутится от востановления консистентности файлов данных ему не удастся.
На самом деле у меня есть подозрение, что грязные страницы (в нашей терминологии блоки) сбрасываются в файлы данных только при коммите. А до коммита удерживаются там и засоряют буферный кэш. Сейчас я пытаюсь выяснить сей момент у знакомых, работающих с MS SQL. Т.к. от господина pkarklin'а развернутого технического коментария не дождешься... впрочем это очень тепично для адептом технологий майкрософта, они очень не любят вдаваться в подробности и копать вглубь.

P.S. Документация на этот счет тоже не изобилует подробностями... :(

pkarklin
Вы даже не потрудились поситать цитату, которую я привел:

SQL Server maintains a buffer cache into which it reads data pages when data must be retrieved. Data modifications are not made directly to disk, but are made to the copy of the page in the buffer cache. The modification is not written to disk until a checkpoint occurs in the database , or the modification must be written to disk so the buffer can be used to hold a new page . Writing a modified data page from the buffer cache to disk is called flushing the page. A page modified in the cache, but not yet written to disk, is called a dirty page.
Виноват. Но в таком случае, как же это соотносится с утвержденим о том, что базу можно подключать и без лога, при этом детач не делает чекпоинт, при этом данные в файле консистентны (ваше утверждение о том, что без лога запрос вернет какие-то в прошлом закомиченные данные)? Видимо, без лога данные все же не консистентны? Но при этом, Вы опять же утверждали, что при аттаче никакого восстановления данных в файле не происходит. Так в какой же момент происходит восстановление данных после аттача?

pkarklin
Вот тут я был, конечно, не прав , сказав, что при аттаче не происходит процедура восстановления бд. Она происходит . Во всяком случаи на то есть косвенные упоминания на технете.

Но не смотря на это, есть и противоположные утверждения, о том, что якобы при отсодинении, все изменения, зафиксированные в логе, применяются к файлу данных. На этом основывается "быстрый способ" усечения лога. Но, боюь, что этот способ вряд ли можно применять со 100% уверенностью.
Аминь. Стало быть, если восстановление происходит, то ни о какой мгновенности речи не идет. Речь идет лишь о переносе неких действий с данными (оно же восстановление) во времени, но не об их отсутствии за ненадобность. Так в чем же тогда, приимущество переноса БД в MS SQL перед аналоичным в Oracle? В конпке?

И еще, Вы, как я полагаю, эксперт по СУБД MS SQL. И как я понял, у Вас возникли трудности в описании данного, важного на мой взгляд процесса, из-за его слабой документированности?

P.S. А еще было бы интересно узнать, а что же происходит, в описанном Вами случае отсутствия лога? Если есть возможность подключить бд без лога, как же с ней работать?

pkarklin
А как же "сложности" c TTS?

Дело в том, что перенос базы в MS SQL и перенос табличного пространства в оракле не эквивалентные с концептуальной точки зрения операции. Табличное пространство - это лишь часть БД, а не вся БД (оно может содержать одну или несколько больших таблиц). Оно не содержит метаданных описывающих его. Поэтому необходимо эти метаданные создавать и формировать набор файлов. Кроме того TTS гораздо гибче в данном случае: нет необходимости отстреливать читающие транзакции при переводе переносимого TS в read-only. В MS SQL отключение бд - это отключение в буквальном смысле, вот она была и вот ее нет. Со всеми вытекающими.
Саму же базу целиком в Оракле перенести не сложнее, чем где бы то ни было: остановили, скопировали, запустили.

pkarklin
Не все внутренние процессы сервера документированы. Часто, кроме документации, приходится еще кое-что почитывать.

Это был скорее камень в огород майкрософта. Тема, имхо, весьма важная, чтобы ее обходить в доке стороной.
pkarklin
авторCREATE DATABASE ... FOR ATTACH_REBUILD_LOG

создаст новый лог файл.
Но ведь это толко если есть уверенность, что данные в файле консистентны? Иначе мусор...