Как вывести базу из состояния restoring
Dating > Как вывести базу из состояния restoring
Download links: → Как вывести базу из состояния restoring → Как вывести базу из состояния restoring
This dialog box displays the name of the next media set if known and the name and description of the next backup set. No user action required. В файле журнала я нашел следующее: CREATE DATABASE или ALTER DATABASE не удалось, потому что результат кумулятивный размер базы данных будет превышать ваш лицензионный лимит в размере 10240 МБдля каждой базы данных. Прежде чем приступать к восстановлению последующих журналов регистрации транзакций, SQL Server придется привести базу данных в состояние восстановления, применить хранимые в файле UNDO транзакции и затем, наконец, восстановить следующий журнал регистрации транзакций в цепочке резервирования. Надеюсь, вы резервируете журналы регистрации транзакций, если для вас важно иметь возможность восстановления по этой схеме? Эти параметры также следует отнести к категории дополнительных проверок. Про некоторые из них например, про возможность восстановления до метки транзакции или LSN уже рассказано. В зависимости от размеров базы данных я обычно устанавливаю это значение в пределах от 10 до 50. Файл резервной копии Backup file Указывает файл резервной копии для заключительного фрагмента журнала. Резервирование остатка журнала Резервное копирование остатка, или «хвоста», журнала — это особый процесс, состоящий из двух фаз: выполняется резервная копия последнего журнала регистрации транзакций, а затем база данных переводится в состояние, блокирующее все попытки соединения с ней, за исключением соединения с целью получения резервной копии остатка журнала записей в журнале транзакций, появившихся там с момента последней операции резервного копирования этого журнала и выполнения последующего процесса восстановления. No additional transaction logs can be restored — после завершения восстановления база данных будет приведена в рабочее состояние. В этом случае обычно буквы дисков, начиная с D: меняются, а т.
SQL Server поддерживает три различных вида резервных копий — полную full backup , дифференциальную differential backup и резервную копию журнала транзакций transaction log backup. Первые два вида резервных копий доступны для баз данных в любой модели восстановления, резервная копия журнала транзакций — для баз данных в модели восстановления FULL и BULK-LOGGED про модели восстановления вкратце вы можете прочитать , а лучше в. Если вы используете модель восстановления SIMPLE — вы сможете восстановить свою базу только из полного бэкапа ну и накатить, дополнительно, дифференциальную копию. Вы никогда не восстановитесь на момент времени предшествующий сбою, только если вы не создали резервную копию непосредственно перед сбоем. Если ваша база данных находится в модели восстановления FULL и вы никогда не делаете бэкап журнала транзакций, но время от времени «обрезаете лог», прочитайте дальше — узнайте чего вы лишаетесь :. Если вы это читаете, я полагаю, что ваша база находится в модели восстановления FULL, вы регулярно делаете полные резервные копии и копии журналов транзакций. Кроме того, ваша «цепочка восстановления» из резервных копий журнала транзакций должна быть неповрежденной. Что такое «цепочка восстановления»? Это непрерывная последовательность резервных копий, состоящая из полного бэкапа и непрерывной последовательности резервных копий журнала транзакций. До тех пор пока у вас есть все эти резервные копии, вы сможете восстановить свою базу данных на любой момент времени между 12. Если вы удалите копию trlog2, созданную в 13. То же самое произойдет в случае, если кто-то создаст копию в 12. Чтобы начать новую цепочку восстановления вам нужно будет сделать полную резервную копию и, затем, резервную копию журнала транзакций. Во всем этом есть один не очень очевидный по крайней мере, так было для меня момент. Полная резервная копия всегда начинает, но никогда не прерывает цепочку восстановления это справедливо для SQL Server 2005 и старше. Разберем это на примере. Вдобавок к уже имеющимся копиям full1, trlog1, trlog2, trlog3 — непрерывная цепочка восстановления сделаем в 13. Теперь, если нам нужно восстановить базу данных на 14. Но, если окажется, что из копии full2 мы не можем восстановиться например, посыпался диск, содержащий эту копию , то мы можем воспользоваться нашей «первой» цепочкой восстановления — восстановить резервную копию full1 и последовательно накатить на нее копии журнала транзакций trlog1, trlog2, trlog3, trlog4, trlog5, trlog6. Точно также, мы можем использовать первую цепочку восстановления, для восстановления базы данных на 13. Таким образом, имея полную цепочку восстановления, мы можем восстановить нужную базу данных на любой момент времени между временем создания полной резервной копии и временем создания последней резервной копии. Небольшой хинт — если у вас полная модель восстановления, есть несколько резервных копий и ни одной копии журнала транзакций, но вы никогда не «обрезали» журнал транзакций — вы можете прямо сейчас создать эту резервную копию и получить возможность восстановления на любой момент времени между временем создания самой первой полной резервной копии и текущим моментом времени. Но, повторюсь, только в том случае, если резервные копии журнала транзакций раньше не создавались и журнал транзакций не обрезался. Дальше я расскажу несколько способов использования резервных копий SQL Server. Первый вариант он работает для всех моделей восстановления — необходимо восстановить базу данных из полной резервной копии. Если вы восстанавливаете базу данных с помощью GUI — нужно указать «Overwrite the existing database» на вкладке «Options». RECOVERY говорит о том, что базу данных необходимо перевести в согласованное состояние и разрешить соединения пользователей. В GUI это соответствует опции «Leave the database ready to use by rolling back uncommitted transactions. Additional transaction logs cannot be restored. После того как вы восстановили резервную копию с параметром RECOVERY, к ней нельзя применять дополнительно копии журналов транзакций и дифференциальные копии. Будьте внимательны, этот параметр устанавливается по умолчанию и если вы захотите «накатить» еще одну копию — процесс восстановления придется начать заново. В данном случае, при восстановлении каждых 10 % резервной копии, на вкладке Messages в SSMS будет появляться сообщение. При восстановлении с помощью GUI вы не можете управлять этим параметром — за изменениями можно следить на «графике» в нижнем левом углу. По умолчанию копия восстанавливается в то же самое место откуда она была сделана. Для использования MOVE вам необходимо знать логические имена файлов — их можно посмотреть с помощью представления sys. На рисунке показан пример использования этого представления. Второй вариант — восстановление из полной резервной копии и всех резервных копий журнала транзакций или дифференциальных копий. Восстановление всегда начинается с восстановления полной резервной копии, но если вы хотите после этого восстанавливать какие-либо дополнительные копии, вам нужно оставить базу в состоянии RESTORING. It is in the middle of a restore. Третий вариант — восстановление на момент времени. У меня есть база данных AdventureWorks, ее полная резервная копия и резервная копия журнала транзакций, сделанная ранее. AddressType представлен на рисунке: В 13. Тот же самый запрос теперь возвращает: Invalid object name 'Person. Еще один вариант восстановления данных. История из жизни :. Несколько месяцев назад попали в не очень приятную ситуацию — записи в одном из регистров сведений периодическом, не подчиненном регистратору были «испорчены». То есть они как бы остались, но свой смысл потеряли. Регистр был большим и нужным. Ошибка произошла несколько часов назад, так что полностью восстанавливать базу данных было нельзя. Собирались переносить данные с помощью обработки ВыгрузкаЗагрузкаДанныхXML, но программисты попросили попробовать перенести данные средствами SQL, в надежде, что это будет быстрее. Мы восстановили из бэкапов копию базы на момент времени предшествующий порче данных. На странице выбора объектов выбрали только одну — нужную нам таблицу: Еще два клика мышью и все. Таблица перенеслась, люди продолжили работу. Хочу обратить внимание на несколько нюансов. Во-первых, если не очищать таблицу-приемник, все данные в ней останутся, а новые могут и не появиться. Во-вторых, такой метод может подойти для некоторых регистров сведений и справочников, но для таблиц по которым делаются движения, или объектов, совершающих движения, придется восстанавливать множество дополнительных таблиц — 100 раз подумайте, прежде чем применять этот метод. Ну и вообще этот метод идет в разрез с лицензионным соглашением, но он быстр и удобен в некоторых случаях. Надеюсь эта информация была хоть кому-нибудь полезной. Не верьте мне на слово - попробуйте все это сделать на своих копиях!
Last updated
