Войти
Android, Windows, Apple, Ликбез. Социальные сети. Драйверы
  • Японские телефоны Новый японский смартфон
  • Lenovo G500S: характеристики, основные особенности
  • Определяем серию продукта видеокарт Nvidia Характеристики карты nvidia 9800 gt
  • А конкуренты у смартфона есть
  • Что такое расширение файла TRZ?
  • Не работает динамик в "айфоне"
  • Программа резервного копирования sql баз. Резервное копирование MS SQL

    Программа резервного копирования sql баз. Резервное копирование MS SQL

    Давайте рассмотрим нежелательную ситуацию. А именно: по какой-то причине вышла из строя БД. Что есть у нас? Полная копия, диференциальная копия на вчера, но на сегодня тоже есть данные, неужели нужно было делать диф.копирование каждый час? - Нет! Есть Журнал транзакций .
    Журнал транзакций - журнал, в который записываются все транзакции и все изменения базы данных, выполняемые каждой транзакцией. Т.е. любое действие с БД пошагово запысается в журнал. Каждая запись отмечается СУБД на предмет завершённости транзакции, выполнена или нет. С его помощью, можно восстановить состояние БД не только после сбоя, а и при непредвиденных действиях с данными. Откатить до определённого времени. Как и с БД, с журналом транзакций нужно проводить резервное копирование, полное, дифференциальное, инкрементное. Для восстановления части журнала транзакций после сбоя в промежутке между созданием резервных копий, нужно выполнить резервирование заключительного фрагмента журнала, который, по-сути, является точкой финализации резервного копирования. Выполняется после сбоя, как точка обратного отсчёта.
    Итак, для восстановления БД после сбоя нам нужны - актуальная полная копия БД, дифференциальная копия БД и копия журнала транзакций.

    Для самой базы данных существует 3 модели восстановления - простая, полная и модель с неполным протоколированием. Рассмотрим:

    1. Простая модель (Simple) - используется только полное резервирование. Нет диф. резервирования, как и резервирования журнала транзакций. Полные копии нужно создавать как можно чаще. Актуально для БД, используемых "только для чтения".
    2. Модель полного восстановления (Full) - наиболее применяемая модель, при которой доступны все функции резервного копирования данных и их восстановление. Поддерживает восстановление отдельных страниц данных. Происходит полное протоколирование транзакций сохраниние журнала транзакций.
    3. Модель с неполным протоколированием (Bulk-Logged) - предназначена, как дополнение к полной модели полного восстановления. Не поддерживает протоколирование большинство массовых операций, соответственно - не поддерживает восстановление БД до определённого момента времени.

    Рассмотрим наиболее актуальную цепочку создания резервных копий: Полное резервирование - раз в неделю, Дифференциальное резервирование - раз в день, Резервирование журнала транзакций - раз в час.
    Есть несколько вариантов создания резервных копий:

    • С помощью встроенного планировщика задач MS SQL
    • С помощью языка Transact-SQL
    • С помощью sqlcmd и Планировщика задач ОС
    • Вручную (что нас не устраивает, ибо тру админ должен постоянно бездельничать)

    Рассмотрим первый вариант, как наиболее юзабельный. Для этого используется Windows Server 2008 R2 Enterprise и MS SQL Server 2008 Eng.

    Итак, допустим, что у нас есть БД TECH:

    Переходим к инструменту создания Джобы:

    Трём правую клавишу мышака и вызываем Мастера Джобу:
    Выбираем галочку "Отдельное выполнение каждого задания", мы ведь выполняем только одно действие

    Мастер без тюрбана, но ведь не в размере тюрбане главное)) Выбираем тип желания, в нашем случае - полное резервирование:

    Мастер Джоба, как оказалось, чуточку немного еврей, поэтому переспрашивает ещё раз:

    "Параметры дополнительные выбрать стоит, о юнный паддаван!":
    здесь выбираем БД, срок хранения резервной копии, адрес (лента или диск), путь сохранения и главное - планировщик заданий!

    "Не стоит о базе данных забывать при выборе своём. Сконцентрируй силу и выбери БД":

    "Слишком быстро ты спешишь задание создать, нажать на кнопку стоит, что внизу с названием Shedule - Define".
    Собсно, планировщик заданий, где выбираем тип (повторение, единожды и т.д.), день, время, тип старта:

    Вот и всё, создали. Мастер Джоба крут и зелен. Смотрим в Maintance Plans состояние:

    Для параноиков, не бойтесь в этом признаться зеркалу, стоит заглянуть в душу SQL Server Agent - Job Activity Monitor, Мастер Джоба подробно покажет всё:

    Теперь, при удовлетворении заданных условий, должен создаться полный бэкап БД. По такому же принципу, создаётся диф.резервирование и резервирование журнала транзакций (эти подпункты разположены ниже "Полное резервирование" в списке выбора заданий).
    Крутите уши MSSQL-ю, как Вам удобно, не отвертите

    В следующей статье - создание с помощью Transact-SQL и пара примеров.

    В данной статье будет рассказано как вручную сделать полную резервную копию базы данных в с помощью программы «Среда Microsoft SQL Server Management Studio».

    1. Создание резервной копии

    На самом деле все довольно просто. Запускаем оснастку «» («Пуск » — «Все программы » — «SQL Server 2008 R2 » — «Среда Microsoft SQL Server Management Studio ») и вводим данные для авторизации.

    После чего в Обозревателе объектов раскрываем вкладку «Базы данных » и кликнем правой кнопкой мыши по той базе данных, для которой необходимо сделать резервную копию. В появившемся контекстном меню выберем «Задачи » (Tasks ) — «Создать резервную копию » (Back Up… ) .

    Запустится окно «Резервная копия базы данных » (Back Up Data Base ) . Убедимся, что стоит «Полная » (Full ), при необходимости зададим имя и описание, а также укажем назначение резервной копии. По умолчанию выбран путь на жестком диске компьютера в папку Backup основного расположения баз SQL-сервера. Для того чтобы изменить место размещения копии, сначала нажмем «Удалить » (Remove ), чтобы удалить существующее назначение, а затем «Добавить » (Add …) для добавления нового.

    Здесь зададим расположение и имя файла резервной копии и нажмем «ОК » . Таких мест назначений можно задать несколько. В этом случае резервная копия будет разбита на равные части, каждая часть в указанном файле.

    Когда все настройки установлены, нажимаем «ОК » и дожидаемся завершения задачи. Если все сделано правильно, в указанной директории мы найдем файл резервной копии базы данных SQL.

    2. Восстановление базы данных из резервной копии

    Восстановление происходит по аналогичной схеме. В «Среде Microsoft SQL Server Management Studio » выбираем базу из которой сделана резервная копия , кликаем по ней правой кнопкой мыши, в контекстном меню выбираем «Задачи » (Tasks ) — «Восстановить » (Restore ) — «База данных… » (Database… ).

    Откроется окно «Восстановление базы данных » (Restore Database ). Здесь, в качестве источника укажем «С устройства » (From device ) и выберем файл резервной копии (созданных в пункте 1).

    Установим флаг «Восстановить » (Restore ) напротив выбранной резервной копии. При необходимости, на вкладке «Параметры » (Options ), можно указать дополнительные параметры восстановления, о значении которых можно прочитать .

    После того, как все настройки сделаны, жмем «ОК » и дожидаемся сообщения об успешном восстановлении базы данных.

    3. Восстановление резервной копии в другую базу данных (копирование данных)

    Если же необходимо загрузить данные в базу данных, отличную от той из которой была сделана резервная копия , то при загрузке помимо действий, описанных в пункте 2, необходимо на вкладке «Параметры » (Options) задать имена файлов этой базы данных и установить флаг «Перезаписывать существующую базу данных » (WITH REPLACE).

    Помогла ли Вам данная статья?

    sqlcmd -S DECLSERVER\SQLGTD -E -Q «declare @s varchar(255) set @s=’E:\backup\GTD_’ + convert(varchar(1), datepart(dw, getdate())) + ‘.bak’ backup database GTD to disk = @s with init, noformat, skip, nounload»

    sqlcmd позволяет вводить инструкции Transact-SQL, системные процедуры и файлы скриптов из командной строки в редактор запросов в режиме SQLCMD,

    • -S - задает имя сервера, server[\instance_name] ;
    • DECLSERVER\SQLGTD - имя сервера/имя экземпляра, на котором крутится база;
    • -E - использует для соединения с SQL server вместо имени пользователя и пароля доверительное соединение;
    • -Q «cmdlinequery « - при запуске программы sqlcmd выполняет запрос, но выход из программы по завершении его выполнения не производится. Может быть выполнено несколько запросов, разделенных точкой с запятой. Заключайте запрос в кавычки, как показано выше;
    • declare - объявляем переменную s ,имя переменной всегда начинается с @, поэтому @s . В нашем случае @s - это папка (диск) хранения бэкапов;
    • varchar(n) - задает тип переменной @s как строковый с длинной строки n, в примере 255 символов;
    • set - задает значение переменной @s ,в примере это папка backup на диске E (E:\backup\ ), далее задается имя бэкап файла, где набор функций convert(varchar(1), datepart(dw, getdate())) возвращает в текстовом формате с длиной в 1 символ текущий день недели (понедельник – 1 , вторник – 2 , и т.д.) и добавляется расширение bak . На выходе получим файл с именем GTD_НомерДняНедели.bak ;
    • backup - создает бэкап;
    • database - указывает на создание бэкапа всей базы;
    • GTD - в нашем примере имя базы на SQL-сервере;
    • to disk - указывает на тип устройства резервного хранения, файл жесткого диска, и указана переменная @s , которой присвоено путь и имя создаваемого файла;
    • with init, noformat, skip, nounload - указывает на то, что необходимо произвести перезапись данных по кругу с переопределением заголовков, что позволит нам иметь 7 файлов бэкапа на каждый день недели, перезаписываемые по кругу.

    При необходимости можно использовать и другие функции, например сжатие, см. справку по запросам и функциям Transact-SQL.

    Шаг 2. Меняем расширение текстового файла на.cmd

    В итоге получаем файл backupGTD.cmd . Запускать созданный командный файл необходимо с той машины, где установлена БД MS SQL.

    Шаг 3. Автоматизируем данный процесс

    Рассмотрим данный шаг на примере MS Windows Server 2008: Диспетчер сервера -> Конфигурация -> Планировщик заданий -> Библиотека планировщика заданий.

    После изучения множества информации с разных источников, решил описать процесс настройки резервного копирования БД MS SQL Server для полной модели восстановления, какую модель использовать решать Вам, но от себя добавлю, что если в вашей БД большой поток информации (например создаются десятки, сотни или тысячи документов в 1 час), то потеря информации за день работы будет просто неприемлемой, в таком случае только полная модель обеспечит сохранность ваших данных. Данна статья предназначена для начинающих системных администраторов и содержит по моему мнению минимальный набор действий для резервного копирования БД 1С. Установка\Настройка самого SQL сервера и развертывание БД на нём в не рамках данной статьи.

    Все настройки будем производить с помощью SQL Management Studio. Для начала нужно создать Устройство резервного копирования, можно и не создавать, но на мой взгляд это гораздо удобнее и правельнее. в оснастке SQL Management Studio -> Объекты сервера-> Устройства резервного копирования. Нужно указать имя устройства и файл в котором будут храниться резервные копии (лучше с расширением BAK), в дальнейшем можно посмотреть содержимое носителя, там будут перечислены все резервные копии.

    Теперь можно приступать к настройки Плана обслуживания (Maintenance Plan). План Обслуживания можно создать сразу для всех БД, но удобнее для каждой БД создать свой план обслуживания.

    В нашем Плане обслуживания будет три подплана: 1 - резервное копирование БД (Полное); 2 - резервное копирование БД (Разностное); 3 - Резервное копирование Журнала транзакций. У каждого подплана есть свое расписание выполнения. Раписание каждый настраивает по своим усмотрениям, в моём же случае полное копирование делается раз в неделю в воскресенье, Разностное копирование каждый день кроме воскресенья, ЖТ - журнал транзакций каждый час. При такой модели резервирования можно восстановить искомую БД на любую дату и час, причем экономим пространство на жёстком диске т.к. полное резервирование выполняется фактически раз в неделю, а в течении недели только изменения.

    Настройка дневного расписания. Недельное отличается только установленной галочкой "Воскресенье" и снятыми с "понедельника" по "Субботу"

    Расписание для ЖТ. Красным выделено время сохранения в течении дня, имеет смысл например, если пользователи работают с БД в определённый период, если режим работы 24х7, то оставляем по уполчанию.

    На рисунке ниже, изображен редактор недельного подплана, он состоит из задач, которые выполняются в заданной последовательности. Последовательность задается вручную, причем зелёные стрелки означают, что следущая задача будет выполнена только при успешном выполнении предыдущей, а синяя, что задача выполнится при любом завершении предыдущей задачи. В редактор подплана обслуживания, задачи можно добавить из "Панель элементов", которая находится в левом верхнем углу, когда редактор открыт.

    Задачи. В каждую задачу нужно зайти и выбрать БД, для которой она будет выполняться и ряд других настроеек (если есть). Рассмотрим, какие задачи содержит недельный подплан нашего плана обслуживания.

    1. "Проверка целостности БД" (Check Database Integrity Task). Следующая задача будет выполняться, только если БД не содержит ошибок. (Замем резервировать БД с ошибками?)

    2. "Восстановить индекс" (Rebuild Index Task). Восстановить (Перестроить) индекс необходимо каждый день, т.к. при работе с индексами они сильно фрагментируются и при фрагментации более 25% SQL начинает заметно "тормозить". Эта операция довольно ресурсоёмка, поэтому её можно делать хотябы раз в неделю, а в дневном подплане заменить её менее ресурсоёмкую задачу "Реорганизация индекса".

    3. "Обновить статистику" (Update Statistics Task). Для оптимизации... Кстати эту задачу можно выполнять несколько раз в течении дня, если ваша БД сильно нагружена.

    4. После обновления статистики ОБЯЗАТЕЛЬНО нужно очистить процедурный кэш. Для этого перетаскиваем в редактор задачу "Выполнение инструкции T-SQL" и в поле "инструкция T-SQL:" написать процедуру DBCC FREEPROCCACHE . Но нужно учесть, что эта процедура очищает кэш у ВСЕХ БД, а мы обновили статистику по одной! Как очистить процедурный кэш для определённой БД, читаем . Вкратце: DBCC FLUSHPROCINDB(ID_БД)

    5. "Резервное копирование БД" (Back Up Database Task). В этой задаче указываем какую БД мы резервируем, тип резервной копии (Для недельного подплана - Полное, для дневного - Разностное, для часового - Журнал транзакций.) Ставим переключатель в положение "Создать резервную копию баз данных в одном или нескольких файлах" и добавляем ранее созданное устройство резервного копирования. В таком случае ВСЕ копии сохраняются в один файл, который указали при создании устройства резервного копирования, если переключатель оставить в "Создать файл резервной копии для каждой базы данных", то на каждое резервное копирование будет создаваться отдельный файл и на Полное и на Разностное и на ЖТ, что очень неудобно при восстановлении, зато удобно при хранении. Не забываем укзать что нужно сжимать резервные копии!

    6. "Очистка Журнала" Очищает записи, создаваемые при выполнении задач. Также можно включить задачу "Очистка после обслуживания" и настроить её для удаления текстовых логов или устаревших резервных копий.

    Подплан для резервирования ЖТ, состоит из одной задачи "Резервное копирование базы данных".ЖТ для меня удобнее сохранять не в Устройство резервного копирования, а в отдельный файл, что необходимо указать в настройке задачи.

    2. Просмотр информации о событиях резервного копирования и восстановления для базы данных

    Для того чтобы узнать, когда производилось создание резервных копий конкретной базы данных, а также восстановление базы данных из резервной копии, можно воспользоваться стандартным отчетом «» (Backup and Restore Events). Для формирования данного отчета необходимо в Обозревателе объектов (Server Oblects) кликнуть правой кнопкой мыши по соответствующей базе данных, в контекстном меню выбрать «Отчеты » (Reports) — «Стандартный отчет » (Standart Reports) — «События резервного копирования и восстановления » (Backup and Restore Events).

    Сформировавшийся отчет содержит в себе следующие данные:

    • Среднее время, затрачиваемое на операции резервного копирования (Average Time Taken For Backup Operations)
    • Успешные операции резервного копирования (Saccessful Backup Operations)
    • Ошибки операции резервного копирования (Backup Operation Errors)
    • Успешные операции восстановления (Saccessful Restore Operations)

    Для просмотра данной информации необходимо раскрыть соответствующую группировку в отчете.

    Помогла ли Вам данная статья?