Différences T-SQL entre SQL Server et Azure SQL Managed Instance
S’applique à : Azure SQL Managed Instance
Cet article résume et explique les différences de syntaxe et de comportement entre Azure SQL Managed Instance et SQL Server.
SQL Managed Instance offre une haute compatibilité avec le moteur de base de données SQL Server, et la plupart des fonctionnalités sont prises en charge dans une instance gérée SQL.
Certaines limitations PaaS ont été introduites dans SQL Managed Instance et certains comportements ont changé par rapport à SQL Server. Les différences se répartissent en différentes catégories, à savoir :
- la disponibilité incluant les différences dans les groupes de disponibilité Always On et les sauvegardes ;
- la sécurité incluant les différences dans l’audit, les certificats, les informations d’identification, les fournisseurs de chiffrement, les connexions et les utilisateurs ainsi que la clé de service et la clé principale du service ;
- la configuration incluant les différences dans l’extension du pool de mémoires tampons, le classement, les niveaux de compatibilité, la mise en miroir de bases de données, les options de base de données, le service SQL Server Agent et les options de Table ;
- les fonctionnalités incluant BULK INSERT/OPENROWSET, CLR, DBCC, les transactions distribuées, les événements étendus, les bibliothèques externes, FILESTREAM et FileTable, la recherche sémantique de texte intégral, les serveurs liés, Polybase, la Réplication, la RESTAURATION, Service Broker, les procédures stockées, fonctions et déclencheurs.
- les paramètres d’environnement, tels que les configurations de réseau virtuel et de sous-réseau ;
La plupart de ces fonctionnalités sont des contraintes architecturales et représentent des fonctionnalités de service.
Les problèmes connus temporaires qui ont été détectés dans SQL Managed Instance et qui seront résolus ultérieurement sont décrits dans Nouveautés.
Remarque
Microsoft Entra ID était précédemment connu sous le nom d’Azure Active Directory (Azure AD).
Disponibilité
Groupes de disponibilité Always On
La haute disponibilité étant intégrée à SQL Managed Instance, les utilisateurs ne peuvent pas la contrôler. Les instructions suivantes ne sont pas prises en charge :
- CREATE ENDPOINT … FOR DATABASE_MIRRORING
- CREATE AVAILABILITY GROUP
- ALTER AVAILABILITY GROUP
- DROP AVAILABILITY GROUP
- La clause SET HADR de l’instruction ALTER DATABASE
Sauvegarde
Azure SQL Managed Instance permet d’effectuer des sauvegardes automatiques. Les utilisateurs peuvent donc créer des sauvegardes COPY_ONLY
de bases de données complètes. Les sauvegardes différentielles de fichiers journaux et de captures instantanées de fichiers ne sont pas prises en charge.
- Avec une SQL Managed Instance, vous pouvez sauvegarder une base de données d'instance seulement vers un compte de stockage Blob Azure :
- Seul
BACKUP TO URL
est pris en charge. FILE
,TAPE
et les unités de sauvegarde ne sont pas pris en charge.
- Seul
- La plupart des options générales
WITH
sont prises en charge.COPY_ONLY
est obligatoire.FILE_SNAPSHOT
etCREDENTIAL
ne sont pas pris en charge.- Options de bande :
REWIND
,NOREWIND
,UNLOAD
etNOUNLOAD
ne sont pas pris en charge. - Options propres au journal :
NORECOVERY
,STANDBY
etNO_TRUNCATE
ne sont pas pris en charge.
Limites :
Une instance gérée SQL permet de sauvegarder une base de données d’instance vers une sauvegarde comprenant jusqu’à 32 bandes, ce qui est suffisant pour des bases de données allant jusqu’à 4 To si la compression de sauvegarde est utilisée.
Vous ne pouvez pas exécuter
BACKUP DATABASE ... WITH COPY_ONLY
sur une base de données qui est chiffrée avec Transparent Data Encryption (TDE) managé par le service. TDE managé par le service oblige le chiffrement des sauvegardes à l’aide d’une clé de chiffrement TDE interne. La clé ne pouvant pas être exportée, vous ne pouvez pas restaurer la sauvegarde. utilisez des sauvegardes automatiques et la restauration dans le temps, ou utilisez TDE managé par le client (BYOK) à la place. Vous pouvez également désactiver le chiffrement sur la base de données.Les sauvegardes natives effectuées dans SQL Managed Instance peuvent être restaurées seulement sur une instance SQL Server 2022. La raison en est que SQL Managed Instance a une version de base de données interne supérieure à toutes les versions de SQL Server. Pour plus d’informations, consultez Restaurer une sauvegarde de base de données SQL Managed Instance sur SQL Server 2022.
Pour sauvegarder ou restaurer une base de données vers/à partir d’un stockage Azure, vous pouvez vous authentifier à l’aide d’une identité managée ou d’une signature d’accès partagé (SAS). Il s’agit d’un identificateur URI qui accorde des droits d’accès restreints aux ressources du stockage Azure En savoir plus. L’utilisation des clés d’accès pour ces scénarios n’est pas prise en charge.
La taille maximale de la bande de sauvegarde en utilisant la commande
BACKUP
dans une instance gérée SQL est de 195 Go, ce qui représente la taille maximale des objets blob. Augmentez le nombre de bandes défini dans la commande de sauvegarde pour réduire la taille de chaque bande et ainsi ne pas dépasser cette limite.Conseil
Pour contourner cette limitation, lorsque vous sauvegardez une base de données, soit à partir de SQL Server dans un environnement local, soit sur une machine virtuelle, vous pouvez :
- sauvegarder sur
DISK
au lieu de sauvegarder jusqu’àURL
; - charger les fichiers de sauvegarde sur le stockage d’objets blob ;
- Restaurer dans l’instance gérée SQL.
La commande
Restore
dans une instance gérée SQL prend en charge des tailles d’objet blob plus volumineuses dans les fichiers de sauvegarde, car un autre type d’objet blob est utilisé pour le stockage des fichiers de sauvegarde chargés.- sauvegarder sur
Pour plus d’informations sur les sauvegardes à l’aide de T-SQL, consultez BACKUP.
Sécurité
Audit
Les principales différences entre l’audit dans Microsoft Azure SQL et dans SQL Server sont les suivantes :
- Avec SQL Managed Instance, l’audit fonctionne au niveau du serveur. Les fichiers journaux
.xel
sont stockés dans le stockage Blob Azure. - Dans Azure SQL Database, l’audit fonctionne au niveau de la base de données. Les fichiers journaux
.xel
sont stockés dans le stockage Blob Azure. - Avec SQL Server, en local ou sur machines virtuelles, l’audit s’effectue au niveau serveur. Les événements sont stockés dans le système de fichiers ou dans les journaux des événements Windows.
L’audit XEvent dans SQL Managed Instance prend en charge les cibles de Stockage Blob Azure. Les journaux de fichiers et de Windows ne sont pas pris en charge.
Les principales différences de syntaxe CREATE AUDIT
pour l’audit du Stockage Blob Azure sont :
- Une nouvelle syntaxe
TO URL
est fournie pour spécifier l’URL du conteneur de stockage Blob Azure où sont placés les fichiers.xel
. - La syntaxe
TO FILE
n’est pas prise en charge, car SQL Managed Instance ne peut pas accéder à des partages de fichiers Windows.
Pour plus d'informations, consultez les pages suivantes :
Certificats
SQL Managed Instance ne pouvant pas accéder à des partages de fichiers et à des dossiers Windows, les contraintes suivantes s’appliquent :
- le fichier
CREATE FROM
/BACKUP TO
n’est pas pris en charge pour les certificats ; - le certificat
CREATE
/BACKUP
deFILE
/ASSEMBLY
n’est pas pris en charge ; Les fichiers de clés privés ne peuvent pas être utilisés
Consultez CREATE CERTIFICATE et BACKUP CERTIFICATE.
Solution de contournement : Au lieu de créer une sauvegarde du certificat et de restaurer la sauvegarde, obtenez le contenu binaire du certificat et la clé privée, stockez-les en tant que fichier .sql et créez à partir du binaire :
CREATE CERTIFICATE
FROM BINARY = asn_encoded_certificate
WITH PRIVATE KEY (<private_key_options>);
Informations d'identification
L’identité managée, Azure Key Vault et les identités SHARED ACCESS SIGNATURE
sont pris en charge. Les utilisateurs de Windows ne sont pas pris en charge.
Consultez CREATE CREDENTIAL et ALTER CREDENTIAL.
Fournisseurs de chiffrement
SQL Managed Instance ne pouvant pas accéder aux fichiers, vous ne pouvez pas créer de fournisseur de chiffrement :
CREATE CRYPTOGRAPHIC PROVIDER
n’est pas pris en charge. Consultez CREATE CRYPTOGRAPHIC PROVIDER.ALTER CRYPTOGRAPHIC PROVIDER
n’est pas pris en charge. Consultez ALTER CRYPTOGRAPHIC PROVIDER.
Connexions et utilisateurs
Les connexions SQL créées à l’aide de
FROM CERTIFICATE
,FROM ASYMMETRIC KEY
etFROM SID
sont prises en charge. Consultez CREATE LOGIN. Les principaux (connexions) de serveur sont créés au niveau du serveur, et les utilisateurs (principaux de base de données) sont créés au niveau de la base de données. Les connexions Microsoft Entra créées avec la syntaxe CREATE LOGIN et les utilisateurs Microsoft Entra créés avec la syntaxe CREATE USER FROM LOGIN sont pris en charge. Lors de la création d’un utilisateur et de sa spécificationFROM LOGIN
, cet utilisateur est associé à la connexion et hérite des rôles et autorisations de serveur qui lui sont attribués.SQL Managed Instance prend en charge la création d’utilisateurs de base de données autonome basés sur des identités Microsoft Entra avec la syntaxe
CREATE USER [AADUser/AAD group] FROM EXTERNAL PROVIDER
. Les utilisateurs créés de cette façon ne sont pas associés aux principaux du serveur, même si un principal de serveur portant le même nom existe dans la base de donnéesmaster
.Les connexions Windows créées avec la syntaxe
CREATE LOGIN ... FROM WINDOWS
ne sont pas prises en charge. Utilisez les connexions et les utilisateurs Microsoft Entra.L’administrateur Microsoft Entra de l’instance dispose de privilèges d’administrateur illimités.
Certaines fonctionnalités ne prennent pas en charge l’utilisation des connexions Microsoft Entra dans les interactions entre instances, mais uniquement dans une SQL Managed Instance unique, comme la réplication SQL Server. La fonctionnalité de serveur lié prend en charge l’authentification inter-instance à l’aide des principaux (connexions) de serveur Microsoft Entra.
La définition d’une connexion Microsoft Entra mappée à un groupe Microsoft Entra en tant que propriétaire de la base de données n’est pas prise en charge. Un membre du groupe Microsoft Entra peut être un propriétaire de base de données, même si la connexion n’a pas été créée dans la base de données.
L’usurpation d’identité des principaux au niveau du serveur Microsoft Entra à l’aide d’autres principaux Microsoft Entra est pris en charge, par exemple avec la clause EXECUTE AS. Les limitations EXECUTE AS sont les suivantes :
EXECUTE AS USER n’est pas pris en charge pour les utilisateurs Microsoft Entra quand le nom diffère du nom de connexion. Par exemple, quand l’utilisateur est créé par le biais de la syntaxe
CREATE USER [myAadUser] FROM LOGIN [john@contoso.com]
et que l’emprunt d’identité est tenté par le biais deEXEC AS USER = myAadUser
. Quand vous créez un USER à partir d’une connexion Microsoft Entra, spécifiez le même user_name que le login_name à partir de LOGIN.Seules les connexions au niveau de SQL Server titulaires du rôle
sysadmin
peuvent exécuter les opérations suivantes ciblant des principaux Microsoft Entra :- EXECUTE AS USER
- EXECUTE AS LOGIN
Pour emprunter l’identité d’un utilisateur avec l’instruction EXECUTE AS, l’utilisateur doit être mappé directement à la connexion Microsoft Entra. Les utilisateurs membres de groupes Microsoft Entra mappés aux principaux de serveur Microsoft Entra ne peuvent pas faire l’objet d’un emprunt d’identité à l’aide de l’instruction EXECUTE AS, même si l’appelant dispose d’autorisations d’emprunt d’identité sur le nom d’utilisateur spécifié.
L’exportation/importation de bases de données à l’aide de fichiers bacpac est prise en charge pour les utilisateurs Microsoft Entra dans SQL Managed Instance avec SSMS v18.4 ou ultérieur et SqlPackage.
- Les configurations suivantes sont prises en charge avec le fichier de base de données bacpac :
- Exporter/importer une base de données entre différentes Managed Instances dans le même domaine Microsoft Entra.
- Exporter une base de données à partir de SQL Managed Instance et l’importer dans SQL Database au sein du même domaine Microsoft Entra.
- Exporter une base de données à partir de SQL Database et l’importer dans SQL Managed Instance au sein du même domaine Microsoft Entra.
- Exporter une base de données à partir de SQL Managed Instance et l’importer dans SQL Server (version 2012 ou ultérieure).
- Dans cette configuration, tous les utilisateurs Microsoft Entra sont créés en tant que principaux (utilisateurs) de base de données SQL Server sans connexions. Le type d’utilisateur est
SQL
et se présente sous la formeSQL_USER
danssys.database_principals
. Leurs autorisations et leurs rôles restent dans les métadonnées de la base de données SQL Server et peuvent être utilisés pour l’emprunt d’identité. Toutefois, ils ne peuvent pas être utilisés pour accéder et se connecter à SQL Server à l’aide de leurs informations d’identification.
- Dans cette configuration, tous les utilisateurs Microsoft Entra sont créés en tant que principaux (utilisateurs) de base de données SQL Server sans connexions. Le type d’utilisateur est
- Les configurations suivantes sont prises en charge avec le fichier de base de données bacpac :
Seule la connexion du principal au niveau du serveur, qui est créée par le processus de provisionnement de SQL Managed Instance, les membres des rôles de serveur, tels que
securityadmin
ousysadmin
, ou d’autres connexions disposant de l’autorisation ALTER ANY LOGIN au niveau du serveur peuvent créer les principaux de serveur (connexions) Microsoft Entra dans la base de donnéesmaster
pour SQL Managed Instance.Les connexions basées sur l’authentification SQL doivent être affectées au rôle
sysadmin
pour créer des connexions pour les identités Microsoft Entra.La connexion doit être membre du même locataire Microsoft Entra que celui dans lequel Azure SQL Managed Instance est hébergé.
Les principaux de serveur (connexions) Microsoft Entra sont visibles dans l’Explorateur d’objets à compter de SQL Server Management Studio 18.0 préversion 5.
Un principal de serveur avec le niveau d’accès sysadmin est automatiquement créé pour l’administrateur Microsoft Entra une fois qu’il est activé sur une instance.
Lors de l’authentification, la séquence suivante est appliquée pour résoudre le principal d’authentification :
- Si le compte Microsoft Entra est mappé directement à une connexion Microsoft, qui est présent dans
sys.server_principals
en tant que type « E », autorisez l’accès et appliquez les autorisations de l’utilisateur à cette connexion. - Si le compte Microsoft Entra membre d’un groupe qui est mappé directement à une connexion Microsoft, qui est présent dans
sys.server_principals
en tant que type « X », autorisez l’accès et appliquez les autorisations de l’utilisateur à cette connexion. - Si le compte Microsoft Entra existe en tant que mappage direct à un utilisateur Microsoft Entra dans une base de données, qui est présent dans
sys.database_principals
en tant que type « E », l’accès est accordé et les autorisations de l’utilisateur de base de données Microsoft Entra sont appliquées. - Si le compte Microsoft Entra est membre d’un groupe Microsoft Entra qui est mappé à un utilisateur Microsoft Entra dans une base de données, qui est présent dans
sys.database_principals
en tant que type « X », autorisez l’accès et appliquez les autorisations de l’utilisateur à cette connexion.
- Si le compte Microsoft Entra est mappé directement à une connexion Microsoft, qui est présent dans
Clé de service et clé principale de service
- Backup master key n’est pas pris en charge (géré par le service SQL Database).
- Restore master key n’est pas pris en charge (géré par le service SQL Database).
- Backup service master key n’est pas pris en charge (géré par le service SQL Database).
- Restore service master key n’est pas pris en charge (géré par le service SQL Database).
Configuration
Extension du pool de mémoires tampons
- L’extension du pool de mémoires tampons n’est pas prise en charge.
ALTER SERVER CONFIGURATION SET BUFFER POOL EXTENSION
n’est pas pris en charge. Consultez ALTER SERVER CONFIGURATION.
Classement
Le classement d’instance par défaut est SQL_Latin1_General_CP1_CI_AS
et peut être spécifié comme paramètre de création. Consultez Classements.
Niveaux de compatibilité
- Les niveaux de compatibilité pris en charge sont 100, 110, 120, 130, 140, 150 et 160.
- Les niveaux de compatibilité inférieurs à 100 ne sont pas pris en charge.
- Le niveau de compatibilité par défaut est de 150 pour les nouvelles bases de données. Pour les bases de données restaurées, le niveau de compatibilité reste inchangé s’il était de 100 et plus.
Consultez Niveau de compatibilité ALTER TABLE (Transact-SQL).
Mise en miroir de bases de données
La mise en miroir de bases de données n’est pas prise en charge.
- Les options
ALTER DATABASE SET PARTNER
etSET WITNESS
ne sont pas prises en charge. CREATE ENDPOINT … FOR DATABASE_MIRRORING
n’est pas pris en charge.
Pour plus d’informations, consultez ALTER DATABASE SET PARTNER AND SET WITNESS et CREATE ENDPOINT … FOR DATABASE_MIRRORING.
Options de la base de données
- Les fichiers journaux multiples ne sont pas pris en charge.
- Les objets en mémoire ne sont pas pris en charge dans le niveau de service Usage général.
- Il existe une limite de 280 fichiers par instance Usage général, ce qui implique un maximum de 280 fichiers par base de données. Les fichiers de données et de journaux du niveau Usage général sont tous les deux comptabilisés dans cette limite. Le niveau Critique pour l’entreprise prend en charge 32 767 fichiers par base de données.
- La base de données ne peut pas contenir de groupes de fichiers qui contiennent des données FILESTREAM. La restauration échoue si le
.bak
contient des donnéesFILESTREAM
. - Chaque fichier est placé dans Stockage Blob Azure. L’E/S et le débit par fichier dépendent de la taille de chaque fichier.
CREATE DATABASE, instruction
Les limites suivantes s’appliquent à CREATE DATABASE
:
Les fichiers et les groupes de fichiers ne peuvent pas être définis.
Un groupe de fichiers et un fichier à mémoire optimisée sont automatiquement ajoutés et sont appelés XTP.
L’option
CONTAINMENT
n’est pas prise en charge.Les options
WITH
ne sont pas prises en charge.Conseil
Comme solution de contournement, utilisez
ALTER DATABASE
aprèsCREATE DATABASE
pour définir les options de la base de données de manière à ajouter des fichiers ou pour définir l’autonomie.L’option
FOR ATTACH
n’est pas prise en charge.L’option
AS SNAPSHOT OF
n’est pas prise en charge.
Pour plus d’informations, consultez CREATE DATABASE.
ALTER DATABASE, instruction
Certaines propriétés de fichiers ne peuvent pas être définies ou modifiées :
- Un chemin de fichier ne peut pas être spécifié dans l’instruction T-SQL
ALTER DATABASE ADD FILE (FILENAME='path')
. EnlevezFILENAME
du script car SQL Managed Instance place les fichiers automatiquement. - Un nom de fichier ne peut pas être modifié à l’aide de l’instruction
ALTER DATABASE
. - La modification du fichier ou du groupe de fichiers XTP n’est pas autorisée.
Les options suivantes sont définies par défaut et ne peuvent pas être modifiées :
MULTI_USER
ENABLE_BROKER
AUTO_CLOSE OFF
Les options suivantes ne peuvent pas être modifiées :
AUTO_CLOSE
AUTOMATIC_TUNING(CREATE_INDEX=ON|OFF)
AUTOMATIC_TUNING(DROP_INDEX=ON|OFF)
DISABLE_BROKER
EMERGENCY
ENABLE_BROKER
FILESTREAM
HADR
NEW_BROKER
OFFLINE
PAGE_VERIFY
PARTNER
READ_ONLY
RECOVERY BULK_LOGGED
RECOVERY_SIMPLE
REMOTE_DATA_ARCHIVE
RESTRICTED_USER
SINGLE_USER
WITNESS
Certaines instructions ALTER DATABASE
(par exemple SET CONTAINMENT) peuvent échouer temporairement, par exemple pendant la sauvegarde automatisée de la base de données ou immédiatement après la création d’une base de données. Dans ce cas, l’instruction ALTER DATABASE
doit être retentée. Pour plus d’informations sur les messages d’erreur, consultez la section Notes.
Pour en savoir plus, consultez ALTER DATABASE.
SQL Server Agent
- L’activation et la désactivation de SQL Server Agent ne sont actuellement pas prises en charge dans SQL Managed Instance. L’Agent SQL est toujours en cours d’exécution.
- Le déclencheur de calendrier des tâches basé sur une UC inactive n’est pas pris en charge.
- Les paramètres de SQL Server Agent sont en lecture seule. La procédure
sp_set_agent_properties
n’est pas prise en charge dans SQL Managed Instance. - Travaux
- Les étapes de travail T-SQL sont prises en charge.
- Les travaux de réplication suivants sont pris en charge :
- Lecteur de journaux de transactions
- Instantané
- Serveur de distribution
- Les étapes de travail SSIS sont prises en charge.
- Les autres types d'étapes de travail ne sont pas pris en charge actuellement :
- L’étape de travail de réplication de fusion n’est pas prise en charge.
- L’agent de lecture de la file d’attente n’est pas pris en charge.
- L’interpréteur de commandes n’est pas encore pris en charge.
- SQL Managed Instance ne peut pas accéder à des ressources externes, par exemple des partages réseau via robocopy.
- SQL Server Analysis Services n’est pas pris en charge.
- Les notifications sont partiellement prises en charge.
- Les notifications par e-mail sont prises en charge bien qu’elles nécessitent de votre part la configuration d’un profil Database Mail. SQL Server Agent ne peut utiliser qu’un seul profil Database Mail, et il doit être appelé
AzureManagedInstance_dbmail_profile
.- Le récepteur d’appel n’est pas pris en charge.
- NetSend n’est pas pris en charge.
- Les alertes ne sont pas encore prises en charge.
- Les proxies ne sont pas pris en charge.
- EventLog n’est pas pris en charge.
- L’utilisateur doit être directement mappé à la connexion de serveur Microsoft Entra pour pouvoir créer, modifier ou exécuter des travaux SQL Agent. Les utilisateurs qui ne sont pas directement mappés, par exemple les utilisateurs membres d’un groupe Microsoft Entra qui dispose des droits de création, de modification ou d’exécution des travaux SQL Agent, ne peuvent pas effectuer efficacement ces actions. Cela est dû à l’emprunt d’identité SQL Managed Instance et aux limitations d’EXECUTE AS.
- La fonctionnalité d’administration multiserveur pour les travaux maître/cible (MSX/TSX) n’est pas prise en charge.
Pour plus d’informations sur SQL Server Agent, consultez SQL Server Agent.
Tables
Les types de tables suivantes ne sont pas prises en charge :
- FILESTREAM
- FILETABLE
- EXTERNAL TABLE (sauf PolyBase)
- MEMORY_OPTIMIZED (non pris en charge uniquement dans le niveau usage général)
Pour plus d’informations sur la façon de créer et de modifier des tables, consultez CREATE TABLE et ALTER TABLE.
Fonctionnalités
BULK INSERT / OPENROWSET
SQL Managed Instance ne pouvant pas accéder à des partages de fichiers et à des dossiers Windows, les fichiers doivent être importés à partir du stockage Blob Azure :
DATASOURCE
est requis dans la commandeBULK INSERT
lors de l’importation des fichiers depuis le Stockage Blob Azure. Consultez BULK INSERT.DATASOURCE
est nécessaire dans la fonctionOPENROWSET
lorsque vous lisez le contenu d’un fichier à partir du stockage Blob Azure. Consultez OPENROWSET.OPENROWSET
peut être utilisé pour lire des données à partir d’Azure SQL Database, Azure SQL Managed Instance, ou d’instances SQL Server. Les autres sources, telles que les bases de données Oracle ou les fichiers Excel, ne sont pas prises en charge.
CLR
SQL Managed Instance ne pouvant pas accéder à des partages de fichiers et à des dossiers Windows, les contraintes suivantes s’appliquent :
- Seul
CREATE ASSEMBLY FROM BINARY
est pris en charge. Consultez CREATE ASSEMBLY FROM BINARY. CREATE ASSEMBLY FROM FILE
n’est pas pris en charge. Consultez CREATE ASSEMBLY FROM FILE.ALTER ASSEMBLY
ne peut pas référencer des fichiers. Consultez ALTER ASSEMBLY.
Database Mail (db_mail)
sp_send_dbmail
ne peut pas envoyer de pièces jointes à l’aide du paramètre @file_attachments. Le système de fichiers local ainsi que les partages externes ou le Stockage Blob Azure ne sont pas accessibles avec cette procédure.- Consultez les problèmes connus liés au paramètre
@query
et à l’authentification.
DBCC
Les instructions DBCC non documentées qui sont activées dans SQL Server ne sont pas prises en charge dans SQL Managed Instance.
- Seuls un nombre limité d’indicateurs de trace globaux sont pris en charge. Les
Trace flags
de session ne sont pas pris en charge. Consultez les indicateurs de trace. - DBCC TRACEOFF et DBCC TRACEON fonctionnent avec le nombre limité d’indicateurs de trace globaux.
- DBCC CHECKDB ne peut pas être utilisé avec les options REPAIR_ALLOW_DATA_LOSS, REPAIR_FAST et REPAIR_REBUILD, car la base de données ne peut pas être définie sur le mode
SINGLE_USER
. Consultez l’article sur les différences avec ALTER DATABASE. L’endommagement potentiel de la base de données est géré par l’équipe de support Azure. Contactez le support Azure si vous constatez des signes de corruption de la base de données.
Transactions distribuées
Les transactions distribuées basées sur T-SQL et .NET entre les instances managées sont en disponibilité générale. D’autres scénarios, tels que les transactions XA, les transactions distribuées entre des instances managées et d’autres participants, sont pris en charge avec DTC pour Azure SQL Managed Instance, qui est disponible en préversion publique.
Événements étendus
Certaines cibles propres à Windows pour les événements étendus (XEvent) ne sont pas prises en charge :
- Le
etw_classic_sync
cible n’est pas pris en charge. Stockez les fichiers.xel
dans le stockage Blob Azure. Consultez etw_classic_sync target. - Le
event_file
cible n’est pas pris en charge. Stockez les fichiers.xel
dans le stockage Blob Azure. Consultez event_file target.
Bibliothèques externes
Les bibliothèques externes R et Python dans la base de données sont prises en charge dans la préversion publique limitée. Consultez Machine Learning Services dans Azure SQL Managed Instance (préversion).
FILESTREAM et FileTable
- Les données FILESTREAM ne sont pas prises en charge.
- La base de données ne peut pas contenir de groupes de fichiers avec des données
FILESTREAM
. FILETABLE
n’est pas pris en charge.- Les tables ne peuvent pas avoir de types
FILESTREAM
. - Les fonctions suivantes ne sont pas prises en charge :
GetPathLocator()
GET_FILESTREAM_TRANSACTION_CONTEXT()
PathName()
GetFileNamespacePat)
FileTableRootPath()
Pour plus d’informations, consultez FILESTREAM et FileTables.
Recherche sémantique de texte intégral
La recherche sémantique n’est pas prise en charge.
Serveurs liés
Les serveurs liés dans SQL Managed Instance prennent en charge un nombre limité de cibles :
- Les cibles prises en charge sont SQL Managed Instance, SQL Database, Azure Synapse SQL serverless et les pools dédiés, ainsi que les instances SQL Server.
- Les cibles qui ne sont pas prises en charge sont des fichiers, Analysis Services et d’autres SGBDR. Essayez d’utiliser l’importation CSV native à partir du Stockage Blob Azure à l’aide de
BULK INSERT
ouOPENROWSET
comme alternative pour l’importation de fichiers, ou chargez des fichiers à l’aide d’un pool SQL serverless dans Azure Synapse Analytics.
Opérations :
sp_dropserver
est pris en charge pour supprimer un serveur lié. Consultez sp_dropserver.- La fonction
OPENROWSET
peut être utilisée pour exécuter des requêtes uniquement sur des instances SQL Server. Elles peuvent être managées, locales ou dans des machines virtuelles. Consultez OPENROWSET. - La fonction OPENDATASOURCE peut être utilisée pour exécuter des requêtes uniquement sur des instances SQL Server. Elles peuvent être managées, locales ou dans des machines virtuelles. par exemple
SELECT * FROM OPENDATASOURCE('SQLNCLI', '...').AdventureWorks2022.HumanResources.Employee
. Seules les valeursSQLNCLI
,SQLNCLI11
,SQLOLEDB
etMSOLEDBSQL
sont prises en charge en tant que fournisseur. SQL Server Native Client (souvent abrégé sous la forme de SNAC) a été supprimé dans SQL Server 2022 et SQL Server Management Studio 19 (SSMS). SQL Server Native Client (SQLNCLI ou SQLNCLI11) et le fournisseur OLE DB Microsoft hérité pour SQL Server (SQLOLEDB) ne sont pas recommandés dans les nouveaux développements. Utilisez à la place le nouveau Microsoft OLE DB Driver (MSOLEDBSQL) pour SQL Server ou le Microsoft ODBC Driver for SQL Server le plus récent. - Les serveurs liés ne peuvent pas être utilisés pour lire des fichiers (Excel, CSV) à partir des partages réseau. Essayez d’utiliser BULK INSERT, OPENROWSET qui lit les fichiers CSV à partir du Stockage Blob Azure, ou un serveur lié qui fait référence à un pool SQL serverless dans Synapse Analytics. Suivez ces requêtes sur l’élément de commentaires de SQL Managed Instance
Les serveurs liés sur Azure SQL Managed Instance prennent en charge l’authentification SQL et l’authentification Microsoft Entra.
PolyBase
La virtualisation des données avec Azure SQL Managed Instance vous permet d’exécuter des requêtes Transact-SQL (T-SQL) sur des données de fichiers stockés dans Azure Data Lake Storage Gen2 ou dans Stockage Blob Azure, et de les combiner avec des données relationnelles stockées localement à l’aide de jointures. Les formats de fichiers Parquet et texte délimité (CSV) sont directement pris en charge. Le format de fichier JSON est pris en charge indirectement en spécifiant le format de fichier CSV dans lequel les requêtes retournent chaque document sous la forme d’une ligne distincte. Il est possible d’analyser les lignes plus en détail à l’aide de JSON_VALUE
et OPENJSON
. Pour des informations générales sur PolyBase, consultez PolyBase.
Par ailleurs, CREATE EXTERNAL TABLE AS SELECT (CETAS) vous permet d’exporter des données de votre instance managée SQL vers un compte de stockage externe. Vous pouvez utiliser CETAS pour créer une table externe par-dessus des fichiers Parquet ou CSV dans le Stockage Blob Azure ou Azure Data Lake Storage (ADLS) Gen2. CETAS peut également exporter, en parallèle, les résultats d’une instruction SELECT T-SQL dans la table externe créée.
Réplication
- Les types de réplication d’instantané et bidirectionnelle sont pris en charge. La réplication de fusion, la réplication d’égal à égal et les abonnements modifiables ne sont pas pris en charge.
- La réplication transactionnelle est disponible dans SQL Managed Instance avec quelques contraintes :
- Tous les types de participants à la réplication (serveur de publication, serveur de distribution, abonné d’extraction et abonné de type push) peuvent être placés sur SQL Managed Instance, mais le serveur de publication et le serveur de distribution doivent être tous deux dans le cloud ou locaux.
- SQL Managed Instance peut communiquer avec les versions récentes de SQL Server. Pour plus d’informations, consultez la matrice des versions prises en charge.
- La réplication transactionnelle présente des exigences de mise en réseau supplémentaires.
Pour plus d’informations sur la configuration de la réplication transactionnelle, consultez les tutoriels suivants :
- Réplication entre un éditeur d’instance gérée SQL et un abonné d’instance gérée SQL
- Réplication entre un éditeur d’instance gérée SQL, un distributeur d’instance gérée SQL et un abonné SQL Server
L’instruction RESTORE
- Syntaxe prise en charge :
RESTORE DATABASE
RESTORE FILELISTONLY
RESTORE HEADERONLY
RESTORE LABELONLY
RESTORE VERIFYONLY
- Syntaxe non prise en charge :
RESTORE LOGONLY
RESTORE REWINDONLY
- Source :
FROM URL
(Stockage Blob Azure) est l’unique option prise en charge.- L’unité de sauvegarde/
FROM DISK
/TAPE
n’est pas prise en charge. - Les jeux de sauvegarde ne sont pas pris en charge.
- Les options
WITH
ne sont pas prises en charge. Les tentatives de restauration incluantWITH
telles queDIFFERENTIAL
,STATS
,REPLACE
, etc. échouent.
Une opération de restauration des bases de données est asynchrone et réessayable dans Azure SQL Managed Instance. Il se peut que vous obteniez une erreur dans SSMS si la connexion échoue ou si un délai d’attente expire. Azure SQL Managed Instance continue d’essayer de restaurer la base de données en arrière-plan et vous pouvez suivre l’avancement du processus de restauration dans les vues de gestion dynamique sys.dm_exec_requests et sys.dm_operation_status.
Les options de base de données suivantes sont fixées ou remplacées et ne peuvent pas être modifiées ultérieurement :
NEW_BROKER
si le broker n’est pas activé dans le fichier .bak.ENABLE_BROKER
si le broker n’est pas activé dans le fichier .bak.AUTO_CLOSE=OFF
si une base de données dans le fichier .bak comprendAUTO_CLOSE=ON
.RECOVERY FULL
si une base de données dans le fichier .bak a le mode de récupérationSIMPLE
ouBULK_LOGGED
.- Un groupe de fichiers à mémoire optimisée est ajouté et appelé XTP s’il n’était pas dans le fichier .bak source.
- Tout groupe de fichiers à mémoire optimisée existant est renommé XTP.
- Les options
SINGLE_USER
etRESTRICTED_USER
sont changées enMULTI_USER
.
Limites :
- Les sauvegardes des bases de données endommagées peuvent être restaurées en fonction du type d’altération, mais les sauvegardes automatisées ne sont pas effectuées tant que la corruption n’est pas corrigée. Assurez-vous que vous exécutez
DBCC CHECKDB
sur l’instance gérée SQL source et utilisez la sauvegardeWITH CHECKSUM
afin d’éviter ce problème. - La restauration d’un fichier
.BAK
d’une base de données qui contient une limitation décrite dans ce document (par exemple,FILESTREAM
ou des objetsFILETABLE
) ne peut pas être restaurée sur SQL Managed instance. - Les fichiers
.BAK
qui contiennent plusieurs jeux de sauvegarde ne peuvent pas être restaurés. - Les fichiers
.BAK
qui contiennent plusieurs fichiers journaux ne peuvent pas être restaurés. - Les sauvegardes contenant des bases de données dont la taille excède 8 To, contenant des objets OLTP en mémoire actifs ou comprenant plus de 280 fichiers par instance ne peuvent pas être restaurées sur une instance d’usage général.
- Les sauvegardes contenant des bases de données dont la taille excède 4 To ou contenant des objets OLTP en mémoire dont la taille totale est supérieure à la taille spécifiée dans les limites de ressources ne peuvent pas être restaurées sur une instance critique pour l’entreprise. Pour plus d’informations sur les instructions de restauration, consultez Instructions RESTORE.
Important
Les mêmes limitations s’appliquent à une opération de restauration dans le temps intégrée. À titre d’exemple, une base de données à usage général dont la taille est supérieure à 4 To ne peut pas être restaurée sur une instance critique pour l’entreprise. Une base de données critique pour l’entreprise comprenant des fichiers OLTP en mémoire ou plus 280 fichiers ne peut pas être restaurée sur une instance à usage général.
Service Broker
L’échange de messages Service Broker entre les instances est pris en charge uniquement entre des instances Azure SQL Managed Instances :
CREATE ROUTE
: vous ne pouvez pas utiliserCREATE ROUTE
avecADDRESS
autre queLOCAL
ou le nom DNS d’une autre Managed instance SQL. Le port est toujours 4022.ALTER ROUTE
: vous ne pouvez pas utiliserALTER ROUTE
avecADDRESS
autre queLOCAL
ou le nom DNS d’une autre Managed instance SQL. Le port est toujours 4022.
La sécurité du transport est prise en charge, pas la sécurité du dialogue :
CREATE REMOTE SERVICE BINDING
n’est pas pris en charge.
Service Broker est activé par défaut et ne peut pas être désactivé. Les options ALTER DATABASE suivantes ne sont pas prises en charge :
ENABLE_BROKER
DISABLE_BROKER
Procédures stockées, fonctions et déclencheurs
NATIVE_COMPILATION
n’est pas pris en charge dans le niveau Usage général.- Les options sp_configure suivantes ne sont pas prises en charge :
allow polybase export
allow updates
filestream_access_level
remote access
remote data archive
remote proc trans
scan for startup procs
- Les options sp_configure suivantes sont ignorées et n'ont aucun effet :
Ole Automation Procedures
sp_execute_external_scripts
est uniquement pris en charge pour les Machine Learning Services pour SQL MI ; sinon,sp_execute_external_scripts
n’est pas pris en charge pour SQL Managed Instance. Consultez sp_execute_external_scripts.xp_cmdshell
n’est pas pris en charge. Consultez xp_cmdshell.- Les
Extended stored procedures
, à savoirsp_addextendedproc
etsp_dropextendedproc
, ne sont pas pris en charge. Cette fonctionnalité n’est pas prise en charge, car elle est en voie de dépréciation pour SQL Server. Pour plus d’informations, consultez Procédures stockées étendues. sp_attach_db
,sp_attach_single_file_db
etsp_detach_db
ne sont pas pris en charge. Consultez sp_attach_db, sp_attach_single_file_db et sp_detach_db.
Fonctions et variables système
Les variables, fonctions et vues suivantes retournent des résultats différents :
SERVERPROPERTY('EngineEdition')
retourne la valeur 8. Cette propriété identifie une instance gérée SQL de façon unique. Consultez SERVERPROPERTY.SERVERPROPERTY('InstanceName')
retourne la valeur NULL, car le concept d’instance tel qu’il existe pour SQL Server ne s’applique pas à une instance gérée SQL. Consultez SERVERPROPERTY(« InstanceName »).@@SERVERNAME
retourne un nom DNS « connectable » complet, par exemplemy-managed-instance.wcus17662feb9ce98.database.windows.net
. Voir @@SERVERNAME.SYS.SERVERS
retourne le nom DNS « connectable » complet, tel quemyinstance.domain.database.windows.net
pour les propriétés « name » et « data_source ». Voir SYS.SERVERS.@@SERVICENAME
retourne la valeur NULL, car le concept de service tel qu’il existe pour SQL Server ne s’applique pas à une instance gérée SQL. Voir @@SERVICENAME.SUSER_ID
est pris en charge. Elle retourne la valeur NULL si la connexion Microsoft Entra n’est pas danssys.syslogins
. Consultez SUSER_ID.SUSER_SID
n’est pas pris en charge. Les données incorrectes sont retournées, ce qui est un problème temporaire connu. Consultez SUSER_SID.
Contraintes d’environnement
Sous-réseau
- Vous ne pouvez pas placer d’autres ressources (par exemple des machines virtuelles) dans le sous-réseau sur lequel vous avez déployé votre SQL Managed Instance. Déployez ces ressources à l’aide d’un sous-réseau différent.
- Le sous-réseau doit avoir un nombre suffisant d’adresses IP disponibles. Le nombre minimal est de 32 adresses IP dans le sous-réseau.
- Le nombre de vCores et de types d’instances que vous pouvez déployer dans une région ont certaines contraintes et limites.
- Il existe une configuration de la mise en réseau qui doit être appliquée au sous-réseau.
Réseau virtuel
- Le réseau virtuel peut être déployé à l’aide du modèle de ressource. Le modèle classique ne prend pas en charge le déploiement de réseau virtuel (VNet).
- Après avoir créé une SQL Managed Instance, le déplacement de celle-ci ou du VNet vers un autre groupe de ressources ou abonnement n’est pas pris en charge.
- Pour les SQL Managed Instances hébergées dans des clusters virtuels créés avant le 22 septembre 2020, l’appairage de réseau virtuel mondial n’est pas pris en charge. Vous pouvez vous connecter à ces ressources via ExpressRoute ou une connexion entre deux réseaux virtuels, par l’intermédiaire de passerelles de réseau virtuel.
Groupes de basculement
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.
tempdb
- La taille maximale de la base de données système
tempdb
ne peut pas être supérieure à 24 Go par cœur sur un niveau Usage général. La taille maximale detempdb
sur un niveau Critique pour l’entreprise est limitée à la taille de stockage de SQL Managed Instance. La taille du fichier journaltempdb
est limitée à 120 Go sur le niveau Usage général. Certaines requêtes peuvent retourner une erreur si elles ont besoin de plus de 24 Go par cœur danstempdb
ou si elles produisent plus de 120 Go de données de journal. tempdb
est toujours divisée en 12 fichiers de données : 1 fichier de données principal, également appelémaster
, et 11 fichiers de données non principaux. La structure de fichier ne peut pas être modifiée et de nouveaux fichiers ne peuvent pas être ajoutés àtempdb
.- Les métadonnées TempDB à mémoire optimisée, une nouvelle fonctionnalité de base de données en mémoire SQL Server 2019, ne sont pas prises en charge.
- Les objets créés dans la base de données
model
ne peuvent pas être créés automatiquement danstempdb
après un redémarrage ou un basculement, cartempdb
n’obtient pas sa liste initiale d’objets de la base de donnéesmodel
. Vous devez créer des objets danstempdb
manuellement après chaque redémarrage ou après un basculement.
msdb
Les schémas suivants dans la base de données système msdb
de SQL Managed Instance doivent être détenus par leurs rôles prédéfinis respectifs :
- Rôles généraux
- TargetServersRole
- Rôles de base de données fixes
- SQLAgentUserRole
- SQLAgentReaderRole
- SQLAgentOperatorRole
- Rôles DatabaseMail :
- DatabaseMailUserRole
- Rôles de service d'intégration :
- db_ssisadmin
- db_ssisltduser
- db_ssisoperator
Important
La modification des noms de rôles prédéfinis, des noms de schéma et des propriétaires de schéma prédéfinis par les clients aura un impact sur le fonctionnement normal du service. Toutes les modifications apportées à ces valeurs seront restaurées aux valeurs prédéfinies dès qu’elles seront détectées, ou au plus tard lors de la prochaine mise à jour du service et ce, pour garantir un fonctionnement normal de ce dernier.
Journaux des erreurs
SQL Managed Instance ajoute des informations détaillées dans les journaux des erreurs. Beaucoup d’événements système internes sont journalisés dans le journal des erreurs. utilisez une procédure personnalisée pour lire les journaux des erreurs en excluant les entrées non pertinentes. Pour plus d’informations, consultez SQL Managed Instance – sp_readmierrorlog ou Extension SQL Managed Instance (préversion) pour Azure Data Studio.
La modification du nombre de journaux d’erreurs conservés n’est pas prise en charge.