Parus16.ru

Парус №16
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Резервное копирование базы данных

Резервное копирование базы данных

В этой статье рассказывается, как восстановить базу данных программы из резервной копии, сделанной программой несколько дней назад. Этой системой нельзя пользоваться , если вы используете в работе синхронизацию баз данных. Если при настроенной синхронизации БД вы откатите одну из участвующих в синхронизации баз данных на резервную копию, то рано или поздно при синхронизации вы получите ошибку «primary key musst be unique», после чего синхронизация у вас никогда работать больше не будет; для того, чтобы восстановить синхронизацию, надо будет заново настраивать ее на пустых базах данных, потеряв т.о. все введенные в программу данные на всех участвующих в синхронизации компьютерах.

Узнать, настроена ли у вас синхронизация баз данных, несложно. Для этого выберите, пожалуйста, в программе пункт меню Файл|Настройки|Синхронизация и в открывшемся окне проверьте номер базы данных. Если там стоит число «-1» (минус один), значит, синхронизацию БД вы не используете.

Введение

Программа Тирика-Магазин использует в работе две системы управления базами данных: систему SQLite в случае локального использования, то есть если вы не настраивали програму для работы в сети и используете ее на одном компьютере, и систему FireBird при работе в сети. Обе эти системы хранения данных чрезвычайно надежны и имеют встроенные механизмы восстановления данных после сбоев — даже фатальных сбоев вроде отключения электропитания. Нужно, однако, понимать, что встроенные в систему управления данными программные средства защиты от сбоев и восстановления — это что-то вроде подушек безопасности в автомобиле: они значительно повышают ваши шансы в случае аварии, но если водитель не соблюдает правил разумной езды, то подушки могут и не спасти.

Программа Тирика-Магазин обладает двумя дополнительными возможностями обезопаситься от сбоев и сохранить свои данные в критических ситуациях, фигурально выражаясь — дает вам как «водителю» этого «автомобиля» инструменты безопасной езды. Давайте рассмотрим их по очереди.

Отступление. А какую базу данных я использую?

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

Определить этот режим очень просто: для этого запустите программу Тирика-Магазин и выберите пункт меню Файл|Настройка, после чего переключитесь на вкладку Сеть. Если выпадающий список на этой вкладке установлен в положение «Одновременно будет работать только один человек», программа работает в локальном режиме, в любом другом случае она работает в сетевом режиме:

Автоматическое резервное копирование

Однопользовательская версия

По умолчанию программа Тирика-Магазин настроена так, что каждый день при первом запуске программы она будет автоматически делать резервную копию вашей базы данных. В случае, если программа работает в локальном (однопользовательском) режиме, программа складывает резервные копии базы данных в подпапку Backups той папки, куда установлена программа, скорее всего это будет C:Program FilesTirika ShopBackups. Создавая очередную резервную копию базы данных, программа не затирает прошлую резервную копию, но размещает новую копию рядом со старой, называя файл резервной копии по дате ее создания, например 2012-02-22.zip для резервной копии, созданной 22 февраля 2012 года.

Некоторые резервные копии в имени файла включают также и время, например файл 2012-02-20-11-51-23.zip был создан 20 февраля 2012 года в 11 часов 51 минуту 23 секунды. Такие «внеплановые» резервные копии программа создает при установке обновлений в случае, если это обновление изменит структуру базы данных; кроме «длинного» имени файла «внеплановые» резервные копии ничем не отличаются от «плановых»:

;

Прежде чем восстанавливать данные из резервной копии убедитесь, что программа Тирика-Магазин у вас закрыта.

Внимание!
Вы должны понимать, что восстанавливая базу данных из резервной копии, вы удаляете текущую базу данных программы. Так, например, если сегодня 20 февраля 2012 года и файл резервной копии называется 2012-02-20.zip, то он скорее всего был создан утром 20 февраля при первом старте программы и хранит базу данных с данными по вечер 19 февраля включительно. Восстановив из резервной копии эту базу данных, вы потеряете все данные, созданные за 20 февраля. Таким образом, восстанавливать базу данных из резервной копии имеет смысл только в том случае, если ваша рабочая база данных, например, испорчена.

Читайте так же:
Видео показывает зеленым цветом

Для того, чтобы восстановить данные из резервной копии программы, вам достаточно найти нужную резервную копию по дате (скорее всего это будет последняя по дате резервная копия. Если таких у вас две — с закодированном в имени файла временем и без него — выбирайте ту, что со временем, она скорее всего новее), «зайти» в нее двойным щелчком мыши в Проводнике Windows. Собственно файл резервной копии — это ZIP-архив, поэтому после двойного мыши по этому архиву вы либо «зайдете» в него как в папку Windows, либо же у вас запустится дополнительная программа типа WinZip, WinRar или 7-Zip, в которой вы сможете «зайти» в этот архив как в папку.


Вот так может выглядеть, например, окошко winrar после двойного щелчка мыши в проводнике по файлу резервной копии

Пройдите опять по дереву папок внутри архива с резервной копией (Program FilesTirika Shop) и найдите в самой последней по очереди папке единственный хранящийся в архиве файл — файл shop.db. Это и есть резервная копия базы данных программы. Разархивируйте ее в ту папку, куда установлена программа Тирика-Магазин, заменяя файлом резервной копии актуальную базу данных программы, и на этом восстановление базы данных из резервной копии закончено. Вы можете теперь запустить программу Тирика-Магазин.

Сетевая версия

Для того, чтобы правильно понимать эту главу, вам необходимо ознакомиться со статей, описывающей настройки программы для работы в сети, так как здесь мы часто ссылаемся на понятия, определенные в ней, например, «компьютер Альфа» или «сервер баз данных FireBird». Если вы не читали статью о сетевых настройках программы, пожалуйста, прочтите ее сейчас.

Если вы используете сетевую версию программы Тирика-Магазин, вернее, если программа Тирика-Магазин работает у вас в сетевом режиме, резервные копии базы данных хранятся на компьютере «Альфа». Переключитесь на компьютер Альфа и перейдите на диск C: этого компьютера. В корневой папке диска C: вы увидите несколько файлов с именем типа shop-2012-02-22.fbk — это и есть резервные копии базы данных. Эти файлы имеют вид shop-гггг-мм-дд.fbk, где гггг, мм и дд — год, месяц и день создания резервной копии соответственно. Некоторые резервные копии могут также иметь вид shop-гггг-мм-дд-чч-мм-сс.fbk, где чч, мм и сс — часы, минуты и секунды времени создания резервной копии. Резервные копии «с секундами» — это «внеплановые» резервные копии, описанные в предыдущей главе этой статьи.

Перед восстановлением данных из резервной копии убедитесь, что программа Тирика-Магазин закрыта (не запущена) на всех тех компьютерах, где она установлена. Если хотя бы один пользователь будет работать с базой данных FireBird в момент восстановления данных из резервной копии, восстановить данные не удастся.

Внимание!
Вы должны понимать, что восстанавливая базу данных из резервной копии, вы удаляете текущую базу данных программы. Так, например, если сегодня 20 февраля 2012 года и файл резервной копии называется 2012-02-20.zip, то он скорее всего был создан утром 20 февраля при первом старте программы и хранит базу данных с данными по вечер 19 февраля включительно. Восстановив из резервной копии эту базу данных, вы потеряете все данные, созданные за 20 февраля. Таким образом, восстанавливать базу данных из резервной копии имеет смысл только в том случае, если ваша рабочая база данных, например, испорчена.

Процесс восстановления базы данных из резервной копии сетевой версии программы Тирика-Магазин сильно отличается от аналогичного процесса в случае использования локальной версии. Выберите резервную копию, из которой вы хотите восстановить данные, и запомните ее имя файла, после чего нажмите кнопку Пуск|Все Программы|Стандартные|Командная Строка и в открывшемся окне введите последовательно перечисленные ниже команды, после каждой нажимая кнопку Enter на клавиатуре. В списке команд ниже даны комментарии к каждой команде, их, разумеется, на клавиатуре набирать не надо; в предпоследней команде имя файла shop-2012-02-24.fbk нужно заменить на имя файла той резервной копии базы данных, которую вы выбрали для восстановления :

  • C:<Enter> (переходим на диск C)
  • cd <Enter> (переходим в корневую папку диска)
  • cd «Program Files»<Enter> (переходим в папку C:Program Files)
  • cd Firebird25<Enter> (переходим в папку C:Program FilesFireBird25)
  • cd bin<Enter> (переходим в папку C:Program FilesFireBird25bin)
  • gbak -user sysdba -password masterkey -replace_database -service localhost:service_mgr C:shop-2012-02-24.fbk tirika<Enter> (запускаем утилиту gbak восстановления данных из резервной копии)
  • Внимательно прочитайте, что вам напишет утилита gbak. Она может сказать, что восстановление из резервной копии не удалось, или что восстановление, наоборот, прошло успешно
  • exit<Enter> (закрываем окно командной строки)
Читайте так же:
В приложении system update произошла ошибка

Список команд выше дан для случая, когда вы устанавливали сервер баз данных FireBird 2.5 из скачанного с нашего сайта дистрибутива программы и не меняли его настроек; показателем этого служит то, что в окне Файл|Настройки|Сеть программы Тирика-Магазин выпадающий список установлен у вас в положение Одновременно может работать несколько человек:

Если же эта настройка программы у Вас установлена в позицию Для IT-специалистов и приведенная выше последовательность команд не восстанавливает данные из резервной копии, для операции восстановления данных вам необходимо обратиться к тому специалисту, который настраивал вам программу для работы в сети.

Создание резервной копии вручную

Создание резервной копии программы вручную и восстановление данных из такой резервной копии — существенно более простой процесс по сравнению с работой с автоматически создаваемыми программой резервными копиями. Мы рекомендуем вам время от времени делать вручную резервные копии базы данных программы и сохранять их на внешних носителях: на флешке, на другом компьютере и тюпю с тем, чтобы застраховаться от потери данных при серьезной поломке компьютера, на котором установлена база данных программы Тирика-Магазин или его жесткого диска.

Собственно процесс изготовления резервной копии предельно прост: вам нужно просто скопировать файл базы данных программы на другой носитель. О том, где находится файл базы данных программы и как его найти, написано в этой статье

Код Икс Пи :: Лучшие IT-решения для бизнеса

Иногда бывает необходимо узнать, кто именно сейчас работает в базе данных или в базах данных на сервере MSSQL 2008/2012. Например, для того чтобы принудительно завершить все эти сеансы или просто узнать, кто именно нагружает сервер запросами. Сегодня мы научимся с Вами это делать, используя при этом простые запросы к системным представлениям на Transact-SQL.

Как Вы уже поняли, сегодня речь пойдет об активных сеансах и процессах в СУБД MSSQL, которые мы будем получать, используя системное представление sys.sysprocesses.

Содержит сведения о процессах, которые выполняются в экземпляре SQL Server. Эти процессы могут быть клиентскими или системными. Для доступа к sysprocesses либо необходимо быть в контексте главной базы данных, либо следует использовать трехчастное имя master.dbo.sysprocesses.

Для того чтобы понимать, что такое системное представление, советую Вам для начала ознакомиться с понятием простого представления, которое рассматривается в статье — Зачем нужны представления (views) в базах данных. Также мы будем писать пусть простые, но все запросы, с основами которых Вы естественно должны быть знакомы, если нет, то можете прочитать статью основы языка SQL — оператор select.

Вроде бы все, что необходимо знать, перед тем как что-то пробовать из ниже приведенных примеров на практике я указал, переходим непосредственно к самой сути сегодняшнего вопроса.

Как узнать активные сеансы пользователей

Системное представление sys.sysprocesses содержит текущее состояние сервера на предмет запущенных процессов, исходя из этого, напишем простенький запрос:

db – это база данных, в которой запущен процесс;
idproc – идентификатор процесса;
loginame – логин, т.е. кто именно запустил;
program_name – приложение, из которого запущен процесс;
status – соответственно статус.
Статусы бывают разные, например,

Runnable – активный процесс, т.е. например, в данный момент выполняется какой-нибудь запрос;
Sleeping – режим ожидания, т.е. например, окно запроса открыто, но в данный момент он не запущен;
Background – запущен в фоновом режиме.
Если необходимо узнать, кто именно работает конкретно в той или иной базе можно добавить условие:

Соответственно вместо name_db пишите свою нужную базу данных, и результат будет получен только по этой базе данных.

Как завершить все активные сеансы пользователей

Это необходимо, например, для того чтобы получить монопольный доступ к базе данных, а для чего он Вам может понадобится это уже Ваше дело, например, чтобы восстановить базу данных. Мы кстати рассматривали процесс восстановления базы данных, правда, на MSSql 2000.

Для того чтобы завершить все подключения пользователей к бд, выполним следующий запрос:

@dbname – переменная, для того чтобы указать к какой базе необходимо завершить все подключения;
@query – переменная для хранения запроса;
В конструкции select мы динамически формируем запрос с идентификаторами процессов, которые необходимо завершить. Далее в переменной @query будет храниться запросы вида

Читайте так же:
В приложении htc sense input произошла ошибка

которые мы выполним через exec(@query) и тем самым завершим все процессы.

Из всего выше сказанного Вы легко можете узнавать, кто именно сейчас выполняет запрос и даже завершить его, что в свою очередь иногда бывает полезно.

Также хотелось бы сказать, что в MSSQL существует встроенный «Монитор активности». Его можно вызвать, нажав правой кнопкой по серверу, в окне «обозреватель объектов» и вызвать окно «Монитор активности», на котором будет располагаться список свойств, которые Вы можете развернуть для подробного просмотра, где в свою очередь и будет отображать вся текущая активность на сервере.

Описание всех полей sysprocesses
Имя столбцаТип данныхОписание
spidsmallintИдентификатор сеанса SQL Server.
kpidsmallintИдентификатор потока Windows.
blockedsmallintИдентификатор сеанса, блокирующего данный запрос. Если этот столбец содержит значение NULL, то запрос не блокирован или сведения о сеансе блокировки недоступны (или не могут быть идентифицированы).

-2 = Блокирующий ресурс принадлежит потерянной распределенной транзакции.

-3 = Блокирующий ресурс принадлежит отложенной транзакции восстановления.

Неактивные = SQL Server сбрасывает сеанс.

под управлением = сеанс запущен один или несколько пакетов. Если включен режим MARS, в сеансе может выполняться несколько пакетов.

фон = сеанса запущена фоновая задача, например обнаружение взаимоблокировок.

откат = сеанс имеет отката транзакции в процессе.

Ожидание = сеанс ожидает доступности рабочего потока.

готов к запуску = задача в сеансе находится в очереди исполнителей планировщика, ожидая времени такта.

spinloop = задача сеанса ожидает освобождения объекта взаимоблокировки.

Типичные ошибки настройки планов обслуживания СУБД MS SQL Server для 1С

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

Итак, с чего начинается настройка плана обслуживания? Конечно же с бэкапа! Первое правило DBA гласит: "Ничего не начинай делать без бэкапа". Ну и мы не будем. Давайте рассмотрим два основных варианта создания бэкапов, а точнее две модели резервного копирования, или модели восстановления ( https://msdn.microsoft.com/ru-ru/library/ms189275(v=sql.120).aspx )

Восстановление по модели simple

Восстановление данных

Ваша база данных находится в SIMPLE режиме восстановления. Что это означает? Это означает, что бэкапы бывают только полные, журналы транзакций бэкапировать не нужно, производительность в этом смысле максимальная, но восстановиться можно только на точку бэкапа. Восстановление базы “на указанный момент времени” невозможно.
Следовательно, еженочно (или чаще, в зависимости от потребности) мы должны снимать свеженькую копию нашей базы данных и складывать ее в надежное место, и обязательно не в то, в котором лежит наша основная база данных
В целом, использование модели SIMPLE для реальных рабочих баз оправданно только в случаях исключительно высокой нагрузки и незначительности события потери данных с момента последнего бэкапа.

Кроме того, затрону сразу вопрос работы с журналом транзакций. Так как нам журнал тразакций в этом режиме восстановления не очень-то и помощник, нет необходимости в его резервном копировании — вся информация из журнала уже ушла в бэкап. Обычно журналы в такой модели восстановления почти не растут, но иногда полезно его усекать. Например, после массового изменения данных эта операция может быть крайне полезна с точки зрения места, занимаемого журналом транзакций. Если диск с журналом переполнится — проблемы функционирования базы данных вам обеспечены.

Усечение данных может быть проведено, как стандартным мастером настройки плана обслуживания, так и с помощью несложно скрипта на T-SQL:

DBCC SHRINKFILE (DatabaseName, 1);
GO

Этот скрипт уменьшит размер лог-файла базы данных до начального размера (по умолчанию, чаще всего это будет 1 Мб). Однако, не стоит выполнять эту операцию постоянно. В идеале, ваши файлы не должны изменяться в размере в ходе планомерной работы, но об этом мы поговорим как-нибудь в другой раз.

Восстановление по модели full

Давайте рассмотрим основные принципы настройки резервного копирования и управления размером журнала лога транзакций с точки зрения самого массового варианта — полной модели восстановления БД.

Восстановление данных

Полная модель восстановления отличается от простой тем, что в течение всей работы базы данных мы можем (а еще точнее — ДОЛЖНЫ!) делать бэкапы лога транзакций, тем самым обеспечивая возможность восстановления БД между точками основных бэкапов или откаты на конкретные промежутки времени функционирования базы, а также обеспечивая освобождение места в файле журнала (усечение). Если этого не делать, он будет расти постоянно до тех пор, пока однажды не заполнит все доступное ему место (либо на диске, либо до ограничения, заданного в СУБД). Последствия кажутся очевидными, и не самыми приятными.

С точки зрения наличия полных бэкапов — безусловно, минимальная граница — это как правило те же одни сутки. Разностные бэкапы базы данных — это возможность сохранить только изменения, произошедшие с момента последнего бэкапа. Это позволяет достаточно быстро и оперативно проводить резервное копирование базы данных, при этом использовать достаточно быстрое восстановление БД до нужного состояния.
Резервные копии журнала транзакций могут выполняться с нужной вам периодичностью в течение дня, подробнее чем разностное копирование БД. Мы рекомендуем, обычно, выбирать степень подробности копий около ¼ от времени создания разностных копий БД.

Как уже было сказано выше, при выполнении резервной копии журнала транзакций базы данных в полной модели он усечется автоматически (только не путайте усечение со сжатием!).

Пересчет статистики и работа с индексами

Достаточно ошибочной является сложившаяся практика работы с индексами и статистикой у наших клиентов. Очень часто мы сталкиваемся вообще с полным отсутствием этих процедур в планах обслуживания баз данных. Часто они выполняются в неправильном порядке. Часто просто неоптимально (например, одновременно!).

Правильная последовательность действий выглядит так:

Определяем степень фрагментированности индекса

Если индекс маленький или мало фрагментирован, запускаем процедуру реорганизации индекса и пересчета статистики.

В противном случае запускам процедуру перестроения индекса. Процедура перестроения индекса фактически приведет к обновлению статистики, поэтому пересчитывать статистику после полного перестроения индекса не нужно.

Если рассмотреть мини-скрипт для пересчета статистики и перестроения индексов (не претендуем на супер полноту и универсальность), то выглядеть он будет примерно так (с перебором индексов через курсор):

DECLARE @SQL NVARCHAR(MAX)

DECLARE @MIN_IND_SIZE integer = 128

DECLARE @MIN_FRAGMENTATION_LEVEL integer = 10

DECLARE @CRITICAL_FRAGMENTATION_LEVEL integer = 30

DECLARE currentIndex CURSOR LOCAL READ_ONLY FORWARD_ONLY FOR

SELECT ‘ALTER INDEX [‘ + ind.name + N’] ON [‘ +

CASE WHEN stat.avg_fragmentation_in_percent > @CRITICAL_FRAGMENTATION_LEVEL

THEN ‘REBUILD WITH (SORT_IN_TEMPDB = ON, ONLINE = ON)’

SELECT stat.[object_id], stat.index_id,

FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, ‘DETAILED’) stat

WHERE stat.page_count > @MIN_IND_SIZE AND stat.index_id > 0

AND stat.avg_fragmentation_in_percent > @MIN_FRAGMENTATION_LEVEL

GROUP BY stat.[object_id], stat.index_id

JOIN sys.indexes ind WITH(NOLOCK) ON stat.[object_id] = ind.[object_id]

AND stat.index_id = ind.index_id

JOIN sys.objects obj WITH(NOLOCK) ON obj.[object_id] = stat.[object_id]

FETCH NEXT FROM currentIndex INTO @SQL

WHILE @@FETCH_STATUS = 0 BEGIN

EXEC sys.sp_executesql @SQL

FETCH NEXT FROM cur INTO @SQL

Уведомления

Кроме всех технических аспектов, очень правильно настраивать такие планы обслуживания, которые при некорректном выполнении все-таки уведомят вас о произошедшей беде. И это будет самый короткий абзац в моей статье. 🙂

Если вам все показалось слишком сложным, или вы не уверены в том, что можете сделать подобные настройки самостоятельно — не стесняйтесь, обращайтесь к нам — мы поможем!

База данных в процессе восстановления

При необходимости восстановите компьютер Windows.

После завершения восстановления системы Windows либо после запуска нового экземпляра сервера можно начать восстановление баз данных SQL.

Для восстановления баз данных SQL должен быть запущен; однако запуск SQL невозможен без наличия главной и модельной баз данных.

Восстановить главную и модельную базы данных и запустить SQL можно одним из следующих способов:

Переименуйте файлы, созданные программой Backup Exec для замены главной и модельной баз данных. После появления главной и модельной баз данных в SQL следует запустить SQL, восстановить главную базу данных с помощью опции «Автоматическое восстановление главной базы данных», а затем восстановить остальные базы данных.

Запустите утилиту Rebuild Master ( Program FilesMicrosoft SQL Server80ToolsBinnrebuildm.exe для SQL 2000 или MSSQL7binnrebuildm.exe для SQL 7.0) для повторного создания главной базы данных.

Утилита Rebuild Master не поддерживается в SQL 2005. Параметры настройки описаны в документации MS SQL 2005.

Заново установите SQL.

В этом разделе описана только процедура перезапуска SQL при использовании копий главной и модельной баз данных, созданных программой Backup Exec. Дополнительная информация о работе с утилитой Rebuild Master и повторной установке SQL приведена в документации по MS SQL.

В случае восстановления нового экземпляра SQL запустите операцию восстановления главной базы данных.

Как перезапустить SQL 2000, 2005 или SQL 2008 с использованием копий баз данных

Убедитесь, что имеются копии баз данных.

Копии базы данных называются master$4idr, mastlog$4idr, model$4idr и modellog$4idr и находятся в следующих каталогах:

Экземпляр SQL 2000 по умолчанию

C:Program FilesMicrosoft SQL ServerMSSQLData*.*

Именованный экземпляр SQL 2000

C:Program FilesMicrosoft SQL ServerMSSQL$Instance_NameData*.*

Первый экземпляр SQL 2005/2008

C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLData*.*

Второй экземпляр SQL 2005/2008

C:Program FilesMicrosoft SQL ServerMSSQL.2MSSQLData*.*

При необходимости восстановите копии главной и модельной баз данных из наборов данных резервного копирования в исходный каталог этих баз данных.

С помощью Проводника Windows откройте каталог данных по умолчанию и удалите следующие файлы:

Переименуйте копии баз данных, восстановив исходные имена. Эти имена указаны ниже:

Имя копии базы данных

Исходное имя базы данных

modellog$4idr

modellog.ldf

Не используйте файлы, доступные только для чтения. Это приведет к сбою при запуске служб SQL.

С помощью SQL Service Control Manager запустите сервер SQL Server.

Для восстановления последних изменений в главной базе данных выполните следующие действия:

Как перезапустить SQL 7.0 с использованием копий баз данных

Убедитесь, что имеются копии баз данных.

Копиям баз данных присваиваются имена master$4idr, mastlog$4idr, model$4idr и modellog$4idr.

В установке SQL 7.0 по умолчанию базы данных находятся в каталоге C:MSSQL7Data.

При необходимости восстановите копии главной и модельной баз данных из наборов данных резервного копирования в исходный каталог этих баз данных.

С помощью Проводника Windows откройте каталог данных по умолчанию и удалите следующие файлы:

Переименуйте копии баз данных, восстановив исходные имена. Эти имена указаны ниже:

Имя копии базы данных

Исходное имя базы данных

modellog$4idr

modellog.ldf

Не используйте файлы, доступные только для чтения. Это приведет к сбою при запуске служб SQL.

С помощью SQL Server Service Manager запустите SQL.

Для восстановления последних изменений в главной базе данных выполните следующие действия:

Как восстановить главную базу данных

На панели навигации щелкните на стрелке рядом со значком Восстановление.

Выберите Создать задание восстановления .

На панели свойств найдите раздел «Источник» и нажмите Выбранные ресурсы .

В списке выбранных ресурсов для восстановления выберите набор данных резервного копирования, содержащий последнюю резервную копию главной базы данных.

На панели «Свойства» в разделе «Параметры» выберите Microsoft SQL .

В окне Свойства задания восстановления для SQL выберите Автоматическое восстановление главной базы данных .

Все текущие сеансы других пользователей завершаются, и сервер SQL переводится в однопользовательский режим.

При выборе этой опции можно восстановить только главную базу данных; если эта опция выбрана для какой-либо другой базы данных, произойдет сбой задания.

Если у программы Backup Exec нет доступа к записям реестра SQL HKEY_LOCAL_MACHINESoftwareMicrosoftMicrosoft SQL Server и HKEY_LOCAL_MACHINESoftwareMicrosoftMSSQLServer , может оказаться невозможным восстановление в каталог по умолчанию и будет недоступна опция «Автоматическое восстановление главной базы данных» в окне свойств задания восстановления для SQL. Для того чтобы убедиться в наличии прав доступа у программы Backup Exec, проверьте, используются ли в учетной записи права доступа администратора к системе, в которой запущен экземпляр SQL.

Выберите способ проверки целостности, выполняемой после восстановления.

Запустите задание восстановления.

После восстановления SQL перезапускается в многопользовательском режиме.

Выполните следующие действия для восстановления остальных баз данных SQL.

Как восстановить остальные базы данных SQL

На панели навигации щелкните на стрелке рядом со значком «Восстановление».

Выберите Создать задание восстановления .

На панели свойств найдите раздел «Источник» и нажмите Выбранные ресурсы .

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

При этом не выбирайте главную базу данных для восстановления.

В случае восстановления баз данных SQL из резервной копии группы файлов следует помнить о следующих условиях:

На панели «Свойства» в разделе «Параметры» выберите Microsoft SQL .

Выберите параметр Оставить базу данных в рабочем состоянии ; не восстанавливать другие журналы транзакций или дифференциальные резервные копии .

Выберите опцию Заменить существующую базу данных .

В поле «Проверка целостности после восстановления базы данных» выберите опцию Полная проверка, включая индексы .

Запустите задание восстановления или выберите другие опции на панели «Свойства».

После успешного завершения всех операций восстановления восстановление баз данных SQL завершено.

После завершения восстановления настоятельно рекомендуется выполнить полное резервное копирование баз данных при первой возможности.

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector