Différences T-SQL entre SQL Server et Azure SQL Managed Instance

  • Article

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.

Diagram showing the easy migration from SQL Server.

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 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 :

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.
  • La plupart des options générales WITH sont prises en charge.
    • COPY_ONLY est obligatoire.
    • FILE_SNAPSHOT et CREDENTIAL ne sont pas pris en charge.
    • Options de bande : REWIND, NOREWIND, UNLOAD et NOUNLOAD ne sont pas pris en charge.
    • Options propres au journal : NORECOVERY, STANDBY et NO_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.

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 de FILE/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 :

Connexions et utilisateurs

  • Les connexions SQL créées à l’aide de FROM CERTIFICATE, FROM ASYMMETRIC KEY et FROM 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écification FROM 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ées master.

  • 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 de EXEC 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 forme SQL_USER dans sys.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.

  • 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 ou sysadmin, 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ées master 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 :

    1. 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.
    2. 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.
    3. 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.
    4. 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.

Clé de service et clé principale de service

Configuration

Extension du pool de mémoires tampons

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 et SET 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ées FILESTREAM.
  • 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ès CREATE 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'). Enlevez FILENAME 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 :

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 commande BULK INSERT lors de l’importation des fichiers depuis le Stockage Blob Azure. Consultez BULK INSERT.
  • DATASOURCE est nécessaire dans la fonction OPENROWSET 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 :

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 ou OPENROWSET 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 valeurs SQLNCLI, SQLNCLI11, SQLOLEDB et MSOLEDBSQL 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 :

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 incluant WITH telles que DIFFERENTIAL, 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 comprend AUTO_CLOSE=ON.
  • RECOVERY FULL si une base de données dans le fichier .bak a le mode de récupération SIMPLE ou BULK_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 et RESTRICTED_USER sont changées en MULTI_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 sauvegarde WITH 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 objets FILETABLE) 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 utiliser CREATE ROUTE avec ADDRESS autre que LOCAL ou le nom DNS d’une autre Managed instance SQL. Le port est toujours 4022.
  • ALTER ROUTE : vous ne pouvez pas utiliser ALTER ROUTE avec ADDRESS autre que LOCAL 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, à savoir sp_addextendedproc et sp_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 et sp_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 »).
  • @@SERVERNAMEretourne un nom DNS « connectable » complet, par exemple my-managed-instance.wcus17662feb9ce98.database.windows.net. Voir @@SERVERNAME.
  • SYS.SERVERS retourne le nom DNS « connectable » complet, tel que myinstance.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 dans sys.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

Subnet

  • 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 de tempdb sur un niveau Critique pour l’entreprise est limitée à la taille de stockage de SQL Managed Instance. La taille du fichier journal tempdb 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 dans tempdb 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 dans tempdb après un redémarrage ou un basculement, car tempdb n’obtient pas sa liste initiale d’objets de la base de données model. Vous devez créer des objets dans tempdb 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 :

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.

Contenu connexe