ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Последовательность бекапов
8 сообщений из 8, страница 1 из 1
Последовательность бекапов
    #39960165
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
Добрый день,

Сегодня набрел на такую проблему, когда стал восстанавливать базу:
Код: sql
1.
2.
3.
4.
5.
6.
7.
physical_device_name	bkSize	TimeTaken	backup_start_time	backup_finish_time	first_lsn	last_lsn
LogBackup5.trn	13014 MB	92 Seconds	7:40:04	7:41:36	 7,693,915,000,000,620,000,000 	 7,694,907,000,002,050,000,000 
LogBackup4.trn	11379 MB	92 Seconds	7:30:04	7:31:36	 7,693,089,000,019,010,000,000 	 7,693,915,000,000,620,000,000 
LogBackup3.trn	6405 MB	        47 Seconds	7:20:04	7:20:51	 7,693,079,000,048,710,000,000 	 7,693,089,000,019,010,000,000 
LogBackup2.trn	1251 MB	        10 Seconds	7:10:04	7:10:14	 7,693,077,000,060,950,000,000 	 7,693,079,000,048,710,000,000 
LogBackup1.trn	2285 MB	        20 Seconds	7:00:05	7:00:25	 7,693,073,000,127,190,000,000 	 7,693,077,000,060,950,000,000 
FullBackup.bak	330964 MB	1988 Seconds	6:58:36	7:31:44	 7,693,073,000,020,760,000,000 	 7,693,855,000,000,650,000,000



Полный бекап завершился в 7:31:44, поэтому вроде бы как логично восстановить FullBackup.bak и потом LogBackup5.trn. Однако на деле не так, LogBackup4.trn начался и завершился до завершения полного, но тем не менее имеено он должен быть восстановлен первым поверх полного. Вопрос собственно риторический: получается нельзя полагаться на время начала/завершения бекапов при определении последовательности восстановления базы.
...
Рейтинг: 0 / 0
21.05.2020, 06:11
| Ответить | Цитировать | Написать  
Последовательность бекапов
    #39960179
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Roust_m
Вопрос собственно риторический: получается нельзя полагаться на время начала/завершения бекапов при определении последовательности восстановления базы.
Конечно.
Полагаться нужно на LSN
В крайнем случае, на время начала полного бакапа, и время завершения бакапа лога.

Почему так сделано - понятно.
Бакап же на время своего завершения не может содержать все изменения базы на этот момент, т.к. иначе бы он никогда не завершился.
Поэтому, когда восстанавливается полный бакап, изменения, сделанные во время бакапа, восстановлены не будут, и для восстановления дальнейшей цепочки нужно восстановить то, что менялось, начиная с начала бакапа.
...
Рейтинг: 0 / 0
21.05.2020, 08:13
| Ответить | Цитировать | Написать  
Последовательность бекапов
    #39960184
Фотография HandKot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
HandKot
Участник
alexeyvg

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

всегда считал по иному
вот выдержка из бола
Код: plaintext
1.
2.
3.
DATABASE Specifies a complete database backup. 
If a list of files and filegroups is specified, only those files and filegroups are backed up. 
During a full or differential database backup, SQL Server backs up enough of the transaction log 
to produce a consistent database when the backup is restored.
...
Рейтинг: 0 / 0
21.05.2020, 08:32
| Ответить | Цитировать | Написать  
Последовательность бекапов
    #39960193
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
HandKot
alexeyvg

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

всегда считал по иному
вот выдержка из бола
Код: plaintext
1.
2.
3.
DATABASE Specifies a complete database backup. 
If a list of files and filegroups is specified, only those files and filegroups are backed up. 
During a full or differential database backup, SQL Server backs up enough of the transaction log 
to produce a consistent database when the backup is restored.
Это да, дописывается журнал.

Как то там всё это расплывчато описано :-) На уровне "утром полный бакап, вечером бакап журнала"...
...
Рейтинг: 0 / 0
21.05.2020, 09:04
| Ответить | Цитировать | Написать  
Последовательность бекапов
    #39960195
Фотография Roust_m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roust_m
Участник
alexeyvg
Roust_m
Вопрос собственно риторический: получается нельзя полагаться на время начала/завершения бекапов при определении последовательности восстановления базы.

В крайнем случае, на время начала полного бакапа, и время завершения бакапа лога.

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


В том то и дело, что нельзя полагаться на время вообще. Полный бекап содержит изменения сделанные во время бекапа. Например, измения LogBackup1.trn, LogBackup2.trn, LogBackup3.trn вошли в полный бекап, хотя все эти бекапы начались после полного бекапа. А вот изменения LogBackup4.trn не вошли, хотя он завершился до окончания полного бекапа. То есть полный бекап включает изменения во время себя, но до определенного момента, потом "ворота" закрываются и он делает какие-то операции завершения и не берет новые изменения.
...
Рейтинг: 0 / 0
21.05.2020, 09:18
| Ответить | Цитировать | Написать  
Последовательность бекапов
    #39960225
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Roust_m
Полный бекап завершился в 7:31:44, поэтому вроде бы как логично восстановить FullBackup.bak и потом LogBackup5.trn.
Несмотря на запись изменений из лога в полный бакап, нельзя расчитывать, что в бакап лога, завершившийся за миллисекунду после конца полного бакапа, не попадёт часть изменений, делавшихся во время полного бакапа.
В данном случае за 8 секунд.

Нельзя на это рассчитывать, всё будет зависеть от нагрузки, и производительности.
Полный бакап записывает остатки лога, а в базу в это время валятся транзакции. Когда там настанет час X, или LSN X вы предсказать не сможете.
...
Рейтинг: 0 / 0
21.05.2020, 11:11
| Ответить | Цитировать | Написать  
Последовательность бекапов
    #39960226
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Roust_m
alexeyvg
пропущено...

В крайнем случае, на время начала полного бакапа, и время завершения бакапа лога.

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


В том то и дело, что нельзя полагаться на время вообще. Полный бекап содержит изменения сделанные во время бекапа. Например, измения LogBackup1.trn, LogBackup2.trn, LogBackup3.trn вошли в полный бекап, хотя все эти бекапы начались после полного бекапа. А вот изменения LogBackup4.trn не вошли, хотя он завершился до окончания полного бекапа. То есть полный бекап включает изменения во время себя, но до определенного момента, потом "ворота" закрываются и он делает какие-то операции завершения и не берет новые изменения.
Угу, только смотреть цепочку LSN.
Или можно полагаться на время - бакап лога, который завершился до момента начала полного бакапа, не нужен.
Вот это всё гарантированно, а остальное - нет.
...
Рейтинг: 0 / 0
21.05.2020, 11:13
| Ответить | Цитировать | Написать  
Последовательность бекапов
    #39960239
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
msLex
Участник
Roust_m
alexeyvg
пропущено...

В крайнем случае, на время начала полного бакапа, и время завершения бакапа лога.

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


В том то и дело, что нельзя полагаться на время вообще. Полный бекап содержит изменения сделанные во время бекапа. Например, измения LogBackup1.trn, LogBackup2.trn, LogBackup3.trn вошли в полный бекап, хотя все эти бекапы начались после полного бекапа. А вот изменения LogBackup4.trn не вошли, хотя он завершился до окончания полного бекапа. То есть полный бекап включает изменения во время себя, но до определенного момента, потом "ворота" закрываются и он делает какие-то операции завершения и не берет новые изменения.

Все просто

полный бекап состоит из двух основных частей

1. Бекап данных. Т.е. прям постраничная копия файлов данных. Т.к. в процессе чтение этих данных, страницы меняются, то эта часть получается не консистентной. И для этого добавляется вторая часть
2. Бекап лога, содержавший все изменения с начала до конца первой части.

Т.е. по факту, полный бекап хранит базу в состоянии на момент завершения 1-й части бекапа.


Если во второй период полного бекапа успело сделаться более одного бекапа лога, то все они, начиная со второго, будут иметь дату начала меньше, чем дата окончания полного, но при этом не могут быть восстановлены на него.
...
Рейтинг: 0 / 0
21.05.2020, 11:27
| Ответить | Цитировать | Написать  
8 сообщений из 8, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Последовательность бекапов
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&tid=1686094]:
 0ms
get settings:
 10ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 24ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 48ms
get tp. blocked users:
 2ms
others: 14ms
total:  131ms
созд. / загр.: 131ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]