Устранение проблем с подключением и других ошибок

Область применения:База данных SQL AzureУправляемый экземпляр SQL AzureБаза данных SQL Azure в Fabric

При сбое подключения к базе данных SQL Azure, базе данных SQL в Microsoft Fabric или Управляемом экземпляре SQL Azure возникают сообщения об ошибках.

Как всегда, применяйте рекомендации и рекомендации по проектированию во время процесса разработки приложений.

Примечание.

Средство проверки подключения к SQL Azure можно использовать для обнаружения и устранения различных ошибок подключения.

Инструкции по устранению распространенных неполадок с подключением

  1. Убедитесь, что протокол TCP/IP включен в качестве клиентского протокола на сервере приложений. На серверах приложений, на которых нет установленных средств SQL, убедитесь, что tcp/IP включен, выполнив cliconfg.exe (служебная программа клиентской сети SQL Server).

  2. Проверьте строку подключения приложения, чтобы убедиться, что она настроена правильно. Например, убедитесь, что в строке подключения указан правильный порт (1433) и полное имя сервера. См. сведения о подключении с помощью SQL Server Management Studio.

  3. Попробуйте увеличить значение времени ожидания подключения. Мы рекомендуем устанавливать время ожидания подключения не менее 30 секунд.

  4. Проверьте подключение между сервером приложений и базой данных Azure SQL с помощью краткого руководства: используйте SSMS для подключения и выполнения запросов к базе данных Azure SQL или управляемому экземпляру Azure SQL, UDL-файла, ping или telnet. Дополнительные сведения см. в статьях Устранение неполадок с подключением и Диагностика проблем с подключением.

    Примечание.

    На этапе устранения неполадок можно также проверить возможность подключения на другом клиентском компьютере.

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

Если эти действия не помогли устранить проблему, попробуйте собрать дополнительные данные, а затем обратитесь в службу поддержки. Если приложение является облачной службой, включите ведение журнала. Это действие возвращает метку времени ошибки в формате UTC. Дополнительные сведения о ведении журналов см. в статье Включение ведения журнала диагностики для приложений в службе приложений Azure. Кроме того, база данных SQL возвращает идентификатор трассировки. Эти сведения могут использовать службы поддержки пользователей Майкрософт.

Сбои подключения, вызванные переопределением пользовательских файлов DNS или файла hosts

Если приложение имеет постоянные сбои входа (ошибки 18456, 40532 или 40615), изолированные от определенных клиентских сетей в то время как служба Azure SQL работоспособна, причина может быть настраиваемой конфигурацией DNS, которая закрепляет полное доменное имя сервера на устаревший IP-адрес шлюза Azure SQL.

Почему это происходит

База данных SQL Azure использует парк региональных шлюзов. Azure периодически выводит из эксплуатации и заменяет шлюзы в рамках обычных операций, включая обновление оборудования, масштабирование и миграцию на основе состояния. Azure авторитетный DNS для <server>.database.windows.net обновляется автоматически, чтобы отображать текущие активные шлюзы.

Когда среда переопределяет это разрешение DNS (через запись файла узлов, статическую запись CNAME или частную зону DNS, которая сопоставляет полное доменное имя сервера с определенным IP-адресом), клиент закрепляется на этом IP-адресе. Если шлюз на этом IP-адресе позже отставлен или переназначен, подключения переходят к неправильной конечной точке. Шлюз Azure SQL проверяет входящие полные доменные имена (FQDN) на целевом сервере, и несоответствие вызывает сбои входа.

Это важно

Попытки входа, которые переходят непосредственно на IP-адрес (или на устаревший IP-адрес через переопределение DNS) завершаются сбоем. Шлюз Azure SQL требует правильного полного доменного имени для маршрутизации подключений к целевому серверу.

Обнаружение переопределения DNS

Выполните следующие проверки из затронутого клиента.

  1. Проверьте файл локальных узлов для переопределения:

    :: Windows
type C:\Windows\System32\drivers\etc\hosts | findstr /i "database.windows.net"

    # Linux or macOS
grep -i "database.windows.net" /etc/hosts

  2. Сравните разрешение DNS запросов клиента с авторитетным Azure DNS.

    :: Client or recursive resolver
nslookup <server>.database.windows.net

:: Authoritative public DNS
nslookup <server>.database.windows.net 208.67.222.222

    # PowerShell
Resolve-DnsName -Name "<server>.database.windows.net" -DnsOnly

    Если резолвер клиента возвращает IP-адрес, отличный от авторитетного DNS, то переопределение DNS активно.

  3. Проверьте переопределение зоны CNAME или частной зоны DNS:

    nslookup -type=CNAME <server>.database.windows.net

    az network private-dns record-set list \
  --resource-group <ResourceGroup> \
  --zone-name database.windows.net \
  --output table

Исправить переопределение

  1. Удалите переопределение. Удалите запись в файле hosts, удалите статическую запись CNAME или удалите частную запись зоны DNS, которая привязывает FQDN сервера к конкретному IP-адресу.

  2. Очистка кэшей DNS на клиенте и любых промежуточных сопоставителей:

    :: Windows
ipconfig /flushdns

    # Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

  3. Убедитесь, что DNS теперь сопоставляется с нынешним шлюзом Azure.

    nslookup <server>.database.windows.net

    Убедитесь, что возвращенный IP-адрес попадает в диапазоны IP-адресов опубликованного шлюза для региона сервера. Список см. в разделе "IP-адреса шлюза " в архитектуре подключения.

  4. Повторное тестирование подключения с помощью средства проверки подключения Azure SQL или SQL Server Management Studio (SSMS).

Предотвращение этой проблемы

  • Никогда не закрепляйте полные доменные имена сервера Azure SQL к определенным IP-адресам в файлах узлов, статических записях CNAME или частных зонах DNS. Azure SQL шлюзы являются динамическими и изменяются с течением времени.
  • Если вы используете списки разрешений брандмауэра на основе IP-адресов шлюза, разрешите все диапазоны IP-адресов шлюза для вашего региона, а не отдельные IP-адреса. По возможности используйте Sql.<region> тег службы.
  • Для частного подключения используйте Приватный канал Azure или приватные конечные точки вместо замены DNS. Частные конечные точки предоставляют стабильные частные IP-адреса в виртуальной сети и направляются непосредственно в шлюз.
  • Подпишитесь на оповещения о работоспособности службы База данных SQL Azure, чтобы получать уведомления о миграции шлюзов в вашем регионе.

Краткий справочник

Симптом Вероятно, причина Исправить
Сбои входа (18456, 40532, 40615) изолированы от определенных клиентских сетей, в то время как работоспособность службы является нормальной Файл hosts или статический CNAME связывает FQDN с устаревшим или неправильным IP-адресом шлюза. Снимите переопределение, очистите кеш DNS, проверьте разрешение и повторно протестируйте.
nslookup возвращает IP-адрес, который не содержится в опубликованных диапазонах шлюзов для региона Активно переопределение DNS (файл hosts, CNAME или частная зона DNS) Удалите запись переопределения и очистите кэш DNS.
Подключения работают в некоторых сетях, но не удаются в других. Только сеть с перезаписью привязана к устаревшему IP-адресу Сравните разрешение DNS на неработающих и работающих сетях и удалите переопределение на неработающей сети.
Сбой подключения после уведомления о миграции шлюза Azure Статическое сопоставление DNS по-прежнему указывает на выведенный из эксплуатации шлюз. Удалите статическое сопоставление и разрешите все диапазоны IP-адресов шлюза для региона.
Cannot open server или server not found после отсутствия изменений конфигурации Ротация шлюза вывела из эксплуатации IP-адрес, который был жестко прописан в DNS. Удалите переопределение DNS и используйте динамическое разрешение через авторитетные серверы Azure.

Реализация логики повторных попыток

Настоятельно рекомендуется, чтобы клиентские приложения использовали логику повторных попыток, чтобы они могли восстановить соединение, дав время временной неисправности устраниться. Рекомендуется подождать 5 секунд, прежде чем выполнять первую повторную попытку. Повторная попытка после ожидания менее 5 секунд может привести к перегрузке облачной службы. Для каждой последующей повторной попытки ожидание должно увеличиваться экспоненциально, но не более чем до 60 секунд.

Примеры кода с логикой повторных попыток см. в следующих статьях:

Дополнительные сведения об обработке временных ошибок в приложении см. в статье "Устранение временных ошибок подключения".

Обсуждение периода блокировки для клиентов, которые используют ADO.NET, см. в статье Организация пулов соединений (ADO.NET).

Сообщения о временных ошибках (40197, 40613 и др.)

Инфраструктура Azure способна динамически изменять конфигурацию серверов при высокой рабочей нагрузке на службу баз данных SQL. Такое динамическое поведение может привести к разрыву подключения между клиентской программой и базой данных или экземпляром. Такое состояние называется временной ошибкой. События перенастройки базы данных обычно происходят в запланированном случае (например, при обновлении программного обеспечения) или в незапланированном случае (например, при сбое процесса или балансировке нагрузки). Большинство событий перенастройки являются короткими и должны быть завершены не более 60 секунд. Тем не менее завершение этих событий иногда может занимать больше времени, например когда большая транзакция приводит к длительному восстановлению. В следующей таблице перечислены различные временные ошибки, которые могут отображаться в приложениях при подключении к Базе данных SQL Azure.

Список кодов ошибок временных сбоев

Код ошибки Уровень серьезности Описание
926 14 Database 'replicatedmaster' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server error log for more information.

Эта ошибка может быть зарегистрирована в журнале ошибок экземпляра Управляемый экземпляр SQL на последнем этапе перенастройки, когда старый первичный сервер закрывает свой журнал, в течение короткого периода времени.
Другие нетрансляционные сценарии, связанные с этим сообщением об ошибке, описаны в документации по ошибкам MSSQL.
4060 16 Cannot open database "%.&#x2a;ls" requested by the login. The login failed.

Дополнительные сведения см. в разделе Ошибки с 4000 по 4999
40197 17 The service has encountered an error processing your request. Please try again. Error code %d.

Эта ошибка возникает, если служба не работает из-за обновления программного или аппаратного обеспечения, отказов оборудования или проблем, связанных с переключением на резерв. Код ошибки (%d), указанный в ошибке 40197, содержит дополнительные сведения о характере сбоя или переключении на запасной ресурс. В сообщении об ошибке 40197 может быть указан код ошибки 40020, 40143, 40166 или 40540.
При повторном подключении происходит автоматическое подключение к здоровой копии базы данных. Приложение должно зафиксировать ошибку 40197, зарегистрировать указанный в сообщении код ошибки (%d) для устранения неполадок и повторять попытки подключения к базе данных SQL, пока не появится доступ к ресурсам, а подключение не будет восстановлено. Дополнительные сведения см. в разделе Временные ошибки.
40501 20 The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.

Для получения дополнительной информации см.
• Управление ресурсами.
• Ограничения ресурсов для эластичных пулов при использовании модели приобретения DTU.
• ограничения на основе виртуальных ядер для отдельных баз данных.
• Ограничения на основе виртуального ядра для пулов эластичных баз данных.
• Ограничения ресурсов Управляемого экземпляра SQL Azure.
40613 17 Database '%.&#x2a;ls' on server '%.&#x2a;ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them with the session tracing ID of '%.&#x2a;ls'.

Эта ошибка может возникнуть, если в базе данных уже установлено подключение выделенного администратора (DAC). Дополнительные сведения см. в разделе Временные ошибки.
49918 16 Cannot process request. Not enough resources to process request. The service is currently busy. Please retry the request later.

Для получения дополнительной информации см.
• Управление ресурсами.
• Ограничения ресурсов для эластичных пулов при использовании модели приобретения DTU.
• ограничения на основе виртуальных ядер для отдельных баз данных.
• Ограничения на основе виртуального ядра для пулов эластичных баз данных.
• Ограничения ресурсов Управляемого экземпляра SQL Azure.
49919 16 Cannot process create or update request. Too many create or update operations in progress for subscription "%ld".

Служба занята обработкой нескольких запросов на создание или обновление для вашей подписки или сервера. В данный момент запросы блокируются для оптимизации ресурсов. Выполните запрос sys.dm_operation_status для ожидающих операций. Подождите, пока выполнятся ожидающие запросы на создание или обновление, либо удалите один из ожидающих запросов и повторите свой запрос позже. Если операции, как представляется, зависают, дождитесь завершения других выполняемых операций или отмените их по возможности. Например, можно отменить копию базы данных или создание геореплики, удалив созданную базу данных или реплику. Если не удается отменить по-видимому застрявшую операцию, откройте запрос в службу поддержки с корпорацией Майкрософт.
49920 16 Cannot process request. Too many operations in progress for subscription "%ld".

Служба занята обработкой нескольких запросов для этой подписки. В данный момент запросы блокируются для оптимизации ресурсов. Выполните запрос sys.dm_operation_status для состояния операции. Подождите, пока выполнятся ожидающие запросы, либо удалите один из ожидающих запросов и повторите свой запрос позже. Если операции, как представляется, зависают, дождитесь завершения других выполняемых операций или отмените их по возможности. Например, можно отменить копию базы данных или создание геореплики, удалив созданную базу данных или реплику. Если не удается отменить по-видимому застрявшую операцию, откройте запрос в службу поддержки с корпорацией Майкрософт.
4221 16 Login to read-secondary failed due to long wait on 'HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING'.

Вход в реплику данных невозможен, так как отсутствуют версии строк для транзакций, которые находились в процессе выполнения в момент перезапуска реплики. Чтобы устранить проблему, выполните откат или фиксацию активных транзакций на первичной реплике. Случаи этого состояния можно уменьшить, избегая выполнения длительных транзакций записи на основном сервере.
615 двадцать один Could not find database ID %d, name '%.&#x2a;ls'

Это означает, что кэш в памяти не синхронизируется с экземпляром SQL Server и поиски извлекают устаревший идентификатор базы данных.

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

Порядок устранения временных проблем подключения

  1. Проверьте панель мониторинга службы Microsoft Azure для всех известных сбоев, произошедших в течение времени, в течение которого приложение сообщает.
  2. Приложения, которые подключаются к облачной службе, например База данных SQL Azure, должны ожидать периодические события перенастройки и реализовать логику повторных попыток для обработки этих ошибок вместо отображения ошибок приложений пользователям.
  3. Если база данных близка к исчерпанию доступных ресурсов, может возникать временная проблема подключения. Смотрите Ограничения ресурсов.
  4. Если проблемы подключения остаются или интервал, во время которого приложение обнаруживает ошибку, превышает 60 секунд, а также если в определенный день такая ошибка возникает многократно, зарегистрируйте запрос на поддержку Azure, нажав Получить поддержку на сайте Поддержка Azure .

Эта проблема возникает в том случае, если приложению не удается подключиться к серверу.

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

Сервер/экземпляр не найден или недоступен (ошибки 26, 40, 10053)

Ошибка 26: ошибка при поиске указанного сервера

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.(provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Ошибка 40: невозможно открыть соединение с сервером.

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Ошибка 10053: ошибка на транспортном уровне при получении результатов с сервера

10053: A transport-level error has occurred when receiving results from the server. (Provider: TCP Provider, error: 0 - An established connection was aborted by the software in your host machine)

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

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

Не удается подключиться к серверу из-за проблем с брандмауэром

Ошибка 40615: не удается подключиться к серверу < имя сервера >

Чтобы устранить эту проблему, настройте параметры брандмауэра в базе данных SQL с помощью портала Azure.

Ошибка 5: не удается подключиться к серверу < имя сервера >

Чтобы устранить эту ошибку, откройте порт 1433 для исходящих соединений на всех брандмауэрах между клиентом и Интернетом.

Не удалось войти на сервер (ошибки 18456, 40531)

Пользователю '< имя_пользователя>' не удалось войти в систему

Login failed for user '<User name>'.This session has been assigned a tracing ID of '<Tracing ID>'. Provide this tracing ID to customer support when you need assistance. (Microsoft SQL Server, Error: 18456)

Чтобы устранить эту проблему, обратитесь к администратору служб, чтобы он дал вам допустимое имя пользователя и пароль.

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

  1. Войдите на сервер с помощью SQL Server Management Studio (SSMS).

  2. Чтобы проверить, отключен ли имя входа, выполните следующий SQL-запрос в master базе данных:

    SELECT name, is_disabled FROM sys.sql_logins;

  3. Если соответствующее имя отключено, его можно включить с помощью следующей инструкции:

    ALTER LOGIN <User name> ENABLE;

  4. Если имя пользователя для входа SQL не существует, внесите изменения и отправьте следующий SQL-запрос, чтобы создать новое имя входа SQL:

    CREATE LOGIN <SQL_login_name, sysname, login_name>
WITH PASSWORD = '<password, sysname, Change_Password>';
GO

  5. В обозревателе объектов SSMS разверните Базы данных.

  6. Выберите базу данных, на доступ к которой пользователю нужно предоставить разрешение.

  7. Щелкните правой кнопкой мыши значок Безопасность, а затем выберите Новый, Пользователь.

  8. В созданном скрипте с плейсхолдерами следуйте шагам для замены параметров в шаблоне SSMS и выполните его, например:

    CREATE USER [<user_name, sysname, user_name>]
FOR LOGIN [<login_name, sysname, login_name>]
WITH DEFAULT_SCHEMA = [<default_schema, sysname, dbo>];
GO

-- Add user to the database owner role
EXEC sp_addrolemember N'db_owner', N'<user_name, sysname, user_name>';
GO

    Также можно использовать sp_addrolemember, чтобы сопоставить данные определенных пользователей с конкретными ролями базы данных.

    Примечание.

    В База данных SQL Azure рассмотрите использование нового синтаксиса ALTER ROLE для управления членством в ролях базы данных.

Дополнительные сведения см. в разделе "Авторизация доступа к базе данных".

Ошибки, связанные с истечением времени ожидания подключения.

System. Data. SqlClient. SqlException (0x80131904): время ожидания подключения истекло

System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=3; handshake=29995;

System. Data. SqlClient. SqlException (0x80131904): время ожидания истекло

System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

System.Data.Entity.Core.EntityException: произошла ошибка базового поставщика при попытке открытия

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. -> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. -> System.ComponentModel.Win32Exception: The wait operation timed out

Не удается подключиться к серверу < имя_сервера >

Cannot connect to <server name>.ADDITIONAL INFORMATION:Connection Timeout Expired. The timeout period elapsed during the post-login phase. The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=231; handshake=983; [Login] initialization=0; authentication=0; [Post-Login] complete=13000; (Microsoft SQL Server, Error: -2) For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=-2&LinkId=20476 The wait operation timed out

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

Ошибки, связанные с истечением времени ожидания подключения, возникают из-за того, что приложению не удается подключиться к серверу. Чтобы устранить эту проблему, попробуйте выполнить действия (в указанном порядке), описанные в разделе Инструкции по устранению распространенных неполадок с подключением.

Устранение неполадок подключения к частной конечной точке

Подключения к базе данных База данных SQL Azure через частную конечную точку могут завершиться тайм-аутами подключения или ошибками на стадии предварительного установления соединения. Выполните следующие действия по порядку. Каждый шаг устраняет конкретный режим сбоя.

Шаг 1. Проверка частной конечной точки и разрешения DNS

Убедитесь, что частная конечная точка подготовлена и что DNS разрешает частный IP-адрес.

Проверка Как
Состояние подключения к частной конечной точке утверждено На портале Azure перейдите на сервер SQL Server, а затем Networking>Private access.
Частный IP-адрес выделяется Откройте ресурс частной конечной точки и запишите IP-адрес на странице обзора (например, 10.0.1.4).
DNS разрешает в частный IP-адрес Запустите nslookup <server>.database.windows.net. Результат должен пройти по цепочке CNAME к <server>.privatelink.database.windows.net и быть разрешён в частный IP-адрес. Если вместо этого отображается общедоступный IP-адрес, проверьте privatelink.database.windows.net частную зону DNS или правила условной пересылки.

Шаг 2. Добавление правила брандмауэра на уровне сервера для ip-адреса исходящего трафика

Даже при использовании частной конечной точки База данных SQL Azure по-прежнему применяет правила брандмауэра IP уровня сервера к исходному IP-адресу, который отображается шлюзом.

  1. Определите IP-адрес исходящего трафика. Для локального трафика, перенаправленного через VPN-шлюз или ExpressRoute, ip-адрес исходящего трафика обычно является шлюзом или частным IP-адресом NAT в виртуальной сети. В Azure это частный IP-адрес виртуальной машины или внешний IP-адрес подсистемы балансировки нагрузки.

  2. Добавьте правило брандмауэра уровня сервера для этого IP-адреса или подсети:

    EXECUTE sp_set_firewall_rule
    @name = N'AllowPrivateEndpointSubnet',
    @start_ip_address = '10.0.1.0',
    @end_ip_address = '10.0.1.255';

Примечание.

Переключатель Разрешить службам и ресурсам Azure доступ к этому серверу не включает трафик, поступающий из вашей собственной виртуальной сети через частную конечную точку. Необходимо добавить явное правило.

Шаг 3. Открытие правильных портов на пограничных или локальных брандмауэрах

Необходимые порты зависят от политики подключения:

Политика подключения Разрешенные порты Notes
Redirect (по умолчанию внутри Azure) 1433 - 65535 (входящий трафик к виртуальной сети частной конечной точки и исходящий трафик из клиентской виртуальной сети) После первоначального подтверждения 1433клиент перенаправляется на порт в более высоком диапазоне. Если более высокие порты заблокированы, рукопожатие проходит успешно, а затем время ожидания перенаправления истекает.
Proxy (по умолчанию вне Azure) Только 1433 Весь трафик проходит через шлюз через порт 1433. Правила брандмауэра проще, но задержка выше.
По умолч. Соответствует приведенным выше правилам. В Azure политика подключения Redirect. За пределами Azure это называется Proxy.

Если подключение успешно выполнено из виртуальной сети, но завершается сбоем из локальной среды, локальный брандмауэр, скорее всего, блокирует более высокие порты 1433-65535 диапазона. Откройте этот диапазон портов или измените политику подключения сервера на proxy. Дополнительные сведения см. в статье «Использование политики перенаправления соединений с частными конечными точками».

Шаг 4. Проверка симметричного маршрутизации для сценариев UDR, NVA и NAT

Если трафик к частной конечной точке SQL проходит через сетевое виртуальное устройство (NVA), Брандмауэр Azure или шлюз NAT, возвращаемый трафик должен соответствовать тому же пути. Асимметричная маршрутизация приводит к сбросу TCP или автоматическому удалению.

Ключевые факты:

  • Azure создает системный маршрут /32 для каждого IP-адреса частной конечной точки (например, 10.0.1.4/32 с типом следующего прыжка InterfaceEndpoints). Пользовательский маршрут (UDR) может переопределить этот системный маршрут, если его префикс равен или более конкретен (другой /32).

  • Если вы направляете исходящий трафик в NVA, NVA должен применить преобразование сетевых адресов источника (SNAT), чтобы возвращать пакеты обратно в NVA, а не напрямую к клиенту. Без SNAT путь возврата является асимметричным.

  • Политики сети частной конечной точки (поддержка NSG и UDR в подсети частной конечной точки) по умолчанию отключены. Чтобы применить правила NSG или UDR к трафику частной конечной точки, включите политики сети в подсети:

    az network vnet subnet update \
  --name <SubnetName> \
  --vnet-name <VNetName> \
  --resource-group <ResourceGroup> \
  --private-endpoint-network-policies Enabled

Если подключение работает без NVA, но истекает время ожидания при маршрутизации через него, /32 системный маршрут отправляет обратный трафик непосредственно клиенту, обходя таблицу состояний NVA. /32 Добавьте UDR для IP-адреса частной конечной точки, указывающего на NVA, и включите SNAT в NVA.

Шаг 5. Использование Наблюдатель за сетями для подтверждения сквозного подключения

Если предыдущие шаги выглядят правильно, но подключения по-прежнему завершаются ошибкой, используйте Azure Network Watcher для изоляции сбоя:

Инструмент Что это говорит вам
Устранение неполадок подключения Проверяет подключение TCP из виртуальной машины к виртуальной машине <server>.database.windows.net:1433 и сообщает о сбое подключения (NSG, маршрут или DNS).
Следующий прыжок Показывает, по какому элементу таблицы маршрутов проходит пакет к IP-адресу частной конечной точки. Подтверждает, находится ли в силе системный маршрут /32 или UDR.
Действующие маршруты Отображает объединенную таблицу маршрутов сетевого адаптера виртуальной машины, включая системные маршруты для частных конечных точек (тип следующего прыжка InterfaceEndpoints).

Краткий справочник

Симптом Вероятно, причина Исправить
nslookup возвращает общедоступный IP-адрес Зона DNS или условное перенаправление неправильно настроены Создайте или свяжите privatelink.database.windows.net частную зону DNS и проверьте условный сервер пересылки.
Cannot open server "не найден или недоступен" Для IP-адреса исходящего трафика отсутствует правило брандмауэра на уровне сервера. Добавьте правило брандмауэра для исходного IP-адреса с помощью sp_set_firewall_rule или на портале.
Соединение успешно установлено, затем происходит тайм-аут. Перенаправление более высоких портов (выше 1433, до 65535) блокируется локальным брандмауэром. Откройте полный 1433-65535 диапазон или переключите политику подключения на прокси-сервер.
Подключение работает без NVA, но истекает время ожидания с ним. Асимметричная маршрутизация. NVA не использует SNAT, или /32 отсутствует изменение UDR. Добавьте UDR, указывающий на /32 NVA, включите SNAT на NVA и включите политики сети для частных конечных точек.
Периодические сбросы TCP NSG в подсети частной конечной точки блокирует возврат трафика или политики сети частной конечной точки не включены. Включите сетевые политики для частных конечных точек и просмотрите правила группы безопасности сети (NSG).

Ошибки завершения сетевого подключения

Клиентские библиотеки SQL подключаются к базе данных Azure SQL и управляемому экземпляру Azure SQL с помощью сетевого протокола TCP. Клиентская библиотека использует компонент более низкого уровня, называемый поставщиком TCP для управления TCP-подключениями. Когда поставщик TCP обнаруживает, что удаленный узел неожиданно завершает существующее TCP-подключение, клиентская библиотека вызывает ошибку. Так как ошибка является клиентской ошибкой, а не ошибкой SQL Server, номер ошибки SQL не включен. Вместо этого номер ошибки равен 0, а используется сообщение об ошибке от поставщика TCP.

Ниже приведены примеры ошибок завершения сетевого подключения:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) An existing connection was forcibly closed by the remote host

A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

The client was unable to establish a connection because of an error during connection initialization process before login. Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

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

Ошибки управления ресурсами

Благодаря реализации системы управления ресурсами, основанной на Resource Governor, в Базе данных SQL Azure применяются ограничения ресурсов. См. подробные сведения об управлении ресурсами в Базе данных SQL Azure.

Сначала перечислены самые распространенные ошибки системы управления ресурсами с подробными сведениями. Затем следуют сообщения об ошибках системы управления ресурсами.

Ошибки 10928 и 10936: идентификатор ресурса : 1. Ограничение запроса для [базы данных или эластичного пула] равно %d и достигнуто

Если достигнуто ограничение уровня базы данных, в этом случае подробное сообщение об ошибке говорится: Resource ID : 1. The request limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

Если ограничение эластичного пула достигнуто, подробное сообщение об ошибке в этом случае считывается: Resource ID : 1. The request limit for the elastic pool is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance. ограничения эластичного пула превышают ограничения базы данных, дополнительные сведения см. в разделе "Управление ресурсами" в базе данных SQL Azure. Ограничения могут возникать, когда несколько баз данных в пуле используют ресурс (например, рабочие) одновременно.

Это сообщение об ошибке указывает, что достигнуто ограничение на количество рабочих для базы данных или эластичного пула. Максимальное значение параллельных рабочих ролей для цели службы базы данных или эластичного пула будет присутствовать вместо заполнителя %d.

Примечание.

В первоначальном предложении для Базы данных SQL Azure поддерживались только запросы с одним потоком. В то время число запросов всегда было равно числу рабочих. Сообщения об ошибках 10928 и 10936 в База данных SQL Azure содержат слово "Ограничение запроса [...] имеет значение N и достигнуто" для обеспечения обратной совместимости. Фактически, достигнутое ограничение — это число рабочих. Если параметр max degree of parallelism (MAXDOP) равен нулю или больше одного, число рабочих потоков может намного превосходить число запросов, и можно быстрее достичь ограничения, чем когда MAXDOP равен одному.

См. подробные сведения о сеансах, рабочих ролях и запросах.

Подключитесь к выделенному соединению администратора (DAC) при необходимости

Если текущий инцидент продолжается, когда достигнуто ограничение лимита рабочих процессов, при подключении с помощью SQL Server Management Studio (SSMS) может появиться ошибка 10928. Одно подключение может использовать диагностическое подключение для администраторов баз данных (DAC), даже когда достигнут максимальный предел числa рабочих потоков.

Чтобы установить соединение с DAC из SSMS:

  • В меню выберите Файл > Новый > Запрос движка базы данных.
  • В диалоговом окне подключения в поле "Имя сервера" введите admin:<fully_qualified_server_name> (например, admin:servername.database.windows.net).
  • Выберите Параметры>>.
  • Выберите вкладку Свойства подключения.
  • В поле Подключение к базе данных: введите имя базы данных.
  • Нажмите Подключиться.

Если вы получаете ошибку 40613, это может указывать на то, Database '%.&#x2a;ls' on server '%.&#x2a;ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '%.&#x2a;ls'что другой сеанс уже подключен к DAC. Только один сеанс может подключаться к DAC для одной базы данных или эластичного пула одновременно.

Если вы столкнулись с ошибкой "Не удалось подключиться к серверу" после выбора подключения, сеанс DAC может быть успешно установлен, если вы используете версию SSMS до 18.9. В ранних версиях SSMS выполнялась попытка предоставить Intellisense для подключений к DAC. Это не удалось, так как DAC поддерживает только один рабочий процесс, а для Intellisense требуется отдельный рабочий процесс.

Невозможно использовать подключение DAC с Обозревателем объектов в SSMS.

Проверьте использование max_worker_percent

Чтобы найти статистику потребления ресурсов для базы данных за 14 дней, подайте запрос к представлению каталога системы sys.resource_stats. В столбце max_worker_percent показано количество используемых рабочих ролей относительно предельного количества рабочих ролей для вашей базы данных. Подключитесь к базе данных на логическом сервере master для запросаsys.resource_stats.

SELECT start_time, end_time, database_name, sku, avg_cpu_percent, max_worker_percent, max_session_percent 
FROM sys.resource_stats;

Кроме того, вы можете запросить статистику по потреблению ресурсов за последний час в динамическом административном представлении sys.dm_db_resource_stats. Подключитесь непосредственно к своей базе данных, чтобы запросить sys.dm_db_resource_stats.

SELECT end_time, avg_cpu_percent, max_worker_percent, max_session_percent
FROM sys.dm_db_resource_stats;

Снижение использования рабочих при возможности

Блокирование цепочек может привести к внезапному увеличению количества работников в базе данных. Большой объем параллельных запросов может привести к большому количеству рабочих процессов. Увеличив максимальный уровень параллелизма (MAXDOP) или установив MAXDOP равным нулю, можно увеличить число активных потоков.

Разберите инцидент с недостаточным числом работников, следуя этим инструкциям:

  1. Исследуйте, происходит ли блокировка или вы можете определить большое количество одновременных рабочих процессов. Чтобы изучить текущие запросы и проверить, нет ли блокировки, когда из базы данных поступает сообщение об ошибке 10928, выполните следующий запрос. Для выполнения запроса может потребоваться подключиться к выделенному подключению администратора (DAC ).

    SELECT
    r.session_id, r.request_id, r.blocking_session_id, r.start_time, 
    r.status, r.command, DB_NAME(r.database_id) AS database_name,
    (SELECT COUNT(*) 
        FROM sys.dm_os_tasks AS t 
        WHERE t.session_id=r.session_id and t.request_id=r.request_id) AS worker_count,
    i.parameters, i.event_info AS input_buffer,
    r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
    r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
FROM sys.dm_exec_requests as r
JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
WHERE s.is_user_process=1;
GO

    1. Выполните поиск строк с blocking_session_id, чтобы определить заблокированные сеансы. Найдите каждый blocking_session_id в списке, чтобы определить, заблокирован ли также этот сеанс. Следуя значениям blocking_session_id и session_id, вы в конечном итоге приведете к главному блокирующему элементу: сеансу, который не заблокирован, но блокирует. Настройка запроса главного блокировщика.

      Совет

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

    2. Чтобы выявить большое количество одновременно используемых рабочих ролей, просмотрите общее количество запросов и столбец worker_count для каждого запроса. Worker_count — это количество рабочих на момент выборки и может изменяться по мере выполнения запроса. Настройте запросы, чтобы уменьшить показатель использования ресурсов, если причина увеличения количества рабочих ролей заключается в параллельных запросах, которые работают на оптимальном уровне параллелизма. Дополнительные сведения см. в разделе Настройка запросов и указания на них.

  2. Оцените максимальную степень параллелизма (MAXDOP) для базы данных.

Увеличение лимитов рабочих.

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

Узнайте пределы ресурсов для База данных SQL Azure в зависимости от уровня службы и вычислительных ресурсов.

Узнайте больше о регулировании ресурсов рабочих процессов в База данных SQL Azure.

Ошибка 10929: идентификатор ресурса: 1

10929: Resource ID: 1. The %s minimum guarantee is %d, maximum limit is %d and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database. See http://go.microsoft.com/fwlink/?LinkId=267637 for assistance. Otherwise, please try again later.

Ошибка 40501: служба сейчас перегружена

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.

Ошибка 40501 — это ошибка регулирования двигателя, указывающая на превышение пределов ресурсов.

Дополнительные сведения об ограничениях ресурсов см. в разделе "Управление ресурсами" в База данных SQL Azure.

Ошибка 40544: база данных достигла предельного размера

40544: The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Incident ID: <ID>. Code: <code>.

Эта ошибка возникает в тех случаях, когда база данных достигает предельного размера.

Следующие инструкции помогут вам решить эту проблему или получить больше возможностей:

  1. Проверьте текущий размер базы данных с помощью панели мониторинга на портале Azure.

    Примечание.

    Чтобы узнать, какие таблицы потребляют наибольшее пространство, и, следовательно, являются потенциальными претендентами на очистку, отправьте следующий SQL-запрос:

    SELECT o.name,
 SUM(p.row_count) AS 'Row Count',
 SUM(p.reserved_page_count) * 8.0 / 1024 AS 'Table Size (MB)'
FROM sys.objects o
JOIN sys.dm_db_partition_stats p on p.object_id = o.object_id
GROUP BY o.name
ORDER BY [Table Size (MB)] DESC;
GO

  2. Если текущий размер не превышает максимальный размер, поддерживаемый для выпуска, можно использовать ALTER DATABASE для увеличения параметра MAXSIZE.

  3. Если размер базы данных уже превышает максимальный поддерживаемый выпуском размер, попробуйте выполнить одно или несколько из следующих действий:

    • Выполните обычные действия по очистке базы данных. Например, можно очистить ненужные данные с помощью обрезки/удаления, или перенести данные с помощью SQL Server Integration Services (SSIS) или утилиты массового копирования (bcp).
    • Разделите или удалите данные, удалите индексы или просмотрите документацию, чтобы найти возможные решения проблемы.
    • Сведения о масштабирования баз данных см. в статье Масштабирование ресурсов отдельной базы данных и Масштабирование ресурсов эластичного пула.

Ошибка 40549: сеанс завершен по причине долго выполняющейся транзакции

40549: Session is terminated because you have a long-running transaction. Try shortening your transaction.

Если эта ошибка повторяется, попробуйте устранить проблему, выполнив описанные ниже действия.

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

    SELECT
    r.start_time, DATEDIFF(ms,start_time, SYSDATETIME()) as duration_ms, 
    r.session_id, r.request_id, r.blocking_session_id,  
    r.status, r.command, DB_NAME(r.database_id) AS database_name,
    i.parameters, i.event_info AS input_buffer,
    r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
    r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
FROM sys.dm_exec_requests as r
JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
WHERE s.is_user_process=1
ORDER BY start_time ASC;
GO

    Можно игнорировать строки, в которых в столбце input_buffer отображается запрос, который считывает из sys.fn_MSxe_read_event_stream: эти запросы связаны с сеансами расширенных событий.

  2. Просмотрите столбец blocking_session_id, чтобы узнать, влияет ли блокировка на долгосрочные транзакции.

    Примечание.

    Дополнительные сведения об устранении неполадок при блокировке в базе данных SQL Azure см. в статье "Общие сведения о блокировке и устранении проблем".

  3. Кроме того, рекомендуем выполнить пакетную обработку запросов. Сведения о пакетной обработке см. в статье "Как использовать пакетную обработку для улучшения производительности База данных SQL Azure и Управляемый экземпляр SQL Azure приложений".

Ошибка 40551: сеанс был завершен из-за чрезмерного использования tempdb

40551: The session has been terminated because of excessive TEMPDB usage. Try modifying your query to reduce the temporary table space usage.

Чтобы обойти эту проблему, выполните указанные ниже действия.

  1. Измените запросы, чтобы уменьшить использование временного пространства таблицы.
  2. Удалите временные объекты, которые вам уже не нужны.
  3. Выполните усечение таблиц или удалите неиспользуемые таблицы.

Ошибка 40552: сеанс был завершен в связи с чрезмерным использованием объема журнала транзакций

40552: The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

Устранить эту проблему можно с помощью следующих методов.

Ошибка 40553: сеанс был завершен в связи с чрезмерным использованием памяти

40553: The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows.

Чтобы устранить эту проблему, попробуйте оптимизировать запрос.

Подробные сведения об устранении неполадок см. в статье "Мой запрос работает хорошо" в облаке?

Дополнительные сведения о других ошибках, связанных с нехваткой памяти, и примеры запросов об ошибке в памяти см. в Устранение ошибок нехватки памяти в базе данных Azure SQL.

Таблица сообщений об ошибках управления ресурсами

Код ошибки Уровень серьезности Описание
10928 20 Resource ID: %d. The %s limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

Идентификатор ресурса указывает ресурс, который достиг предела. Если идентификатор ресурса = 1, это означает, что достигнут лимит работников. Дополнительные сведения см. в разделе Ошибка 10928: идентификатор ресурса: 1. Предел запросов для базы данных составляет %d, и он достигнут. Если идентификатор ресурса 2, значит, достигнуто ограничение количества сеансов.
Дополнительные сведения об ограничениях ресурсов:
• Управление ресурсами в База данных SQL Azure.
• Ограничения ресурсов для модели покупок DTU.
• ограничения на основе виртуальных ядер для отдельных баз данных.
• Ограничения ресурсов Управляемого экземпляра SQL Azure.
10936 20 Resource ID: %d. The %s limit for the elastic pool is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

Идентификатор ресурса указывает ресурс, который достиг предела. Если идентификатор ресурса = 1, это означает, что достигнут лимит работников. Дополнительные сведения об ошибке 10936: идентификатор ресурса: 1. Ограничение запроса для эластичного пула равно %d и достигнуто. Если идентификатор ресурса = 2, это означает, что достигнуто ограничение сеанса.
Дополнительные сведения об ограничениях ресурсов:
• Управление ресурсами в База данных SQL Azure.
• Ограничения ресурсов для эластичных пулов, использующих модель покупок DTU.
• Ограничения на основе виртуального ядра для эластичных пулов.
• Ограничения ресурсов Управляемого экземпляра SQL Azure.
10929 20 Resource ID: %d. The %s minimum guarantee is %d, maximum limit is %d, and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database.

Идентификатор ресурса указывает ресурс, который достиг предела. Для рабочих потоков идентификатор ресурса = 1. Для сеансов идентификатор ресурса — 2. Для получения дополнительной информации см.
• Управление ресурсами в База данных SQL Azure.
• Ограничения ресурсов для эластичных пулов при использовании модели приобретения DTU.
• ограничения на основе виртуальных ядер для отдельных баз данных.
• Ограничения на основе виртуального ядра для пулов эластичных баз данных.
• Ограничения ресурсов Управляемого экземпляра SQL Azure.
В противном случае повторите попытку.
40544 20 The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions.

Сведения о масштабирования баз данных см. в статье Масштабирование ресурсов отдельной базы данных и Масштабирование ресурсов эластичного пула.
40549 16 Session is terminated because you have a long-running transaction. Try shortening your transaction.

Сведения о пакетной обработке см. в статье "Как использовать пакетную обработку для повышения производительности приложений Базы данных Azure SQL и Управляемого экземпляра Azure SQL".
40550 16 The session has been terminated because it has acquired too many locks. Try reading or modifying fewer rows in a single transaction.

Сведения о пакетировании см. в статье "Как использовать пакетирование для улучшения производительности приложений в База данных SQL Azure и Управляемый экземпляр SQL Azure".
40551 16 The session has been terminated because of excessive tempdb usage. Try modifying your query to reduce the temporary table space usage.

Если вы используете временные объекты, то для экономии места в базе данных tempdb удаляйте их сразу после того, как в них исчезнет необходимость. Дополнительные сведения об ограничениях в tempdb базе данных SQL см. в базе данных Tempdb в базе данных SQL.
40552 16 The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

Сведения о пакетной обработке см. в статье "Как использовать пакетную обработку для улучшения производительности приложений База данных SQL в Azure и Управляемый экземпляр SQL в Azure".
В случае выполнения массовых вставок с использованием служебной программы bcp.exe или класса System.Data.SqlClient.SqlBulkCopy попробуйте ограничить количество строк, копируемых на сервер при каждой транзакции, с помощью параметра -b batchsize или BatchSize. В случае перестройки индекса с помощью оператора ALTER INDEX попробуйте использовать параметр REBUILD WITH ONLINE = ON. Сведения о размерах журналов транзакций для модели приобретения виртуальных ядер см. в следующей статье.
• ограничения на основе vCore для отдельных баз данных.
• Ограничения на основе виртуального ядра для эластичных пулов.
• Ограничения ресурсов Управляемого экземпляра SQL Azure.
40553 16 The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows.

Сокращение количества операций ORDER BY и GROUP BY в коде Transact-SQL позволяет уменьшить потребление памяти при выполнении запроса. Сведения о масштабирования баз данных см. в статье Масштабирование ресурсов отдельной базы данных и Масштабирование ресурсов эластичного пула. Дополнительные сведения об ошибках, связанных с нехваткой памяти, и примеры запросов об ошибке в памяти см. в Устранение ошибок нехватки памяти в базе данных Azure SQL.

Ошибки эластичного пула

Приведенные ниже ошибки связаны с созданием и использованием эластичных пулов.

Код ошибки Серьезность Описание Корректирующее действие
1132 17 The elastic pool has reached its storage limit. The storage usage for the elastic pool cannot exceed (%d) MBs.

Попытка записать данные в базу данных при достижении ограничения хранилища эластичного пула . Дополнительные сведения об ограничениях ресурсов см. в статье:
• Ограничения ресурсов для эластичных пулов при использовании модели приобретения DTU.
• Ограничения на основе виртуального ядра для эластичных пулов.
 Если это возможно, попробуйте увеличить DTU эластичного пула и (или) добавить в него пространство хранения для увеличения предельного размера его хранилища, сократить объем памяти, используемой отдельными базами данных в эластичном пуле, или удалить базы данных из пула. Сведения о масштабировании эластичных пулов см. в статье Масштабирование ресурсов эластичного пула. Дополнительные сведения об удалении неиспользуемого пространства из баз данных см. в статье Управление пространством для баз данных в Базе данных SQL Azure.
10929 16 The %s minimum guarantee is %d, maximum limit is %d, and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database.

Дополнительные сведения об ограничениях ресурсов см. в статье:
• Ограничения ресурсов DTU для эластичных пулов.
• Пределы на основе vCore для эластичных пулов.
В противном случае повторите попытку. Минимальное количество DTU / виртуальных ядер на одну базу данных; максимальное количество DTU / виртуальных ядер на одну базу данных. Общее количество одновременных рабочих процессов на всех базах данных в эластичном пуле попыталось превысить лимит пула.		 Если это возможно, попробуйте увеличить DTU или число виртуальных ядер эластичного пула для увеличения предельно допустимого количества работников или удалить базы данных из эластичного пула.
40844 16 Database '%ls' on Server '%ls' is a '%ls' edition database in an elastic pool and cannot have a continuous copy relationship. Н/П
40857 16 Elastic pool not found for server: '%ls', elastic pool name: '%ls'. Specified elastic pool does not exist in the specified server. Укажите допустимое имя эластичного пула.
40858 16 Elastic pool '%ls' already exists in server: '%ls'. Specified elastic pool already exists in the specified server. Укажите новое имя эластичного пула.
40859 16 Elastic pool does not support service tier '%ls'. Specified service tier is not supported for elastic pool provisioning. Укажите правильный выпуск или оставьте значение уровня служб пустым, чтобы использовать значение по умолчанию.
40860 16 Elastic pool '%ls' and service objective '%ls' combination is invalid. Elastic pool and service tier can be specified together only if resource type is specified as 'ElasticPool'. Укажите правильную комбинацию эластичного пула и уровня служб.
40861 16 The database edition '%.*ls' cannot be different than the elastic pool service tier which is '%.*ls'. The database edition is different than the elastic pool service tier. Не указывайте выпуск базы данных, который отличается от уровня служб эластичного пула. Не нужно указывать выпуск базы данных.
40862 16 Elastic pool name must be specified if the elastic pool service objective is specified. Elastic pool service objective does not uniquely identify an elastic pool. Если используется объект службы эластичного пула, укажите имя эластичного пула.
40864 16 The DTUs for the elastic pool must be at least (%d) DTUs for service tier '%.*ls'. Attempting to set the DTUs for the elastic pool below the minimum limit. Повторите попытку, установив для эластичного пула DTU, значение которого хотя бы равно минимальному ограничению.
40865 16 The DTUs for the elastic pool cannot exceed (%d) DTUs for service tier '%.*ls'. Attempting to set the DTUs for the elastic pool above the maximum limit. Повторите попытку, установив для эластичного пула DTU не превышающее максимальное ограничение.
40867 16 The DTU max per database must be at least (%d) for service tier '%.*ls'. Attempting to set the DTU max per database below the supported limit. Попробуйте использовать уровень служб эластичного пула, который поддерживает желаемый параметр.
40868 16 The DTU max per database cannot exceed (%d) for service tier '%.*ls'. Attempting to set the DTU max per database beyond the supported limit. Попробуйте использовать уровень служб эластичного пула, который поддерживает желаемый параметр.
40870 16 The DTU min per database cannot exceed (%d) for service tier '%.*ls'. Attempting to set the DTU min per database beyond the supported limit. Попробуйте использовать уровень служб эластичного пула, который поддерживает желаемый параметр.
40873 16 The number of databases (%d) and DTU min per database (%d) cannot exceed the DTUs of the elastic pool (%d). Attempting to specify DTU min for databases in the elastic pool that exceeds the DTUs of the elastic pool. Попробуйте увеличить количество DTU эластичного пула, уменьшить минимальное количество DTU на каждую базу данных или уменьшить количество баз данных в эластичном пуле.
40877 16 An elastic pool cannot be deleted unless it does not contain any databases. The elastic pool contains one or more databases and therefore cannot be deleted. Чтобы удалить эластичный пул, удалите из него базы данных.
40881 16 The elastic pool '%.*ls' has reached its database count limit. The database count limit for the elastic pool cannot exceed (%d) for an elastic pool with (%d) DTUs. Attempting to create or add database to elastic pool when the database count limit of the elastic pool has been reached. Если это возможно, попробуйте увеличить DTU эластичного пула, чтобы увеличить предельное количество баз данных, или удалить базы данных из эластичного пула.
40889 16 The DTUs or storage limit for the elastic pool '%.*ls' cannot be decreased since that would not provide sufficient storage space for its databases. Attempting to decrease the storage limit of the elastic pool below its storage usage. Попробуйте уменьшить использование хранилища отдельными базами данных в эластичном пуле или удалить базы данных из пула, чтобы снизить количество DTU или предел хранилища.
40891 16 The DTU min per database (%d) cannot exceed the DTU max per database (%d). Attempting to set the DTU min per database higher than the DTU max per database. Убедитесь, что минимальное число DTU на базу данных не превышает максимального числа DTU на базу данных.
TBD 16 The storage size for an individual database in an elastic pool cannot exceed the max size allowed by '%.*ls' service tier elastic pool. The max size for the database exceeds the max size allowed by the elastic pool service tier. Укажите максимальный размер базы данных, который находится в пределах ограничений на максимальный размер, допустимый уровнем служб эластичного пула.

Не удается открыть базу данных "master", запрошенную при входе в систему. Не удалось выполнить вход

Эта проблема возникает из-за того, что учетная запись не имеет разрешения на доступ к базе данных master. Но по умолчанию SQL Server Management Studio (SSMS) пытается подключиться к базе данных master.

Проблему можно устранить следующим способом.

  1. На экране входа SSMS выберите Параметры, а затем — Свойства подключения.

  2. В поле Подключение к базе данных введите имя базы данных пользователя по умолчанию в качестве базы данных для входа по умолчанию, а затем выберите Подключить.

    Снимок экрана: диалоговое окно

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

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

Ошибка 3906: не удалось обновить базу данных databaseName, так как база данных доступна только для чтения.

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

Msg 3906, Level 16, State 2, Line 1
Failed to update database "%d" because the database is read-only.

Существует несколько возможных объяснений, почему база данных доступна только для чтения.

После отказа вручную приложения по-прежнему подключаются к старой реплике.

В базе данных Azure SQL после переключения на другую реплику приложение может по-прежнему подключаться к предыдущей первичной реплике из-за DNS. Маршрутизация группы резервирования реализуется с помощью DNS.

Потенциальные первопричины:

  1. Во время отработки отказа конечные точки группы отработки отказа обновляются, чтобы указать на соответствующие новые первичные и новые вторичные серверы, изменив целевой объект соответствующей записи DNS. По умолчанию записи DNS создаются с TTL 30 секунд, что означает, что клиенты DNS кэшируют эти записи в течение 30 секунд. В результате обновления записей DNS не распространяются немедленно; записи будут устаревшими, пока все клиенты и промежуточные узлы не обновили свои кэши. Таким образом, оно может занять от 0 до примерно 10 минут (в зависимости от сетевой топологии) для входа в конечные точки группы отработки отказа, которые будут перенаправлены на новые целевые объекты после отработки отказа. Очистка кэшей DNS может или не может помочь в этой проблеме, так как промежуточные сетевые узлы, реагирующие на DNS-запросы, также кэшируют результаты DNS в течение некоторого времени.

    Рекомендуемое решение этой проблемы — просто ждать, пока записи DNS будут обновлены на клиенте. В настоящее время это решение приведет к решению проблемы в течение 10 минут.

  2. Некоторые клиентские библиотеки SQL используют функцию "пул соединений", которая повторно использует подключения к одному источнику данных, а не закрывает и повторно открывает их при необходимости подключения к базе данных. В частности, пул подключений включен в ADO.NET по умолчанию. В сочетании с проблемой, описанной в 1), пул подключений может привести к повторному использованию подключения к старой базе данных, что не позволяет приложению подключаться к новой основной базе данных бесконечно.

Решения:

Существует три возможных обходных решения этой проблемы DNS после переключения группы отказа:

  1. Измените приложение для вызова SQLConnection.ClearAllPools или SQLConnection.ClearPool(conn) при возникновении ошибки "только для чтения".
  2. В строке подключения приложения укажите Pooling=False, чтобы отключить пул подключений. Это должно быть проверено, так как это может значительно повлиять на производительность, если приложение открывает и закрывает подключения часто.
  3. Другой вариант, чтобы избежать задержек репликации и кэширования DNS, — это напрямую подключиться, используя имя логического сервера базы данных Azure SQL (исходного вторичного сервера, который стал новым основным) на определенный период времени после возникновения события или ошибки 3906.

Возможно, вы подключены к реплике только для чтения

Для базы данных SQL Azure и управляемого экземпляра SQL Azure вы можете подключиться к базе данных в реплике с доступом только для чтения. В этом случае следующий запрос с помощью функции DATABASEPROPERTYEX() возвращает READ_ONLY:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');
GO

Если вы подключаетесь с помощью SQL Server Management Studio, убедитесь, что вы указали ApplicationIntent=ReadOnly на вкладке "Дополнительные параметрыподключения" в параметрах подключения.

Если подключение устанавливается из приложения или клиента с использованием строки подключения, проверьте, указано ли значение ApplicationIntent=ReadOnly в строке подключения. Дополнительные сведения см. в разделе Подключение к реплике, доступной только для чтения.

База данных может быть задана только для чтения.

Если вы используете База данных SQL Azure, возможно, сама база данных была настроена только для чтения. Состояние базы данных можно проверить с помощью следующего запроса:

SELECT name, is_read_only
FROM sys.databases
WHERE database_id = DB_ID();

Вы можете изменить состояние базы данных, доступной только для чтения, в Базе данных SQL Azure с помощью инструкции ALTER DATABASE Transact-SQL. В настоящее время невозможно задать базу данных в управляемом экземпляре только для чтения.

Проверьте, вызвана ли ошибка проблемой подключения.

Чтобы проверить, вызвана ли ошибка проблемой подключения, просмотрите трассировку стека для фреймов, показывающих вызовы, чтобы открыть подключение, как показано ниже (обратите внимание на ссылку на класс SqlConnection):

System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
 at System.Data.SqlClient.SqlConnection.Open()
 at AzureConnectionTest.Program.Main(String[] args)
ClientConnectionId:<Client connection ID>

Если исключение срабатывает из-за проблем с запросами, вы увидите стек вызовов, аналогичный приведенному ниже (обратите внимание на ссылку на класс SqlCommand). В этом случае выполните настройку запросов.

  at System.Data.SqlClient.SqlCommand.ExecuteReader()
  at AzureConnectionTest.Program.Main(String[] args)
  ClientConnectionId:<Client ID>

Дополнительные сведения о точной настройке производительности см. в следующем разделе:

Связанный контент

  • Last updated on