Добрый день.

спорю на 500 рублей с админом )))

дано: база с моделью восстановления "простая"
полный архив бд делается 20 минут.

1) я утверждаю что в архив попадут данные только на момент начала архива и то что проведенные за время архивирования никак не повлияют на конечный архив

2) админ утверждает что полный бекап эскуэль делает "простым копированием" и в конечном архиве могут быть "дырки" из за деятельности пользователей.

кто проиграет спор?

Бэкап базы или файлов?

бекап базы. через агент SQL

где голосовалка?

Админ глупый !?

(3)  а чтооо?? можно было?? :)

(5) 1С - понятие растяжимое. Тут нет черного и белого, есть только желтое.

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

Обычно BackUp открывает транзакцию и отслеживает всё на определённый момент времени.

(0) админ проиграет...

Админ разориться на таких ставках)

(6) и красное

(1) Да даже если файлы (боже упаси) то теневое копирование тома делает его копию на определённый момент времени.

Проголосую:
Админ проиграет.

>админ утверждает что полный бекап эскуэль делает "простым копированием"

не чай он у вас пьет (с) Комноедов

Да по-любому админ не прав.

По идее бэкап должен делаться в транзакции с макс. уровнем изоляции

вот бэкап mysql - это песТня

открываешь его блокнотом

а там портянка

сначала из createtable

а потом

портянка из insert into

админ (Ромик) сидит рядом, сжимает пятихатку в руке. но ему нужен железный аргумент )) говорит просто так не отдаст

ну а что спорить? Надо взять да попробовать на маленькой базе.

(19) за пятихатку мне лень пробовать. а на маленькой базе мы не успеем во время архивации "наколбасить" проводок в базе.

(17) чем проще, тем надежнее )))
(19) не надо на большой. на маленькой вдруг скуль отследит что что-то изменилось и включит эти изменения в бэкап

короче Ромик сдался - пятихатка у меня в кармане! всем спасибо.

>По идее бэкап должен делаться в транзакции с макс. уровнем изоляции

в скуле есть понятие checkpoint

закомитченные транзакции сбрасываются на диск и начинает создаваться бэкап

Эмм... Ошибочка вышла:

https://msdn.microsoft.com/en-us/library/ms186289.aspx

A full database backup backs up the whole database. This includes part of the transaction log so that the full database can be recovered after a full database backup is restored. Full database backups represent the database at the time the backup finished.

Финишед. Финишед, блRть!

(19) Один нажимает кнопку восснатовления. Другой запускает групповую обработку справочников и документов (перед этим сформировав отчет)
(22) Че-то вы скучные какие-то так быстро?

(24) фулл блеать

(0)Проиграете оба. Ибо оба несете чушь.
1. В бэкап попадают все завершенные на момент ОКОНЧАНИЯ бэкапа транзакции. Ибо последним этапом бэкапа идет запись в бэкап активной части журнала транзакций.
2. Как можно видеть по п. 1 бэкап не есть "простое копирование" и результат его всегда дает косистентную базу.

Думать тут нечего. В бекап попадут данные всех транзакций, которые будут завершены к окончанию процесса бекапа. Это документировано.

(26) При чем здесь это? Простая модель - это один большой бек ап и куча маленьких. По любому попадают данные на конец бек апа.

(0) Какой смысл, все равно пятихатка будет распита...

(29) цитату ты неверно привел.

верный вывод из неверных предпосылок

>Простая модель - это один большой бек ап и куча маленьких.

щито?

Ромик, забирай у него пятихатку))

(31)
Поддержу коллег

По русски читаем, если что-то не верит в финишед

https://msdn.microsoft.com/ru-ru/library/ms175477.aspx  
ищем буковки
резервное копирование базы данных
Резервная копия базы данных. Полные резервные копии базы данных отображают состояние всей базы данных на момент завершения резервного копирования. Разностные резервные копии базы данных содержат только изменения базы данных с момента последнего полного резервного копирования.

(29) не вчитался. какая куча маленьких имеется ввиду?

(31) Цитату он привел верную.
Читаем в(0): полный архив бд делается 20 минут
Читаем в(24) : A full database backup

А простая модель восстановления к полноте бэкапа отношения не имеет от слова совсем.

Если следовать (24) то неправы оба, так как никаких "дырок" тоже не будет. Будет база на определённый момент времени.
Так что - идите оба и отмечайте свою неправоту.

(31) что же касается утверждения в (26) - то, увы, это актуально и для простой(симпл)-модели.

Я так полагаю, что автор и Ромик должны по 500 рублей каждому, ответившему правильно на этот вопрос.

(29) Простая модель - это модель восстановления. К бэкапам относится только отсутствием/наличием возможности восстановления на произвольный момент времени, к полноте бэкапа не имеет вообще никакого отношения.

(36) это я прогнал, всё верно

вариант 1

(42) уже выяснили, что вариант 3

В простой модели какждый чекпойнт приводит к отчистке журнала транзакций. а в полной соответственно нет

(44) Неправда. В простой модели новые транзакции в журнале записываются на место старых, помеченных как ненужные.

(45) ну очитска всегда была как пометка на удаление

физическая очистка это шринк уже

(46) А давайте не подменять уже устоявшиеся понятия? Пометка на удаление - это пометка, а не очистка. И очистка есть очистка, а не урезание файла.

(48) Вот файл ты удаляешь - это какое понятие нужно применять?

(49) Пометка на удаление, если ты удаляешь его командой DEL

(34) Как странно...

http://catalog.mista.ru/public/173494/
Полная резервная копия
Позволяет восстановить состояние базы данных на некоторый момент времени (на тот в который начато формирование резервной копии).

(51) ну ты сравнил МСДН и инфостарт

(51) Позволяет восстановить состояние базы данных на некоторый момент времени (на тот в который начато формирование резервной копии).
Состоит из постраничной копии используемой части файлов данных и активного куска журнала транзакций за то время пока формировалась резервная копия.

Там есть продолжение.

(52) так я же не спорю... просто похоже заблуждение распространено

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

(55) так он был в копии? или получился потом?

(0) Скиньтесь оба по пятихатке, набухайтесь и проверьте.

(0)Все транзакции, произведенные после начала бекапа, в бекап не попадут.

(56) еще раз
начал делать архив рабочей базы, в процессе создал контрагента, восстановил архив в соседней базе - контрагент там тоже был

(0) этот эникейщик про СУБД ни чего не знает.
Простым копированием, блин...

(58) Уже выяснили, что попадут, см (55) дописывает из журнала транзакций.

(61) Таки действительно был не прав. Мелкомягкие говорят, что при старте процесса SQL Server бекапит все содержание БД, в том числе части журнала транзакций, используемые во время создания резервной копии.  Т.е. бекап по состоянию на момент завершения процесса резервирования. Незавершенные транзакции при восстановлении очищаются и база находится в согласованном состоянии.

интересно, а если транзакции будут сыпаться быстрее чем они бэкапятся?

о, голосовалка!
проводки попадут без дырок

Оба продули.
Забекапит сначала базу, потом из журнала транзакций доцепит.