recovery pending sql что значит
Ручной Способ исправить Состояние ожидания восстановления SQL Server
Люди, которые использовали SQL-сервер, возможно, однажды столкнулись с ошибкой SQL база данных в состояние ожидания восстановления из-за ее повторного появления. Если вы не знаете, почему происходит эта ошибка, значит, ваш раздел базы данных, вероятно, заполнен. SQL не может открыть базу данных и не может заблокировать файл базы данных, который очень похож на базу данных в автономном режиме. Это больше похоже на то, что что-то мешает запуску сервера. В этом блоге мы собираемся обсудить, как исправить состояние ожидания восстановления SQL Server с помощью наилучших возможных методов. Прежде чем продолжить, давайте узнаем, каковы причины этой ошибки.
Причины – Состояние Ожидания восстановления базы данных SQL Server
Мгновенное Решение: Используйте средство восстановления SQL SysTools, чтобы исправить состояние ожидания восстановления в базе данных SQL Server. Это программное обеспечение может быстро устранить все ошибки, связанные с базой данных SQL. После восстановления он предоставляет возможность экспортировать данные в базу данных SQL или сценарии SQL.
Ручные способы исправить Состояние ожидания восстановления SQL Server
Как всегда можно увидеть или испытать, что ручные способы довольно сложны и опасны в использовании. Поэтому, прежде чем запустить его, убедитесь, что у вас есть резервная копия базы данных. Если вы новичок в этом, то рекомендуется, чтобы вы выполняли его под руководством технического специалиста или не выполняли его.
Способ 1
В этом ручном методе для разрешения Состояние ожидания восстановления базы данных SQL Server необходимо запустить принудительное восстановление.
1. Запустите нижеуказанные SQL-запросы.
ALTER DATABASE (Database Name) SET EMERGENCY;
ALTER DATABASE (Database Name) set single_user
DBCC CHECKDB ([Database Name], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;
ALTER DATABASE (Database Name) set multi_user
2. База данных помечена как READ_ONLY в аварийном режиме, отключает ведение журнала и предоставляет доступ только системным администраторам.
3. После того, как эти шаги будут выполнены, повреждение файла будет исправлено, и база данных снова будет подключена автоматически.
Способ 2
В этом втором методе, который может разрешить состояние ожидания восстановления в базе данных SQL Server, нам нужно сначала поработать в аварийном режиме, давайте посмотрим, как.
1. Выполните следующие команды:
ALTER DATABASE (Database Name) SET EMERGENCY;
ALTER DATABASE (Database Name) set multi_user
EXEC sp_detach_ db ‘(Database Name)’
EXEC sp_attach_single_file_db @Database Name = ‘(Database Name)’, @physname = N’(mdf path)’
2. Система автоматически удалять поврежденные журналы и создаст новый.
Если вы успешно выполнили оба метода, то до сих пор проблема Состояние ожидания восстановления базы данных SQL Server может быть решена. Если нет, то рекомендуется перейти на более безопасный и лучший подход, который является автоматизированным методом.
Автоматизированное решение для исправления Состояние Ожидания восстановления SQL Server
Автоматизация гораздо лучше, чем тратить много времени и усилий на ручные методы. Для автоматического метода вы можете перейти к Восстановление базы данных SQL. Это программное обеспечение помогает восстановить поврежденный файл MDF со всеми объектами базы данных. Для выполнения процесса восстановления базы данных SQL не требуется резервное копирование. Можно легко восстановить базу данных SQL без резервного копирования. Давайте узнаем, как это работает для восстановления поврежденных файлов базы данных SQL и устранения состояние ожидания восстановления в базе данных SQL Server.
1. Установите и запустите программу восстановления SQL, затем нажмите кнопку «Открыть», чтобы загрузить файл базы данных.
2. Выберите режим быстрого или расширенного сканирования, а затем установите флажок Автоопределение версии файла SQL Server.
3. Теперь начнется процесс сканирования. После сканирования вы можете увидеть предварительный просмотр восстановленных предметов.
4. Выберите опцию «Экспорт» сверху и выберите «Экспорт данных в базу данных SQL или сценарии SQL».
5. Заполните все необходимые данные ниже и выберите экспорт только со схемой или только со схемой и данными.
6. В конце нажмите кнопку «Экспорт», чтобы восстановить файлы базы данных SQL.
Вывод
Troubleshoot AlwaysOn availability databases in Recovery Pending or Suspect state in SQL Server
This article describes the errors and limitations of an availability database in Microsoft SQL Server that is in a Recovery Pending or Suspect state and how to restore the database to full functionality in an availability group.
Original product version: В SQL Server 2012
Original KB number: В 2857849
Summary
Assume that an availability database that is defined in an AlwaysOn availability group transitions to a Recovery Pending or Suspect state in SQL Server. If this occurs on the availability group’s primary replica, database availability is affected. In this situation, you can not access the database through the client applications. Additionally, you can not drop or remove the database from the availability group.
For example, assume SQL Server is running and an availability database is set to the Recovery Pending or Suspect state. When you query the dynamic management views (DMVs) at the primary replica by using the following SQL script, the database might be reported in a NOT_HEALTHY and RECOVERY_PENDING state or in a SUSPECT state as follows:
Additionally, this database may be reported as being in the Not Synchronizing / Recovery Pending or Suspect state in SQL Server Management Studio.
When the database is defined in an availability group, the database can not be dropped or restored. Therefore, you have to take specific steps to recover the database and return it to production use.
More information
The following content discusses the errors and limitations of an availability database that is in a Recovery Pending state in various situations.
Database status prevents restoring database
You try to run the following SQL script in order to restore the database that has the RECOVERY parameter:
When you run this script, you receive the following error message because the database is defined in an availability group:
Msg 3104, Level 16, State 1, Line 1
RESTORE cannot operate on database DatabaseName because it is configured for database mirroring or has joined an availability group. If you intend to restore the database, use ALTER DATABASE to remove mirroring or to remove the database from its availability group.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Database status prevents dropping database
You try to run the following SQL script in order to drop the database:
When you run this script, you receive the following error message because the database is defined in an availability group:
Msg 3752, Level 16, State 1, Line 1
The database DatabaseName is currently joined to an availability group. Before you can drop the database, you need to remove it from the availability group.
Database status prevents removing database from availability group
You try to run the following SQL script to remove the database from the availability group:
When you try to run this script, you receive the following error message because the availability database belongs to the primary replica:
Msg 35240, Level 16, State 14, Line 1
Database DatabaseName cannot be joined to or unjoined from availability group AvailabilityGroupName. This operation is not supported on the primary replica of the availability group.
Because of this error message, you may be compelled to fail over the database. After the database is failed over, the replica that owns the recovery pending database is in the secondary role. In this situation, you try to execute the following SQL script again in order to remove the database from the availability group at the secondary replica:
However, you still can not remove the database from the availability group, and you receive the following error message because the database is still in Recovery Pending state:
Msg 921, Level 16, State 112, Line 1
Database DatabaseName has not been recovered yet. Wait and try again.
Resolution when the database is in the secondary role
To resolve this issue, take the following general actions:
To take these actions, connect to the new primary replica, and then run the ALTER AVAILABILITY GROUP SQL script to remove the replica that is hosting the failed availability database. To do this, follow these steps.
These steps assume that the primary replica first hosts the damaged database. Therefore, a failover must first occur to transition the replica that is hosting the damaged database into a secondary role.
Connect to the server that is running SQL Server and that is hosting the secondary replica.
Run the following SQL script:
Run the following SQL script to remove the replica that is hosting the damaged database from the availability group:
Resolve any issues on the server that is running SQL Server and that might contribute to the database failure.
Add the replica back into the availability group.
Resolution when the primary replica is the only replica in the availability group
If the primary replica hosts the damaged database and is the only working replica in the availability group, the availability group must be dropped. After the availability group is dropped, your database can be recovered from a backup, or other emergency recovery efforts can be applied to restore the databases and to resume production.
To drop the availability group, use the following SQL script :
At this point, you can try to recover the problematic database. Or you can restore the database from the last-known good backup copy.
Resolution when you drop the availability group
When you drop an availability group, the listener resource is also dropped and interrupts application connectivity to the availability databases.
To minimize application downtime, use one of the following methods to sustain application connectivity through the listener and drop the availability group:
Method 1: Associate the listener with a new availability group (role) in Failover Cluster Manager
This method lets you maintain the listener while dropping and re-creating the availability group
On the instance of SQL Server to which the existing availability group listener is directing connections, create a new, empty availability group. To simplify this process, use the Transact-SQL command to create an availability group that has no secondary replica or database:
Start Failover Cluster Manager, and then click Roles in the left pane. In the pane that lists the roles, select the original availability group.
In the bottom-middle pane under the Resources tab, right-click the availability group resource, and then click Properties. Click the Dependencies tab, delete the dependency to the listener, and then click OK.
Under the resources, right-click the listener, click More Actions, and then click Assign to Another Role.
In the Assign Source to Role dialog box, select the new availability group, and then click OK.
In the Roles pane, select the new availability group. In the bottom-middle pane, under the Resources tab, you should now see the new availability group and the listener resource. Right-click the new availability group resource, and then click Properties.
Click the Dependencies tab, select the listener resource from the drop-down box, and then click OK.
In SQL Server Management Studio, use Object Explorer to connect to the instance of SQL Server that hosts the primary replica of the new availability group. Click AlwaysOn High Availability, click the new availability group, and then click Availability Group Listeners. You should find the listener.
Right-click the listener, click Properties, type the appropriate port number for the listener, and then click OK.
This makes sure that applications that use the listener can still use it to connect to the instance of SQL Server that is hosting the production databases without interruption. The original availability group can now be completely removed and re-created. Or the databases and replicas can be added to the new availability group.
If you re-create the original availability group, you should reassign the listener back to the availability group role, set up the dependency between the new availability group resource and the listener, and then reassign the port to the listener. To do this, follow these steps:
Method 2: Associate the listener with an existing SQL Server Failover Clustered Instance (SQLFCI)
If you are hosting your availability group on a SQL Server Failover Clustered Instance (SQLFCI), you can associate the listener clustered resource with the SQLFCI clustered resource group while you drop and then re-create the availability group.
Start Failover Cluster Manager, and then click Roles in the left pane.
In the pane that lists the roles, select the original availability group.
In the bottom middle pane under the Resources tab, right-click the availability group resource, and then click Properties.
Click the Dependencies tab, delete the dependency to the listener, and then click OK.
In the bottom middle pane under the Resources tab, right-click the listener, click More Actions, and then click Assign to Another Role.
In the Assign Resource to Role dialog box, click the SQL Server FCI instance, and then click OK.
In the Roles pane, select the SQLFCI group. In the bottom middle pane, under the Resources tab, you should now see the new listener resource.
This makes sure that applications that use the listener can still use it to connect to the instance of SQL Server that hosts the production databases without interruption. The original availability group can now be removed and re-created. Or the databases and replicas can be added to the new availability group.
After the availability group is re-created, reassign the listener back to the availability group role. Then set up the dependency between the new availability group resource and the listener, and reassign the port to the listener:
Method 3: Drop the availability group, and then re-create the availability group and listener with the same listener name
This method will result in a small outage for applications that are currently connected because the availability group and listener are dropped and then re-created:
Drop the availability group.
This will also drop the listener.
Immediately create a new, empty availability group that includes the listener definition, on the same server that hosts the production databases.
For example, assume that your availability group listener is aglisten. The following Transact-SQL statement creates an availability group with no primary or secondary database, but it also creates a listener named aglisten. Applications can use this listener to connect.
Recover the damaged database. Then add it and the secondary replica back to the availability group.
How to fix Recovery Pending State in SQL Server Database?
Updated on April 14, 2021
Summary: This post will outline the reasons why a database (db) is marked in recovery pending state. Also, it will describe methods to fix ‘SQL server database in recovery pending state’ problem. You can resolve the problem by executing queries in SQL Server Management Studio (SSMS), or by using Stellar Repair for MS SQL software.
SQL Server Database States
A SQL database is considered to be damaged if one or more of its core files are in an inconsistent state. Depending on how severe the damage is, the db is marked with different states. Some of these states are:
Let’s first understand how you can check the current state of the database.
How to Check Database State?
To check the current state of an SQL db, run the following query:
Executing the query will give you an output that looks something like:
Reasons behind Recovery Pending State in SQL Server
Some of the reasons causing such an issue are:
Methods to Fix Recovery Pending in SQL Server Database Issue
Note: Before initiating any of the following repair procedures, make sure to take db backup, so as to have a fail-safe copy in case anything goes wrong.
Method 1 – Manual Ways to Resolve the Database in Pending State
Following are the two manual ways that helps bring SQL database in recovery mode to normal mode:
1. Mark Database in Emergency Mode and Initiate Forceful Repair
Database EMERGENCY mode marks the database as READ_ONLY, disables logging, and grants access only to system administrators. Essentially, setting the db in this mode can bring the inaccessible database online.
Note: Usually a database comes out of EMERGENCY mode automatically. If you are having issues restoring the db from this mode, read this Recover SQL Database from Emergency Mode to Normal Mode.
Once you have opened the db in EMERGENCY mode, try repairing the database using the DBCC CHECKDB command with the ‘REPAIR_ALLOW_DATA_LOSS’ option. To do so, open SSMS and execute the following set of queries:
2. Mark Database in Emergency Mode, Detach the Main Database and Re-attach It
This solution also requires to mark db in EMERGENCY mode. Once done, take the database offline (detach) and then bring it online (re-attach). To do so, execute the following set of queries in SSMS:
The above set of queries help make the server get rid of the corrupt log and build a new one automatically.
Method 2 – Use Stellar Repair for MS SQL Software
If the above methods cannot help resolve the db in recovery pending state issue, use Stellar Repair for MS SQL software. The software can help you repair corrupt database files and bring the database back online from recovery pending state quickly and smoothly.
Steps to Use Stellar Repair for MS SQL Software
The repaired file will get saved in the selected location.
Note: For detailed information about using Stellar Repair for MS SQL software, refer to this user guide.
Key Features of Stellar Repair for MS SQL
Conclusion
You can fix the database by setting it to emergency state, and initiating the repair process or de-attaching and reattaching the db. But, such solutions have their own downsides:
You can overcome these limitations by using Stellar Repair for MS SQL software. The software helps SQL users and database administrators (DBAs) to fix severe database corruption errors. Also, it ensures complete recovery of db components, while preserving data integrity.
About The Author
Priyanka
Priyanka is a technology expert working for key technology domains that revolve around Data Recovery and related software’s. She got expertise on related subjects like SQL Database, Access Database, QuickBooks, and Microsoft Excel. Loves to write on different technology and data recovery subjects on regular basis. Technology freak who always found exploring neo-tech subjects, when not writing, research is something that keeps her going in life.
Best Selling Products
Stellar Repair for MS SQL is an enterprise-grade database repair softw.
3-in-1 software package, recommended by Microsoft MVPs and SQL adminis.
Stellar Converter for Database is an efficient database interconversio.
Powerful tool, widely trusted by users & admins worldwide, to repair c.
Устранение неполадок в базах данных доступности 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 RECOVERY_PENDING SUSPECT состоянии:
Кроме того, эта база данных может быть в состоянии Not Synchronizing /Recovery Pending или Suspect в SQL Server Management Studio.
Если база данных определена в группе доступности, ее нельзя отохить или восстановить. Поэтому необходимо предпринять определенные действия для восстановления базы данных и ее возврата к производственному использованию.
Дополнительные сведения
В следующем контенте обсуждаются ошибки и ограничения базы данных доступности, которая находится в состоянии Восстановления, ожидающих восстановления в различных ситуациях.
Состояние базы данных предотвращает восстановление базы данных
Чтобы восстановить базу данных с параметром, SQL выполнить следующий RECOVERY сценарий.
При запуске этого сценария вы получаете следующее сообщение об ошибке, так как база данных определяется в группе доступности:
Msg 3104, Level 16, State 1, Line 1
RESTORE не может работать на базе данных DatabaseName, так как она настроена для зеркального зеркального доступа к базе данных или присоединилась к группе доступности. Если вы собираетесь восстановить базу данных, используйте ALTER DATABASE, чтобы удалить зеркальное отражение или удалить базу данных из группы доступности.
Msg 3013, Level 16, State 1, Line 1
ВОССТАНОВЛЕНИЕ БАЗЫ данных завершается ненормально.
Состояние базы данных предотвращает удаление базы данных
Вы пытаетесь выполнить следующий сценарий SQL, чтобы отбросить базу данных:
При запуске этого сценария вы получаете следующее сообщение об ошибке, так как база данных определяется в группе доступности:
Msg 3752, Level 16, State 1, Line 1
В настоящее время имя базы данных присоединяется к группе доступности. Прежде чем удалить базу данных, ее необходимо удалить из группы доступности.
Состояние базы данных предотвращает удаление базы данных из группы доступности
Для удаления базы данных из группы доступности SQL следующий сценарий.
При попытке запуска этого скрипта вы получаете следующее сообщение об ошибке, так как база данных доступности принадлежит основной реплике:
Msg 35240, Level 16, State 14, Line 1
Имя базы данных не может быть соединено с группой availabilityGroupName или отсоединяется от нее. Эта операция не поддерживается в основной реплике группы доступности.
Из-за этого сообщения об ошибке может возникнуть принуждение к сбойу в базе данных. После сбой базы данных реплика, которой принадлежит ожидаемая база данных восстановления, будет в второстепенной роли. В этой ситуации вы пытаетесь выполнить следующий сценарий SQL, чтобы удалить базу данных из группы доступности на вторичной реплике:
Однако удалить базу данных из группы доступности по-прежнему нельзя, и вы получите следующее сообщение об ошибке, так как база данных по-прежнему находится в состоянии Recovery Pending:
Msg 921, Level 16, State 112, Line 1
Имя базы данных базы данных еще не восстановлено. Подождите и попробуйте еще раз.
Разрешение, когда база данных находится в второстепенной роли
Чтобы устранить эту проблему, примите следующие общие действия:
Чтобы выполнить эти действия, подключите новую первичную реплику, а затем запустите сценарий SQL, чтобы удалить реплику, в которой размещена база данных о несостоялась ALTER AVAILABILITY GROUP доступности. Для этого выполните указанные ниже действия.
Эти действия предполагают, что в основной реплике сначала размещена поврежденная база данных. Поэтому для перехода реплики, на которой размещена поврежденная база данных, необходимо сначала перейти на второстепенную роль.
Подключение серверу, который работает SQL Server и на который размещена вторичная реплика.
Запустите следующий SQL:
Запустите следующий SQL, чтобы удалить реплику, в которой размещена поврежденная база данных из группы доступности:
Устранение любых проблем на сервере, на SQL Server и которые могут привести к сбою базы данных.
Добавьте реплику обратно в группу доступности.
Разрешение, когда основная реплика является единственной репликой в группе доступности
Если основная реплика содержит поврежденную базу данных и является единственной рабочей репликой в группе доступности, группа доступности должна быть отброшена. После того как группа доступности будет отброшена, база данных может быть восстановлена из резервного копирования, а для восстановления баз данных и возобновления производства могут быть применены другие усилия по аварийному восстановлению.
Чтобы отказаться от группы доступности, используйте следующий сценарий SQL:
На этом этапе можно попытаться восстановить проблемную базу данных. Или вы можете восстановить базу данных из последней известной копии резервного копирования.
Разрешение при падении группы доступности
При падении группы доступности ресурс слушателя также отброшен и прерывается подключение приложений к базам данных доступности.
Чтобы свести к минимуму время простоя приложения, используйте один из следующих методов, чтобы поддерживать подключение приложений через слушателя и отказаться от группы доступности:
Метод 1. Связать слушателя с новой группой доступности (роль) в Failover Cluster Manager
Этот метод позволяет поддерживать слушателя при сбросе и повторном создании группы доступности
На примере SQL Server, к которому подключений руководит существующий слушатель группы доступности, создайте новую, пустую группу доступности. Чтобы упростить этот процесс, используйте команду Transact-SQL для создания группы доступности, у которой нет вторичной реплики или базы данных:
Запустите диспетчер кластера failover и нажмите кнопку Роли в левой области. В области, в которую перечислены роли, выберите исходную группу доступности.
На нижней середине области в вкладке Ресурсы щелкните правой кнопкой мыши ресурс группы доступности и нажмите кнопку Свойства. Щелкните вкладку Зависимостей, удалите зависимость для слушателя и нажмите кнопку ОК.
В соответствии с ресурсами щелкните правой кнопкой мыши слушатель, нажмите кнопку Дополнительные действия, а затем нажмите Кнопку Назначить другую роль.
В диалоговом окне Назначение источника роли выберите новую группу доступности и нажмите кнопку ОК.
В области Ролей выберите новую группу доступности. На нижней середине области в вкладке Ресурсы теперь необходимо увидеть новую группу доступности и ресурс слушателя. Щелкните правой кнопкой мыши новый ресурс группы доступности и нажмите кнопку Свойства.
Щелкните вкладку Зависимостей, выберите ресурс слушателя из выпадаемого окна и нажмите кнопку ОК.
В SQL Server Management Studio используйте Object Explorer для подключения к экземпляру SQL Server, в котором размещена основная реплика новой группы доступности. Щелкните AlwaysOn с высокой доступностью, щелкните новую группу доступности и нажмите кнопку Слушатели группы доступности. Вы должны найти слушателя.
Щелкните правой кнопкой мыши слушателя, щелкните Свойства, введите соответствующий номер порта для слушателя, а затем нажмите кнопку ОК.
Это позволяет приложениям, которые используют прослушиватель, по-прежнему использовать его для подключения к экземпляру SQL Server, в который без перерыва размещены производственные базы данных. Оригинальная группа доступности теперь может быть полностью удалена и повторно создана. Или базы данных и реплики могут быть добавлены в новую группу доступности.
При повторном создании исходной группы доступности следует переназначить слушателя на роль группы доступности, настроить зависимость между новым ресурсом группы доступности и слушателем, а затем переназначить порт слушателю. Для этого выполните следующие действия:
Метод 2. Связать слушателя с существующим экземпляром SQL Server failover Clustered Instance (SQLFCI)
Если вы размещены в группе доступности в кластерной экземпляре SQL Server failover (SQLFCI), можно связать кластерный ресурс слушателя с кластерной группой ресурсов SQLFCI во время падения и повторного создания группы доступности.
Запустите диспетчер кластера failover и нажмите кнопку Роли в левой области.
В области, в которую перечислены роли, выберите исходную группу доступности.
В нижней средней области на вкладке Ресурсы щелкните правой кнопкой мыши ресурс группы доступности и нажмите кнопку Свойства.
Щелкните вкладку Зависимостей, удалите зависимость для слушателя и нажмите кнопку ОК.
В нижней средней области в вкладке Ресурсы щелкните правой кнопкой мыши слушателя, нажмите кнопку Дополнительные действия и нажмите кнопку Назначить другую роль.
В диалоговом окне Назначение ресурса роли щелкните экземпляр SQL Server FCI и нажмите кнопку ОК.
В области Ролей выберите группу SQLFCI. В нижней средней области, на вкладке Ресурсы, теперь необходимо увидеть новый ресурс слушателя.
Это позволяет приложениям, которые используют прослушиватель, по-прежнему использовать его для подключения к экземпляру SQL Server, в котором без перерыва размещены производственные базы данных. Оригинальная группа доступности теперь может быть удалена и повторно создана. Или базы данных и реплики могут быть добавлены в новую группу доступности.
После повторного создания группы доступности перенанаменуем слушателя на роль группы доступности. Затем установите зависимость между новым ресурсом группы доступности и слушателем и перенастройка порта для слушателя:
Метод 3. Падение группы доступности, а затем повторное создание группы доступности и слушателя с тем же именем слушателя
Этот метод приведет к небольшому отключению приложений, подключенных в настоящее время, так как группа доступности и слушатель будут отброшены, а затем повторно созданы:
Отбросить группу доступности.
Это также отпадет от слушателя.
Немедленно создайте новую группу доступности, которая включает определение слушателя, на том же сервере, на котором размещены производственные базы данных.
Например, предположим, что ваш прослушиватель группы доступности является aglisten. В следующем заявлении Transact-SQL создается группа доступности без первичной или вторичной базы данных, но также создается прослушиватель с именем aglisten. Приложения могут использовать этот прослушиватель для подключения.
Восстановление поврежденной базы данных. Затем добавьте его и вторичную реплику обратно в группу доступности.