Известные проблемы с Управляемый экземпляр SQL Azure

Применимо к:Управляемый экземпляр SQL Azure

В этой статье перечислены известные проблемы с Управляемый экземпляр SQL Azure и датой их разрешения или возможным решением. Дополнительные сведения о Управляемый экземпляр SQL Azure см. в статьях Что такое Управляемый экземпляр SQL Azure? и Что нового в Управляемый экземпляр SQL Azure?

Известные проблемы

Существует обходной путь

Запросы связанного сервера, использующие MSDASQL, завершаются ошибкой 7416

Запросы к связанным серверам, использующие поставщик Microsoft OLE DB для ODBC (MSDASQL) и указывающие строку поставщика (@provstr), могут завершиться следующей ошибкой:

Msg 7416, Level 16
Access to the remote server is denied because no login-mapping exists.

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

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

Обходное решение. Используйте один из следующих вариантов:

• Удалите @provstr из определения связанного сервера, если конфигурация не требует его.

• Добавьте User ID=<value> в @provstr. Логин должен по-прежнему указывать UID в строке поставщика.

Предоставление затронутого имени входа sysadmin также предотвращает ошибку, но не рекомендуется.

Проблемы с выполнением операции восстановления после миграции в Управляемый экземпляр SQL

При переносе базы данных в Управляемый экземпляр SQL Azure из SQL Server 2019 и более поздних версий с ускоренным восстановлением базы данных, включенным, но настроенным в хранилище постоянных версий (PVS), установленном на значение, отличное от группы файлов PRIMARY, вы можете столкнуться с ошибками операций восстановления в целевом управляемом экземпляре SQL.

Чтобы обойти эту проблему, убедитесь, что хранилище версий persistent (PVS) задано как PRIMARY в исходной базе данных SQL Server перед переносом на Управляемый экземпляр SQL. Если база данных уже перенесена без настройки PVS для PRIMARY, ее можно задать в базе данных-источнике SQL Server, а затем повторно перенести базу данных в Управляемый экземпляр SQL.

Не удалось использовать ускоренное восстановление базы данных после миграции в Управляемый экземпляр SQL

Начиная с SQL Server 2019, если вы переносите базу данных в Управляемый экземпляр SQL Azure, и исходная база данных имеет отключенное ускоренное восстановление базы данных, невозможно использовать ускоренное восстановление базы данных на целевом управляемом экземпляре SQL Managed Instance.

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

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

Не удается использовать Service Broker после миграции в Управляемый экземпляр SQL

Если вы переносите базу данных в Управляемый экземпляр SQL Azure и Service Broker отключена в исходной базе данных, вы не можете использовать Компонент Service Broker в целевом управляемом экземпляре SQL.

Чтобы обойти эту проблему, убедитесь, что вы включите Service Broker в исходной базе данных SQL Server, прежде чем перенести ее в Управляемый экземпляр SQL. Если база данных уже перенесена без включения Service Broker, ее можно включить в исходной SQL Server базе данных, а затем повторно перенести базу данных в Управляемый экземпляр SQL.

Изменение срока хранения резервных копий для бесплатного предложения

Политику хранения резервных копий баз данных в управляемом экземпляре SQL можно изменить только с помощью REST API, PowerShell и команд Azure CLI. Политику хранения резервных копий нельзя изменить на портале Azure.

Ошибка входа в read-secondary из-за длительного ожидания на "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"

Эта ошибка может появиться в качестве исключения для драйвера Microsoft OLE DB Driver 19 для SQL Server при попытке подключиться к вторичной реплике failover group, доступной только для чтения, или базе данных, реплицированной через ссылку Управляемый экземпляр.

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

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

Ошибка 8992 при запуске DBCC CHECKDB в базе данных SQL Server, созданной из Управляемый экземпляр SQL

При выполнении команды DBCC CHECKDB в базе данных SQL Server 2022 после удаления индекса или таблицы с индексом, а база данных возникла из Управляемый экземпляр SQL Azure, например после восстановления файла резервной копии или функции ссылки Управляемый экземпляр SQL:

Msg 8992, Level 16, State 1, Line <Line_Number>
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 невозможно, обратитесь в службу поддержки Microsoft, чтобы устранить эту проблему.

Ошибка 1412 при создании ссылки Управляемый экземпляр

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

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

Если в журнале ошибок SQL Server Управляемый экземпляр SQL Azure отображается ошибка 1412, необходимо drop и повторно создать ссылку. Чтобы предотвратить эту проблему, приостанавливайте резервные копии журналов транзакций на начальном этапе заполнения. Если резервные копии журналов транзакций необходимы во время начального этапа заполнения, то начните открытую транзакцию, чтобы предотвратить усечение журнала. Дополнительные сведения см. в статье Error 1412 при создании ссылки Управляемый экземпляр в руководстве по устранению неполадок функции ссылки.

Список долгосрочных резервных копий на портале Azure отображает файлы резервных копий для активных и удаленных баз данных с тем же именем.

Долгосрочные резервные копии можно перечислить и управлять на странице портала Azure для Управляемый экземпляр SQL Azure на вкладке Backups. На странице перечислены активные или удаленные базы данных, основные сведения об их долгосрочных резервных копиях и ссылка на управление резервными копиями. При выборе ссылки "Управление" откроется новая боковая область со списком резервных копий. Из-за проблемы с логикой фильтрации список отображает резервные копии для активной базы данных и удаленных баз данных с одинаковым именем. Это требует особого внимания при выборе резервных копий для удаления, чтобы избежать удаления резервных копий для неправильной базы данных.

Обходное решение. Используйте отображаемые сведения о времени резервного копирования (UTC) в списке, чтобы отличить резервные копии, принадлежащие базам данных с тем же именем, что и в экземпляре в разные периоды. Кроме того, используйте команды PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup и Remove-AzSqlInstanceDatabaseLongTermRetentionBackup или команды CLI az sql midb ltr-backup list и az sql midb ltr-backup delete для управления долгосрочными резервными копиями, используя параметр DatabaseState и возвращаемое значение DatabaseDeletionTime для фильтрации резервных копий для базы данных.

Процедура sp_send_dbmail может завершиться ошибкой при использовании параметра @query

Процедура sp_send_dbmail может завершиться ошибкой, если используется параметр @query. Сбои происходят при выполнении хранимой процедуры в учетной записи sysadmin .

Эта проблема вызвана известной ошибкой, связанной с тем, как sp_send_dbmail использует имперсонацию.

Обходное решение: Убедитесь, что вы используете соответствующую пользовательскую учетную запись, которую вы создали, и не используете учетную запись sp_send_dbmail.

Вот пример, как создать выделенную учетную запись и изменить существующие объекты, отправляющие электронные письма через 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

EXECUTE 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.
EXECUTE 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
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
    @principal_name = N'user_name',
    @profile_name = N'profile_name',
    @is_default = 0;
GO

Распределенные транзакции можно выполнять после удаления управляемого экземпляра SQL из группы доверия сервера

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

Не удается создать Управляемый экземпляр SQL с тем же именем, что и ранее удаленный логический сервер

При создании логического сервера в Azure для База данных SQL Azure или Управляемый экземпляр SQL система создает запись DNS для <name>.database.windows.com. Эта запись DNS должна быть уникальной. Если создать логический сервер для базы данных SQL, а затем удалить его, имя остается зарезервированным в течение семи дней. В течение этого периода невозможно создать Управляемый экземпляр SQL с тем же именем, что и удаленный логический сервер. В качестве обходного решения используйте другое имя для Управляемый экземпляр SQL или создайте запрос в службу поддержки для освобождения имени логического сервера.

Служебный принципал не может получить доступ к Microsoft Entra ID и Azure Key Vault.

В некоторых случаях возникает проблема с учетной записью службы, используемой для доступа к Microsoft Entra ID (ранее Azure Active Directory) и Azure Key Vault (AKV). В результате эта проблема влияет на использование проверки подлинности Microsoft Entra и прозрачного шифрования данных (TDE) с Управляемый экземпляр SQL. Вы можете столкнуться с этой проблемой в качестве периодических проблем с подключением или не иметь возможности выполнять инструкции, такие CREATE LOGIN/USER FROM EXTERNAL PROVIDER или EXECUTE AS LOGIN/USER. Настройка TDE с помощью ключа, управляемого клиентом, на новом Управляемый экземпляр SQL Azure может также не работать в некоторых обстоятельствах.

Workaround. Чтобы предотвратить возникновение этой проблемы на Управляемый экземпляр SQL, перед выполнением каких-либо команд обновления или в случае, если вы уже столкнулись с этой проблемой после выполнения команд обновления, перейдите на страницу Overview SQL managed instance на портале Azure. В разделе Settings выберите Microsoft Entra ID для доступа к странице администрирования Управляемый экземпляр SQL Microsoft Entra ID. Найдите следующее сообщение об ошибке:

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

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

Ошибка, возвращенная при попытке удалить файл, который не пуст

SQL Server и Управляемый экземпляр SQL не позволяют пользователю удалять файл, если он не пуст. Если вы пытаетесь удалить непустой файл данных с помощью инструкции ALTER DATABASE REMOVE FILE, возникнет ошибка:

Msg 5042 - The file '<file_name>' cannot be removed because it is not empty` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `Internal server error.

Изменение уровня обслуживания и создание экземпляров заблокированы текущим восстановлением базы данных.

Текущая RESTORE инструкция, процесс миграции Data Migration Service и встроенное восстановление на определенный момент времени могут блокировать обновления на уровне служб или изменять размер существующего экземпляра и создавать новые экземпляры, пока процесс восстановления не завершится.

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

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

Диспетчеру ресурсов на читаемой вторичной реплике требуется перенастройка после переключения.

Функция регулятора ресурсов, которая позволяет ограничить ресурсы, назначенные пользователю, может неправильно классифицировать некоторые рабочие нагрузки пользователей после отказа или изменения уровня обслуживания, инициированного пользователем (например, изменение максимального размера виртуального ядра или максимального объема хранилища экземпляров).

Обходной путь. Периодически выполняйте ALTER RESOURCE GOVERNOR RECONFIGURE или в рамках задания агента SQL, выполняющего задачу SQL при запуске доступной для чтения вторичной реплики, если вы используете регулятор ресурсов.

Превышение пространства на диске из-за небольших файлов баз данных

CREATE DATABASE, ALTER DATABASE ADD FILE и инструкции RESTORE DATABASE могут завершиться ошибкой, так как экземпляр достигает ограничения служба хранилища Azure уровня служб общего назначения, но не нового уровня общего назначения или уровня служб «Критически важный для бизнеса».

Каждый экземпляр общего назначения Управляемый экземпляр SQL имеет до 35 ТБ хранилища, зарезервированного для Azure дискового пространства класса Premium. Каждый файл базы данных размещается на отдельном физическом диске. Поддерживаются диски размером 128 ГБ, 256 ГБ, 512 ГБ, 1 ТБ или 4 ТБ. Плата за неиспользуемое пространство на диске не взимается, но общая сумма Azure размеров дисков класса Premium не может превышать 35 ТБ. В некоторых случаях управляемый экземпляр SQL, которому не требуется 8 ТБ в общей сложности, может превысить лимит Azure на размер хранилища в 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-адрес локального экземпляра. Это временная ошибка.

Нет решения

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

При попытке подключиться к вторичной реплике экземпляра уровня "Критически важный для бизнеса" с помощью ApplicationIntent=ReadOnly и недопустимых учетных данных экземпляр сообщает об ошибке, указывающей, что master база данных доступна только для чтения. Экземпляр некорректно сообщает, что учетные данные недействительны.

Разностные резервные копии не принимаются, когда экземпляр связан с SQL Server

При настройке link между SQL Server и Управляемый экземпляр SQL Azure автоматические полные резервные копии журналов транзакций выполняются в управляемом экземпляре SQL, независимо от того, находится ли он в основной роли. Однако дифференциальные резервные копии в настоящее время не создаются, что может привести к более длительному времени восстановления.

Увеличение количества системных имен входа, используемых для репликации транзакций

Управляемый экземпляр SQL Azure служба создает системное имя входа для целей репликации транзакций. Это имя входа можно найти в SSMS (в обозреватель объектов>Security>Logins) или в системном представлении sys.syslogins. Формат имени входа выглядит следующим DBxCy\WF-abcde01234QWERTобразом, а имя входа имеет роль общедоступного сервера. При определенных условиях этот вход создается повторно и из-за внутренней проблемы предыдущий вход не удаляется. Эта ошибка может привести к увеличению количества входов. Эти имена входа не представляют угрозу безопасности, и их можно игнорировать. Не удаляйте эти имена входа, так как по крайней мере один из них используется для репликации транзакций.

В SSDT не поддерживаются учетные записи и пользователи Microsoft Entra.

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 должен очистить все публикации на старой основной базе данных и перенастроить эти публикации на новой основной базе данных после отработки отказа в другую область. Дополнительные сведения см. в разделе Репликация.

Журналы ошибок не сохраняются

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

Решено

Целевой объект event_file для сеанса событий system_health недоступен.

(Разрешено в марте 2026 г.) При попытке прочитать содержимое целевого event_filesystem_health сеанса событий вы получите ошибку 40538, "Допустимый URL-адрес, начинающийся с "https://", требуется в качестве значения для любого указанного файлового пути".

Эта проблема возникла в SQL Server Management Studio (SSMS) или при чтении данных сеанса с помощью функции sys.fn_xe_file_target_read_file. Проблема устранена в обоих случаях.

Это изменение поведения было непреднамеренное следствием необходимого исправления безопасности. Клиенты могут обойти эту проблему, создав собственный эквивалент сеанса system_health с целевым объектом event_file в хранилище BLOB-объектов Azure. Дополнительные сведения, включая скрипт T-SQL для создания system_health сеанса, который можно изменить для создания собственного эквивалента system_health, см. в разделе «Использование сеанса system_health».

Промежуточное руководство по обновлениям часового пояса 2024 года для Парагвая

(Разрешено в феврале 2026 г.)

14 октября 2024 года правительство Парагвая объявило о постоянном изменении политики часового пояса. Парагвай теперь остается на летнее время (DST) круглый год, эффективно принимая UTC-3 в качестве своего стандартного времени. В результате часы не продвинулись на 60 минут в 12:00 утра 23 марта 2025 года, как было запланировано ранее. Это изменение влияет на часовой пояс "Стандартный" в Парагвае. Microsoft выпустила связанные обновления Windows в феврале и марте 2025. Управляемые экземпляры SQL, использующие затронутый часовой пояс, отражают это изменение и соответствуют новому смещению UTC-3.

Изменение типа подключения не влияет на подключения через узел отказоустойчивой группы.

(Разрешено в ноябре 2025 г.)

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

Временная недоступность экземпляра через прослушиватель группы отработки отказа во время операции масштабирования

(Разрешено в апреле 2025 г.)

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

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

Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).

Эта проблема будет устранена путем перепроектирования операций масштабирования.

Таблица для резервных копий вручную в msdb не сохраняет имя пользователя

(Разрешено в августе 2023 г.) Недавно внедрена поддержка автоматического резервного копирования в msdb, и в настоящее время она не содержит сведений о имени пользователя.

При использовании проверки подлинности SQL Server имена пользователей с именем @не поддерживаются

Имена пользователей, содержащие символ @ в середине (например, abc@xy), не могут выполнять вход с помощью проверки подлинности SQL Server.

Восстановление резервной копии вручную без контрольной суммы может привести к сбоям

(Устранено в июне 2020 г.) В некоторых случаях восстановление резервной копии баз данных, созданной вручную на управляемом экземпляре SQL без CHECKSUM, может завершиться ошибкой. В подобных случаях следует повторять попытку восстановления резервной копии до тех пор, пока это не получится.

Решение: Делайте ручные резервные копии баз данных на управляемых экземплярах SQL с CHECKSUM включенной.

Разрешения на группу ресурсов, не примененные к Управляемый экземпляр SQL

При применении роли Управляемый экземпляр SQL вкладчика Azure к группе ресурсов (RG), она не применяется к Управляемый экземпляр SQL и не оказывает никакого влияния.

Workaround: Настройте роль участника Управляемый экземпляр SQL для пользователей на уровне подписки.

На портале Azure отображается вводящее в заблуждение сообщение об ошибке, предлагающее воссоздать учетную запись службы.

Страница админа Active Directory портала Azure для Управляемый экземпляр SQL Azure может отобразить следующее сообщение об ошибке, даже если служебный принципал уже существует.

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

Это сообщение об ошибке можно игнорировать, если учетная запись службы для управляемого экземпляра базы данных SQL уже существует и (или) аутентификация Microsoft Entra в управляемом экземпляре базы данных SQL работает.

Чтобы проверить наличие Service Principal, перейдите на страницу Enterprise applications на портале Azure, выберите Managed Identities из раскрывающегося списка Application type, нажмите Применить и введите имя управляемого экземпляра SQL в поле поиска. Если имя экземпляра присутствует в списке результатов, это означает, что главный компонент службы уже существует, и дальнейшие действия не требуются.

Если вы уже выполнили инструкции из сообщения об ошибке и выбрали ссылку, основной сервис управляемого экземпляра SQL будет воссоздан. Назначьте разрешения на чтение Microsoft Entra ID новому субъекту-службе для корректной работы аутентификации Microsoft Entra. Вы также можете выполнить этот шаг с Azure PowerShell, следуя инструкции.

Недоступен целевой объект event_file сеанса событий system_health

(Частично разрешено в мае 2025 г.) При попытке прочитать содержимое event_file целевого сеанса событий вы получите сообщение об ошибке 40538: "Необходим допустимый URL-адрес, начинающийся с system_health, в качестве значения для любого указанного файлового пути".

Изначально эта проблема возникла в SQL Server Management Studio (SSMS) или при чтении данных сеанса с помощью функции sys.fn_xe_file_target_read_file.

В мае 2025 г. эта проблема была устранена для чтения данных сеанса из SSMS. Проблема не устранена при чтении данных событий с помощью sys.fn_xe_file_target_read_file функции.

Это изменение поведения является непредвиденным следствием необходимого исправления безопасности. Эту проблему можно обойти, создав собственный эквивалент сеанса system_health с целевым объектом event_file в Хранилище BLOB-объектов Azure. Дополнительные сведения, включая скрипт T-SQL для создания system_health сеанса, который можно изменить для создания собственного эквивалента system_health, см. в разделе «Использование сеанса system_health».

Диалоги Service Broker между базами данных требуют реинициализации после обновления уровня обслуживания.

(Разрешено в январе 2020 г.) Диалоговые окна компонента Service Broker между базами данных перестают доставлять сообщения службам в других базах данных после изменения операции уровня служб. Сообщения не теряются, и их можно найти в очереди отправителей. Любое изменение числа виртуальных ядер или размера хранилища экземпляра в Управляемый экземпляр SQL приводит к изменению значения service_broke_guid в представлении sys.databases для всех баз данных. Любое DIALOG, созданное с помощью инструкции BEGIN DIALOG, ссылающееся на Service Brokers в других базах данных, перестает доставлять сообщения в целевую службу.

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

Участие в разработке содержимого

Чтобы внести свой вклад в документацию по Azure SQL, см. руководство для участников Docs.

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

• Для получения списка обновлений и улучшений Управляемый экземпляр SQL смотрите раздел обновления сервиса Управляемый экземпляр SQL.

• Обновления и улучшения всех служб Azure см. в разделе Service updates.