Problèmes connus/limitations de migration dans le cadre des migrations en ligne vers Azure SQL Managed Instance

Les problèmes connus et limitations associées aux migrations en ligne de SQL Server vers Azure SQL Managed Instance sont décrits ci-dessous.

Important

Avec les migrations en ligne de SQL Server vers Azure SQL Managed Instance, la migration de types de données SQL_variant n’est pas prise en charge.

Exigences de sauvegarde

Support de sauvegarde

Veillez à effectuer chaque sauvegarde sur un support de sauvegarde distinct (fichiers de sauvegarde). Azure Database Migration Service ne prend pas en charge les sauvegardes ajoutées à un fichier de sauvegarde unique. Effectuez des sauvegardes complètes, différentielles et de journaux dans des fichiers de sauvegarde distincts.

Nombre de fichiers journaux

Azure Database Migration Service ne prend pas en charge les bases de données avec plusieurs fichiers journaux. Si vous disposez de plusieurs fichiers journaux, réduisez et réorganisez-les au sein d'un même fichier journal de transactions. N'étant pas en mesure de vous connecter à distance à des fichiers journaux non vides, vous devez d’abord sauvegarder le fichier journal.

FileStream/FileTables

Actuellement, SQL Managed Instance ne prend pas en charge FileStream et FileTables. Pour les charges de travail dépendant de ces fonctionnalités, nous vous recommandons d’opter pour les instances SQL Server qui s'exécutent sur des machines virtuelles Azure telles que votre cible Azure.
Tables en mémoire

OLTP en mémoire est disponible aux niveaux Premium et Critique pour l’entreprise pour SQL Managed Instance. Le niveau Usage général ne prend pas en charge OLTP en mémoire.

Déploiements

SQL Managed Instance est un service PaaS avec mises à jour correctives et mises à jour de version automatiques. Lors de la migration de votre instance SQL Managed Instance, les mises à jour non critiques sont suspendues jusqu’à 36 heures. Ensuite (et pour les mises à jour critiques), si la migration est interrompue, le processus se réinitialise en état de restauration complète.

Le basculement de la migration ne peut être appelé qu'au terme de la restauration de la sauvegarde complète, et récupère toutes les sauvegardes de journaux. Si vos basculements de migration de production sont affectés par des problèmes inattendus, ouvrez un ticket de support pour obtenir de l’aide.

Vous pouvez soumettre des idées/suggestions d’amélioration et d’autres commentaires, y compris des bogues dans le forum de la communauté Azure — Azure Database Migration Service.

Les problèmes de connexion au partage de fichiers SMB sont probablement dus à un problème d’autorisation.

Pour tester la connectivité du partage de fichiers SMB, procédez comme suit :

Enregistrez une sauvegarde dans le partage de fichiers SMB.
Vérifiez la connectivité réseau entre le sous-réseau d’Azure Database Migration Service et le serveur SQL source. Le moyen le plus simple consiste à déployer une machine virtuelle SQL Server sur le sous-réseau DMS et à vous connecter au serveur SQL source à l’aide de SQL Server Management Studio.
Restaurez l’en-tête sur le serveur SQL source à partir de la sauvegarde sur le partage de fichiers :
```
RESTORE HEADERONLY   
FROM DISK = N'\\<SMB file share path>\full.bak'
```

Si vous ne parvenez pas à vous connecter au partage de fichiers, configurez les autorisations en procédant comme suit :

Accédez à votre partage de fichiers à l’aide d’Explorateur de fichiers.
Cliquez avec le bouton droit sur le partage de fichiers et sélectionnez Propriétés.
Choisissez l’onglet Partage et sélectionnez Partage avancé.
Ajoutez le compte Windows utilisé pour la migration et attribuez-lui un contrôle d’accès total.
Ajoutez le compte de service SQL Server et attribuez-lui un contrôle d’accès total. Vérifiez Gestionnaire de configuration SQL Server pour le compte de service SQL Server si vous n’êtes pas certain du compte utilisé.