SQL-Server: Ошибка — не удалось получить монопольный доступ, поскольку база данных уже используется.
Я предполагаю, что если вы восстанавливаете базу данных, вас не волнуют какие-либо существующие транзакции в этой базе данных. Верно? Если это так, это должно сработать для вас:
А теперь еще об одном пункте, о котором нужно знать. После того, как вы установите базу данных в однопользовательский режим, кто-то другой может попытаться подключиться к базе данных. В случае успеха вы не сможете продолжить восстановление. Это гонка! Я предлагаю запустить все три оператора одновременно.
Установка БД в однопользовательский режим не сработала для меня, но перевод ее в автономный режим, а затем возврат в оперативный режим действительно сработал. Он находится в контекстном меню базы данных, в разделе «Задачи».
Обязательно установите флажок «Отменить все активные подключения» в диалоговом окне.
У меня возникла эта проблема при попытке восстановить базу данных на MS SQL Server 2012.
Вот что сработало для меня :
Мне пришлось сначала запустить команду RESTORE FILELISTONLY ниже для файла резервной копии, чтобы вывести логические имена файлов:
Это отобразит логическое имя и соответствующее физическое имя файлов данных и журнала для базы данных соответственно:
Все, что мне нужно было сделать, это просто заменить логическое имя и соответствующее физическое имя файлов данных и журнала для базы данных соответственно в моем сценарии восстановления базы данных:
И задача восстановления базы данных успешно выполнилась:
Надеюсь, это поможет
- Задайте путь для восстановления файла.
- Нажмите «Параметры» слева.
- Снимите флажок «Сделать резервную копию журнала перед восстановлением»
- Установите флажок — «Закрыть существующие подключения к целевой базе данных».
- Щелкните ОК.
Выполните этот запрос перед восстановлением базы данных:
И этот после восстановления:
Для меня решение:
Установите флажок Перезаписать существующую базу данных (ЗАМЕНИТЬ) на вкладке параметров слева.
Снимите все флажки со всех остальных опций.
Выберите исходную и целевую базы данных.
Используйте следующий сценарий, чтобы найти и закрыть все открытые подключения к базе данных перед восстановлением базы данных.
Надеюсь, это поможет .
Я думаю, вам просто нужно установить базу данных в однопользовательский режим, прежде чем пытаться восстановить, как показано ниже, просто убедитесь, что вы используете master
Я просто перезапустил службу sqlexpress, а затем восстановление завершилось нормально
Перевод исходной базы данных в автономный режим работал для меня
Решение 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
-
Marked as answer by
-
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
-
Proposed as answer by
-
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
-
Marked as answer by
-
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
-
Marked as answer by
-
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
-
Marked as answer by
-
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
-
Marked as answer by
-
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
GOALTER LOGIN [yourLoginHere] WITH DEFAULT_DATABASE=[master]
GODisconect 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
-
Marked as answer by
- 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
-
Marked as answer by
-
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
-
Proposed as answer by
-
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
-
Marked as answer by
-
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
-
Marked as answer by
-
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
-
Marked as answer by
-
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
-
Marked as answer by
-
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
GOALTER LOGIN [yourLoginHere] WITH DEFAULT_DATABASE=[master]
GODisconect 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
-
Marked as answer by
Наконец-то дошли руки самостоятельно испытать слияние двух чудо миров 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 add—apt—repository «$(wget -qO- https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2017.list)» |
Если вы хотите попробовать SQL Server 2019, вместо этого необходимо добавить этот репозиторий:
sudo add—apt—repository «$(wget -qO- https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-preview.list)» |
Установка:
sudo apt—get update sudo apt—get install —y mssql—server |
Выбор выпуска, языка и установка пароля системного Администратора:
sudo systemctl stop mssql—server sudo /opt/mssql/bin/mssql—conf setup |
Об использовании утилиты
mssql—conf для конфигурации SQL Server в Linux написано тут.
Доступные выпуски SQL Server:
1) Evaluation (бесплатный, без прав на использование в рабочем окружении, 180-дневное ограничение)
2) Developer (бесплатный, без прав на использование в рабочем окружении)
3) Express (бесплатная)
4) Web (платный)
5) Standard (платный)
6) Enterprise (платный)
7) Enterprise Core (платный)
У меня есть лицензия, купленная через канал розничных продаж, и ключ продукта для ввода.
Изменение номера прослушиваемого TCP-порта со стандартного 1433 и перезапуск службы (если она, конечно, была запущена):
sudo /opt/mssql/bin/mssql—conf set network.tcpport <new_tcp_port> sudo systemctl restart mssql—server |
Проверка запущена ли служба:
systemctl status mssql—server |
Или так:
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