Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : SQL Server 2025 (17.x)
Cet article décrit les modifications majeures affectant les fonctionnalités du moteur de base de données SQL Server introduites avec SQL Server 2025 (17.x). Ces modifications peuvent interrompre les applications, les scripts ou les fonctionnalités basées sur des versions antérieures de SQL Server.
Les connexions de serveur liées échouent après une mise à niveau
SQL Server 2025 (17.x) inclut des modifications apportées au chiffrement qui introduisent un changement incompatible aux serveurs liés. Ces modifications peuvent interrompre les applications, les scripts ou les fonctionnalités basées sur des versions antérieures de SQL Server.
Lorsque vous effectuez une mise à niveau des versions précédentes de SQL Server vers SQL Server 2025 (17.x) avec Microsoft OLE DB Driver 19, les configurations de serveur liées existantes peuvent échouer. Différentes valeurs par défaut pour le paramètre de chiffrement peuvent entraîner cet échec, sauf si un certificat valide est fourni.
Dans SQL Server 2025 (17.x) :
-
Les serveurs liés aux instances de SQL Server 2025 doivent utiliser le
Encryptparamètre dans la chaîne de connexion - Lorsque vous migrez des éditions précédentes de SQL Server vers SQL Server 2025 avec Microsoft OLE DB Driver 19, les configurations de serveur liées existantes peuvent échouer
Pour plus d’informations sur la connexion sécurisée aux instances SQL Server 2025 (17.x), consultez TDS 8.0.
Les composants de réplication échouent après une mise à niveau
SQL Server 2025 (17.x) inclut des modifications apportées au chiffrement qui provoquent une incompatibilité dans la réplication transactionnelle, instantanée, entre pairs et de fusion.
Les composants de réplication peuvent échouer après une mise à niveau vers SQL Server 2025 (17.x) à partir de toutes les versions précédentes de SQL Server, si votre instance SQL Server :
- Est configuré en tant qu’éditeur de réplication.
- Dispose d’un serveur de distribution distant dans la topologie de réplication.
- N’est pas configuré avec un certificat approuvé.
Vous pouvez voir le comportement suivant après la mise à niveau :
- La réplication continue de réussir, mais les modifications apportées à la publication échouent.
- Le moniteur de réplication dans SQL Server Management Studio (SSMS) échoue.
- L’état de l’agent dans l’interface utilisateur de SSMS échoue.
Un serveur distant utilise un serveur lié pour la communication entre l’éditeur et le serveur de distribution. La valeur par défaut sécurisée introduite dans SQL Server 2025 (17.x) du fournisseur OLEDB 19 nécessite cela TrustServerCertificate=False.
Vous pouvez résoudre ce problème de manière préemptive avant de démarrer la mise à niveau, ou vous pouvez résoudre le problème si les composants de réplication échouent après une mise à niveau.
Avant de commencer la mise à niveau
Si vous savez que votre instance SQL Server va rencontrer ce problème après une mise à niveau, vous pouvez atténuer de manière préemptive l’échec en configurant l’instance SQL Server pour utiliser un certificat commercial public ou un certificat d’une autorité de certification interne.
Il s’agit de l’option recommandée pour une sécurité maximale.
Composants ayant échoué après une mise à niveau
Si vos composants de réplication échouent après une mise à niveau, vous pouvez toujours configurer l’instance SQL Server pour utiliser un certificat commercial public ou un certificat d’une autorité de certification interne.
Vous pouvez également choisir l’option moins sécurisée pour remplacer la valeur par défaut sécurisée du fournisseur OLEDB 19 et définir trust_distributor_certificate=yes afin que le serveur de distribution approuve le certificat auto-signé.
Pour remplacer la nouvelle valeur par défaut sécurisée, utilisez la procédure stockée sp_changedistributor_property pour définir l’option trust_distributor_certificate sur yes:
EXECUTE sp_changedistributor_property
@property = N'trust_distributor_certificate',
@value = N'yes';
Note
Les valeurs par défaut sécurisées se rapportent au fournisseur OLEDB 19 sous-jacent, ce qui améliore la sécurité. L’option de remplacement de la valeur par défaut est moins sécurisée que la configuration de votre instance pour utiliser un certificat approuvé. Après avoir remplacé la valeur par défaut, vous avez la possibilité de configurer SQL Server pour utiliser un certificat, puis d’utiliser la procédure stockée sp_changedistributor_property pour définir la trust_distributor_certificate=no propriété sur la valeur par défaut sécurisée.
L’ajout d’un serveur de distribution de réplication distant échoue
SQL Server 2025 (17.x) inclut des modifications apportées au chiffrement qui introduisent un changement de rupture des réplications transactionnelle, d’instantané, entre pairs et de fusion.
Lors de la configuration d’un serveur de distribution pour la réplication, la procédure stockée sp_adddistributor échoue quand :
- L’éditeur est une instance SQL Server 2025 (17.x).
- Le serveur de distribution est distant.
- Le serveur de distribution n’est pas configuré avec un certificat approuvé.
L’erreur suivante peut s’afficher lors de l’exécution sp_adddistributor sur l’instance de l’éditeur :
OLE DB provider "MSOLEDBSQL19" for linked server "repl_distributor" returned message
"Client unable to establish connection".
Msg -2146893019, Level 16, State 1, Line 21
SSL Provider: The certificate chain was issued by an authority that is not trusted.
Un serveur distant utilise un serveur lié pour la communication entre l’éditeur et le serveur de distribution. La valeur par défaut sécurisée introduite dans SQL Server 2025 (17.x) du fournisseur OLEDB 19 nécessite cela TrustServerCertificate=False.
Pour résoudre ce problème, configurez l’instance SQL Server du serveur de distribution pour utiliser un certificat commercial public ou un certificat d’une autorité de certification interne.
Vous pouvez également choisir l’option moins sécurisée pour remplacer la valeur par défaut sécurisée du fournisseur OLEDB 19 et définir TrustServerCertificate=True afin que le serveur de distribution approuve le certificat auto-signé. Pour remplacer la valeur par défaut, utilisez le trust_distributor_certificate paramètre lors de l’appel de la procédure stockée sp_adddistributor :
EXECUTE sys.sp_adddistributor @trust_distributor_certificate = 'yes';
Note
Les valeurs par défaut sécurisées se rapportent au fournisseur OLEDB 19 sous-jacent, ce qui améliore la sécurité. L’option de remplacement de la valeur par défaut est moins sécurisée que la configuration de votre instance pour utiliser un certificat approuvé. Après avoir remplacé la valeur par défaut, vous avez la possibilité de configurer SQL Server pour utiliser un certificat, puis d’utiliser la procédure stockée sp_changedistributor_property pour définir la trust_distributor_certificate=no propriété sur la valeur par défaut sécurisée.
La surveillance de l'expédition des journaux à distance peut échouer.
SQL Server 2025 (17.x) inclut des modifications du chiffrement qui introduisent un changement majeur à l'expédition des journaux. Vous pouvez rencontrer ces problèmes lors de la mise à niveau.
La surveillance de la journalisation peut être interrompue si le moniteur est une instance distante de SQL Server 2025 (17.x) alors que d'autres instances SQL Server de la topologie de journalisation utilisent une version antérieure.
Pour plus d’informations sur la connexion sécurisée aux instances SQL Server 2025 (17.x), consultez TDS 8.0.
Full-Text requêtes et les populations échouent après la mise à niveau
SQL Server 2025 (17.x) supprime tous les analyseurs de mots hérités et les filtres binaires utilisés par Recherche en texte intégral. Ces composants sont reconstruits avec un ensemble d’outils moderne et offrent une prise en charge étendue pour d’autres langages et types de documents. Les index existants après la mise à niveau sont désignés par index_version = 1 selon sys.fulltext_indexes. Les index nouvellement créés sont désignés version 2 et utilisent les nouveaux composants, sauf indication contraire à l’aide de la configuration étendue à la FULLTEXT_INDEX_VERSION base de données.
Toute requête Full-Text sur un index version 1 ne parvient pas à trouver les fichiers binaires de l’analyseur de mots sur le disque immédiatement après la mise à niveau :
Msg 30010, Level 16, State 2, Line 8
An error has occurred during the full-text query. Common causes include: word-breaking errors or timeout, FDHOST permissions/ACL issues, service account missing privileges, malfunctioning IFilters, communication channel issues with FDHost and sqlservr.exe, etc. If recently performed in-place upgrade to SQL2025, For help please see https://aka.ms/sqlfulltext.
De même, toute population Full-Text émise sur un index version 1 ne parvient pas à trouver les fichiers binaires de filtre sur le disque après la mise à niveau :
Warning: No appropriate filter was found during full-text index population for table or indexed view '[db].[dbo].[table_name]' (table or indexed view ID '901578250', database ID '5'), full-text key value '1'. Some columns of the row were not indexed.
Reconstruire les index existants avec la nouvelle version
La méthode recommandée pour continuer à utiliser vos index consiste à les reconstruire avec les composants plus récents de la version 2.
-- Verify value = 2
SELECT *
FROM sys.database_scoped_configurations
WHERE [name] = 'FULLTEXT_INDEX_VERSION';
-- Per catalog upgrade
ALTER FULLTEXT CATALOG [FtCatalog] REBUILD;
La seule méthode permettant de mettre à niveau des index individuels sans regénérer l’intégralité du catalogue consiste à les supprimer et à les recréer.
Continuer à utiliser la version 1
S’il est nécessaire de rester sur la version 1 pour la compatibilité des applications, vérifiez d’abord que vous définissez FULLTEXT_INDEX_VERSION = 1 pour éviter une mise à niveau involontaire lors de la reconstruction.
ALTER DATABASE SCOPED CONFIGURATION
SET FULLTEXT_INDEX_VERSION = 1;
Vous devez ensuite copier l’analyseur de mots hérité et filtrer les fichiers binaires d’une instance antérieure vers le dossier de l’instance binn cible.