SQL-Ex blog
Как перевести базу данных SQL Server в состояние Recovery Pending
Добавил Sergey Moiseenko on Среда, 2 февраля. 2022
Вы могли бы спросить, зачем кому-то на земле понадобилось переводить базу данных в нежелательное состояние, а конкретно в состояние Recovery Pending (ожидание восстановления). Ну, в моем случае имелась клиентская база данных, которая вошла в это состояние в результате отказа хранилища. К счастью, это не была производственная база данных, поэтому у меня было время найти наилучший способ исправить проблему.
Фраза, которая часто использовалась во время моей службы в пожарной части, была такой: «Попробуй, прежде чем совать нос». Нужно ли выбивать входную дверь? Возможно она не заперта и, сначала попробовав (своим ботинком), я могу предотвратить повреждение двери. В подобных сценариях эта философия верна. Проверка на некритичных базах данных поможет предотвратить любые дальнейшие повреждения.
В данном случае я захотел проверить, прежде чем предпринимать некие действия, которые могли привести к повреждению. Это означало, что я должен был перевести тестовую базу данных в состояние восстановления. Переведя её в требуемое состояние, затем я могу испытать различные методы, чтобы правильно восстановить базу данных. Определившись с успешным решением, я смогу уверенно сунуть нос в поврежденную производственную базу данных, зная, что я использую проверенный метод.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: НЕ ДЕЛАЙТЕ ЭТОГО НА ПРОИЗВОДСТВЕННОМ ЭКЗЕМПЛЯРЕ SQL SERVER.
Как перевести базу данные в режим ожидания восстановления?
- Начать новую транзакцию.
- Создать новую таблицу.
- Остановить службу SQL Server.
- Переименовать/удалить файл журнала базы данных.
- Перезапустить службу SQL Server.
Почему база данных находится в режиме ожидания восстановления?
Когда база данных снова пытается перейти в оперативный режим, она будет переведена в состояние ожидания восстановления, поскольку отсутствует файл журнала, и имелась открытая транзакция, когда служба была выключена. При обычном функционировании даже при открытой транзакции SQL Server прошел бы фазу восстановления журнала транзакций. При восстановлении на фазе отката SQL Server попытался бы откатить транзакцию, которая была открыта на момент рестарта, и отменить изменения. Поскольку файл журнала теперь отсутствует, это невозможно сделать.
Следовательно, база данных теперь находится в состоянии ожидания восстановления. Это ожидание восстановления обусловлено открытой транзакцией, но SQL Server не может перевести базу данных в согласованное состояние.
Когда это происходит, вы видите что-то подобное в журнале ошибок:
Если база данных закрыта чисто, и файл журнала транзакций удален/переименован/и т.д., SQL Server просто перестроит для вас файл журнала.
Выводы
Иногда полезно иметь возможность перевести базу данных в конкретное состояние с тем, чтобы вы могли проверить решения прежде, чем выполнять какое-либо действие в условиях производства. Просто не забудьте попробовать, прежде чем сунуть нос. Если вы этого не сделаете, то можете только ухудшить ситуацию, поэтому излишняя осторожность не помешает.
Обратные ссылки
Нет обратных ссылок
Комментарии
Показывать комментарии Как список | Древовидной структурой
Автор не разрешил комментировать эту запись
Устранение неполадок баз данных доступности AlwaysOn в состоянии ожидания восстановления или подозрительного состояния в SQL Server
В этой статье описываются ошибки и ограничения базы данных доступности в Microsoft SQL Server, которая находится в Recovery Pending состоянии или , Suspect а также способы восстановления базы данных до полной функциональности в группе доступности.
Исходная версия продукта: SQL Server 2012 г.
Исходный номер базы знаний: 2857849
Заключение
Предположим, что база данных доступности, определенная в группе доступности AlwaysOn, переходит Recovery Pending в состояние или Suspect в SQL Server. Если это происходит на первичном реплика группы доступности, это влияет на доступность базы данных. В этом случае вы не сможете получить доступ к базе данных через клиентские приложения. Кроме того, нельзя удалить или удалить базу данных из группы доступности.
Например, предположим, что SQL Server выполняется, а для базы данных доступности задано Recovery Pending состояние или Suspect . При запросе динамических административных представлений (DMV) на первичном реплика с помощью следующего скрипта SQL база данных может быть представлена NOT_HEALTHY SUSPECT в состоянии и RECOVERY_PENDING или в состоянии следующим образом:
SELECT dc.database_name, d.synchronization_health_desc, d.synchronization_state_desc, d.database_state_desc FROM sys.dm_hadr_database_replica_states d JOIN sys.availability_databases_cluster dc ON d.group_database_id = dc.group_database_id AND d.is_local = 1 database_name synchronization_health_desc synchronization_state_desc database_state_desc -------------------- ------------------------------ ------------------------------ --------------------- NOT_HEALTHY NOT SYNCHRONIZING RECOVERY_PENDING (1 row(s) affected) 
Кроме того, эта база данных может находиться в состоянии Не синхронизация/ Ожидание восстановления или Подозрительное в SQL Server Management Studio.
Если база данных определена в группе доступности, ее невозможно удалить или восстановить. Поэтому необходимо выполнить определенные действия, чтобы восстановить базу данных и вернуть ее в рабочую среду.
Дополнительные сведения
В следующем содержимом рассматриваются ошибки и ограничения базы данных доступности, которая находится в состоянии ожидания восстановления в различных ситуациях.
-
Состояние базы данных предотвращает восстановление базы данных Чтобы восстановить базу данных с параметром RECOVERY , попробуйте выполнить следующий скрипт SQL:
RESTORE DATABASE WITH RECOVERY При выполнении этого скрипта появляется следующее сообщение об ошибке, так как база данных определена в группе доступности:
Сообщение 3104, уровень 16, состояние 1, строка 1
Функция RESTORE не может работать с database , так как она настроена для зеркального отображения базы данных или присоединена к группе доступности. Если вы планируете восстановить базу данных, используйте инструкцию ALTER DATABASE, чтобы удалить зеркальное отображение или удалить базу данных из группы доступности. Сообщение 3013, уровень 16, состояние 1, строка 1
Восстановление базы данных происходит аномально.
DROP DATABASE
При выполнении этого скрипта появляется следующее сообщение об ошибке, так как база данных определена в группе доступности:
Сообщение 3752, уровень 16, состояние 1, строка 1
База данных в настоящее время присоединена к группе доступности. Перед удалением базы данных необходимо удалить ее из группы доступности.
ALTER DATABASE SET hadr OFF При попытке запустить этот скрипт появляется следующее сообщение об ошибке, так как база данных доступности принадлежит к основному реплика:
Сообщение 35240, уровень 16, состояние 14, строка 1
База данных не может быть присоединена к группе доступности AvailabilityGroupName> или отсоединена от нее<. Эта операция не поддерживается в основном реплика группы доступности.
Из-за этого сообщения об ошибке может потребоваться выполнить отработку отказа базы данных. После отработки отказа базы данных реплика, которому принадлежит ожидающая восстановления база данных, находится в роли-получателе. В этом случае вы попытаетесь выполнить следующий скрипт SQL еще раз, чтобы удалить базу данных из группы доступности на вторичном реплика:
ALTER DATABASE SET hadr OFF Однако вы по-прежнему не можете удалить базу данных из группы доступности, и вы получите следующее сообщение об ошибке, так как база данных по-прежнему находится в состоянии ожидания восстановления:
Сообщение 921, уровень 16, состояние 112, строка 1
Database еще не восстановлен. Подождите и повторите попытку.
Разрешение, когда база данных находится в роли-получателе
Чтобы устранить эту проблему, выполните следующие общие действия.
- Удалите из группы доступности реплика, в котором размещена поврежденная база данных, когда база данных находится в роли-получателе.
- Устраните все проблемы, влияющие на систему и которые могли привести к сбою базы данных.
- Восстановите реплика в группе доступности.
Чтобы выполнить эти действия, подключитесь к новой первичной реплика, а затем запустите ALTER AVAILABILITY GROUP скрипт SQL, чтобы удалить реплика, в котором размещена база данных доступности, на котором была выполнена сбойная база данных доступности. Для этого выполните указанные ниже действия.
При выполнении этих действий предполагается, что на реплика-источнике сначала размещается поврежденная база данных. Поэтому сначала необходимо выполнить отработку отказа, чтобы перевести реплика, в котором размещена поврежденная база данных, во вторичную роль.
- Подключитесь к серверу, на котором выполняется SQL Server и на котором размещается дополнительный реплика.
- Выполните следующий скрипт SQL:
ALTER AVAILABILITY GROUP FAILOVER ALTER AVAILABILITY GROUP REMOVE REPLICA ON '' Разрешение, когда основной реплика является единственным реплика в группе доступности
Если основная реплика размещает поврежденную базу данных и является единственным рабочим реплика в группе доступности, группа доступности должна быть удалена. После удаления группы доступности базу данных можно восстановить из резервной копии или применить другие усилия по аварийному восстановлению для восстановления баз данных и возобновления рабочей среды.
Чтобы удалить группу доступности, используйте следующий скрипт SQL:
DROP AVAILABILITY GROUP
На этом этапе можно попытаться восстановить проблемную базу данных. Или можно восстановить базу данных из последней известной хорошей резервной копии.
Решение при удалении группы доступности
При удалении группы доступности ресурс прослушивателя также удаляется и прерывает подключение приложения к базам данных доступности.
Чтобы свести к минимуму время простоя приложения, используйте один из следующих методов для поддержки подключения к приложению через прослушиватель и удаления группы доступности:
Метод 1. Связывание прослушивателя с новой группой доступности (ролью) в диспетчере отказоустойчивости кластеров
Этот метод позволяет поддерживать прослушиватель при удалении и повторном создании группы доступности.
-
На экземпляре SQL Server, к которому существующий прослушиватель группы доступности направляет подключения, создайте пустую группу доступности. Чтобы упростить этот процесс, используйте команду Transact-SQL, чтобы создать группу доступности без дополнительных реплика или базы данных:
USE master GO CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH ( ENDPOINT_URL = 'tcp://sqlnode1:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL ) 
Это гарантирует, что приложения, использующие прослушиватель, по-прежнему могут использовать его для подключения к экземпляру SQL Server, в котором размещаются рабочие базы данных без прерывания. Исходную группу доступности теперь можно полностью удалить и повторно создать. Кроме того, базы данных и реплики можно добавить в новую группу доступности.
При повторном создании исходной группы доступности следует переназначить прослушиватель обратно роли группы доступности, настроить зависимость между новым ресурсом группы доступности и прослушивателем, а затем переназначить порт прослушивателю. Для этого выполните следующие действия:
- Запустите диспетчер отказоустойчивости кластеров, а затем выберите Роли в области слева. В области со списком ролей щелкните новую группу доступности, в которую размещается прослушиватель.
- В нижней средней области на вкладке Ресурсы щелкните прослушивателя правой кнопкой мыши, выберите Дополнительные действия, а затем выберите Назначить другую роль. В диалоговом окне выберите повторно созданную группу доступности и нажмите кнопку ОК.
- В области Роли щелкните повторно созданную группу доступности. В нижней средней области на вкладке Ресурсы вы увидите повторно созданную группу доступности и ресурс прослушивателя. Щелкните правой кнопкой мыши повторно созданный ресурс группы доступности и выберите Пункт Свойства.
- Перейдите на вкладку Зависимости , выберите ресурс прослушивателя в раскрывающемся списке и нажмите кнопку ОК.
- В SQL Server Management Studio используйте объектную Обозреватель для подключения к экземпляру SQL Server, на котором размещается основной реплика повторно созданной группы доступности. Выберите Высокий уровень доступности AlwaysOn, щелкните новую группу доступности, а затем выберите Прослушиватели группы доступности. Вы должны найти прослушиватель.
- Щелкните прослушиватель правой кнопкой мыши, выберите Свойства, введите соответствующий номер порта для прослушивателя и нажмите кнопку ОК.
Метод 2. Связывание прослушивателя с существующим кластеризованным экземпляром SQL Server отработки отказа (SQLFCI)
Если вы размещаете группу доступности в экземпляре отказоустойчивой кластеризации SQL Server (SQLFCI), вы можете связать кластеризованный ресурс прослушивателя с кластеризованной группой ресурсов SQLFCI во время удаления, а затем повторно создать группу доступности.
- Запустите диспетчер отказоустойчивости кластеров, а затем выберите Роли в области слева.
- В области со списком ролей выберите исходную группу доступности.
- В нижней средней области на вкладке Ресурсы щелкните правой кнопкой мыши ресурс группы доступности и выберите Пункт Свойства.
- Перейдите на вкладку Зависимости , удалите зависимость прослушивателя и нажмите кнопку ОК.
- В нижней средней области на вкладке Ресурсы щелкните прослушивателя правой кнопкой мыши, выберите Дополнительные действия, а затем выберите Назначить другую роль.
- В диалоговом окне Назначение ресурса роли щелкните экземпляр FCI SQL Server и нажмите кнопку ОК.
- В области Роли выберите группу SQLFCI. В нижней средней области на вкладке Ресурсы должен появиться новый ресурс прослушивателя.
Это гарантирует, что приложения, использующие прослушиватель, по-прежнему могут использовать его для подключения к экземпляру SQL Server, на котором размещаются рабочие базы данных без прерывания. Исходную группу доступности теперь можно удалить и повторно создать. Кроме того, базы данных и реплики можно добавить в новую группу доступности.
После повторного создания группы доступности переназначьте прослушиватель обратно роли группы доступности. Затем настройте зависимость между новым ресурсом группы доступности и прослушивателем и переназначьте порт прослушивателю:
- Запустите диспетчер отказоустойчивости кластеров, а затем выберите Роли в области слева.
- В области со списком ролей щелкните исходную роль SQLFCI.
- В нижней средней области на вкладке Ресурсы щелкните прослушивателя правой кнопкой мыши, выберите Дополнительные действия, а затем выберите Назначить другую роль.
- В диалоговом окне щелкните повторно созданную группу доступности и нажмите кнопку ОК.
- В области Роли выберите новую группу доступности.
- На вкладке Ресурсы вы увидите новую группу доступности и ресурс прослушивателя. Щелкните правой кнопкой мыши новый ресурс группы доступности и выберите Пункт Свойства.
- Перейдите на вкладку Зависимости , выберите ресурс прослушивателя в раскрывающемся списке и нажмите кнопку ОК.
- В SQL Server Management Studio используйте объектную Обозреватель для подключения к экземпляру SQL Server, на котором размещается основной реплика новой группы доступности.
- Выберите Высокий уровень доступности AlwaysOn, щелкните новую группу доступности, а затем выберите Прослушиватели группы доступности. Вы должны найти прослушиватель.
- Щелкните прослушиватель правой кнопкой мыши, выберите Свойства, введите соответствующий номер порта для прослушивателя и нажмите кнопку ОК.
Способ 3. Удалите группу доступности, а затем повторно создайте группу доступности и прослушиватель с тем же именем прослушивателя.
Этот метод приведет к небольшому сбою для приложений, которые в настоящее время подключены, так как группа доступности и прослушиватель удаляются, а затем создаются повторно:
-
Удалите группу доступности.
Примечание. Это также приведет к удалению прослушивателя.
USE master GO CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH ( ENDPOINT_URL = 'tcp://sqlnode1:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL ) LISTENER 'aglisten' ( WITH IP ((N'11.0.0.25', N'255.0.0.0')), PORT = 1433 ) GO MSSQLSERVER_4064
Имя входа SQL Server не удалось подключиться к SQL Server, либо из-за проблем с разрешением пользователя базы данных, связанного с именем входа в базе данных по умолчанию, либо с проблемой со своей базой данных по умолчанию.
Проблемы с разрешениями могут быть одним или несколькими из следующих:
- Имя входа не имеет соответствующего сопоставленного пользователя в базе данных по умолчанию.
- Вы назначили базу данных по умолчанию для входа, но не создали сопоставление пользователей в указанной базе данных.
- Сопоставленный пользователь для имени входа был отказано в доступе. (Например, это может произойти, если пользователь непреднамеренно добавляется в предопределенную роль базы данных db_denydatareader .)
База данных по умолчанию может быть недоступна во время подключения по следующим причинам:
- База данных по умолчанию находится в режиме подозрения.
- База данных по умолчанию больше не существует.
- База данных по умолчанию находится в однопользовательском режиме, и единственное доступное подключение уже используется кем-то или другим.
- База данных по умолчанию отключена.
- База данных по умолчанию имеет состояние RESTRICTED_USER.
- База данных по умолчанию находится в автономном режиме.
- Для базы данных по умолчанию задано состояние ЭКСТРЕННОГО РЕАГИРОВАНИЯ.
- База данных по умолчанию является частью зеркального отображения базы данных.
Кроме того, учетная запись входа может быть членом нескольких групп, а база данных по умолчанию для одной из этих групп недоступна во время подключения.
Дополнительные сведения о пользователях базы данных в SQL Server см. в разделе «Создание пользователя базы данных».
Действие пользователя
Вы можете выполнить одно из следующих действий:
Обход проблемы
Если вам не нужно получить доступ к текущей настроенной базе данных по умолчанию и вам просто нужно подключиться к экземпляру SQL Server для других операций с помощью SQL Server Management Studio (SSMS), выполните следующие действия:
- Откройте SQL Server Management Studio (SSMS).
- В обозревателе объектов выберите «Подключить>ядро СУБД».
- Заполните диалоговое окно «Подключение к серверу «.
- Выберите Параметры.
- В разделе «Свойства подключения» измените значение подключения к базе данных с помощью одного из следующих параметров:
- Если имя входа является членом роли sysadmin, введите master и выберите «Подключиться «, чтобы установить подключение к SQL Server. После успешного подключения к SQL Server можно изменить базу данных по умолчанию на другую, которая в настоящее время доступна на странице «Общие » свойств входа в SSMS. Дополнительные сведения см. в разделе Создание имени входа.
- Если имя входа не является членом роли sysadmin, введите имя базы данных на сервере, к которому у вас есть доступ. Кроме того, можно попробовать ввести имя системной базы данных, например master , а затем нажмите кнопку «Подключить». Этот шаг может не работать, если системный администратор явно отказался от разрешений гостевого master пользователя в базе данных. В этом сценарии необходимо работать с системным администратором, чтобы устранить проблему.
Устранение проблемы
Системный администратор может проверить, является ли текущая база данных по умолчанию пользователя, с помощью следующего запроса:
SELECT name, default_database_name FROM sys.server_principals WHERE type = 'S' AND name = ''; Используйте следующую таблицу, чтобы определить соответствующее действие для устранения проблемы для связанных причин:
| Причина | Решение |
|---|---|
| В базе данных по умолчанию для входа не существует сопоставления пользователей или пользователь был отказано в доступе. | Эти пользователи базы данных также называются потерянными пользователями. Эта проблема обычно возникает при перемещении баз данных между двумя экземплярами сервера и является одной из распространенных причин ошибки 4064. Сведения об обнаружении потерянных пользователей и устранении этой проблемы см. в статье «Устранение неполадок потерянных пользователей (SQL Server)». |
| Для входа не существует пользователя базы данных | Создайте пользователя базы данных и назначьте соответствующие разрешения для доступа к базе данных. |
| Учетные записи пользователя базы данных запрещены разрешения на доступ к базе данных | Перейдите к свойствам пользователя в базе данных (разверните пользователей системы безопасности > узла> базы данных) и проверьте, является ли пользователь частью db_denydatareader роли на странице членства. Вы также можете проверить действующие разрешения пользователя с помощью sys.fn_my_permissions. |
| База данных по умолчанию находится в режиме подозрения. | База данных может перейти в состояние SUSPECT по нескольким причинам. Возможные причины включают отказ в доступе к ресурсу базы данных операционной системой и недоступность или повреждение одного или нескольких файлов базы данных. Вы можете проверить состояние базы данных с помощью этого запроса: SELECT DATABASEPROPERTYEX (N», N’STATUS’) AS N’Database Status’; В SSMS состояние подозрительных баз данных отображается как (ожидание восстановления). Чтобы устранить эту ситуацию, может потребоваться восстановить базу данных из резервной копии. |
| База данных по умолчанию больше не существует. | Если вы намеренно удалили базу данных с сервера, измените базу данных по умолчанию для входа на другую существующую базу данных на сервере с помощью SSMS или инструкции ALTER LOGIN (Transact-SQL). При необходимости может потребоваться проверить наличие других имен входа на сервере, для которой для базы данных по умолчанию задана эта не существующая база данных с помощью этого запроса: SELECT name AS Login_Name FROM sys.server_principals where default_database_name = »; |
| База данных по умолчанию находится в однопользовательском режиме, а единственное подключение используется администратором или другим пользователем. | Если для целей обслуживания для базы данных задан режим с одним пользователем, его следует вернуть в режим с несколькими пользователями после завершения действия обслуживания, используя следующий запрос: ALTER DATABASE SET MULTI_USER; Дополнительные сведения см. в разделе «Настройка базы данных в однопользовательском режиме». Примечание. Чтобы проверить, находится ли база данных в однопользовательском режиме, можно использовать следующий запрос: SELECT name, user_access_desc FROM sys.databases WHERE name = »; Если вам по-прежнему нужно ограничить доступ к базе данных, но хотите включить подключение к затронутым именам входа, измените базу данных по умолчанию на другую базу данных на сервере. |
| База данных по умолчанию отключена. | Отключение базы данных удаляет ее из экземпляра SQL Server и больше не доступно. Чтобы сделать его доступным для входа, подключите базу данных с помощью SSMS или sp_attach_db хранимой процедуры. Дополнительные сведения см. в разделе «Отсоединение базы данных» и «Подключение» (SQL Server). |
| Для базы данных по умолчанию задано состояние RESTRICTED_USER. | Если для базы данных задано состояние RESTRICTED_USER, только члены предопределенных ролей базы данных db_owner, а также предопределенных ролей сервера dbcreator и sysadmin могут подключаться к базе данных. Если вам больше не нужно ограничивать доступ к соответствующей базе данных, задайте для базы данных многопользовательский режим, используя следующий запрос: ALTER DATABASE SET MULTI_USER; Примечание. Чтобы проверить, находится ли база данных в состоянии ограниченного пользователя, можно использовать следующий запрос: SELECT name, user_access_desc FROM sys.databases WHERE name = »; Если вам по-прежнему нужно ограничить доступ к базе данных, но хотите включить подключение к затронутым именам входа, измените базу данных по умолчанию на другую базу данных на сервере. |
| База данных по умолчанию находится в автономном режиме. | Невозможно изменить базу данных, которая находится в автономном состоянии. Вы можете перевести базу данных в режим «в сети», используя следующий запрос: ALTER database SET ONLINE; Можно проверить, является ли база данных автономной либо с помощью SSMS, либо с помощью этого запроса: SELECT DATABASEPROPERTYEX (N», N’STATUS’) AS N’Database Status’; Дополнительные сведения см. в разделе «Состояния базы данных» и параметры ALTER DATABASE SET (Transact-SQL) — SQL Server. Если необходимо сохранить базу данных в автономном состоянии, но хотите включить подключение к затронутым именам входа, измените базу данных по умолчанию на другую базу данных на сервере. |
| Для базы данных по умолчанию задано состояние ЭКСТРЕННОГО РЕАГИРОВАНИЯ. | Возможно, база данных была помещена в состояние аварийного реагирования для устранения неполадок системным администратором. Только пользователи роли sysadmin могут получить доступ к базам данных, заданным для состояния ЧРЕЗВЫЧАЙНОЙ СИТУАЦИи. Вы можете перевести базу данных в режим «в сети», используя следующий запрос: ALTER database SET ONLINE; Можно проверить, находится ли база данных в состоянии аварийного реагирования с помощью SSMS или этого запроса: SELECT DATABASEPROPERTYEX (N», N’STATUS’) AS N’Database Status’; Дополнительные сведения см. в разделе «Состояния базы данных» и параметры ALTER DATABASE SET (Transact-SQL). Если вам по-прежнему нужно сохранить базу данных в состоянии АВАРИЙНОго реагирования, но хотите включить подключение к затронутым именам входа, измените базу данных по умолчанию на другую базу данных на сервере. |
| База данных по умолчанию является частью зеркального отображения базы данных. | Вы не можете подключиться к зеркальной базе данных на зеркальном сервере, и это поведение выполняется путем проектирования. Чтобы проверить, находится ли база данных в зеркальной роли, используйте этот запрос SELECT DB_NAME(database_id) as database_name, mirroring_role_desc FROM sys.database_mirroring WHERE DB_NAME(database_id) = »; . Дополнительные сведения о зеркальных отображениях баз данных см. в разделе «Зеркальное отображение базы данных» (SQL Server). |
| Учетная запись входа может быть членом нескольких групп, а база данных по умолчанию для одной из групп недоступна во время подключения. | Чтобы перечислить группы с указанным пользователем с помощью PowerShell, см. статью Get-ADPrincipalGroupMembership (ActiveDirectory). |
Изменение базы данных по умолчанию для данного пользователя
Чтобы внести изменения в базу данных пользователя по умолчанию, необходимо иметь разрешение ALTER ANY LOGIN. Если измененное имя входа является членом предопределенных ролей сервера sysadmin или участника разрешения CONTROL SERVER, при внесении следующих изменений также требуется разрешение CONTROL SERVER. Члены роли sysadmin имеют эти разрешения по умолчанию. Дополнительные сведения см. в разделе ALTER LOGIN (Transact-SQL).
- Среда SQL Server Management Studio
- Служебная программа sqlcmd
- PowerShell
Изменение базы данных по умолчанию с помощью SSMS
- Подключитесь к экземпляру SQL Server с помощью SQL Server Management Studio (SSMS).
- Выберите «Имена входа безопасности> «, чтобы найти пользователя и изменить базу данных пользователя по умолчанию на другую, которая в настоящее время доступна на странице «Общие» свойств входа в SSMS. Дополнительные сведения см. в разделе Создание имени входа.
- После подключения к экземпляру SQL Server можно выполнить инструкцию ALTER LOGIN , как показано в следующих примерах: ALTER LOGIN WITH DEFAULT_DATABASE = ; — это заполнитель для имени существующей базы данных, к которым можно получить доступ с помощью имени входа SQL Server в экземпляре. — заполнитель для входа SQL Server с необходимыми ALTER LOGIN разрешениями. Например:
ALTER LOGIN [SQLLogin] WITH DEFAULT_DATABASE = master; ALTER LOGIN [Constoso\Windowslogin] WITH DEFAULT_DATABASE = [AdventureWorks]; Изменение базы данных по умолчанию с помощью служебной программы sqlcmd
Чтобы изменить базу данных по умолчанию, можно использовать следующую процедуру, используя служебную программу sqlcmd:
- На компьютере под управлением SQL Server нажмите кнопку «Пуск», а затем нажмите кнопку «Запустить«, введите и нажмите клавишу ВВОД cmd .
- Подключитесь к SQL Server с помощью служебной программы sqlcmd и одного из следующих параметров:
- Если вы хотите использовать проверку подлинности Windows для подключения к экземпляру с помощью учетной записи пользователя Windows, вошедшего в систему, введите следующую команду в окне командной строки и нажмите клавишу ВВОД: sqlcmd -E -S -d master Например:
sqlcmd -S "contoso\sql22" -E -d master sqlcmd -S contososql -U sqladmin -P
ALTER LOGIN [SQLLogin] WITH DEFAULT_DATABASE = master; ALTER LOGIN [Constoso\Windowslogin] WITH DEFAULT_DATABASE = [AdventureWorks]; Изменение базы данных по умолчанию с помощью PowerShell
Для обновления базы данных по умолчанию для указанного имени входа можно использовать следующий скрипт PowerShell.
# Define the variables for the SQL Server instance name and login name $instanceName = "YOUR_SQL_SERVER_INSTANCE_NAME" $loginName = "YOUR_SQL_SERVER_LOGIN_NAME" $newDefaultDB = "YOUR_NEW_DEFAULT_DATABASE" # Connect to the SQL Server instance $connectionString = "Server=$instanceName;Integrated Security=True" $connection = New-Object System.Data.SqlClient.SqlConnection($connectionString) $connection.Open() # Execute a T-SQL command to change the default database for the specified login $tsql = "ALTER LOGIN $loginName WITH DEFAULT_DATABASE = $newDefaultDB" $command = New-Object System.Data.SqlClient.SqlCommand($tsql, $connection) $command.ExecuteNonQuery() # Print a message indicating the update was successful Write-Host "The default database for the login '$loginName' has been successfully updated to '$newDefaultDB'" # Close the SQL Server connection $connection.Close() Ошибка 18456 отображается вместе с ошибкой 4064
При использовании таких приложений, как SSMS, которые получают ошибку 4064, отображаемой пользователю, в журнал ошибок SQL Server регистрируется следующее сообщение. В этом весь замысел. Исправление базы данных по умолчанию для неудачного входа с помощью процедур, описанных в этой статье, автоматически устраняет ошибку 18456.
2023-02-06 18:17:02.56 Logon Error: 18456, Severity: 14, State: 40. 2023-02-06 18:17:02.56 Logon Login failed for user '. Reason: Failed to open the database '' specified in the login properties. [CLIENT: ] Обратная связь
Были ли сведения на этой странице полезными?
Восстанавливаем базу данных SQL Server из режима “suspect”
В случае выхода базы данных из строя, может быть повреждена важная информация, потеря которой обернется катастрофическими последствиями как для пользователя, так и для бизнеса.
Автор: Waqas, журналист в сфере информационной безопасности В случае выхода базы данных из строя может быть потеряна важная информация. Последствия потери данных могут быть катастрофическими как для пользователя, так и для бизнеса. Если крупные организации понесут огромные убытки, малые предприятия могут поплатиться своим существованием. По словам разработчиков, ошибка присутствует в каждой программе. Даже самое лучшее программное обеспечение может иногда давать сбой. 
Иногда работа и жизнь людей зависят от функциональности программного обеспечения. Корректная работа ПО влияет на финансовое благополучие или здоровье людей. Поэтому особенно важно, чтобы при сбоях программного обеспечения, имелась возможность быстро его вернуть в нормальное рабочее состояние. Программы работают с базами данных. В случае выхода базы данных из строя, может быть повреждена важная информация, потеря которой обернется катастрофическими последствиями как для пользователя, так и для бизнеса. Большинство баз данных работают на сервере Microsoft SQL. В случае проблем с сервером для восстановления базы потребуется много времени и сил. 
Существует несколько способов восстановить базу данных после инцидента. Во-первых, следует разобраться с таблицей подозрительных(suspect) страниц. Информация в таблице подозрительных страниц доступна любому пользователю, имеющему доступ к базе данных MSDB. Обновлять базу также может любой пользователь, имеющий разрешение на обновление. Владельцы базы, исправив роль базы данных в MSDB, или сисадмин, исправив роль сервера, могут вставлять, обновлять и удалять записи. Способы восстановления базы данных из подозрительного режима: Сброс статуса базы данных + DBCC CHECKDB DBCC CHECKDB Используйте программное обеспечение Recovery Toolbox for SQL Server Таблица подозрительных страниц содержит информацию о потенциально поврежденных страницах и используется при принятии решения о восстановлении страниц. Подозрительная страница из таблицы находится в базе данных MSDB. Страница считается «подозрительной», если при попытке ее чтения ядром СУБД SQL Server обнаруживается одна из следующих ошибок.
- Ошибка 823: возникает во время проверки циклической контрольной суммы (CRC), запущенной операционной системой, например, ошибка диска (возникает при некоторых аппаратных ошибках)
- Ошибка 824: например, разрыв страницы (или любая другая логическая ошибка)
Идентификатор каждой «подозрительной» страницы записывается в таблицу подозрительных страниц. В данную таблицу компонент Database Engine записывает все подозрительные страницы, с которыми сталкивается во время обработки, в частности:
- Когда при обработке запроса необходимо прочитать страницу.
- При выполнении DBCC CHECKDB.
- Во время операции резервного копирования.
Во время операции восстановления, исправления DBCC или удаления базы данных таблица подозрительных страниц также обновляется по мере необходимости.
Ниже приведены несколько способов восстановления базы данных, если она перешла в режим “suspected”.
Во время своей работы я однажды столкнулся с ситуацией, когда рабочая база данных в конце дня перешла в режим “suspected”. Причем в последний раз база была заархивирована много часов назад. К сожалению, вернуться в штатный режим не получилось. DBCC checkdb также отказался запускаться.
Я очень расстроился, пока не нашел решение. Рассмотрим первый способ восстановления базы данных.
Сначала необходимо перевести базу данных в АВАРИЙНЫЙ режим, выполнив следующие действия:
- EXEC sp_resetstatus ‘yourDBname’;
- ALTER DATABASE yourDBname SET EMERGENCY
Затем требуется протестировать базу данных:
- DBCC checkdb (‘yourDBname’)
- ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
- DBCC CheckDB (‘yourDBname’, REPAIR_ALLOW_DATA_LOSS)
- ALTER DATABASE yourDBname SET MULTI_USER
Если не получилось восстановить базу первым способом
У вас имеется поврежденная база данных сервера (MS SQL 2005) и она неисправна. Такую базу невозможно восстановить путем тестирования-исправления (возникает ошибка контрольной суммы). В таком случае база данных не выгружается в файл – выдается та же ошибка. Вы попробовали несколько раз, и это не помогло. Попробуйте восстановить базу данных, протестировав сам SQL.
Команды для тестирования SQL приведены ниже:
- DBCC CHECKDB (‘database’, REPAIR_FAST)
- DBCC CHECKDB (‘database’, REPAIR_REBUILD)
Если обе команды не работают, можно использовать третью. Рекомендуем использовать данную команду только в крайнем случае в связи с опасностью возможной потери данных.
DBCC CHECKDB (‘database’, REPAIR_ALLOW_DATA_LOSS)
Если команда не выполняется из-за не однопользовательского режима, используйте команду:
Alter database db-name set SINGLE_USER
! Перед тестированием обязательно сделайте бэкап!
Используйте программу Recovery Toolbox for SQL Server — важный инструмент в работе любого системного администратора. Программа позволяет работать с файлами MS SQL Server любой версии.
Программа позволяет комплексно восстанавливать файлы базы данных. Особенности программы Recovery Toolbox for SQL Server приведены ниже:
1. Данные из нечитаемых баз данных можно восстановить в приостановленном состоянии (suspended state);
2. Программа работает со всеми версиями Microsoft SQL Server;
3. Программа позволяет восстановить самое важное и ценное в базе данных;
4. В базе данных несколько элементов — тоже не проблема;
5. Восстановливает таблицы при работе с MDF файлами;
6. SQL MDF Recovery экспортирует данные непосредственно в Microsoft SQL Server;
7. Информация сохраняется в том числе в виде скриптов;
8. Извлеченные данные напрямую экспортируются в новую базу данных;
9. Программа работает с любой версией Windows;
10. Мультиязычный интерфейс;
11. Возможен просмотр данных перед восстановлением;
Сбой базы данных после сбоя сервера является самым страшным сном любого сисадмина. Как в такой ситуации восстановить поврежденную базу?
Для восстановления данных после сбоя обычно используется резервная копия. Однако, если по какой-то причине копия не была сделана, попробуйте использовать Recovery Toolbox for SQL Server. Скорее всего, вам удастся восстановить рабочее состояние базы данных.
Для этого необходимо выполнить следующие действия:
1. Установите Recovery Toolbox for SQL Server на свой компьютер. Нет необходимости использовать полную версию, достаточно демонстрационной версии;
2. Выберите файл;
3. После выполнения действий начнется анализ базы данных;
4. Изучите список всех восстановленных таблиц;
5. Просматривайте данные в таблицах;
6. Изучайте восстановленные объекты;
7. Настройте параметры сохранения;
8. Выберите необходимые данные;
9. Сохраните их (для этого потребуется полная версия)
Восстановление базы данных
Как видим, для быстрого исправления MDF файла потребовалось нажать всего несколько кнопок. Все восстановленные данные копируются в новую базу данных или в виде скриптов на диск. Таким образом, программа никак не влияет на поврежденные файлы.
Как это работает?
1. Выбираем поврежденную базу данных.
2. Смотрим, какие данные можно восстановить.
3. Определяемся с вариантом экспорта.
4. Выбираем данные для восстановления.
5. Просматриваем отчет после сохранения.
Программа условно-бесплатная, стоит 99 долларов. Скачать программу можно здесь.