1С++ users forum - Бэкап базы на SQL Server

(UTC)

1С++ users forum › 1С++ и прочие расширения v7 › Прямые запросы к БД › Бэкап базы на SQL Server

(Группа Модераторов: 1c++ moderator)

‹ Предыдущая Тема | Следующая Тема ›

Переключение на Главную Страницу

Страницы: 1

Отправить

Горячая тема (более 10 ответов)

Бэкап базы на SQL Server (число прочтений - 6898 )

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Бэкап базы на SQL Server 19. Июля 2010 :: 11:19	Печать
	Прочитал любопытную статью на сей счет: http://www.interface.ru/home.asp?artId=22199. Несколько напрягли и заставили задуматься например следующие моменты: Цитата: "Усечению журнала могут воспрепятствовать две широко известные проблемы: ... Переключение на модель восстановления FULL, выполнение полной резервной копии и полный отказ от создания резервных копий журнала. Весь журнал транзакций остается активным в ожидании резервного копирования процедурой резервного копирования журнала". Цитата: Ни при каких обстоятельствах не следует удалять журнал транзакций, пытаться восстановить его с помощью недокументированных команд или просто обрезать его с помощью параметров NO_LOG или TRUNCATE_ONLY команды BACKUP LOG (которая удалена из SQL Server 2008). Эти параметры приведут либо к несогласованности с точки зрения транзакций (и, что более вероятно, к повреждению файла), либо лишат возможности надлежащего восстановления базы данных. Захотелось погрузиться в теорию и обсудить следующие вопросы: 1) Чем же так опасна команда BACKUP LOG WITH TRUNCATE_ONLY? 2) Действительно ли нельзя провести усечение журнала , если не проводится резервное копирование журнала транзакций (при модели восстановления FULL)? Насколько помню, усекать всегда так или иначе удавалось, хотя такого бэкапа не делается никогда...


	IP записан

val Full Member Отсутствует Дорогу осиливает идущий Сообщений: 137 Зарегистрирован: 07. Июля 2006	Re: Бэкап базы на SQL Server Ответ #1 - 19. Июля 2010 :: 13:45	Печать
	Для восстановления базы в случае сбоя нужен бекап базы (полный и дифф.,если дифф. делается) и бекапы логов, сделанные после бекапа базы. Чтобы делать бекапы логов, нужна модель FULL. Отсюда ответы на твои вопросы: TRUNCATE_ONLY делает обрезку лога и прерывает последовательность бекапов логов. Поэтому после TRUNCATE_ONLY необходимо сразу сделать полный бекап базы. Иначе восстановление возможно только на момент последнего бекапа логов до обрезки.


	IP записан

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Re: Бэкап базы на SQL Server Ответ #2 - 19. Июля 2010 :: 14:03	Печать
	Так все-таки, TRUNCATE_ONLY делает обрезку даже тех записей журнала, которые не перенеслись в основную базу? Или оно только прерывает последовательность бэкапов? Если последнее, тогда все равно не ясно, каким образом это может привести к "несогласованности с точки зрения транзакций (и, что более вероятно, к повреждению файла)"


	IP записан

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Re: Бэкап базы на SQL Server Ответ #3 - 19. Июля 2010 :: 14:06	Печать
	Из этого: Цитата: Ни при каких обстоятельствах не следует удалять журнал транзакций, пытаться восстановить его с помощью недокументированных команд или просто обрезать его с помощью параметров NO_LOG или TRUNCATE_ONLY команды BACKUP LOG (которая удалена из SQL Server 2008). Эти параметры приведут либо к несогласованности с точки зрения транзакций (и, что более вероятно, к повреждению файла), либо лишат возможности надлежащего восстановления базы данных. разве не следует, что это нельзя делать даже на нормально функционирующей базе, т.к. тем самым она может повредиться?


	IP записан

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Re: Бэкап базы на SQL Server Ответ #4 - 19. Июля 2010 :: 14:09	Печать
	Из другой статьи : Цитата: Урезать неактивные страницы журнала транзакций: BACKUP LOG ИмяБазы WITH TRUNCATE_ONLY Разве урезание неактивных страниц журнала транзакций может как-то испортить базу данных? Цитата: Сама база данных знает, с какого места процедура восстановления после сбоя должна начинать чтение записей журнала в активной части журнала - с начала самой старой активной транзакции в журнале, MinLSN (она хранится в загрузочной странице базы данных).


	IP записан

val Full Member Отсутствует Дорогу осиливает идущий Сообщений: 137 Зарегистрирован: 07. Июля 2006	Re: Бэкап базы на SQL Server Ответ #5 - 19. Июля 2010 :: 14:25	Печать
	(3) Предполагаю, что автор слова "не следует удалять журнал транзакций, пытаться восстановить его с помощью недокументированных команд" соотносил с "к несогласованности с точки зрения транзакций (и, что более вероятно, к повреждению файла)". А слова "просто обрезать его с помощью параметров NO_LOG или TRUNCATE_ONLY команды BACKUP LOG" - с "возможности надлежащего восстановления базы данных". Иначе логика автора непонятна.


	IP записан

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Re: Бэкап базы на SQL Server Ответ #6 - 20. Июля 2010 :: 05:50	Печать
	Кстати, а почему эта команда BACKUP LOG ИмяБазы WITH TRUNCATE_ONLY нарушает последовательность бэкапов, если она обрезает только неактивные страницы, а бэкапы делаются из активных? Или она там что-то еще далает, например, принудительно обрезает и активные страницы, которые еще не забэкапены??


	IP записан

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Re: Бэкап базы на SQL Server Ответ #7 - 20. Июля 2010 :: 06:11	Печать
	Цитата: Итак, как осуществляется отбрасывание записей журнала, позволяющее занимаемое ими пространство использовать повторно? Запись журнала транзакций становится не нужной, если имеют место следующие факты. - Транзакция, частью которой является эта запись, зафиксирована. - Все страницы базы данных, которые она изменила, записаны на диск процедурой контрольной точки. - Данная запись журнала не требуется для резервного копирования (полного, выборочного или журнала). - Эта запись журнала не требуется никакому компоненту, читающему журнал (например, средству зеркального отображения базы данных или репликации). Запись журнала, потребность в которой сохраняется, называется активной, и файл VLF, имеющий по крайней мере одну активную запись журнала, также называется активным. Время от времени журнал транзакций проверяется с целью выяснения, являются ли активными все записи журнала в заполненном VLF, или нет; если они все не активны, VLF помечается как отброшенный (что означает, что VLF можно перезаписывать, когда исчерпается свободное место в журнале транзакций). Когда VLF отбрасывается, он никак не перезаписывается и не опустошается, а просто помечается как отброшенный и впоследствии может быть использован повторно.


	IP записан

val Full Member Отсутствует Дорогу осиливает идущий Сообщений: 137 Зарегистрирован: 07. Июля 2006	Re: Бэкап базы на SQL Server Ответ #8 - 20. Июля 2010 :: 07:15	Печать
	(6) (7) Я так понимаю, ты сам себе ответил. "Данная запись журнала не требуется для резервного копирования". "BACKUP LOG ИмяБазы WITH TRUNCATE_ONLY " как раз и отмечает такие записи как ненужные и в следующий бекап логов они не попадут. А надо, чтобы попали.


	IP записан

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Re: Бэкап базы на SQL Server Ответ #9 - 20. Июля 2010 :: 07:39	Печать
	Цитата: Я так понимаю, ты сам себе ответил. как раз нет, скорее это было расшифровкой к моему вопросу)) Цитата: "BACKUP LOG ИмяБазы WITH TRUNCATE_ONLY " как раз и отмечает такие записи как ненужные и в следующий бекап логов они не попадут. А надо, чтобы попали". Под ненужными же подразумеваются неактивные. А BACKUP LOG согласно инструкции удаляет только неактивные записи, то есть уже ненужные. Цитата: NO_LOG \| TRUNCATE_ONLY Removes the inactive part of the log without making a backup copy of it and truncates the log. This option frees space. В этом и вопрос, тогда как он нарушает последовательность бэкапов? Или все-таки здесь где-то неточность в терминах, и например, ненужный <>неактивный?


	IP записан

val Full Member Отсутствует Дорогу осиливает идущий Сообщений: 137 Зарегистрирован: 07. Июля 2006	Re: Бэкап базы на SQL Server Ответ #10 - 20. Июля 2010 :: 08:15	Печать
	(9) При полной модели восстановления, при бэкапе лога происходит освобождение места в логе, занимаемое всеми завершеными транзакциями. При "BACKUP LOG ИмяБазы WITH TRUNCATE_ONLY " происходит то же самое, только эти данные на диск не попадают. Поэтому прерывается цепочка бекапов логов, необходимых для восстановления.


	IP записан

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Re: Бэкап базы на SQL Server Ответ #11 - 20. Июля 2010 :: 08:41	Печать
	Цитата: только эти данные на диск не попадают Какие "эти" данные? Даже завершенные транзакции, еще не записанные на диск?


	IP записан

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Re: Бэкап базы на SQL Server Ответ #12 - 20. Июля 2010 :: 08:47	Печать
	Вообще, вопрос ко всем хорошо разбирающимся в структуре SQL Servera. Очень хотель бы связать в единую схему такие конкретные понятия, как активная запись, ненужная запись, команда TRUNCATE_ONLY, и шринк. Что происходит при TRUNCATE_ONLY ? - Удаление неактивных записей? - Проверка активных на предмет того, нужны ли они еще или не нужны, и если не нужны - пометка как неактивные? - Пометка всех активных записей как неактивные? - То же, что и предыдущий пункт, но пометка как неактивные только завершенных транзакций? Опять же, чем шринк базы отличается от ее "усечения", которое, я так понимаю, происходит при TRUNCATE_ONLY? Именно в понятиях "активная-неактивная запись?


	IP записан

val Full Member Отсутствует Дорогу осиливает идущий Сообщений: 137 Зарегистрирован: 07. Июля 2006	Re: Бэкап базы на SQL Server Ответ #13 - 20. Июля 2010 :: 09:26	Печать
	(11) "эти данные" - занимаемые всеми завершеными транзакциями. (12) Так детально - на sql.ru


	IP записан

Neo Senior Member Отсутствует I Love YaBB 2! Сообщений: 327 Зарегистрирован: 12. Ноября 2007	Re: Бэкап базы на SQL Server Ответ #14 - 20. Июля 2010 :: 09:54	Печать
	Цитата: "эти данные" - занимаемые всеми завершеными транзакциями. Если в том числе и не перенесенными на диск, то тогда это противоречит тому, что TRUNCATE_ONLY обрезает только неактивные записи. Может ли не перенесенная на диск запись быть неактивной?


	IP записан

Переключение на Главную Страницу

Страницы: 1

Отправить

‹ Предыдущая Тема | Следующая Тема ›

« Главная ‹ Раздел Вверх

Вверх

Valid XHTML

Valid CSS

Powered by Perl

Source Forge