Problèmes connus avec Azure SQL Managed Instance
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 était précédemment connu sous le nom d’Azure Active Directory (Azure AD).
Problèmes connus
Solution de contournement
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 d’une Azure SQL Managed Instance, dans 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 pour 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 de retour DatabaseDeletionTime pour filtrer les sauvegardes d’une base de données.
La cible event_file de la session d’événements system_health n’est pas accessible
Lorsque vous tentez de lire le contenu de la cible event_file de la session d’événements system_health, 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 une cible event_file dans le stockage d’objets blob Azure. 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.
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
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
Conseils intermédiaires sur les mises à jour des fuseaux horaires de 2022 pour le Chili
Le 8 août 2022, le gouvernement chilien a fait une annonce officielle concernant un changement de fuseau horaire pour l’heure d’été. À partir du samedi 10 septembre 2022, à 0 h 00, jusqu’au samedi 1er avril 2023, à 0 h 00, l’heure officielle sera avancée de 60 minutes. Le changement affecte les trois fuseaux horaires suivants : Heure standard du Pacifique SA, Heure standard de l’île de Pâques et Heure standard de Magallanes. Les instances Azure SQL Managed Instances utilisant des fuseaux horaires affectés ne reflète pas les modifications tant que Microsoft n’a pas publié une mise à jour du système d’exploitation pour prendre en charge ce service et Azure SQL Managed Instance absorbe 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.
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.
La procédure sp_send_dbmail peut échouer de façon transitoire lorsque le paramètre @query est utilisé
La procédure sp_send_dbmail peut échouer momentanément lorsque le paramètre @query est utilisé. Quand ce problème se produit, chaque deuxième exécution de la procédure sp_send_dbmail échoue avec l’erreur Msg 22050, Level 16, State 1 et le message Failed to initialize sqlcmd library with error number -2147467259. Pour voir correctement cette erreur, vous devez appeler la procédure avec la valeur par défaut 0 pour le paramètre @exclude_query_output. Autrement, l’erreur n’est pas propagée.
Ce problème est dû à un bogue connu lié à la façon dont la procédure sp_send_dbmail utilise l’emprunt d’identité et le regroupement de connexions.
Pour contourner ce problème, encapsulez le code pour l’envoi d’e-mail dans une logique de nouvelle tentative s’appuyant sur le paramètre de sortie @mailitem_id. Si l’exécution échoue, la valeur du paramètre est NULL, ce qui indique que la procédure sp_send_dbmail doit être appelée une fois de plus pour envoyer un e-mail avec succès. Voici un exemple de logique de nouvelle tentative :
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
Les transactions distribuées peuvent être exécutées après la suppression de l’instance gérée du groupe d’approbation de serveurs
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 gérée du groupe d’approbation de serveurs ou supprimé le groupe, vous pourrez peut-être encore exécuter des transactions distribuées. Il existe une solution de contournement que vous pouvez appliquer pour vous assurer que les transactions distribuées sont désactivées : il s’agit du basculement manuel initié par l’utilisateur sur l’instance managée.
Les transactions distribuées ne peuvent pas être exécutées après l’opération de mise à l’échelle de l’instance gérée
Les opérations de mise à l’échelle de SQL Managed Instance qui incluent la modification du niveau de service ou du nombre de vCores réinitialisent les paramètres du groupe d’approbation de serveurs sur le back-end et désactivent les transactions distribuées en cours d’exécution. Pour contourner ce problème, supprimez le groupe d’approbation de serveurs et créez-en un nouveau sur le portail Azure.
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 vous pouvez voir le message d’erreur « Managed Instance a besoin d’un principal du service pour accéder à Microsoft Entra ID. Cliquez ici pour créer un principal de service ». 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.
Limitation du basculement manuel via le portail pour les groupes de basculement
Si le groupe de basculement s’étend sur plusieurs instances dans différents abonnements ou groupes de ressources Azure, le basculement manuel ne peut pas être initié à partir de l’instance principale dans le groupe de basculement.
Solution de contournement : Lancez le basculement via le portail à partir de l’instance géographique secondaire.
Les rôles d’agent SQL requièrent des autorisations d’exécution explicites pour les connexions non-sysadmin
Si des connexions non-sysadmin sont ajoutées à un rôle de base de données fixe de SQL Agent, il y a un problème du fait que des autorisations EXECUTE explicites doivent être accordées à trois procédures stockées dans la base de données master pour que ces connexions fonctionnent. Si ce problème se produit, le message d’erreur The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) s’affiche.
Solution de contournement : Une fois que vous avez ajouté des connexions à un rôle de base de données fixe SQL Agent (SQLAgentUserRole, SQLAgentReaderRole ou SQLAgentOperatorRole) pour chaque connexion ajoutée à ces rôles, exécutez le script T-SQL suivant pour autoriser explicitement l’accès EXÉCUTER aux procédures stockées listées.
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];
Les limites de mémoire OLTP en mémoire ne sont pas appliquées
Le niveau de service critique pour l’entreprise n’applique pas correctement les limites max de mémoire pour les objets à mémoire optimisée dans certains cas. SQL Managed Instance peut permettre à la charge de travail d’utiliser davantage de mémoire pour les opérations OLTP en mémoire, ce qui peut affecter la disponibilité et la stabilité de l’instance. Les requêtes OLTP en mémoire qui atteignent les limites peuvent ne pas échouer immédiatement. Les requêtes qui utilisent plus de mémoire OLTP en mémoire échouent plus tôt si elles atteignent les limites.
Solution de contournement : Surveillez l’utilisation du stockage OLTP en mémoire à l’aide de SQL Server Management Studio pour vous assurer que la charge de travail n’utilise pas plus que la mémoire disponible. Augmentez les limites de mémoire qui dépendent du nombre de vCores ou optimisez votre charge de travail pour utiliser moins de mémoire.
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 instruction RESTORE en cours, un processus de migration Data Migration Service et une limite de restauration dans le temps intégrée bloquent la mise à jour du niveau de service ou le redimensionnement de l’instance existante et la création de nouvelles instances jusqu’à la fin du processus de restauration.
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.
Il peut être nécessaire de reconfigurer Resource Governor sur le niveau de service Critique pour l’entreprise après le basculement
Il se peut que la fonctionnalité Resource Governor qui permet de limiter les ressources affectées aux charges de travail utilisateur classe erronément une charge de travail utilisateur après un basculement ou une modification du niveau de service apportée par un utilisateur (par exemple, la modification du nombre maximal de vCores ou de la taille maximale de stockage d’instance).
Solution de contournement : Exécutez ALTER RESOURCE GOVERNOR RECONFIGURE régulièrement ou dans le cadre du travail du SQL Agent qui exécute la tâche SQL lorsque l’instance 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 Service Broker utilisées entre plusieurs bases de données cessent de transmettre les messages aux services dans d’autres bases de données après un changement du 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 référence des répartiteurs Service Brokers dans une autre base de données cesse de remettre 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
Les instructions CREATE DATABASE, ALTER DATABASE ADD FILE et RESTORE DATABASE risquent d’échouer, car l’instance peut atteindre la limite de Stockage Azure.
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 qui n’a pas besoin de 8 To au total peut dépasser la limite Azure de 35 To en taille de stockage à cause 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 l’affichage sys.databases pour résoudre le nom de la base de données à 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.
L’utilisation de la même étendue de transaction pour deux bases de données appartenant à une même instance n’est pas prise en charge
(Résolu en mars 2020) Dans .NET, la classe TransactionScope ne fonctionne pas si deux requêtes sont envoyées à deux bases de données appartenant à la même instance et à la même étendue de transaction :
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();
}
Solution de contournement (non nécessaire depuis mars 2020) : servez-vous de SqlConnection.ChangeDatabase(String) pour utiliser une autre base de données dans un contexte de connexion au lieu d’utiliser deux connexions.
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 gérée, qu’elle soit ou non dans le rôle principal. Toutefois, les sauvegardes différentielles ne sont pas prises actuellement, quand elles peuvent entraîner des temps de restauration plus longs.
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. 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 d’identité des types de connexion Microsoft Entra n’est pas prise en charge
L’usurpation d’identité avec EXECUTE AS USER ou EXECUTE AS LOGIN des principaux Microsoft Entra suivants n’est pas prise en charge :
- Alias des utilisateurs de Microsoft Entra. 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.
La structure et le contenu de tempdb sont recréés
La base de données tempdb est toujours fractionnée en 12 fichiers de données, et cette structure de fichiers ne peut pas être modifiée. La taille maximale par fichier n’est pas modifiable, et il n’est pas possible d’ajouter de nouveaux fichiers dans tempdb. La base de données tempdb est toujours recréée en tant que base de données vide quand l’instance démarre ou bascule, et les modifications apportées dans tempdb ne sont pas conservées.
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.
Inaccessibilité d’instance temporaire en utilisant l’écouteur de groupe de basculement lors de l’opération de mise à l’échelle
La mise à l’échelle de l’instance managé 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 participe à un groupe de basculement, l’enregistrement DNS correspondant à son écouteur de groupe de basculement associé (écouteur en lecture et en écriture, si l’instance est la géo-primaire actuelle, c’est-à-dire écouteur en lecture seule, 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 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 : « Erreur 40532 : Impossible d’ouvrir le serveur « xxx.xxx.xxx.xxx » demandé par la connexion. La connexion a échoué. (Microsoft SQL Server, erreur : 40532). »
Le problème sera résolu par une refonte de l’opération de mise à l’échelle.
Résolu
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.
L’interrogation de table externe échoue avec un message d’erreur indiquant qu’elle n’est pas prise en charge
L’interrogation d’une table externe peut échouer avec le message d’erreur générique « Les requêtes sur les tables externes ne sont pas prises en charge avec le niveau de service ou le niveau de performance actuel de cette base de données ». Augmentez le niveau de performance ou le niveau de service de la base de données. » Le seul type de table externe pris en charge dans Azure SQL Managed Instance sont les tables externes PolyBase (en préversion). Pour autoriser les requêtes sur des tables externes PolyBase, vous devez activer PolyBase sur l’instance gérée en exécutant la commande sp_configure.
Les tables externes associées à la fonctionnalité Requête élastique d’Azure SQL Database ne sont pas prises en charge dans SQL Managed Instance, mais leur création et leur interrogation n’ont pas été bloquées explicitement. Avec la prise en charge des tables externes PolyBase, de nouvelles vérifications ont été introduites, bloquant l’interrogation de tous les types de table externe dans l’instance gérée, sauf si PolyBase est activé.
Si vous utilisez des tables externes de Requête élastique non prises en charge pour interroger des données dans Azure SQL Database ou Azure Synapse à partir de votre instance gérée, vous devez plutôt utiliser la fonctionnalité Serveur lié. Pour établir une connexion de Serveur lié depuis SQL Managed Instance vers SQL Database, suivez les instructions de cet article. Pour établir une connexion de Serveur lié à partir de SQL Managed Instance vers SQL Synapse, consultez ces instructions pas à pas. Comme la configuration et le test de la connexion de Serveur lié prennent un certain temps, vous pouvez utiliser une solution de contournement temporaire pour activer l’interrogation des tables externes associées à la fonctionnalité de Requête élastique :
Solution de contournement : exécutez les commandes suivantes (une fois par instance) pour activer les requêtes sur les tables externes :
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
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 certains cas, la restauration d’une copie de sauvegarde manuelle de bases de données effectuée sur une instance gérée sans CHECKSUM peut échouer. Vous devez alors réessayer de restaurer la copie de sauvegarde jusqu’à ce que l’opération réussisse.
Solution de contournement : Effectuez des copies de sauvegarde manuelles des bases de données sur une instance gérée avec activation de la CHECKSUM.
L’agent ne répond plus lors de la modification, la désactivation ou l’activation de travaux existants
Dans certaines circonstances, la modification d’un travail existant, sa désactivation ou son activation peuvent entraîner le blocage de l’agent. Le problème est automatiquement atténué lors de la détection, ce qui entraîne le redémarrage du processus de l’agent.
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.
Les travaux de l’agent SQL peuvent être interrompus par le redémarrage du processus de l’agent
(Résolu en mars 2020) SQL Agent crée une session chaque fois qu’une tâche démarre, ce qui augmente progressivement la consommation de mémoire. Pour éviter d’atteindre la limite de mémoire interne qui bloquerait l’exécution de tâches planifiées, le processus de l’agent est redémarré une fois que la consommation de mémoire atteint le seuil. Cela peut entraîner l’interruption de l’exécution des tâches en cours au moment du redémarrage.
@queryLe paramètre n’est pas pris en charge dans sp_send_db_mail
Le @queryparamètre dans la procédure sp_send_db_mail ne fonctionne pas.
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 a besoin d’un principal de service pour accéder à Microsoft Entra ID (anciennement Azure Active Directory). Cliquez ici pour créer un principal de service »
Vous pouvez ignorer ce message d’erreur si le principal de service pour la Managed Instance existe déjà et/ou si l’authentification Microsoft Entra sur la Managed Instance fonctionne.
Pour vérifier si le principal de service existe, accédez à la page Applications d’entreprise sur le portail Azure, choisissez Identités managées dans la liste déroulante Type d’application, sélectionnez Appliquer et entrez le nom de l’instance gérée 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 du message d’erreur, le principal du service de l’instance gérée 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.
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.