Автоматизированное восстановление баз данных MS SQL из бэкапов. Восстановление базы данных sql из резервной копии
Восстановление копии одной базы Microsoft SQL Server в другую
Резервный набор данных содержит копию базы данных, отличной от существующей базы данных — знакомо сообщение? Восстановить Backup одной базы данных Microsoft SQL Server в другую «в лоб» приводит к сообщению об ошибке. Нередко встречаюсь с ситуациями, когда горе админы на этом и завершают свои попытки восстановления базы. Ниже приведу пример восстановления из копии одной базы в другую.
Диагноз: Резервный набор данных содержит копию базы данных, отличной от существующей базы данных
Была сделана копия заданием или T-SQL из базы в файл.
Попытка восстановления на другом сервере или на этом же, но в другую базу приводит к сообщению об ошибке:
Сообщение 3154, уровень 16, состояние 4, строка 1 Резервный набор данных содержит копию базы данных, отличной от существующей базы данных "trade". Сообщение 3013, уровень 16, состояние 1, строка 1 RESTORE DATABASE прервано с ошибкой.Суть проблемы
Создавая Backup базы данных SQL Server сохраняет данные и о файлах и путях к ним, а также еще вагон служебной инфы.
При попытке восстановления в другую БД, естественно указанные ресурсы не обнаруживаются, и пользователь получает чудное сообщение, что база нужна другая.
Способ решения
При восстановлении нужно явно указать какие файлы данных куда сохранять.
В процессе восстановления, фактически создаются файлы со структурой соответствующей копии, но с другими именами и путями.
Все это подробно описано в доке для разработчиков Microsoft, но в многобукофф не многие хотят разбираться. 😉
Процесс
Разберем процесс создания копии и восстановления от начала до конца. В примере будет приведен способ с T-SQL. Как аналогичное сделать с использованием пользовательского интерфейса в части восстановления – понятия не имею.
Процесс рассматриваем на примере Microsoft SQLS erver 2012, но другие версии особо от него не отличаются.
Исходную базу данных будем рассматривать trade.
База данных, в которую будем грузить будет называться tradenew.
Сам Microsoft SQL Server установлен со значениями путей по-умолчанию.
Создание резервной копии базы данных Microsoft SQL Server
Создаем запрос для формирования файла резервной копии базы данных trade.
BACKUP DATABASE [trade] TO DISK = N'c:\Backup\Trade\trade.bak' WITH NOFORMAT, INIT, NAME = N'trade-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GOТаким образом файл копии базы данных будет расположен в папке
N'c:\Backup\Trade\trade.bakПолучение списка файлов в файле копии
Имена файлов нам нужны для того, чтоб точно указать куда они будут сохранены при восстановлении.
Создаем и запускаем запрос:
RESTORE FILELISTONLY FROM DISK = N'c:\Backup\Trade\trade.bak' GOПолучаем список:
Восстановление базы данных
Предварительно создавать новую базу ненужно, т.е. в списке у вас ее не должно быть!
Создаем и запускаем запрос:
RESTORE DATABASE [tradenew] FROM DISK = N'c:\Backup\Trade\trade.bak' WITH RECOVERY, FILE=1, MOVE 'trade' TO 'C:\Program Files\Microsoft SQL Server\MSSQL \MSSQL\DATA\tradenew.mdf', MOVE 'trade_log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL \MSSQL\DATA\tradenew_log.ldf' GOПо завершении наслаждаемся готовым результатом.
Ссылки на страницы документации по теме
Похожие записи
www.msav.ru
Восстановление данных в отдельной таблице SQL Server из резервной копии
Часто администраторы баз данных в процессе администрирования СУБД сталкиваются с необходимостью восстановления испорченных данных. И очень часто восстановление данных из резервной копии не является оптимальным решением, так как обычно требуется восстановить не всю базу данных, а данные только в одной или двух таблицах базы данных. В данной статье я расскажу о двух наиболее популярных способах восстановления данных в MS SQL Server и о том, как быстро и легко восстановить данные в отдельной таблице SQL Server из резервной копии. Подробнее читайте далее.
Способы восстановления данных в SQL Server
1. Восстановление данных из резервной копии в SQL Server
Одним из самых важных правил для любого системного администратора является необходимость регулярного резервного копирования данных программ. В MS SQL Server для резервного копирования есть штатная команда Задачи / Создать резервную копию. Остается только выбрать расположение, куда MS SQL Server создаст резевную копию, а дальше программа все сделает сама.
Для восстановления сохраненных данных также существует штатная команда Задачи / Восстановить / База данных. Достаточно просто указать имя файла резервной копии, а остальную часть процесса восстановления данных программа возьмет на себя.
Однако у данного отличного, на первый взгляд, способа резервного копирования и восстановления данных есть свои плюсы и минусы.
Во-первых, в случае большого объема базы данных резервное копирование может занять час и более, а размер резервной копии может быть не маленьким. Именно поэтому такие копии делают не чаще одного или двух раз в день.
Во-вторых, данные возможно восстановить только целиком, то есть можно восстановить полностью одну базу данных, но не отдельную таблицу в базе данных.
2. Восстановление данных в отдельной таблице базы данных в SQL Server
Способ № 1. Первый способ предполагает предварительное восстановление данных из имеющейся резервной копии в базу-клон исходной базы данных.
Для этого нужно создать новую базу данных (если имя исходной базы данных Base01, базу-клон можно назвать, например, Base02) и восстановить в нее данные из резервной копии. Далее уже можно написать скрипт для восстановления данных. Отличие скрипта от обычного написания будет в том, что при указании имени таблицы необходимо будет указать также и имя базы данных. Например,
Update Base01..Table01 set Base01..Table01.Date = Base02..Table01.Date from Base02..Table01 join Base01..Table01 on Base01..Table01.ID = Base02..Table01.ID where...
Способ №2. Допустим, что исходные неиспорченные данные есть на другом резервном (тестовом) сервере. Конечно, целесообразнее их взять оттуда, не прибегая к созданию базы-клона, в которую необходимо восстановить данные из резервной копии, так как это в случае большого объема базы данных (современные базы данных имеют размеры более терабайта) займет много времени. Сделать это можно опять-таки двумя способами.
Способ А. Для этого способа потребуется вновь создать базу-клон. Только вместо восстановления данных из резервной копии более быстрым решением будет использование операции экспорта с резервного сервера с неповрежденными данными.
Для экспорта в SQL Server существует команда Задачи / Экспортировать данные. При экспорте потребуется указать имя сервера и базы данных, из которых копируются данные, и имя сервера и базы данных, в которые копируются данные, а также указать перечень копируемых таблиц. Копирование отдельных таблиц займет меньше времени, чем восстановление базы данных из копии целиком.
А далее достаточно для восстановления данных в отдельной таблице достаточно выполнить все ту же команду:
Update Base01..Table01 set Base01..Table01.Date = Base02..Table01.Date from Base02..Table01 join Base01..Table01 on Base01..Table01.ID = Base02..Table01.ID where...
Способ Б. При применении этого способа не потребуется ни базы клона, ни восстановления из копии, ни экспорта данных отдельной таблицы. Восстановление данных будет идти напрямую из отдельной таблицы другого сервера.
Для этого способа потребуется предварительно создать линк между серверами.
Линк можно создать через интерфейс SQL Server (команда Создать / Связанный сервер в папке Объекты сервера) или с помощью скриптов ниже.
exec sp_addlinkedserver @server='Имя_сервера', @srvproduct='SQL Server'
exec sp_addlinkedsrvlogin 'Имя_сервера', 'false', null, 'sa', 'Пароль_для_sa'
После создания линка можно выбирать данные с другого сервера командой:
SELECT top 10 * FROM [Имя_сервера].Base01.dbo.Table01
Для восстановления данных используем уже знакомую, но немного видоизмененную команду:
Update Table01 set Table01.Date = A.Date from [Имя_сервера].Base01.dbo.Table01 A join Table01 on A.ID = Table01.ID where...
При использовании этого способа учитывайте, что к таблице командой вида [Имя_сервера].Base01.dbo.Table01 можно обратиться только один раз, а потом можно использовать только псевдоним в виде, например, букв A или B как в примере выше.
На этом все. Надеюсь статья была информативной и полезной для практического применения в администрировании баз данных на основе SQL Server.
multiblog67.ru
Как восстановить базу данных в SQL Server?
Вот как восстановить резервную копию как дополнительный db с уникальным именем db.
Для SQL 2005 это работает очень быстро. Я уверен, что более новые версии будут работать одинаково.
Во-первых, вам не нужно брать исходный db в автономном режиме. Но ради безопасности, я люблю. В моем примере я собираюсь установить клон моей базы данных биллинга и будет называться "billingclone".
1) Сделайте резервную копию базы данных фактурирования
2) Для безопасности я взял оригинал в автономном режиме следующим образом:
3) Откройте новое окно запроса
** ВАЖНО! Держите это окно запроса открытым, пока все не закончите! Вам нужно восстановить db из этого окна!
Теперь введите следующий код:
3) Далее, в Management Studio, rt нажмите "Базы данных в обозревателе объектов", выберите "Восстановить базу данных"
4) введите новое имя в поле "В базу данных". И.Е. billingclone
5) В "Источник восстановления" нажмите "От устройства" и нажмите кнопку "...".
6) Нажмите "Добавить" и перейдите к резервной копии
7) Поставьте галочку рядом с пунктом "Восстановить" (выберите резервные копии для восстановления)
8) затем выберите страницу OPTIONS в верхнем углу LH
9) Теперь отредактируйте имена файлов базы данных в RESTORE AS. Сделайте это как для db, так и для журнала. И.Е. billingclone.mdf и billingclone_log.ldf
10) теперь нажмите ОК и дождитесь завершения задачи.
11) Обновите обновление в своем обозревателе объектов, и вы увидите новый db
12) Теперь вы можете вернуть свой биллинг db в онлайн. Используйте одно и то же окно запросов, которое вы использовали для отключения биллинга. Используйте эту команду:
сделано!
qaru.site
Восстановление базы данных SQL Azure из резервной копии
- 10/23/2018
- Время чтения: 16 мин
- Соавторы
В этой статье
По умолчанию резервные копии базы данных SQL хранятся в геореплицированном хранилище BLOB-объектов (RA-GRS).By default, SQL Database backups are stored in geo-replicated blob storage (RA-GRS). При использовании функции автоматически создаваемых резервных копий для восстановления базы данных, становятся доступны следующие параметры.The following options are available for database recovery using automated database backups:
- Создание новой базы данных на том же логическом сервере, восстановленной до указанной точки во времени в пределах срока хранения.Create a new database on the same logical server recovered to a specified point in time within the retention period.
- Создание базы данных на том же логическом сервере, восстановленной до момента удаления, если исходная база данных была удалена.Create a database on the same logical server recovered to the deletion time for a deleted database.
- Создание базы данных на любом логическом сервере в том же регионе, восстановленной до точки во времени последней резервной копии.Create a new database on any logical server in the same region recovered to the point of the most recent backups.
- Создание базы данных на любом логическом сервере в любом другом регионе, восстановленной до точки во времени последней реплицированной резервной копии.Create a new database on any logical server in any other region recovered to the point of the most recent replicated backups.
После настройки резервного копирования для длительного хранение также можно использовать любую резервную копия LTR и любой логический сервер для создания новой базы данных в любом регионе.If you configured backup long-term retention you can also create a new database from any LTR backup on any logical server in any region.
Важно!
При восстановлении существующую базу данных невозможно перезаписать.You cannot overwrite an existing database during restore.
При использовании уровня службы Standard или Premium для восстановленной базы данных, взимается дополнительная оплата за хранилище при следующих условиях.When using Standard or Premium service tier, a restored database incurs an extra storage cost under the following conditions:
- Восстановление P11–P15 в S4–S12 или P1–P6, если максимальный размер базы данных превышает 500 ГБ.Restore of P11–P15 to S4-S12 or P1–P6 if the database max size is greater than 500 GB.
- Восстановление P1–P6 в S4–S12, если максимальный размер базы данных превышает 250 ГБ.Restore of P1–P6 to S4-S12 if the database max size is greater than 250 GB.
Дополнительная плата связана с тем, что максимальный размер восстановленной базы данных превышает объем хранилища для объема вычислительных ресурсов. За все дополнительные ресурсы хранилища, подготовленные сверх включенного объема, взимается дополнительная плата.The extra cost is because the max size of the restored database is greater than the amount of storage included for the compute size, and any extra storage provisioned above the included amount is charged extra. Сведения о ценах на дополнительное хранилище см. на странице цен на Базу данных SQL.For pricing details of extra storage, see the SQL Database pricing page. Если фактический объем пространства, которое используется, меньше, чем включенный объем хранилища, то этих дополнительных затрат можно избежать, уменьшив максимальный размер базы данных до включенного объема.If the actual amount of space used is less than the amount of storage included, then this extra cost can be avoided by reducing the database max size to the included amount.
Время восстановленияRecovery time
На время восстановления базы данных с использованием создаваемых автоматически резервных копий влияет несколько факторов:The recovery time to restore a database using automated database backups is impacted by several factors:
- размер базы данных;The size of the database
- объем вычислительных ресурсов базы данных;The compute size of the database
- число участвующих журналов транзакций;The number of transaction logs involved
- объем операций, которые требуется воспроизвести для восстановления до точки восстановления;The amount of activity that needs to be replayed to recover to the restore point
- пропускная способность сети, если выполняется восстановление в другой регион;The network bandwidth if the restore is to a different region
- количество одновременных запросов на восстановление, обрабатываемых в целевом регионе.The number of concurrent restore requests being processed in the target region
Восстановление очень большой и (или) активной базы данных может занять несколько часов.For a very large and/or active database, the restore may take several hours. В случае длительного простоя в регионе возможно появление большого количества запросов на геовосстановление, обрабатываемых другими регионами.If there is prolonged outage in a region, it is possible that there are large numbers of geo-restore requests being processed by other regions. Наличие большого числа запросов может увеличить время восстановления баз данных в соответствующем регионе.When there are many requests, the recovery time may increase for databases in that region. В большинстве случаев на восстановление базы данных требуется менее 12 часов.Most database restores complete in less than 12 hours.
Для одной подписки действуют определенные ограничения на количество одновременных запросов на восстановление (восстановление до точки во времени, геовосстановление и восстановление из резервной копии долгосрочного хранения), которые могут быть отправлены и обработаны.For a single subscription, there are some limitations on number of concurrent restore requests (including point in time restore, geo restore and restore from long-term retention backup) being submitted and proceeded:
| Отдельная база данных (на подписку)Single database (per subscription) | 1010 | 6060 |
| Эластичный пул (на пул)Elastic pool (per pool) | 4.4 | 200200 |
Возможность массового восстановления встроенными средствами не предусмотрена.There is no built-in functionality to do bulk restore. Сценарий База данных SQL Azure: полное восстановление сервера является примером одного из способов выполнения этой задачи.The Azure SQL Database: Full Server Recovery script is an example of one way of accomplishing this task.
Важно!
Чтобы использовать восстановление с помощью автоматически создаваемых резервных копий, нужно быть участником подписки с ролью "Участник SQL Server" или владельцем подписки (см. статью Встроенные роли в Azure).To recover using automated backups, you must be a member of the SQL Server Contributor role in the subscription or be the subscription owner - see RBAC: Built-in roles. Выполнить восстановление можно с помощью портала Azure, PowerShell или REST API.You can recover using the Azure portal, PowerShell, or the REST API. Использовать для этого Transact-SQL невозможно.You cannot use Transact-SQL.
Восстановление до точки во времениPoint-in-time restore
Вы можете восстановить отдельную базу данных, базу данных в составе пула или базу данных Управляемого экземпляра до предшествующей точки во времени как новую базу данных на том же сервере с помощью портала Azure, PowerShell или REST API.You can restore a single, pooled, or Managed Instance database to an earlier point in time as a new database on the same server using the Azure portal, PowerShell, or the REST API. Базу данных можно восстановить для любого уровня служб или объема вычислительных ресурсов.A database can be restored to any service tier or compute size. Убедитесь, что на сервере, в который выполняется восстановление базы данных, достаточно ресурсов.Ensure you have sufficient resources on the server to which you are restoring the database. После завершения восстановленная вы получите обычную полностью доступную базу данных в сети.Once complete, the restored database is a normal, fully accessible, online database. Использование восстановленной базы данных оплачивается по обычным тарифам на основе уровня служб и объема вычислительных ресурсов.The restored database is charged at normal rates based on its service tier and compute size. Плата не взимается до завершения восстановления базы данных.You do not incur charges until the database restore is complete.
Обычно база данных восстанавливается до более ранней точки во времени.You generally restore a database to an earlier point for recovery purposes. Таким образом восстановленную базу данных можно рассматривать как замену исходной базы данных или же использовать для извлечения данных, чтобы затем обновить исходную базу данных.When doing so, you can treat the restored database as a replacement for the original database or use it to retrieve data from and then update the original database.
Замена базы данныхDatabase replacement
Если восстановленная база данных предназначена для замены исходной базы данных, то следует проверить, настроен ли для нее соответствующий объем вычислительных ресурсов и (или) уровень служб, и при необходимости масштабировать эту базу данных.If the restored database is intended as a replacement for the original database, you should verify the compute size and/or service tier are appropriate and scale the database if necessary. Можно переименовать исходную базу данных, а затем присвоить восстановленной базе данных исходное имя с помощью команды ALTER DATABASE в T-SQL.You can rename the original database and then give the restored database the original name using the ALTER DATABASE command in T-SQL.
Восстановление данныхData recovery
Если вы планируете извлечь данные из восстановленной базы данных для восстановления после ошибки пользователя или приложения, то потребуется создать и выполнить сценарии восстановления данных, необходимые для извлечения данных из восстановленной базы данных в исходную.If you plan to retrieve data from the restored database to recover from a user or application error, you need to write and execute the necessary data recovery scripts to extract data from the restored database to the original database. Несмотря на то, что операция восстановления может занять много времени, восстанавливаемая база данных будет отображаться в списке баз данных на протяжении всего процесса.Although the restore operation may take a long time to complete, the restoring database is visible in the database list throughout the restore process. Если удалить эту базу данных во время восстановления, то операция будет отменена и плата за базу данных, восстановление которой не было завершено, взиматься не будет.If you delete the database during the restore, the restore operation is canceled and you are not charged for the database that did not complete the restore.
Чтобы восстановить отдельную базу данных, базу данных в составе пула или базу данных Управляемого экземпляра до точки во времени с помощью портала Azure, откройте страницу для базы данных и щелкните Восстановление на панели инструментов.To recover a single, pooled, or Managed Instance database to a point in time using the Azure portal, open the page for your database and click Restore on the toolbar.
Восстановление удаленной базы данныхDeleted database restore
Вы можете восстановить удаленную базу данных до момента удаления на том же логическом сервере с помощью портала Azure, PowerShell или REST (createMode=Restore).You can restore a deleted database to the deletion time for a deleted database on the same logical server using the Azure portal, PowerShell, or the REST (createMode=Restore). Удаленную базу данных можно восстановить до предшествующей точки во времени при хранении с помощью PowerShell.You can restore a deleted database to an earlier point in time during the retention using PowerShell.
Примечание
Восстановление удаленной базы данных в управляемом экземпляре недоступно.Restoring deleted database is not available in Managed Instance.
Важно!
При удалении экземпляра сервера базы данных SQL Azure все базы данных, находившиеся на нем, также будут удалены без возможности восстановления.If you delete an Azure SQL Database server instance, all its databases are also deleted and cannot be recovered. В настоящее время восстановление удаленного сервера не поддерживается.There is currently no support for restoring a deleted server.
Восстановление удаленной базы данных на портале AzureDeleted database restore using the Azure portal
Чтобы восстановить удаленную базу данных в течение срока хранения для модели на основе DTU или срока хранения для модели на основе виртуальных ядер с помощью портала Azure, откройте страницу сервера и в области операций щелкните Удаленные базы данных.To recover a deleted database using the Azure portal during its DTU-based model retention period or vCore-based model retention period using the Azure portal, open the page for your server and in the Operations area, click Deleted databases.
ГеовосстановлениеGeo-restore
Вы можете восстановить базу данных SQL на любой сервер в любом регионе Azure из последней геореплицированной резервной копии.You can restore a SQL database on any server in any Azure region from the most recent geo-replicated backups. В качестве источника геовосстановление использует геоизбыточную резервную копию для восстановления базы данных, даже если она или центр обработки данных недоступны из-за сбоя.Geo-restore uses a geo-redundant backup as its source and can be used to recover a database even if the database or datacenter is inaccessible due to an outage.
Примечание
В Управляемом экземпляре геовосстановление недоступно.Geo-restore is not available in Managed Instance.
Геовосстановление используется по умолчанию, когда база данных недоступна из-за происшествия в регионе, в котором она размещена.Geo-restore is the default recovery option when your database is unavailable because of an incident in the region where the database is hosted. Если масштабная авария в регионе приведет к недоступности приложения базы данных, то базу данных можно будет восстановить из геореплицированных резервных копий на сервер в любом другом регионе.If a large-scale incident in a region results in unavailability of your database application, you can restore a database from the geo-replicated backups to a server in any other region. Между созданием резервной копии и ее георепликацией в большой двоичный объект Azure в другом регионе существует задержка.There is a delay between when a backup is taken and when it is geo-replicated to an Azure blob in a different region. Эта задержка может длиться до часа, поэтому в случае аварии возможна потеря данных за час или менее.This delay can be up to an hour, so, if a disaster occurs, there can be up to one hour data loss. На следующем рисунке показано восстановление базы данных из последней доступной резервной копии в другом регионе.The following illustration shows restore of the database from the last available backup in another region.
Восстановление до точки во времени для базы данных-получателя геореплицируемых данных в настоящее время не поддерживается.Point-in-time restore on a geo-secondary is not currently supported. Восстановление до точки во времени может выполняться только для базы данных-источника.Point-in-time restore can be done only on a primary database. Дополнительные сведения об использовании геовосстановления для восстановления после сбоя см. в статье Восстановление базы данных SQL Azure или переход на базу данных-получатель при отказе.For detailed information about using geo-restore to recover from an outage, see Recover from an outage.
Важно!
Восстановление из резервных копий — это наиболее простое из решений аварийного восстановления, доступных в Базе данных SQL, с наибольшими значениями целевой точки восстановления (RPO) и предполагаемого времени восстановления (ERT).Recovery from backups is the most basic of the disaster recovery solutions available in SQL Database with the longest Recovery Point Objective (RPO) and Estimate Recovery Time (ERT). Для решений с небольшими базами данных (например, на уровне службы "Базовый" или для небольших баз данных клиентов в эластичных пулах) часто целесообразным решением аварийного восстановления является геовосстановление с периодом ERT до 12 часов (обычно он значительно меньше).For solutions using small size databases (e.g. Basic service tier or small size tenant databases in elastic pools), geo-restore is frequently a reasonable DR solution with an ERT of up to 12 hours (generally much less). В решениях, использующих большие базы данных, для которых требуется минимизировать интервалы восстановления, мы рекомендуем использовать группы отработки отказа и активную георепликацию.For solutions using large databases and require shorter recovery times, you should consider using Failover groups and active geo-replication. Активная георепликация обеспечивает более низкие значения RPO и ERT, так как требует только инициировать отработку отказа для перехода на непрерывно реплицируемую базу данных-получатель.Active geo-replication offers a much lower RPO and ERT as it only requires you initiate a failover to a continuously replicated secondary. Дополнительные сведения о непрерывности бизнес-процессов см. в обзоре обеспечения непрерывности бизнес-процессов.For more information on business continuity choices, see Overview of business continuity.
Геовосстановление с помощью портала AzureGeo-restore using the Azure portal
Чтобы выполнить геовосстановление базы данных в течение ее срока хранения для модели на основе DTU или срока хранения для модели на основе виртуальных ядер с помощью портала Azure, откройте страницу "Базы данных SQL" и щелкните Добавить.To geo-restore a database during its DTU-based model retention period or vCore-based model retention period using the Azure portal, open the SQL Databases page and then click Add. В текстовом поле Выбрать источник выберите Резервная копия.In the Select source text box, select Backup. Укажите, из какой резервной копии будет выполняться восстановление в регионе и на сервере по своему усмотрению.Specify the backup from which to perform the recovery in the region and on the server of your choice.
Программное восстановление с помощью создаваемых автоматически резервных копийProgrammatically performing recovery using automated backups
Как уже говорилось ранее, в дополнение к порталу Azure восстановление базы данных можно выполнить программно, с помощью Azure PowerShell или REST API.As previously discussed, in addition to the Azure portal, database recovery can be performed programmatically using Azure PowerShell or the REST API. В приведенных ниже таблицах описан доступный для этого набор команд.The following tables describe the set of commands available.
PowerShellPowerShell
REST APIREST API
Восстановление отдельной базы данных или базы данных в составе пула с помощью REST API:To restore a single or pooled database using the REST API:
Инфраструктура CLI AzureAzure CLI
Для восстановления отдельной базы данных или базы данных в составе пула с помощью Azure CLI см. описание команды az sql db restore.To restore a single or pooled database using Azure CLI, see az sql db restore.
СводкаSummary
Создаваемые автоматически резервные копии позволяют защитить базы данных от ошибок пользователей и приложений, случайного удаления базы данных и длительных простоев.Automatic backups protect your databases from user and application errors, accidental database deletion, and prolonged outages. Эта встроенная возможность доступна для всех уровней служб и объемов вычислительных ресурсов.This built-in capability is available for all service tiers and compute sizes.
Дополнительная информацияNext steps
docs.microsoft.com
восстановление базы данных из резервной копии sql – Zencoder
Недавно столкнулся с такой задачей. Когда-то у меня имелся свой собственный сайт под управлением CMS WordPress. Но примерно через год пользования сайт был заброшен, домен продан и площадка на хостинге аннулирована провайдером за неуплату.
Казалось бы, все, сайт пропал бесследно, как в воду канул. Но, в те далекие времена у меня хватило благоразумия делать регулярные резервные копии сайта, благо, под WordPress имеются несколько плагинов для этой цели. Удобных и относящихся к разряду “must have”.
Одним из них я и воспользовался. Названия этого плагина уже не помню. Но результатом его работы была заархивированная резервная копия базы данных сайта, которую плагин отправлял на мой почтовый ящик в качестве вложения в письмо. Файл-вложение имел примерный вид
| 1 | cifero_wrdp1_wp_20100225_594.sql.gz |
Порывшись в старых письмах на почтовом ящике, я выбрал самую последнюю по дате резервную копию. Раз она самая последняя, значит эта копия должна быть самой полной перед тем моментом, когда сайт перестал существовать. Затем скачал эту копию на свой локальный компьютер и стал думать, что же мне с нею делать? Как с помощью этой копии восстановить сайт на своем компьютере?
Первыми моими шагами были следующие. Резервную копию предполагалось развернуть на локальном сервере. Наиболее известным в этом плане является пакет Denwer. Поэтому он был скачан и установлен на локальную систему. Сам процесс установки Denwer в данной статье я описывать не буду, так как в Интернет имеется достаточное количество хороших материалов на эту тему.
В мою задачу входит восстановление статей, которые были когда-то размещены на этом сайте. С точки зрения полноценного восстановления сайта способ, описанный здесь, является незаконченным, так как сам сайт (его , в частности) восстановлен не был, что привело к так называемому “белому экрану смерти”. Стоит также оговориться, что, возможно, существуют команды и правки резервной копии базы данных, с помощью которых можно “напрямую” восстановить статьи, не заморачиваясь с phpMyAdmin и WordPress. Но для автора такие команды неизвестны, а способ, приведенный ниже, является более наглядным и простым.
Мною был скачана свежая версия CMS WordPress - 3.5. Но только скачана - не установлена. Данный шаг будет в дальнейшей последовательности действий самым последним.
Теперь все необходимое для восстановления сайта у меня есть. Приступаю к пошаговому разворачиванию локальной копии моего бывшего сайта .
- Запускаю локальный сервер Denwer. Это можно сделать разными способами, но если установка происходила в точности по инструкциям самого пакета, то на Рабочем столе должны быть три ярлычка - “Start Denwer”, “Restart Denwer”, “Stop Denwer” - которые запускают, перезапускают или останавливают Denwer. Я такими ярлычками и воспользовался, щелкнув мышью на ярлыке “Start Denwer”. На несколько секунд мелькнет и пропадет окно терминала, а в панели задач появится значок Denwer’а, говорящий о том, что локальный сервер запустился и готов к работе:
- Вторым шагом мне необходим доступ к базам данных локального сервера. В состав пакета Denwer входит графическое приложение phpMyAdmin, с помощью которого очень удобно работать с базами данных MySQL. Иногда в Интернет встречается сокращенное название этого приложения - . Так как сервер уже запущен, то я захожу в панель управления базами, набрав к адресной строке браузера (любого - это дело вкуса и дела совсем не меняет) -
. Откроется окно phpMyAdmin, в левой половине которого будет список уже имеющихся баз данных, созданных во время инсталляции локального сервера:1 http://localhost/tools/phpmyadmin/
- Теперь необходимо создать новую базу данных, в которой и будет развернуты резервные копии таблиц сайта . Стоит заранее оговориться, что база данных будет в нашем случае создана пустой, таблиц в ней не будет. Последние будут взяты из backup’а. Итак, перехожу на вкладку “Базы данных” и создаю новую, введя в поле нужное мне имя - . На самом деле имя может быть любым. Нажимаю кнопку “Создать”. База данных появляется в списке:
- Перед импортом резервной копии базы данных необходимо отметить один момент. Доменное имя, на котором находился когда-то сайт, нужно поменять. Ведь в таблицах резервной копии везде прописана ссылка на , а в нашем случае копия будет восстанавливаться на домене . Также в таблицах необходимо исправить имя базы данных - она также изменилась и теперь называется . Можно также изменить и пароль пользователя, но проще это сделать уже потом, после импорта в phpMyAdmin.
Если не выполнить вышеуказанные действия, то импортированная база данных просто не подключиться и восстановление сайта будет невозможно.
Итак, в первую очередь, распаковываю резервную копию
| 1 | cifero_wrdp1_wp_20100225_594.sql.gz |
- Запускаю его в AkelPad и начинаю правку. Нахожу строчку Database: (она находится в самом начале файла, тут проблем не возникает) и меняю ее значение на Database: . Все - имя базы данных исправлено. Теперь необходимо найти все ссылки вида , и заменить их на . Для этого воспользуюсь автоматизированным инструментом поиска и замены в редакторе AkelPad, иначе вручную эта операция может занять неизвестно сколько времени:
Сохраняю измененный файл и закрываю его. Стоит также упомянуть еще один момент. При редактировании файла можно заметить многочисленные ссылки, указывающие на плагины, которые когда то были установлены в WordPress на сайте . Но в версии WordPress, которую я буду устанавливать на локальном хостинге Denwer, их не будет. Этот факт приведет к эффекту так называемого “белого экрана смерти” в WordPress. То есть, при вводе в адресной строке браузера страница откроется, но изображено на ней ничего не будет - она будет пуста, как чистый лист бумаги. Но для меня данный факт не является критичным. В мою задачу, как уже говорилось ранее, входит восстановление статей, но не самого сайта.
Теперь можно импортировать таблицы в созданную пустую базу данных .
- Захожу в эту базу данных (для этого достаточно кликнуть одинарным щелчком мыши на самом названии этой базы в списке) и вижу, что она действительно пустая, о чем говорит надпись “Таблиц в базе данных не обнаружено”. Но я их и не собираюсь создавать - они у меня уже есть, только в резервной копии. Мне нужно только их импортировать из ранее скачанного ‘а в базу данных . Для этого перехожу на вкладку “Импорт” и выбираю файлик
:1 cifero_wrdp1_wp_20100225_594.sql
Нажимаю кнопку ОК в самом низу окна. Начнется процесс импорта. И тут же возникает ошибка:
Это говорит о том, что в настройках Denwer имеется ограничение по размеру загружаемого файла, моем случае это
| 1 | cifero_wrdp1_wp_20100225_594.sql |
Расположение файла я не знаю (а если и знал, то забыл), поэтому проще всего найти его с помощью инструмента поиска TotalCommander:
Перехожу к найденному с помощью кнопки “Перейти к файлу” и открываю его в текстового редакторе (может быть любым, но лучше специализированный - Notepad++ или AkelPad). Теперь необходимо найти параметр . Для этого опять воспользуюсь инструментом поиска, но уже текстового редактора (у меня это AkelPad):
Вижу, что значение по умолчанию для этого параметра равно 2Мб. Мой распакованный файл резервной копии имеет размер 3,88Мб. Поэтому меняю параметр на 8Мб (с запасом). Сохраняю изменения в файле и обязательно не забываю перезапустить Denwer, чтобы изменения вступили в силу.
Снова пробую импортировать таблицы в базу данных . На этот раз операция проходит успешно:
Осталась последняя операция с таблицами в базе данных. Так как ни имени пользователя, ни пароля к нему я не помню (давно уже это было), то необходимо изменить хотя бы пароль для входа в административную часть сайта. Открываю в phpMyAdmin базу данных (если она еще не открыта) и в левом списке нахожу таблицу . Открываю ее и вижу одну единственную строку, в которой прописана учетная запись в WordPress, под которой я размещал статьи.
Нажимаю на ссылку “Изменить” для входа в редактирование учетной записи. Появится небольшая табличка с десятью строками. Мне необходима строка . В столбце “Функция” из раскрывающегося списка выбираю алгоритм шифрования MD5. В поле столбца “Значение” прописан предыдущий пароль в зашифрованном виде. Очищаю это поле и ввожу туда новый пароль, пусть это будет :
Логин пользователя - - оставляю без изменений, только выписываю его отдельно, чтобы снова не забыть. Нажимаю кнопку ОК для сохранения внесенных в таблицу изменений. Опять перезапускаю Denwer.
- Половина дела сделана. Теперь осталось только установить саму систему управления контентом WordPress. При установке созданная мною база данных подключится к этой CMS.
Открываю файловый менеджер (для меня удобнее всего работать с Total Commander), перехожу на локальный диск Z, созданный и запущенный программой Denwer. В Total Commander последовательно создаю директории для будущей локальной копии сайта . Сперва создаю директорию , затем еще одну вложенную директорию .
Распаковываю скачанный WordPress версии 3.5 по пути . Проще всего это сделать таким образом. Открыть архив в WordPress в другой панели Total Commander, выделить все содержимое архива Ctrl+A и перетащить выделенные файлы мышью в противоположную панель Total Commander. Программа спросит, распаковывать ли такие-то файлы в указанное место. Соглашаюсь и через пару секунд разархивация и копирование будут выполнены:
-
Перезапускаю Denwer с помощью ярлыка “Restart Denwer” на “Рабочем столе”. Это необходимо для того, чтобы все изменения, внесенные мною - создание базы данных и импорт в нее таблиц - вступили в силу.
-
Остается только установить саму систему управления контентом WordPress. Процесс инсталляции стандартный и мало отличается от предыдущих версий WordPress, разве что немного изменился сам интерфейс пошагового мастера и стал удобнее. В адресной строке браузера ввожу и жму Enter. Установка WordPress начата:
Соглашаюсь с пошаговым мастером и нажимаю кнопку “Создать файл настроек”. После успешного создания файла настроек откроется окно, которое является вторым шагом при установке WordPress. Оно не требует ввода каких-либо данных. Просто жму кнопку Вперед.
Третье окно является, если так можно сказать, самым главным, так как здесь необходимо ввести такую важную информацию, как имя базы данных, которая будет подключена к устанавливаемой системе WordPress, имя пользователя (и его пароль) указанной базы данных. В моем случае я не стал усложнять задачу и создавать отдельного пользователя для базы данных . Воспользовался учетной записью , созданной пакетом Denwer по умолчанию. Так как для этой учетной записи не установлен пароль, то в поле ввода “Пароль” просто стер предыдущее значение и оставил его пустым:
Два последних поля ввода можно оставить без изменений, так как сервер базы данных и так располагается локально , а префикс подключаемой базы данных имеет точно такое же значение .
Жму отправить. Мастер установки отрапортует, что все в порядке, указанные мною данные верны и существующая база данных успешно подключена. Можно запускать установку WordPress. Нажимаю кнопку “Запустить установку”.
В браузере появиться сообщение о том, что: “Вы уже установили WordPress. Для переустановки, пожалуйста, сначала очистите старые таблицы в базе данных”. Нажимаю на кнопку Войти. Откроется обычное окно для входа в административную панель WordPress. Ввожу логин пользователя - , и пароль (который я изменил) - .
Откроется еще одно окно с предупреждением о том, что необходимо обновить базы данных:
Соглашаюсь с предложением. После сообщения о том, что: “База данных WordPress успешно обновлена!” жму кнопочку Продолжить.
Откроется панель администратора WordPress. Красным будет ярко высвечена надпись о том, что: “ОШИБКА: Директория тем либо пуста, либо не существует. Убедитесь, что дистрибутив установлен полностью”. Что же, данный факт, помимо отсутствия плагинов, будет причиной белого экрана сайта.
Перехожу в пункт меню “Записи” и вижу то, ради чего все и затевалось - записи, записи, записи. Вверху шапка сайта с таким романтическим названием:
Любую запись можно открыть, отредактировать или сохранить в другом месте компьютера. Или перенести на действующий сайт. На этом поставленную задачу считаю выполненной.
На этом все.
wordpressgearmobile.github.io
Автоматизированное восстановление баз данных MS SQL из бэкапов
В этой статье я хотел бы рассказать о том, как с помощью утилиты Quick Maintenance & Backup for MS SQL настроить автоматическое восстановление баз данных из бэкапов на тестовом экземпляре SQL Server в сети. При этом создавать бэкапы будет штатный План обслуживания. Потребность в автоматизированном восстановлении может возникнуть в следующих случаях:
- Если требуется регулярно актуализировать базы данных на тестовых серверах.
- Если требуется периодически проверять через восстановление созданные бэкапы: полный, разностный и журналы транзакций.
В сети можно найти примеры скриптов позволяющие в той или иной мере автоматизировать эти задачи. Но большинство решений требуют хорошего понимания T-SQL, предметной области и скорее всего потребуют изменения ваших Планов обслуживания. Я покажу как это сделать за 15-20 минут с помощью утилиты Quick Maintenance & Backup for MS SQL (QMB). Мы задействуем механизм XML планов восстановления — это XML файл с последовательностью бэкапов, который умеет создавать утилита. По информации в XML файле программа получит последовательность бэкапов, сформирует T-SQL скрипт для восстановления и запустит его на выполнение. Подробнее об этой возможности можно почитать здесь.Подробнее о других возможностях утилиты читайте на официальном сайте, а также в этой статье.
Задача
Итак, допустим имеется рабочий SQL Server (Srv01) на котором развернуты несколько баз данных с Полной моделью восстановления. На сервере создан План обслуживания с произвольной стратегией резервного копирования. В моем случае это:
Полный бэкап – каждую неделю 24.00 в воскресенье Разностный бэкап – каждую ночь в 24.00 кроме воскресеньяБэкап лога – каждый день с 9.00 до 23.59 через каждые 1 час
Бэкапы создаются в папке F:MS SQLBackup. При этом для каждой базы агент SQL Server создает отдельные подпапки.
Задача: каждый день в 23:00 на резервном SQL Server (London) выполнять восстановление баз данных на последнее возможное состояние из бэкапов созданных на Srv01. Оба сервера находятся в единой локальной сети. После восстановления каждой базы данных необходимо проверить её целостность (DBCC CHECKDB). Таким образом, каждый вечер кроме воскресенья, будет выполняться восстановление из Полного бэкапа, разностного и журналов транзакций, созданных в течении дня. В понедельник восстановление будет проводится из Полного бэкапа и журналов транзакций, созданных в течении понедельника. Если по каким-то причинам восстановление не выполнится администратору должно прийти email-уведомление.
Понятно, что для того чтобы тестовый SQL Server (London) смог выполнить восстановление он должен иметь доступ к файлам бэкапов. Тут возможны два варианта:
- Расшарить папку F:MS SQLBackup на Srv01 так чтобы она была доступна на London.
- С помощью QMB копировать бэкапы в общую сетевую папку, которая доступна на London.
По причине дополнительной надежности и простоты настройки мы реализуем второй вариант, т.е. утилита будет дополнительно копировать файлы в сетевую папку.
Общий порядок действий
Итак, нам потребуется проделать следующие шаги:
- Настроить общую сетевую папку
- Установить утилиту QMB
- Настроить уведомления и зарегистрировать в программе два SQL Server: Srv01 и London.
- Создать в программе две новых задачи:
- Создание XML плана восстановления на сетевом диске
- Восстановление по XML плану с сетевого диска
- Создать в программе два сценария:
- Сценарий, на рабочем сервере Srv01, выполняющий создание XML плана восстановления в общей папке с копированием в неё файлов бэкапов. Старт каждый 1 час.
- Сценарий, на тестовом сервере London, выполняющий восстановление по XML плану из бэкапов, размещенных в общей папке. Старт каждый день в 23.00.
Ниже рассмотрим каждый шаг подробнее.
Установка QMB
Утилиту можно скачать тут. Пробный период — 30 дней.
Я поставил утилиту на тестовом сервере London. В общем случае программу можно установить на любом компьютере, работающем круглосуточно т.е. установка именно на SQL Server не обязательна. При установке программы оставляем все параметры по умолчанию. Инсталлятор установит службу QmbService и клиента.
Регистрация SQL Server и настройка уведомлений
При первом старте программы откроется мастер. Перейдем на следующий шаг и установим галку «Включить email-оповещения» и введем адрес электронной почты для получения уведомлений.
Для отправки уведомлений рекомендуется настраивать собственную учетную запись SMTP, но для простоты мы будем использовать встроенную. Далее введем имя SQL Server и учетную запись для подключения к SQL Server. Необходимо указать учетную запись имеющую привилегии sysadmin (по умолчанию sa).
На следующем шаге программа отобразит версию сервера, лицензию и признак сжатия резервных копий. Все параметры оставляем по умолчанию и нажимаем кнопку «Вперед».
В следующем окне можно настроить слежение за свободным местом на дисках. Если в этом нет необходимости, то снимите все чекбоксы с дисков.
Жмем кнопку «Вперед».
Нам не требуется обслуживать базы данных поэтому на последней странице мы выберем «Создать пустой автономный сценарий». Затем снимем галку «Создать автономный сценарий для обслуживания системных баз данных» и нажмем кнопку «Завершить».
Программа зарегистрирует SQL Server и откроет форму нового пустого сценария.
Создание XML-плана восстановления
Любые задачи в программе исполняются в рамках сценариев. В окне нового автономного сценария ведем его имя Создание XML плана восстановления.
Добавим в сценарий задачу, которая будет создавать XML файл плана восстановления. Нажмем кнопку «Добавить». Откроется форма выбора задачи. Кликнем кнопку «Добавить новую задачу». Откроется форма новой задачи.
На форме нужно:
- Изменить тип задачи на «Создание XML плана восстановления»
- Создать новое подключение к общей папке. В моем случае это папка \ServerBackup на файловом сервере.
Примечание: Для сети без домена имя пользователя необходимо указывать в формате: КомпьютерПользователь
- Выбрать базы данных которые войдут в XML план восстановления. В моем случае это три базы — Account2013, Account2014, Account2015.
- Указать имя задачи — Создание XML плана для Account2013, Account2014, Account2015.
После выполнения всех действий, форма задачи будет выглядеть как на рисунке ниже.
Обратите внимание на признак «Копировать недостающие файлы архивных копий в общую папку». Благодаря этой опции программа автоматически скопирует недостающие файлы бэкапов с локального диска SQL Server в сетевую папку. При этом, путь к файлу источнику программа определит самостоятельно по информации о созданных резервных копиях, которую SQL Server хранит в системной базе msdb.
Нажмем кнопку Принять и выберем созданную задачу в сценарий. На форме сценария установим флаг «Запуск сценария по расписанию» и укажем расписание: Каждый день, через 1 час начиная с 9:30 до 22:30. Напомню, что План обслуживания создает бэкап лога каждый час с 9:00 до 23:59. Таким образом QMB будет обновлять XML план восстановления со сдвигом в 30 минут (9:30, 10:30, 11:30 и т.д). Нужно отметить, что если бы бэкапы создавались Политикой обслуживания QMB, то XML файл плана восстановления обновлялся бы автоматически.
Сценарий должен выглядеть как на рисунке ниже.
Теперь проверим сценарий. Для этого нажмем кнопку «Выполнить». Если все настроено верно, то в сетевую папку будут скопированы файлы резервных копий и создан файл RestorationPlan.xml. Если в ходе работы программа не найдет нужных файлов резервных копий, то задача завершится ошибкой. Таким образом мы заранее узнаем о потенциальных проблемах. Например, довольно часто, администраторы для передачи базы данных создают её полный бэкап (без параметра COPY_ONLY), а после передачи сразу удаляют его чтобы он не занимал место. Однако при этом рвется цепочка резервных копий и восстановление на актуальный момент времени становится невозможно. Программа выявит эту проблему ещё на этапе создания XML плана восстановления.
Сохраним сценарий. Теперь QMB через каждый час будет пересоздавать XML файл плана восстановления и копировать новые файлы бэкапов, которые создает штатный агент SQL Server.Нужно отметить, что задача по созданию XML плана копирует файлы, необходимые только для восстановления на последний возможный момент времени. При этом файлы копируются без папок т.е. все файлы будут размещены в указанной сетевой папке. В программе существует возможность настроить копирование подпапок, а даже удаление устаревших файлов в сетевой папке. Это можно сделать через пользовательскую задачу, содержащую CMD скрипт или используя Политику обслуживания QMB.
Восстановление на тестовом сервере
Восстановление по XML плану выполняется аналогично, с помощью специальной задачи, размещенной в сценарии. Однако восстановление должно выполняться на тестовом SQL Server (London), поэтому этот сервер тоже необходимо зарегистрировать в программе. Для этого в древовидном списке слева нажмем кнопку «Зарегистрировать сервер». Процедура регистрации сервера полностью аналогична описанной ранее.
После регистрации сервера откроется окно автономного сценария. Введем наименование Восстановление по XML плану с Srv01 и укажем его расписание: Каждый день в 23:00.
Теперь из формы сценария добавим новую задачу, аналогично тому как мы создавали задачу для создания XML плана. Однако, теперь в поле тип укажем Восстановление по XML плану, выберем ранее созданное подключение к сетевой папке и укажем имя XML файла. Переключатель База источник определяет какие именно базы данных XML плана восстановления необходимо восстанавливать.
База данных в которую будет выполнено восстановление определяется одноименным переключателем. В нашем случае я буду восстанавливать в одноименные базы данных. Это значит, что на SQL Server будут созданы/перезаписаны базы данных имеющие аналогичные имена (в моем случае это три базы: Account2013, Account2014, Account2015). Таким образом эти базы будут актуализироваться до последнего состояния.
Режим Восстанавливать во временную базу данных следует выбирать, если восстановление выполняется с целью проверки файлов резервных копий и процедуры восстановления. В этом режиме QMB создаст временную базу с наименованием qmbTempRestoreDb[Случайный индекс], которая будет удалена после восстановления и проверки её целостности.
Сохраняем задачу и выбираем её в нашем сценарии.
Чтобы убедиться, что восстановление пройдет успешно выполним сценарий в ручном режиме. Программа последовательно восстановит каждую базу данных и выполнит тестирование её целостности. В зависимости от размеров баз данных процедура может занимать значительное время.
Сохраним сценарий. Теперь каждый день в 23:00 программа будет автоматически восстанавливать базы данных и в случае сбоя отправлять уведомления на Email.
Кроме этого, используя XML файл плана восстановления, администратор с помощью программы может вручную, в несколько кликов, восстанавливать базы данных на других SQL Server.
С удовольствием отвечу на ваши вопросы в комментариях или по электронной почте [email protected]Спасибо за внимание!
Автор: СофтЛаб
Источник
www.pvsm.ru
Восстановление базы данных из резервной копии
Для восстановление базы данных из резервной копии следует щелкнуть правой клавишей мыши оп элементу, представляющему выбранную базу данных в правой части фрейма SQL Server Management Studio, и во всплывающем меню выбрать пункт Tasks > Restore > Database.... При этом открывается диалоговое окно для управления восстановлением выбранной базы данных:
Лабораторная работа рассчитана на 3 часа аудиторных занятий и состоит в изучении теоретического материала и получении практических навыков по конфигурированию| созданию| просмотру| удалению |отключению|подключению базы данных. Сдача лабораторной работы заключается в ответах на контрольные вопросы и демонстрации индивидуального задания.
Содержание отчета:
Название и цель работы
Задания
Результаты выполнения заданий
Задания
1. Изучите утилиту SQL Server Configuration.
1.1 Запустите утилиту SQL Server Configuration Manager и с ее помощью определите список запущенных на сервере служб. Запишите этот список в отчет.
1.2 На сервере с установленным MS SQL Server 2008 с помощью утилиты Services определите параметры запуска служб MS SQL Server и запишите их в отчет. (Если нет доступа к утилите Services, то при помощи SQL Server Configuration Manager).
1.3 Определите, с помощью каких сетевых библиотек может быть установлено соединение с MS SQL Server (см. пример рис). Какие библиотеки являются активными в момент запуска? Запишите эту информацию в отчет.
Рис. Протоколы на стороне сервера, через которые к нему можно подключаться
1.4 При помощи SQL Server Configuration Manager определите, на основе каких сетевых библиотек клиент может подключаться к MS SQL Server (см. пример рис). Запишите список библиотек в отчет.
Рис. Протоколы на стороне клиента, через которые он может подключаться к серверу
2. Установите соединение с SQL сервером.
2.1 На рабочей станции запустите SQL Server Management Studio и выберите из списка логическое имя сервера, запущенного на вашем компьютере. Если нужного сервера нет в списке, то можно выбрать <Browse for more…> и найти требуемый сервер в списке серверов, к которым может быть выполнено подключение.
2.2 Подключитесь к серверу с использованием средств аутентификации MS SQL Server.
2.3 Для того чтобы написать новый запрос необходимо выполнить команду New Query расположенную на панели инструментов SQL Server Management Studio. В результате откроется новая вкладка, которая предоставляет следующие возможности:
заголовок, в котором указывается логическое имя сервера, текущая база данных и имя пользователя, установившего соединение;
область запроса, используемая для ввода запросов, передаваемых MS SQL Server;
область результатов, в которой отображаются результаты выполнения запроса, а способ отображения задается кнопками Messages (в виде текста) и Results (в виде таблицы) соответственно.
С помощью команды SELECT @@version определите и запищите в отчет информацию об используемой версии MS SQL Server и операционной системы (результат запроса должен быть отображен в текстовом виде) (пример рис.).
Рис. Сведения о версии MS SQL Server
Примечание: Для выполнения запроса необходимо выполнить команду Query – Execute (F5), а для анализа правильности его синтаксической записи можно воспользоваться командой Query – Parse (Ctrl+F5).
SQL Server Management Studio позволяет открывать несколько окон запросов и работать с несколькими базами данных одновременно. В каждом окне устанавливается собственное соединение с MS SQL Server на основе различных учетных записей пользователей и их паролей. Для создания нового подключения используется команда File – New – Database Engine Query.
Содержимое области запроса текущего подключения может быть сохранено в файле на внешнем носителе командой File – Save.
2.5 При помощи панели Object Explorer определите имена поддерживаемых баз данных и какие базы данных сервера являются системными (для этого нужно развернуть узел Databases в панели Object Explorer). Запишите эту информацию в отчет.
3. Изучите параметры конфигурации MS SQL Server.
Конфигурирование службы MSSQLServer может быть выполнено либо специальной хранимой процедурой, выполняемой в утилите SQL Server Management Studio, либо графическим способом средствами этой же утилиты. Выбор способа не имеет значения, т.к. графический способ осуществляет доступ к системным данным с помощью этой же хранимой процедуры, только в более наглядной форме.
3.1 Для изменения параметров службы с помощью SQL Server Management Studio необходимо выбрать нужный сервер в Object Explorer и в контекстном меню выбрать команду Properties. В появившемся диалоговом окне можно выполнить настройку всех необходимых параметров.
Отобразите список параметров сервера (пример рис ).
Рис. Свойства MS SQL Server 2008
На вкладке General отображаются основные сведения о системе: версия операционной системы, объем памяти, количество процессоров и др., а также параметры запуска служб сервера.
Вкладка Memory позволяет управлять выделением памяти для выполнения действий MS SQL Server: либо динамическое управление памятью, либо установить фиксированный размер.
С помощью вкладки Security определяется тип аутентификации пользователей, также определяются параметры аудита доступа к серверу. Можно настроить сервер на использование определенной учетной записи, под которой будет запускаться служба MSSQLServer.
Вкладка Connections позволяет конфигурировать подключения клиентские подключения к серверу. Максимальное количество пользователей, которые могут одновременно подключиться к серверу. Если указано нулевое значение, то их количество составляет 32767.
Вкладка Advanced содержит некоторые общие установки сервера. Например, определяется язык по умолчанию для сообщений сервера или регулируется поддержка 2000 года, которая определяет, как будут интерпретироваться две последние цифры года.
С помощью вкладки Database Settings указываются настройки вновь создаваемых баз данных: параметры индексов и работы с устройствами резервного копирования, время восстановления базы данных.
3.2 Определите и запишите в отчет корневой каталог сервера, количество процессоров в системе, тип аутентификации пользователей и максимальное количество пользователей, поддерживаемых сервером.
3.3 Изучите остальные свойства MS SQL Server, доступные в этом диалоге.
4. Создать базу данных с именем Stud_<фио_студента>_1 средствами СУБД MS SQL Server 2008 с журналом средствами SQL Server Management Studio и с именем Stud_<фио_студента>_2 средствами Query Editor и запишите в отчет результаты выполнения процедуры sp_helpdb …. Для созданных вами БД
studfiles.net
