Restore database

Greenhorn
Дата: 02.02.2009 16:09:35
select @@version as [Добрый день]
---
Microsoft SQL Server 2005 - 9.00.3050.00 (Intel X86)   Mar  2 2007 20:01:28   Copyright (c) 1988-2005 
Microsoft Corporation  Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2) 

Имею VLDB с секционированными таблицами.
Модель восстановления VLDB - SIMPLE. Выбор такой модели основывается на рекомендациях из BOL:
Модель простого восстановления рекомендуется использовать при следующих условиях.
•	В восстановлении до момента сбоя необходимости нет. Если база данных утрачена или
повреждена, допускается потеря всех обновлений, выполненных с момента предыдущего 
резервного копирования до момента сбоя.
•	Допускается возможность потери некоторых данных в журнале. 
•	Нет необходимости в резервном копировании и восстановлении журнала транзакций, 
вместо этого отдается предпочтение полным и разностным резервным копиям.
Все пункты - то, что мне надо и куча других аргументов за SIMPLE.
Все было бы ничего, вот только при движении окна секционирования небходимо откусывать старую
информацию и бэкапить ее с возможностью восстанавливать по требованию как отдельную базу данных.
Это возможно, если файловую группу со старой информацией (она в ReadOnly) забэкапить вместе с группой PRIMARY.
Но модель - SIMPLE, а PRIMARY по определению ReadWrite, значит забэкапить только их нельзя.
И на это есть финт ушами - перед бэкапом переключим базу в FULL, ну а после в SIMPLE.

Все бы ничего и в 8 случаях из 10 все O.K. - база восстанавливается без ошибок, как и было задумано.

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

Для восстановления базы данных необходимо, чтобы весь набор восстанавливаемых данных (набор
данных наката) был согласован с базой данных. Если набор данных наката, необходимый для
согласования с базой данных, достаточно велик и указан параметр RECOVERY, компонент Database
Engine формирует ошибку. 
Иными словами команда Restore DataBase после часа работы возвращает ошибку. К сожалению ошибку не сохранил, очень торопился данные отресторить. Но, если очень нужно, то могу потратить часок, чтоб ее выловить, хотя причина imho ясна.

Вот что странно, я c PRIMARY Default снял и никаких таблиц там не держу, все остальные ReadWrite файловые группы в момент бэкапа могут менятся и даже интенсивно. НО я их не бэкаплю в этом бэкапе !!! Следовательно, PRIMARY не меняется, хотя буферные таблицы создаются/удаляются на др. файловой группе, но метаданные то в Primary (может в этом собака ?).

Вопрос - как с этим бороться ?

У кого есть опыт использования VLDB с такими параметрами - поделитесь плз.
mike909
Дата: 02.02.2009 16:58:06
Greenhorn,

Ну если Вы перевели базу в FULL, то Backup Log явно не помешает...
Greenhorn
Дата: 02.02.2009 17:10:28
mike909,

Спасибо, наверное Вы правы - бум проверять.

А вот как определить - нужно ли еще и лог бэкапить или можно обойтись без него, ведь в 8 из 10 бэкапах лог не понадобился ?
Ozerov
Дата: 02.02.2009 17:47:56
Бэкап лога, обычно определяется вашими потребностями. Если не критично восстанавливать базу на момент последнего полного бекапа, то нет смысла в бэкапе лога. Если есть необходимость отката на время после последнего полного бэкапа, то необходимо производить бэкап лога транзакций с временным периодом не более критичного времени отктата.
Greenhorn
Дата: 02.02.2009 18:14:59
Ozerov
Бэкап лога, обычно определяется вашими потребностями. Если не критично восстанавливать базу на момент последнего полного бекапа, то нет смысла в бэкапе лога. Если есть необходимость отката на время после последнего полного бэкапа, то необходимо производить бэкап лога транзакций с временным периодом не более критичного времени отктата.


Еще раз. Мне нужно вывести из базы данных файловую группу которая
1) Находится в ReadOnly около года
2) Иметь возможность восстановить ее как отдельную базу данных.

Собственно все текущие изменения в ReadWrite файловых группах до лампочки/НЕ НУЖНЫ.
Восстановить отдельную ReadOnly файловую группу как базу данных можно только если с PRIMARY.
Как выясняется в двух случаях из десяти еще и лог бэкапить нужно было.

Более того, а всегда ли можно восстановить полный бэкап ? Только его, не прибегая к бэкапам лога ?
Или это (ошибка при Restore) особенность частичных бэкапов ?

Основной вопрос остался прежним - Как определить нужен бэкап лога или нет ?
Greenhorn
Дата: 03.02.2009 09:53:24
UP.

Как определить посде бэкапа, что набор данных наката согласован с базой данных ???
Или будет ли успешен Restore with RECOVERY ???
Greenhorn
Дата: 03.02.2009 16:45:02
Greenhorn,

UP UP UP.

Вот о каких ошибках идет реч:
Msg 3410, Level 16, State 1, Line 9
Data in filegroup QUEUES is offline, and deferred transactions exist. Use RESTORE to recover the filegroup, 
or drop the filegroup if you never intend to recover it. Log truncation cannot occur until this condition
is resolved. 
Msg 3418, Level 16, State 1, Line 9
Recovery is unable to defer error 3410. Errors can only be deferred in databases using the full recovery model 
and an active backup log chain.
Msg 3167, Level 16, State 2, Line 9
RESTORE could not start database 'Test_200801'.
Msg 3013, Level 16, State 1, Line 9
RESTORE DATABASE is terminating abnormally.
Msg 3414, Level 21, State 2, Line 9
An error occurred during recovery, preventing the database 'Test_200801' (database ID 81) from restarting. 
Diagnose the recovery errors and fix them, or restore from a known good backup. 
If errors are not corrected or expected, contact Technical Support.

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