Forum aux questions sur Azure SQL Managed Instance

Pour obtenir la liste des fonctionnalités prises en charge dans SQL Managed Instance, consultez Fonctionnalités d’Azure SQL Managed Instance.

Pour connaître les différences de syntaxe et de comportement entre Azure SQL Managed Instance et SQL Server, consultez Différences T-SQL par rapport à SQL Server.

Pour voir les caractéristiques du matériel disponible, consultez Différences techniques dans les configurations matérielles. Pour voir les niveaux de service disponibles et leurs caractéristiques, consultez Différences techniques entre les niveaux de service.

Tout client est éligible à n’importe quel niveau de service. Les éditions Standard et Entreprise couvertes par Software Assurance peuvent toutes deux être échangées en utilisant Azure Hybrid Benefit (AHB) pour le niveau de service Usage général (lequel inclut la mise à niveau vers le niveau de service Usage général nouvelle génération) ou Critique pour l’entreprise en utilisant les ratios d’échange suivants : 1 Édition Standard = 1 Usage général, 1 Édition Entreprise = 1 Critique pour l’entreprise, 1 Édition Entreprise = 4 Usage général et 4 Usage général = 1 Édition Entreprise. Pour plus d’informations, consultez Droits spécifiques associés à AHB.

Pour voir la liste des types d’abonnements pris en charge, consultez Types d’abonnements pris en charge.

Il est possible de créer des instances managées dans la plupart des régions Azure ; consultez Régions prises en charge pour SQL Managed Instance. Si vous avez besoin d’une instance managée dans une région qui n’est actuellement pas prise en charge, envoyez une demande de support via le portail Azure.

Par défaut, SQL Managed Instance présente deux limites : une limite sur le nombre de sous-réseaux que vous pouvez utiliser et une limite sur le nombre de vCores que vous pouvez provisionner. Les limites varient en fonction du type d’abonnement et de la région. Pour voir la liste des limitations des ressources régionales par type d’abonnement, consultez le tableau de la section Limitations des ressources régionales. Il s’agit de limites non strictes qui peuvent être relevées sur demande. Si vous avez besoin de provisionner davantage d’instances managées dans vos régions actuelles, envoyez une demande de support pour augmenter le quota à partir du portail Azure. Pour plus d’informations, consultez Demander des augmentations de quota pour Azure SQL Database.

La limite de 100 bases de données par instance SQL Managed Instance est une limite matérielle qui ne peut pas être modifiée dans les niveaux de service Usage général et Critique pour l’entreprise. Vous pouvez avoir jusqu’à 500 bases de données dans le niveau de service Usage général nouvelle génération.

Vous pouvez envisager de migrer vers d’autres versions d’Azure plus adaptées à votre charge de travail : Azure SQL Database Hyperscale ou SQL Server sur les machines virtuelles Azure.

Vous pouvez envisager de migrer vers SQL Server sur les machines virtuelles Azure ou Azure SQL Database avec un ratio mémoire/processeur optimisé.

Pour les défauts et les problèmes connus, consultez Problèmes connus.

Pour les nouvelles fonctionnalités et les fonctionnalités en préversion, consultez Nouveautés.

Vous pouvez provisionner une instance managée à partir du portail Azure, de PowerShell, d’Azure CLI et de modèles ARM.

Oui, vous pouvez provisionner une instance managée dans un abonnement existant si cet abonnement appartient aux types d’abonnements pris en charge.

Il s’agit d’une limitation actuelle du composant sous-jacent qui vérifie le nom du sous-réseau par rapport à l’expression régulière ^[a-zA-Z_][^\/:*?"<>|`'^]*(?<![.\s])$. Tous les noms qui réussissent le test de l’expression régulière et qui sont des noms de sous-réseau valides sont actuellement pris en charge.

Vous pouvez mettre à l’échelle votre instance gérée à partir du Portail Azure, de PowerShell, d’Azure CLI ou de modèles ARM.

Oui, vous pouvez. Pour obtenir des instructions, consultez Déplacer des ressources entre régions.

Vous pouvez supprimer des instances managées via le portail Azure, PowerShell, Azure CLI ou les API REST Resource Manager.

Le temps nécessaire à la création d’une instance managée ou au changement du niveau de service (vCores, stockage) dépend de plusieurs facteurs. Consultez Opérations de gestion.

La restauration de chaque base de données est garantie pendant toute la période de rétention définie, même les bases de données qui ont été créées, puis supprimées après seulement quelques secondes. Quand une base de données est créée, supprimée ou restaurée, les sauvegardes sont effectuées à des intervalles différents afin de conserver les données pour pouvoir les restaurer pendant la période de conservation donnée. En cas de suppression d'une base de données avant la fin d'une opération de sauvegarde, l'opération de suppression peut être bloquée par l'erreur suivante :

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

Pour éviter cette erreur, vérifiez l’état de l’opération de suppression avant de recréer une base de données du même nom. Pour plus d’informations, consultez sys.dm_operation_status. Une fois que l’opération est dans l’état Terminé, vous pouvez restaurer ou créer une base de données du même nom.

Les cas d’utilisation courants suivants sont susceptibles de rencontrer cette erreur :

• Quand plusieurs bases de données sont supprimées et recréées avec le même nom rapidement et successivement. Quand une base de données est supprimée, la fin restante du journal des transactions est sauvegardée de façon synchrone avant la fin de l’opération de suppression, comme le montre l’image :

  

  Vous ne pouvez pas créer de base de données du même nom tant que la fin du journal n’est pas sauvegardée et que l’opération de suppression n’est pas terminée. La nature séquentielle de l’opération de suppression place les bases de données qui sont supprimées rapidement et successivement dans une file d’attente, ce qui peut prolonger le processus de suppression des bases de données et retarder la possibilité d’en créer d’autres en utilisant le même nom.

• Quand une base de données est restaurée et supprimée avant la création d’une sauvegarde complète. Quand une base de données est restaurée, la première étape du processus de restauration est d’effectuer une nouvelle sauvegarde complète de la base de données. Si vous essayez de restaurer une base de données puis que vous la supprimez immédiatement avant la fin de la sauvegarde complète, vous ne pouvez pas supprimer la base de données et en créer une autre du même nom tant que la sauvegarde complète n’a pas été effectuée et que l’opération de suppression de la base de données n’est pas effectuée. Selon la taille de la base de données, la sauvegarde complète peut prendre des heures.

Il est possible que votre abonnement ne soit pas éligible à SQL Managed Instance gratuite. Sinon, il existe une limite d’une instance gratuite par abonnement. Vous devez supprimer une instance existante à caractère gratuit pour en créer une autre. Si vous avez récemment supprimé votre instance gratuite, il peut prendre tout au plus une heure pour que la bannière de l’offre gratuite réapparaisse.

Il est probable que vous n’avez plus de crédits pour le mois. Accédez à votre SQL Managed Instance dans le Portail Azure et case activée l’état pour voir si votre instance est dans un état arrêté en raison d’un crédit insuffisant.

Cette fonctionnalité n’est pas disponible actuellement.

Oui, vous pouvez restaurer une sauvegarde automatisée à partir du stockage Azure ou restaurer une sauvegarde de base de données à l’aide de SQL Server Management Studio (SSMS).

Malgré les limitations des ressources, SQL Managed gratuit est conçu pour vous permettre de tester vos charges de travail sans aucun impact. Les performances que vous rencontrez lors de l’utilisation de SQL Managed Instance gratuite sont identiques aux performances d’une version de production de l’instance.

Sql Managed Instance gratuit offre 4 et 8 options vCore. Si votre entreprise nécessite une instance avec plus de ressources, créez une instance SQL Managed Instance payante à part entière.

Les options de sauvegarde ne peuvent pas être modifiées pour la SQL Managed Instance gratuite.

Actuellement, l’abonnement Student n’est pas éligible. Pour les abonnements éligibles, passez en revue les prérequis gratuits de l’offre SQL Managed Instance.

Il n’est pas possible de changer le nom d’une instance managée.

Oui, vous pouvez remplacez la zone DNS par défaut de SQL Managed Instance .database.windows.net par la vôtre. Cependant, la partie nom d’hôte de l’instance managée de son FQDN doit rester la même.

Pour utiliser une autre zone DNS au lieu de la valeur par défaut, par exemple, .contoso.com :

• Utilisez l’utilitaire réseau Client SQL Server (CliConfg) pour définir un alias. Vous pouvez utiliser uniquement le nom d’hôte de l’instance managée, ou le nom d’hôte de l’instance managée suivi d’un nom de domaine personnalisé. L’outil CliConfg ajoute simplement un alias dans le Registre sous « HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo » ou « HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo », selon que vous utilisez la version 64 bits (C:\Windows\System32\cliconfg.exe) ou la version 32 bits (C:\Windows\SysWOW64\cliconfg.exe). Vous pouvez donc l’utiliser à l’aide d’un script ou d’une stratégie de groupe. Utilisez les deux pour vous assurer que les programmes 32 bits et 64 bits peuvent résoudre l’alias.
• Utilisez un enregistrement CNAME dans DNS avec le nom d’hôte de l’instance managée pointant vers le FQDN de l’instance managée. Dans ce cas, TrustServerCertificate=TRUE est nécessaire lors de l’utilisation de l’authentification avec Microsoft Entra ID (anciennement Azure Active Directory).
• Utilisez un enregistrement A dans DNS avec le nom d’hôte de l’instance managée pointant vers l’adresse IP de l’instance managée. L’utilisation de l’adresse IP n’est pas recommandée, car elle est susceptible d’être modifiée sans information préalable. Dans ce cas, TrustServerCertificate=TRUE est nécessaire lorsque l’authentification Microsoft Entra est utilisée.

Azure SQL Managed Instance offre les mêmes niveaux de performance par calcul et taille de stockage que les autres options de déploiement d’Azure SQL Database. Si vous souhaitez regrouper les données sur une instance unique ou si vous avez simplement besoin d’une fonctionnalité prise en charge exclusivement dans SQL Managed Instance, vous pouvez migrer vos données en utilisant la fonctionnalité d’exportation/importation (BACPAC). Voici d’autres façons de prendre en compte la migration SQL Database vers SQL Managed Instance :

• Utilisation d'une Source de données externe
• Utilisation de SQLPackage
• Utilisation de la commande BCP

Une option consiste à exporter la base de données vers un fichier BACPAC, puis à importer le fichier BACPAC. Cette approche est recommandée si votre base de données est inférieure à 100 Go.

La réplication transactionnelle peut être utilisée si tous les tableaux dans la base de données ont des clés primaires et s’il n'y a pas d'objets OLTP en mémoire.

Pour migrer votre instance de SQL Server, consultez Guide SQL Server vers Azure SQL Managed Instance.

Pour obtenir des informations sur la migration à partir d’autres plateformes, consultez le Guide de migration des bases de données Azure.

Pour une comparaison des performances entre une instance managée et SQL Server, commencez par consulter l’article Bonnes pratiques pour comparer les performances entre Azure SQL Managed Instance et SQL Server.

Consultez Causes principales des différences de performances entre SQL Managed Instance et SQL Server. La taille du fichier journal des transactions peut avoir un impact sur le niveau de performance de SQL Managed Instance à usage général. Pour plus d’informations, consultez Impact of log file size on General Purpose.

Vous pouvez optimiser les performances de votre instance managée en procédant comme suit:

• Le réglage automatique fournit une optimisation des performances et une stabilisation des charges de travail grâce à un réglage continu des performances basé sur l’intelligence artificielle et le machine learning.
• L’OLTP en mémoire améliore le débit et la latence sur les charges de travail de traitement transactionnel et fournit des analyses plus rapides.
• L’application de quelques meilleures pratiques pour le paramétrage des applications et des bases de données.
• Le remplacement du mode proxy par le mode redirection pour le type de connexion afin de réduire la latence et d’augmenter le débit, si votre charge de travail se compose de nombreuses petites transactions.

Pour améliorer les performances sur une instance à usage général, augmentez la taille des fichiers de données. Pour optimiser les performances de stockage sur une instance à usage général, consultez Storage best practice guidelines for General Purpose tier.

Consultez Analyse des statistiques d’attente sur une instance managée SQL. Les statistiques d’attente sont des informations susceptibles de vous aider à comprendre pourquoi la durée de la requête est longue et à identifier les requêtes qui attendent quelque chose dans le moteur de base de données.

Pour connaître toutes les options possibles pour surveiller et alerter sur la consommation et les performances de SQL Managed Instance, consultez la publication sur les options d’analyse d’Azure SQL Managed Instance de notre blog. Pour le monitoring des performances en temps réel pour SQL Managed Instance, consultez Monitoring des performances en temps réel pour Azure SQL Managed Instance.

Consultez Monitoring et réglage des performances

Consultez Monitoring des performances en temps réel pour Azure SQL Managed Instance.

Oui, SQL Profiler est pris en charge sur SQL Managed Instance. Pour plus d’informations, consultez SQL Profiler. Toutefois, envisagez des événements étendus pour l’activité de « suivi », ceux-ci ayant moins d’impact sur l’instance monitorée. Pour plus d’informations, consultez Événements étendus.

Non, ils ne sont pas pris en charge. Vous pouvez utiliser DMV et le Magasin de données des requêtes avec SQL Profiler et XEvents pour surveiller vos bases de données.

Consultez Monitor CPU usage on your SQL Server and Azure SQL.

Oui. Pour obtenir des instructions, consultez Créer des alertes pour SQL Managed Instance. Pour plus de conseils et d’astuces, consultez le blog.

Non. Les alertes de métriques sont disponibles uniquement pour les instances managées. Les métriques d’alerte pour les bases de données individuelles d’une instance managée ne sont pas disponibles.

La taille de stockage pour SQL Managed Instance dépend du niveau de service sélectionné (Usage général, Usage général nouvelle génération ou Critique pour l’entreprise). Pour connaître les limitations de stockage de ces niveaux de service, consultez Limites des ressources.

La quantité minimale de stockage disponible dans une instance est de 32 Go. Le stockage peut être ajouté par incréments de 32 Go jusqu’à la taille de stockage maximale. Les 32 premiers gigaoctets sont gratuits.

Oui, vous pouvez acheter le stockage de module complémentaire, indépendamment des ressources de calcul, dans une certaine mesure. Voir Stockage maximal réservé aux instances dans le tableau.

Pour optimiser les performances de stockage, consultez Bonnes pratiques de stockage d’usage général.

Non, le stockage de sauvegarde n’est pas déduit de votre espace de stockage d’instance managée. Le stockage de sauvegarde est indépendant de l’espace de stockage d’instance et n’est pas limité en taille. Le stockage de sauvegarde est limité par la durée de rétention de la sauvegarde de vos bases de données d’instance configurables jusqu’à 35 jours. Pour plus d’informations. consultez Sauvegardes automatisées.

Pour suivre les sauvegardes automatisées effectuées sur une instance managée SQL, consultez Surveiller l’activité de sauvegarde.

Oui, vous pouvez créer une sauvegarde complète en copie seule dans le stockage Blob Azure, mais elle ne peut être restaurée que dans une instance managée. Pour plus d’informations, consultez Sauvegarde en copie seule. Cependant, la sauvegarde en copie seule est impossible si la base de données est chiffrée par le TDE managé par le service, car le certificat utilisé pour le chiffrement est inaccessible. Dans ce cas-là, utilisez la fonctionnalité de restauration à un instant dans le passé pour déplacer la base de données vers une autre instance managée ou basculer vers une clé gérée par le client.

Oui, elle est prise en charge et disponible pour les versions SQL Server 2005 et ultérieures. Pour utiliser la restauration native, chargez votre fichier. bak dans le stockage Blob Azure et exécutez des commandes T-SQL. Pour plus d’informations, consultez Restauration native à partir d’une URL.

Oui, mais seulement vers SQL Server 2022, pendant la période de support standard de SQL Server 2022. Il est possible qu'à l'avenir, certaines caractéristiques d'Azure SQL Managed Instance soient introduites et nécessitent des modifications du format de la base de données. Toute modification de format rendrait les sauvegardes incompatibles avec la dernière version de SQL Server. L’accès à ces fonctionnalités exige une adhésion explicite.

Les bases de données système ne sont pas répliquées vers l’instance secondaire dans un groupe de basculement. Par conséquent, les scénarios qui dépendent des objets des bases de données système ne peuvent pas s’appliquer à l’instance secondaire, à moins que ces objets soient créés manuellement sur cette dernière. Pour contourner ce problème, consulter Activer les scénarios dépendant des objets des bases de données système.

Quelles sont les contraintes NSG entrantes/sortantes actuelles sur le sous-réseau de l’instance managée ?

Les règles NSG et UDR obligatoires sont documentées dans Configuration du sous-réseau assistée par le service et définies automatiquement par le service. Ne perdez pas de vue que ces règles sont simplement celles dont nous avons besoin pour tenir à jour le service. Pour vous connecter à Managed Instance et utiliser des fonctionnalités différentes, vous devez définir des règles supplémentaires propres aux fonctionnalités, que vous devez tenir à jour.

Comment puis-je définir des règles de groupe de sécurité réseau entrants sur les ports de gestion ?

La définition de règles au niveau des ports de gestion incombe à SQL Managed Instance. Pour cela, le service utilise une fonctionnalité nommée Configuration de sous-réseau assistée par le service. Elle assure un flux ininterrompu de trafic de gestion pour satisfaire un contrat SLA.

Oui. Vous pouvez analyser le trafic en provenance de votre groupe de sécurité réseau en configurant des journaux de flux Network Watcher.

Oui. Dès lors qu’une instance managée est provisionnée, vous pouvez définir le groupe de sécurité réseau qui contrôle l’accès entrant au port 1433. Il est recommandé de limiter autant que possible sa plage d’adresses IP.

Non. Ce n’est pas pris en charge pour plusieurs raisons :

• Le routage du trafic qui représente la réponse à la demande de gestion entrante serait asymétrique et ne pourrait pas fonctionner.
• Le routage du trafic à destination du stockage Azure serait concerné par les contraintes de débit et la latence, ce qui ne nous permettrait pas d'assurer la disponibilité et la qualité de service attendues.
• Ces configurations sont sujettes à des erreurs et ne sont pas prises en charge.

Oui. Le moyen le plus simple est d’ajouter la règle 0/0 à un UDR associé au sous-réseau de l’instance managée pour faire transiter le trafic par l’appliance virtuelle réseau.

Le sous-réseau doit avoir un nombre suffisant d’adresses IP disponibles. Pour déterminer la taille de sous-réseau d’un réseau virtuel pour SQL Managed Instance, consultez Déterminer la taille et la plage de sous-réseau requises pour Azure SQL Managed Instance.

S’il n’y a pas suffisamment d’adresses IP dans le sous-réseau où votre SQL Managed Instance est provisionnée, créez un sous-réseau et déplacez-y la SQL Managed Instance. Nous vous suggérons aussi de créer le nouveau sous-réseau avec davantage d’adresses IP allouées pour éviter que des situations similaires se représentent lors des futures opérations de mise à jour. Découvrez comment déplacer une instance Azure SQL Managed Instance entre des sous-réseaux.

Non. Vous pouvez utiliser un sous-réseau vide ou un sous-réseau qui contient déjà une ou plusieurs instances managées.

Non si des instances managées s’y trouvent. Il s’agit d’une limitation de l’infrastructure réseau Azure. Vous êtes seulement autorisé à ajouter un espace d’adressage supplémentaire à un sous-réseau vide.

Oui. Une instance managée SQL peut être déplacée en ligne vers un autre sous-réseau au sein du même réseau virtuel ou dans un autre réseau virtuel. Découvrez comment déplacer une instance Azure SQL Managed Instance entre des sous-réseaux.

Ce n’est pas obligatoire. Vous pouvez créer un réseau virtuel pour Azure SQL Managed Instance ou configurer un réseau virtuel existant pour Azure SQL Managed Instance.

Non. Pour l’heure, nous ne prenons pas en charge le placement d’une instance managée dans un sous-réseau qui contient déjà d’autres types de ressources.

Non, cela n’est pas pris en charge. Le nom d'hôte d'une instance mappée correspond à l'équilibreur de charge devant le cluster virtuel de la Managed Instance. Comme un cluster virtuel peut héberger plusieurs instances managées, la connexion ne peut pas être acheminée vers l’instance managée appropriée si son nom n’est pas spécifié. Pour plus d’informations sur l’architecture de cluster virtuel SQL Managed Instance, consultez Architecture de la connectivité du cluster virtuel.

Actuellement, seuls les points de terminaison privés pour les instances gérées garantissent des adresses IP statiques.

Dans des situations rares mais nécessaires, nous pouvons effectuer une migration en ligne d'une Managed Instance vers un nouveau cluster virtuel, ou un groupe de machines virtuelles différent au sein du cluster virtuel, en raison de modifications dans la pile technologique visant à améliorer la sécurité et la fiabilité du service. La migration vers un nouveau groupe de machines virtuelles ou un nouveau cluster virtuel entraîne la modification de l'adresse IP mappée au nom d'hôte de la Managed Instance. Le service de la Managed Instance ne fournit pas d'adresse IP statique et se réserve le droit de modifier l'adresse IP sans information préalable, dans le cadre de cycles de maintenance réguliers.

Pour la raison ci-dessus, les points de terminaison locaux et publics de réseau virtuel ne doivent être accessibles que via les noms de domaine associés. Nous déconseillons fortement de s'appuyer sur l'immuabilité de leur adresse IP, car cela pourrait entraîner une indisponibilité prolongée alors que le service est sain.

Si vous avez besoin d'une adresse IP statique accessible à partir de l'extérieur du réseau virtuel, vous pouvez déployer le Pare-feu Azure avec une adresse IP publique frontale et configurer une règle NAT pour traduire le trafic entrant vers le point de terminaison privé d'une instance managée. Ensuite, configurez la résolution DNS ou configurez des alias de client afin que les clients SQL se connectent à l'adresse IP publique du pare-feu via le nom de domaine complet de l'instance managée.

Oui, un point de terminaison public peut être activé pour permettre au trafic entrant d’Internet d’atteindre SQL Managed Instance. Pour plus d’informations, consultez Utiliser SQL Managed Instance avec des points de terminaison publics et Configurer un point de terminaison public dans SQL Managed Instance.

Non, l’utilisation d’un port personnalisé n’est pas disponible. Pour le point de terminaison local de réseau privé, SQL Managed Instance utilise le numéro de port par défaut 1433 et pour le point de terminaison de données public, SQL Managed Instance utilise le numéro de port par défaut 3342.

Le peering de réseau virtuel global (peering de réseaux virtuels) et Azure Virtual WAN sont les méthodes recommandées pour connecter deux instances managées dans des régions différentes. Le peering de circuits Express Route est une autre option. Si aucune option n’est possible dans votre environnement, la seule autre méthode de connectivité est une connexion VPN site à site. Configurer un réseau virtuel de site à site en utilisant le portail Azure, PowerShell ou Azure CLI

La prise en charge du peering de réseaux virtuels mondiaux pour les clusters virtuels nouvellement créés a été ajoutée à Azure SQL Managed Instance le 22 septembre 2020. Ainsi, le peering de réseaux virtuels est pris en charge pour les instances managées créées dans des sous-réseaux vides après le 22 septembre 2020. Pour les instances déployées avant cette date, la prise en charge du peering est limitée aux réseaux de la même région en raison des contraintes de l’appairage de réseaux virtuels mondiaux. Pour plus d’informations, passez en revue la section appropriée des Questions fréquentes (FAQ) sur les réseaux virtuels Azure.

Pour utiliser le peering mondial de réseaux virtuels avec des instances créées avant 2020, envisagez de configurer une fenêtre de maintenance ou de déplacer les instance dans un nouveau sous-réseau, car dans les deux cas, les instances seront déplacées dans un nouveau cluster virtuel qui prend en charge le peering mondial de réseaux virtuels.

Consultez si nécessaire Comment vérifier si le peering de réseaux virtuels mondiaux est pris en charge sur le cluster virtuel.

Afin d’atténuer les risques liés à l’exfiltration de données, il est recommandé aux clients d’appliquer un ensemble de paramètres et de contrôles de sécurité :

• Activez Transparent Data Encryption (TDE) sur toutes les bases de données.
• Désactivez Common Language Runtime (CLR). Cela est recommandé localement également.
• Utiliser l’authentification Microsoft Entra uniquement.
• Accédez à l’instance avec un compte DBA à faibles privilèges.
• Configurez l’accès au serveur de rebond (jumpbox) JIT pour le compte sysadmin.
• Activez l’audit SQL et intégrez-le à des mécanismes d’alerte.
• Activez Détection des menaces à partir de la suite Microsoft Defender pour SQL.
• Appliquez une stratégie de point de terminaison de service au sous-réseau pour contrôler le trafic sortant vers Stockage Azure.
• CREATE EXTERNAL TABLE AS SELECT (CETAS) est désactivé par défaut. Pour activer CETAS via l’option de configuration de serveur allowPolyBaseExport, consultez CREATE EXTERNAL TABLE AS SELECT (CETAS).

Oui. Consultez Résolution des noms DNS privés dans Azure SQL Managed Instance.

Oui. Consultez Résolution des noms DNS privés dans Azure SQL Managed Instance.

La configuration de fuseau horaire peut être définie lorsqu’une instance gérée est configurée pour la première fois. Le fuseau horaire d’une instance managée existante ne peut pas être modifié. Pour plus d’informations, consultez Limites liées aux fuseaux horaires.

En guise de solutions de contournement, vous pouvez créer une nouvelle instance managée avec le fuseau horaire approprié, puis soit effectuer une sauvegarde et une restauration manuelles, soit (ce que nous recommandons) effectuer une restauration à un moment donné entre les instances.

Oui, les clients peuvent créer des connexions membres du rôle sysadmin. Les clients qui assument le privilège sysadmin peuvent aussi assumer la responsabilité d’exploiter l’instance, ce qui peut avoir un impact négatif sur l’engagement du contrat SLA. Pour ajouter une connexion au rôle serveur sysadmin, consultez Authentification Microsoft Entra.

Oui, Azure SQL Managed Instance prend en charge Transparent Data Encryption (TDE). Pour plus d’informations, consultez Chiffrement transparent des données pour SQL Managed Instance.

Oui, le scénario Azure Key Vault pour BYOK est disponible pour Azure SQL Managed Instance. Pour plus d’informations, consultez Chiffrement transparent des données avec une clé gérée par le client.

Oui, vous pouvez. Pour migrer une base de données SQL Server chiffrée, vous devez exporter et importer vos certificats existants dans SQL Managed Instance, puis effectuer une sauvegarde complète de la base de données et la restaurer dans une instance managée.

Vous pouvez aussi utiliser Azure Database Migration Service pour migrer les bases de données chiffrées avec TDE.

Vous pouvez faire tourner le protecteur TDE pour SQL Managed Instance en utilisant Azure Cloud Shell. Pour obtenir des instructions, consultez Transparent Data Encryption dans SQL Managed Instance à l’aide de votre propre clé Azure Key Vault.

Oui, vous n’avez pas besoin de déchiffrer votre base de données pour pouvoir la restaurer sur SQL Managed Instance. Vous devez toutefois fournir à SQL Managed Instance un certificat/une clé servant de protecteur de clé de chiffrement sur le système source pour pouvoir lire les données du fichier de sauvegarde chiffré. Il existe deux façons d'effectuer cette opération :

• Chargez le protecteur de certificat dans SQL Managed Instance. Cela est uniquement possible à l’aide de PowerShell. L’exemple de script décrit l’ensemble du processus.
• Chargez le protecteur de clé asymétrique dans Azure Key Vault et faites pointer SQL Managed Instance vers celui-ci. . Cette approche ressemble au cas d’usage TDE BYOK (Bring Your Own Key) qui utilise également l’intégration Key Vault pour stocker la clé de chiffrement. Si vous ne souhaitez pas utiliser la clé en tant que protecteur de clé de chiffrement, mais simplement la mettre à disposition de SQL Managed Instance pour restaurer les bases de données chiffrées, suivez les instructions pour configurer BYOK TDE et ne cochez pas la case Définir la clé sélectionnée comme protecteur TDE par défaut.

Une fois que vous mettez le protecteur de chiffrement à disposition de SQL Managed Instance, vous pouvez appliquer la procédure standard de restauration de la base de données.

SQL Managed Instance propose le modèle d’achat vCore.

Voici comment vous pouvez réduire les coûts grâce aux avantages Azure SQL :

• Optimisez les investissements existants en licences locales et économisez jusqu’à 55 % avec Azure Hybrid Benefit.
• Validez une réservation pour les ressources de calcul et économisez jusqu’à 33 % avec avantages des réservations Azure. Combinez-le à Azure Hybrid Benefit pour bénéficier d’économies pouvant atteindre jusqu’à 82 %.
• Économisez jusqu’à 55 % par rapport aux prix catalogue grâce à l’avantage Tarification Azure Dev/Test qui offre des tarifs réduits pour vos charges de travail de développement et de test en cours.

Pour bénéficier de l’avantage d’instance réservée, votre type d’abonnement doit être un contrat entreprise (numéros d’offre : MS-AZR-0017P ou MS-AZR-0148p) ou un accord individuel avec paiement à l’utilisation (numéros de l’offre: MS-AZR-0003P ou MS-AZR-0023P). Pour plus d’informations sur les réservations, consultez réservations Azure.

Vous pouvez annuler, échanger ou rembourser des réservations avec certaines limitations. Pour plus d’informations, consultez Échanges et remboursements en libre-service pour les réservations Azure.

Pour explorer les options tarifaires de SQL Managed Instance, consultez la page des prix.

Vous pouvez le faire à l’aide de la solution Microsoft Cost Management. Accédez à Abonnements dans le portail Azure et sélectionnez Analyse des coûts.

Utilisez l’option Coûts cumulés, puis filtrez en fonction du type de ressource comme microsoft.sql/managedinstances.

Vous pouvez utiliser des outils clients Microsoft ou tiers compatibles pour accéder à SQL Managed Instance, et aucun coût supplémentaire n’apparaîtra sur votre facture Azure. Toutefois, si certains des outils nécessitent une licence, vous devez avoir un logiciel sous licence. Cet aspect est régi par le contrat spécifique qui vous lie à chaque fabricant d’outil.

Vous bénéficiez de la même quantité d’espace de stockage de sauvegarde gratuit que l’espace de stockage de données réservé acheté, quelle que soit la période de rétention de sauvegarde définie. Si votre consommation d’espace de stockage de sauvegarde reste dans les limites de l’espace de stockage de sauvegarde gratuit alloué, les sauvegardes automatisées dans SQL Managed Instance n’occasionnent pas de frais supplémentaires de votre côté. Autrement dit, elles sont gratuites. Une utilisation du stockage de sauvegarde qui dépasse l’espace gratuit se traduit par des coûts supplémentaires. Pour plus d’informations, consultez la section Stockage de sauvegarde de la page des tarifs. Pour plus d’informations techniques sur les sauvegardes automatisées sur SQL Managed Instance, consultez Consommation du stockage de sauvegarde expliquée.

Vous pouvez surveiller le coût du stockage de sauvegarde via le Portail Azure. Pour obtenir des instructions, consultez Superviser le coût des sauvegardes automatisées.

Pour optimiser les coûts de stockage des sauvegardes, consultez Fine backup tuning on SQL Managed Instance.

Études de cas SQL Managed Instance :

• Komatsu
• KMD
• PowerDETAILS
• Allscripts

Pour mieux comprendre les avantages, les coûts et les risques associés au déploiement d’Azure SQL Managed Instance, une étude de Forrester est également disponible : L’incidence économique globale (Total Economic Impact™) des bases de données Microsoft Azure SQL Managed Instance.

La stratégie de mot de passe SQL Managed Instance pour les connexions SQL hérite des stratégies de plateforme Azure qui sont appliquées aux machines virtuelles formant un cluster virtuel contenant l’instance managée. À l’heure actuelle, il n’est pas possible de modifier ces paramètres, car ils sont définis par Azure et hérités par l’instance managée.

Chaque connexion doit définir son mot de passe lors de la connexion, et le modifier une fois qu’il a atteint l’âge maximal.

Oui, vous pouvez contrôler les champs CHECK_POLICY et CHECK_EXPIRATION au niveau de la connexion. Vous pouvez vérifier les paramètres actuels en exécutant la commande T-SQL suivante :

SELECT *
FROM sys.sql_logins

Après cela, vous pouvez modifier les paramètres de connexion spécifiés en exécutant :

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

(Remplacez « test » par le nom de connexion souhaité et ajustez les valeurs de stratégie et d’expiration.)

Voir Rotation des certificats pour Azure SQL Database et SQL Managed Instance.

Consultez Planifier les événements de maintenance Azure dans SQL Managed Instance.

Vous pouvez voter pour une nouvelle fonctionnalité SQL Managed Instance ou créer une idée d’amélioration sur le forum de commentaires sur SQL Managed Instance. De cette façon, vous pouvez contribuer au développement du produit et nous aider à hiérarchiser nos améliorations potentielles.

Pour savoir comment créer une demande de support Azure, consultez le guide pratique pour créer une demande de support Azure.

Les modifications et fonctionnalités introduites dans la vague de fonctionnalités de novembre 2022 ont été intégrées à la majorité des instances et sont désormais disponibles par défaut. Étant donné que l’inscription d’une instance n’est plus nécessaire, les options qui mentionnent la vague de fonctionnalités de novembre 2022 ont été supprimées du Portail Azure.

La vague de fonctionnalités est disponible pour les instances des sous-réseaux éligibles. Si vous ne voyez pas de nouvelles fonctionnalités, il est probable que le sous-réseau qui contient votre SQL Managed Instance n’est pas éligible, car il se trouve toujours dans le processus d’inscription. Les instances des sous-réseaux non inscrits dans la vague continuent d’afficher la page Vague de fonctionnalités dans le portail Azure.

Pour les instances à l’intérieur d’un groupe de basculement, la modification du niveau de service vers ou depuis le niveau Usage général nouvelle génération n’est pas prise en charge. Vous devez d’abord supprimer le groupe de basculement avant de modifier l’une ou l’autre réplica, puis recréer le groupe de basculement une fois que la modification a pris effet.

La redondance de zone n’est pas prise en charge pour le niveau de service Usage général nouvelle génération.

Non, la mise à niveau vers le niveau de service Usage général nouvelle génération n’est actuellement pas prise en charge pour les pools d’instances ou les instances à l’intérieur d’un pool.