Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
Azure SQL Managed Instance
Cet article répertorie les problèmes actuellement connus avec Azure SQL Managed Instance, ainsi que leur date de résolution ou une éventuelle solution de contournement. Pour en savoir plus sur Azure SQL Managed Instance, consultez Présentation d’Azure SQL Managed Instance et Nouveautés d’Azure SQL Managed Instance ?
Remarque
Microsoft Entra ID s'appelait Azure Active Directory (Azure AD) jusqu'à une date récente.
Problèmes connus
A une solution de contournement
Modification de la période de rétention des sauvegardes pour l’offre gratuite
Vous pouvez uniquement modifier la stratégie de rétention de sauvegarde de vos bases de données dans l’instance managée SQL gratuite à l’aide de l’API REST, de PowerShell et des commandes Azure CLI . Il n’est pas possible de modifier la stratégie de rétention de sauvegarde via le portail Azure.
Nous n’avons pas pu effectuer la connexion au serveur de lecture secondaire en raison d’une longue attente sur « HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING »
Vous pouvez voir cette erreur comme une exception pour le pilote Microsoft OLE DB Driver 19 pour SQL Server lorsque vous tentez de vous connecter à un réplica secondaire en lecture seule d’un groupe de basculement ou à une base de données répliquée via le lien Managed Instance.
Cette erreur se produit lorsque le réplica secondaire n’est pas disponible pour les connexions, car les versions de ligne sont manquantes pour les transactions en cours lorsque le réplica secondaire a été redémarré ou recyclé, soit pour maintenance, soit en raison d’un basculement. Lorsqu’une instance est redémarrée ou bascule, les données de contrôle de version stockées dans tempdb sont effacées afin que les requêtes de lecture secondaires soient abandonnées si des transactions actives de longue durée ont été démarrées avant le basculement ou le redémarrage.
Pour résoudre ce problème, restaurez ou engagez les transactions en cours sur le réplica principal. Pour éviter cette erreur, minimisez les transactions en écriture de longue durée sur le réplica principal.
Conseils provisoires sur les mises à jour des fuseaux horaires 2024 pour le Paraguay
Le 14 octobre 2024, le gouvernement paraguayen a annoncé un changement permanent de la politique de fuseau horaire du pays. Le Paraguay reste sur l’heure d’été (DST) toute l’année, adoptant efficacement UTC-3 comme heure standard. Par conséquent, les horloges n’avancent pas de 60 minutes à 12 h 00 le 23 mars 2025, comme prévu précédemment. Cette modification affecte le fuseau horaire standard du Paraguay. Microsoft a publié des mises à jour Windows connexes en février et mars 2025. Actuellement, Azure SQL Managed Instance ne reflète pas cette mise à jour. Les instances utilisant un fuseau horaire affecté ne reflètent pas les modifications tant que le service Azure SQL Managed Instance n’absorbe pas la mise à jour au niveau du système d’exploitation.
Solution de contournement : si vous devez modifier les fuseaux horaires affectés pour vos instances managées, prenez connaissance des limitations et suivez les instructions de la documentation.
Erreur 8992 lors de l’exécution de DBCC CHECKDB sur une base de données SQL Server provenant de SQL Managed Instance
Vous pouvez voir l’erreur suivante lorsque vous exécutez la DBCC CHECKDB commande sur une base de données SQL Server 2022 après la suppression d’un index ou d’une table avec un index, et que la base de données provient d’Azure SQL Managed Instance, par exemple après la restauration d’un fichier de sauvegarde ou de la fonctionnalité de liaison SQL Managed Instance :
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.
Pour contourner le problème, supprimez d’abord l’index ou la table avec l’index, à partir de la base de données source dans Azure SQL Managed Instance, puis restaurez ou liez à nouveau la base de données vers SQL Server 2022. Si la recréation de la base de données à partir de la source Azure SQL Managed Instance n’est pas possible, contactez le support Microsoft pour résoudre ce problème.
Avertissement
Si vous créez un index partitionné sur une table après avoir supprimé un index comme décrit dans ce scénario, la table devient inaccessible.
La liste des sauvegardes à long terme dans le portail Azure affiche les fichiers de sauvegarde des bases de données actives et supprimées portant le même nom.
Les sauvegardes à long terme peuvent être répertoriées et gérées sur la page du portail Azure pour une instance managée Azure SQL sous l’onglet Sauvegardes . La page répertorie les bases de données actives ou supprimées, les informations de base sur leurs sauvegardes à long terme et le lien permettant de gérer les sauvegardes. Lorsque vous sélectionnez le lien Gérer, un nouveau volet latéral s’ouvre avec la liste des sauvegardes. En raison d’un problème lié à la logique de filtrage, la liste affiche les sauvegardes des bases de données actives et des bases de données supprimées portant le même nom. Cela nécessite une attention particulière lors de la sélection des sauvegardes à supprimer, afin d’éviter de supprimer les sauvegardes d’une mauvaise base de données.
Solution de contournement : utilisez les informations affichées sur l’heure de la sauvegarde (UTC) dans la liste pour différencier les sauvegardes appartenant à des bases de données portant le même nom qui existaient sur l’instance à des périodes différentes. Vous pouvez également utiliser les commandes PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup et Remove-AzSqlInstanceDatabaseLongTermRetentionBackup, ou les commandes CLI az sql midb ltr-backup list et az sql midb ltr-backup delete pour gérer les sauvegardes à long terme à l’aide du paramètre DatabaseState et de la valeur retournée DatabaseDeletionTime pour filtrer les sauvegardes pour une base de données.
La procédure sp_send_dbmail peut échouer lorsque le paramètre @query est utilisé.
La procédure sp_send_dbmail peut échouer lorsque le paramètre @query est utilisé. Les échecs se produisent lorsque la procédure stockée est exécutée sous le compte administrateur système.
Ce problème est dû à un bogue connu lié à la façon dont sp_send_dbmail utilise l’usurpation d’identité.
Solution de contournement : vérifiez que vous appelez sp_send_dbmail sous le compte personnalisé approprié que vous avez créé, non sous un compte administrateur système.
Voici un exemple de la façon dont vous pouvez créer un compte dédié et modifier des objets existants qui envoient des e-mails à l’aide de 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
La modification du type de connexion n’affecte pas les connexions via le point de terminaison du groupe de basculement
Si une instance participe à un groupe de basculement, la modification du type de connexion de l’instance ne prend pas effet pour les connexions établies via le point de terminaison de l’écouteur de groupe de basculement.
Solution de contournement : supprimez et recréez le groupe de basculement après avoir modifié le type de connexion.
Les transactions distribuées peuvent être exécutées après la suppression de l’instance managée SQL du groupe d’approbations de serveur
Les groupes d’approbation de serveurs sont utilisés pour établir une relation de confiance entre les instances gérées, condition préalable à l’exécution de transactions distribuées. Après avoir supprimé l’instance managée SQL du groupe d’approbations de serveur ou supprimé le groupe, vous pouvez toujours exécuter des transactions distribuées. Vous pouvez appliquer un moyen de contournement pour vous assurer que les transactions distribuées sont désactivées, à savoir un basculement manuel initié par l’utilisateur sur l’instance managée SQL.
Impossible de créer l’Instance managée SQL avec le même nom que le serveur logique précédemment supprimé
Un enregistrement DNS de <name>.database.windows.com est créé lorsque vous créez un serveur logique dans Azure pour Azure SQL Database et lorsque vous créez une instance gérée SQL. L’enregistrement DNS doit être unique. Ainsi, si vous créez un serveur logique pour SQL Database, puis que vous le supprimez, il existe une période seuil de sept jours avant que le nom ne soit libéré des enregistrements. Pendant cette période, une instance gérée SQL ne peut pas être créée avec le même nom que le serveur logique supprimé. En guise de solution de contournement, utilisez un nom différent pour l’instance gérée SQL ou créez un ticket de support pour libérer le nom du serveur logique.
Le principal de service ne peut pas accéder à Microsoft Entra ID et AKV
Dans certains cas, il existe peut exister un problème avec le principal de service utilisé pour accéder aux services Microsoft Entra ID (anciennement Azure Active Directory) et Azure Key Vault (AKV). Par conséquent, ce problème a un impact sur l’utilisation de l’authentification Microsoft Entra et Transparent Data Encryption (TDE) avec SQL Managed Instance. Cela peut être ressenti comme un problème de connectivité intermittent ou comme l’impossibilité d’exécuter des instructions telles que CREATE LOGIN/USER FROM EXTERNAL PROVIDER ou EXECUTE AS LOGIN/USER. La configuration de TDE avec une clé gérée par le client sur un nouveau service Azure SQL Managed Instance peut également ne pas fonctionner dans certaines circonstances.
Solution de contournement : Pour éviter que ce problème ne se produise sur votre service SQL Managed Instance avant d’exécuter des commandes de mise à jour, ou si vous avez déjà rencontré ce problème après l’exécution de commandes de mise à jour, allez sur la page de présentation de votre SQL Managed Instance dans le portail Azure. Sous Paramètres, sélectionnez Microsoft Entra ID pour accéder à la page d’administration SQL Managed Instance Microsoft Entra ID. Vérifiez si le message d’erreur s’affiche :
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Si vous rencontrez ce message d’erreur, sélectionnez-le, puis suivez les instructions pas à pas fournies jusqu’à ce que cette erreur soit résolue.
Erreur retournée lors de la tentative de suppression d’un fichier qui n’est pas vide
SQL Server et SQL Managed Instance ne permettent pas à l’utilisateur de déposer un fichier qui n’est pas vide. Si vous tentez de supprimer un fichier de données non vide à l’aide d’une instruction ALTER DATABASE REMOVE FILE, l’erreur Msg 5042 – The file '<file_name>' cannot be removed because it is not empty n’est pas retournée immédiatement. SQL Managed Instance continue d’essayer de déposer le fichier et l’opération échoue après 30 minutes avec Internal server error.
Les opérations de changement de niveau de service et de création d’instance sont bloquées par la restauration de base de données en cours
Une déclaration en cours RESTORE, un processus de migration Data Migration Service et une restauration ponctuelle intégrée empêchent la mise à jour d’un niveau de service, le redimensionnement de l’instance existante et la création de nouvelles instances jusqu’à ce que le processus de restauration soit terminé.
Le processus de restauration bloque ces opérations sur les instances managées et les pools d’instances sur le sous-réseau où le processus de restauration est en cours d’exécution. Les instances dans les pools d’instances ne sont pas affectées. Les opérations de création ou de modification du niveau de service n’échouent pas et ne sont pas interrompues. Elles se poursuivent une fois le processus de restauration terminé ou annulé.
Solution de contournement : Attendez la fin du processus de restauration ou annulez-le si l’opération de création ou de mise à jour du niveau de service a une priorité plus élevée.
Resource Governor sur un réplica secondaire lisible doit être reconfiguré après son basculement
La fonctionnalité Resource Governor qui vous permet de limiter les ressources affectées à la charge de travail de l’utilisateur peut classer incorrectement certaines charges de travail utilisateur après le basculement ou une modification initiée par l’utilisateur du niveau de service (par exemple, la modification de la taille maximale de stockage vCore ou de l’instance maximale).
Solution de contournement : exécutez ALTER RESOURCE GOVERNOR RECONFIGURE régulièrement ou dans le cadre d’un travail SQL Agent qui exécute la tâche SQL lorsque le réplica secondaire lisible démarre si vous utilisez Resource Governor.
Les boîtes de dialogue Service Broker utilisées entre plusieurs bases de données doivent être réinitialisées après la mise à niveau du niveau de service
Les boîtes de dialogue du Service Broker inter-bases de données arrêtent de délivrer les messages aux services des autres bases de données après une opération de changement de niveau de service. Les messages ne sont pas perdus et peuvent être retrouvés dans la file d’attente de l’expéditeur. Toute modification du nombre de vCores ou de la taille de stockage des instances dans SQL Managed Instance entraîne le changement de la valeur service_broke_guid affichée dans sys.databases pour toutes les bases de données. Tout élément DIALOG créé à l’aide de l’instruction BEGIN DIALOG qui fait référence aux courtiers de services dans une autre base de données arrête de transmettre les messages au service cible.
Solution de contournement : Arrêtez toutes les activités qui utilisent des conversations de boîtes de dialogue Service Broker entre plusieurs bases de données avant de mettre à jour le niveau de service et réinitialisez-les ensuite. S’il reste des messages non transmis après le changement de niveau de service, consultez les messages en question dans la file d’attente source et renvoyez-les à la file d’attente cible.
Dépassement de l’espace de stockage avec des fichiers de base de données de petite taille
CREATE DATABASE, ALTER DATABASE ADD FILEet les RESTORE DATABASE instructions peuvent échouer, car l’instance peut atteindre la limite de stockage Azure sur le niveau de service Usage général, mais pas la mise à niveau du niveau de service Usage général de nouvelle génération ou le niveau de service Critique pour l’entreprise.
Chaque instance SQL Managed Instance à usage général a jusqu’à 35 To de stockage réservé pour l’espace disque Azure Premium. Chaque fichier de base de données est placé sur un disque physique distinct. Les tailles de disque peuvent être de 128 Go, 256 Go, 512 Go, 1 To ou 4 To. L’espace non utilisé sur le disque n’est pas facturé, mais la somme des tailles des disques Premium Azure ne peut pas dépasser 35 To. Dans certains cas, une instance managée SQL qui n’a pas besoin de 8 To au total peut dépasser la limite Azure de 35 To en raison d’une fragmentation interne.
Par exemple, une instance SQL Managed Instance à usage général peut avoir un fichier d’une taille de 1,2 To placé sur un disque de 4 To. Elle peut également posséder 248 fichiers, d’une taille de 1 Go chacun, qui sont placés sur des disques distincts de 128 Go. Dans cet exemple :
- La taille totale du stockage de disque alloué est de 1 x 4 To + 248 x 128 Go = 35 To.
- L’espace total réservé pour les bases de données sur l’instance est de 1 x 1,2 To + 248 x 1 Go = 1,4 To.
Cet exemple montre que, dans certaines circonstances, du fait d’une répartition spécifique des fichiers, une instance SQL Managed Instance peut atteindre la limite des 35 To réservée pour un disque Azure Premium attaché, sans que vous vous y attendiez.
Dans cet exemple, les bases de données existantes continuent de fonctionner et peuvent croître sans aucun problème du moment que de nouveaux fichiers ne sont pas ajoutés. La création ou la restauration de bases de données est impossible, car il n’y a pas suffisamment d’espace pour les nouveaux lecteurs de disque, même si la taille totale de toutes les bases de données n’atteint pas la limite de taille d’instance. L’erreur qui est retournée dans ce cas n’est pas claire.
Vous pouvez identifier le nombre de fichiers restants à l’aide de vues système. Si vous atteignez cette limite, essayez de vider et de supprimer certains fichiers plus petits au moyen de l’instruction DBCC SHRINKFILE, ou basculez vers le niveau Critique pour l’entreprise, qui ne connaît pas cette limite.
Affichage des valeurs GUID à la place des noms de base de données
Plusieurs vues système, compteurs de performances, messages d’erreur, événements XEvent et entrées du journal des erreurs affichent des identificateurs de base de données GUID au lieu d’afficher les noms des bases de données. Ne prenez pas en compte ces identificateurs GUID, car ils peuvent être remplacés à l’avenir par les noms des bases de données.
Solution de contournement : utilisez la vue sys.databases pour résoudre le nom de la base de données réel à partir du nom de la base de données physique, spécifié sous forme d’identificateurs de base de données GUID :
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
Les modules CLR et les serveurs liés parfois ne parviennent pas à référencer une adresse IP locale
Il arrive que des modules CLR placés dans une instance SQL Managed Instance et que des serveurs liés ou des requêtes distribuées référençant une instance active ne parviennent pas à résoudre l’adresse IP d’une instance locale. Cette erreur est un problème temporaire.
Aucune résolution
Il est impossible d’effectuer les sauvegardes différentielles lorsqu’une instance est liée à SQL Server
Lorsque vous configurez un lien entre SQL Server et Azure SQL Managed Instance, les sauvegardes de journaux de transactions et complètes automatisées sont effectuées sur l’instance managée SQL, qu’elle soit ou non dans le rôle principal. Toutefois, les sauvegardes différentielles ne sont pas effectuées actuellement, ce qui peut entraîner des temps de restauration plus longs que prévu.
Augmentation du nombre de connexions système utilisées pour la réplication transactionnelle
Le service Azure SQL Managed Instance crée une connexion système à des fins de réplication transactionnelle. Cette connexion se trouve dans SSMS (dans Explorateur d’objets, sous Sécurité, Connexions) ou dans la vue système sys.syslogins. Le format de nom de connexion ressemble à 'DBxCy\WF-abcde01234QWERT', et la connexion a le rôle serveur public. Dans certaines conditions, cette connexion est recréée, et en raison d’une erreur système, la connexion précédente n’est pas supprimée. Cela peut entraîner une augmentation du nombre de connexions. Ces connexions ne représentent pas une menace de sécurité. Vous pouvez les ignorer sans risque. Ces connexions ne doivent pas être supprimées, car au moins l’une d’elles est utilisée pour la réplication transactionnelle.
Les connexions et les utilisateurs Microsoft Entra ne sont pas pris en charge dans SSDT.
SQL Server Data Tools ne prend pas complètement en charge les connexions et les utilisateurs Microsoft Entra.
L'usurpation des types de connexion Microsoft Entra n'est pas supportée
L’emprunt d’identité en utilisant EXECUTE AS USER ou EXECUTE AS LOGIN des principaux Microsoft Entra suivants n’est pas pris en charge :
- Utilisateurs de Microsoft Entra avec alias L’erreur suivante est renvoyée dans ce cas :
15517. - Connexions et utilisateurs Microsoft Entra basés sur des applications ou des principaux de service Microsoft Entra. Les erreurs suivantes sont retournées dans ces cas
15517et15406.
La réplication transactionnelle doit être reconfigurée après un basculement géographique.
Si la réplication transactionnelle est activée sur une base de données dans un groupe de basculement, l’administrateur de SQL Managed Instance doit nettoyer toutes les publications de l’ancien principal et les reconfigurer sur le nouveau principal après un basculement vers une autre région. Pour plus d’informations, voir Réplication.
Les journaux des erreurs ne sont pas conservés
Les journaux des erreurs qui sont disponibles dans SQL Managed Instance ne sont pas persistants, et leur taille n’est pas comprise dans la limite de stockage maximale. Les journaux des erreurs peuvent être automatiquement effacés si un basculement se produit. Il peut y avoir des lacunes dans l’historique du journal des erreurs, car l’instance SQL Managed Instance a été déplacée plusieurs fois sur plusieurs machines virtuelles.
Résolu
Inaccessibilité temporaire de l’instance avec l’écouteur de groupe de basculement lors de l’opération de mise à l’échelle
(Résolu en avril 2025)
La mise à l’échelle de l’instance managée SQL nécessite parfois de déplacer l’instance vers un autre cluster virtuel, ainsi que les enregistrements DNS gérés par le service associés. Si l’instance managée SQL participe à un groupe de basculement, l’enregistrement DNS correspondant à son écouteur de groupe de basculement associé (écouteur en lecture-écriture, si l’instance est l’écouteur en lecture seule géo-primaire actuel, si l’instance est la géo-secondaire actuelle) est déplacée vers le nouveau cluster virtuel.
Dans la conception actuelle de l’opération de mise à l’échelle, les enregistrements DNS de l’écouteur sont supprimés du cluster virtuel d’origine avant que l’instance managée SQL elle-même soit entièrement migrée vers le nouveau cluster virtuel, ce qui, dans certaines situations, peut entraîner une durée prolongée pendant laquelle l’adresse IP de l’instance ne peut pas être résolue à l’aide de l’écouteur. Pendant ce temps, un client SQL qui tente d’accéder à l’instance mise à l’échelle à l’aide du point de terminaison de l’écouteur peut s’attendre à des échecs de connexion avec le message d’erreur suivant :
Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).
Le problème sera résolu par une refonte de l’opération de mise à l’échelle.
La table msdb pour les sauvegardes manuelles ne conserve pas le nom d’utilisateur
(Résolu en août 2023) Nous avons récemment introduit la prise en charge des sauvegardes automatiques dans msdb, mais la table ne contient actuellement pas d’informations sur le nom d’utilisateur.
Lors de l’utilisation de l’authentification SQL Server, les noms d’utilisateur avec « @ » ne sont pas pris en charge
Les noms d’utilisateur contenant le symbole « @ » au milieu (par exemple, 'abc@xy') ne sont pas en mesure de se connecter à l’aide de l’authentification SQL Server.
La restauration d’une sauvegarde manuelle sans CHECKSUM peut échouer
(Résolu en juin 2020) Dans certaines circonstances, la sauvegarde manuelle des bases de données effectuées sur une instance managée SQL sans CHECKSUM peut ne pas être restaurée. Vous devez alors réessayer de restaurer la copie de sauvegarde jusqu’à ce que l’opération réussisse.
Solution de contournement : Effectuez des sauvegardes manuelles de bases de données sur des instances managées SQL avec CHECKSUM activé.
Autorisations sur le groupe de ressources non appliquées à SQL Managed Instance
Si le rôle Azure Contributeur SQL Managed Instance est appliqué à un groupe de ressources, il n’est pas appliqué à SQL Managed Instance et n’a aucun effet.
Solution de contournement : Configurez le rôle Contributeur SQL Managed Instance pour les utilisateurs au niveau de l’abonnement.
Message d’erreur trompeur sur le portail Azure suggérant de recréer le principal de service
La page d’administration Active Directory du portail Azure pour Azure SQL Managed Instance peut afficher le message d’erreur suivant même si le principal de service existe déjà :
Managed Instance needs a Service Principal to access Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)). Click here to create a Service Principal
Vous pouvez ignorer ce message d’erreur si le principal de service pour l’instance managée SQL existe déjà, et/ou l’authentification Microsoft Entra sur l’instance managée SQL fonctionne.
Pour vérifier si le principal de service existe, accédez à la page Applications d’entreprise du portail Azure, choisissez Identités managées dans la liste déroulante Type d’application , sélectionnez Appliquer et tapez le nom de l’instance managée SQL dans la zone de recherche. Si le nom d’instance s’affiche dans la liste de résultats, le principal de service existe déjà et aucune autre action n’est nécessaire.
Si vous avez déjà suivi les instructions du message d’erreur et sélectionné le lien à partir du message d’erreur, le Service Principal de l’instance managée SQL a été recréé. Dans ce cas, attribuez les autorisations de lecture Microsoft Entra ID au principal de service nouvellement créé afin que l’authentification Microsoft Entra fonctionne correctement. Pour ce faire, vous pouvez utiliser Azure PowerShell en suivant les instructions ci-dessous.
La cible event_file de la session 'system_health' n’est pas accessible
(Résolu en mai 2025) Lorsque vous tentez de lire le contenu de la event_file cible de la system_health session d’événements, vous obtenez l’erreur 40538 : « Une URL valide commençant par « https:// » est requise comme valeur pour tout chemin de fichier spécifié. » Cela se produit dans SQL Server Management Studio ou lors de la lecture des données de session à l’aide de la fonction sys.fn_xe_file_target_read_file .
Ce changement de comportement est une conséquence inattendue d’un correctif de sécurité requis récent. Nous examinons la faisabilité d’une modification supplémentaire qui permettrait aux clients de continuer à utiliser la system_health session sur Managed Instance en toute sécurité. En attendant, les clients peuvent contourner ce problème en créant leur propre équivalent de la session system_health avec event_file comme cible dans Azure Blob Storage. Pour plus d’informations, notamment un script T-SQL pour créer la session system_health qui peut être modifiée pour créer votre propre équivalent de system_health, consultez Utiliser la session system_health.
Contribuer au contenu
Pour contribuer à la documentation Azure SQL, consultez le guide du contributeur Docs.
Contenu connexe
Pour obtenir la liste des mises à jour et améliorations apportées à SQL Managed Instance, consultez Mises à jour du service SQL Managed Instance.
Pour connaître les mises à jour et améliorations apportées à tous les services Azure, consultez Mises à jour des services.