Комментарии
Избранное
Подписка
Сортировка:
Древо
(4) headMade,
(6) andr_andrey, спасибо за отзыв, но не считаю статью лаконичной. А работы нам еще много останется. Хотя бы от тех, кто 2 раза в день все индексы ребилдит :)
(7) Новиков, спасибо за отзыв, но по автоматизации бэкапов, начиная с SQL Server 2008 R2 и писать-то нечего. В 99% случаев схема "1 раз в сутки полный, каждые 10 минут РКЖТ, глубина 2-4 недели" работает без вопросов. Раньше хоть архивировать приходилось, а с 2008 R2 и сжатием и это стало ненужным. Для баз меньше 200 ГБ даже разностные бэкапы лень настраивать, а баз больше 1,5 ТБ (где уже можно подумать о чем-то более сложном чем вышеупомянутая схема с поправкой на то, что заменить часть полных бэкапов на разностные) вообще изчезающе мало.
Вот "самодельный лог-шиппинг" было бы, пожалуй, интересно описать.
- . В частности Там сейчас русский язык очень приличный и относительно систематичное изложение. Минус - реально почти вся информация.
- - классика, хоть и не совсем по администрированию.
- хоть и не блещет новизной, но полезно
- , если начинаешь чувствовать "гуристость"
- Ну и вся серия от Microsoft Press, но там самое интересное не переведено, насколько я помню:, ,
- обратить внимание на книги авторов Кален Дилейни (Kalen Delaney), Джо Селко (Joe Celko), Кен Хендерсон (Ken Henderson), Ицик Бен-Ган (Itzik Ben-Gan), Мамаев Е. В. (последний по SQL 2000, но на этом уровне минимально устарело)
(6) andr_andrey, спасибо за отзыв, но не считаю статью лаконичной. А работы нам еще много останется. Хотя бы от тех, кто 2 раза в день все индексы ребилдит :)
(7) Новиков, спасибо за отзыв, но по автоматизации бэкапов, начиная с SQL Server 2008 R2 и писать-то нечего. В 99% случаев схема "1 раз в сутки полный, каждые 10 минут РКЖТ, глубина 2-4 недели" работает без вопросов. Раньше хоть архивировать приходилось, а с 2008 R2 и сжатием и это стало ненужным. Для баз меньше 200 ГБ даже разностные бэкапы лень настраивать, а баз больше 1,5 ТБ (где уже можно подумать о чем-то более сложном чем вышеупомянутая схема с поправкой на то, что заменить часть полных бэкапов на разностные) вообще изчезающе мало.
Вот "самодельный лог-шиппинг" было бы, пожалуй, интересно описать.
(8) speshuric,
просто в последнее время часто встречается: при полной модели восстановления и двух полных резервных копиях базы в сутки, делают бэкап 60Гбайтного журнала транзакций 1 раз в 2 недели исключительно для того чтобы шринкнуть журнал и удалить этот "ненужный" бэкап. При этом форумы пестрят вопросом, что делать с переполняющим диск журналом транзакций. Пусть хоть тут они прочитают введение в суть вопроса без страшного слова "мануал".
Добавлю тут пример простенького скрипта архивирования резервных копий с помощью WinRar для владельцев SQLserver-а без возможности сжатия (пусть резервные копии хранятся в папке "C:\Backup\" имеют расширение "bak", и WinRar у нас установлен в папку "C:\WinRAR\"):
cd "C:\Backup"
for %%i in (*.bak) do "C:\WinRAR\winrar" m -ibck %%~ni %%i
просто в последнее время часто встречается: при полной модели восстановления и двух полных резервных копиях базы в сутки, делают бэкап 60Гбайтного журнала транзакций 1 раз в 2 недели исключительно для того чтобы шринкнуть журнал и удалить этот "ненужный" бэкап. При этом форумы пестрят вопросом, что делать с переполняющим диск журналом транзакций. Пусть хоть тут они прочитают введение в суть вопроса без страшного слова "мануал".
Добавлю тут пример простенького скрипта архивирования резервных копий с помощью WinRar для владельцев SQLserver-а без возможности сжатия (пусть резервные копии хранятся в папке "C:\Backup\" имеют расширение "bak", и WinRar у нас установлен в папку "C:\WinRAR\"):
cd "C:\Backup"
for %%i in (*.bak) do "C:\WinRAR\winrar" m -ibck %%~ni %%i
(13) andr_andrey,
Лично я не вижу смысла сейчас в RARении. SQL Server 2005 уже с поддержки планируют снимать, и сейчас, наверное, ни одной причины не назову оставаться на нём для 1С 8, а Express использовать в продукте как-то странно. Поэтому сейчас лучше всё-таки использовать сжатие.
Лично я не вижу смысла сейчас в RARении. SQL Server 2005 уже с поддержки планируют снимать, и сейчас, наверное, ни одной причины не назову оставаться на нём для 1С 8, а Express использовать в продукте как-то странно. Поэтому сейчас лучше всё-таки использовать сжатие.
спасибо за лаконичную статью, будет куда отправлять некоторых 1сников.
хотя, чего греха таить, пока таких статей мало или их никто не читает, не пыльная работа по настройке бэкапа давала на конфеты и мороженное :)
хотя, чего греха таить, пока таких статей мало или их никто не читает, не пыльная работа по настройке бэкапа давала на конфеты и мороженное :)
Автор молодец. Давно не видел такой грамотной подачи - с одной стороны, и - не скатывания к адаму и еве - с другой.
Ждем следующую обзорную статью, которые позволяют автоматизировать всю рутину, которая описана в статье "в несколько кликов мыши" (с).
Ждем следующую обзорную статью, которые позволяют автоматизировать всю рутину, которая описана в статье "в несколько кликов мыши" (с).
0) не забыть USE MASTER
1) в случае загрузки логов - RESTORE LOG:
2) В случае загрузки в существующую базу не забыть указать параметр REPLACE
3) Когда вручную создаете бэкап, то ещё раз помните - в поле где указываются файлы бэкапа будет использоваться не выделенный файл, а ВСЕ файлы. Т.е. MS:SQL размажет бэкап по всем указанным файлам.
В тексте статьи это есть, но только мельком.
Сам как-то нарвался, потом сожалел (удалил один из файлов, а бэкап был нужен).
PS
Хотел спросить - только у меня при загрузке через Management Studio не получается загрузить "на точку" (указываю вверху)?
Грузит полностью лог.
Через скрипты всё ОК.
1) в случае загрузки логов - RESTORE LOG:
RESTORE LOG mydb
FROM DISK = N'C:\Backup\log2.trn'
WITH STOPAT = '12.02.2013 21:45:00';2) В случае загрузки в существующую базу не забыть указать параметр REPLACE
3) Когда вручную создаете бэкап, то ещё раз помните - в поле где указываются файлы бэкапа будет использоваться не выделенный файл, а ВСЕ файлы. Т.е. MS:SQL размажет бэкап по всем указанным файлам.
В тексте статьи это есть, но только мельком.
Сам как-то нарвался, потом сожалел (удалил один из файлов, а бэкап был нужен).
PS
Хотел спросить - только у меня при загрузке через Management Studio не получается загрузить "на точку" (указываю вверху)?
Грузит полностью лог.
Через скрипты всё ОК.
Статья понравилась, спасибо!
Непонятен следующий момент:
Видимо, "10 января" - опечатка?
Где взять ЖТ с 0:00 по 12:00 10 февраля, в РКЖТ 5?
Непонятен следующий момент:
Пример. Для восстановления на 13:13:13 10 февраля нам понадобятся:
Полная копия F2 от 0:00 8 февраля
Разностная копия D2.2 от 0:00 10 февраля
РКЖТ 6 за период с 12:00 10 января по 12:00 12 февраля
Полная копия F2 от 0:00 8 февраля
Разностная копия D2.2 от 0:00 10 февраля
РКЖТ 6 за период с 12:00 10 января по 12:00 12 февраля
Видимо, "10 января" - опечатка?
Где взять ЖТ с 0:00 по 12:00 10 февраля, в РКЖТ 5?
Подскажите, можно ли создать план резервного копирования, как описано выше НО добавить к нему MIRROR TO ?
Т.е. у меня настроен план копирования всех баз(Backup Database Task) в папку. Для каждой базы свои подпапки. Но хотелось бы копировать их сразу в две папки.
Т.е. у меня настроен план копирования всех баз(Backup Database Task) в папку. Для каждой базы свои подпапки. Но хотелось бы копировать их сразу в две папки.
Мои "5 копеек":
Целостность и живучесть отложенных яиц(архивов) я контролирую с помощью ежедневного резервного копирования и восстановления рабочей базы в параллельное состояние. Иными словами, ночью главная база(base1) бакапится и тут же средствами TSQL реанимируется параллельно рабочей(base2).
Т.е. на каждое утро имеем две актуальные базы. Все развлекухи(отчеты, программные дописки) главбух "марьиванна" и иже с ней делают на base2, чтобы не сажать(по нагрузке) манагеров в рабочей(base1).
Целостность и живучесть отложенных яиц(архивов) я контролирую с помощью ежедневного резервного копирования и восстановления рабочей базы в параллельное состояние. Иными словами, ночью главная база(base1) бакапится и тут же средствами TSQL реанимируется параллельно рабочей(base2).
Т.е. на каждое утро имеем две актуальные базы. Все развлекухи(отчеты, программные дописки) главбух "марьиванна" и иже с ней делают на base2, чтобы не сажать(по нагрузке) манагеров в рабочей(base1).
(25) zzz_natali,
Автоматическое создание "игрушечной" копии рабочей базы по расписанию в целом хорошая идея, если только вы не забыли про такие "милые особенности":
Автоматическое создание "игрушечной" копии рабочей базы по расписанию в целом хорошая идея, если только вы не забыли про такие "милые особенности":
- Строки соединения с внешними данными и файловые каталоги в копии будут совпадать с боевыми. Так запущенное для тестирования задание выгрузки во внешнюю систему может нарушить работу продуктовой среды.
- Нередко пользователи (да и ИТшники) начинаю путать эти 2 базы, если открывают их одновременно.
- При расположении копии на основном сервере, загрузка сервера вызванная созданием и работой такой базы может оказаться заметной и неприемлемой.
Спасибо за статью! Не получилось сделать восстановление из полной копии с журналами транзакций через мастер восстановления. Если делать последовательно восстановление бака, потом журналов по одному то работает, при попытке добавить все файлы выдает ошибку. Неужели через мастер нельзя за раз сделать восстановление? Или я как то не так делаю?
(30) Собственно, регулярное резервное копирование ЖТ избавляет от самой частой причины его переполнения. Он не переполняется, потому что своевременно сливается и место внутри файлов освобождается. Если при настроенном резервном копировании ЖТ всё равно переполняется, то это может быть из-за:
Каждая из этих проблем сама по себе достаточно серьёзна, чтобы с ней разбираться безотлагательно. Для корректной "бережливой" переиндексации можно использовать скрипт из .
- Незавершённых длительных транзакций
- Поломанной репликации
- Огромных изменений в БД (например, нередко при перестроении индексов).
SELECT [name], recovery_model_desc, log_reuse_wait_desc FROM sys.databases;Каждая из этих проблем сама по себе достаточно серьёзна, чтобы с ней разбираться безотлагательно. Для корректной "бережливой" переиндексации можно использовать скрипт из .
(34) speshuric,
Если нет необходимости восстанавливать базу на любой момент времени и достаточно возможности восстановить "на начало дня" тогда есть смысл использовать Simple + Разностный BackUp в течении недели.
В этом случае не нужно делать копию ЖТ (смысла все равно нет) при этом ЖТ разрастается, вот сейчас посмотрел для базы с режимом Simple у меня в журнале 82% неиспользуемого места (280 Гб) и он вырос достаточно сильно.
В этом случае я думаю shrink не помешал бы?
Может в этом случае есть смысл после очередного разностного BackUp делать Shrink с реорганизацией так что бы оставалось 10% свободного места в журнале. ?
Если нет необходимости восстанавливать базу на любой момент времени и достаточно возможности восстановить "на начало дня" тогда есть смысл использовать Simple + Разностный BackUp в течении недели.
В этом случае не нужно делать копию ЖТ (смысла все равно нет) при этом ЖТ разрастается, вот сейчас посмотрел для базы с режимом Simple у меня в журнале 82% неиспользуемого места (280 Гб) и он вырос достаточно сильно.
В этом случае я думаю shrink не помешал бы?
Может в этом случае есть смысл после очередного разностного BackUp делать Shrink с реорганизацией так что бы оставалось 10% свободного места в журнале. ?
(35) почти уверен, что ЖТ разросся на какой-то конкретной операции: либо перестроение всех индексов, либо большая реструктуризация, либо проведение огромного куска БД в транзакции. Если это не победимо, то в этом случае в принципе может быть и имеет смысл шринкнуть до 25-40% от объёма файла данных
А с какой периодичностью и в какой последовательности необходимо выполнять регламентные операции:
- Проверка БД
- Сокращение БД
- Реорганизация индексов
- Перестроение индексов
- Обновление статистики
- Очистка КЭШа
А то в разных публикациях разная информация
- Проверка БД
- Сокращение БД
- Реорганизация индексов
- Перестроение индексов
- Обновление статистики
- Очистка КЭШа
А то в разных публикациях разная информация
(37) AleksSF,
Ну потому и разная, что для разных БД - разные рекомендации. Если говорить о небольших БД (до 500 ГБ на всем сервере), то я бы сделал примерно так:
Проверка БД - никогда или раз в 1-2-4 недели по выходным, если уж очень хочется.
Сокращение БД - никогда (или раз в год, если база сворачивается)
Реорганизация и перестроение индексов вместе с обновлением статистики - раз в неделю, но не для всех таблиц, а с анализом фрагментации (в другой моей статье пример скрипта)
"Очистка кэша" не нужна никогда.
А с какой периодичностью и в какой последовательности необходимо выполнять регламентные операции:
- Проверка БД
- Сокращение БД
- Реорганизация индексов
- Перестроение индексов
- Обновление статистики
- Очистка КЭШа
А то в разных публикациях разная информация
- Проверка БД
- Сокращение БД
- Реорганизация индексов
- Перестроение индексов
- Обновление статистики
- Очистка КЭШа
А то в разных публикациях разная информация
Ну потому и разная, что для разных БД - разные рекомендации. Если говорить о небольших БД (до 500 ГБ на всем сервере), то я бы сделал примерно так:
Проверка БД - никогда или раз в 1-2-4 недели по выходным, если уж очень хочется.
Сокращение БД - никогда (или раз в год, если база сворачивается)
Реорганизация и перестроение индексов вместе с обновлением статистики - раз в неделю, но не для всех таблиц, а с анализом фрагментации (в другой моей статье пример скрипта)
"Очистка кэша" не нужна никогда.
Огреб только что странную ошибку,
При восстановлении в непустую базу с отметкой перезаписывать данные.
Все перенеслось, но у некоторых справочников часть данных потерялась.
При этом отчеты с оборотами, остатками сходятся.
Пробую второй раз с выгрузкой в Новую (пустую) базу
SQL 2008
раньше вроде таких проблем не было.
При восстановлении в непустую базу с отметкой перезаписывать данные.
Все перенеслось, но у некоторых справочников часть данных потерялась.
При этом отчеты с оборотами, остатками сходятся.
Пробую второй раз с выгрузкой в Новую (пустую) базу
SQL 2008
раньше вроде таких проблем не было.
Нарисовал немножко скриптов для работы с бэкапами, может пригодится кому.
Схема работы такая:
Делается полный бэкап (раз в сутки, к примеру), складывается в отдельный файл <dbName>-yyy-mm-dd_hh-mm-ss.bak.
Далее раз в N минут делается бэкап лога, складывается также в отдельный файл <dbName>-yyy-mm-dd_hh-mm-ss_Log.bak,
т.е. все логи - в одном файле.
Расположение и имена файлов фиксируются в момент полного бэкапа - для этого создаётся табличка в msdb.
На сервере, базы которого нужно бэкапить создаются вспомогательные 2 таблички, и 3 SP-шки.
Таблички
- BackupLog - информация о полных резервных копиях
- BackupLog_Diff - информация о разностных копиях
SP-шки для бэкапа:
- dbo.BackupDatabase(@dbName, @dir)
- dbo.BackupTransactionLog(@dbName)
- dbo.BackupDatabaseDiff(@dbName, @dir)
SP-шки для просмотра содержимого файлов, и восстановления:
- dbo.RestoreDatabase(@DestDatabase, @SrcServer, @SrcDb = '', @idBackup = -1)
Разворачивает основной бэкап, в режиме NORECOVERY
Параметры:
@DestDatabase - имя базы, куда хотим развернуть бэкап
@SrcServer - имя сервера, на котором делается бэкап (т.е. где живёт табличка BackupLog)
@SrcDb - имя базы, бэкап которой надо развернуть. Если не указано, то д.б. указан параметр @idBackup
@idBackup - ID из таблички BackupLog. Если указан, то будет восстановлен соотв. файл
- dbo.RestoreTransactionLog(@DestDatabase, @SrcServer, @idBackup, @nStartFile int = -1, @nEndFile int = -1, @fFinal int = 0)
Разворачивает набор логов
Параметры:
@DestDatabase
@SrcServer
@idBackup
@nStartFile, @nEndFile - диапазон номеров логов внутри файла
@fFinal - если 1, то восстановление последнего лога будет с параметром RECOVERY. По умолчанию NORECOVERY
- dbo.ShowBackupHeader(@SrcServer, @idBackup)
Показывает содержимое файлов бэкапа с указанным ID
Схема работы такая:
Делается полный бэкап (раз в сутки, к примеру), складывается в отдельный файл <dbName>-yyy-mm-dd_hh-mm-ss.bak.
Далее раз в N минут делается бэкап лога, складывается также в отдельный файл <dbName>-yyy-mm-dd_hh-mm-ss_Log.bak,
т.е. все логи - в одном файле.
Расположение и имена файлов фиксируются в момент полного бэкапа - для этого создаётся табличка в msdb.
На сервере, базы которого нужно бэкапить создаются вспомогательные 2 таблички, и 3 SP-шки.
Таблички
- BackupLog - информация о полных резервных копиях
- BackupLog_Diff - информация о разностных копиях
SP-шки для бэкапа:
- dbo.BackupDatabase(@dbName, @dir)
- dbo.BackupTransactionLog(@dbName)
- dbo.BackupDatabaseDiff(@dbName, @dir)
SP-шки для просмотра содержимого файлов, и восстановления:
- dbo.RestoreDatabase(@DestDatabase, @SrcServer, @SrcDb = '', @idBackup = -1)
Разворачивает основной бэкап, в режиме NORECOVERY
Параметры:
@DestDatabase - имя базы, куда хотим развернуть бэкап
@SrcServer - имя сервера, на котором делается бэкап (т.е. где живёт табличка BackupLog)
@SrcDb - имя базы, бэкап которой надо развернуть. Если не указано, то д.б. указан параметр @idBackup
@idBackup - ID из таблички BackupLog. Если указан, то будет восстановлен соотв. файл
- dbo.RestoreTransactionLog(@DestDatabase, @SrcServer, @idBackup, @nStartFile int = -1, @nEndFile int = -1, @fFinal int = 0)
Разворачивает набор логов
Параметры:
@DestDatabase
@SrcServer
@idBackup
@nStartFile, @nEndFile - диапазон номеров логов внутри файла
@fFinal - если 1, то восстановление последнего лога будет с параметром RECOVERY. По умолчанию NORECOVERY
- dbo.ShowBackupHeader(@SrcServer, @idBackup)
Показывает содержимое файлов бэкапа с указанным ID
Прикрепленные файлы:
SQL_Backup.rar
(46) alexfps79,
Только если в это время были огромные открытые транзакции (тогда там кусок журнала транзакций, необходимый, чтобы учесть изменения происходившие во время бэкапа). Ну или случайно в тот же файл еще что-то запихнули. Уточнить можно командами RESTORE HEADERONLY и RESTORE FILELISTONLY
Только если в это время были огромные открытые транзакции (тогда там кусок журнала транзакций, необходимый, чтобы учесть изменения происходившие во время бэкапа). Ну или случайно в тот же файл еще что-то запихнули. Уточнить можно командами RESTORE HEADERONLY и RESTORE FILELISTONLY
Спасибо большое за статью! Настраивал бэкап по инструкции - возникли вопросы. при настройке 2 плана дифференциального копирования на скриншоте и в пояснениях не указано - разширение файла ставить так же как и в полном бэкапе *.bak , или ставить *.diff - как в примерах?
Я к чему спрашиваю - при проверке планов было всё нормально, создался файл .bak (правда, не заметил, чтоб сжатие сработало), потом создался *.diff и *.tm для ркжт. Сегодня утром проверяю логи - вижу что дифференциальное копирование не сработало :
И так по всем 16 базам пользователей :(
Это первый момент. Второй - из статьи я так и не понял, что делать с огромным файлом лога транзакций? Почитал по рекомендуемой тут ссылке : заявлялось, что *.ldf сам усекается после создания полной ркжт.
Описываю ситуацию. файл базы CSM_TEST.mdf весом 3,91 ГБ (4 203 544 576 байт)... и есть файлик CSM_TEST_log.LDF весом 33,9 ГБ (36 402 692 096 байт). И что с ним делать?
Разностная резервная копия
Аналогично — разностная копия
BACKUP DATABASE [mydb] TO DISK = N'C:\Backup\mydb.diff'
WITH DIFFERENTIAL, INIT, FORMAT, STATS = 1, CHECKSUM
Аналогично — разностная копия
BACKUP DATABASE [mydb] TO DISK = N'C:\Backup\mydb.diff'
WITH DIFFERENTIAL, INIT, FORMAT, STATS = 1, CHECKSUM
Я к чему спрашиваю - при проверке планов было всё нормально, создался файл .bak (правда, не заметил, чтоб сжатие сработало), потом создался *.diff и *.tm для ркжт. Сегодня утром проверяю логи - вижу что дифференциальное копирование не сработало :
GO
BACKUP DATABASE [82PMOVK_AK] TO DISK = N''F:\_arhive\82PMOVK_AK\82PMOVK_AK_backup_2015_10_21_105824_7325670.diff'' WITH DIFFERENTIAL , NOFORMAT, NOINIT, NAME = N''82PMOVK_AK_backup_2015_10_21_105824_7325670'', SKIP, REWIND, NOUNLOAD, STATS = 10
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N''82PMOVK_AK'' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N''82PMOVK_AK'' )
if @backupSetId is null begin raiserror(N''Ошибка верификации. Сведения о резервном копировании для базы данных "82PMOVK_AK" не найдены.'', 16, 1) end
RESTORE VERIFYONLY FROM DISK = N''F:\_arhive\82PMOVK_AK\82PMOVK_AK_backup_2015_10_21_105824_7325Это первый момент. Второй - из статьи я так и не понял, что делать с огромным файлом лога транзакций? Почитал по рекомендуемой тут ссылке : заявлялось, что *.ldf сам усекается после создания полной ркжт.
Описываю ситуацию. файл базы CSM_TEST.mdf весом 3,91 ГБ (4 203 544 576 байт)... и есть файлик CSM_TEST_log.LDF весом 33,9 ГБ (36 402 692 096 байт). И что с ним делать?
(48) Какие расширения у файлов вообще не имеет значения. Попробуй выполнить этот запрос в студии, возможно сразу увидишь, что не так (например, может банально прав не хватать).
Лог усекается при полном бэкапе базы (а не лога). Если он всё время растёт, то возможно проблема в чём-то другом.
(49) Вот да, тоже было бы интересно побороть эту особенность. У нас в основном экспериментальные базы на отдельном сервере, но иной раз бывает необходимость.
Лог усекается при полном бэкапе базы (а не лога). Если он всё время растёт, то возможно проблема в чём-то другом.
(49) Вот да, тоже было бы интересно побороть эту особенность. У нас в основном экспериментальные базы на отдельном сервере, но иной раз бывает необходимость.
(50) ADirks, Лог получилось усечь, выполнив
А вот с дифференциальным копированием - беда прямо. Принудительно запустил все задачи, как показано в шаге №15 -- успешно создался полный бэкап, потом дифференциальный, потом ркжт.
Проверяю на следующий день лог по плану 2 (который за дифференциальное отвечает) - -снова вижу ошибки. По Вашему совету пробую это сделать запросом, получаю ту же ошибку
И так выборочно по каждой из 16ти баз. Почему SQL не находит полный бэкап, который лежит в той же папке - для меня загадка :(
DBCC SHRINKFILEА вот с дифференциальным копированием - беда прямо. Принудительно запустил все задачи, как показано в шаге №15 -- успешно создался полный бэкап, потом дифференциальный, потом ркжт.
Проверяю на следующий день лог по плану 2 (который за дифференциальное отвечает) - -снова вижу ошибки. По Вашему совету пробую это сделать запросом, получаю ту же ошибку
И так выборочно по каждой из 16ти баз. Почему SQL не находит полный бэкап, который лежит в той же папке - для меня загадка :(
(51) А точно ли есть полный бэкап? Проверяется легко: делаешь восстановление базы вручную, если в списке "... резервные наборы" внизу нет ничего - значит нет бэкапа (по крайней мере с точки зрения сервера). Может, файл после бэкапа перемещался/переименовавался?
Опять же, можно в студии запустить скрипт полного бэкапа, и сразу же дифф - может что-то прояснится.
Кстати, эти самые дифференциальные бэкапы актуальны только при совсем уж больших объемах баз. У нас к примеру база 40Г, и я делаю полный бэкап по пятницам, и каждые 15 мин. бэкап лога. Лога за неделю всего гиг набегает, восстанавливается за 15мин, а с диффами только гемор один.
Опять же, можно в студии запустить скрипт полного бэкапа, и сразу же дифф - может что-то прояснится.
Кстати, эти самые дифференциальные бэкапы актуальны только при совсем уж больших объемах баз. У нас к примеру база 40Г, и я делаю полный бэкап по пятницам, и каждые 15 мин. бэкап лога. Лога за неделю всего гиг набегает, восстанавливается за 15мин, а с диффами только гемор один.
(52) ADirks, судя по скриншоту - -сервер не видит файла полного бэкапа? Если указываю вручную - вроде опознаёт его корректно.
То есть- при восстановлении сначала восстанавливается полный лог, а потом вся цепочка ркжт, создаваемые каждые 15 минут? Или нужен будет только последний ркжт?
Может, файл после бэкапа перемещался/переименовавался?
Нет, не перемещался, не переименовывался. Всё настраивалось по статье в этом топике.
У нас к примеру база 40Г, и я делаю полный бэкап по пятницам, и каждые 15 мин. бэкап лога. Лога за неделю всего гиг набегает, восстанавливается за 15мин, а с диффами только гемор один.
То есть- при восстановлении сначала восстанавливается полный лог, а потом вся цепочка ркжт, создаваемые каждые 15 минут? Или нужен будет только последний ркжт?
Прикрепленные файлы:
(53) По первой части ничего сказать не могу, вроде должно всё работать. Когда экспериментировал с диффами - работало.
Про восстановление по логам:
Сначала восстанавливается полный бэкап в режиме NORECOVERY, потом восстанавливаются все куски ркжт начиная с первого, до нужного. Самый последний кусок ркжт восстанавливается с флагом RECOVERY, и получаем рабочую базу.
Как это делается можно посмотреть в скриптах, которые я в (44) приводил. Удобная фигня, как раз когда баз много. Не надо каждый раз всё прописывать в планах обслуживания.
к примеру, так выглядит еженедельный бэкап:
use msdb
exec dbo.BackupDatabase 'dinal2011', '\\NAS2\Backup\1Cv77'
а так бэкап лога:
use msdb
exec dbo.BackupTransactionLog 'dinal2011'
развёртывание тестовой среды (на тестовом сервере):
exec msdb.dbo.RestoreDatabase 'test77', '[1CSQL]', '', 59
exec msdb.dbo.RestoreTransactionLog 'test77', '[1CSQL]', 59, 1, 389, 1
Про восстановление по логам:
Сначала восстанавливается полный бэкап в режиме NORECOVERY, потом восстанавливаются все куски ркжт начиная с первого, до нужного. Самый последний кусок ркжт восстанавливается с флагом RECOVERY, и получаем рабочую базу.
Как это делается можно посмотреть в скриптах, которые я в (44) приводил. Удобная фигня, как раз когда баз много. Не надо каждый раз всё прописывать в планах обслуживания.
к примеру, так выглядит еженедельный бэкап:
use msdb
exec dbo.BackupDatabase 'dinal2011', '\\NAS2\Backup\1Cv77'
а так бэкап лога:
use msdb
exec dbo.BackupTransactionLog 'dinal2011'
развёртывание тестовой среды (на тестовом сервере):
exec msdb.dbo.RestoreDatabase 'test77', '[1CSQL]', '', 59
exec msdb.dbo.RestoreTransactionLog 'test77', '[1CSQL]', 59, 1, 389, 1
(54) ADirks, посмотрел скрипты в (44) - ещё больше запутался. Я так понял там идёт работа с файловыми группами? Синтаксис в скриптах очень отличается от синтаксисе в статье. Если делать ежедневный полный бэкап, а потом каждый час ркжт, то - грубо говоря, при сбое я могу ограничиться восстановлением последнего полного бэкапа в режиме норекавери, а потом поочерёдно накатывать ркжт с флагом норекавери от момента полного бэкапа и до последней ркжт с флагом рекавери? Максимум что я потеряю - данные за 1 час работы? Или я что-то упустил?
Статью несколько раз перечитывал, и с каждым разом всё больше и больше вопросов, чем ответов.
Причём же тут РКЖТ? Я думал - речь идёт о логе транзакций, который разрастается и весит в несколько раз больше самой базы?
[CUOTE]ЖТ нужно перидически чистить вручную, уменьшать, шринкать. Нет, не надо и даже наоборот — нежелательно. Если освобождать ЖТ между РКЖТ, то будет нарушена цепочка РКЖТ, нужная для восстановления. А постоянные уменьшения/расширения файла приведут к его физической и логической фрагментации.[/IS-QUOTE] Если нежелательно, что делать с логом транзакций в 30-40 гигабайт при размере базы 3-7 гигабайт? Это разве нормальная ситуация? И разве плохо будет сделать болный бэкап, потом перевести базу в simple, шринкануть лог транзакций до нуля, вернуть в полную модель восстановления?
Статью несколько раз перечитывал, и с каждым разом всё больше и больше вопросов, чем ответов.
Частые заблуждения и мифы:
"РКЖТ содержит данные журнала транзакций от момента предыдущего полного или разностного бэкапа". Нет, это не так. РКЖТ содержит и на первый взгляд бесполезные данные между предыдущей РКЖТ и последующим полным бэкапом.
Почему последующим полным бэкапом, а не следующим ркжт? Речь же идёт о цепочке ркжт?
"РКЖТ содержит данные журнала транзакций от момента предыдущего полного или разностного бэкапа". Нет, это не так. РКЖТ содержит и на первый взгляд бесполезные данные между предыдущей РКЖТ и последующим полным бэкапом.
"Полный или разностный бэкап должны приводить к освобождению места внутри журнала транзакций". Нет, это не так. Полный и разностный бэкап не трогают цепочку РКЖТ.
Причём же тут РКЖТ? Я думал - речь идёт о логе транзакций, который разрастается и весит в несколько раз больше самой базы?
[CUOTE]ЖТ нужно перидически чистить вручную, уменьшать, шринкать. Нет, не надо и даже наоборот — нежелательно. Если освобождать ЖТ между РКЖТ, то будет нарушена цепочка РКЖТ, нужная для восстановления. А постоянные уменьшения/расширения файла приведут к его физической и логической фрагментации.[/IS-QUOTE] Если нежелательно, что делать с логом транзакций в 30-40 гигабайт при размере базы 3-7 гигабайт? Это разве нормальная ситуация? И разве плохо будет сделать болный бэкап, потом перевести базу в simple, шринкануть лог транзакций до нуля, вернуть в полную модель восстановления?
Такой вопрос по теме: есть рабочая база, есть также развернутая на том же SQL серваке копия для экспериментов, куда периодически загружается SQL бэкап рабочей. Загрузка идет с флагом WITH REPLACE. При выборе бэкапа пути автоматом проставляются базы источника, и вот никак не могу разобраться, нужно ли менять имена на имена файлов базы-приемника? По идее если мы загружаем с WITH REPLACE, должны перезатираться файлы приемника, по факту - то пишет, что файлы используются, то загружает без вопросов, перезатирая файлы приемника (пути при этом не меняются, т.е. остаются от приемника)
Скрипты выглядят непонятно, т.к. там все SQL-команды генерируются динамически
По сути, при восстановлении выполняется серия команд
RESTORE DATABASE [Database] FROM DISK = N'\\path\Database.bak' WITH NORECOVERY, NOUNLOAD, REPLACE, STATS = 5
RESTORE LOG [Database] FROM DISK = N'\\path\Database_Log.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD
RESTORE LOG [Database] FROM DISK = N'\\path\Database_Log.bak' WITH FILE = 2, NORECOVERY, NOUNLOAD
RESTORE LOG [Database] FROM DISK = N'\\path\Database_Log.bak' WITH FILE = 3, NORECOVERY, NOUNLOAD
...
RESTORE LOG [Database] FROM DISK = N'\\path\Database_Log.bak' WITH FILE = 200, RECOVERY, NOUNLOAD
В принципе, имея бэкап лога можно восстановить состояние БД на любое время, с точностью до SQL-транзакции (не пробовал). Но проще делать бэкап лога почаще.
Что касается размера файла лога - то он никогда не уменьшается. В момент полного бэкапа базы место внутри файла "освобождается", таким образом, чтобы файл лога не рос сильно, надо чаще делать полный бэкап. У нас, при описанных выше условиях, файл лога 25Г. Т.е. при еженедельном полном бэкапе лог вырастает чуть больше, чем пол базы. Ну и ладно, никого не парит. И шринкать его совершенно ни к чему.
По сути, при восстановлении выполняется серия команд
RESTORE DATABASE [Database] FROM DISK = N'\\path\Database.bak' WITH NORECOVERY, NOUNLOAD, REPLACE, STATS = 5
RESTORE LOG [Database] FROM DISK = N'\\path\Database_Log.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD
RESTORE LOG [Database] FROM DISK = N'\\path\Database_Log.bak' WITH FILE = 2, NORECOVERY, NOUNLOAD
RESTORE LOG [Database] FROM DISK = N'\\path\Database_Log.bak' WITH FILE = 3, NORECOVERY, NOUNLOAD
...
RESTORE LOG [Database] FROM DISK = N'\\path\Database_Log.bak' WITH FILE = 200, RECOVERY, NOUNLOAD
В принципе, имея бэкап лога можно восстановить состояние БД на любое время, с точностью до SQL-транзакции (не пробовал). Но проще делать бэкап лога почаще.
Что касается размера файла лога - то он никогда не уменьшается. В момент полного бэкапа базы место внутри файла "освобождается", таким образом, чтобы файл лога не рос сильно, надо чаще делать полный бэкап. У нас, при описанных выше условиях, файл лога 25Г. Т.е. при еженедельном полном бэкапе лог вырастает чуть больше, чем пол базы. Ну и ладно, никого не парит. И шринкать его совершенно ни к чему.
что-то SQL кривит, не могу понять где. Поудалял все планы обслуживания и архивации, в логе ERRORLOG всё равно регулярно появляются записи
Что это такое, почему оно стартует регулярно в 21.00 и по всем базам? Подозрение, что именно после этого и не видит SQL изначально созданного полного бэкапа.
2015-11-14 21:00:27.11 Database backed up. Database: 83BP_NN_TRIM, creation date(time): 2015/02/10(12:34:50), pages dumped: 90401, first LSN: 756:4676:37, last LSN: 756:4692:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'{101F414D-13B6-4E75-9E34-9A17172239BB}19'}). This is an informational message only. No user action is required.Что это такое, почему оно стартует регулярно в 21.00 и по всем базам? Подозрение, что именно после этого и не видит SQL изначально созданного полного бэкапа.
Стоит задача иметь возможность восстановить или откатить базу с потерей данных максимум за один час. Есть два сервера: на одном одна база до 50 гб, на втором 30-50 баз по 1-2 гб. Что будет эффективнее (по параметрам: надежность, минимальная нагрузка на сервер резервированием, минимальных размер арихивов сам посмотрю) для каждого из серверов делать каждый час по всем базам сервера разностных архив или архив журнала транзакции?
(58) grachev1c,
Для суммы в 150 ГБ с двух серверов и планировать-то лень. Это ж даже полный размер на 2 минуты неспешного копирования на современном железе. Я бы сделал раз в день полный и раз в 5-10 минут ЖТ. Если дисковая система нормально спроектирована (данные, ЖТ и темпдб на разных дисках), то нагрузки не будет. При этом можно где-нибудь сразу разворачивать болванку в norecovery и время восстановления почти равно времени обнаружения - как бы тёплый резерв, как бы аналог доставки журналов (лог шиппинг). С учетом сжатия (5-8 раз обычно, но таблица конфигурации хуже) одного раздела в 1 ТБ хватит "навсегда" (годовая история бэкапов).
Для суммы в 150 ГБ с двух серверов и планировать-то лень. Это ж даже полный размер на 2 минуты неспешного копирования на современном железе. Я бы сделал раз в день полный и раз в 5-10 минут ЖТ. Если дисковая система нормально спроектирована (данные, ЖТ и темпдб на разных дисках), то нагрузки не будет. При этом можно где-нибудь сразу разворачивать болванку в norecovery и время восстановления почти равно времени обнаружения - как бы тёплый резерв, как бы аналог доставки журналов (лог шиппинг). С учетом сжатия (5-8 раз обычно, но таблица конфигурации хуже) одного раздела в 1 ТБ хватит "навсегда" (годовая история бэкапов).
Я конечно дико извиняюсь, что поднимаю старую тему, но все таки. Не совсем понятно, как сделать зеркальную резервную копию? В уже спрашивали, но на этот вопрос тихо ответили в и не совсем понятно как это сделать. Можно ли какой нибудь пример?
(60) Зеркальную резервную копию делать при помощи "MIRROR TO", но насколько я помню в maintenance plan это не настраивается, надо писать скрипт. Способ обхода - копировать после создания (это можно настроить). Пример есть и в статье и в
(61) Речь о предложении "MIRROR TO" из синтаксиса BACKUP DATABASE.
(61) Речь о предложении "MIRROR TO" из синтаксиса BACKUP DATABASE.
Добрый день.
Копирую бэкапы bak и trn на сетевой диск, при этом скорость копирования 500-1000КБ, это нормально ?)
В архив (также на сетевой диск) эти файлы сжимает на скорости 2000 КБ/сек, что тоже мало. Как ускорить копирование?
Железо 4 sas винта в 10RAID, сеть гигабит, ничего не загружено, другие файлы копирует нормально.
Копирую бэкапы bak и trn на сетевой диск, при этом скорость копирования 500-1000КБ, это нормально ?)
В архив (также на сетевой диск) эти файлы сжимает на скорости 2000 КБ/сек, что тоже мало. Как ускорить копирование?
Железо 4 sas винта в 10RAID, сеть гигабит, ничего не загружено, другие файлы копирует нормально.
(69) то что там указано, мне лично не понятно.
Вот такой текст в логах выходит...
"Executed as user WorkgRoUP\система. Microsoft® SQL Server Execute Package Utility Version 10.0.1600.22 for 64-bit Copyright© Microsoft Corp 1984-2005. All rights reserved. The SQL Server Execute Package Utility requires integration Services to be installed one of these editions of SQL 2008: Standard, Enterprise, Develope, or Evalution. To install integration Services, run SQL Server Setup and select integration Services. The package execution failed. The step failed".
Вот такой текст в логах выходит...
"Executed as user WorkgRoUP\система. Microsoft® SQL Server Execute Package Utility Version 10.0.1600.22 for 64-bit Copyright© Microsoft Corp 1984-2005. All rights reserved. The SQL Server Execute Package Utility requires integration Services to be installed one of these editions of SQL 2008: Standard, Enterprise, Develope, or Evalution. To install integration Services, run SQL Server Setup and select integration Services. The package execution failed. The step failed".
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.