Известные проблемы с Управляемым экземпляром SQL Azure
Область применения:
Управляемый экземпляр SQL Azure
В этой статье перечислены имеющиеся в настоящее время проблемы с Управляемым экземпляром SQL Azure, а также дата их решения или возможные обходные пути. Дополнительные сведения об управляемом экземпляре SQL Azure см. в статье «Что такое управляемый экземпляр SQL Azure?» и «Новые возможности в управляемом экземпляре SQL Azure».
Примечание.
Microsoft Entra ID ранее был известен как Azure Active Directory (Azure AD).
Известные проблемы
Существует обходной путь
Ошибка 8992 при запуске DBCC CHECKDB в базе данных SQL Server, созданной из Управляемого экземпляра SQL
При выполнении команды DBCC CHECKDB в базе данных SQL Server 2022 после удаления индекса или таблицы с индексом может возникнуть следующая ошибка, если база данных была получена из управляемого экземпляра SQL Azure, например, после восстановления файла резервного копирования или использования функции ссылок на управляемых экземплярах :
_Msg 8992, Level 16, State 1, Line <Line_Number>an
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes._
Чтобы обойти эту проблему, сначала удалите индекс или таблицу с индексом из исходной базы данных в Управляемом экземпляре SQL Azure, а затем восстановите базу данных с SQL Server 2022 еще раз. Если повторное создание базы данных из исходного управляемого экземпляра SQL Azure невозможно, обратитесь в службу поддержки Майкрософт, чтобы устранить эту проблему.
Список долгосрочных резервных копий в портале Azure отображает файлы резервных копий для активных и удалённых баз данных с тем же именем.
Долгосрочные резервные копии можно перечислить и управлять ими на странице портала Azure для управляемого экземпляра Azure SQL на вкладке "Резервные копии". На странице перечислены активные или удаленные базы данных, основные сведения об их долгосрочных резервных копиях и ссылка на управление резервными копиями. При выборе ссылки "Управление" откроется новая боковая область со списком резервных копий. Из-за проблемы с логикой фильтрации список отображает резервные копии для активной базы данных и удаленных баз данных с одинаковым именем. Это требует особого внимания при выборе резервных копий для удаления, чтобы избежать удаления резервных копий для неправильной базы данных.
Обходное решение. Используйте отображаемые сведения о времени резервного копирования (UTC) в списке, чтобы отличить резервные копии, принадлежащие базам данных с тем же именем, что и в экземпляре в разные периоды. Кроме того, используйте команды PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup и Remove-AzSqlInstanceDatabaseLongTermRetentionBackup или CLI команды az sql midb ltr-backup list и az sql midb ltr-backup delete для управления долгосрочными резервными копиями с помощью параметра DatabaseState и DatabaseDeletionTime возвращаемого значения для фильтрации резервных копий для базы данных.
Целевой объект event_file для сеанса событий system_health недоступен.
При попытке прочитать содержимое целевого объекта event_file сеанса события system_health, возникает ошибка 40538: "Допустимый URL, начинающийся с 'https://', требуется в качестве значения для любого указанного файлового пути". Это происходит в SQL Server Management Studio или при чтении данных сеанса с помощью функции sys.fn_xe_file_target_read_file.
Это изменение поведения является непредвиденным следствием недавнего необходимого исправления безопасности. Мы исследуем возможность дополнительного изменения, которое позволит клиентам безопасно продолжать использовать сеанс в Управляемом экземпляре SQL Azure. В то же время клиенты могут обойти эту проблему, создав собственный эквивалент сеанса system_health с целевым event_file объектом в хранилище BLOB-объектов Azure. Дополнительные сведения, включая скрипт T-SQL для создания system_health сеанса, который можно изменить для создания собственного эквивалента system_health, см. в разделе «Использование сеанса system_health».
Процедура sp_send_dbmail может завершиться ошибкой, если параметр @query
Процедура sp_send_dbmail может завершиться ошибкой, когда используется параметр @query. Сбои происходят, когда хранимая процедура выполняется в учетной записи sysadmin.
Эта проблема вызвана известной ошибкой, связанной с тем, как sp_send_dbmail использует олицетворение.
Обходное решение: Убедитесь, что вы выполняете вызов sp_send_dbmail под соответствующей пользовательской учетной записью, которую вы создали, а не под учетной записью sysadmin.
Ниже приведен пример создания выделенной учетной записи и изменения существующих объектов, отправляющих электронную почту.sp_send_dbmail
USE [msdb]
GO
-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name]
GO
EXEC msdb.dbo.sp_update_jobstep @job_name=N'db_mail_sending_job', @step_id=db_mail_sending_job_id , @database_user_name=N'user_name'
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name]
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXEC msdb.dbo.sp_update_jobstep @job_name=N'db_mail_sending_job', @step_id=db_mail_sending_job_id , @database_name=N'msdb'
GO
-- Step 4: Set a principal in the email profile
EXEC msdb.dbo.sysmail_add_principalprofile_sp @principal_name=N'user_name', @profile_name=N'profile_name', @is_default=0
GO
Промежуточное руководство по обновлениям часового пояса 2022 года для Чили
8 августа 2022 года чилийское правительство сделало официальное объявление об изменении часового пояса дневного времени (DST). Начиная с 12:00 в субботу, 10 сентября 2022 года, до 12:00 в субботу, 1 апреля 2023 года, официальное время будет продвигаться 60 минут. Это изменение влияет на следующие три часовых пояса: Тихоокеанское стандартное время Южной Америки, Стандартное время Острова Пасхи и Стандартное время Магаллана. Управляемые экземпляры SQL Azure, использующие затронутые часовые пояса, не будут отражать изменения
Обходное решение. Если необходимо изменить затронутые часовые пояса для управляемых экземпляров, помните об ограничениях и следуйте инструкциям из документации.
Изменение типа соединения не влияет на подключения через конечную точку группы отказоустойчивости
Если экземпляр участвует в группе отказоустойчивости, изменение типа подключения экземпляра не действует для подключений, установленных через прослушиватель точки подключения группы отказоустойчивости.
Обходное решение: После изменения типа подключения удалите и заново создайте группу отказоустойчивости.
Процедура sp_send_dbmail может временно завершиться ошибкой при использовании параметра @query.
Процедура sp_send_dbmail может временно давать сбой при использовании параметра @query. При возникновении этой проблемы каждое второе выполнение процедуры sp_send_dbmail завершается ошибкой Msg 22050, Level 16, State 1 и сообщением Failed to initialize sqlcmd library with error number -2147467259. Чтобы правильно увидеть эту ошибку, необходимо вызвать процедуру со значением по умолчанию 0 для параметра @exclude_query_output, в противном случае ошибка не распространяется.
Эта проблема вызвана известной ошибкой, связанной с тем, как в sp_send_dbmail используется олицетворение и создание пула подключений.
Чтобы обойти эту ошибку, добавьте в код для отправки сообщений электронной почты логику повторных попыток, зависящую от параметра вывода @mailitem_id. Если выполнение завершается сбоем, значение параметра равно NULL, что указывает на необходимость снова вызвать sp_send_dbmail, чтобы успешно отправить электронное письмо. Ниже приведен пример этой логики повторных попыток:
CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
DECLARE @miid INT
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
@mailitem_id = @miid OUTPUT
-- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
--
IF (@miid is NULL)
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END
Распределенные транзакции можно выполнять после удаления Управляемого экземпляра Базы данных SQL Azure из группы доверия сервера
Группы доверия сервера используются для установления отношений доверия между управляемыми экземплярами. Это предварительное требование для выполнения распределенных транзакций. После удаления Управляемого экземпляра Базы данных SQL Azure из группы доверия сервера или удаления группы распределенные транзакции по-прежнему можно выполнять. Существует обходное решение, которое можно применить, чтобы убедиться, что распределенные транзакции отключены, и это выполняется вручную пользователем переключение на управляемом экземпляре.
Распределенные транзакции не могут выполняться после операции масштабирования управляемой базы данных
Операции масштабирования Управляемого экземпляра Базы данных SQL Azure, включающие изменение уровня служб или количества виртуальных ядер, сбросят параметры группы доверия сервера в серверной части и запретят выполнение распределенных транзакций. Обходное решение состоит в удалении и создании новой группы доверия сервера на портале Microsoft Azure.
Не удается создать Управляемый экземпляр SQL с тем же именем, что и ранее удаленный логический сервер
Запись DNS <name>.database.windows.com создается при создании логического сервера в Azure для базы данных SQL Azure, а также при создании управляемого экземпляра SQL. Имя записи DNS должно быть уникальным. Таким образом, если вы создадите логический сервер для База данных SQL, а затем удалите его, пороговый период составляет семь дней до освобождения имени из записей. В этом периоде невозможно создать Управляемый экземпляр SQL с тем же именем, что и удаленный логический сервер. В качестве обходного решения используйте другое имя Управляемого экземпляра SQL или создайте запрос в службу поддержки для освобождения логического имени сервера.
Субъект-служба не может получить доступ к идентификатору Microsoft Entra ID и AKV
В некоторых случаях может возникнуть проблема с учетной записью службы, используемой для доступа к идентификатору Microsoft Entra ID (ранее Azure Active Directory) и службам Azure Key Vault (AKV). В результате эта проблема влияет на использование прозрачного шифрования данных (TDE) и аутентификации Microsoft Entra с управляемым экземпляром SQL. Может возникать проблема периодического подключения или невозможность выполнения таких инструкций, как CREATE LOGIN/USER FROM EXTERNAL PROVIDER или EXECUTE AS LOGIN/USER. Настройка TDE с использованием ключа, управляемого клиентом, на новом Управляемом экземпляре SQL Azure в некоторых случаях также может не работать.
Обходной метод: Чтобы предотвратить возникновение этой проблемы на вашем управляемом экземпляре SQL, перед выполнением любых команд обновления, или в случае, если вы уже столкнулись с этой проблемой после выполнения команд обновления, перейдите на страницу обзора вашего управляемого экземпляра SQL в портале Azure. В разделе «Параметры» выберите Microsoft Entra ID, чтобы получить доступ к странице администратора Управляемого экземпляра SQL Microsoft Entra ID. Проверьте, отображается ли сообщение об ошибке "Управляемому экземпляру требуется сервисный принципал для доступа к Microsoft Entra ID". Для создания учетной записи службы нажмите здесь. Если вы столкнулись с этим сообщением об ошибке, выберите его и следуйте пошаговые инструкции, предоставленные до устранения этой ошибки.
Ограничения на вручную выполняемое переключение при отказе через портал для групп переключения при отказе.
Если группа отказоустойчивости распространяется между экземплярами в разных подписках или группах ресурсов Azure, отработка отказа вручную не может быть инициирована из основного экземпляра в группе отказоустойчивости.
Обходное решение: инициируйте переключение на резерв через портал из гео-вторичного экземпляра.
Ролям агента SQL требуются явные разрешения EXECUTE для учётных записей, не относящихся к администраторам системы.
Если имена входа, отличные от sysadmin, добавляются к любым предопределенным ролям базы данных агента SQL, существует проблема, в которой явные разрешения EXECUTE должны быть предоставлены трем хранимым процедурам в master базе данных для работы этих имен входа. Если эта проблема возникла, отображается сообщение The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) об ошибке.
Обходной путь. После добавления входа в предопределенную роль базы данных агента SQL (SQLAgentUserRole, SQLAgentReaderRole или SQLAgentOperatorRole) для каждого из входов, добавленных в эти роли, выполните следующий скрипт T-SQL, чтобы явно предоставить разрешения EXECUTE хранимым процедурам.
USE [master];
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];
Ограничения памяти для OLTP в оперативной памяти не применяются
Уровень служб критически важный для бизнеса не правильно применяет максимальные ограничения памяти для оптимизированных для памяти объектов в некоторых случаях. Управляемый экземпляр SQL может позволить рабочей нагрузке использовать больше памяти для операций OLTP в памяти, что может повлиять на доступность и стабильность экземпляра. Запросы OLTP, выполняемые в памяти, которые достигают ограничений, могут не завершаться сбоем сразу. Запросы, использующие больше памяти OLTP, завершаются сбоем раньше, если они достигают ограничений.
Обходной путь. Отслеживайте использование хранилища OLTP в памяти с помощью SQL Server Management Studio , чтобы убедиться, что рабочая нагрузка не использует больше доступной памяти. Увеличьте ограничения памяти, зависящие от числа виртуальных ядер, или оптимизируйте рабочую нагрузку для использования меньшего объема памяти.
Ошибка, возвращенная при попытке удалить файл, который не пуст
SQL Server и Управляемый экземпляр SQL не позволяют пользователю удалять файл, который не пуст. Если вы пытаетесь удалить непустой файл данных с помощью инструкции ALTER DATABASE REMOVE FILE, сообщение об ошибке Msg 5042 – The file '<file_name>' cannot be removed because it is not empty не возвращается немедленно. Управляемый экземпляр SQL будет пытаться удалить файл, и через 30 минут операция завершится с ошибкой Internal server error.
Изменение уровня обслуживания и создание экземпляров заблокированы текущим восстановлением базы данных.
Активный RESTORE оператор, процесс миграции Data Migration Service и встроенное восстановление до определенного момента времени блокируют обновление уровня службы, изменение размера существующего экземпляра и создание новых экземпляров до завершения процесса восстановления.
Процесс восстановления блокирует эти операции в управляемых экземплярах и пулах экземпляров в той же подсети, где выполняется процесс восстановления. Экземпляры в пулах экземпляров не затрагиваются. Операции создания или изменения уровня службы не завершаются ошибкой или тайм-аутом. Они продолжаются после успешного завершения или отмены процесса восстановления.
Возможное решение: дождитесь завершения процесса восстановления или отмените процесс восстановления, если операция создания или обновления уровня службы имеет более высокий приоритет.
Resource Governor на уровне обслуживания 'Business Critical' может потребовать перенастройки после переключения на резервный узел.
Функция Resource Governor, позволяющая ограничить ресурсы, назначенные пользовательской рабочей нагрузке, может неправильно классифицировать определенную рабочую нагрузку пользователя после переключения в случае сбоя или инициированного пользователем изменения уровня обслуживания (например, изменение максимального размера хранилища экземпляра или максимального количества виртуальных ядер).
Возможное решение: запускайте ALTER RESOURCE GOVERNOR RECONFIGURE периодически или в рамках задания Агента SQL, которое выполняет задачу SQL при запуске экземпляра, если используется Resource Governor.
После обновления уровня службы необходимо повторно инициализировать диалоговые окна Service Broker для нескольких баз данных
Диалоги Service Broker между базами данных прекратят доставлять сообщения службам в других базах данных после изменения уровня обслуживания. Сообщения не теряются, и их можно найти в очереди отправителей. Любое изменение числа виртуальных ядер или размера хранилища экземпляра в Управляемом экземпляре SQL приводит к изменению значения в представлении sys.databases для всех баз данных. Все DIALOG, созданные с помощью инструкции BEGIN DIALOG и ссылающиеся на сервера Service Broker в других базах данных, перестают доставлять сообщения в целевую службу.
Возможное решение: перед обновлением уровня службы и повторной инициализацией остановите все операции, использующие диалоговые окна Service Broker для нескольких баз данных. Если остались сообщения, не доставленные после изменения уровня службы, прочтите сообщения из очереди источника и повторно отправьте их в очередь цели.
Превышение пространства на диске из-за небольших файлов баз данных
Операторы CREATE DATABASE, ALTER DATABASE ADD FILE и RESTORE DATABASE могут завершиться ошибкой, так как экземпляр может достичь ограничения хранилища Azure.
Каждый экземпляр SQL Управляемой базы данных общего назначения имеет до 35 ТБ хранилища, зарезервированного для дискового пространства Azure Premium. Каждый файл базы данных размещается на отдельном физическом диске. Поддерживаются диски размером 128 ГБ, 256 ГБ, 512 ГБ, 1 ТБ или 4 ТБ. Неиспользуемое пространство на диске не оплачивается, но суммарный размер дисков Azure уровня "Премиум" не может превышать 35 ТБ. В некоторых случаях из-за внутренней фрагментации размер управляемого экземпляра, которому требуется не более 8 ТБ дискового пространства, может превысить ограничение в 35 ТБ.
Например, экземпляр общего назначения Управляемого экземпляра SQL может иметь один большой файл размером 1,2 ТБ, размещенный на диске объемом 4 ТБ. У него также может быть 248 файлов размером 1 ГБ, каждый из которых размещается на отдельных дисках емкостью 128 ГБ. В этом примере:
- общий размер выделенного дискового хранилища составляет 1 x 4 ТБ + 248 x 128 ГБ = 35 ТБ;
- общий объем зарезервированного пространства для баз данных в экземпляре составляет 1 x 1,2 ТБ + 248 x 1 ГБ = 1,4 ТБ.
В этом примере показано, что в определенных обстоятельствах из-за специфического распределения файлов экземпляр SQL Управляемая СУБД может достичь ограничения в 35 ТБ, зарезервированного для подключенного диска Azure Premium, даже если вы этого не ожидаете.
В этом примере существующие базы данных без проблем будут работать и разрастаться при условии, что в них не будут добавляться новые файлы. При этом создать новые базы данных или восстановить имеющиеся не удастся, так как для новых дисков места недостаточно, даже если общий размер всех баз данных не достигает предельного размера экземпляра. Сообщение об ошибке, поступающее в этом случае, неясно.
Можно узнать количество оставшихся файлов с помощью системных представлений. Если вы достигли этого лимита, попробуйте опустошить и удалить некоторые из файлов меньшего размера с помощью инструкции DBCC SHRINKFILE или переключиться на уровень "Критически важный для бизнеса", который не имеет этого лимита.
Значения GUID, отображаемые вместо имен баз данных
Несколько системных представлений, счетчиков производительности, сообщений об ошибках, XEvents и записей в журнале ошибок отображают идентификаторы базы данных GUID вместо фактических имен базы данных. Не полагаться на эти идентификаторы GUID, так как они могут быть заменены фактическими именами баз данных в будущем.
Обходное решение: Используйте представление sys.databases для определения фактического имени базы данных на основе физического имени базы данных, указанного в виде идентификаторов базы данных GUID.
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
Модули среды CLR и связанные серверы иногда не могут ссылаться на локальный IP-адрес
Модули CLR в Управляемом экземпляре SQL и связанные серверы или ссылающиеся на текущий экземпляр распределенные запросы иногда не могут разрешить IP-адрес локального экземпляра. Это временная ошибка.
Область транзакции между двумя базами данных в одном экземпляре не поддерживается.
(Решено в марте 2020 г.) Класс TransactionScope в .NET не работает, если два запроса отправляются двум базам данных из одного экземпляра в той же области транзакции:
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
Возможное решение (не требуется с марта 2020 г.): вместо двух подключений используйте SqlConnection.ChangeDatabase(String), чтобы подключиться к другой базе данных в том же контексте.
Нет решения
Разностные резервные копии не принимаются при связывании экземпляра с SQL Server
При настройке связи между SQL Server и управляемым экземпляром SQL Azure, автоматические полные резервные копии и копии журналов транзакций выполняются на управляемом экземпляре, независимо от того, находится ли он в основной роли. Однако дифференциальные резервные копии в настоящее время не создаются, что может привести к более длительному времени восстановления.
Увеличение количества системных имен входа, используемых для репликации транзакций
Служба Управляемого экземпляра SQL Azure создает системный логин для целей репликации транзакций. Это имя входа можно найти в SSMS (в Формат имени входа выглядит следующим образом 'DBxCy\WF-abcde01234QWERT', а имя входа имеет роль общедоступного сервера. В определенных условиях этот логин воссоздается, и из-за сбоя в системе предыдущий логин не был удалён. Это может привести к увеличению числа входов. Эти имена входа не представляют угрозу безопасности. Их можно безопасно игнорировать. Эти имена входа не следует удалять, так как по крайней мере один из них используется для репликации транзакций.
Учетные записи и пользователи Microsoft Entra не поддерживаются в SSDT.
SQL Server Data Tools в полной мере не поддерживает имена входа и пользователей Microsoft Entra.
Имитация типов входа Microsoft Entra не поддерживается
Олицетворение с использованием EXECUTE AS USER или EXECUTE AS LOGIN следующих сущностей Microsoft Entra не поддерживается.
- Пользователи Microsoft Entra с псевдонимами. В этом случае возвращается ошибка
15517. - Имя входа и пользовательские учетные записи Microsoft Entra, основанные на приложениях Microsoft Entra или сервисных принципалах. В этом случае возвращаются ошибки
15517и15406.
Репликация транзакций должна быть перенастроена после геоотказа.
Если репликация транзакций включена в базе данных в группе аварийного переключения, администратор управляемого экземпляра SQL должен удалить все публикации на старом первичном сервере и перенастроить их на новый первичный после переключения на новый регион. Дополнительные сведения см. в разделе Репликация.
tempdb структура и содержимое создаются повторно
База tempdb данных всегда разделена на 12 файлов данных, а структура файлов не может быть изменена. Максимальный размер каждого файла нельзя изменить, и новые файлы добавить нельзя в tempdb. База данных tempdb всегда создается заново как пустая база данных при запуске или переключении на резерв экземпляра, и любые изменения, внесенные в tempdb, не сохраняются.
Журналы ошибок не сохраняются
Журналы ошибок, которые доступны в Управляемом экземпляре SQL, не сохраняются, и их размер не включается в максимальный размер хранилища. Журналы ошибок могут автоматически удаляться в случае отказоустойчивости. В журнале ошибок могут присутствовать пропуски, так как управляемый экземпляр SQL перемещался несколько раз по нескольким виртуальным машинам.
Временная недоступность экземпляра через прослушиватель группы отработки отказа во время операции масштабирования
Масштабирование управляемого экземпляра иногда требует перемещения экземпляра в другой виртуальный кластер, а также связанных записей DNS, поддерживаемых службой. Если управляемый экземпляр участвует в группе отказоустойчивости, запись DNS, соответствующая слушателю связанной группы отказоустойчивости (слушатель чтения-записи, если экземпляр является текущим гео-первичным, и слушатель только для чтения, если экземпляр является текущим гео-вторичным), перемещается в новый виртуальный кластер.
В текущей структуре операции масштабирования записи DNS прослушивателя удаляются из исходного виртуального кластера до полного переноса управляемого экземпляра в новый виртуальный кластер, который в некоторых ситуациях может привести к длительному времени, в течение которого IP-адрес экземпляра не может быть разрешен с помощью прослушивателя. Во время этого периода клиент SQL, пытающийся получить доступ к экземпляру, масштабируемого с помощью конечной точки прослушивателя, может столкнуться с отказами входа со следующим сообщением об ошибке: "Ошибка 40532: не удается открыть сервер "xxx.xxx.xxx.xxx", запрошенный в процессе входа. Не удалось выполнить вход. (Microsoft SQL Server, ошибка: 40532)".
Эта проблема будет устранена путем перепроектирования операций масштабирования.
Решено
Таблица для резервных копий вручную в msdb не сохраняет имя пользователя
(Разрешено в августе 2023 г.) Недавно мы ввели поддержку автоматического резервного копирования msdb, но таблица в настоящее время не содержит сведения о имени пользователя.
Запрос во внешней таблице завершается сбоем с сообщением об ошибке, которое не поддерживается
Запрос внешней таблицы может завершиться ошибкой с универсальным сообщением об ошибке "Запросы по внешним таблицам не поддерживаются с текущим уровнем служб или уровнем производительности этой базы данных. Рассмотрите возможность повышения уровня обслуживания или производительности базы данных. Единственным типом внешней таблицы, поддерживаемой в Управляемом экземпляре SQL Azure, являются внешние таблицы PolyBase (предоставляется в режиме предварительной версии). Чтобы разрешить запросы во внешних таблицах PolyBase, необходимо включить PolyBase в управляемом экземпляре, выполнив sp_configure команду.
Внешние таблицы, связанные с функцией эластичных запросов в базах данных SQL Azure, не поддерживаются в управляемом экземпляре SQL, но создание и выполнение запросов на них не были явно заблокированы. Вместе с поддержкой внешних таблиц PolyBase появились новые проверки, которые блокируют запросы любого типа к внешним таблицам в управляемом экземпляре, если не включена поддержка PolyBase.
Если вы используете неподдерживаемые внешние таблицы с функцией эластичных запросов для запроса данных в Базе данных SQL Azure или Azure Synapse из управляемого экземпляра, вместо этого следует использовать функцию связанного сервера. Чтобы установить подключение связанного сервера из управляемого экземпляра SQL к базе данных SQL, следуйте инструкциям из этой статьи. Чтобы установить подключение связанного сервера из Управляемого экземпляра SQL к SQL Synapse, следуйте пошаговым инструкциям. Так как настройка и тестирование подключения связанного сервера занимает некоторое время, можно в качестве временного решения применить обходной путь, позволяющий выполнять запросы к внешним таблицам, связанным с функцией запросов к эластичным базам данных.
Обходное решение: Выполните следующие команды (один раз на инстанцию), которые позволяют выполнять запросы на внешних таблицах.
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
При использовании проверки подлинности SQL Server имена пользователей с именем @не поддерживаются
Имена пользователей, содержащие символ @, в середине (например, 'abc@xy') не могут выполнять вход с помощью проверки подлинности SQL Server.
Восстановление резервного копирования вручную без контрольной суммы может завершиться ошибкой
(Устранено в июне 2020 г.) В определенных обстоятельствах ручное резервное копирование баз данных, выполненное в управляемом экземпляре без проверки контрольной суммы, может завершиться ошибкой. В подобных случаях следует повторять попытку восстановления резервной копии до тех пор, пока это не получится.
Обходное решение: выполняйте резервное копирование баз данных вручную на управляемом экземпляре с включенной CHECKSUM.
Агент перестает отвечать на запросы при изменении, отключении или включении существующих заданий
В определенных случаях изменение, отключение или включение существующего задания может привести к тому, что агент перестанет отвечать на запросы. Проблема автоматически устраняется при обнаружении, в результате чего происходит перезапуск процесса агента.
Разрешения для группы ресурсов не применяются к Управляемому экземпляру SQL
Если роль Azure "Участник Управляемого экземпляра" применяется к группе ресурсов (RG), к Управляемому экземпляру SQL она не применяется и не оказывает какого-либо воздействия.
Обходное решение: настройте роль участника Управляемого экземпляра SQL для пользователей на уровне подписки.
Задания Агента SQL могут быть прерваны перезапуском процесса агента
(Разрешено в марте 2020 г.) Агент SQL создает новый сеанс каждый раз, когда запускается задание, постепенно увеличивая потребление памяти. Чтобы избежать попадания в предел внутренней памяти, который будет блокировать выполнение запланированных заданий, процесс агента перезапускается после достижения порогового значения потребления памяти. Это может привести к прерыванию выполнения заданий, выполняемых в момент перезапуска.
Параметр @query не поддерживается в sp_send_db_mail
Параметр @query в процедуре sp_send_db_mail не работает.
Неверное сообщение об ошибке на портале Azure, вводящее в заблуждение предложение по повторному созданию главного компонента службы
Страница администратора Active Directory портала Azure для Azure SQL Управляемого экземпляра может отобразить следующее сообщение об ошибке, даже если принципал-служба уже существует.
Управляемому экземпляру необходим служебный принципал для доступа к Microsoft Entra ID (ранее Azure Active Directory). Щелкните здесь, чтобы создать учетную запись службы.
Это сообщение об ошибке можно игнорировать, если учетная запись службы для управляемого экземпляра уже существует или аутентификация Microsoft Entra в управляемом экземпляре работает.
Чтобы проверить наличие Управляемого Идентификатора, перейдите на страницу корпоративных приложений на портале Azure, выберите управляемые удостоверения из раскрывающегося списка типов приложения, выберите "Применить" и введите имя управляемого экземпляра в поле поиска. Если имя экземпляра присутствует в списке результатов, это означает, что главный компонент службы уже существует, и дальнейшие действия не требуются.
Если вы уже выполнили инструкции из сообщения об ошибке и перешли по ссылке из сообщения об ошибке, служебный принципал управляемого экземпляра был повторно создан. В этом случае назначьте разрешения на чтение Microsoft Entra ID только что созданному служебному принципалу, чтобы аутентификация с помощью Microsoft Entra работала правильно. Это можно сделать в Azure PowerShell с помощью этих инструкций.
Участие в разработке содержимого
Чтобы внести свой вклад в документацию Azure SQL, ознакомьтесь с руководством для участников.
Связанный контент
Список обновлений и улучшений Управляемого экземпляра SQL см. в разделе Обновления службы Управляемого экземпляра SQL.
Улучшения и обновления всех служб Azure см. в статье Обновления служб.