Différences de T-SQL entre SQL Server et Azure SQL Database

Lors de la migration de votre base de données de SQL Server vers Azure SQL Database, vous pouvez découvrir que vos bases de données SQL Server nécessitent une re-ingénierie avant de pouvoir être migrées. Cet article comprend des informations vous permettant d’apporter les révisions nécessaires et de comprendre les raisons sous-jacentes à ces changements. Pour détecter les incompatibilités et migrer des bases de données vers Azure SQL Database, utilisez Azure Data Migration Service.

Vue d’ensemble

La plupart des fonctionnalités Transact-SQL (T-SQL) utilisées par les applications sont entièrement prises en charge dans Microsoft SQL Server et Azure SQL Database. Par exemple, les principaux composants SQL tels que les types de données, les opérateurs ainsi que les fonctions de chaîne, arithmétiques, logiques et de curseur fonctionnent de la même façon dans SQL Server et SQL Database. Il existe toutefois quelques différences au niveau des éléments du langage de définition de données (DDL) et des éléments du langage de manipulation de données (DML). Ceux-ci génèrent en effet des instructions et des requêtes T-SQL qui ne sont que partiellement prises en charge (nous y reviendrons plus loin dans cet article).

Par ailleurs, Azure SQL Database étant conçu pour isoler les fonctionnalités des dépendances sur les bases de données système et le système d’exploitation, certaines fonctionnalités et syntaxes ne sont pas du tout prises en charge. Par conséquent, la plupart des fonctionnalités au niveau de l’instance ne sont pas prises en charge dans SQL Database. Les instructions et les options T-SQL ne sont pas disponibles si elles configurent des composants du système d’exploitation et des options au niveau de l’instance ou si elles spécifient la configuration du système de fichiers. Si de telles fonctionnalités sont nécessaires, vous trouverez la plupart du temps une alternative appropriée en procédant différemment à partir de SQL Database ou d’un autre service/d’une autre fonctionnalité Azure.

Par exemple, la haute disponibilité est intégrée à Azure SQL Database. Les instructions T-SQL relatives aux groupes de disponibilité ne sont pas prises en charge par SQL Database, et les vues de gestion dynamique liées aux groupes de disponibilité Always On ne sont pas non plus prises en charge.

Pour obtenir la liste des fonctionnalités prises en charge et non prises en charge par SQL Database, consultez comparaison des fonctionnalités : Azure SQL Database et Azure SQL Managed Instance. Cette page complète cet article. Elle est consacrée aux instructions T-SQL.

Instructions T-SQL avec des différences partielles

Les instructions DDL principales sont disponibles, mais les extensions d’instruction DDL liées aux fonctionnalités non prises en charge, telles que le placement de fichiers sur le disque, ne sont pas prises en charge.

• Dans SQL Server, les instructions CREATE DATABASE et ALTER DATABASE ont plus d’une trentaine d’options. Les instructions incluent des options liées à l’emplacement des fichiers, à FILESTREAM et à Service Broker qui s’appliquent uniquement à SQL Server. Cela peut ne pas être important si vous créez des bases de données dans SQL Database avant de migrer, mais si vous migrez du code T-SQL qui crée des bases de données, vous devez comparer CREATE DATABASE (Azure SQL Database) à la syntaxe SQL Server dans CREATE DATABASE (SQL Server T-SQL) pour vous assurer que toutes les options que vous utilisez sont prises en charge. CREATE DATABASE pour Azure SQL Database compte également des options d’objectif de service et de pool élastique qui s’appliquent uniquement à SQL Database.
• Les instructions CREATE TABLE et ALTER TABLE offrent les options FILETABLE et FILESTREAM que vous ne pouvez pas utiliser sur SQL Database, car elles ne sont pas prises en charge.
• La création, la modification ou la suppression d’objets utilisateur tels que des tables, des vues ou des procédures stockées à l’aide des instructions correspondantes CREATEALTERdans DROP la master base de données sur un serveur logique ne sont pas prises en charge.
• CREATE LOGIN et ALTER LOGIN les instructions sont prises en charge, mais ne proposent pas toutes les options disponibles dans SQL Server. Pour accroître la portabilité de votre base de données, SQL Database recommande, dans la mesure du possible, de remplacer les connexions par des utilisateurs de base de données autonome. Pour plus d’informations, consultez CREATE LOGIN, ALTER LOGIN et Autoriser l’accès à la base de données SQL Database, SQL Managed Instance et Azure Synapse Analytics.

Syntaxe T-SQL non prise en charge dans Azure SQL Database

Outre les instructions T-SQL relatives aux fonctionnalités non prises en charge décrites dans la comparaison des fonctionnalités : Azure SQL Database et Azure SQL Managed Instance, les instructions et groupes d’instructions suivants ne sont pas pris en charge. Si la base de données à migrer utilise les fonctionnalités et instructions T-SQL suivantes, vous devez donc remanier votre application pour les éliminer.

• Classement des objets système.
• Relatif à la connexion : instructions relatives aux points de terminaison. SQL Database ne prend pas en charge l’authentification Windows, mais prend en charge l’authentification Microsoft Entra. Cela inclut l’authentification des principaux Active Directory fédérés avec l’ID Microsoft Entra. Pour plus d’informations, consultez l’authentification Microsoft Entra pour Azure SQL.
• Requêtes sur plusieurs bases de données et plusieurs instances à l’aide de noms en trois ou quatre parties. Les noms en trois parties référençant la base de données tempdb et la base de données actuelle sont pris en charge. La requête élastique prend en charge les références en lecture seule aux tables d’autres bases de données MSSQL.
• Chaînage des propriétés des bases de données croisées et la propriété de base de données TRUSTWORTHY.
• EXECUTE AS LOGIN. Utilisez EXECUTE AS USER à la place.
• Gestion de clés extensible pour les clés de chiffrement. Les clés gérées par le client TDE (Transparent Data Encryption) et les clés principales de colonne Always Encrypted peuvent être stockées dans Azure Key Vault.
• Gestion des événements : notifications d’événements, notifications de requête.
• Propriétés de fichier : syntaxe associée au nom, au placement et à la taille des fichiers de base de données ainsi qu’à d’autres propriétés de fichier gérées automatiquement par SQL Database.
• Haute disponibilité : syntaxe liée à la haute disponibilité et à la récupération de base de données, qui sont gérées par SQL Database. Ceci inclut la syntaxe pour la sauvegarde, la restauration, la fonctionnalité Always On, la mise en miroir de bases de données, la copie des journaux de transaction et les modèles de récupération.
• Syntaxe liée à la réplication d’instantané, transactionnelle et de fusion, qui n’est pas disponible dans SQL Database. Les abonnements de réplication sont pris en charge.
• Fonctions : fn_get_sql, fn_virtualfilestats, fn_virtualservernodes.
• Configuration de l’instance : syntaxe liée à la mémoire, aux threads de travail, à l’affinité du processeur et aux indicateurs de trace du serveur. Utilisez plutôt des niveaux de service et des tailles de calcul.
• KILL STATS JOB.
• OPENQUERY, OPENDATASOURCE et noms en quatre parties.
• .NET Framework : intégration clR (Common Language Runtime)
• Recherche sémantique
• Informations d’identification du serveur : utilisez les informations d’identification de la base de données à la place.
• Autorisations au niveau du serveur : GRANT, REVOKEet DENY des autorisations au niveau du serveur ne sont pas prises en charge. Certaines autorisations de niveau serveur sont remplacées par des autorisations de niveau base de données ou accordées implicitement par des rôles serveur intégrés. Pour certaines vues de gestion dynamique et vues de catalogue de niveau serveur, des vues de niveau base de données similaires sont disponibles.
• SET REMOTE_PROC_TRANSACTIONS
• SHUTDOWN
• sp_addmessage
• Voir sp_configure et RECONFIGURE. ALTER DATABASE SCOPED CONFIGURATION est pris en charge.
• sp_helpuser
• sp_migrate_user_to_contained
• SQL Server Agent : syntaxe reposant sur SQL Server Agent ou la base de données msdb (alertes, opérateurs, serveurs d’administration centrale). Utilisez des scripts tels que des scripts PowerShell à la place.
• Audit SQL Server : utilisez plutôt l’audit SQL Database.
• Trace SQL Server.
• Indicateurs de trace.
• Débogage T-SQL.
• Déclencheurs avec étendue au niveau serveur ou déclencheurs d’ouverture de session.
• Instruction USE : pour basculer le contexte de base de données vers une autre base de données, vous devez créer une connexion à cette base de données.

Référence T-SQL complète

Pour plus d’informations sur la grammaire, l’utilisation et les exemples T-SQL, consultez Transact-SQL référence (moteur de base de données).

À propos des balises « S’applique à »

La référence T-SQL comprend des articles relatifs à toutes les versions récentes de SQL Server. Sous le titre de l’article se trouve une barre d’icônes qui liste les plateformes MSSQL et indique l’applicabilité. Par exemple, la fonction des groupes de disponibilité ont été introduits dans SQL Server 2012. L’article CREATE AVAILABILITY GROUP indique que l’instruction s’applique à SQL Server (à partir de 2012) . L’instruction ne s’applique pas à SQL Server 2008, SQL Server 2008 R2, Azure SQL Database, Azure Synapse Analytics ou Parallel Data Warehouse.

Dans certains cas, le sujet général d’un article peut être utilisé dans un produit, mais il existe des différences mineures entre les produits. Les différences sont indiquées dans l’article comme il convient. Par exemple, l’article CREATE TRIGGER est disponible dans SQL Database. Cependant, l’option ALL SERVER pour les déclencheurs de niveau serveur indique que ces derniers ne peuvent pas être utilisés dans SQL Database. Utilisez plutôt des déclencheurs de niveau base de données.

Contenu connexe

• Comparaison des fonctionnalités : Azure SQL Database et Azure SQL Managed Instance