Ошибка восстановления базы данных sql server не удалось получить монопольный доступ

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

SQL-Server: Ошибка — не удалось получить монопольный доступ, поскольку база данных уже используется.

Я предполагаю, что если вы восстанавливаете базу данных, вас не волнуют какие-либо существующие транзакции в этой базе данных. Верно? Если это так, это должно сработать для вас:

А теперь еще об одном пункте, о котором нужно знать. После того, как вы установите базу данных в однопользовательский режим, кто-то другой может попытаться подключиться к базе данных. В случае успеха вы не сможете продолжить восстановление. Это гонка! Я предлагаю запустить все три оператора одновременно.

Установка БД в однопользовательский режим не сработала для меня, но перевод ее в автономный режим, а затем возврат в оперативный режим действительно сработал. Он находится в контекстном меню базы данных, в разделе «Задачи».

Обязательно установите флажок «Отменить все активные подключения» в диалоговом окне.

У меня возникла эта проблема при попытке восстановить базу данных на MS SQL Server 2012.

Вот что сработало для меня :

Мне пришлось сначала запустить команду RESTORE FILELISTONLY ниже для файла резервной копии, чтобы вывести логические имена файлов:

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

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

И задача восстановления базы данных успешно выполнилась:

Надеюсь, это поможет

  1. Задайте путь для восстановления файла.
  2. Нажмите «Параметры» слева.
  3. Снимите флажок «Сделать резервную копию журнала перед восстановлением»
  4. Установите флажок — «Закрыть существующие подключения к целевой базе данных».
  5. Щелкните ОК.

Выполните этот запрос перед восстановлением базы данных:

И этот после восстановления:

Для меня решение:

Установите флажок Перезаписать существующую базу данных (ЗАМЕНИТЬ) на вкладке параметров слева.

Снимите все флажки со всех остальных опций.

Выберите исходную и целевую базы данных.

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

Надеюсь, это поможет .

Я думаю, вам просто нужно установить базу данных в однопользовательский режим, прежде чем пытаться восстановить, как показано ниже, просто убедитесь, что вы используете master

Я просто перезапустил службу sqlexpress, а затем восстановление завершилось нормально

Перевод исходной базы данных в автономный режим работал для меня

take offline

Решение 1. Перезапустите службы SQL и попытайтесь восстановить БД. Решение 2. Перезапустите систему / сервер и попытайтесь восстановить БД. Решение 3. Верните текущую БД, удалите текущую / целевую БД и попытайтесь восстановить БД.

Вот способ восстановления базы данных от производства к разработке:

ПРИМЕЧАНИЕ. Я делаю это с помощью задания SSAS, чтобы ежедневно запускать производственную базу данных в разработку:

Шаг 1. Удалите резервную копию предыдущего дня, находящуюся в разработке:

Шаг 2: Скопируйте производственную базу данных в разработку:

Шаг 3. Восстановите, запустив скрипт .sql.

Код, который находится в файле AE11_Restore.sql:

Я получил эту ошибку, когда на диске не хватало места для восстановления Db. Очистка места решила эту проблему.

Я получил эту ошибку, когда без моего ведома кто-то был подключен к базе данных в другом сеансе SSMS. После того, как я их выписал, восстановление завершилось успешно.

Перевод БД Microsoft в Single-user Mode

В некоторых случаях требуется перевод БД SQL сервер в монопольный режим доступа (однопользовательский режим базы данных, Single-user Mode) это требуется в случаях выполнения операций, внесения изменений в БД или операций восстановления из резервной копии.
Так, например, при попытке восстановить рабочую БД, из резервной копии появится сообщение:
Exclusive access could not be obtained because the database is in use.

Чтобы исправить данное сообщение об ошибке, рекомендуется закрыть все приложения работающие с данной БД, а также вкладки SQL Management Studio, после этого выполнить команду:
где, AdventureWork — это имя базы данных.
Это откатит все текущие транзакции и переведет базу данных в режим работы Single-user Mode. После этого, если в этом же окне запустить операцию восстановления из резервной копии, то ошибка: «Exclusive access. » не повторится.

Для перевода режима работы БД в нормальный многопользовательский режим работы, необходимо выполнить команду:

Ошибка — не удалось получить монопольный доступ, поскольку база данных уже используется.

Я предполагаю, что если вы восстанавливаете базу данных, вам не нужны никакие существующие транзакции в этой базе данных. Правильно? Если да, то это должно сработать для вас:

Теперь нужно знать еще об одном пункте. После того, как вы установите базу данных в однопользовательский режим, кто-то другой может попытаться подключиться к базе данных. В случае успеха вы не сможете продолжить восстановление. Это гонка! Я предлагаю запустить все три оператора одновременно.

  • Remove From My Forums
  • Question

  • Hi,

    I am unable to restore a db on SQL Server 2005 running on XP Professional. The backup was made on the same machine just a few hours previously. The error msg is:

    Restore failed for Server ‘Server_Name’. (Microsoft.SqlServer.Smo)

    System.Data.SqlClient.SqlError: RESTORE cannot process database ‘DbName’ because it is in use by this session. It is recommended that the master database be used when performing this operation.

    However, there are no other apps currently connected to the db and the db is not involved in any query windows. This should be a perfectly routine restore, which I have done hundreds of times on many servers. I rebooted the server and still the same error.

    Any suggestions?

    Thanks.

    Dan

Answers

  • Hi — I just ran into this problem too, and my issue was I was restoring a database that I also was using as my default database.

    So, by changing my user default database to the master db, I was able to restore.

    Hope that helps.

    • Marked as answer by

      Tuesday, July 27, 2010 10:06 PM

  • Your login to the server cannot have the database as its default. Go to Security > Logins > your login user. Right click to get properties and where it says Default, put the database back to «Master.» It doesn’t take you out of the other db, just takes it out of that connection for the restore. I’d routinely restored but must have one day changed the default thinking it wouldn’t hurt anything. Now I know it hurts restores to that db if I log onto the server as that connection with that default! Hope this helps clear it up.

    • Proposed as answer by
      Jeffrey N. Sarmiento
      Monday, April 13, 2009 7:53 AM
    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:05 PM

  • I’m assuming that you are using Enterprise Manager or SQL Server Management Studio.

    You are connected to the database.

    With SSMS, close all query windows until the only window left open is [Object Exporer Details]. In the [Object Explorer] pane, click on any database OTHER than the one you want to RESTORE. IF there are no others listed, click on [System Databases], then click on the Master database.

    With EM, close all windows until you have on [Console Root], then click on the Master database

    Now try your RESTORE again.

  • I got the same problem. After my hard research, I found it is because your login is using your destined database as default database. SSMS is using your login default database as working platform and always keeps a session (connection) alive. So you just need to go to your login properties and change the «Default database» to something else. It works for me!

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:05 PM

  • You do NOT want to be connected to the database. That is the problem.

    Connect to a different database, such as Master. In Object Explorer, you do not want to have the database in question selected.

  • Hi rebton — thanks for your suggestion.

    I had the same problem and changing my default database sorted it, although I did have to close down SSMS and reopen for the changes to take effect.

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:05 PM

  • I ran into the same problem.

    Thanks for the suggestion. I changed my Default database and it worked for me.

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:05 PM

  • Hi All,

    It’s an old post, but high rank, so I will add one option. Default database might be specified for login used. Change that to master in Object Explorer tab under Security >> Logins >> Your Login.

    Thanks,
    Montek


    «Do you think I am what I am without being what I’m not?»

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:04 PM

  • FWIW:

    The issue is that the your user’s default database is the on you are trying to update or is offline.

    I know this solution is stated in other posts but here’s how got past the issue.  Both the windows login I was using and the «sa» login were both pointing to the database that I was trying to update
    as their default database (don’t ask).

    This solution works for both the SQL 2005 and SQL EM (SSMS):

    When I got the connection dialog box right after SQL startup, I clicked the «Options>>» button and typed in «master» (no quotes).  Once I connected (I was getting a login error because the database I was trying to update was offline from
    a previous troubleshooting step), I ran this:

    USE [master]
    GO

     
    ALTER DATABASE yourDbHere SET ONLINE
    GO

    ALTER LOGIN [yourLoginHere] WITH DEFAULT_DATABASE=[master]
    GO

    Disconect and reconnect to your DB Engine and you’re good to go.

    Rock on

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:04 PM

  • Remove From My Forums
  • Question

  • Hi,

    I am unable to restore a db on SQL Server 2005 running on XP Professional. The backup was made on the same machine just a few hours previously. The error msg is:

    Restore failed for Server ‘Server_Name’. (Microsoft.SqlServer.Smo)

    System.Data.SqlClient.SqlError: RESTORE cannot process database ‘DbName’ because it is in use by this session. It is recommended that the master database be used when performing this operation.

    However, there are no other apps currently connected to the db and the db is not involved in any query windows. This should be a perfectly routine restore, which I have done hundreds of times on many servers. I rebooted the server and still the same error.

    Any suggestions?

    Thanks.

    Dan

Answers

  • Hi — I just ran into this problem too, and my issue was I was restoring a database that I also was using as my default database.

    So, by changing my user default database to the master db, I was able to restore.

    Hope that helps.

    • Marked as answer by

      Tuesday, July 27, 2010 10:06 PM

  • Your login to the server cannot have the database as its default. Go to Security > Logins > your login user. Right click to get properties and where it says Default, put the database back to «Master.» It doesn’t take you out of the other db, just takes it out of that connection for the restore. I’d routinely restored but must have one day changed the default thinking it wouldn’t hurt anything. Now I know it hurts restores to that db if I log onto the server as that connection with that default! Hope this helps clear it up.

    • Proposed as answer by
      Jeffrey N. Sarmiento
      Monday, April 13, 2009 7:53 AM
    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:05 PM

  • I’m assuming that you are using Enterprise Manager or SQL Server Management Studio.

    You are connected to the database.

    With SSMS, close all query windows until the only window left open is [Object Exporer Details]. In the [Object Explorer] pane, click on any database OTHER than the one you want to RESTORE. IF there are no others listed, click on [System Databases], then click on the Master database.

    With EM, close all windows until you have on [Console Root], then click on the Master database

    Now try your RESTORE again.

  • I got the same problem. After my hard research, I found it is because your login is using your destined database as default database. SSMS is using your login default database as working platform and always keeps a session (connection) alive. So you just need to go to your login properties and change the «Default database» to something else. It works for me!

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:05 PM

  • You do NOT want to be connected to the database. That is the problem.

    Connect to a different database, such as Master. In Object Explorer, you do not want to have the database in question selected.

  • Hi rebton — thanks for your suggestion.

    I had the same problem and changing my default database sorted it, although I did have to close down SSMS and reopen for the changes to take effect.

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:05 PM

  • I ran into the same problem.

    Thanks for the suggestion. I changed my Default database and it worked for me.

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:05 PM

  • Hi All,

    It’s an old post, but high rank, so I will add one option. Default database might be specified for login used. Change that to master in Object Explorer tab under Security >> Logins >> Your Login.

    Thanks,
    Montek


    «Do you think I am what I am without being what I’m not?»

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:04 PM

  • FWIW:

    The issue is that the your user’s default database is the on you are trying to update or is offline.

    I know this solution is stated in other posts but here’s how got past the issue.  Both the windows login I was using and the «sa» login were both pointing to the database that I was trying to update
    as their default database (don’t ask).

    This solution works for both the SQL 2005 and SQL EM (SSMS):

    When I got the connection dialog box right after SQL startup, I clicked the «Options>>» button and typed in «master» (no quotes).  Once I connected (I was getting a login error because the database I was trying to update was offline from
    a previous troubleshooting step), I ran this:

    USE [master]
    GO

     
    ALTER DATABASE yourDbHere SET ONLINE
    GO

    ALTER LOGIN [yourLoginHere] WITH DEFAULT_DATABASE=[master]
    GO

    Disconect and reconnect to your DB Engine and you’re good to go.

    Rock on

    • Marked as answer by
      Kalman TothEditor
      Tuesday, July 27, 2010 10:04 PM

Наконец-то дошли руки самостоятельно испытать слияние двух чудо миров Microsoft и Linux в виде установки СУБД SQL Server 2017 на Debian 9.

Как написано в статье по ссылке, в SQL Server 2017 используется одно и то же ядро СУБД на всех поддерживаемых платформах, включая Linux. Тем не менее некоторые функции в настоящее время не поддерживаются в Linux (неподдерживаемые функции и службы, а также известные проблемы).

Также, довольно информативна страница часто задаваемых вопросов (FAQ).

Список платформ Linux, официально поддерживающиеся на данный момент:

  • Red Hat Enterprise Linux 7.3 или 7.4
  • SUSE Linux Enterprise Server до версии 12 с пакетом обновления 2
  • Ubuntu 16.04
  • Подсистема docker 1.8+

Написаны рекомендации по производительности и конфигурации для SQL Server в Linux.

Импорт ключей GPG общедоступного репозитория:

wget qO https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add —

Добавление репозитория Microsoft SQL Server 2017 Ubuntu:

sudo addaptrepository «$(wget -qO- https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2017.list)»

Если вы хотите попробовать SQL Server 2019, вместо этого необходимо добавить этот репозиторий:

sudo addaptrepository «$(wget -qO- https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-preview.list)»

Установка:

sudo aptget update

sudo aptget install y mssqlserver

Выбор выпуска, языка и установка пароля системного Администратора:

sudo systemctl stop mssqlserver

sudo /opt/mssql/bin/mssqlconf setup

Об использовании утилиты
mssqlconf  для конфигурации SQL Server в Linux написано тут.

Доступные выпуски SQL Server:
1) Evaluation (бесплатный, без прав на использование в рабочем окружении, 180-дневное ограничение)
2) Developer (бесплатный, без прав на использование в рабочем окружении)
3) Express (бесплатная)
4) Web (платный)
5) Standard (платный)
6) Enterprise (платный)
7) Enterprise Core (платный)
8) У меня есть лицензия, купленная через канал розничных продаж, и ключ продукта для ввода.

Изменение номера прослушиваемого TCP-порта со стандартного 1433 и перезапуск службы (если она, конечно, была запущена):

sudo /opt/mssql/bin/mssqlconf set network.tcpport <new_tcp_port>

sudo systemctl restart mssqlserver

Проверка запущена ли служба:

systemctl status mssqlserver

Или так:

netstat tlnp | grep 1433

По поводу разрешений на файлы SQL Server:
Все файлы в
/var/opt/mssql  должен принадлежать пользователю mssql из одноименной группы mssql, которые, в свою очередь, должны иметь разрешения на чтение и запись всех файлов и каталогов. Обратите внимание, следующих особых сценариев, включающих разрешений файлов и каталогов:
* Для подключенных сетевых ресурсов, которые используются для хранения файлов SQL Server, требуются разрешения владельца mssql.
* Если файлы базы данных или резервных копий находятся в каталоге не по-умолчанию, необходимо также задать разрешения для этого каталога.
* Если значение umask было изменено со значения по-умолчанию 0022, то произойдет сбой при настройке SQL Server после установки. Необходимо вручную применить нужные разрешения для стартовой учетной записи SQL Server.


Создание и восстановление БД из бэкапа

Тут можно пойти, почти как всегда, несколькими путями:
1) использовать родную консоль Linux, вот пример
2) использовать новый Azure Data Studio (Предварительная версия) на Linux — это кросс платформенное средство управления SQL Server, по типу SQL Server Management Studio
2) использовать старый, добрый SQL Server Management Studio

По сложившейся привычке использования продуктов Microsoft на Windows, я запустил свой SSMS 10.50.4000.0 от SQL Server 2008 R2. Т.к. версия у него, мягко говоря, не самая новая, то в работе с Linux периодически вылазили нелепые ошибки.

Создание БД
При создание новой БД нужно подправить путь сохранения файлов базы (убрать имена самих файлов, сгенерированных автоматически):

Восстановление БД из бэкапа
В любом случае нужно наш файл .bak загрузить на сервер, т.к. SSMS не умеет работать с файлами по сети, ну и не надо. Делаем mount сетевой шары, загружаем по FTP или еще как-нибудь.

Чтобы избежать ошибку:
"Не удалось получить монопольный доступ, так как база данных используется."
Устанавливаем монопольный режим у БД:
ПКМ на нашей БД => Свойства => Вкладка Параметры => внизу параметр "Ограничение доступа" установить в "SINGLE_USER"

Непосредственно восстановление
ПКМ на нашей БД => Задачи => Восстановить => База данных

Настраиваем параметры:

1) В базу данных <ИМЯ_БД>
2) С устройства => Добавить. И тут будет ошибочка:

Опять кривая работа со структурой разделов Linux. Нажимаем ОК и видим, что винда прилепила корневым разделом свой любимый “диск C:”. Ну, ничего, переживем как-нибудь. Находим свой файл бэкапа и вперед.


3) Не забываем установить галочку на добавленном “устройстве” в списке.
4) На вкладке Параметры корректируем имена файлов (удаляем лишнее)
5) Ставим галку “Перезаписать существующую БД (WITH REPLACE)”, иначе будет ошибка:
"Резервный набор данных содержит копию базы данных отличной от существующей"

Готово.

Итоговый запрос получился таким:

RESTORE DATABASE [TicketsTest]

FROM DISK = N‘C:homeivanTickets2008_26-01-2019_02-00-00.bak’ WITH FILE = 1,

MOVE N‘Tickets’ TO N‘/var/opt/mssql/data/TicketsTest.mdf’,

MOVE N‘Tickets_log’ TO N‘/var/opt/mssql/data/TicketsTest.ldf’,

NOUNLOAD,

REPLACE,

STATS = 10

UPDATE:

Позже я все-таки обновил SSMS (установил версию 17.9.1 (2017)), который уже, естественно, работает с Linux без глюков.

UPDATE 2:

Кстати, судя по всему, 1С до сих пор не поддерживает СУБД MS SQL Server на Linux’е. Цитата:

Особенности рабочих серверов под управлением Linux

  • не могут взаимодействовать с СУБД Microsoft SQL Server

Жаль, хотел запилить сравнение PGSQL и MSSQL на Linux.


Просмотров:
4 645

Понравилась статья? Поделить с друзьями:
  • Ошибка восстановления базы данных microsoft sqlserver management relationalenginetasks
  • Ошибка времени чем закончился фильм
  • Ошибка воспроизведения ошибка netsdk smart pss
  • Ошибка времени фильм ютуб
  • Ошибка времени фильм сюжет