Существует несколько способов копирования таблицы в базе данных MS SQL Server. Предлагаю несколько вариантов создания копии таблиц. Какой из них выбрать – зависит от структуры таблицы, наличия в ней индексов, триггеров и т.п., а также желания делать что-то руками.
1. Ручной метод копирования структуры таблицы
В Micrisoft SQL Management Studio выбрать базу, выбрать таблицу, нажать правой кнопкой мыши и выбрать пункты "Script Table as" -> "CREATE TO" -> "New Query Editor Window". В окне запроса откроется код для создания таблицы. В нем нужно указать имя базы, в которой нужно сделать копию таблицы, и новое имя, если база не меняется. Как создать код для создания структуры имеющейся таблицы, показано на рисунке ниже.
С помощью этого способа будут созданы индексы таблицы, но не скопируются триггеры. Их нужно копировать аналогичным способом.
Для копирования данных в уже созданную таблицу нужно использовать такой SQL запрос:
INSERT into ..tmp_tbl_Deps SELECT * FROM ..tbl_Deps
2. Копирование SQL таблицы запросом в одну строчку
Сделать копию структуры таблицу и данных внутри одной базы:
SELECT * into tmp_tbl_Dep FROM tbl_Deps
Скопировать структуры таблицу и ее данные из одной базы в другую:
SELECT * into ..tmp_tbl_Deps FROM ..tbl_Deps
Минус у такого решения – не копируются индексы.
В данной статье будет рассказано как вручную сделать полную резервную копию базы данных в с помощью программы «Среда 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).
Помогла ли Вам данная статья?
Данная статья посвящена решениям для восстановления MS SQL. Постараемся рассмотреть основные моменты и важные детали, которые необходимо учесть, при планировании и выборе решения для восстановления базы данных MS SQL.
В рамках планирования аварийного восстановления MS SQL особый интерес представляют два параметра: допустимое время восстановления (recovery time objective - RTO) и допустимая точка восстановления (recovery point objective - RPO).
RPO иными словами, это период времени с момента последнего резервного копирования до момента инцидента, за который будет потерян не критичный объём данных (информации). RTO - это допустимое время, за которое необходимо восстановить работоспособность сервиса/системы с момента инцидента. Оба параметра имеют переменное значение и зависят от требований к той или иной системе. Поэтому для выполнения, установленных RPO и RTO необходимо иметь соответствующий план резервного копирования. На примере, проведём анализ возможных аварийных инцидентов и попробуем выделить точки отказа нашего SQL сервера и способы их решения:
- аппаратный сбой, физический выход сервера из строя: диски, CPU, системная плата, блок питания и т.д.
- программный сбой: операционная система, база данных
Для каждого обозначенного инцидента есть целый комплекс мер, позволяющий избежать последствия инцидента.
HIGH AVAILABILITY MS SQL
При высоких требованиях к RPO и RTO (секунды/минуты) единственным решением для обеспечения отказоустойчивости MS SQL является организация технологии высокой доступности сервера (High Availability):
- Встроенными средствами MS SQL и ОС Windows Server мы можем достичь высокой доступности (High Availability) за счет реализации отказоустойчивого кластера Windows Server Failover Cluster (WSFC) в том числе и с применением технологии AlwaysOn. Отказоустойчивый кластер состоит как минимум из двух узлов/серверов. При сбое активного сервера, происходит аварийное переключение на другой доступный сервер, он становится активным. При этом все службы, которые размещались на сервере автоматически или вручную переносятся на другой доступный узел.
- В случаи, с виртуальной машиной MS SQL высокую доступность можно обеспечить c помощь средств виртуализации VMware HA-cluster или Hyper-V High Availability. В этом случае при выходе из строя физического сервера, позволяет автоматически запустить виртуальную машину на другом сервере кластера.
Оба способа могут быть реализованы как по отдельности, так и совместно, если в этом есть необходимость. Кластеризация в большей степени рассчитана для оперативного устранения аппаратного сбоя.
Преимущества High Availability MS SQL:
- мгновенное переключение с ноды на ноду, без простоя
- без зависимости от физических серверов
- позволяет проводить обслуживание серверов без перерыва в работе с базой данных
Недостатки High Availability MS SQL:
- реализации требует дополнительной инфраструктуры и ресурсов
- высокая стоимость решения по лицензиям и оборудованию
- более сложное и высоквалифицированное обслуживание
BACKUP MS SQL
В случаях, когда требования к RTO и RPO не высокие и потребность в High Availability (кластеризации) отсутствует, для обеспечения отказоустойчивости баз данных MS SQL на физическом или виртуальном сервере необходимым условием является наличие резервной копии. Для этого можно задействовать встроенные функции SQL Server или использовать отдельные специализированные системы, поддерживающие различные способы резервного копирования MS SQL, например:
Данные системы помогут избежать как аппаратных, так и программных сбоев в работе сервера базы данных.
После расчета значений RTO и RPO можно перейти к планированию конфигурации SQL сервера. Для достижения этих значений мы можем использовать как технологии высокой доступности, перечисленные выше, так и backup баз данных.
Регламент backup MS SQL
- Резервные копии должны находиться на разных физических носителях с исходными файлами базы данных
- Используйте тестовый сервер (песочница) для проверки процедуры восстановления резервных копий
- Выполняйте ежедневное
- Делайте как можно чаще. Они занимают гораздо меньший объем в хранилище и еще больше сокращают риск потери данных
- Как можно чаще выполняйте резервное копирование журналов транзакций. Журналы транзакций содержат все последние действия, произошедшие в базе данных. Журналы можно использовать для восстановления базы данных на определенный момент времени, и это является самым большим преимуществом. Резервные копии журнала транзакций могут выполняться во время работы системы. Если частота новых данных, создаваемых в вашей базе данных, очень высока, то можно делать резервные копии журнала транзакций каждые 10 минут, в то время как для других баз данных, которые менее активны, такое резервное копирование может выполняться каждые 30 или 60 минут
- Делайте резервное копирование системных баз данных MS SQL: server, master , model и msdb . Эти базы данных абсолютно необходимы, так как содержат конфигурацию системы, а также информацию о задании SQL Server, которую необходимо будет восстановить в случае полного восстановления системы
НАСТРОЙКА РЕЗЕРВНОГО КОПИРОВАНИЯ MS SQL С ПОМОЩЬЮ BACKUP EXEC
Backup Exec предлагает три метода резервного копирования MS SQL: Full, Differential и Full Copy-only. Метод Full выполняет полное резервное копирование всей базы данных, а Differential выполняет резервное копирование только измененых блоков в базе данных с момента последнего полного резервного копирования. Метод Full Copy-only идентичен полному резервному копированию, но только он не влияет на последующие задания дифференциального резервного копирования.
Рассмотрим каждый случай более подробно для этого создадим в системе новое задание для резервного копирования основной и системных баз данных.
Затем, в настройках параметров (опции) выбрать тип задания (сначала настроить Full потом Differential backup).
В Backup Exec есть очень важная и полезная функция «Проверка целостности базы до и после выполнения резервного копирования» (Consistency check before/after backup), имеется на выбор четыре варианта:
- не проводить проверку
- полная проверка, без учёта индексов
- полная проверка с учётом индексов
- только физическая проверка
Для настройки differential backup необходимо (аналогично job full backup) сначала добавить новое задание Job Differential, а затем на вкладке Microsoft SQL выбрать один из методов резервного копирования.
В данном списке в первую очередь интересует «Differential - Backup up database changes since the last full» (создание дифференциальной резервной копии на основании полной). Так же возможен вариант создания дифференциальной резервной копии (на уровне блоков) с последующей конвертацией в виртуальную машину «Differential (block-level) - Backup up database changes since the last full – use with convert to virtual machine job» .
Еще одним важным параметром является «Log - Back up and truncate transaction log» для резервного копирования журнала транзакций MS SQL.
Мы рассмотрели основные моменты резервного копирования MS SQL. Обращаем внимание, что резервное копирование является частью общего плана аварийного восстановления (DRP), поэтому, перед планированием резервного копирования, необходимо провести полный анализ систем и инфраструктуры, для обеспечения RPO и RTO. А если есть возможность выполнить планирование DRP при разработке системы, это поможет исключить многие проблемы и, возможно, удешевит эксплуатацию системы.
Используемая в статье информация взята из официальных источников.
«Кто владеет информацией - тот владеет миром» - Майер Амшель Ротшильд
Самое ценной сущностью в любом бизнесе является информация. Потеря информации может привести к непредсказуемым последствиям, в основном финансовым. Поэтому одной из главной задач IT специалистов является резервное копирование всей IT инфраструктуры. Это относится и базам данных MS SQL Server.
Для того, чтобы обеспечить сохранность информации в используемых базах данных, а также снизить время для восстановления работоспособности, необходимо производить периодическое резервное копирование SQL-серверов.
Разберем на простейшем примере: необходимо настроить резервное копирование базы данных на отдельный диск.
Решение:
- Открываем Microsoft SQL Server Management Studio . В навигационном меню справа открываем вкладку "Управление" . Там видим вкладку "Планы обслуживания" . Нажимаем правой кнопкой мыши -> "Создать план обслуживания" и даем имя нашему плану (Рис.1):
Рис.1 Создание нового плана обслуживания.
2. На панели элементов добавляем задачу "Резервное копирование базы данных" (Рис.2):
Рис.2 Добавление задачи "Резервное копирование базы данных".
3. На созданной задаче нажимаем правой кнопкой мыши -> "Изменить" (Рис.3):
4. В окне свойствах задачи выбираем тип резервной копии (в моем случае полный), выбираем нужную базу данных (у меня ka_cons), каталог для бэкапов, возможность проверки резервных копий на целостность и варианты сжатия оных (Рис.4-6):
Рис.4 Тип бэкапа - полный.
Рис.5 Выбор базы данных для бэкапа.
Рис.6 Определение каталога для бэкапов, проверки целостности и степени сжатия.
5. На панели настройки плана обслуживания справа. нажимаем на кнопку "Расписание" (Рис.7):
6. Настраиваем нужное нам расписание и нажимаем "Ок" (Рис.8):
Рис.8 Настройка расписания резервного копирования.
7. Сохраняем наш план обслуживания (Рис.9):
Рис.9 Сохранение плана обслуживания.
Полное резервное копирование базы данных по расписанию настроено.
Восстановим базу «Test _Recovery » в состояние «t 4 ».
Приступим к восстановление базы данных из полной резервной копии «Full2_Test_Recovery.bak» используя « SQL Server Management Studio ». Щелкаем правой кнопкой мыши по базе « Test _ Recovery », в появившемся меню выбираем « Tasks », далее « Restore », потом « Database ».
В появившемся окне « Restore Database » в разделе « Sourse » выбираем « Device ». Далее « Add », прописываем путь «\\ vniz - tst - bkp 01. test . local \ Backup _ SQL \ Full 2_ Test _ Recovery . bak », нажимаем « Ok ». В разделе «Destination» выбираем Database «Test Recovery»
Нажимаем «Ok»
База успешно восстановится.
Рассмотрим восстановление базы данных используя Transact-SQL.
Щелкаем правой кнопкой мыши по базе «Test_Recovery», в появившемся меню выбираем «New Query»:
В появившемся окне вводим:
USE master
RESTORE DATABASE Test_Recovery
FROM DISK = "\\vniz-tst-bkp01.test.local\Backup_SQL\Full2_Test_Recovery.bak"
WITH REPLACE
База успешно восстановится.
В этом примере мы использовали параметр «REPLACE»:
Восстановление обычно не допускает случайной перезаписи базы данных другой базой данных. Если указанная в инструкции RESTORE база данных уже существует на текущем сервере, а идентификатор GUID семейства для заданной базы данных отличается от идентификатора GUID семейства для базы данных, записанного в резервном наборе данных, то ее восстановление не будет выполнено.
Параметр REPLACE отменяет несколько важных проверок, обычно выполняемых операцией восстановления. Отменяются следующие проверки.
- Проверка на восстановление поверх существующей базы данных резервной копии, созданной для другой базы данных. При использовании параметра REPLACE при восстановлении можно записать данные поверх существующей базы данных независимо от того, какие базы данных содержатся в резервном наборе данных, даже если указанное имя данных отличается от записанного в резервном наборе. Это может привести к случайной перезаписи поверх базы данных другой базы данных.
- Проверка на восстановление базы данных, использующей модель полного восстановления или модель восстановления с неполным протоколированием, для которой не была создана резервная копия заключительного фрагмента журнала, и не был применен параметр STOPAT. При использовании параметра REPLACE возможна потеря зафиксированных данных, поскольку последние записанные в журнал данные еще не были скопированы в резервную копию.
- Перезапись существующих файлов.