ЛП hvladОк, пусть я жутко не прав. Где ваши весомые агументы ? Тесты, ссылки на документацию, и т.д. - где ?
Я что, должен доказывать то, что Ахилл догонит таки черепаху? Да он её уже обогнал, судя по вашему "батч, начавшись до бекапа, закончился после него" Потому как вся остальная деятельность была приостановлена.
Т.е. черепаху временно убрали с общей дороги.
Более другие аргументы есть ? Кроме зоопарка престарелых ?

ЛП hvladПотому как вся остальная деятельность была приостановлена.
Вам что, так сложно временную отметку поставить в изменяемые записи? Чтобы проверить, что остановок не было (или же отловить трехсекундную паузу в выполнении батча)?Куда её поставить ?
UPDATE выполняет свою работу и должен сначала записать в лог INSERTED и DELETED - они уже сформированны.
Вот здесь ему не дают лог на запись и заставляют ждать - как вы это обнаружите непосредственно ? Только косвенно...

Я же не говорю, что всё останавливается на всё время работы бекапа !

Изначально речь шла о системе с 1000 тр\сек и ежеминутным бекапом логов - вот в этой системе задержки должны быть заметны. Возможно SAN может их снизить до приемлемого уровня, но о его наличии было сказано значительно позже.

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

ЛП hvladРазница между приостановлена и остановлена для вас не существует ?
Между утверждениями:
"Работа с БД останавливается во время выполнения бекапа"
и
"Работа с БД приостанавливается на время выполнения бекапа"
я разницы не вижу.
И оба эти утверждения неверны.Ибо так сказал сам ЛП, да святится имя его... :)
Прекращаем толочь воду в ступе - безаргументный спор неинтересен

Да, именно так и бекапятся логи транзакций при активной в них записи.
Браво

AAronпоказана возможность чтения и записи в файл, типа одновременно. этот пример сделать быстрее всего. Желающие могут попробовать написать подобное на других языках.Уверяю вас, что данный пример, как бы ни был он великолепен, не показывает взаимодействия процессов при одновременной записи в лог и чтения лога с целью бекапа .
Ибо документация гласит, что в бекап попадают данные, актуальные на момент его окончания, а не начала. Если процесс записи никогда не заканчивается, то читающий процесс никогда за ним не угонится, т.к. он не должен записывать в бекап часть тр-ции и должен записать их все. Поэтому писатель (все писатели) должен приостановиться хоть на 1 мсек, дабы бекап мог а) завершиться и б) очистить лог.

AAronА вообще, hvlad, для Вас характерно использовать "опускание" собеседников в качестве метода ведения дискуссии или спора при собственной аргументации. Намерений таких не было и нет, но со стороны наверное виднее. Учту, спасибо за замечание.

AAronНе смотря на полный бред в некоторых рассужденияхТак кто тут кого "опускает" ? :)

andsm hvladИбо документация гласит, что в бекап попадают данные, актуальные на момент его окончания, а не начала.
В документации написано совсем другое. В документации написано, что
1. A database backup creates a duplicate of the data that is in the database when the backup completes
2. О том, что попадает в transaction log backup, явно не сказано ни слова.
Есть только критерии нахождения "ending point of the inactive portion of the transaction log" и фраза "When SQL Server finishes backing up the transaction log, it automatically truncates the inactive portion of the transaction log"

andsmДокументацию нужно читать, а не придумывать самомуПробелы приходится чем-то заполнять. А квотить нужно правильно: hvlad Поэтому писатель (все писатели) должен приостановиться хоть на 1 мсек, дабы бекап мог а) завершиться и б) очистить лог.а не выдёргивать из контекста пол-фразы.

Так что, даже если я и придумал о кол-ве данных, попадающих в бекап лога, то необходимость его обрезания никто не отменял. Кстати, если "ending point" постоянно двигается (тр-ции короткие и их много), то это ещё вопрос - когда бекап решит остановиться.

Договорились

michael_ hvlad
Так что, даже если я и придумал о кол-ве данных, попадающих в бекап лога, то необходимость его обрезания никто не отменял.
Хочу - обрезаю при бэкапе, хочу - нет. Какая такая необходимость?
1. When SQL Server finishes backing up the transaction log, it automatically truncates the inactive portion of the transaction log.
2. BACKUP LOG ... NO_TRUNCATE
Allows backing up the log in situations where the database is damaged.

Можете не обрезать. Никогда. Нет такой необходимости, всё мои домыслы.

michael_Среди изложенных Вами мыслей столько неточностей и описок, что это заставляет задуматься о том, что предмета Вы просто не знаете. А порассуждать очень хочется.Во-первых - деталей предмета не знает никто из здесь присутствующих. Или у вас есть источник в MS ?
Во-вторых - вы никогда не рассуждаете о том, что вам не известно наверняка ? Никогда не было интересно - что там внутри ? Это не повод запрещать это делать другим, не так ли ?
В-третьих - я неоднократно говорил о том, что я предполагаю , а не знаю точно , что там происходит

michael_Из моей практики: бэкап БД при одновременно работающих 100-180 пользователей почти не вызывает замедления их работы. Производительность снижается незначительно, видимое торможение бывает крайне редко. И это при создании полной копии, бэкап лога делается вообще на раз.Вы делаете ежеминутный бекап логов ? При нагрузке 1000 тр-ций\сек ? 200 коннектов не означает 200 runnable процесов на сервере.

locky2hvlad
>В документации написано, что
>1. A database backup creates a duplicate of the data
>that is in the database when the backup completes

если читать буквально, то там написано примерно следующее: в бэкапе содержаться все данные, которые он сумел или захотел записать. Т.е. бэкап содержит все данные, которые в нем есть. А вот когда он решил остановится - это его половая проблема.Не надо читать буквально: andsmВ документации написано совсем другое. Документацию нужно читать, а не придумывать самому.(с) andsm

Database backup <> transaction log backup.
Мы говорим о втором.

michael_С ежеминутным бекапом лога надо к доктору обращаться. Это симптом.Вот с этого данный флейм и начался.
Только я был более вежлив в формулировке и никого не "опускал"