Depannage SQL Module Complet

Contents
Bienvenue
Analysis Services
Calculer la croissance de la période précédente
Ne peut pas se connecter à une instance nommée
Configurer le fournisseur de données MSOLAP pour Excel
Configurer SSAS pour générer des fichiers de vidage mémoire
Déterminer le premier ou le dernier membre avec des données
L’espace disque est épuisé et SSAS se crashe
Activer le niveau d’isolation des transactions de capture instantanée
Erreur 1032 dans le journal des applications
Erreur et échec de la requête MDX dans une instance multidimensionnelle SSAS
Erreur lors de la connexion à une instance nommée
Erreur lors du traitement d’une base de données ou d’un cube
Erreur lors du traitement d’une dimension
Erreur lors de l’utilisation de PowerPivot pour Excel
La requête MDX contient l’erreur De retours agrégés
La requête MDX avec mesure calculée s’exécute lentement
Aucune propriété et aucun membre de la hiérarchie de dimension
Effectuer une requête distribuée avec OLAP Server
Résultat inattendu d’Analysis Services
Problème de performances d’écriture
NA renvoie lorsque vous exécutez une requête multi-sous-sélectionné
Erreur et code de 0x80004005 fournisseur WMI
Machine virtuelle Azure SQL
Échec de l’installation FCI avec erreur sur azure VM
Services de qualité des données
Échec de l’exportation DQS vers un fichier Excel 64 bits avec erreur
DQSInstaller peut ne pas accéder au dossier temp
Erreur lors de l’exécutement de la transformation nettoyage DQS
Moteur de base de données
Administration et gestion
SQL Server de démarrage
SQL Server de démarrage
Erreur de refus d’accès SQL Server’accès ne démarre pas
Erreur 17113 lorsque vous démarrez SQL Server service
Erreur 17182 lorsque vous démarrez SQL Server service
Erreur 1068 lors du démarrage SQL Server
Erreur 1069 lors du démarrage SQL Server
L’ID d’événement 17058 et SQL Server ne démarre pas
Erreurs 1450 et 665 lors de l’exécution du DBCC
Une erreur d’O/S non récoverable lorsque vous utilisez la sauvegarde vers l’URL
Une base de données TDE peut ne pas récupérer
Violations d’accès et fichiers de vidage mémoire
Les tâches d’activation s’exécutent au-dessus de la limite
Le travail de l’agent peut échouer avec l’erreur 65535
Impossible de migrer l’assembly vers SQL Server erreur 2017
Assertion lorsque vous exécutez l’insertion en bloc ou bcp
Échec de l’agent ASR ou de la sauvegarde VSS non-composant
Échec des travaux Azure Site Recovery sur les serveurs hébergeant SQL serveurs
Sauvegarder une base de données à l’aide d’une application de sauvegarde VSS
Résolution des problèmes de sauvegarde et de restauration
Opération de sauvegarde dans la table historique du jeu de sauvegarde
Comportement des sauvegardes compressées
Configuration des autorisations pour accéder aux données distantes
Considérations sur larow automatique et l’autoshrink
Considérations lors de l’utilisation de la Full-Text pour la recherche
Se crashe lorsque vous exécutez une requête de serveur lié Oracle
L’autorisation Créer une base de données est enregistrée
Moteur de base de données Exigences en matière d’entrée/sortie
Tirets ignorés dans la recherche avec SQL Full-Text
Défragmentation des lecteurs de disque de base de données
Erreur 0x80040e97 lors de l’utilisation de la recherche en texte intégral
Erreur 3156 lors de la restauration d’une base de données
Erreur après avoir effectué une rotation de clé ou de certificat TDE
Erreur lors de la backing up in-memory database
Erreur lors de la création d’une capture instantanée
Erreur lorsque vous exécutez un objet CLR ou créez un assembly
L’index de texte intégral n’indexe pas les valeurs d’attribut
Les index de texte intégral cessent de se remplir
Conditions requises pour le sous-système d’I/S pour tempdb
Améliorer les performances des requêtes en texte intégral
Délai d’verrouillage lors de l’exécution du DBCC
Algorithmes de journalisation et de stockage des données
Gérer le journal des erreurs
Transmettre une variable à une requête de serveur lié
Problèmes de performances lors de l’utilisation d’index Columstore avec des pages
de grande taille
La gestion basée sur la stratégie génère des alertes
La restauration ou la récupération peut échouer
Exécuter un objet COM basé sur une DLL
Planifier et automatiser les sauvegardes de bases de données
Configurer et dépanner un serveur lié à une base de données Oracle
L’espace utilisé par un tableau n’est pas libéré
Prise en charge des bases de données sur des volumes compressés
Prise en charge des fichiers de base de données réseau
Prise en charge des composants de technologie iSCSI
La transaction n’est plus valide lors de l’utilisation de la messagerie de base de
données
Le fichier journal des transactions n’augmente pas
Résoudre les erreurs DBCC
Impossible de commencer une transaction distribuée
Les pilotes d’hôte virtuel entraînent des problèmes de cohérence des données
Les mots ne sont pas renvoyés par un décomposeur de mots anglais
Développement d’applications clientes
Ne peut pas désinstaller complètement le pilote ODBC
Problèmes de connexion
Ne peut pas se connecter à distance à l’aide de TCP/IP
Kerberos Configuration Manager est disponible
Résolution des erreurs de connectivité
Erreur d’autorité de certification non valide
Conception et développement de base de données
Can’t make a remote connection from a CLR trigger
Erreur 556 : échec d’insertion exec
L’exécution du CLR échoue avec TypeInitializationException
Index filtré non utilisé dans les requêtes
Améliorations de la gestion de certains types de données et opérations peu
courantes
Itérer dans le jeu de résultats à l’aide de T-SQL
Stratégie pour les assemblys .NET Framework non testés
La requête renvoie des résultats incorrects
Supprimer les lignes en double du tableau
Faire pivoter un tableau
Problèmes de délai d’SQL des objets CLR
Utiliser une procédure stockée étendue ou SP_OA pour charger le CLR
Fonctionnalités de haute disponibilité et de récupération d’urgence
Groupes de disponibilité
Erreur 9002 sur le réplica principal
DB AlwaysOn en attente de récupération ou état suspect
Le temps d’attente de la connexion de l’écoute dans plusieurs sous-réseaux
Dégradation des performances des requêtes sur les réplicas secondaires
Résolution des problèmes deover automatique
Résolution des problèmes AlwaysOn
Mise en miroir de bases de données
Les bases de données en miroir sont déconnectées
Failover Clusters
Ressource de cluster en état d’échec
Échec de la règle de validation de cluster
Créer des bases de données ou modifier des emplacements de fichiers disque
Échec de l’installation SQL Server sur un disque CSV
Re-créer manuellement des clés de Registre pour les ressources de cluster
Stratégie de prise en charge des configurations en cluster
Windows Dépendances de ressources de cluster de failover
Copie des journaux de transaction
Configurer la sécurité pour la livraison des journaux de bord
Le moniteur de connexion lève une erreur 14420
Installation, correction et mise à niveau
Conditions requises de .Net Framework pour SQL Server
Tentative d’effectuer une erreur d’opération non autorisée
Description du dossier Cache de mise à jour
Erreurs différentes lors de l’installation SQL Server 2008 R2
Code d’erreur 1642 si la mise à jour est appliquée
Erreur si vous modifiez le répertoire des composants partagés
La période d’évaluation a expiré lorsque vous utilisez SSMS
Échec de la vérification des règles Fusion ATL
CUS inapplicables répertoriés dans WSUS, MU ou SCM
Échec de l’installation lorsque vous supprimez des droits d’utilisateur
Message d’annuaire d’utilisateurs non valide lors de l’installation de CU ou SP
Nommer des zones de schéma et de correction pour SQL mises à jour
Nouveau modèle de maintenance de mu
Erreur d’autorisation lorsque vous utilisez un point de montage de volume
Supprimer une installation partielle d’SQL serveur
Restaurer les fichiers cache du programme d Windows installer manquants
Le service peut ne pas démarrer après l’installation du correctif
Le programme d’installation cesse de répondre lors de la mise à niveau
SQL sur Windows 7 ou Windows Server 2008 R2
SQL Server 2008 R2 et SQL Server 2008
SQL Server 2012
Installation SxS des versions X64 et X86 de SSRS 2008
Échec de la mise à jour Cluster_IsOnlineIfClustered règle
Mise à jour ou installation slipstream pour SQL Server 2008
Échecs de mise à niveau sur Windows Server 2012
Avertissement concernant l’ordre de liaison réseau
Machine Learning Services (dans la base de données)
Résultats incohérents dans les calculs MKL
Performances
La colonne bloquée est remplie pour les attentes de verrou
L’analyse du pool de mémoire tampon s’exécute lentement sur des ordinateurs
mémoire de grande taille
Diminution des performances lors de l’utilisation de TOP, MAX ou MIN
Les modules externes peuvent entraîner des problèmes de performances
Les pilotes de filtre provoquent des problèmes de performances et de cohérence
Une utilisation élevée de l’UC se produit dans vos requêtes
Moniteur de ressources non rapportant
Dégradation des performances avec le nouveau CE
Réduction de la contention d’allocation dans tempdb
Résoudre les problèmes de blocage causés par l’escalade de verrouillage
Résoudre l’insertion de la dernière page PAGELATCH_EX contention
Les entrées du magasin SchemaMgr dégradent les performances
Résoudre les problèmes de blocage causés par les verrous de compilation
Résoudre les problèmes de requêtes lentes
Comprendre et résoudre les problèmes de blocage
Mises à jour et options de configuration pour les charges de travail hautes
performances (SQL Server 2014 et 2012)
Mises à jour et options de configuration pour les charges de travail hautes
performances (SQL Server 2017 et 2016)
La mise à niveau du niveau de compatibilité dégrade les performances des requêtes
spatiales
Utiliser DBCC MEMORYSTATUS pour surveiller l’utilisation de la mémoire
Winsock LSP entraîne des problèmes de réseau ou de stabilité
Réplication, suivi des changements, capture des données de modification
Erreur de syntaxe 102 et incorrecte avec la réplication d’égal à égal
Erreur 1205 lors de la configuration de la réplication transactionnelle
Erreur 20011 : le processus n’a pas pu s’sp_replcmds
Erreur 20598 : la ligne n’a pas été trouvée dans l’abonné lors de l’application de la
commande répliquée
Erreur 213 lors de l’attachement d’une base de données ACTIVÉE
Une erreur s’est produite lors de la récupération des données de composition
Appliquer SQL correctifs dans une topologie de réplication
Impossible d’utiliser rowguidcol dans la définition de filtre dans la réplication de
fusion
Échec du travail de capture DE LAS lors du traitement des modifications
LASO pour Oracle se traduit par une croissance du journal des transactions
Lignes de touches en double à partir sys.systableau de validation
Message d’erreur lorsque vous exécutez l’agent de distribution
Échec de l’éumation des propriétés d’abonnement
Installer des Service Packs et des correctifs logiciels
Problème avec le handler de logique métier personnalisé
Supprimer manuellement la réplication
La réplication de fusion ne prend pas en charge les topologies d’abonné centralisées
Non-convergence lors du traitement SQL Server générations enfants
ORACDC517E - Échec de la méthode OCI (Oracle Call Interface)
Les déclencheurs de composition Oracle envoient des données pour les colonnes
non publiées
Statistiques de performances pour le lecteur de journaux et les agents de
distribution
Les abonnements Pull ne s’affichent pas dans Windows Synchronization Manager
Les agents de réplication ne peuvent pas s’exécuter
Erreur de script échoué lors de la création d’un instantané de composition de fusion
Paramètre SkipErrors dans l’agent de distribution
Échec des agents Snapshot ou Logreader
Échec de la synchronisation pour la réplication de fusion
L’abonnement n’existe pas
Comprendre l’ordre de traitement de l’article de réplication de fusion
La mise à jour est répliquée en tant que paires DELETE/INSERT
Aspects liés à la sécurité
Bloquer l’utilisation à distance de comptes locaux dans Windows
Erreur d’échec de déchiffrement avec la base de données toujours chiffrée
Erreurs lorsque vous désactivez l’utilisateur invité
Résoudre le problème d’autorisation lorsque vous déplacez la base de données
MSDB
Échec de démarrage avec l’erreur 17182
SQL Le service ne peut pas démarrer après la configuration du certificat SSL
Transférer des connexions et des mots de passe entre instances
Utiliser des certificats au format PFX
Utilisation SQL Server 2014 en mode conforme FIPS 140-2
Informations générales sur la résolution des problèmes
Réponses aux questions sur le MSDT
Collecteur de diagnostics de connectivité
Déterminer la version, l’édition et le niveau de mise à jour
Les déviations ou des techniques similaires provoquent des problèmes
Fin de la prise en charge SQL Server 2008
Informations sur MATS et SDP
RS Diagnostics Collector collecte des informations
Outil de diagnostic de collecte de données d’installation
SQL Collecteur de diagnostics de base
SQL Server dans Windows d’exploitation
Stratégie de prise en charge du produit de virtualisation du matériel
Stratégie de prise en charge SQL Server
Integration Services
Ag ag reste dans l’état de résolution
Créer un objet dynamique pour la tâche Envoyer un message
Une erreur 0xC0202009 se produit lorsque SSIS convertit le paramètre
Erreur lors du chargement du package
Erreur dans le package SSIS lorsque le UAC est activé
Erreur lors de l’utilisation du gestionnaire de connexion Oracle
Erreur lors de la virtualisation de BIDS ou SSDT
Points de contrôle SSIS non honorés pour les conteneurs de boucle For et Foreach
Le package SSIS ne s’exécute pas lorsqu’il est appelé à partir d’une étape de travail
L’exécution d’un package SSIS cesse de répondre
La Base de connaissances n’existe pas
Utiliser le chiffrement et la taille des paquets réseau
Master Data Services
MDS intermédiaire basé sur une entité peut échouer
MDS Échec de la commande Valider la version
MDAC et ADO
80020009 d’erreur lors de la récupération des données
Ne peut pas traduire correctement les données de caractères
Vérifier la version de MDAC
Erreur lorsque vous utilisez le curseur client pour ajouter un enregistrement
Échec de l’utilisation d’un lot important d’instructions SQL’instructions
L’administrateur ODBC affiche les DSN utilisateur 32 bits et 64 bits
Ouvrir une connexion ADO et des objets Recordset
Récupérer des valeurs dans les procédures stockées avec ADO
SQL Server clients peuvent modifier les protocoles
SQLDescribeCol renvoie une longueur de colonne erronée
Utiliser le paramètre de nom de serveur dans une chaîne de connexion
Parallel Data Warehouse (APS)
Détecter une inclinaison des valeurs des clés de distribution
Erreur 105005 lorsque vous faites ceTAS sur le stockage d’objets blob
Évaluer la précision des statistiques PDW
Msg 104381 lorsque vous exécutez une instruction avec une clause ORDER BY
Operations Manager ne peut pas surveiller APS appliance
Reporting Services
Un appel à AuthzInitializeContextFromSid échoue
Meilleures pratiques pour modifier le compte de service
Ne peut pas démarrer SSRS
Des blocages se produisent lorsque vous affichez un rapport SSRS
Erreur lors du chargement d’extensions personnalisées dans les outils de données
Le rapport exporté contient des lignes et des colonnes masquées
Clé non valide pour une utilisation dans l’état spécifié
Volet de paramètres non visible en mode SharePoint’intégration
Problèmes de rendu dans Internet Explorer
Erreur de récupération des fichiers d’application impossible
Message d’avertissement lors de l’ajout d’un assembly RS
SQL Server sur Linux
Choix d’un modèle de licence à l’aide de mssql-conf
Vidage principal sur RHEL 7.4 lorsque vous exécutez mssql-conf
Échec de l’opération de restauration sur les serveurs Linux
Outils
Management Studio
Impossible de faire basculer le volet de résultats
Erreur lors de la lecture du journal des erreurs
Échec de la récupération des données pour cette demande
L’Explorateur d’objets se crashe par intermittence
OutofMemoryException lors de l’exécution d’une requête
Message d’erreur non autorisé lors de l’enregistrement des modifications
Impossible de mody table - Expiration du délai d’expiration
Désinstaller SQL Server Management Studio
Diverses erreurs lors de la mise à jour de lignes dans un tableau
Autres outils
Impossible de se connecter à une erreur de fournisseur WMI dans configuration
manager
La base de données MSDB augmente
Les nouvelles données ne sont pas téléchargées dans la base de données MDW
après la configuration de l’ensemble de collections
Problème PowerShell lorsque RemoteSigned n’est pas définie
Utilitaires de langage de marques de relecture
La demande a échoué ou le service n’a pas répondu en temps voulu lorsque vous
démarrez SQL Agent
Échec de l’initialisation de l’objet Application SQLDMO lors de l’utilisation de
Sqlmaint
Utiliser Sqldumper pour générer des fichiers de vidage
Utilisation de l’utilitaire SQLIOSim pour simuler l’SQL Server disque
Visual Studio 2010 Shell est installé avec SQL Server 2014 et 2012
SQL Server résolution des problèmes
12/08/2021 • 2 minutes to read
Bienvenue dans SQL Server résolution des problèmes. Ces articles expliquent comment déterminer,
diagnostiquer et résoudre les problèmes que vous pouvez rencontrer lorsque vous utilisez SQL Server.
Pour plus d’informations sur les builds les plus récentes et les mises à jour cumulatives disponibles pour
une version SQL Server spécifique, voir Déterminer la version, l’édition et le niveau de mise à jour de SQL
Server et de ses composants.
Pour plus d’informations sur la façon dont vous pouvez contribuer à SQL Server documentation de
résolution des problèmes, voir Comment contribuer à SQL Server documentation .
Calculer la croissance de la période précédente
dans SQL Server Analysis Services
Cet article explique comment calculer la croissance de la période précédente dans SQL Server Analysis Services.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2406745
Résumé
Cet article décrit la procédure que vous pouvez suivre pour calculer la valeur correcte pour la croissance de la
période précédente lorsque vous avez des cubes Analysis Services qui contiennent des résultats négatifs.
Utiliser une formule pour calculer la croissance de la période

précédente
Dans un scénario où vous avez un cube Analysis Services qui contient des résultats négatifs pour lesquels vous
souhaitez calculer les valeurs de croissance de période précédente, vous devez appliquer une formule pour
obtenir les résultats corrects. Par exemple, supposons que vous avez les soldes suivants pour les années 2008,
2009 et 2010 : 10,00 $, (4,00 $), 5,00 $. Entre 2009 et 2010, étant donné que le solde est passé de négatif (4,00
$) à une valeur positive de 5,00 $, la croissance doit être positive. Pour obtenir les résultats corrects, vous devez
appliquer la formule suivante :
IIF (measures.PreviousPeriodCurrentBalance = 0, NULL,

IIF (measures.PreviousPeriodCurrentBalance < 0,
([Measures].[Balance Current] - measures.PreviousPeriodCurrentBalance) /
measures.PreviousPeriodCurrentBalance * -1,
([Measures].[Balance Current] - measures.PreviousPeriodCurrentBalance) /
measures.PreviousPeriodCurrentBalance
))
NOTE
La formule ci-dessus utilise un membre calculé créé sur une hiérarchie PreviousPeriodCurrentBalance de dates avec la
formule suivante :
([Measures].[Balance Current], [Date Balance].[Hierarchy].currentmember.Prevmember)
Pour plus d’informations, reportez-vous à la rubrique IIf SQL Server Books Online : IIf (MDX)
Impossible de se connecter à une instance nommée
d’un service d’analyse en cluster
Cet article vous aide à résoudre le problème où vous ne pouvez pas vous connecter à une instance nommée
d’Analysis Services installée sur un cluster deover.
Version du produit d’origine : SQL Server 2008 R2 Enterprise, SQL Server 2008 Enterprise, Microsoft SQL
Server 2005 Êdition Entreprise
Symptômes
Il se peut que vous ne parveniez pas à vous connecter à une instance nommée d’Analysis Services installée sur
un cluster deover. Vous pouvez recevoir un message d’erreur semblable au suivant :
Connexion impossible <server name>

INFORMATIONS SUPPLÉMENTAIRES :
Impossible d’établir une connexion. Vérifiez que le serveur fonctionne.
(Microsoft.AnalysisServices.AdomdClient)
Aucune connexion n’a pu être réalisée car l’ordinateur cible a activement refusé <ip address> :2383
(Système)
Cause
Le problème se produit lorsque vous démarrez l’instance nommée de SQL Server Analysis Services (SSAS) à
l’aide de Gestionnaire de configuration SQL Server ou de l’applet Services dans le panneau de contrôle. Lorsque
vous démarrez une instance SSAS sur un cluster deover à l’aide d’un outil autre que gestion du cluster de
failover (administrateur de cluster sur des systèmes d’exploitation plus anciens), cette instance SSAS s’exécute en
tant qu’instance autonome et écoute sur un port autre que celui par défaut, ce qui entraîne des échecs de
connexion de différentes applications.
Résolution
Arrêtez et redémarrez les services SQL Server Analysis à l’aide de l’outil Gestion du cluster de failover.
Plus d’informations
Une instance SSAS démarrée sur un cluster (instance par défaut ou nommée) commence à écouter toutes les
adresses IP du groupe de clusters à l’aide du port par défaut 2383. La propriété de <Port> paramètre du
serveur ne modifie pas le numéro de port du service SSAS sur un cluster.
Pour plus d’informations, voir l’article de la KB : Comment déterminer et modifier le port d’une instance SSAS
Configurer le fournisseur de données MSOLAP
pour Excel connexion à Analysis Services
Cet article explique comment configurer le fournisseur de données MSOLAP correct pour que Excel se connecte
à Analysis Services.
Version du produit d’origine : SQL Server 2017 Enterprise, SQL Server 2016 Enterprise, SQL Server 2014
Enterprise, SQL Server 2012 Enterprise, SQL Server 2008 Enterprise
Résumé
Pour créer une connexion de données à une source de données Analysis Services, Microsoft Excel utilise le
fournisseur OLE DB Microsoft Analysis Services pour Microsoft SQL Server (MSOLAP). Chaque version
d’Analysis Services possède sa propre version de fournisseur MSOLAP. Le tableau suivant répertorie les versions
analysis service et leur version de fournisseur MSOLAP correspondante.
VERSIO N D’A N A LY SIS SERVIC ES VERSIO N DU F O URN ISSEUR M SO L A P
SQL Server 2008 MSOLAP.4
SQL Server 2017 et versions ultérieures MSOLAP.8 (considéré comme persistant)
Pour plus d’informations sur MSOLAP et d’autres bibliothèques clientes pour Analysis Services, examinez les
bibliothèques clientes Analysis Services.
Pour plus d’informations sur l’utilisation de la version correcte de MSOLAP, voirPropriétés de chaîne de
connexion. Pour les versions MSOLAP héritées, reportez-vous à La manière d’obtenir les dernières versions de
MSOLAP. Pour la dernière version MSOLAP, reportez-vous aux bibliothèques clientes Analysis Services.
Excel utilise la version du fournisseur MSOLAP installée sur l’appareil client. Dans l’exemple suivant, Excel a
configuré MSOLAP.5 comme fournisseur de données dans la chaîne de connexion de données.
Sur un appareil client où plusieurs versions du fournisseur MSOLAP sont installées, Excel utilise la version
configurée dans le Registre.
Par exemple, dans le scénario suivant :
MSOLAP.5 est installé et configuré dans le Registre.
Vous avez installé MSOLAP.6 sur votre appareil pour vous connecter à Analysis Services 2014, mais vous
n’avez pas mis à jour le Registre pour référencer MSOLAP.6.
Excel configurer la connexion pour utiliser MSOLAP.5 dans la chaîne de connexion. Cela provoque des
problèmes, car vous ne pouvez pas utiliser les versions MSOLAP antérieures à la version de la source de
données.
Pour spécifier la version de MSOLAP Excel, mettez à jour la version dans les clés de Registre. Les clés suivantes
définissent la version MSOLAP Excel pour se connecter à Analysis Services. L’emplacement de la clé de Registre
varie selon que Microsoft Office est une installation MSI ou « Click-to-Run » (C2R) et qu’il s’agit d’une
installation 32 bits ou 64 bits.
Office MSI 32 bits
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{308FF259-8671-4df4-B66C-9851BFACF446}\ProgID\
(Default)
Office MSI 64 bits

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{308FF259-8671-4df4-B66C-9851BFACF446}\ProgID\(Default)
Office C2R 32 bits

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\
{308FF259-8671-4df4-B66C-9851BFACF446}\ProgID\(Default)
ou
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\
{DBC724B0-DD86-4772-BB5A-FCC6CAB2FC1A}\ProgID
Office C2R 64 bits

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\
{308FF259-8671-4df4-B66C-9851BFACF446}\ProgID\(Default)
ou
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\
{DBC724B0-DD86-4772-BB5A-FCC6CAB2FC1A}\ProgID\(Default)
Voici un exemple de Office C2R 32 bits configuré pour utiliser MSOLAP.5 :
Pour déterminer si votre installation est MSI ou C2R, dans Excel allez à Compte > de fichier . Si vous voyez une
section Office updates, l’installation est C2R :
S’il n’existe Office section Mises à jour, il s’agit d’une installation MSI :
Pour déterminer si Excel est 32 bits ou 64 bits, cliquez sur À propos de Excel dans le même écran Comptes et
vous affichera dans la boîte de dialogue en haut :
Configurer SQL Server Analysis Services pour
générer des fichiers de vidage mémoire
Cet article explique comment configurer SQL Server Analysis Services pour générer automatiquement des
fichiers de vidage mémoire.
Introduction
Cet article explique comment configurer Microsoft SQL Server Analysis Services (SSAS) 2012 ou des builds
supérieures pour générer automatiquement différents types de fichiers de vidage de mémoire lorsqu’il
rencontre des exceptions. L’article explique également comment utiliser l’utilitaire Sqldumper.exe pour obtenir
manuellement un fichier de vidage mémoire pour le processus SQL Server Analysis Services.
Par défaut, SQL Server Analysis Services génère automatiquement des fichiers minidump lorsqu’une exception
se produit. Pour l’installation par défaut, les fichiers minidump sont écrits à l’emplacement par défaut :
VERSIO N D’A N A LY SIS SERVIC ES EM P L A C EM EN T
2019 %ProgramFiles%\Microsoft SQL

Server\MSAS15.InstanceName\OLAP\log

Server\MSAS14.InstanceName\OLAP\log
2016 %ProgramFiles%\Microsoft SQL Server

MSAS13.InstanceName\OLAP\log


NOTE
InstanceName est un espace réservé pour la valeur correspondante pour SQL Server version Analysis Services.
L’emplacement du journal de l’instance analysis services SQL Server peut être modifié après l’installation, afin
que vous pouvez vérifier l’emplacement du journal en vérifiant le fichier msmdsrv.ini pour le fichier SQL Server
Analysis Services installé.
Pour déterminer la valeur correspondante pour le système, déterminez la valeur de la clé d’inscription
ImagePath, elle doit contenir le chemin d’accès au chemin d’accès de la msmdsrv.ini.
VERSIO N D’A N A LY SIS SERVIC ES SO US- C L É DE REGIST RE
Instance par défaut HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLServerOLAPService\ImageP
Instance nommée HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSOLAP$InstanceName\ImagePath
Les fichiers minidump incluent les informations suivantes :

Toutes les piles de threads
Mémoire de second ordre référencé par des pointeurs sur la pile
Informations sur le bloc d’environnement de processus (PEB)
Informations sur le bloc d’environnement de thread (TEB)
Informations sur les modules récemment déchargés
Informations sur l’état du thread
La section Exception du fichier Msmdsrv.ini contrôle la génération du fichier de vidage mémoire. Le fichier par
défaut se trouve dans le %ProgramFiles%\Microsoft SQL Server\MSASxx.InstanceName\OLAP\Config dossier. MSASxx
est un espace réservé pour la version correspondante pour SQL Server Analysis Service. Lorsque vous ouvrez le
fichier dans Bloc-notes, vous remarquez une section dans la balise XML Exception qui ressemble à ce qui suit :
<Exception>
<CreateAndSendCrashReports>1</CreateAndSendCrashReports>
<CrashReportsFolder/>
<SQLDumperFlagsOn>0x0</SQLDumperFlagsOn>
<SQLDumperFlagsOff>0x0</SQLDumperFlagsOff>
<MiniDumpFlagsOn>0x0</MiniDumpFlagsOn>
<MiniDumpFlagsOff>0x0</MiniDumpFlagsOff>
<MinidumpErrorList>0xC1000000, 0xC1000001, 0xC1000016, 0xC11D0005, 0xC102003F</MinidumpErrorList>
<ExceptionHandlingMode>0</ExceptionHandlingMode>
<CriticalErrorHandling>1</CriticalErrorHandling>
</Exception>
Vous pouvez contrôler le comportement de génération du fichier de vidage mémoire en modifiant les
paramètres de cette section. Vous pouvez également modifier ces paramètres dans SQL Server Management
Studio. Pour plus d’informations sur ces paramètres, visitez le SQL Server Management Studio web de
téléchargement : Propriétés du journal.
Désactiver le fichier de vidage automatique de mémoire pour Analysis

Services
La valeur du paramètre CreateAndSendCrashReports détermine si un fichier de vidage mémoire sera généré. Ce
paramètre peut avoir l’une des valeurs répertoriées dans le tableau suivant.
VA L EUR DESC RIP T IO N
0 Cette valeur indique qu’Analysis Services ne génère aucun

fichier de vidage mémoire. En outre, la valeur des autres
paramètres sous la section Exception est ignorée.
1 Cette valeur par défaut active le fichier de vidage mémoire.

Toutefois, SQL Server Analysis Services n’envoie pas de
rapport d’erreurs à Microsoft.
2 Cette valeur spécifie que SQL Server Analysis Services

génère un fichier de vidage mémoire et envoie un rapport
d’erreurs à Microsoft.
Lorsque le paramètre CreateAndSendCrashReports est 1 ou 2, les autres paramètres de la section Exception

peuvent contrôler le type du fichier de vidage mémoire et les informations à inclure dans le fichier de vidage
mémoire.
Configurer SQL Server Analysis Services pour générer

automatiquement un fichier de vidage complet
Pour configurer SQL Server Analysis Services afin de générer automatiquement un fichier de vidage complet
lorsqu’une exception se produit, vous pouvez définir le paramètre SQLDumperFlagsOn sur 0x34. En outre, si
vous souhaitez configurer SQL Server Analysis Services pour générer un fichier de vidage complet qui inclut les
informations de handle, vous pouvez définir le paramètre SQLDumperFlagsOn sur 0x34 et le paramètre
MiniDumpFlagsOn sur 0x4. Par exemple, la section Exception du fichier Msmdsrv.ini peut ressembler à ce qui
suit :
<Exception>
<CreateAndSendCrashReports>1</CreateAndSendCrashReports>
<CrashReportsFolder/>
<SQLDumperFlagsOn>0x34</SQLDumperFlagsOn>
<SQLDumperFlagsOff>0x0</SQLDumperFlagsOff>
<MiniDumpFlagsOn>0x4</MiniDumpFlagsOn>
<MiniDumpFlagsOff>0x0</MiniDumpFlagsOff>
<MinidumpErrorList>0xC1000000, 0xC1000001, 0xC1000016, 0xC11D0005, 0xC102003F</MinidumpErrorList>
<ExceptionHandlingMode>0</ExceptionHandlingMode>
<CriticalErrorHandling>1</CriticalErrorHandling>
</Exception>
Générer un fichier de vidage complet qui inclut la poignée des

informations manuellement
Pour résoudre des problèmes tels qu’un serveur qui cesse de répondre (se bloque), vous pouvez générer un
fichier de vidage complet qui inclut la poignée des informations manuellement. Pour ce faire, vous pouvez
exécuter l’utilitaire Sqldumper.exe à l’invite de commandes avec les arguments suivants :
Sqldumper.exe PID 0 0x34:0x4 0 PathToDumpFile
NOTE
PiD représente l’ID de processus du processus SQL Server Analysis Services. PathToDumpFile représente le dossier dans
lequel le fichier de vidage est écrit.
Vous devez exécuter cette commande à partir du répertoire partagé où vous avez installé l’instance, ou vous
devez spécifier le chemin d’accès complet du fichier Sqldumper.exe dans la commande.
VERSIO N D’A N A LY SIS SERVIC ES EM P L A C EM EN T
2019 %ProgramFiles%\Microsoft SQL Server\150\Shared
Par exemple, le répertoire par défaut à exécuter sqldumper.exe pour SQL Server Analysis Services 2019 est
C:\Program Files\Microsoft SQL Server\1590\Shared .
Informations supplémentaires
Vous pouvez utiliser le paramètre SQLDumperFlagsOn pour spécifier les différents indicateurs SQLDumper. Le
tableau suivant répertorie les valeurs de masque de bits que vous pouvez utiliser comme valeur pour le
paramètre d’indicateur.
N O M M N ÉM O N IQ UE VA L EUR H EXA DÉC IM A L E DESC RIP T IO N

SQLDUMPER_DBGBREAK 0x0001 Cet indicateur entraîne

lSqldumper.exe'utilitaire de débogage à
exécuter l’appel de l’API DebugBreak au
début du programme lorsque les
paramètres sont interrogés. En règle
générale, les professionnels des
services de support technique
Microsoft n’utilisent pas cet indicateur,
car l’indicateur est utilisé uniquement
pour déboguer Sqldumper.exe
problèmes utilitaires.
Remarque Cet indicateur s’interrompt
dans Sqldumper.exe processus. Cet
indicateur ne s’insérait pas dans le
processus de débogage
Sqldumper.exe'utilitaire de
développement.
SQLDUMPER_NOMINIDUMP 0x0002 Lorsque vous utilisez cet indicateur,

l’utilitaire Sqldumper.exe ne génère pas
de fichier de vidage. Cet indicateur est
utilisé pour tester l’utilitaire
Sqldumper.exe de test.
SQLDUMPER_NOWATSON 0x0004 En règle générale, cet indicateur est

utilisé lorsque vous générez
manuellement des fichiers de vidage.
Cet indicateur remplace le
comportement de rapport d’erreurs
par défaut. Par défaut, le fichier de
vidage est envoyé au site de rapports
d’erreurs configuré dans le Registre.
SQLDUMPER_REFERENCED_MEMORY 0x0008 Cet indicateur entraîne la

Sqldumper.exe à définir l’indicateur
MiniDumpWithIndirectlyReferencedMe
mory pour le paramètre
MiniDumpType lorsqu’il appelle la
fonction MiniDumpWritedump. La
mémoire des pointeurs (un niveau
uniquement) qui sont basés sur une
pile (paramètres ou variables locales)
sera stockée dans le fichier de vidage.
Le test révèle que certains paramètres
locaux basés sur des données TLS
(Thread Local Storage), telles que les
structures PSS (Probabilistic Signature
Scheme) et EC, ne semblent pas
fonctionner même lorsque vous
définissez cet indicateur.
SQLDUMPER_ALL_MEMORY 0x0010 Cet indicateur entraîne la

Sqldumper.exe à définir
l’indicateurMiniDumpWithFullMemory
pour MiniDumpType lorsque l’utilitaire
appelle la fonction
MiniDumpWriteDump. Ce
comportement est identique à
l’utilisation de la commande .dump /mf
sous le déboguer. Toutefois, vous devez
également avoir l’indicateur
SQLDUMPER_DUMP_ALL_THREADS
sur pour vous assurer que toutes les
piles de threads sont incluses.
SQLDUMPER_DUMP_ALL_THREADS 0x0020 Cet indicateur n’est pas requis lorsque

vous exécutez manuellement l’utilitaire
Sqldumper.exe et que vous spécifiez
une valeur de paramètre ThreadId de
0. Une valeur de paramètre ThreadId
de 0 indique que tous les threads
doivent être vidés. Si vous spécifiez
une valeur de paramètre ThreadId
spécifique non nulle, mais que vous
utilisez également cet indicateur, tous
les threads sont écrits dans le fichier de
vidage. Cet indicateur existe, car le
comportement classique dans le
processus Sqlservr.exe consiste à
transmettre la valeur de propriété
ThreadId actuelle du thread qui
engendre le processus Sqlservr.exe jour.
Lorsque ce comportement se produit,
l’indicateur est nécessaire comme
option pour vider tous les threads.
SQLDUMPER_MATCH_FILE_NAME 0x0040 Vous pouvez utiliser cet indicateur

pour essayer de forcer l’utilitaire
Sqldumper.exe à générer un nom de
fichier de vidage qui ressemble à une
convention d’attribution de noms
spécifique. Cette convention
d’attribution de noms spécifique peut
être basée sur un nom de fichier
existant. Étant donné que vous devez
configurer une structure de mémoire
spéciale qui contient le nom de fichier
existant dans votre propre
programme, puis transmettre ce
pointeur à l’utilitaire Sqldumper.exe en
tant que paramètre SqlInfoPtr, cet
indicateur n’est pas utile lorsque vous
exécutez manuellement l’utilitaire
Sqldumper.exe.
SQLDUMPER_SKIP_DW_REG_READ 0x0080 Cet indicateur permet à

lSqldumper.exe'utilitaire de ne pas
utiliser le Registre comme chemin
d’accès pour l’exécution Dw15.exe
programme. Le Dw15.exe est utilisé
pour télécharger les fichiers de vidage
sur le site de rapports d’erreurs.
SQLDUMPER_VERBOSE 0x0100 Cet indicateur peut être utile si vous

n’êtes pas sûr des paramètres que
l’utilitaire Sqldumper.exe pense être
utilisés comme entrée. Lorsque vous
utilisez cet indicateur, l’utilitaire
Sqldumper.exe affiche les valeurs des
paramètres et le nombre de valeurs de
paramètre spécifiées à partir de la ligne
de commande.
SQLDUMPER_WAIT_AT_EXIT 0x0200 Vous pouvez utiliser cet indicateur

pour attacher un débogger à
lSqldumper.exe utilitaire. Vous pouvez
utiliser ce débompeur pour résoudre
les problèmes liés à l’utilitaire
Sqldumper.exe de l’outil. Ces problèmes
peuvent notamment se produire
lorsque l’utilitaire Sqldumper.exe est
généré par Sqlservr.exe ou par un
autre programme. Lorsque vous
définissez cet indicateur, l’utilitaire
Sqldumper.exe appelle la fonction
SleepEx pendant 15 secondes juste
avant l’existence du programme
Sqldumper.exe et une fois toutes les
autres opérations terminées.
SQLDUMPER_FILTERED 0x0800 Vous pouvez utiliser cet indicateur

pour générer un fichier de vidage filtré.
SQL Server Analysis Services ne prend
pas encore en charge cet indicateur.
Vous pouvez utiliser le paramètre MiniDumpFlagsOn pour fournir des indicateurs minidump. Le tableau suivant
répertorie les indicateurs minidump disponibles :
O P T IO N VA L EUR DESC RIP T IO N
MiniDumpNormal 0x00000000 Créez un fichier de mini-vidage

classique qui utilise la réécriture.
MiniDumpWithDataSegs 0x00000001 Inclure un segment de données pour

tous les modules chargés. L’indicateur
que les modules chargés récupèrent
les variables globales.
MiniDumpWithFullMemory 0x00000002 Créez un fichier de vidage utilisateur

complet. Un fichier de vidage filtré est
désactivé lorsque l’indicateur est
définie.
MiniDumpWithHandleData 0x00000004 Inclure les informations de handle.
MiniDumpFilterMemory 0x00000010 La mémoire de la pile et du magasin

de documents doit être analysée pour
les références de pointeur aux modules
de la liste des modules. L’utilisateur ne
doit pas utiliser cet indicateur pour
SQL Server Analysis Services.
MiniDumpWithUnloadedModules 0x00000020 Cet indicateur fournit des informations

sur les modules récemment déchargés.
Seuls Microsoft Windows XP et
Microsoft Windows Server 2003 la
prise en charge de cet indicateur. Le
système d’exploitation ne conserve pas
les informations pour les modules
déchargés avant Windows Server 2003
Service Pack 1 (SP1) et Windows XP
Service Pack 2 (SP2).
MiniDumpWithIndirectlyReferencedMe 0x00000040 Inclure les pages qui comportent des

mory données référencés par des données
locales ou par d’autres mémoires de
pile.
O P T IO N VA L EUR DESC RIP T IO N
MiniDumpFilterModulePaths 0x00000080 Si le chemin d’accès du module est

retiré des informations du module,
n’utilisez pas cet indicateur.
MiniDumpWithProcessThreadData 0x00000100 Cet indicateur fournit des informations

sur le bloc d’environnement de
processus (PEB) et le bloc
d’environnement de thread (TEB).
MiniDumpWithPrivateReadWriteMemo 0x00000200 Analysez l’espace d’adressa visite

ry virtuel pour trouver d’autres types de
mémoire à inclure.
MiniDumpWithoutOptionalData 0x00000400 Réduisez les données qui sont vidées

en éliminant les régions de mémoire
qui ne sont pas requises. Faites-le pour
répondre aux critères spécifiés pour le
fichier de vidage. L’utilisation de cet
indicateur permet d’éviter toute
mémoire mémoire contenant des
données privées pour l’utilisateur.
Toutefois, cela ne garantit pas
qu’aucune information privée ne sera
présente. N’utilisez pas cet indicateur.
MiniDumpWithFullMemoryInfo 0x00000800 Inclure des informations descriptives

sur la région de mémoire éumée.
MiniDumpWithThreadInfo 0x00001000 Inclure les informations sur l’état du

thread.
MiniDumpWithCodeSegs 0x00002000 Incluez des sections de code et de

code pour tous les modules chargés.
Références
Utilisation de l’utilitaire Sqldumper.exe pour générer un fichier de vidage dans SQL Server
Déterminer le premier ou le dernier membre avec
des données
Résumé
Dans certaines applications, il est utile de rechercher le premier ou la dernière dimension membre qui a des
données associées à celui-ci. Cet article montre comment utiliser les fonctions et les fonctions pour renvoyer les
premier et dernier membres d’une HEAD() dimension qui ont des TAIL() UNION() données. L’article illustre
également l’utilisation de la NonEmptyCrossJoin() fonction.
Supposons que votre tâche consiste à rechercher les premiers et derniers membres de la dimension de temps
avec les données de l’exemple FoodMart 2000. Pour de nombreux utilisateurs, la première idée de trouver le
premier membre avec des données serait d’utiliser la FirstChild() fonction comme suit :
SELECT {[Time].FirstChild} ON COLUMNS

FROM SALES
De même, la première idée de trouver le dernier membre de la dimension de temps avec des données serait
d’utiliser la LastChild() fonction comme suit :
SELECT {[Time].[1998].[Q4].LastChild} ON COLUMNS

FROM SALES
Toutefois, la première requête MDX renvoie la valeur associée à [1997]. [Q1] et non la valeur associée à [1997],
qui est le premier membre avec des données. La deuxième requête MDX renvoie la valeur associée à [1997].
[Q4]. [12], qui est le dernier membre de la dimension, mais pas le dernier membre avec des données.
En alternative, la fonction renvoie le premier nombre spécifié d’éléments dans un ensemble et peut être utilisée
pour renvoyer le HEAD() premier membre de la dimension. De même, la fonction renvoie un sous-ensemble à
partir de la fin d’un ensemble et peut être utilisée pour renvoyer le TAIL() dernier membre de la dimension. La
requête MDX pour renvoyer le premier membre de la dimension de temps aurait la forme suivante :
SELECT HEAD([Time].Members,1) ON COLUMNS

FROM SALES
Cette requête retourne 1997 en tant que premier membre de la dimension avec des données.
La requête MDX pour renvoyer le dernier membre de la dimension doit prendre la forme suivante :
SELECT TAIL([Time].Members,1) ON COLUMNS

FROM SALES
Cette requête MDX renvoie [1998]. [Q4]. [12] en tant que dernier membre de la dimension. Toutefois, le membre
renvoyé n’est pas le dernier membre de la dimension avec des données. Afin d’éliminer les membres sans
données, la fonction doit être utilisée pour filtrer tous les membres de la dimension qui ne sont pas associés
NonEmptyCrossJoin() à des données.
La requête MDX pour rechercher le premier membre avec des données prend ensuite la forme
SELECT HEAD(NonEmptyCrossJoin([Time].Members,1),1) ON COLUMNS

FROM SALES
et la requête MDX pour rechercher le dernier membre avec des données prend ensuite la forme :
SELECT TAIL(NonEmptyCrossJoin([Time].Members,1),1) ON COLUMNS

FROM SALES
La fonction peut ensuite être utilisée pour combiner les deux requêtes UNION() MDX en une seule requête :
SELECT
UNION(HEAD(NonEmptyCrossJoin([Time].Members,1),1), TAIL(NonEmptyCrossJoin([Time].Members,1),1)) ON COLUMNS
FROM SALES
La panne de l’espace disque pendant la
récupération d’un travail de traitement en échec
entraîne l’incident de SSAS
Cet article décrit une erreur de Microsoft SQL Server Analysis Services (SSAS) qui se produit lorsque l’espace
disque est épuisé sur le système hébergeant l’instance SSAS.
Symptômes
Toute version de SSAS se crashe lorsqu’elle subit une erreur d’I/S pendant la récupération d’un travail de
traitement qui a échoué. Lorsque ce problème se produit, le message d’erreur suivant peut être consigné dans le
journal des applications :
Erreur du système de fichiers : l’erreur suivante s’est produite lors de l’écriture dans le fichier « LazyWriter
Stream » : il n’y a pas suffisamment d’espace sur le disque. .
Erreur du système de fichiers : le thread d’arrière-plan exécutant le rédacteur différé a rencontré une erreur
d’E/S.
Ce problème peut se produire si l’espace disque disponible est épuisé. Ce problème peut entraîner un arrêt
d’urgence du service. L’arrêt ressemble à un blocage, bien qu’il soit initié en interne.
Pendant l’opération de rollback, certaines opérations d’opération d’ouverture de projet sont nécessaires pour
terminer la transaction. L’épuisement du disque peut provoquer une défaillance des E/S. Ainsi, il est impossible
de revenir à un état cohérent pour la transaction de manière déterministe. Le serveur ne doit pas continuer à
servir des données alors qu’il est dans un état incohérent. Dans ce cas, la seule façon de récupérer est d’arrêter
le serveur, puis de le forcer à redémarrer.
Lorsque le serveur redémarre, une opération de nettoyage se produit avant que des données ne sont
disponibles pour l’interrogation. Cette opération peut émaner en toute sécurité tous les fichiers du répertoire de
données. Le nettoyage supprime tous les fichiers qui ne sont pas confirmés comme valides et font partie des
données attendues.
S’applique à
SQL Server 2017 sur Windows (toutes les éditions)
SQL Server 2017 sur Linux (toutes éditions)
SQL Server 2016 Enterprise
Activer le niveau d’isolation des transactions
instantanées dans SQL Server 2005 Analysis
Services
Cet article décrit les étapes à suivre pour activer le niveau d’isolation des transactions instantanées dans
Analysis Services.
Introduction
Cet article explique comment activer le niveau d’isolation des transactions instantanées dans Microsoft SQL
Server Analysis Services. En outre, cet article explique comment tester si le niveau d’isolation des transactions
instantanées est activé.
Activer le niveau d’isolation des transactions de capture instantanée

Dans Analysis Services, vous pouvez utiliser le niveau d’isolation des transactions instantanées pour vous
connecter à SQL Server source de données. Pour activer le niveau d’isolation de transaction de capture
instantanée, suivez les étapes suivantes :
1. Dans SQL Server Management Studio, exécutez les instructions suivantes.
ALTER DATABASE <DatabaseName>

SET READ_COMMITTED_SNAPSHOT ON
GO
ALTER DATABASE <DatabaseName>
SET ALLOW_SNAPSHOT_ISOLATION ON
GO
NOTE
Dans ces instructions, il s’agit d’un espace réservé pour une base de données dans la source de données que vous
souhaitez <DatabaseName> utiliser dans Analysis Services.
2. Dans Business Intelligence Development Studio, créez un projet Analysis Services.

Vous pouvez également ouvrir un projet Analysis Services existant.
3. Si vous avez créé un projet Analysis Services à l’étape 2, suivez les étapes suivantes :
a. Dans l’Explorateur de solutions, cliquez avec le bouton droit sur Sources de données, puis cliquez sur
Nouvelle source de données.
b. Dans la boîte de dialogue Sélectionner comment définir la connexion, cliquez sur Nouveau. La
boîte de dialogue Gestionnaire des connexions s’affiche.
Si vous avez ouvert un projet Analysis Services existant à l’étape 2, suivez les étapes suivantes :
a. Sous le dossier Sources de données, double-cliquez sur la source de données existante.
b. Dans la boîte de dialogue Concepteur de source de données, cliquez sur Modifier. La boîte de
dialogue Gestionnaire des connexions s’affiche.
4. Dans la boîte de dialogue Gestionnaire des connexions, cliquez sur Native OLE DB\SQL Native
Client dans la liste Des fournisseurs.
5. Spécifiez le nom du serveur et l’authentification.
6. Pour tester la connexion, cliquez sur Tester la connexion.
7. Dans le volet gauche, cliquez sur Tout.
8. Dans le volet droit, cliquez sur True dans la liste connexion MARS, puis cliquez sur OK.
9. Dans la boîte de dialogue Concepteur de source de données, cliquez sur Instantané dans la liste
Isolation, puis cliquez sur OK .
Tester si le niveau d’isolation des transactions instantanées est activé

Pour tester si le niveau d’isolation des transactions instantanées est activé, suivez les étapes suivantes :
1. Démarrez SQL Server Profiler.
2. Créez un suivi pour vous connecter à la source de données que vous avez spécifiée dans le projet
Analysis Services.
3. Dans la boîte de dialogue Propriétés de suivi, cliquez sur l’onglet Sélection des événements.
4. Dans la colonne TransactionID, cliquez pour cocher les cases à cocher de la ligne de l’événement et de
la SQL:BatchCompleted ligne de SQL:BatchStarting l’événement.
NOTE
Pour afficher la colonne TransactionID, cochez la case Afficher toutes les colonnes.
5. Cliquez sur Exécuter pour démarrer le suivi.

6. Dans Business Intelligence Development Studio, traiter le projet Analysis Services.
7. Dans SQL Server Profiler, recherchez les événements et les événements qui ont la même valeur
SQL:BatchCompleted SQL:BatchStarting dans la colonne TransactionID. En règle générale, ces
événements SELECT contiennent l’instruction dans la colonne TextData. Pour ces événements, obtenez
l’ID de session dans la colonne SPID.
8. Pour vous connecter à la source de données, démarrez SQL Server Management Studio.
9. Créez une requête, puis exécutez l’instruction Transact-SQL suivante.
select session_id,Transaction_Isolation_Level from sys.dm_exec_sessions

where session_id=<SPID>
NOTE
Dans cette instruction, <SPID> il s’agit d’un espace réservé pour l’ID de session que vous avez obtenu à l’étape
7.
10. Sous l’onglet Résultats, notez la valeur dans la Transaction_Isolation_Level colonne. Cette valeur
indique le niveau d’isolation des transactions que vous utilisez dans le projet Analysis Services. Lorsque
le niveau d’isolation de transaction de capture instantanée est activé, la valeur dans la colonne
Transaction_Isolation_Level est 5 . Le tableau suivant indique les valeurs de la colonne
Transaction_Isolation_Level et les niveaux d’isolation des transactions correspondants.
VA L EUR N IVEA U D’ISO L AT IO N DES T RA N SA C T IO N S
0 Non spécifié.
1 ReadUncommitted
2 ReadCommitted
3 Répétable
4 Sérialisable
5 Capture instantanée
Références
Pour plus d’informations sur le niveau d’isolation des transactions instantanées, consultez les rubriques
suivantes dans SQL Server 2005 Books Online :
DÉFINIR LE NIVEAU D’ISOLATION DES TRANSACTIONS (Transact-SQL)
Activation des niveaux d’isolation basés sur le système de version de ligne
Niveaux d’isolation dans le Moteur de base de données
Erreur 1032 messages dans le journal d’application
Windows Server 2012
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez d’exécuter des instances de
SQL Server ou SQL Server Analysis Services sur un ordinateur qui exécute Windows Server 2012.
Version du produit d’origine : SQL Server Analysis Services, SQL Server
Symptômes
Prenons l’exemple du scénario suivant :
Vous installez Microsoft SQL Server ou SQL Server Analysis Services sur un ordinateur qui s’exécute
Windows Server 2012.
Vous utilisez le compte par défaut comme compte de service pour ces applications pendant l’installation.
L’installation a réussi.
Après l’installation, les services de ces programmes démarrent correctement.
Dans ce scénario, vous pouvez trouver dans le journal des applications des messages d’erreur semblables à ce
qui suit :
Pour les instances de SQL Server (SQLServr.exe)
sqlservr (3472) Une tentative d’ouverture du fichier « C:\Windows\system32\LogFiles\Sum\Api.log »

pour l’accès en lecture seule a échoué avec l’erreur système 5 (0x00000005) : « L’accès est refusé. ".
L’opération d’ouverture de fichier échoue avec l’erreur -1032 (0xfffffbf8).
sqlservr (3472) L’erreur -1032 (0xfffffbf8) s’est produite lors de l’ouverture du fichier journal
C:\Windows\system32\LogFiles\Sum\Api.log.
Pour les instances de SQL Server Analysis Services (Msmdsrv.exe)
msmdsrv (4680) Une tentative d’ouverture du fichier « C:\Windows\system32\LogFiles\Sum\Api.chk

» pour l’accès en lecture/écriture a échoué avec l’erreur système 5 (0x00000005) : « L’accès est refusé.
". L’opération d’ouverture de fichier échoue avec l’erreur -1032 (0xfffffbf8).
Msmdsrv (4680) Error -1032 (0xfffffbf8) occurred while opening logfile
C:\Windows\system32\LogFiles\Sum\Api.log.
Cause
Ce problème se produit en raison d’autorisations insuffisantes pour les comptes de démarrage de service pour
SQL Server et SQL Server Analysis Services lorsque les services accèdent au dossier suivant pour la
journalisation dans le cadre de la fonctionnalité Mesures d’utilisation des logiciels :
C:\Windows\System32\LogFiles\Sum
Solution de contournement
Pour contourner ce problème, ajoutez manuellement des autorisations de lecture/écriture aux comptes de
service utilisés par SQL Server (sqlservr.exe) et SQL Server Analysis Services (msmdsrv.exe) pour accéder au
\Windows\System32\LogFiles\Sum dossier.
La fonctionnalité Mesures de l’utilisation des logiciels utilise le service de journalisation de l’accès utilisateur
Windows Server 2012. Pour plus d’informations, voir Vue d’ensemble de la journalisation de l’accès utilisateur.
Erreur (l’optimiseur de requête a généré trop de
sous-ressources) et la requête MDX échoue dans
l’instance multidimensionnelle SSAS
Cet article vous aide à résoudre le problème qui se produit lorsque vous exécutez une requête MDX
(Multidimensional Expressions) sur une instance multidimensionnelle Microsoft SQL Server Analysis Services
(SSAS).
S’applique à : SQL Server 2012 Analysis Services, SQL Server 2014 Analysis Services, SQL Server 2016
Analysis Services, SQL Server 2017 Analysis Services Windows, SQL Server 2019 Analysis Services Windows
Symptômes
Lorsque vous exécutez une requête MDX (Multidimensional Expressions) sur une instance multidimensionnelle
Microsoft SQL Server Analysis Services (SSAS), la requête MDX échoue et renvoie le message d’erreur suivant :
L’optimiseur de requête a généré trop de sous-ressources dans le plan de requête
Cette erreur se produit si les conditions suivantes sont vraies :

Trop de membres calculés sont définis sur un seul niveau hiérarchique ou attribut.
De nombreux champs ou membres d’attribut sont placés sur chaque axe. Ou bien, de nombreux champs sont
rassemblés sur les lignes ou les colonnes d’un tableau croisé dynamique Microsoft Excel.
Tous les membres des hiérarchies sélectionnées sont inclus dans l’axe.
Les totaux et sous-totaux sont allumés dans le tableau Excel tableau croisé dynamique.
Cause
Le moteur de formule SSAS (FE) doit générer tous les ensembles MDX pertinents pour le sous-cube de requête
Stockage Engine (SE) ou sonar. Il existe une limite au nombre de sous-SE de requête par requête qui peuvent
être générés. Ce comportement est voulu par la conception même du produit. Actuellement dans le plan de
requête, une erreur se produit si la fe génère trop de sous-cubes de requête pour la requête.
Résolution
Pour éviter cette erreur, suivez les recommandations suivantes :
Dans le Excel tableau croisé dynamique, éteinez les totaux et les sous-totaux.
Supprimez la hiérarchie de l’axe Lignes ou Colonnes du tableau croisé dynamique dans Excel’interface
utilisateur.
Ne définissez pas trop de membres calculés (par exemple, plus de 500) sur la hiérarchie de dimension. Au
lieu de cela, vous devez avoir des membres réguliers dans la hiérarchie de dimension et utiliser des
expressions d’attribution d’étendue MDX (également appelées cellules calculées) pour remplacer les
expressions de ces membres calculés.
Erreur lors de la connexion à une instance nommée
de SQL Server Analysis Services à l’aide d’IPv6
Cet article vous aide à résoudre un problème qui peut se produire lorsque vous vous connectez à une instance
nommée de SQL Server Analysis Services qui est configurée pour utiliser IPv6.
Version du produit d’origine : SQL Server Entreprise
Symptômes
Dans Microsoft SQL Server, vous recevez une erreur ressemblant à ce qui suit lorsque vous essayez de vous
connecter à une instance nommée de SQL Server Analysis Services (SSAS) à l’aide d’IPv6 :
Aucune connexion n’a pu être réalisée car l’ordinateur cible l’a activement refusée [:: n ]: nnnnn (System)
NOTE
Dans cette erreur, n est un integer.
Cause
Ce problème peut se produire si le serveur qui héberge l’instance nommée de SSAS a été configuré pour utiliser
IPv4 et IPv6 lors de SQL Server été installé. Ensuite, le serveur a été reconfiguré pour utiliser uniquement IPv6.
Résolution
Pour résoudre ce problème, suivez les étapes suivantes :
1. Arrêtez le service SQL Server Analysis Services.
2. Ouvrez leMsmdredir.ini dans Bloc-notes.
NOTE
Par défaut, le Msmdredir.ini se trouve dans le dossier suivant
%ProgramFiles%\Microsoft SQL Server\90\Shared\ASConfig :
3. Dans la section Instances, vérifiez que les valeurs de la propriété Por t et de la propriété IPv6 sont
différentes pour l’instance nommée.
4. Supprimez la propriété Por tIPV6.
5. Enregistrez leMsmdredir.ini, puis quittez Bloc-notes .
6. Démarrez le SQL Server service Analysis Services.
Lorsque SSAS détecte que le serveur hôte est configuré pour écouter sur IPv4 et IPv6, SSAS crée deux entrées
dans le fichierMSmdredir.ini. Toutefois, si le serveur est configuré pour écouter sur un protocole, <Port> l’entrée
est utilisée.
Prenons le scénario dans lequel le serveur qui héberge l’instance nommée de SSAS a été configuré pour utiliser
IPv4 et IPv6 lors de l’installation de SQL Server, puis le serveur a été reconfiguré pour utiliser uniquement IPv6.
Dans ce scénario, le fichier Msmdredir.ini peut contenir des entrées obsolètes qui ne pointent pas vers les ports
sur lesquels l’instance nommée SSAS est à l’écoute.
Lorsque le service SQL Server Analysis Services démarre, il détecte les protocoles utilisés et met à jour
Msmdredir.ini fichier. Si le serveur a été configuré pour utiliser IPv4 et IPv6, il existe deux entrées dans
Msmdredir.ini fichier. Toutefois, si le service SQL Server Analysis Services détecte qu’un protocole est utilisé,
seule la propriété Port est mise à jour. Par conséquent, la propriété PortIPv6 peut contenir des informations
obsolètes.
Lorsque le service SQL navigateur lit les informations obsolètes, il peut rediriger les demandes vers l’instance
nommée et provoquer des échecs de connexion. Lorsque les informations obsolètes contenues dans la propriété
PortIPv6 sont supprimées, les informations de la propriété Port sont utilisées.
Messages d’erreur lorsque vous essayez de traiter
une base de données ou un cube
Cet article vous aide à résoudre le problème où vous recevez des messages d’erreur lorsque vous essayez de
traiter une base de données ou un cube dans SQL Server Analysis Services.
Symptômes
Dans SQL Server Analysis Services, vous essayez de traiter une base de données ou un cube à l’aide SQL Server
Business Intelligence Development Studio ou SQL Server Management Studio. Toutefois, l’opération de
processus échoue et vous recevez les messages d’erreur suivants :
Message d’erreur 1
Erreurs dans le moteur de stockage OLAP La clé d’attribut : : : TableName, Column :

ColumnName1, Value Value1 est in trouver : la clé d’attribut. Table : TableName, Column :
ColumnName2, Value: Value2.
Erreurs dans le moteur de stockage OLAP : l’enregistrement a été ignoré car la clé d’attribut est in
trouvée. Attribut : attribut généré X de dimension : DimensionName à partir de la base de données :
DatabaseName, Cube: CubeName, Measure Group: MeasureGroupName, Partition: PartitionName,
Record: RecordNumber.
Cause
Ce problème se produit car une table de faits pour un cube possède un ou plusieurs enregistrements qui
contiennent une clé d’attribut, et cette clé d’attribut n’existe pas dans la table de dimension correspondante. Ce
comportement peut se produire lorsque vous n’avez pas traitée la dimension correspondante avant de traiter le
cube ou lorsque les tables sous-jacentes ne correspondent pas. Si le champ « Valeur : » dans le message n’a pas
de numéro après, la table de faits doit contenir des données null.
Résolution
Pour résoudre ce problème, vous devez vérifier que votre source de données pointe vers les emplacements
suivants :
L’instance de source de données sous-jacente correcte, telle qu’une instance de SQL Server.
Base de données correcte.
Ensuite, corrigez les enregistrements sous-jacents qui contiennent la clé d’attribut problématique. Pour ce faire,
utilisez l’une des méthodes suivantes.
Utiliser une clé d’attribut existante
Mettez à jour les enregistrements pour utiliser une clé d’attribut existante en exécutant une instruction
semblable à ce qui suit :
Update <TableName> set <KeyName>=<ExistingKeyValue> where <KeyName>=<BadKeyValue> or <KeyName> IS NULL
Faire correspondre les valeurs clés dans la table de faits

Insérez des lignes supplémentaires dans la table de dimension pour qu’elle corresponde aux valeurs clés du
tableau de faits. S’il existe des valeurs null, utilisez l’une des méthodes suivantes :
Remplacez les valeurs null par des valeurs réelles.
Configurez la ou les dimensions pour qu’ils ont un membre inconnu en configurant les UnknownMember
propriétés et les UnknownMemberName dimensions. Vous pouvez rendre le membre inconnu visible ou
masqué en fonction de vos besoins.
Utilisez tous les paramètres suivants dans la boîte de dialogue Paramètres modification :
Définissez KeyErrorAction la propriété sur Conver tToUnknown .
Définissez NullKeyNotAllowed la propriété sur IgnoreError ou Repor tAndContinue .
Définissez NullKeyConvertedtoUnknown la propriété sur IgnoreError ou Repor tAndContinue .
Cliquez sur Ignorer le nombre d’erreurs.
Vous pouvez définir ces paramètres à l’échelle de l’instance ou utiliser une configuration personnalisée
pour chaque dimension.
Ignorer l’erreur
Si vous souhaitez traiter la base de données ou le cube sans corriger les données, vous pouvez définir la
configuration d’erreur pour l’opération de processus de manière à ignorer l’erreur. Vous ne devez le faire qu’en
tant que solution de contournement temporaire lorsque vous corrigez les données sous-jacentes. Dans le cas
contraire, vous risquez de recevoir des résultats inattendus de vos requêtes MDX (Multidimensional
Expressions). Pour ignorer les erreurs, suivez les étapes suivantes :
1. Dans la boîte de dialogue Base de données de processus - DatabaseName**** ou cube processus -
CubeName****, cliquez sur Modifier Paramètres .
2. Dans la boîte de dialogue Modifier Paramètres, cliquez sur l’onglet Erreurs de la touche Dimension.
3. Cliquez sur Utiliser la configuration d’erreur personnalisée.
4. Dans la liste Clé in trouvée, modifiez la valeur par défaut de Repor t et continuez à Ignorer l’erreur .
5. Cliquez sur Ignorer le nombre d’erreurs.
6. Cliquez sur OK pour fermer la boîte de Paramètres modifier.
7. Cliquez sur OK pour traiter la base de données ou le cube.
En outre, vous pouvez définir la configuration d’erreur pour le cube ou la partition de manière à ignorer l’erreur.
Pour plus d’informations, voir Error Configuration for Cube, Partition, and Dimension Processing.
Statut
Ce comportement est inhérent au produit.
Message d’erreur lors du traitement d’une
dimension
Cet article vous aide à résoudre le problème qui se produit lorsque vous traitez une dimension dans SQL Server
Analysis Service.
Symptômes
Dans SQL Server Analysis Service, le traitement des dimensions et vous pouvez recevoir un message d’erreur
Erreurs dans le moteur de stockage OLAP : une clé d’attribut en double a été trouvée lors du traitement :
Tableau : 'TABLE_NAME', Colonne : 'ATTRIBUTE_COLUMN_NAME, Valeur : 'ATTRIBUTE_VALUE'. L’attribut est «
ATTRIBUTENAME ».
Cause
Le comportement est de par sa conception. SQL Server Les services d’analyse détectent la clé d’attribut en
double pendant le traitement.
L’erreur ci-dessus peut également être déclenchée lorsque la base de données relationnelle est sensible à la cas
et que les valeurs de données sont en cas mixte. Dans Analysis Services, lors de la création d’une dimension et
de ses attributs, le classement par défaut de l’attribut ne fait pas l’affaire. La dimension par défaut a
ErrorConfiguration | KeyDuplicate définie sur Repor tAndStop . Ainsi, si vous avez une base de données
relationnelle qui, par exemple, contient des valeurs de données BOOKNAME et Bookname, pendant le
traitement des dimensions, si les données BOOKNAME ont d’abord été traitées en tant que clé d’attribut, le
traitement suivant échouera avec l’erreur suivante :
Une clé d’attribut en double a été trouvée lors du traitement : Table : 'TABLE_NAME', Column:
'ATTRIBUTE_COLUMN_NAME, Value: 'Bookname'. L’attribut est « ATTRIBUTENAME ».
Résolution
Lors de la conception de dimensions, d’attributs de dimension et de relations d’attributs, vous devez vérifier les
valeurs de données relationnelles pour les doublons et, si elles existent, utilisez l’une des procédures suivantes
pour résoudre le problème :
Option 1 : modifiez la requête nommée en affichage source de données pour sélectionner uniquement
les données avec le cas souhaité.
Par exemple, vous pouvez utiliser ou UPPER utiliser la fonction de cas dans la requête LOWER nommée.
Option 2 : vous pouvez contourner le problème à l’aide de l’une des options suivantes :
NOTE
Ces options ne sont généralement pas recommandées, car elles peuvent entraîner des données inattendues, mais
peuvent être utilisées à des fins de dépannage.
Définissez la valeur de l’élément KeyDuplicate sur Repor tAndContinue et

KeyErrorLimitAction sur StopLogging dans ErrorConfiguration .
À l’aide de l’éditeur de dimension dans Business Intelligence Development Studio (BIDS), ouvrez la
dimension à qui appartient l’attribut et définissez le classement approprié pour l’attribut à l’aide de
la propriété Collation de la dimension.
NOTE
La dimension aura alors une clé d’attribut en double (différentes valeurs de cas) une fois le traitement
terminé.
Message d’erreur lorsque vous utilisez un
PowerPivot pour Excel de travail en tant que source
de données dans SQL Server Analysis Services
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez d’utiliser un PowerPivot pour
un Excel comme source de données dans SQL Server Analysis Services.
Symptômes
Vous configurez Microsoft PowerPivot pour Excel sur un serveur intermédiaire.
Vous configurez le serveur pour qu’il utilise l’authentification Kerberos, puis vous connectez au serveur.
Vous essayez d’utiliser une PowerPivot pour Excel de travail en tant que source de données dans Microsoft
SQL Server Analysis Services.
Dans ce scénario, vous pouvez recevoir un message d’erreur semblable à ce qui suit :
Erreur HTTP 401.
Cause
Ce problème se produit car les liaisons personnalisées pour le service de redirection sont configurées pour
utiliser l’authentification Microsoft NTLM. En outre, les liaisons personnalisées sont configurées pour ne pas
négocier.
Résolution
Pour résoudre ce problème, activez l’authentification Kerberos pour le service de redirection. Pour cela, procédez
comme suit :
1. Back up the Web.config file for the Redirector service.
NOTE
Par défaut, le Web.config se trouve dans le dossier :
%SystemDrive%\program files\common files\web service extensions\14\ISAPI\powerpivot .
2. Ouvrez leWeb.config pour le service de redirection dans Bloc-notes.

3. Recherchez <binding name="RedirectorBinding"> la balise, puis modifiez authenticationScheme la valeur
comme suit :
Original
<binding name="RedirectorBinding">
<webMessageEncoding
webContentTypeMapperType="Microsoft.AnalysisServices.SharePoint.Integration.Redirector.RawCont
entTypeMapper, Microsoft.AnalysisServices.SharePoint.Integration" />
<httpTransport manualAddressing="true" authenticationScheme="Ntlm" transferMode="Streamed"
maxReceivedMessageSize="9223372036854775807"/>
</binding>
Mis à jour
<binding name="RedirectorBinding">
<webMessageEncoding
<httpTransport manualAddressing="true" authenticationScheme="Negotiate"
transferMode="Streamed" maxReceivedMessageSize="9223372036854775807"/>
</binding>
4. Recherchez la>,puis modifiez la valeur <binding name="RedirectorSecureBinding"

authenticationScheme comme suit :
Original
<binding name="RedirectorSecureBinding">
<webMessageEncoding
<httpsTransport manualAddressing="true" authenticationScheme="Ntlm" transferMode="Streamed"
maxReceivedMessageSize="9223372036854775807"/>
</binding>
Mis à jour
<binding name="RedirectorSecureBinding">
<webMessageEncoding
<httpsTransport manualAddressing="true" authenticationScheme="Negotiate"
transferMode="Streamed" maxReceivedMessageSize="9223372036854775807"/>
</binding>
5. Dans le menu Fichier , cliquez sur Enregistrer .

6. Quittez Bloc-notes.
Une requête MDX qui contient une fonction
Aggregate renvoie une erreur pour les valeurs de
cellule dans SQL Server Analysis Services
Cet article décrit un problème qui se produit si l’ensemble dans la Aggregate fonction contient un membre
calculé.
Symptômes
Vous avez une requête MDX (Multidimensional Expressions) qui utilise la Aggregate fonction. L’ensemble
spécifié dans la fonction Aggregate contient un membre calculé. Lorsque vous exécutez la requête MDX sur une
instance de Microsoft SQL Server Analysis Services, la requête renvoie #Error valeurs des cellules. Si vous
cliquez sur une cellule, vous recevez le message d’erreur suivant dans la boîte de dialogue Propriétés de la
cellule :
Un ensemble a été rencontré et ne peut pas contenir de membres calculés
NOTE
Vous recevez le message d’erreur dans la colonne Valeur de la VALUE propriété et de la FORMATTED_VALUE propriété.
Cause
Ce problème se produit parce qu’un membre calculé contient la fonction et que cette fonction possède un
ensemble de membres Aggregate non aggrégables.
Par exemple, considérez la requête MDX mentionnée dans la section Étapes pour reproduire le problème. Dans
l’exemple de base de données [Adventure works DW], le [Scénario]. Le membre [Scénario] n’est pas aggrégable.
La propriété IsAggregatable de cet attribut de dimension est définie sur False . Si vous exécutez cette requête
MDX, vous recevrez le message d’erreur mentionné dans la section Symptômes.
Étapes pour reproduire le problème

1. Dans SQL Server Business Intelligence Development Studio, ouvrez l’exemple de projet Adventure Works
DW Êdition Entreprise projet.
NOTE
L’exemple de projet Adventure Works DW Êdition Entreprise est inclus dans le projet de base de données Analysis
Services. Pour télécharger le projet de base de données Analysis Services, voir les exemples de bases de données
AdventureWorks.
2. Déployez l’exemple de projet sur une instance de SQL Server Analysis Services.
3. Ouvrez SQL Server Management Studio, puis connectez-vous à l’instance d’Analysis Services.
4. Cliquez sur Nouvelle requête .
5. Dans la fenêtre de requête, exécutez la requête MDX suivante :
WITH MEMBER
[Scenario].[Scenario].[MyMember]
AS
AGGREGATE(
{[Scenario].[Scenario].&[1],
[Scenario].[Scenario].&[2],
[Scenario].[Scenario].&[3],
[Scenario].[Scenario].[Budget Variance]
})
SELECT
{[Measures].[Amount]} ON AXIS(0)
FROM
[Adventure Works]
WHERE [Scenario].[Scenario].[MyMember]
Les requêtes MDX avec mesure calculée à l’aide de
l’opérateur « / » s’exécutent lentement dans SSAS
Cet article vous aide à résoudre le problème lorsqu’une requête MDX (Multidimensional Expressions) est
exécutée avec une mesure calculée dans les instances tabulaires SSAS 2016, 2017 et 2019.
S’applique à : Analysis Services, SQL Server 2016, SQL Server 2019, SQL Server 2017 Windows, Analysis
Cubes
Symptômes
Lorsqu’une requête MDX (Multidimensional Expressions) est exécutée avec une mesure calculée dans les
instances tabulaires SSAS 2016, 2017 et 2019, la mesure calculée s’exécute lentement et consomme beaucoup
d’activités si elle utilise / l’opérateur.
Cause
Une fonction DIVIDE améliorée permettant d’accélérer les performances est disponible dans MDX et DAX.
Résolution
Utilisez la fonction DIVIDE au lieu de / l’opérateur dans le calcul.
Références
terminDescription of the standard terminology that is used to describe Microsoft software updatesology
Aucun résultat pour la requête de script XMLA pour
les propriétés/membres d’une hiérarchie de
dimension
Cet article vous aide à contourner le problème qui se produit lorsque vous essayez d’obtenir les propriétés et les
membres d’une hiérarchie de dimensions à l’aide du script XML for Analysis (XMLA).
Version du produit d’origine : SQL Server 2016 Business Intelligence, SQL Server 2016 Analysis Services
Symptômes
Supposons que vous Microsoft SQL Server 2016 Analysis Services (SSAS 2016) soit installé. Lorsque vous
essayez d’obtenir les propriétés d’une hiérarchie de dimensions spécifique et de ses membres à l’aide du script
XMLA dans SSAS 2016, aucun résultat n’est renvoyé.
NOTE
Le même script XMLA fonctionne dans SQL Server 2014 Analysis Services ou des versions antérieures de SQL Server
Analysis Services.
This issue only occurs when HierarchyUniqueNameStyle is set to ExcludeDimensionName .
Cause
Ce problème se produit car la valeur ExcludeDimensionName était destinée uniquement à la prise en charge
d’anciennes bases de données, telles que SQL Server 2000 ou 2005. Si HierarchyUniqueNameStyle elle est définie
sur ExcludeDimensionName , toute demande XMLA qui inclut dans le produit DIMENSION_UNIQUE_NAME des
résultats RestrictionList vides.
Pour contourner ce problème, définissez la valeur HierarchyUniqueNameStyle sur IncludeDimensionName
dans l’objet de dimension de cube.
Comment effectuer une requête distribuée SQL
Server avec OLAP Server
Cet article explique comment effectuer une requête distribuée SQL Server avec OLAP Server.
Résumé
Cet article explique comment effectuer une requête distribuée SQL Server pour récupérer des données à partir
d’un cube OLAP Services (ou Analysis Services). Avec Microsoft SQL Server, vous pouvez effectuer des requêtes
auprès de fournisseurs OLE DB. Pour ce faire, vous pouvez utiliser l’une des suivantes :
Utilisez les OPENQUERY fonctions OPENROWSET Transact-SQL.
Utilisez une requête avec des noms en quatre partie, y compris un nom de serveur lié.
Par exemple :
sp_addlinkedserver 'mylinkedserver', 'product_name', 'myoledbprovider', 'data_source','location',

'provider_string', 'catalog'
SELECT *
FROM OPENQUERY(mylinkedserver, 'select * from table1')
Vous pouvez utiliser la ou la fonction dans une instruction SQL Server pour transmettre des requêtes au serveur
OPENROWSET OPENQUERY SELECT OLAP lié. La requête est limitée à la syntaxe abrégée prise en charge par OLAP
Services ; toutefois, la requête peut inclure la SELECT syntaxe MDX (Multidimensional Expressions). Une requête
qui inclut MDX renvoie des jeux de lignes aplatis, comme décrit dans la documentation OLE DB. Pour plus
d’informations sur la syntaxe prise en charge par SQL Server OLAP Services, voir la rubrique Syntaxe SQL
SELECT prise en charge dans la bibliothèque en ligne des SELECT services OLAP.
Pour interroger une base de données de serveur OLAP locale ou distante à partir de SQL Server, vous devez
installer le fournisseur OLE DB MSOLAP sur l’ordinateur qui exécute SQL Server. Le fournisseur MSOLAP OLE
DB est installé lorsque vous installez les composants clients OLAP à partir du SQL Server.
Exemple OPENROWSET et OPENQUERY

L’exemple de code Transact-SQL montre comment configurer et utiliser des requêtes distribuées avec un serveur
OLAP avec les OPENQUERY OpenRowset fonctions et les fonctions. Vous devez modifier les noms de source de
données et le nom de catalogue, le cas échéant.
------------------------------------------
--OPENROWSET for OLAP Server
------------------------------------------
SELECT a.*
FROM OpenRowset('MSOLAP','DATASOURCE=myOlapServer; Initial Catalog=FoodMart;',
'SELECT Measures.members ON ROWS,
[Product Category].members ON COLUMNS
FROM [Sales]') as a
go
-- Example of MDX with slicing --
SELECT a.*
FROM OpenRowset('MSOLAP','DATASOURCE=myOlapServer; Initial Catalog=FoodMart;',
'SELECT
{ Time.Year.[1997] } ON COLUMNS,
NON EMPTY Store.MEMBERS ON ROWS
FROM Sales
WHERE ( Product.[Product Category].[Dairy] )') as a
--------------------------------------------------
-- Linked Server Examples with OPENQUERY
--------------------------------------------------
EXEC sp_addlinkedserver
@server='olap_server',
@srvproduct='',
@provider='MSOLAP',
@datasrc='server',
@catalog='foodmart'
go
-- MDX in OPENQUERY --
SELECT *
FROM OPENQUERY(olap_server,
'SELECT
{ Time.Year.[1997] } ON COLUMNS,
NON EMPTY Store.MEMBERS ON ROWS
FROM Sales
WHERE ( Product.[Product Category].[Dairy])' )
NOTE
La rubrique Transmission de requêtes de SQL Server à un serveur OL AP lié, dans la documentation en ligne des services
OLAP, présente un bogue de documentation dans l’exemple de code :
SELECT *
FROM OPENQUERY(olap_server, 'SELECT [customer], [quantity] FROM sales')
Seule une forme limitée de SQL est prise en charge, et seuls les noms de niveau ou de mesure peuvent être
spécifiés. Lorsque vous exécutez la requête, vous recevez ce message d’erreur :
Serveur : Msg 7399, Level 16, State 1, Line 1 OLE DB provider 'MSOLAP' reported an error. [Message
renvoyé par le fournisseur OLE/DB : Le nom de colonne « client » n’est pas valide. Seuls les noms de
niveau ou de mesure peuvent être spécifiés.]
L’une des façons de résoudre la requête consiste à utiliser ce qui suit :

SELECT *
FROM OPENQUERY(olap_server, 'SELECT [unit sales] FROM sales')
Toutefois, le SQL instructions de ce formulaire à OLAP Server peut être lent et vous pouvez recevoir une erreur
de délai d’SQL sur certains ordinateurs :
Le fournisseur OLE DB « MSOLAP » a signalé une erreur. [Message renvoyé par le fournisseur OLE/DB :
impossible d’ouvrir la base de données « foodmart » ] [Message renvoyé par le fournisseur OLE/DB : erreur
de serveur OLAP : l’opération demandée a échoué en raison du délai d’échéance.]
Exemples de serveurs liés avec des noms en quatre partie

L’exemple de code SQL transact dans cette section illustre l’utilisation d’un serveur lié avec un nom en quatre
parties pour interroger un cube OLAP. Dans le code, le serveur lié nommé Olap_server a été créé dans
l’exemple précédent :
Select [Store:Store Name]

from Olap_server.FoodMart..[sales]
WHERE [Store:Store State]='WA'
go
Select [Product:Product Category], count ([Store:Store Name])
from Olap_server.FoodMart..[sales]
WHERE [Store:Store State]='WA'
GROUP BY [Product:Product Category]
Bien que les exemples de serveur liés avec un nom en quatre partie fonctionnent bien, ils peuvent prendre
beaucoup de temps pour renvoyer un résultat au client. La syntaxe de nom en quatre SQL Server concept ; Il est
utilisé dans une commande Transact-SQL pour faire référence à une table dans un serveur lié et sa syntaxe est
limitée pour les requêtes OLAP. SQL Server peut déterminer qu’il doit lire la table de faits entière à partir
d’OLAP Server et effectuer l’opération proprement dite, ce qui peut prendre beaucoup de temps GROUP BY et de
ressources.
Microsoft recommande d’envoyer une instruction MDX par le biais d’une fonction ou d’une fonction, comme
illustré dans OPENROWSET OPENQUERY les exemples précédents. Cette méthode permet SQL Server envoyer la
commande directement au fournisseur OLAP lié, sans essayer de l’essayer. La commande peut être MDX ou le
sous-ensemble de SQL que le fournisseur OLAP prend en charge. Vous pouvez utiliser le jeu de lignes renvoyé
par la OPENQUERY fonction dans d’SQL opérateurs. Pour les requêtes MDX de base et les requêtes qui retournent
une quantité de données relativement faible (comme un écran), le jeu de résultats doit toujours être créé en
moins de GROUP BY 10 secondes, généralement en 5 secondes, quelle que soit la taille du cube. Si les requêtes
prennent plus de temps, vous pouvez créer davantage d’agrégations à l’aide de l’Assistant Analyse basée sur
l’utilisation.
Conseils de performances
Voici quelques conseils de performances :
SQL Server ouvre deux connexions au fournisseur OLAP pour chaque requête. L’une de ces requêtes est
réutilisée pour les requêtes ultérieures ; Par conséquent, si vous exécutez à nouveau la commande, la
deuxième requête peut s’exécuter plus rapidement.
Pour augmenter la vitesse, groupez par une autre dimension (car vous avez moins de données).
Dans le pire des cas, le cube est stocké par le biais d’olap relationnels (ROLAP) et il n’y a pas d’agrégation.
Ensuite, le serveur OLAP ouvre une connexion à SQL Server pour obtenir les lignes de table de faits.
N’utilisez pas SQL Server requête distribuée dans ce cas.
Si vous avez simplement besoin d’un jeu de résultats provenant d’un serveur OLAP ou d’un fichier cube,
essayez d’utiliser une application SQL Server OLE DB C++ ou ADO(ADO*MD) directement sur le serveur
OLAP ou sur un fichier de cube.
SQL Server installe certains fournisseurs OLE DB et les configure pour qu’ils se chargent in-process. Étant
donné que le fournisseur MSOLAP n’est pas installé par SQL Server, il est configuré pour charger hors
processus. Microsoft recommande vivement de modifier les options de chargement in-process du
fournisseur OLAP, car cette configuration améliore les performances de vos requêtes OLAP. Pour apporter
la modification, suivez les étapes suivantes :
1. Dans le dossier Sécurité, cliquez avec le bouton droit sur Ser veurs liés, puis cliquez sur Nouveau
ser veur lié.
2. Pour le nom du fournisseur, cliquez pour sélectionner le fournisseur OLE DB pour les ser vices
OL AP.
3. Cliquez sur Options .
4. Cliquez pour sélectionner Autoriser InProcess .
5. Cliquez sur OK .
Références
Pour obtenir une description détaillée des paramètres de procédure sp_addlinkedserver stockée, voir
SQL Server Books Online.
Pour plus d’informations sur la configuration et l’utilisation de requêtes distribuées, recherchez sur , et
sur les sp_addlinkedserver OPENQUERY OPENROWSET rubriques connexes, dans SQL Server Books Online.
Pour en savoir plus sur la technologie OLAP et la syntaxe MDX, consultez la bibliothèque en ligne des
services OLAP.
Résultat inattendu d’Analysis Services lorsque
Dimension DefaultMember n’est pas Tout et qu’un
filtre de rapport est appliqué Excel
Cet article vous aide à contourner le problème dans lequel vous obtenez un résultat inattendu d’Analysis
Services lorsque Dimension n’est pas tout et qu’un filtre de rapport est appliqué DefaultMember Excel.
Résumé
Lorsque la hiérarchie d’attributs dimension est définie sur un membre autre que le membre ALL et que vous
exécutez une requête MDX qui utilise un , qui renvoie un ensemble qui exclut le , les valeurs renvoyées dans le
plus à l’extérieur sont les valeurs d’agrégat associées aux membres de l’ensemble défini dans DefaultMember
sub-select le DefaultMember SELECT sub-select . Si la requête MDX (Multidimensional Expressions) utilise un
, qui renvoie un ensemble qui inclut les , les valeurs renvoyées dans le SELECT le plus extérieur sont les valeurs
sub-select DefaultMember associées à DefaultMember la .
Le comportement conçu est que, le plus à l’extérieur, les membres par défaut sur les axes sont déterminés en
fonction de ce qui est disponible dans l’espace du sous-cube défini par les SELECT SELECT instructions internes.
S’il se trouve dans le slicer, mais pas sur un axe, les valeurs associées à DefaultMember DefaultMember l’axe sont
renvoyées. Si l’objet est exclu du slicer, les valeurs renvoyées sont écrasées par les valeurs DefaultMember
d’agrégation sous un membre « ALL ».
Lorsque vous utilisez Excel 2007 ou Excel 2010 pour interroger une base de données Analysis Services, une
pratique relativement courante et une nécessité fréquente consiste à découper le cube en setting un filtre à l’aide
d’une ou plusieurs des dimensions dans la zone « Filtre de rapport » du contrôle Tableau croisé dynamique.
Lorsque cette action est effectuée, le client Excel génère une requête MDX qui inclut une clause ou interne pour
filtrer les données et limiter l’espace SELECT sub-select du cube. Par exemple, en utilisant Excel 2010 et en se
connectant à la base de Adventure Works DW 2008 données, en plaçant [Mesures].[ Montant des ventes Internet]
dans la section Valeurs du tableau croisé dynamique, en ajoutant la hiérarchie, y compris
[Customer].[Customer Geography] uniquement le [Client].[ Géographie du client]. [Pays]. Membre [Canada] et
ajout de la dimension à la zone Filtre de lignes, puis définition d’un filtre qui inclut uniquement et , la valeur
renvoyée est [Product].[Category] [Product].[Category].[Accessories] [Product].[Category].[Bikes] $1 924
680,24 . Dans ce cas, la requête générée par le Excel est :
SELECT
NON EMPTY Hierarchize(AddCalculatedMembers(
{DrilldownLevel({[Customer].[Customer Geography].[All Customers]})}))
DIMENSION PROPERTIES PARENT_UNIQUE_NAME, HIERARCHY_UNIQUE_NAME ON COLUMNS
FROM (SELECT ({[Customer].[Customer Geography].[Country].&[Canada]}) ON COLUMNS
FROM (SELECT ({[Product].[Category].&[1], [Product].[Category].&[4]}) ON COLUMNS
FROM [Adventure Works]))
WHERE ([Measures].[Internet Sales Amount])
CELL PROPERTIES VALUE, FORMAT_STRING, LANGUAGE, BACK_COLOR, FORE_COLOR, FONT_FLAGS
Si les conditions filter sont modifiées afin que le filtre de lignes contienne désormais les membres et que la
valeur renvoyée est [Product].[Category].[Accessories] [Product].[Category].[Clothing] $156 542,47 et que
la requête générée par Excel est :
SELECT
NON EMPTY Hierarchize(AddCalculatedMembers(
{DrilldownLevel({[Customer].[Customer Geography].[All Customers]})}))
DIMENSION PROPERTIES PARENT_UNIQUE_NAME, HIERARCHY_UNIQUE_NAME ON COLUMNS
FROM (SELECT ({[Customer].[Customer Geography].[Country].&[Canada]}) ON COLUMNS
FROM (SELECT ({[Product].[Category].&[3], [Product].[Category].&[4]}) ON COLUMNS
FROM [Adventure Works]))
WHERE ([Measures].[Internet Sales Amount])
CELL PROPERTIES VALUE, FORMAT_STRING, LANGUAGE, BACK_COLOR, FORE_COLOR, FONT_FLAGS
Si la conception de la hiérarchie d’attributs est modifiée pour définir la propriété sur , et que le tableau croisé
dynamique est définie pour utiliser la condition de filtre suivante, le membre sur les colonnes, avec
[Product].[Category] DefaultMember le [Product].[Category].&[2]
[Customer].[Customer Geography].[Country].[Canada] [Produit].[ Dimension Category] de la zone De filtrage des
lignes, y compris uniquement et , la requête générée par Excel est identique à la première et la valeur renvoyée
est [Product].[Category].[Accessories] [Product].[Category].[Bikes] $1 821 302,39 bien que la valeur
agrégée pour les deux et à l’intersection avec est [Product].[Category].[Accessories]
[Product].[Category].[Bikes] [Customer].[Customer Geography].[Country].&[Canada] $1 924 680,24 . Si le
[Produit]. [Category] attribute hierarchy is moved to either the Rows or Columns axis, the value displayed for the
'Grand Total' is $1,924,680.24 . Si la hiérarchie d’attributs est déplacée vers la zone De filtre de ligne et que les
conditions de filtre sont de nouveau modifiées afin que le filtre de ligne contienne maintenant les membres et ,
la valeur renvoyée est [Product].[Category] [Product].[Category].[Accessories] $156 542,47 et la requête
MDX générée par Excel est identique à la deuxième requête [Product].[Category].[Clothing] MDX ci-dessus.
Ce comportement est inhérent au produit. Les membres par défaut sont déterminés lors de l’exécution de la
requête en fonction des membres disponibles dans l’espace de cube. Si le membre par défaut d’une hiérarchie
se trouve dans le slicer qui définit l’espace de cube utilisé pour l’exécution des requêtes et que la hiérarchie n’est
pas explicitement incluse sur l’un des axes, les valeurs associées au membre par défaut sont renvoyées. Si le
membre par défaut d’une hiérarchie se trouve dans le slicer qui définit l’espace de cube utilisé pour l’exécution
des requêtes et que la hiérarchie est explicitement incluse sur l’un des axes, les valeurs des membres individuels
sont renvoyées et la valeur agrégée des membres s’affiche sous la forme d’un total général . Si le membre par
défaut d’une hiérarchie n’est pas dans le slicer qui définit l’espace de cube utilisé pour l’exécution des requêtes et
que la hiérarchie n’est pas explicitement incluse sur l’un des axes, les valeurs agrégées des membres du slicer
sont renvoyées en tant que membre « ALL ».
Pour contourner ce comportement, filtrez les hiérarchies avec DefaultMembers définies sur un membre autre
que le membre « ALL » sur lignes ou colonnes.
Problème de performances d’écriture écriture
lorsque la sécurité des cellules est activée dans SQL
Server Analysis Services
Cet article vous aide à contourner le problème de performances d’écriture écriture qui se produit lorsque la
sécurité des cellules est activée dans SQL Server Analysis Services.
Version du produit d’origine : SQL Server 2012 Analysis Services
Symptômes
Supposons que vous exécutez Microsoft SQL Server Analysis Services (SSAS) sous un rôle pour lequel la
sécurité des cellules est activée. Lorsque vous essayez d’exécuter une instruction MDX (Multidimensional
Expressions) UPDATE CUBE, l’exécution de l’instruction peut prendre plus de temps que pour un rôle pour lequel
la sécurité des cellules n’est pas activée.
Cause
Ce comportement est inhérent au produit. Lorsque la sécurité des cellules est activée, le moteur Analysis
Services exécute les requêtes en mode cellule par cellule. Si l’opération d’écriture écriture/écriture effectue une
allocation à un niveau élevé, l’espace des cellules de niveau feuille est important.
NOTE
L’espace n’est pas le nombre de lignes dans la table de faits. L’espace est l’espace complet entre les jointeurs de tous les
attributs de granularité de dimension. Il faut beaucoup de temps pour éumer ces cellules une par une afin de vérifier la
sécurité des cellules.
Pour contourner ce problème, appliquez l’une des méthodes ci-dessous.
Méthode 1
Placez les mesures qui doivent être sécurisées dans un cube distinct et implémentez la sécurité d’écriture
au niveau du cube sous votre rôle.
NOTE
Les performances lorsque vous utilisez cette méthode sont aussi rapides que lorsque la requête s’exécute sous un
rôle d’administrateur. Toutefois, la conception de votre cube devient complexe et vous devez créer des cubes
virtuels pour utiliser des groupes de mesures liés afin de retourner les différentes mesures dans une seule requête
MDX. En outre, lorsque vous effectuez l’opération d’écriture écriture, vous devez créer une requête MDX qui utilise
le nom de cube correct en fonction de la mesure d’écriture.
Méthode 2
Effectuez l’opération d’écriture en écriture avec le niveau de granularité le plus bas d’un membre. Vous ne
pouvez pas allouer de nombreux membres de granularité détaillés.
NOTE
Vous de devez peut-être créer des membres factices dans les tables de dimension qui sont marqués comme
membres d’ajustement dans chaque dimension, pour prendre en charge l’opération d’écriture.
« #N/A » renvoie lorsque vous exécutez une
requête à plusieurs sous-SQL Server Analysis
Services
Cet article présente un problème qui se produit lorsque vous exécutez une requête à plusieurs sous-sous-SQL
Server Analysis Services.
Version du produit d’origine : SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012
Symptômes
Vous installez Analysis Services en mode sur une instance de Multidimensional SQL Server 2012, SQL
Server 2014, SQL Server 2016 ou SQL Server 2017.
Il existe une base de données dans cette instance.
Vous créez un rôle avec une autorisation de lecture de sécurité des cellules pour cette base de données.
Vous exécutez une requête qui contient un sous-choix avec plusieurs membres.
Dans ce cas, vous obtenez des valeurs de cellule #N/A pour la mesure si le sous-contrôle multi-membres est
inférieur ou inférieur à la granularité et si les membres de niveau supérieur dont les valeurs sont affectées par
les autorisations de lecture de sécurité des cellules leur sont appliquées.
Cause
Ce comportement est inhérent au produit. Cette conception permet de s’assurer que la base de données
n’expose pas de valeurs de cellules réelles qui sont sécurisées par la sécurité des cellules.
S’applique à
SQL Server 2012
SQL Server 2012 Analysis Services
SQL Server 2014
SQL Server 2014 Business Intelligence
SQL Server 2016
SQL Server 2017 sur Windows
Can’t start SQL Server Analysis Services clustered
instance after changing service account
Cet article vous aide à résoudre le problème qui se produit lorsque vous modifiez le compte de service qui a été
spécifié lors de la configuration SQL Server à un nouveau compte de domaine à l’aide de Gestionnaire de
configuration SQL Server.
Symptôme
Supposons que vous avez des instances en cluster dans Microsoft SQL Server 2008 ou dans SQL Server 2008
R2. Lorsque vous modifiez le compte de service dans Gestionnaire de configuration SQL Server du compte
spécifié lors de la configuration d’SQL Server à un nouveau compte de domaine, vous recevez un message
d’erreur semblable au suivant dans Gestionnaire de configuration SQL Server :
Erreur de fournisseur WMI

Erreur non spécifiée [0x80004005]
En outre, vous ne pouvez pas démarrer l’instance SQL Server cluster Analysis Services. Lorsque vous vérifiez le
journal des événements système, vous voyez le message d’erreur suivant :
Le service MSSQLServerOLAPService n’a pas pu se connecter comme avec le mot de passe actuellement
configuré en raison de <Domain> <New account> l’erreur suivante :
Échec de la logon: l’utilisateur n’a pas reçu le type de logon sur cet ordinateur.
Service : MSSQLServerOLAPService
Domaine et compte :<Domain><New account>
Ce compte de service n’a pas le droit d’utilisateur requis « Se connecter en tant que service ».
Action de l'utilisateur
Affectez « Se connecter en tant que service » au compte de service sur cet ordinateur. Vous pouvez utiliser
l’Paramètres de sécurité locale (Secpol.msc) pour ce faire. Si cet ordinateur est un nœud dans un cluster,
vérifiez que ce droit d’utilisateur est affecté au compte de service de cluster sur tous les nœuds du cluster.
Si vous avez déjà affecté ce droit d’utilisateur au compte de service et que le droit d’utilisateur semble être
supprimé, vérifiez auprès de votre administrateur de domaine si un objet de stratégie de groupe associé à ce
nœud peut supprimer le droit.
NOTE
Le service indiqué précédemment est pour l’instance par défaut. Pour une instance nommée, le nom du service est
MSOLAP$ <instance name> .
Cause
Ce problème se produit car lorsque vous définissez l’instance en cluster d’Analysis Services, le SID du service
n’est pas autorisé à se connecter en tant que droit utilisateur de stratégie locale de ser vice
(SeServiceLogonRight).
Résolution
Pour résoudre ce problème, accordez au service Analysis Services SQL Server sid l’utilisateur de la stratégie
locale se connecter en tant que service.
Pour une instance par défaut de SQL Server Analysis Services, le nom du SID de service est
NT SERVICE\MSSQLServerOLAPService .
Pour une instance nommée, le nom est NT SERVICE\MSOLAP$\<instance name> .
Pour accorder au siD de ser vice le droit d’ouvrir une session en tant que service, suivez les étapes suivantes :
1. Ouvrez la stratégie de sécurité locale en exécutant la commande Secpol.msc.
2. Développez les stratégies locales.
3. Cliquez sur Attribution des droits d’utilisateur.
4. Dans le volet droit, cliquez avec le bouton droit sur Ouvrir une session en tant que ser vice, puis cliquez
sur Propriétés.
5. Cliquez sur Ajouter un utilisateur ou un groupe.
6. Cliquez sur le bouton Emplacements, sélectionnez le nom du serveur, puis cliquez sur OK.
7. Dans Entrez les noms d’objets à sélectionner, tapez NT SERVICE\MSSQLServerOLAPService, puis
cliquez sur OK .
NOTE
Pour une instance nommée, utilisez plutôt MSOLAP$\<instance name> .
8. Cliquez sur OK .
Vous devez répéter ces étapes pour tous les nodes dans le cluster.
This issue only affects clustered instances of Analysis Services for SQL Server 2008 and SQL Server 2008 R2.
Pour SQL Server 2012 et les versions ultérieures du programme, vous ne pouvez pas reproduire ce problème.
Erreur (la clé donnée n’était pas présente dans le
dictionnaire) et l’installation SQL Server FCI échoue
sur une VM Azure dans Server 2019
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez d’installer une instance de
cluster de Microsoft SQL Server (FCI) dans Windows Server 2019 sur une machine virtuelle (VM) Microsoft
Azure.
S’applique à : SQL Server VM - Windows, Windows Server 2019
Symptômes
Lorsque vous essayez d’installer une instance en cluster de Microsoft SQL Server (FCI) dans Windows Server
2019 sur une machine virtuelle Microsoft Azure, l’installation échoue et vous recevez le message d’erreur
suivant :
La clé donnée n’était pas présente dans le dictionnaire.
Dans ce cas, vous pouvez voir les informations supplémentaires suivantes dans le fichier journal Details.txt dans
le dossier SQL Server’installation :
Données d’action : Fonctionnalité = SQL_Engine_Core_Inst_sql_engine_core_inst_Cpu64 Scenario = install

Timing = ConfigNonRC ConfigObjectType = Microsoft.SqlServer.Configuration.
ClusterConfiguration.FailoverClusterNamePrivateConfigObject FeatureName = SQL_Engine_Core_Inst
FeatureCpuType = Cpu64 FeaturePackageId = sql_engine_core_inst FeatureClusterState =
CompleteFailoverCluster Configuration action failed for feature SQL_Engine_Core_Inst during timing
ConfigNonRC and scenario ConfigNonRC. La clé donnée n’était pas présente dans le dictionnaire. La
catégorie d’échec de configuration de l’exception actuelle est l’échec de l’action de configuration
ConfigurationFailure pour la fonctionnalité SQL_Engine_Core_Inst lors du minutage ConfigNonRC et du
scénario ConfigNonRC. System.Collections.Generic.KeyNotFoundException : la clé donnée n’était pas
présente dans le dictionnaire. at System.ThrowHelper.ThrowKeyNotFoundException() at
System.Collections.Generic.Dictionary
2.get_Item(TKey key) at
Microsoft.SqlServer.Configuration.ClusterConfiguration.FailoverClusterNamePrivateConfigObject.CreateFailoverClusterNameResource(FailoverClusterNamePubli
pubConfig) at Microsoft.SqlServer.Configuration.ClusterConfiguration.FailoverClusterNamePrivateConfigObject.Install(ConfigActionTiming timing, Dictionar
2 actionData, PublicConfigurationBase spcb) at
Microsoft.SqlServer.Configuration.SqlConfigBase.PrivateConfigurationBase.Execute(ConfigActionScenario
scenario, ConfigActionTiming timing, Action ConfigBaseAction, Dictionary
2 actionData, PublicConfigurationBase spcbCurrent) at
Microsoft.SqlServer.Configuration.SqlConfigBase.SqlFeatureConfigBase.Execute(ConfigActionScenario
scenario, ConfigActionTiming timing, ConfigBaseAction action, Dictionary
Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.ExecuteAction(String actionId) at
Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.Execute(String actionId, TextWriter
errorStream) The following is an exception stack listing the exceptions in outermost to innermost inner
order Inner exceptions are being indented Exception type:
System.Collections.Generic.KeyNotFoundException Message: The given key was not present in the
dictionary. HResult : 0x80131577 données : SQL. Setup.FailureCategory = ConfigurationFailure
WatsonConfigActionData = INSTALL@CONFIGNONRC @SQL_ENGINE_CORE_INST
WatsonExceptionFeatureIdsActionData = System.String[] Stack: at
System.ThrowHelper.ThrowKeyNotFoundException() at System.Collections.Generic.Dictionary
2.get_Item(TKey key) at
Microsoft.SqlServer.Configuration.ClusterConfiguration.FailoverClusterNamePrivateConfigObject.CreateFailoverClusterNameResource(FailoverClusterNamePubli
pubConfig) at Microsoft.SqlServer.Configuration.ClusterConfiguration.FailoverClusterNamePrivateConfigObject.Install(ConfigActionTiming timing, Dictionar
2 actionData, PublicConfigurationBase spcb) at
Microsoft.SqlServer.Configuration.SqlConfigBase.SqlFeatureConfigBase.Execute(ConfigActionScenario
Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.ExecuteAction(String actionId) at
errorStream)
Cause
Un nouveau commutateur, ManagementPointNetworkType , qui peut être appelé par les cmdlets PowerShell
pour FailoverClusters est introduit dans Windows Server 2019. Vous pouvez utiliser les options suivantes pour
le nouveau commutateur.
PA RA M ÈT RE SW ITC H UT IL ISAT IO N
Singleton Utilise la méthode traditionnelle d’adresse IP statique ou

DHCP.
Distribué Utilisez un nom de réseau distribué à l’aide d’adresses IP de

nœud.
Automatique Utilise la détection pour déterminer le paramètre approprié.

Si SQL Server est en cours d’exécution dans Azure, utilise
Distributed . Si SQL Server est en cours d’exécution en local,
utilise Singleton (paramètre par défaut).
Si vous créez le cluster Windows à l’aide de l’outil Windows Cluster Manager, l’outil définit le paramètre de
commutateur sur Automatique . Étant donné que vous travaillez sur une VM Azure, le commutateur utilise
plutôt un nom de réseau distribué.
Vous pouvez le vérifier en exécutant la commande PowerShell suivante :
C:\windows\system32> Get-clusterresource
La sortie renvoyée par cette commande ressemble à ceci :
Name State OwnerGroup ResourceType

Cloud Witness Online Cluster Group Cloud Witness
Cluster Name Online Cluster Group Distributed Network Name
Cluster Pool 1 Online 45d8f3c2-e8df-4a01-87b8-f3c383801f3f
Storage Pool
Cluster Virtual Disk
(ClusterPerformanceHistory) Online Cluster Group Physical Disk
Health Online Cluster Group Health Service
SDDC Management Online Cluster Group SDDC Management
Storage QoS Resource Online Cluster Group Storage QoS Policy Manager
La CreateFailoverClusterNameResource(FailoverClusterNamePublicConfigObject pubConfig) fonction vérifie le nom

de la ressource dont le type estNetworkName. Cela consiste à vérifier que le nom du serveur virtuel que vous
avez entré existe déjà.
Toutefois, l’installation SQL Server FCI sur un cluster Windows qui ne possède qu’un nom de réseau distribué
n’est pas prise en charge. Le message d’erreur mentionné dans la section Symptômes indique qu’il n’existe
aucune ressource disponible dans Windows Server 2019 dont le type estNetworkName.
Résolution
Pour résoudre ce problème, vous pouvez supprimer le cluster actuel, puis le créer à nouveau à l’aide d’une
commande PowerShell qui a le paramètre suivant :
managementpointnetworktype singleton
SQL Server 2012 DQS Export to 64-bit .xls Excel file
fails with error
Cet article vous aide à résoudre le problème où le téléchargement de fichier a échoué, vérifiez que le fichier de
destination d’exportation n’existe pas déjà une erreur se produit.
S’applique à : SQL Server 2012 Business Intelligence, SQL Server 2012 Developer, SQL Server 2012 Enterprise
Symptômes
Lorsque vous utilisez SQL Server Services de qualité des données 2012, sur un ordinateur sur lequel Microsoft
Excel 64 bits est installé, envisagez le scénario suivant :
Vous utilisez Data Quality Client pour exécuter un projet nettoyage ou mise en correspondance des
données.
Vous devez effectuer les étapes nécessaires pour accéder à la page d’exportation finale du projet de
qualité des données.
Vous tentez d’exporter des résultats nettoyés, vers le fichier de Excel de destination.
Cliquez sur le bouton Parcourir pour spécifier un fichier Excel existant vers le fichier à exporter.
Vous spécifiez le type de fichier d’exportation et pointez vers Excel 97-2003 Workbook (*.xls) un
fichier avec l’extension .xls exporter.
Cliquez sur le bouton Ouvrir pour choisir le fichier de destination.
Cliquez sur le bouton Expor ter pour exécuter l’action d’exportation.
Une erreur s’affiche :
Échec du téléchargement du fichier, vérifiez que le fichier de destination d’exportation n’existe pas déjà.
Cause
Dans ce scénario, l’exportation vers Excel type de fichier 2003-2007 *.xls échoue, ce qui est un bogue.
DQS doit être en mesure d’exporter vers *.xls lorsque Microsoft Excel 64 bits est installé sans erreur.
Résolution
Informations sur le Service Pack SQL Server 2012
Pour résoudre ce problème, obtenez le dernier Service Pack pour SQL Server 2012. Pour plus d’informations,
voir KB2755533 -Comment obtenir le dernier Service Pack pour SQL Server 2012 .
Vous pouvez désormais parcourir et spécifier le fichier d’exportation qui possède l’extension *.xls et exécuter
l’action Exporter sans l’erreur, lorsque Excel 64 bits est installé sur l’ordinateur.
Lorsque vous utilisez Microsoft Excel 2007 ou 2010 64 bits sur l’ordinateur sur lequel Data Quality Client est
installé, vous pouvez exporter uniquement vers le format de fichier *Excel 2003-2007 *.xls à compatibilité avec
les rétrogradations, ou choisir un autre type de destination tel que SQL Server ou CSV (fichier texte délimité par
des virgules).
Il est attendu que SQL Server 2012 Data Quality Client ne puisse pas exporter des projets de données vers le
nouveau format de fichier *.xlsx lorsque la version Microsoft Excel installée est 64 bits. Ce comportement est
voulu par la conception même du produit.
Lorsque vous utilisez Microsoft Excel 2007 ou 2010 32 bits sur l’ordinateur sur lequel Data Quality Client est
installé, vous pouvez exporter vers.xlsx*.xls ou choisir un autre type de destination tel que SQL Server ou * CSV.
Données d’analyse à l’aide de connaissances DQS (internes)
Exécuter une Project
Pour afficher la version de Excel et détecter s’il s’agit d’une version 64 bits ou 32 bits.
Dans Excel 2007
Cliquez sur le bouton Office forme circulaire dans le coin supérieur gauche. Choisissez le bouton
Options, affichez la page références. Afficher la section à propos de.
Dans Excel 2010
Cliquez sur l’onglet Fichier sur le ruban, cliquez sur la page d’aide et notez la version dans le volet droit
sous l’en-tête À propos Microsoft Excel.
Le numéro de version et l’architecture seront répertoriés, par exemple (32 bits) ou (64 bits).
SQL Server 2012 DQSInstaller.exe'accès au dossier
TMP peut échouer
Cet article vous aide à résoudre le problème où le chemin d’accès du dossier temporaire contient un caractère
ANSI accentué ou spécial.
S’applique à : SQL Server 2012 Business Intelligence, SQL Server 2012 Developer, SQL Server 2012 Enterprise
Symptômes
Le programme d SQL Server du programme d’installation des services de qualité des données 2012
DQSInstaller.exe peut échouer sur les ordinateurs dont le chemin d’accès au dossier temporaire contient un
caractère ANSI accentué ou spécial.
Par exemple, pour Windows utilisateurs avec des caractères accentués dans le nom d’utilisateur, le dossier
temporaire peut contenir des caractères é accentués, tels que C:\Users\Us é rNam é\AppData\Local\Temp\ .
Vous pouvez noter les erreurs suivantes sur la console lors de l’exécution de DQSInstaller.exe, ou dans le journal
de sortie DQSInstaller.exe (l’emplacement par défaut est ) CREATE ASSEMBLY a échoué, car il n’a pas pu ouvrir le
fichier physique Enregistrer les assemblys
C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\Log\DQS_install.log Microsoft.Practices :
Msg 6501, Level 16, State 7, Server DOMAIN\SERVERNAME, Line 2

CREATE ASSEMBLY a échoué car il n’a pas pu ouvrir le fichier physique « C:\Users <username>
\AppData\Local\Temp\Microsoft.Practices.ObjectBuilder2.dll » : 3(Le système ne peut pas trouver le chemin
d’accès <random folder> spécifié.)
ERREUR - Une erreur s’est produite, le message de vérification ci-dessus le processus de script a renvoyé un
code de sortie inattendu : '1'.
Action « Enregistrer les assemblys de qualité des données et les procédures stockées » terminée par des
erreurs, abandon de l’installation.
Démarrage de la rollback d’installation...
La mise à l’installation a été correctement effectuée.
Le programme d’installation DQS a terminé avec des erreurs. Consultez le fichier journal d’installation à
l’Microsoft SQL Server\MSSQL11. InstanceName\MSSQL\Log\DQS_install.log
Appuyez sur n’importe quelle touche pour continuer...
Cause
Le dossier temporaire utilisé par DQSInstaller.exe est spécifié par la variable d’environnement TMP.
DQSInstaller extrait les fichiers d’assembly et les scripts dans un dossier temporaire avec un nom aléatoire sous
le dossier temporaire. Si ce chemin d’accès temporaire contient des caractères spéciaux, DQSInstaller n’exécute
pas correctement les caractères accentués ou spéciaux lors de l’exécution de scripts et d’assemblys.
Résolution
Le moyen le plus simple de résoudre le problème consiste à lancer l’invite de commandes en tant
qu’administrateur (l’élever si le contrôle UAC est activé), à remplacer temporairement l’emplacement TMP par
une variable TMP locale, puis à exécuter le DQSInstaller.exe.
Dans cet exemple de syntaxe d’invite de commandes, nous allons créer un répertoire (md) c:\temp, puis définir
la variable TMP sur cet emplacement, puis modifier le répertoire dans le dossier où DQSInstaller.exe est présent,
puis exécuter le DQSInstaller.exe (sans commutateurs supplémentaires).
md c:\temp
SET tmp=c:\temp
cd "c:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLServer\MSSQL\Binn\"
DQSInstaller.exe
Pour visiter le dossier TMP dans l’Explorateur Windows, vous pouvez ouvrir l’espace réservé %tmp% :
Démarrer >'> %tmp%
Pour tester la variable d’environnement TMP actuelle, vous pouvez utiliser la syntaxe SET à partir de l’invite de
commandes ou la syntaxe d’écho :
SET TMP
echo %tmp%
Pour modifier définitivement les variables d’environnement TMP et TEMP, voir Comment déplacer les répertoires
TEMP et TMP.
Erreur (échec de la phase de pré-exécution du
nettoyage DQS) lors de l’exécution de la
transformation nettoyage DQS SQL Server 2012
Cet article vous aide à contourner le problème où une erreur est consignée dans le journal SSIS SQL Server
2012.
S’applique à : SQL Server 2012 Developer, SQL Server 2012 Enterprise, SQL Server 2012 Standard
Symptômes
Vous utilisez la transformation nettoyage des services de qualité des données (DQS) dans une Flow de
données du service SQL Server-Integrated (SSIS) pour s’en servir dans Microsoft SQL Server 2012.
Vous définissez le paramètre « Configurer la sortie d’erreur » de la transformation nettoyage DQS sur « Ligne
de redirection ». Toutefois, vous ne spécifiez pas d’emplacement pour enregistrer la sortie d’erreur.
Vous exécutez le package SSIS.
Dans ce scénario, le message d’erreur suivant est consigné dans le journal SSIS :
Le nettoyage DQS a échoué à la phase de pré-exécution et le code d’erreur renvoyé 0x80070057.

System.ArgumentException : la valeur ne se trouve pas dans la plage attendue.
at Microsoft.SqlServer.Dts.pipeline.Wrapper.IDTSBufferManager100.FindColumnByLineageID(Int32
hBufferType, Int32 nLineageID)
at Microsoft.Ssdqs.Component.DataCorrection.Logic.DataCorrectionComponent.PreExecute() at
Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostPreExecute(IDTSManagedComponentWrapp
er100 wrapper)
Cause
Ce problème se produit parce qu’une destination n’est pas définie pour la sortie d’erreur générée pour les lignes
qui ne répondent pas aux critères et règles de domaine DQS.
Pour résoudre ce problème, utilisez l’une des méthodes suivantes.
Méthode 1
Si vous ne souhaitez pas rediriger les lignes d’erreur, suivez les étapes suivantes pour résoudre le
problème :
1. Ouvrez le composant DQS dans l’Éditeur de transformation de nettoyage DQS.
2. Sélectionnez Composant d’échec dans la liste de listes de listes de sortie d’erreur Configurer en bas de
l’Éditeur de transformation de nettoyage DQS.
Méthode 2
Si vous devez rediriger vos lignes d’erreur, vous devez vous assurer que vous avez un emplacement de
destination pour les erreurs à rediriger.
SQL Server de démarrage sur un serveur autonome
Il existe plusieurs raisons pour lesquelles SQL Server service peut ne pas démarrer. À un niveau élevé, les causes
peuvent être classées dans les catégories suivantes :
Problèmes qui affectent le compte configuré pour exécuter le service SQL Server service
Bases de données système inaccessibles
Dépendances manquantes
Configuration incorrecte du service SQL Server service
Problèmes affectant la configuration du certificat
Cette rubrique vous aide à résoudre les problèmes les plus SQL Server de démarrage dans ces catégories sur un
serveur autonome.
S’applique à : SQL Server
Résumé
SQL Server pouvez pas démarrer et vous recevez un message d’erreur lorsque vous utilisez l’un des outils
suivants pour démarrer le service SQL Server service :
Gestionnaire de configuration SQL Server
SQL Server Management Studio
Windows Gestionnaire de contrôle de service
Windows invite de commandes
NOTE
Le message d’erreur peut varier légèrement en fonction de l’outil que vous utilisez. Toutefois, en général, les ID
d’événement, les numéros d’erreur et les descriptions sont très similaires.
Étapes pour résoudre ces problèmes

1. Notez le message d’erreur que vous recevez de l’outil lorsque vous démarrez le service.
2. Notez l’ID d’événement correspondant et sa description associée qui est consignée dans les journaux
système et Windows application.
3. Utilisez le tableau suivant pour rechercher la rubrique correspondante qui contient des informations de
dépannage supplémentaires sur l’erreur, l’ID d’événement et la description.
NOTE
Tous ces dépannages utilisent le Gestionnaire de contrôle de service pour identifier l’erreur de démarrage et utilisent
Gestionnaire de configuration SQL Server pour fournir une résolution.
En règle générale, vous devez être administrateur sur l’ordinateur SQL Server résoudre les problèmes.
SQL Server messages d’erreur de démarrage

M ESSA GE D’ERREUR P RO VEN A N T DE SERVIC ES A P P L ET RÉVISIO N
Le service ou le groupe de dépendances n’a pas réussi à Le service SQL Server et le service d’agent SQL Server ne
démarrer. parviennent pas à démarrer sur un serveur autonome
Windows n’a pas pu démarrer SQL Server service Échec de l’SQL Server de l’SQL Server ne démarre pas
(MSSQLSERVER) sur l’ordinateur local. correctement
Erreur 1069 : le service n’a pas commencé en raison d’un
échec d’accès.
Windows n’a pas pu démarrer SQL Server (MSSQLSERVER) SQL Server ne peut pas démarrer si tous les protocoles sont
sur l’ordinateur local. Pour plus d’informations, examinez le désactivés
journal des événements système.
S’il s’agit d’un service autre que Microsoft, contactez le
fournisseur du service et reportez-vous au code d’erreur
spécifique au service 13.
Windows n’a pas pu démarrer SQL Server service L’ID d’événement 17058 et SQL Server ne démarre pas
(MSSQLSERVER) sur l’ordinateur local.
Erreur 1067 : Le processus s’est terminé de manière
inattendue.
Windows n’a pas pu démarrer SQL Server service L’ID d’événement 7000 et SQL Server ne démarre pas
Erreur 2 : le système ne peut pas trouver le fichier spécifié.
Windows n’a pas pu démarrer SQL Server (MSSQLSERVER) Erreur spécifique au service 17113 lorsque vous démarrez
sur l’ordinateur local. Pour plus d’informations, examinez le SQL Server service
spécifique au service 17113
Windows n’a pas pu démarrer SQL Server (MSSQLSERVER) L’ID d’événement 1814 et SQL Server ne démarre pas
sur l’ordinateur local. Pour plus d’informations, examinez le
sur l’ordinateur local. Pour plus d’informations, examinez le après l’activer
propre au service 2146885628.
sur l’ordinateur local. Pour plus d’informations, examinez le après l’activer
Windows n’a pas pu démarrer SQL Server service Erreur « Accès refusé » et SQL Server ne démarre pas
Erreur 5 : l’accès est refusé.
Référence
SQL Server service ne peut pas démarrer après avoir configuré une instance pour utiliser un certificat Secure
Sockets Layer
Erreur « Accès refusé » et SQL Server ne démarre
pas
Symptômes
Lorsque vous configurez le service Microsoft SQL Server pour qu’il s’exécute sous un compte qui ne contient
pas suffisamment de privilèges sur le dossier d’installation de SQL Server, SQL Server ne démarre pas et
renvoie un message d’erreur semblable à ce qui suit, en fonction de la façon dont vous essayez de démarrer le
service :
À l’aide de l’applet services :
Windows n’a pas pu démarrer SQL Server service (MSSQLSERVER) sur l’ordinateur local.
Erreur 5 : l’accès est refusé.
À l’aide d’une invite de commandes :
C:\Users\username>NET START MSSQLSERVER

L’erreur système 5 s’est produite.
L’accès est refusé.
Résolution
1. Ouvrez le journal système et vérifiez que vous voyez une entrée de message d’erreur semblable à ce qui
suit :
Log Name: System

Source: Service Control Manager
Date: <Datetime>
Event ID: 7000
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <Server name>
Description:
The SQL Server (MSSQLSERVER) service failed to start due to the following error:
Access is denied.
2. À l’Microsoft SQL Server Configuration Manager ou service Control Manager, notez le compte de service
pour SQL Server service.
3. Accédez au dossier SQL Server d’installation (par exemple) et faites les choses suivantes pour vérifier
l’accès effectif C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Binn au compte SQL
service :
a. Cliquez avec le bouton droit sur le fichier ou le dossier, sélectionnez Propriétés, puis sélectionnez
l’onglet Sécurité.
b. Sélectionnez Avancé, sélectionnez l’onglet Accès effectif, puis sélectionnez Un utilisateur à taper dans
le compte SQL Service ou sélectionnez-le dans la liste.
c. Sélectionnez Afficher un accès efficace pour comprendre et résoudre le problème d’autorisations.
Par exemple, si l’autorisation Refuser est ajoutée à l’utilisateur ou au groupe dont le compte de service
SQL Server est membre, supprimez l’autorisation Refuser et redémarrez le service SQL Server.
NOTE
Vous pouvez également utiliser l’outil Process Monitor pour identifier et isoler les problèmes d’autorisation. La
capture d’écran suivante d’un exemple de sortie du moniteur de processus montre le compte de service
\sqlsrvlogin SQL Server générant une erreur <DomainName> d’accès refusé.
Référence
Autorisations de service
Erreur spécifique au service 17113 lorsque vous
démarrez SQL Server service
Symptômes
Dans Microsoft SQL Server, la base de données maître enregistre toutes les informations au niveau du système.
La base de données maître enregistre également l’existence de toutes les autres bases de données,
l’emplacement de ces fichiers de base de données et les informations d’initialisation de SQL Server. Par
conséquent, SQL Server ne peut pas démarrer si la base de données maître n’est pas disponible.
Lorsque vous essayez de démarrer SQL Server dans ce scénario, le service SQL Server ne démarre pas et vous
recevez le message d’erreur suivant, en fonction de la façon dont vous essayez de démarrer le service :
Windows n’a pas pu démarrer SQL Server (MSSQLSERVER) sur l’ordinateur local. Pour plus
d’informations, examinez le journal des événements système. S’il s’agit d’un service autre que
Microsoft, contactez le fournisseur du service et reportez-vous au code d’erreur spécifique au service
17113.
C : \>NET START MSSQLSERVER

Le SQL Server service (MSSQLSERVER) démarre.
Le service SQL Server (MSSQLSERVER) n’a pas pu être démarré.
Une erreur spécifique au service s’est produite : 17113.
Une aide plus utile est disponible en tapant NET HELPMSG 3547.
Résolution
1. Vérifiez SQL Server journal des erreurs et vérifiez que la cause est l’inaccessibilité de la base de données
maître. Par exemple, vous pouvez voir une entrée de journal qui ressemble à ce qui suit :
<Datetime> Server Error: 17113, Severity: 16, State: 1.

<Datetime> Server Error 2(The system cannot find the file specified.) occurred while opening
file
'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\master.mdf' to obtain configuration information at startup.
An invalid startup option might have caused the error. Verify your startup
options, and correct or remove them if necessary.
2. Vérifiez l’emplacement du fichier master.mdf. Si le chemin d’accès est incorrect, corrigez-le à l’aide
Gestionnaire de configuration SQL Server’Éditeur du Registre.
a. À l’aide Gestionnaire de configuration SQL Ser ver :
Sélectionnez Démarrer, pointez sur Tous les programmes, pointez sur Microsoft SQL Ser ver,
pointez sur Outils de configuration, puis sélectionnez Gestionnaire de configuration SQL
Ser ver .
NOTE
Comme Gestionnaire de configuration SQL Server est un logiciel en snap-in pour le programme Microsoft
Management Console et non un programme autonome, Gestionnaire de configuration SQL Server
n’apparaît pas en tant qu’application dans les nouvelles versions de Windows. Pour ouvrir Gestionnaire de
configuration SQL Server dans Windows 10 ou 8, suivez les étapes de votre version de Windows.
Windows 10 :
a. Sélectionnez Page de démarrage, entrez SQLServerManager13.msc (pour SQL Server
2016 (13.x)). Pour les versions précédentes SQL Server, remplacez 13 par le nombre
approprié.
b. Sélectionnez SQLSer verManager13.msc pour ouvrir Configuration Manager. Pour
épingler le Gestionnaire de configuration à la page de démarrage ou à la barre des
tâches, cliquez avec le bouton droit sur SQLSer verManager13.msc, puis sélectionnez
Ouvrir l’emplacement du fichier.
c. Dans la Windows’Explorateur de fichiers, cliquez avec le bouton droit sur
SQLSer verManager13.msc, puis sélectionnez Épingler à l’démarrer ou épingler à la
barre des tâches.
Windows 8 :
Appuyez Windows touche de logo +Q pour ouvrir l’icône Rechercher. Sous Applications,
entrez SQLServerManager <version_number> .msc (par exemple,
SQLServerManager13.msc), puis appuyez sur Entrée.
a. Dans Gestionnaire de configuration SQL Server, sélectionnez SQL Ser ver Ser vices.
b. Dans le volet droit, cliquez avec le bouton droit sur SQL Ser ver ( <instance_name> ),
puis sélectionnez Propriétés.
c. Sous l’onglet Paramètres de démarrage, sélectionnez la ligne qui commence par -d dans
la section Paramètres existants. La valeur actuelle est modifiable. Spécifiez une zone de
paramètre de démarrage. Corrigez le chemin d’accès pour refléter la valeur correcte,
sélectionnez Mettre à jour, puis sélectionnez OK pour enregistrer les modifications.
d. Redémarrez le service SQL Server service.
Pour plus d’informations sur la configuration des options de démarrage, voir Configure
Server Startup Options (Gestionnaire de configuration SQL Server).
Pour plus d’informations sur les options de démarrage du service de moteur de base de
données, voir Moteur de base de données Options de démarrage du service.
b. À l’aide de l’Éditeur du Registre :
a. Accédez à la HKLM\Software\Microsoft\MicrosoftSQL Server\MSSQL{nn}.MyInstance ruche pour
votre instance SQL serveur.
b. Recherchez la valeur SQL Arg0 sous MSSQLServer\Parameters .
c. Modifiez la valeur pour refléter le chemin d’accès correct de la base de données maître.
d. Redémarrez le SQL Server service.
3. Si la base de données maître existe mais qu’elle est inutilisable, vous pouvez la renvoyer à un état
utilisable à l’aide de l’une des méthodes suivantes :
Vérifiez les autorisations du compte de service sur le dossier où se trouve le fichier.
Restituer la base de données maître à partir d’une sauvegarde de base de données complète si
vous pouvez démarrer l’instance du serveur.
Si les dommages du serveur sur la base de données principale vous empêchent de démarrer SQL
Server, ré reconstruire la base de données maître.
Cau t i on
La reconstruction de la base de données principale ré reconstruit toutes les bases de données

système. Par conséquent, toutes les modifications apportées par l’utilisateur à ces bases de
données seront perdues.
SQL Server ne peut pas démarrer si tous les
protocoles sont désactivés
Symptômes
Si tous les protocoles réseau d’une instance Microsoft SQL Server sont désactivés, SQL Server ne démarre pas
et vous recevez le message d’erreur suivant, en fonction de la façon dont vous essayez de démarrer le service :
Windows n’a pas pu démarrer SQL Server (MSSQLSERVER) sur l’ordinateur local. Pour plus
d’informations, examinez le journal des événements système.
S’il s’agit d’un service autre que Microsoft, contactez le fournisseur du service et reportez-vous au
code d’erreur spécifique au service 13.
C:\Users\username>NET START MSSQLSERVER

Une erreur spécifique au service s’est produite : 13. Une aide plus utile est disponible en tapant NET
HELPMSG 3547.
Résolution
Voici comment résoudre ce problème :
1. Vérifiez le journal des événements système et vérifiez que vous voyez l’entrée d’événement suivante :
Event ID: 7024

The SQL Server (MSSQLSERVER) service terminated with the following service-specific error:
The data is invalid.
2. Consultez le SQL Server des erreurs et vérifiez que vous voyez des entrées de message d’erreur
semblables à ce qui suit :
<Datetime> spid9s Server name is '<ServerName>'. This is an informational message only. No user
action is required.
<Datetime> spid17s Error: 17182, Severity: 16, State: 1.
<Datetime> spid17s TDSSNIClient initialization failed with error 0xd, status code 0x4. Reason:
**All protocols are disabled. The data is invalid**.
<Datetime> spid17s TDSSNIClient initialization failed with error 0xd, status code 0x1. Reason:
Initialization failed with an infrastructure error. Check for previous errors. The data is invalid.
.
.
<Datetime> spid17s Could not start the network library because of an internal error in the
network library. To determine the cause, review the errors immediately preceding this one in the
error log.
<Datetime> spid17s SQL Server could not spawn FRunCommunicationsManager thread. Check the SQL
Server error log and the operating system error log for information about possible related problems.
3. Après avoir vérifié le problème mentionné dans la section Symptômes, utilisez le nœud configuration
réseau SQL Server de Gestionnaire de configuration SQL Server pour activer les protocoles réseau
requis. Ensuite, redémarrez le service SQL Server service.
NOTE
Si vous ne souhaitez pas activer les connexions distantes à votre instance SQL Server, vous pouvez activer
uniquement le protocole Mémoire partagée, puis redémarrer le service SQL Server.
Vous pouvez également valider les paramètres de la bibliothèque réseau à l’aide des clés de Registre
suivantes
Si la Enabled valeur est définie sur zéro, la bibliothèque réseau correspondante est désactivée.
Mémoire partagée :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\Sm\Enabled
TCP/IP :
Server\MSSQL15.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\Tcp\Enabled
Canaux nommés :
Server\MSSQL15.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\Np\Enabled
Le service SQL Server et le service d’agent SQL
Server ne parviennent pas à démarrer sur un
serveur autonome
Cet article vous aide à résoudre les problèmes où le service SQL Server et le service d’agent SQL Server
peuvent ne pas démarrer sur un serveur autonome.
Symptômes
Problème 1 : sur un serveur autonome, le démarrage du service MSSQLSERVER peut échouer et vous
recevez le message d’erreur suivant :
Une erreur 1068 (le service ou le groupe de dépendances n’a pas réussi à démarrer)) s’est produite
lors de l’opération de service sur le service MSSQLServer.
Problème 2 : de même, le service SQLServerAgent peut également ne pas démarrer et vous recevez le
message d’erreur suivant :
Une erreur 1068 (le service ou le groupe de dépendances n’a pas réussi à démarrer)) s’est produite
lors de l’opération de service sur le service SQLServerAgent.
Les problèmes 1 et 2 se produisent lorsque les deux conditions suivantes sont vraies :
L’ordinateur serveur se trouve dans un groupe de travail et ne fait pas partie d’un domaine.
Les services MSSQLSERVER et SQLServerAgent sont tous deux définies pour utiliser un compte de
domaine pour le démarrage.
Problème 3 : sur un serveur membre du domaine, le service MSSQLSERVER peut ne pas démarrer au
démarrage du serveur et vous recevez le message d’erreur suivant :
Le service MSSQLSERVER n’a pas pu se connecter en tant que domaine\mssqlsvc avec le mot de
passe actuellement configuré en raison de l’erreur suivante : Source : NetLogon Description : Il n’existe
actuellement aucun serveur de connexion disponible pour le service de demande de connexion. Le
service MSSQLSERVER s’est terminé de manière inattendue.
Ce problème se produit lorsque toutes les conditions suivantes sont vraies :

Le serveur fait partie d’un domaine.
Les services MSSQLSERVER et SQLServerAgent sont tous deux définies pour utiliser un compte de domaine
pour le démarrage.
Le mode de démarrage pour MSSQLSERVER et SQLServerAgent est automatique.
Cause
Le problème 1 et le problème 2 se produisent parce que le serveur est un ordinateur autonome, que le service
NetLogon ne démarre pas sur le serveur, de ce fait, aucune authentification d’authentification à l’échelle du
domaine n’est possible.
Le problème 3 se produit car SQL Server services tentent de démarrer avant le démarrage du service NetLogon.
Résolution
Pour résoudre les problèmes 1 et 2, suivez les étapes suivantes :
Modifiez le compte de démarrage de MSSQLSERVER et de SQLServerAgent pour utiliser le compte
système local.
Redémarrez le serveur.
Pour résoudre le problème 3, utilisez les solutions de contournement suivantes :
Configurez le démarrage SQL Server sur un démarrage différé pour des serveurs Windows particuliers,
d’autres services Windows tels que NetLogon s’achèvent en premier et SQL Server démarre sans
problème.
Configurez le démarrage SQL Server pour qu’il réessaye, le démarrage peut être terminé lors de la
deuxième tentative de démarrage.
Modifiez la valeur de détection d’adresses en double (-Transmits) sur 1 pour toutes les interfaces réseau
sur le serveur. Pour plus d’informations, voir la commande Set-NetIPInterface.
Modifiez les options de récupération pour SQL Server et SQL Server services d’agent. Spécifiez
redémarrer le ser vice en tant qu’action pour les options de défaillance. Vous pouvez effectuer cette
option à partir de l’applet services des outils d’administration à l’aide des interfaces familières du
Gestionnaire de contrôle de service.
Si l’option de démarrage différé ne peut pas résoudre ce problème 3, vous pouvez ajouter les dépendances
suivantes au service SQL Server service :
Service d’aide Ip
Service serveur
Service de liste réseau
Vous pouvez ajouter les dépendances à l’aide de la commande suivante :
sc.exe qc MSSQLSERVER ::view dependencies sc.exe config MSSQLSERVER depend=iphlpsvc/LanmanServer/netprofm

::add service dependencies
Sur un ordinateur autonome, le service NetLogon doit être définie pour le démarrage manuel.
Échec de l’SQL Server de l’SQL Server ne démarre
pas
Ce problème se produit en raison d’un problème avec le compte de service lui-même ou les informations
actuellement enregistrées pour le compte de service.
Symptômes
Lorsque vous essayez de redémarrer Microsoft SQL Server ou l’agent SQL Server, le service ne démarre pas et
vous recevez le message d’erreur suivant, en fonction de la façon dont vous essayez de démarrer le service :
Erreur 1069 : le service n’a pas commencé en raison d’un échec d’accès.

Le service n’a pas commencé en raison d’une défaillance de l’accès.
Conditions préalables
Pour utiliser cet dépannage, ouvrez le journal des événements système et notez l’ID d’événement et la
description de l’événement associé à l’échec. Ensuite, utilisez les informations suivantes pour résoudre le
problème.
ID d’événement : 7041, échec de l’accès : l’utilisateur n’a pas reçu le

type d’accès demandé sur cet ordinateur
L’entrée de message complète dans le journal des événements doit ressembler à ce qui suit :
Log Name: System
Date: <Datetime>
Event ID: 7041
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Description:
The MSSQLSERVER service was unable to log on as NT Service\MSSQLSERVER with the currently configured
password due to the following error:
Logon failure: the user has not been granted the requested logon type at this computer.
Service: MSSQLSERVER
Domain and account: <Account name>
This service account does not have the required user right "Log on as a service."
User Action
Assign "Log on as a service" to the service account on this computer. You can use Local Security Settings
(Secpol.msc) to do this.
If this computer is a node in a cluster, check that this user right is assigned to the Cluster service
account on all nodes in the cluster.
If you have already assigned this user right to the service account, and the user right appears to be
removed,
check with your domain administrator to find out if a Group Policy object associated with this node might
be removing the right.
Action de l’utilisateur
Vérifiez les autorisations attribuées au compte de service à l’aide de l’Paramètres de sécurité <Account Name>
locale (Secpol.msc).
1. Vérifiez ces droits selon les autorisations du serveur. Pour plus d’informations, voir Windows droits et
privilèges. Attribuez manuellement les autorisations manquantes.
2. Examinez le compte de service pour savoir s’il a reçu des autorisations Deny*. Supprimez les
autorisations Deny* du compte SQL service service, puis testez à nouveau. Par exemple, si le compte de
service a été affecté à l’insaisissable « Deny Service Logon » avec , révoquez le droit
SeDenyServiceLogonRight d’SQL Server. SeServiceLogonRight SeDenyServiceLogonRight
ID d’événement : 7038, cet utilisateur ne peut pas se connecter car ce

compte est actuellement désactivé
Log Name: System
Date: <Datetime>
Event ID: 7038
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Description:
The MSSQLSERVER service was unable to log on as .\sqlsrvlogin with the currently configured password due to
the following error:
This user can't sign in because this account is currently disabled.
To ensure that the service is configured properly, use the Services snap-in in Microsoft Management Console
(MMC).
1. Si SQL Server compte de démarrage est un compte d’utilisateur local sur l’ordinateur, ouvrez Gestion de
l’ordinateur (compmgmt.msc) et vérifiez que le compte de service est désactivé dans Groupes
d’utilisateurs & locaux. S’il est désactivé, activez le compte et redémarrez le service SQL Server service.
2. Si SQL Server de démarrage est un compte Windows domaine, vérifiez si le compte est désactivé dans
Utilisateurs et ordinateurs Active Directory. S’il est désactivé, activez le compte et redémarrez le service
SQL Server service.
ID d’événement : 7038, le mot de passe de l’utilisateur doit être

modifié avant la signature
Log Name: System

Date: <Datetime>
Event ID: 7038
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Description:
The user's password must be changed before signing in.
(MMC).
1. Si le compte de démarrage SQL Server est un compte d’utilisateur local sur l’ordinateur, ouvrez Gestion
de l’ordinateur (compmgmt.msc) et clear the User Must change the password at next logon
property for SQL Server Startup Account under Local Users & Groups . Ensuite, sélectionnez OK, puis
redémarrez le service SQL Server service.
2. Si le compte de démarrage SQL Server est un compte de domaine Windows, ouvrez Utilisateurs et
ordinateurs Active Directory, puis vérifiez que l’utilisateur doit modifier le mot de passe sur le compte de
démarrage SQL Server à la prochaine propriété d’ouverture de site activée.
3. Si la propriété de l’étape 2 est activée, vous devez effacer cette option ou vous connecter de manière
interactive à un client Windows, puis définir un nouveau mot de passe, puis mettre à jour le nouveau mot
de passe pour le service SQL Server à l’aide de l’outil Gestionnaire de configuration SQL Server.
ID d’événement : 7038, le nom d’utilisateur ou le mot de passe est

incorrect
Log Name: System

Date: <Datetime>
Event ID: 7038
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Description:
The user name or password is incorrect.
(MMC).
1. L’entrée du message d’erreur indique que le nom de connexion actuel ou le jeu de mots de passe est
incorrect. Pour vérifier la même chose, vous pouvez utiliser l’option Run-As Windows pour ouvrir une
fenêtre Windows invite de commandes, puis fournir les mêmes informations d’identification. Si cela
fonctionne sans problème, tapez soigneusement les informations d’identification dans Gestionnaire de
configuration SQL Server.
2. Si l’étape 1 échoue et signale le même problème, vous devez réinitialiser le mot de passe de la
Windows’utilisateur. Si le compte SQL Server démarrage est un compte d’utilisateur local sur l’ordinateur,
ouvrez Gestion de l’ordinateur (compmgmt.msc) et réinitialisez le mot de passe de l’utilisateur local. Si le
compte SQL Server de démarrage est un compte Windows domaine, ouvrez Utilisateurs et ordinateurs
Active Directory, puis modifiez les informations d’identification. Une fois les informations d’identification
mises à jour, revenir à Gestionnaire de configuration SQL Server, entrez les mêmes informations
d’identification, puis démarrez le service.
Tapez le mot de passe correct dans le compte SQL Server service sur l’ordinateur SQL Server hôte. Pour ce faire,
suivez les procédures de SCM Services - Modifierle mot de passe des comptes utilisés.
ID d’événement : 7038, le compte référencé est actuellement

verrouillé et peut ne pas être connecté
Log Name: System
Date: <Datetime>
Event ID: 7038
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Description:
The referenced account is currently locked out and may not be logged on to.
(MMC).
1. Si SQL Server compte de démarrage est un compte d’utilisateur local sur l’ordinateur, ouvrez Gestion de
l’ordinateur (compmgmt.msc) et clear the Account is Locked Out checkbox for the SQL Server Startup
Account under Local Users & Groups . Ensuite, sélectionnez OK, puis redémarrez le service SQL Server
service.
2. Si SQL Server compte de démarrage est un compte de domaine Windows, ouvrez Utilisateurs et
ordinateurs Active Directory et vérifiez que la propriété Compte de démarrage SQL Server est verrouillée.
3. Si la propriété de l’étape 2 est activée, vous devez effacer cette option, définir un mot de passe fort et
utiliser les mêmes informations d’identification pour la configuration du compte de démarrage SQL
Server à l’aide de Gestionnaire de configuration SQL Server.
L’ID d’événement 17058 et SQL Server ne démarre
pas
Symptômes
Si le service Microsoft SQL Server ne trouve pas le chemin d’accès configuré pour créer des journaux d’erreurs,
le service ne démarre pas et vous recevez le message d’erreur suivant, en fonction de la façon dont vous essayez
de démarrer le service :
Erreur 1067 : Le processus s’est terminé de manière inattendue.

Une erreur spécifique au service s’est produite : 13.
Une aide plus utile est disponible en tapant NET HELPMSG 3523.
Résolution
1. Consultez le journal des applications et vérifiez que vous voyez une entrée de message d’erreur
ressemblant à ce qui suit :
Log Name: Application

Source: MSSQLSERVER
Date: <Datetime>
Event ID: 17058
Task Category: Server
Level: Error
Keywords: Classic
User: N/A
Description:
initerrlog: Could not open error log file 'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVR\MSSQL\Log\ERRORLOG'.
Operating system error = 3(The system cannot find the path specified.).
2. Vérifiez le chemin d’accès qui est définie pour le fichier ErrorLog à l’aide de Gestionnaire de configuration
SQL Server.
Vous pouvez également vérifier le chemin d’accès dans l’entrée de Registre suivante :
SO US- C L É DO N N ÉES
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL -eC:\Program Files\Microsoft SQL Server\MSSQL15.

Server\MSSQL15.MSSQLSERVER\MSSQLServer\Parameters\SQLArg1
MSSQLSERVR\MSSQL\Log\ERRORLOG
3. Essayez de copier le chemin d’accès, puis vérifiez manuellement dans Windows Explorer ou à l’invite de
commandes que vous pouvez accéder à la cible dans le chemin d’accès. (N’ignorez pas les fautes de
frappe, les caractères spéciaux et les problèmes de copier-coller.)
Voici un exemple de commande incorrect qui inclut une faute de frappe :
C:\>dir "C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVR\MSSQL\Log"
Le système ne peut pas trouver le chemin d’accès spécifié.
Voici une commande correcte :
C:\>dir "C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log"
Le volume du lecteur C est Windows

Numéro de série de volume 40B5-7ED1
Répertoire de C:\Program Files\Microsoft SQL Server\MSSQL15. MSSQLSERVER\MSSQL\Log
<Datetime> <DIR> .
<Datetime> <DIR> ..
<Datetime> 20 640 ERRORLOG
<Datetime> 14 082 ERRORLOG.1
4. Mettez à jour le chemin d’accès à un dossier valide dans lequel le compte de démarrage SQL Server des
autorisations pour créer, lire, écrire et mettre à jour des fichiers.
5. Redémarrez le service SQL Server service.
pas
Symptômes
Si le service Microsoft SQL Server ne peut pas créer le fichier Tempdb au démarrage, le service ne démarre pas
lorsque vous utilisez le Gestionnaire de contrôle de service et vous recevez le message d’erreur suivant :
Windows n’a pas pu démarrer SQL Server (MSSQLSERVER) sur l’ordinateur local. Pour plus d’informations,
examinez le journal des événements système.
S’il s’agit d’un service autre que Microsoft, contactez le fournisseur du service et reportez-vous au code
d’erreur spécifique au service 1814.
Cause
Ce problème peut se produire pour les raisons suivantes :
Le disque dur qui hébergeait Tempdb a été supprimé ou la lettre de lecteur a été modifiée pour une raison
quelconque.
Il existe des contraintes d’espace au niveau de la couche du système d’exploitation.
Résolution
1. Ouvrez le journal des applications et vérifiez que vous voyez des entrées de message d’erreur semblables
à ce qui suit :
Source: MSSQLSERVER
Date: <Datetime>
Event ID: 5123
Level: Error
Keywords: Classic
User: N/A
Description:
CREATE FILE encountered operating system error 3(The system cannot find the path specified.)
while attempting to open or create the physical file <FilePath>.

Source: MSSQLSERVER
Date: <Datetime>
Event ID: 17204
Level: Error
Keywords: Classic
User: N/A
Description:
FCB::Open failed: Could not open file <FilePath> for file number 1. OS error: 3(The system cannot
find the path specified.).

Source: MSSQLSERVER
Date: <Datetime>
Event ID: 1814
Level: Information
Keywords: Classic
User: N/A
Description:
Could not create tempdb. You may not have enough disk space available.
Free additional disk space by deleting other files on the tempdb drive and then restart SQL Server.
Check for additional errors in the operating system error log that may indicate why the tempdb files
could not be initialized.
2. Pour résoudre le problème, déplacez le fichier Tempdb vers un autre emplacement à l’aide de la
procédure mentionnée dans la section Procédure de récupération d’échec de Move System Databases.
pas après l’activer
Symptômes
Dans Microsoft SQL Server Configuration Manager, vous devez fournir un certificat côté serveur et activer le
chiffrement. Lorsque vous utilisez le Gestionnaire de contrôle de service pour démarrer le service SQL Server, le
service ne démarre pas et vous recevez le message d’erreur suivant :
d’erreur propre au service 2146885628.
Résolution
1. Consultez le journal des événements d’application et vérifiez que vous voyez deux entrées d’événement

Source: MSSQLSERVER
Date: <Datetime>
Event ID: 26010
Level: Information
Keywords: Classic
User: N/A
Description:
The server could not load the certificate it needs to initiate an SSL connection.
It returned the following error: 0x8009030d. Check certificates to make sure they are valid.

Source: MSSQLSERVER
Date: <Datetime>
Event ID: 33565
Level: Error
Keywords: Classic
User: N/A
Description:
Found the certificate [Cert Hash(sha1) "<Cert Hash number>"] in the local computer store but the SQL
Server service account does not have access to it.
2. Si vous voyez les événements 26010 et 33565, suivez les étapes suivantes :
NOTE
Les deux événements indiquent que le compte de service SQL Server n’a pas d’autorisations sur le certificat qui
est provisioné dans Configuration Manager. Vous devez attribuer les autorisations requises au compte de
service pour résoudre ce problème.
Si vous ne voyez pas les événements 26010 et 33565, vous rencontrez peut-être un autre problème qui n’est
pas résolu dans cet article.
a. Sélectionnez > Démarrer l’exécuter, entrez mmc, puis ouvrez le logiciel en snap-in certificat
dans la console MMC.
b. Dans le menu Console, sélectionnez Ajouter/Supprimer un logiciel en un clin d’œil.
c. Sélectionnez > Ajouter des cer tificats, puis sélectionnez Ajouter à nouveau.
NOTE
Vous êtes invité à ouvrir le logiciel en snap-in pour l’utilisateur, le service ou le compte d’ordinateur actuel.
d. Sélectionnez le compte d’ordinateur.

e. Sélectionnez l’ordinateur local, puis sélectionnez Terminer.
f. Dans la boîte de dialogue Ajouter un logiciel en un clin d’œil autonome, sélectionnez Fermer.
g. Dans la boîte de dialogue Ajouter/Supprimer un logiciel en snap-in, sélectionnez OK.
NOTE
Vos certificats installés sont dans le dossier Certificats dans le conteneur Personnel.
h. Cliquez avec le bouton droit sur le certificat, sélectionnez Toutes les tâches gérer les clés privées,
puis accordez des > autorisations complètes au compte SQL Server service.
Référence
Activer les connexions chiffrées au Moteur de base de données
pas après l’activer
Symptômes
Dans Microsoft SQL Server Configuration Manager, vous devez fournir un certificat côté serveur et activer le
chiffrement. Toutefois, le service SQL Server ne démarre pas et vous recevez le message d’erreur suivant :
d’erreur spécifique au service 13.
Résolution
1. Consultez le journal des applications et vérifiez que vous voyez deux entrées d’événement semblables à
ce qui suit :

Source: MSSQLSERVER
Date: <Datetime>
Event ID: 33556
Level: Error
Keywords: Classic
User: N/A
Description:
Invalid character in the thumbprint [Cert Hash(sha1) " \<Cert Hash number"].
Please provide a certificate with a valid thumbprint.
NOTE
Cette erreur indique généralement que le certificat n’est pas provisionn par le biais de Configuration Manager. Elle
est mise en service en copiant manuellement la valeur d’empreinte numérique dans la clé de Registre suivante :
Server\MSSQL15.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\Certificate
Cette erreur se produit si des caractères non valides sont copiés dans la valeur de Registre.
2. Pour résoudre ce problème, utilisez l’une des méthodes suivantes.

Méthode 1 : fournir le cer tificat à l’aide de Gestionnaire de configuration SQL Ser ver
a. Supprimez manuellement la valeur d’impression miniature de la sous-clé de Registre suivante :
b. Utilisez Configuration Manager pour mettre à nouveau en service le certificat.

c. Redémarrez le service SQL Server service.
Méthode 2 : Corriger les caractères non valides dans la valeur Thumbprint
a. Sélectionnez > Démarrer l’exécuter, entrez mmc, puis ouvrez le logiciel en snap-in certificat
dans la console MMC.
b. Cliquez avec le bouton droit sur le certificat, puis copiez la valeur Thumbprint dans un fichier
texte. Assurez-vous qu’aucun espace n’existe avant et après la valeur de l’empreinte numérique.
c. Supprimez manuellement la valeur Thumbprint de la sous-clé de Registre suivante :
d. Collez manuellement la nouvelle valeur ou retapez la valeur que vous avez provenant du fichier
texte.
e. Redémarrez le service SQL Server service.
pas
Symptômes
Lorsque le fichier binaire Microsoft SQL Server (Sqlservr.exe) est renommé sur le système qui héberge le service
SQL Server, le service ne démarre pas et vous recevez le message d’erreur suivant, en fonction de la façon dont
vous essayez de démarrer le service :
Erreur 2 : le système ne peut pas trouver le fichier spécifié.

Le fichier spécifié est introuvable.
Résolution
1. Vérifiez le Windows système et vérifiez que vous voyez une entrée de message d’erreur semblable à ce
qui suit :
Log Name: System

Date: <Datetime>
Event ID: 7000
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Description:
The SQL Server (MSSQLSERVER) service failed to start due to the following error:
The system cannot find the file specified.
2. Go to the SQL Server installation folder and verify that it doesn’t contain the Sqlservr.exe file.
3. Résolvez le problème en réparant l’installation SQL Server’installation selon la procédure documentée
dans La réparation d’une installation SQL Server échec.
Les erreurs du système d’exploitation 1450 et 665
sont signalées pour les fichiers de base de données
lors de la création de DBCC CHECKDB ou de
capture instantanée de base de données
Cet article vous aide à résoudre le problème où les erreurs de système d’exploitation 1450 et 665 sont signalées
pour les fichiers de base de données pendant ou la création d’une capture instantanée de DBCC CHECKDB base de
données.
Version du produit d’origine : SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012, SQL
Server 2008
Symptômes
Sur un SQL Server, supposons que vous effectuez l’une des actions suivantes :
Vous créez une capture instantanée de base de données sur une base de données de grande taille. Après cela,
vous effectuez de nombreuses opérations de modification de données ou de maintenance dans la base de
données source.
Vous créez une capture instantanée de base de données sur une base de données miroir.
Vous exécutez une famille de commandes pour vérifier la cohérence d’une base de données de grande taille
et vous effectuez également un grand nombre de modifications de données DBCC CHECKDB dans cette base de
données.
Dans ce scénario, vous remarquez les erreurs suivantes signalées dans le journal des erreurs SQL Server en
fonction de l’environnement SQL Server’exécution.
Windows Ser ver 2003
Le système d’exploitation a renvoyé l’erreur 1450 (des ressources système insuffisantes existent pour
terminer le service demandé.) à SQL Server lors d’une écriture au décalage 0x00002a3ef96000 dans un
fichier avec gestion 0x0000000000000D5C. Il s’agit généralement d’une condition temporaire et le SQL
Server va continuer à réessayer l’opération. Si la condition persiste, une action immédiate doit être prise
pour la corriger.
Windows Ser ver 2008, Windows Vista et les versions ultérieures des systèmes d’exploitation
ser veur et client
Le système d’exploitation a renvoyé l’erreur 665 (L’opération demandée n’a pas pu être terminée en raison
d’une limitation du système de fichiers) à SQL Server pendant une écriture au 0x00002a3ef96000 de
décalage dans le fichier « Sam.mdf:MSSQL_DBCC18 ».
En plus de ces erreurs, vous pouvez également remarquer des erreurs de délai d’accès, comme illustré ci-
dessous :
Le délai d’attente s’est produit pendant l’attente du verrou : classe « DBCC_MULTIOBJECT_SCANNER »,

id 000000002C61DF40, type 4, 0x00000000038089B8 de tâche : 16, temps d’attente 600, indicateurs
0x1a, propriétaire de 0x0000000006A09828. Continue d’attendre.
Le délai d’attente s’est produit pendant l’attente du verrou : classe «

ACCESS_METHODS_HOBT_COUNT» , id 000000002C61DF40, type 4, 0x00000000038089B8 de
tâche : 16, temps d’attente 600, indicateurs 0x1a, propriétaire de 0x0000000006A09828. Continue
d’attendre.
En outre, vous pouvez également remarquer le blocage lorsque vous affichez différents affichages de gestion
dynamique (DMV) comme sys.dm_exec_requests , sys.dm_os_waiting_tasks etc.
Cause
Ce problème se produit si un grand nombre d’instances sont nécessaires pour gérer un fichier
ATTRIBUTE_LIST_ENTRY fortement fragmenté dans NFTS. Ce comportement est expliqué dans l’article de la Ko
suivant :
Un fichier fortement fragmenté dans un volume NTFS peut ne pas dépasser une certaine taille
Les fichiers fragmentés créés par SQL Server pour les captures instantanées de base de données peuvent être
fragmentés à ces niveaux lorsque de grandes quantités de modifications de données se produisent pendant la
durée de vie de ces fichiers instantanés.
Pour obtenir un arrière-plan complet de la façon dont SQL Server Engine utilise des fichiers peu nombreux
NTFS et d’autres flux de données, reportez-vous aux liens suivants :
How It Works: SQL Server 2005 Database Snapshots (Replica)
SQL Server signale l’erreur de système d’exploitation 1450, 1452 ou 665 (nouvelles tentatives)
Fonctionnement : nouveau SQL Server de fichiers dispersés (bases de données DBCC et capture
instantanée)
Fonctionnement des captures instantanées de base de données
DBCC CHECKDB (Transact-SQL) [Voir la section « Capture instantanée de base de données interne » ]
Nouvel événement étendu pour suivre les écritures dans le fichier de capture instantanée dispersée
Résolution
1. Décomposez la base de données de grande taille en fichiers plus petits. Par exemple, si vous avez un
fichier de données de 8 To, vous pouvez le décomposer en huit fichiers de données de 1 To. Voici les
étapes à suivre pour effectuer cette tâche :
a. Ajoutez les 7 nouveaux fichiers de 1 To au même groupe de fichiers.
b. Reconstruire les index en cluster des tables existantes, ce qui répartira automatiquement les données
de chaque table entre les 8 fichiers. Si une table ne comprend pas d’index en cluster, créez-en un, puis
déposez-le pour accomplir la même opération.
c. Réduire le fichier d’origine de 8 To, maintenant qu’il est plein d’environ 12 à 15 %.
2. Envisagez de placer les fichiers de base de données sur un volume ReFS qui n’a pas les mêmes limites
ATTRIBUTE_LIST_ENTRY que NTFS présente. Vous devez reformater le volume NTFS actuel à l’aide de
ReFS.
3. Envisagez de défragmenter le volume dans lequel résident les fichiers de base de données. Pour plus
d’informations, voir Erreur du système d’exploitation (665 - Limitationdu système de fichiers) Et pas
seulement pour DBCC.
4. Formatez le volume à l’aide de l’option /L pour obtenir un frS de grande taille.
NOTE
Pour les systèmes exécutant Windows Server 2008 R2 et Vista, vous devez d’abord appliquer le correctif à partir
de l’article de la base de données 967351 avant d’utiliser l’option /L avec la commande de format.
5. CORRECTIF : Erreur du système d’exploitation 665 lorsque vous exécutez la commande DBCC CHECKDB
pour la base de données qui contient l’index columnstore dans SQL Server 2014
6. Réduisez la durée de vie des commandes DBCC CHECK à l’aide des améliorations des performances et
évitez par conséquent les erreurs 665 : les améliorations apportées à la commande DBCC CHECKDB
peuvent accélérer les performances lorsque vous utilisez l’option PHYSICAL_ONLY
Dans certaines conditions, il se peut que vous rencontriez toujours les erreurs mentionnées ci-dessus même
après avoir appliqué ces correctifs. Dans ce scénario, vous pouvez évaluer certaines des solutions de
contournement abordées dans le billet de blog suivant :
Erreurs de fichier fragmentées : 1450 ou 665 en raison de la fragmentation des fichiers : correctifs et solutions
de contournement
Pour plus d’informations, voir comportement DBCC CHECKDBlorsque la base de données SQL Server est située
sur un volume ReFS.
L’erreur 17053 peut être enregistrée dans le journal
des erreurs après avoir exécuté une commande
DBCC dans SQL Server
Cet article explique comment interpréter « Erreur : 17053 » et d’autres messages d’erreur qui peuvent être
signalés lorsque vous exécutez une commande DBCC dans SQL Server.
Symptômes
Vous exécutez l’une des commandes DBCC suivantes dans Microsoft SQL Server :
DBCC CHECKDB
DBCC CHECKALLOC
DBCC CHECKTABLE
DBCC CHECKCATALOG
DBCC CHECKFILEGROUP
Après cela, les messages d’erreur semblables à ce qui suit peuvent être enregistrés dans SQL Server journal des
erreurs :
2006-09-01 17:33:24.48 spid54 35 transactions rolled forward in database 'ProductionData' (11). This is an
informational message only. No user action is required.
2006-09-01 17:35:39.16 spid54 4 transactions rolled back in database 'ProductionData' (11). This is an
2006-09-01 17:36:31.76 spid53 Error: 17053, Severity: 16, State: 1.
2006-09-01 17:36:31.76 spid53 E:\SQLData\ProductionData.mdf:MSSQL_DBCC11: Operating system error 112(There
is not enough space on the disk.) encountered.
2006-09-01 17:36:31.76 spid53 E:\ SQLData \ProductionData.mdf:MSSQL_DBCC11: Operating system error 112(There
2006-09-01 17:36:31.80 spid54 DBCC CHECKDB (ProductionData) executed by DomainName \ UserName found 0 errors
and repaired 0 errors. Elapsed time: 0 hours 3 minutes 19 seconds.
2006-09-01 17:36:32.30 spid54 Database 'ProductionData' cannot be opened. It has been marked SUSPECT by
recovery. See the SQL Server errorlog for more information.
Cause
Dans SQL Server, les commandes DBCC utilisent des captures instantanées de base de données en lecture seule
internes. Ces captures instantanées de base de données sont créées sur le même lecteur que les fichiers de
données de base de données correspondants. Les captures instantanées de base de données grossissent en
proportion de la quantité de données modifiées dans la base de données sur laquelle s’exécutent les
commandes DBCC. Si l’activité transactionnelle se poursuit sur cette base de données, les captures instantanées
de base de données créées par les commandes DBCC peuvent être à l’origine de problèmes d’espace disque.
Étant donné que les fichiers instantanés de base de données et les fichiers de données réels résident sur le
même lecteur de disque, les deux ensembles de fichiers sont en concurrence pour l’espace disque. Dans ce cas,
les transactions d’application ou les transactions utilisateur sont privilégiées. La capture instantanée de base de
données interne utilisée par le DBCC est marquée comme suspecte. Par conséquent, les commandes DBCC sont
à l’expérience d’erreurs et ne peuvent pas se terminer.
L’espace disque est l’une des raisons pour laquelle les écritures dans la capture instantanée de base de données
interne peuvent échouer. D’autres raisons telles que les codes d’erreur du système d’exploitation 1450 et 665
peuvent également contribuer à des problèmes similaires et rendre la capture instantanée de base de données
interne dans un état suspect.
Statut
Les informations importantes suivantes s’appliquent aux messages d’erreur mentionnés dans la section
Symptômes :
Ces messages d’erreur sont issus de différents identificateurs de processus de serveur actif (SPID). SPID
54 est l’ID de session qui exécute la commande DBCC. SPID 53 est l’ID de session qui exécute une
transaction utilisateur.
Ces messages d’erreur indiquent la fin des transactions et l’opération de revenir en arrière. Ces messages
sont générés lors de la phase initiale de l’exécution de la commande DBCC. Lorsque vous exécutez une
commande DBCC, la commande DBCC tente d’abord de créer une capture instantanée interne. Lorsque la
capture instantanée est créée, la récupération de base de données est effectuée par rapport à cette
capture instantanée pour mettre l’instantané dans un état cohérent. Les messages d’erreur reflètent cette
activité.
Le message d’erreur 926 indique que la base de données est marquée comme suspecte. Ce message
d’erreur fait référence à la capture instantanée interne et non à la base de données réelle. L’état de la base
de données est « en ligne » et la base de données est fonctionnelle.
Le message d’erreur 17053 contient le nom des flux de flux de remplacement du système de fichiers
NTFS utilisés pour la capture instantanée interne. Ce message d’erreur indique la raison réelle du
problème.
La capture instantanée de base de données interne utilise le même nom que la base de données réelle.
Par conséquent, ces messages d’erreur contiennent le nom de la base de données.
Même si le message du journal des erreurs indique que DBCC CHECKDB est terminé, il doit être considéré
comme un arrêt anormal. Vous devez réexécuter la commande DBCC CHECKDB pour permettre son
exécuter jusqu’à ce qu’elle soit terminée pour accéder à la cohérence de la base de données. Dans ces
situations, reportez-vous à la sortie de la commande DBCC CHECKDB renvoyée au client pour
comprendre quels objets ont été vérifiés et signalés comme nettoyés.
Pour plus d’informations sur ce problème, consultez les rubriques suivantes dans SQL Server Books Online :
Utilisation des captures instantanées de base de données internes DBCC
Comprendre les tailles de fichiers peu nombreuses dans les captures instantanées de base de données.
Suivez les étapes documentées dans ces rubriques pour éviter les problèmes d’utilisation de l’espace.
Après avoir corrigez un problème, réexécutez les commandes DBCC.
Outre les messages d’erreur mentionnés dans la section Symptômes, vous pouvez recevoir le message d’erreur
suivant :
Msg 5128, Niveau 17, État 2, Ligne 6
Échec de l’écriture dans le fichier E:\CreateFile\ProductionData.mdf:MSSQL_DBCC11 dispersé en raison d’un

manque d’espace disque.
Dans ce cas, l’application cliente qui exécute les commandes DBCC aura les entrées suivantes dans le jeu de
résultats de l’application :
Résultats DBCC pour « ProductionData ».

CHECKDB a trouvé 0 erreur d’allocation et 0 erreur de cohérence dans la base de données « ProductionData
».
Msg 926, Level 21, State 6, Line 1
La base de données « ProductionData » ne peut pas être ouverte. Il a été marqué SUSPECT par récupération.
Pour plus d’informations, SQL Server lelog des erreurs de la recherche.
Une erreur grave s’est produite sur la commande actuelle. Les résultats, s’il y en a, doivent être ignorés.
Si la capture instantanée n’a pas pu être créée, vous recevez des messages d’erreur semblables à ce qui suit dans
l’application cliente qui émettre les commandes DBCC :

Impossible de créer une capture instantanée de base de données car elle n’a pas réussi à démarrer.
La capture instantanée de base de données pour les vérifications en ligne n’a pas pu être créée. La raison est
donnée dans une erreur précédente ou l’un des volumes sous-jacents ne prend pas en charge les fichiers
rares ou les flux de remplacement. Tentative d’accès exclusif pour exécuter des vérifications hors connexion.
La base de données n’a pas pu être verrouillée exclusivement pour effectuer l’opération.
Instruction Check abandonnée. La base de données n’a pas pu être vérifiée car une capture instantanée de
base de données n’a pas pu être créée et la base de données ou la table n’a pas pu être verrouillée. Pour plus
d’informations sur le moment où ce comportement est attendu et les solutions de contournement
existantes, voir Books Online. Consultez également les erreurs précédentes pour plus d’informations.
L’écriture dans le fichier « E:\Data\LogFUllTest_Data.mdf:MSSQL_DBCC10 » a échoué en raison d’un manque
d’espace disque.
Si la capture instantanée de base de données interne s’exécute en erreurs 1450 ou 665, voici une séquence
classique que vous remarquerez dans le journal des SQL Server’erreurs :
2008-05-21 13:03:45.67 spid500 272 transactions rolled forward in database 'MYDATABASE' (12). This is an
2008-05-21 13:03:45.84 spid500 2 transactions rolled back in database 'MYDATABASE' (12). This is an
2008-05-21 13:03:46.97 spid500 Recovery completed for database MYDATABASE (database ID 12) in 5 second(s)
(analysis 602 ms, redo 3954 ms, undo 105 ms.) This is an informational message only. No user action is
required.
2008-05-21 13:36:48.25 spid480 The operating system returned error 665(The requested operation could not be
completed due to a file system limitation) to SQL Server during a write at offset 0x00001b35138000 in file
'I:\MSSQL\DATA\mscrm_data1.ndf:MSSQL_DBCC12'.
2008-05-21 13:36:48.26 spid480 C:\MSSQL\DATA\MyDatabase.mdf:MSSQL_DBCC12: Operating system error 665(The
requested operation could not be completed due to a file system limitation) encountered.
'C:\MSSQL\DATA\MyDatabase.mdf:MSSQL_DBCC12'.
'C:\MSSQL\DATA\MyDatabase.mdf:MSSQL_DBCC12'.
2008-05-21 13:36:48.37 spid500 DBCC CHECKDB (MYDATABASE) executed by DomainName \ UserName found 0 errors
and repaired 0 errors. Elapsed time: 0 hours 33 minutes 16 seconds. Internal database snapshot has split
point LSN = 0000759c:002547bc:0040 and first LSN = 0000759c:0023696d:0049. This is an informational message
only. No user action is required.
Référence
MSSQLSERVER_17053
Message d’erreur lorsque vous exécutez la
commande DBCC CHECKDB sur un ordinateur qui
contient une base de données SQL Server de
données
Cet article vous explique en détail le problème qui se produit lorsque vous exécutez la commande sur un
ordinateur qui contient une base DBCC CHECKDB de données SQL Server données.
Version du produit d’origine : SQL Server 2008
Symptômes
Vous restituer une Microsoft SQL Server base de données 2008 SQL Server 2005 à partir d’une
sauvegarde.
Vous recevez des erreurs au cours du processus de restauration qui vous empêchent de restaurer la base
de données.
Vous avez réussi à restaurer la base de données à partir de la même sauvegarde à l’aide de l
CONTINUE_AFTER_ERROR option.
Dans ce scénario, lorsque vous exécutez la commande DBCC CHECKDB sur l’ordinateur qui contient la base de
données SQL Server, vous recevez un message d’erreur semblable à ce qui suit :
Msg 8967, Niveau 16, État 216, Serveur <server name> , Ligne 2
Une erreur interne s’est produite dans le DBCC, ce qui a empêché d’autres traitements. Contactez le support
technique.
Résultats DBCC pour ' <database name> '.
Msg 8921, Niveau 16, État 1, Serveur <server name> , Ligne 1
Check terminated. Un échec a été détecté lors de la collecte des faits. Il est possible que tempdb manque
d’espace ou qu’une table système soit incohérente. Vérifiez les erreurs précédentes.
En outre, un message semblable à ce qui suit peut s’afficher dans le journal SQL Server’erreurs :
2007-05-26 07:13:49.21 spid58 DBCC a rencontré une page avec un LSN supérieur à la fin actuelle du LSN
() journal pour sa capture instantanée de base de données <LSN> interne. Page non lisible (id:page de
fichier), base de données ' <database name' (database ID database id> ), LSN = ( <LSN> ), type = 32,
isInSparseFile = 1. Ré-exécutez cette commande DBCC.
Cause
Ce problème se produit si la commande ne peut pas effectuer les vérifications nécessaires pour vérifier la
DBCC CHECKDB cohérence de la base de données. Ces vérifications n’ont pas pu être effectuées pour de
nombreuses raisons. Par exemple, ce comportement peut se produire s’il existe des incohérences fondamentales
dans la base de données, telles que des incohérences de métadonnées ou une altération de capture instantanée
de base de données. Pour plus d’informations sur la cause spécifique de cette erreur, vous pouvez examiner
l’état différent affiché dans le message d’erreur. Dans le scénario décrit dans la section Symptômes, le message
d’état 216 indique que la commande lit une page à partir de la capture instantanée interne dont le numéro de
séquence de journal est supérieur à la fin du DBCC CHECKDB LSN du journal. Ce comportement peut se produire
si vous restituer des bases de données à l’aide de CONTINUE_AFTER_ERROR option.
Pour contourner ce problème, utilisez le conseil TABLOCK avec la DBCC CHECKDB commande. Cela permet à la
DBCC CHECKDB commande de se terminer sans générer le message d’erreur.
Pour plus d’informations sur les conseils TABLOCK, visitez le site Web Microsoft suivant : Conseils (Transact-SQL)
- Tableau.
La sauvegarde vers l’URL échoue avec l’erreur
d’SQL Server
Cet article vous aide à résoudre l’erreur qui se produit lorsque vous utilisez la commande URL de la base de
données de sauvegarde nonrecoverable I/O dans SQL Server.
Enterprise
Symptômes
Vous essayez de sauvegarder une base de données sur votre ordinateur virtuel SQL Server Azure (IaaS) à l’aide
de la commande URL de la base de données de sauvegarde. Toutefois, la tentative échoue avec l’erreur suivante :

Une erreur d’O/S non récible s’est produite sur le fichier « « La sauvegarde vers l’URL a reçu une exception
du https://sqlbakurl.blob.core.windows.net/backupcontainer/demodb.bak: point de terminaison distant.
Message d’exception : le serveur distant a renvoyé une erreur : (400) Demande erronée.
BACKUP DATABASE se termine anormalement.
Cause
This issue occurs if the storage account that you’re trying to back up to was created with the Account Kind
setting set to Blob . Le paramètre Type de compte doit être à usage général.
Résolution
Pour résoudre ce problème, créez un compte de stockage et spécifiez l’objectif général du paramètre Type de
compte. Désignez également un conteneur dans ce compte de stockage pour la sauvegarde vers l’URL.
Lorsque le type de compte est définie sur Usage général, cela permet la prise en charge des fichiers blob de
page. SQL Server sauvegarde utilise des blobs de page comme type Blob. Pour plus d’informations, voir SQL
Server sauvegarde et restauration avec Windows Azure Blob Stockage Service.
Une base de données TDE peut ne pas récupérer
dans SQL Server
Cet article vous aide à résoudre le problème où une base de données TDE peut ne pas être récupérée lorsque le
chiffrement automatique de la clé principale par la clé principale de service est supprimé.
S’applique à : SQL Server 2008 Enterprise, SQL Server 2008 R2 Enterprise
Symptômes
Dans Microsoft SQL Server 2008 et dans Microsoft SQL Server 2008 R2, une base de données activée pour le
chiffrement transparent de la base de données peut ne pas être récupérée. De plus, le message d’erreur suivant
peut être consigné dans le journal d SQL Server’erreurs suivant :
2012-01-14 22:16:26.47 erreur spid20s : 15581, Gravité : 16, État : 3.

2012-01-14 22:16:26.47 spid20s Please create a master key in the database or open the master key in the
session before performing this operation.
Cause
Ce problème se produit lorsque le chiffrement de la clé principale de service pour la clé principale de base de
données dans la base de données maître est supprimé lorsque la commande suivante est exécuté :
Use master
go
alter master key drop encryption by service master key
Lorsqu’une clé principale de base de données (DMK) est créée pour la première fois, elle est automatiquement
chiffrée avec la clé principale de service.
La clé principale de base de données est utilisée pour chiffrer le certificat utilisé par la fonctionnalité de
chiffrement transparent de la base de données. Toute tentative d’utilisation de la base de données TDE nécessite
l’accès au certificat et à la clé principale de base de données dans la base de données maître. Dans la
configuration par défaut, la clé principale de base de données est ouverte implicitement par la clé principale de
service. Une clé principale qui n’est pas chiffrée par la clé principale de service doit être ouverte explicitement à
l’aide de l’instruction OPEN MASTER KEY avec un mot de passe sur chaque session nécessitant l’accès à la clé
principale.
La récupération de base de données se produit sur les sessions système. Si ces sessions ne peuvent pas ouvrir le
certificat et la clé principale de base de données, la récupération ne peut pas être effectuée sur une base de
données TDE si le déchiffrement automatique du DMK par SMK est supprimé. Dans ce scénario, la base de
données est marquée comme récupération en attente .
Résolution
Pour résoudre le problème, activez le déchiffrement automatique de la clé principale. Pour ce faire, exécutez les
commandes suivantes :
Use master
go
open master key DECRYPTION BY PASSWORD = 'password'
alter master key add encryption by service master key
Mettre la base de données hors connexion et la mettre en ligne à l’aide

Alter Database <databasename> Set ONLINE command de .
Utilisez la requête suivante pour déterminer si le déchiffrement automatique de la clé principale par la clé
principale de service a été désactivé pour la base de données maître :
select is_master_key_encrypted_by_server from sys.databases where name = 'master'
Si cette requête renvoie la valeur 0, le déchiffrement automatique de la clé principale par la clé principale de
service a été désactivé.
Violations d’accès et fichiers de vidage mémoire
lorsque vous utilisez la session XEvent avec
sqlos.wait_info événement dans SQL Server
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez une session XEvent qui a un
événement sqlos.wait_info SQL Server.
Symptômes
Vous créez une session XEvent qui possède un sqlos.wait_info événement dans Microsoft SQL Server.
Dans cette session, vous définissez un filtre (prédicat) dans le modèle suivant :
[sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%< **Query Text** >')
Dans ce scénario, vous pouvez être face à l’un des problèmes suivants :
SQL Server génère des violations d’accès ou un fichier de vidage mémoire de dépassement de la pile.
SQL Server génère un fichier de vidage mémoire du scheduler sans rapport.
Les requêtes ne retournent pas de résultats, ou vous ne pouvez pas annuler ou supprimer une requête.
Lorsque SQL Server génère une exception et un fichier de vidage mémoire de dépassement de capacité
de la pile dans le journal des erreurs SQL Server, des messages d’erreur semblables à l’un des
EXCEPTION_ACCESS_VIOLATION messages suivants sont générés :
<Time Stamp> spid52 *

<Time Stamp> SPID52 * BEGIN STACK DUMP:
<Time Stamp>spid52 * <Time Stamp> spid 52
<Time Stamp> Spid52 * Exception Address = 00007FFA414ED763
Module(sqlmin+000000000000D763)
<Time Stamp> spid52 * Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION
<Time Stamp> Une violation d’accès spid52 * s’est produite en 0000000000000008
<Time Stamp> spid55 Impossible de créer un fichier de vidage de pile en raison d’un manque de pile
(Emplacement : scheduler.cpp:2090
Expression : !pWorker->WorkerQueueElem::IsInList ()
SPID: 55
ID de processus : 8548)
<Time Stamp> Spid55 Stack Signature pour le vidage est 0x0000000000000000
<Time Stamp> Spid55 <Time Stamp> Stack Overflow Dump not possible - Exception c00000fd
EXCEPTION_STACK_OVERFLOW at 0x00007FFA4EF85F35
<Time Stamp> spid55 SqlDumpExceptionHandler : Address=0x00007FFA4EF85F35 Exception Code
= c00000fd
<Time Stamp> spid55 Rax=00000000000044c Rbx=0000000002612320 Rcx=0000000002612050
Rdx=00000000662baf59
<Time Stamp> spid55 Rsi=000000004b04f848 Rdi=000000004b000270
Premier=0000000004ef85f35 Rsp=000000002611fd0
<Time Stamp> spid55 Rbp=0000000000000000 EFlags=0000000000010202
<Time Stamp> spid55 cs=0000000000000033 ss=000000000000002b ds=000000000000002b
es=00000000000002b fs=0000000000000053 gs=0000000000002b
<Time Stamp> spid55 1 : Frame 0000000000000000 Adresse de retour 00007FFA4EF85F35
Pour contourner ce problème, évitez d’utiliser des conditions de filtre complexes avec wait_info l’événement.
Cela est dû au fait que l’événement est très important en ressources et wait_info peut considérablement
ralentir une requête.
Si vous souhaitez suivre cette situation, modifiez le modèle de prédicat de filtre <Query Text> comme suit :
([sqlserver].[equal_i_sql_unicode_string]([sqlserver].[sql_text],N'<Query Text>')
Max_Queue_Readers est ignorée lorsque vous
essayez de limiter les tâches d’activation dans
Service Broker
Cet article vous aide à résoudre le problème qui se produit lorsque plus de tâches d’activation s’exécutent dans
Service Broker que la limite définie par la Max_Queue_Readers propriété.
Server 2008 R2
Symptômes
Vous utilisez Service Broker dans SQL Server 2017 sur Windows, Microsoft SQL Server 2014 ou SQL
Server 2012.
Vous définissez Service Broker pour l’exécution asynchrone des procédures stockées.
Vous définissez la propriété sur une valeur spécifique pour la file d’attente service Broker afin de limiter le
nombre d’instances d’une procédure stockée d’activation qui s’exécutent Max_Queue_Readers en même
temps.
Dans ce scénario, vous remarquez que plus de tâches activées sont en cours d’exécution que la valeur définie
pour Max_Queue_Readers .
Cause
Ce problème peut se produire si la base de données Service Broker passe du mode mono-utilisateur ( ) au
RESTRICTED_USER mode multi-utilisateur ( ) en exécutant ce MULTI_USER qui suit :
alter database <dbname> set multi_user
Lorsque le mode utilisateur est modifié sur la base de données, Service Broker est arrêté et redémarré. Au cours
de ce processus, l’objet QueueMonitor existant est supprimé et une autre instance de l’objet est QueueMonitor
créée. Si le processus d’activation est en cours d’exécution d’une longue opération pendant l’arrêt du Service
Broker, l’état de l’objet QueueMonitor est modifié pour être abandonné.
Toutefois, l’instance d’objet existante n’est pas supprimée, car son nombre de QueueMonitor références n’a pas
atteint zéro. Si la procédure d’activation est toujours en cours d’exécution au redémarrage du Service Broker, la
nouvelle instance de l’objet et l’objet abandonné QueueMonitor QueueMonitor coexistent dans la même file
d’attente. QueueMonitor L’instance d’objet supprimée sera supprimée lors du prochain démarrage de Service
Broker.
Pour contourner ce problème, veillez à l’exécuter alter database [dbname] set multi_user lorsqu’aucune
procédure activée n’est en cours d’exécution. Pour ce faire, utilisez l’une des méthodes suivantes :
Avant de modifier le mode utilisateur, désactivez toutes les files d’attente de la base de données, puis
réactivez toutes les files d’attente.
Avant de modifier le mode utilisateur, désactivez la procédure d’activation pour toutes les files d’attente
concernées en exécutant la commande suivante, puis réactivez la procédure d’activation :
alter queue <queueName> with activation (status = off)
Vous pouvez vérifier le nombre de procédures d’activation en cours d’exécution pour une file d’attente
spécifique en exécutant une requête sys.dm_broker_activated_tasks comme suit :
select * from sys.dm_broker_activated_tasks where queue_id = <queue number>
Vous pouvez interroger l’état du moniteur de file d’attente en exécutant la requête suivante :
Select * from sys.dm_broker_queue_monitors where queue_id = <queue number>
L’état du moniteur de file d’attente s’affiche comme abandonné si le mode utilisateur de la base de données a
été modifié.
SQL Le travail de l’agent qui exécute une requête
distribuée peut échouer avec les messages d’erreur
65535, 782 ou 7437
Cet article vous aide à résoudre le problème où le travail de l’agent SQL qui exécute une requête distribuée peut
échouer avec des messages d’erreur 65535, 782 ou 7437.
Symptômes
Un travail de l’agent SQL qui exécute une requête distribuée (serveur lié) peut échouer avec l’un des messages
d’erreur suivants, lorsque le propriétaire du travail n’est pas membre du rôle serveur sysadmin :
Le fournisseur OLE DB « pour le serveur lié » a renvoyé le message « Le délai <provider name>
<Linkedserver Name> d’expiration de connexion a expiré ».
Le fournisseur OLE DB « » pour le serveur lié « » a renvoyé le message « Une erreur s’est produite
lors de l’établissement d’une connexion <provider name> <Linkedserver Name> au serveur. Lors de
la connexion à SQL Server 2005, cet échec peut être dû au fait que sous les paramètres par défaut
SQL Server n’autorise pas les connexions distantes. »
SQL Interfaces réseau : serveur de localisation d’erreurs/instance spécifiée [xFFFFFFFF].

Fournisseur SSL : aucune informations d’identification n’est disponible dans le package de sécurité
Fournisseur OLE DB « <provider name> « for linked server " <Linkedserver Name> " returned
message « Client unable to establish connection ».
Par exemple, dans SQL Server 2008, les messages d’erreur peuvent être similaires à ce qui suit :
Le fournisseur OLE DB « SQLNCLI » pour le serveur lié » a renvoyé le message « Le délai d’expiration
de connexion <Linkedserver Name> a expiré ».
Le fournisseur OLE DB « SQLNCLI » pour le serveur lié « » a renvoyé le message « Une erreur s’est
produite lors de l’établissement d’une connexion <Linkedserver Name> au serveur. Lors de la
connexion à SQL Server 2005, cet échec peut être dû au fait que sous les paramètres par défaut SQL
Server n’autorise pas les connexions distantes. »
SQL Interfaces réseau : serveur de localisation d’erreurs/instance spécifiée [xFFFFFFFF].

Fournisseur SSL : aucune informations d’identification n’est disponible dans le fournisseur OLE DB du
package de sécurité « SQLNCLI10 <Linkedserver Name> » pour le serveur lié » a renvoyé le
message « Client incapable d’établir la connexion ».

Les serveurs liés ne peuvent pas être utilisés sous l’emprunt d’identité sans mappage pour la
connexion dont l’identité a été usurpée.
Vous pouvez également voir le même comportement lors de l’utilisation ou de l’exécution d’une requête
distribuée à l’aide de l’emprunt d’identité via une instruction Openquery Execute as Login T-SQL.
Cause
L’étape SQL transactuelle s’exécute en tant que propriétaire de l’étape du travail si le propriétaire de l’étape de
travail n’est pas membre du rôle serveur fixe sysadmin. SQL L’agent Execute as Login exécute l’étape du travail
dans le contexte du propriétaire de l’étape du travail. Vous ne pouvez pas utiliser EXECUTE AS d’instruction au-
delà des limites du serveur. Ce comportement est inhérent au produit. Pour plus d’informations, voir les
rubriques suivantes dans SQL Server Books Online :
EXECUTE AS (Transact-SQL)
Extension de l’emprunt d’identité de base de données à l’aide d’EXECUTE AS
NOTE
La même cause s’applique au scénario dans lequel vous essayez manuellement de modifier le contexte d’exécution d’une
requête distribuée dans management studio à l’aide de l’instruction EXECUTE AS.
IMPORTANT
La solution de contournement suivante nécessite que vous définissiez une connexion de serveur local explicite aux
mappages de connexion de serveur distant à l’aide de la page Sécurité sous Propriétés de l’objet serveur lié. Étant donné
que la colonne Utilisateur distant doit être une connexion d’authentification SQL Server sur le serveur distant, le mode
d’authentification du serveur distant doit être déjà en mode mixte ou doit être modifié en mode mixte avant d’utiliser la
solution de contournement abordée ci-dessous.
Si une étape de travail T-SQL appartient à un utilisateur qui ne fait pas partie du rôle serveur sysadmin et si
l’étape contient une requête distribuée, prenez les mesures suivantes pour vous assurer que les travaux ou les
requêtes n’échouent pas :
1. Créez un mappage pour chaque propriétaire de l’étape du travail sur le serveur local à une connexion
existante ou nouvelle sur le serveur distant.
2. Assurez-vous que la connexion dispose de privilèges suffisants pour exécuter différents modules sur le
serveur distant accessibles dans la requête distribuée. Pour plus d’informations, voir Propriétés du serveur lié
(page Sécurité).
Parfois, vous remarquerez que les requêtes abordées dans l’un des scénarios de la section Symptômes peuvent
s’exécuter correctement. Cela se produit généralement lorsque l’utilisateur dont l’identité a été usurpée s’est
précédemment connectée au système distant et que le système a toujours ouvert une connexion établie par
l’utilisation à distance. Vous ne devez pas vous attendre à ce que la requête fonctionne tout le temps.
Étapes pour reproduire le comportement
1. Sur votre instance SQL, créez un serveur lié à une autre instance SQL à l’aide de SQL Server Management
Studio (SSMS) ou du script suivant.
EXEC master.dbo.sp_addlinkedserver @server = <server name>, @srvproduct=N'SQL Server'
/* For security reasons the linked server remote logins password is changed with ######## */
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=<servername> ,
@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL
2. Exécutez la requête suivante dans SSMS à l’aide d’une connexion membre du rôle serveur Sysadmin et
assurez-vous qu’elle fonctionne bien.
select * from <servername>.master.sys.sysobjects
3. À présent, modifiez le contexte de la requête en un compte non-sysadmin et exécutez la même requête.
execute as login='Domain\Login1'
go
select suser_sname()
go
select * from <servername>.master.sys.sysobjects
go
Cette étape échoue avec l’erreur mentionnée dans la section Symptômes de l’article.
NOTE
OPENROWSET et les fonctions ne sont pas affectées par ce problème, car ces fonctions incluent les informations
OPENDATASOURCE d’identification en tant que paramètres.
BEGIN DISTRIBUTED TRANSACTION est une instruction distincte qui n’a pas ses propres informations d’identification et
n’est pas affectée par ce problème. Toutefois, si la sécurité du serveur lié n’est pas correctement configurée, ces
instructions peuvent toujours échouer.
Impossible de migrer l’assembly vers SQL Server
2017 lors de la vérification de la compatibilité de la
base de données Configuration Manager
Cet article présente l’assembly ne peut pas être migré vers SQL Server erreur 2017 lors de la vérification de
compatibilité de la base de données Configuration Manager.
Version du produit d’origine : System Center Configuration Manager, SQL Server 2017 sur Windows
Résumé
Dans Microsoft SQL Server 2017, vous utilisez le contrôle de compatibilité de base de données intégré pour
déterminer la compatibilité de mise à niveau d’une base de données Microsoft System Center Configuration
Manager. Vous avez également CLR Strict Security activé. Lorsque vous exécutez la vérification, vous recevez
des messages d’information concernant les assemblys indiqués suivants :
Assembly [DcmObjectModel_SQLCLR] ne peut pas être migré vers SQL Server 2017. Pour plus
d’informations, voir : Ligne 1, Colonne 1.
Assembly [MessageHandlerService] ne peut pas être migré vers SQL Server 2017. Pour plus d’informations,
voir : Ligne 1, Colonne 1.
Assembly [ServiceBrokerInterface] ne peut pas être migré vers SQL Server 2017. Pour plus d’informations,
voir : Ligne 1, Colonne 1.
Assembly [SMSSQLCLR] ne peut pas être migré vers SQL Server 2017. Pour plus d’informations, voir : Ligne
1, Colonne 1.
Assembly [StateSysSqlClr] ne peut pas être migré vers SQL Server 2017. Pour plus d’informations, voir :
Ligne 1, Colonne 1.
État
Les messages d’information sont de par leur conception. Bien que les assemblys soient marqués comme NON
SÉCURISÉs, ils sont gérés correctement. Vous pouvez ignorer ces messages en toute sécurité et continuer à
exécuter la mise à niveau de la base de données.
Par défaut, toutes les bases de données Configuration Manager doivent avoir l’option Fiable définie sur True
dans les propriétés de la base de données. Il s’agit d’une condition requise pour Configuration Manager et pour
CLR Strict Security que la fonctionnalité fonctionne correctement.
Pour vérifier ce paramètre, ouvrez la fenêtre Propriétés de la base de données, sélectionnez la page Options
dans le volet de navigation, puis recherchez la ligne Fiable dans la liste Autres options.
SQL Server assertion en bloc lorsque vous essayez
d’exécuter une instruction d’insertion en bloc ou
BCP
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez d’exécuter une Bulk Insert ou
plusieurs BCP opérations.
Version du produit d’origine : SQL Server 2008 R2 Enterprise, SQL Server 2008 Enterprise
Symptômes
Les serveurs A et B exécutent Microsoft SQL Server 2008 ou SQL Server 2008 R2.
Vous pouvez configurer la mise en miroir de bases de données entre le serveur A et le serveur B.
Vous exécutez une BULK INSERT ou BCP plusieurs instructions sur la base de données principale.
NOTE
Par défaut, CHECK_CONSTRAINTS l’option est définie sur Off lorsque vous exécutez une ou plusieurs
BULK INSERT BCP instructions.
La mise en miroir de base de données est interrompue et la session de mise en miroir de base de
données entre dans l’état SUSPENDED.
Dans ce scénario, une assertion se produit sur le serveur miroir. Par conséquent, un fichier de mini-vidage est
créé dans le SQL Server journal. En outre, l’erreur suivante s’SQL Server journal des erreurs sur le serveur
miroir :
NOTE
Vous devez réinitialiser la mise en miroir de bases de données pour résoudre ce problème.
Cause
Ce problème se produit car les informations de compatibilité de verrouillage dans le journal des transactions de
la base de données principale ne sont pas transférées vers le serveur miroir.
Pour contourner ce problème, exécutez la ou l’instruction sur la base de données BULK INSERT principale à l’aide
de BCP CHECK_CONSTRAINTS l’option ON.
NOTE
CHECK_CONSTRAINTS L’option ON ralentit les performances. Toutefois, l’affirmation de verrouillage sur le serveur miroir ne
se produit pas.
Au cours BULK INSERT BCP d’une ou d’une opération, une transaction enfant éteint CHECK_CONSTRAINTS l’option.
Cette transaction enfant utilise un verrou compatible avec les verrous de transaction parent. Les informations de
compatibilité sont stockées dans le journal des transactions de la base de données principale. Par conséquent, la
demande de verrouillage de transaction enfant est accordée sur la base de données principale.
Toutefois, ces informations de compatibilité ne sont pas transférées vers le serveur miroir. Par conséquent, la
demande de verrouillage de transaction enfant est incompatible avec les verrous de transaction parent sur le
serveur miroir. Ce scénario entraîne l’affirmation sur le serveur miroir.
Échec de l’agent ASR ou d’une autre sauvegarde
VSS non-composant pour un serveur hébergeant
SQL Server 2008 R2
Cet article vous aide à contourner le problème dans lequel une sauvegarde VSS non-composant, telle que
l’agent ASR, échoue pour un serveur qui héberge SQL Server 2008 R2.
Version du produit d’origine : SQL Server 2008, SQL Server 2008 R2
Symptômes
Vous utilisez Microsoft SQL Server 2008 ou SQL Server 2008 R2.
Vous démarrez une sauvegarde VSS non-composant d’un volume qui héberge SQL Server fichiers. Par
exemple, vous utilisez Microsoft Azure Agent de récupération de site.
Dans ce cas, vous remarquez que la sauvegarde VSS échoue en raison d’une erreur SQLServerWriter, même si
le journal d’erreurs SQL Server signale une sauvegarde réussie.
SQLServerWriter signale le résultat suivant dans la sortie « vssadmin list writers » :
Writer name: 'SqlServerWriter'

Writer ID: {ID}
ID d’instance de rédacteur : {ID}
État : [11] Échec
Dernière erreur : erreur non réessayable
NOTE
L’état ou l’erreur précédent est très générique. Par conséquent, il ne fournit pas suffisamment d’informations pour vous
laisser identifier de manière sélective un scénario donné. Cette situation est significative dans le contexte de sauvegardes
non-composants sur SQL Server 2008 ou R2.
En outre, un suivi SQLServerWriter signale les éléments suivants :
[-,0x00c390:0xbb80:0x0eba42eb] sqlwriter.pdf\sqllib\FileName(LineNumber) :
FrozenDatabase::GetNextPartialInfo: VDI::GetCommand failed with error 0x8077000e
[-,0x00c390:0xbb80:0x0eba42eb] EXIT {DatabaseName::GetNextPartialInfo}: hr: 0x8077000e
[-,0x00c390:0xbb80:0x0eba42eb] sqlwriter.pdf\sqlwriter\FileName(LineNumber) : CSqlWriter::P
ickupDifferentialInfo : Le maître de base de données de l’instance de serveur CGLONCSQL01 n’a pas réussi à
émaner les informations de fichier. hr = 0x8077000e
[-,0x00c390:0xbb80:0x0eba42eb] sqlwriter.pdf\sqlwriter\FileName(LineNumber) : CSqlWriter::P
ickupDifferentialInfo: Throwing HRESULT code 0x8077000e. Code HRESULT précédent = 0x8077000e
[-,0x00c390:0xbb80:0x0eba42eb] sqlwriter.pé\sqlwriter\FileName(LineNumber) : CSqlWriter::P
ickupDifferentialInfo : EXCEPTION HRESULT capturée : hr : 0x8077000e
[-,0x00c390:0xbb80:0x0eba42eb] EXIT {CSqlWriter::P ickupDifferentialInfo}: hr: 0x8077000e
[-,0x00c390:0xbb80:0x0eba42eb] sqlwriter.pé\sqlwriter\FileName(LineNumber) : STDMETHODCALLTYPE
CSqlWriter::OnPostSnapshot : Échec de la sélection des informations de fichier à partir des serveurs de base
de données. hr = 0x8077000e
CSqlWriter::OnPostSnapshot: Throwing HRESULT code 0x8077000e. Code HRESULT précédent =
0x8077000e
CSqlWriter::OnPostSnapshot: EXCEPTION HRESULT CAUGHT: hr: 0x8077000e
[-,0x00c390:0xbb80:0x0eba42eb] Entrez {Snapshot::~Snapshot}:
Il n’existe aucun correctif SQL Server 2008 ou SQL Server 2008 R2. This issue was fixed in the initial release
(RTM) of SQL Server 2012. Étant donné que SQLServerWriter est un composant partagé, la mise à niveau des
composants partagés avec une version majeure ultérieure de SQL Server remplace SQL Server 2008 ou SQL
Server 2008 R2 SQLServerWriter par une version plus récente qui contient le correctif.
Dans les cas où SQL Server 2008 ou SQL Server 2008 R2 rencontre ce problème, nous vous suggérons
d’installer une édition gratuite d’une version SQL Server récente, telle que SQL Server Express Edition. (Voir la
section Plus d’informations sur la version exacte à utiliser, en fonction de la version du système d’exploitation).
Pour ce faire, sélectionnez Mettre à niveau les fonctionnalités par tagées uniquement dans la page
Sélectionner une instance de l SQL Server Express’installation.
Cette méthode permet de mettre à niveau tous les composants partagés vers la version SQL Server utilisée.
Cela signifie que le même service SQL Server VSS Writer qui 2008 ou 2008 R2 de l’auteur exécute désormais la
version SQL Server la plus récente à partir de SQL Express. La version la plus récente est à compatibilité avec les
versions précédentes.
Cette méthode vous permet également d’installer SQL Server mises à jour cumulatives pertinentes pour la
version de mise à niveau de SQL Express. Par exemple, vous pouvez installer SQL Server mises à jour
cumulatives 2014 ou SQL Server 2017 pour maintenir SQLServerWriter à jour selon les besoins. Pour plus
d’informations, voir FIX: Back up a SQL Server database by using a VSS Backup application may fail after
installing SQL Server
SQL Server 2016 et SQL Server 2017 Express Edition nécessitent Windows Server 2012 version
ultérieure ou ultérieure, ou Windows 8 ou version ultérieure.
Si vous utilisez Windows Server 2008 ou Windows Server 2008 R2 avec SQL Server 2008 ou SQL Server
2008 R2, vous pouvez utiliser SQL Server 2014 Service Pack 3 (SP3) Express Edition pour mettre à niveau
les composants partagés : téléchargez Microsoft SQL Server 2014 SP3 Express.
Lorsque vous mettre à niveau les composants partagés, tous les sous-composants sont mis à niveau en
plus de SQLServerWriter. Par exemple : les services d’intégration, Master Data Services (MDS), SQL
Server Management Studio (SSMS), SQL Server Data Tools (SSDT) et SQL Server Books Online sont mis à
niveau.
Une autre solution de contournement consiste à mettre à niveau les composants partagés et à éviter le
problème en installant dummy une instance SQL Express d’une version majeure ultérieure. Lorsque vous
installez une version majeure ultérieure de SQL Server instance, les composants partagés sont également
mis à niveau. Vous pouvez ensuite désactiver ou désinstaller l’instance factice. Toutefois, l’approche la
plus propre consiste à mettre à niveau les composants partagés.
Références
Découvrez la description de la terminologie standard utilisée pour décrire les mises à jour logicielles Microsoft.
Les sauvegardes VSS non-composants telles que les
travaux Azure Site Recovery échouent sur les
serveurs hébergeant SQL Server instances avec
AUTO_CLOSE DBs
Cet article vous aide à résoudre le problème où les sauvegardes vsS (Volume Shadow Copy Service) non-
composants telles que les travaux Azure Site Recovery (ASR) échouent sur les serveurs qui hébergent des
instances SQL Server avec des AUTO-CLOSE DB.
Version du produit d’origine : SQL Server 2017 sur Windows, SQL Server 2016, SQL Server 2014, SQL Server
2012, SQL Server 2008 R2, SQL Server 2008, SQL Server dans la VM - Windows
Symptômes
Vous avez un serveur qui exécute n’importe quelle version de Microsoft SQL Server.
Cette SQL Server instance héberge des bases de données dont l’option AUTO-CLOSE est définie.
Vous exécutez une sauvegarde VSS non-composant (par exemple, à l’aide de l’agent ASR) sur les volumes de
ce serveur qui héberge des fichiers de base de données SQL Server de données.
Dans ce cas, vous remarquez que la sauvegarde VSS échoue et déclenche l’entrée suivante dans le journal des
applications :
Un rédacteur VSS a rejeté un événement avec 0x800423f4, le rédacteur a connu une erreur non temporaire.
Si le processus de sauvegarde est retenté, l’erreur est susceptible de se reproduire. Les modifications
apportées par l’auteur aux composants du rédacteur lors de la gestion de l’événement ne seront pas
disponibles pour le demandeur. Consultez le journal des événements pour les événements connexes de
l’application hébergeant l’enregistreur VSS.
Opération :
PostSnapshot, événement
Contexte :
Contexte d’exécution : Rédacteur
ID de classe writer : {ID}
Writer Name: SqlServerWriter
Writer Instance Name: Microsoft SQL Server 2012:SQLWriter
ID d’instance writer : {ID}
Ligne de commande : « C:\Program Files\Microsoft SQL Server\90\Shared\sqlwriter.exe »
ID de processus : xxx »
Cause
Ce problème se produit car SQL Server SQLWriter ne gère actuellement pas correctement les bases de données
AUTO-CLOSE dans les demandes de sauvegarde VSS en mode non-composant.
En tant qu’atténuation à court terme, nous vous recommandons de désactiver l’option AUTO-CLOSE sur toutes
les bases de données de toutes les instances SQL Server hébergées sur des serveurs qui reçoivent des
sauvegardes VSS non-composant. En règle générale, les machines virtuelles Azure qui exécutent SQL Server
sont affectées, car l’agent ASR exécute ces sauvegardes non-composants.
Par défaut, la propriété est définie sur OFF dans AUTO_CLOSE SQL Server Understanding SQL Express
behavior: Idle time resource usage, AUTO_CLOSE and User Instances. Si vous êtes sûr de n’avoir pas
activé ce paramètre manuellement sur les serveurs qui pourraient être affectés par ce problème,
examinez les instances de SQL Server Express qui ont pu être installées en mode silencieux en tant que
composants d’autres applications.
Pour obtenir la liste des bases de données dont le mode est activé, exécutez la requête sur AUTO_CLOSE
une instance SQL Server données :
select name,database_id,is_auto_close_on from sys.databases where is_auto_close_on=1
Pour modifier le paramètre, reportez-vous à la section des options ALTER DATABASE SET de la
AUTO_CLOSE documentation en ligne pour TSQL.
Pour mettre cette option hors service, exécutez la commande suivante dans la sqlcmd.exe client
par défaut (par exemple, pour la base de données Ma base de données) :
alter database <myDatabase> set auto_close OFF
La modification prend effet immédiatement. Pour inverser cette modification, exécutez la

commande suivante :
alter database <myDatabase> set auto_close ON
Si vous préférez une méthode GUI, utilisez options des propriétés de base de > données SQL Server
Management Studio.
La sauvegarde d’une base SQL Server à l’aide d’une
application de sauvegarde VSS peut échouer pour
certaines bases de données
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez des applications VSS (Volume
Shadow Copy Services) pour protéger vos bases de données SQL Server données.
Symptômes
Lorsque vous utilisez des applications VSS (Volume Shadow Copy Services) pour sauvegarder vos bases de
données SQL Server, l’opération de sauvegarde peut échouer si le nom de la base de données contient des
espaces de début ou de fin ou des caractères non imprimables.
Le même problème peut également se produire lorsque vous essayez de back up un volume qui contient l’une
de ces bases de données.
Cause
Les applications de sauvegarde basées sur VSS utilisent (SQLWriter) pour interroger les informations du
composant de métadonnées writer afin de déterminer les fichiers de base de données à SQLServerWriter
sauvegarder. Le composant de métadonnées Writer est créé par SQLWriter à l’aide de l’API VSS et contient trois
ensembles de données :
1. Informations d’identification et de classification des rédacteurs
2. Spécifications au niveau du rédacteur
3. Données de composant
Lorsqu’un nom de base de données contient des espaces de début ou de fin ou des caractères non imprimables,
ce document peut ne pas être créé correctement. Par conséquent, les applications basées sur VSS ne pourront
pas la back up de ces bases de données ou des volumes qui contiennent ces bases de données.
Résolution
Renommons toutes les bases de données qui contiennent des espaces de début ou de fin ou des caractères non
imprimables dans leur nom. Vous pouvez utiliser la requête suivante pour localiser la présence de ces caractères
à l’avant ou à la fin des noms :
SELECT database_id as DatabaseID, '##'+name+'##' as DatabaseName from sys.databases
Exemple de sortie :
DatabaseID DatabaseName
8 ##AdventureWorks## -- DB name is fine
15 ## DBWithLeadingSpace## -- DB name contains leading spaces
17 ##DBWithTrailingSpace ## -- DB name contains trailing spaces
NOTE
Dans la requête ci-dessus, si le nom de la base de données contient des caractères non imprimables, ils peuvent être
imprimés en tant qu’espaces ou indésirables.
Les rédacteurs (comme SQL Writer) ajoutent des composants à l’aide de
IVssCreateWriterMetadata::AddComponent, en spécifiant les informations suivantes sur les composants :
Type
Nom
Chemin d’accès logique (le cas caser)
Fonctionnalité prise en charge
Sélection
Métadonnées à utiliser par l’auteur lors de la restauration
Informations d'affichage
Informations de notification
C (Volume Shadow Copy Service) sont des collections de fichiers qui forment une unité logique à des fins de
sauvegarde et de restauration. Tous les fichiers d’un composant (à l’exception de ceux explicitement exclus)
doivent être restaurés en tant qu’unité.
Pour plus d’informations, voir métadonnées VSS.
Vous pouvez utiliser une ou plusieurs des méthodes suivantes pour déterminer si vous êtes en cours d’exécution
dans ce problème :
Diverses applications de sauvegarde peuvent créer des messages personnalisés SqlServerWriter
concernant (ou SQLWriter) in trouvé.
Lorsque vous exécutez à partir d’une invite de commandes sur l SQL Server ordinateur cible, vous ne
voyez SqlServerWriter pas dans la sortie.
rédacteurs de liste vssadmin
Résolution des problèmes SQL Server opérations
de sauvegarde et de restauration
Cet article présente les informations suivantes Microsoft SQL Server opérations de sauvegarde et de
restauration :
Références à SQL Server Books Online età d’autres documentations sur les rubriques de sauvegarde et
de restauration.
Les problèmes potentiels que vous pouvez rencontrer et les résolutions que vous pouvez essayer lorsque
vous travaillez avec des opérations de sauvegarde ou de restauration.
Forum Aux Questions (FAQ) sur les opérations de sauvegarde et de restauration.
Rubriques de référence pour les SQL Server de sauvegarde et de

restauration
Pour plus d’informations sur les opérations de sauvegarde et de restauration, consultez les rubriques
suivantes dans Books Online.
Sauvegarder et restaurer des bases de données SQL Server : cette rubrique aborde les concepts des
opérationsde sauvegarde et de restauration pour les bases de données SQL Server, fournit des liens
vers des rubriques supplémentaires et fournit des procédures détaillées sur la façon d’effectuer
diverses sauvegardes ou tâches de restauration (telles que la vérification des sauvegardes, la
sauvegarde à l’aide de T-SQL ou de SSMS, etc.). Il s’agit de la rubrique parente à ce sujet dans SQL
Server documentation.
Le tableau suivant répertorie les rubriques supplémentaires que vous souhaitez peut-être consulter pour
les tâches spécifiques liées aux opérations de sauvegarde et de restauration.
RÉF ÉREN C E P EUT F O URN IR DES RÉP O N SES P O UR
BACKUP (Transact-SQL) Fournit des réponses aux questions de base relatives à la

sauvegarde. Fournit des exemples de différents types
d’opérations de sauvegarde et de restauration.
Périphériques de sauvegarde (SQL Server) Fournit une excellente référence pour comprendre les
différents périphériques de sauvegarde, la sauvegarde
d’un partage réseau, le stockage d’objets blob Azure et
les tâches connexes.
Modèles de récupération (SQL Server) Couvre en détail les différents modèles de récupération :
simple, complet et journalisé en bloc. Fournit des
informations sur l’impact du modèle de récupération sur
les sauvegardes.
RÉF ÉREN C E P EUT F O URN IR DES RÉP O N SES P O UR
Restauration & sauvegarde : bases de données système Aborde les stratégies et explique ce que vous devez
(SQL Server) savoir lorsque vous travaillez sur des opérations de
sauvegarde et de restauration de bases de données
système.
Vue d’ensemble de la restauration et de la récupération Aborde l’impact des modèles de récupération sur les
(SQL Server) opérations de restauration. Vous devez passer en revue
ce point si vous avez des questions sur la façon dont le
modèle de récupération d’une base de données peut
affecter le processus de restauration.
Gérer les métadonnées lors de la mise à disposition Diverses considérations doivent être à prendre en
d’une base de données sur un autre serveur compte lorsqu’une base de données est déplacée ou que
vous rencontrez des problèmes affectant les connexions,
le chiffrement, la réplication, les autorisations, etc.
Working with Transaction Log Backups Présente des concepts sur la façon de back up and
restore (apply) transaction logs in the full and bulk-
logged recovery models. Explique comment prendre des
sauvegardes de routine des journaux de transactions
(sauvegardes des journaux) pour récupérer des données.
SQL Server Sauvegarde gérée vers Microsoft Azure Présente la sauvegarde gérée et les procédures
associées.
Scénarios de problèmes d SQL Server de sauvegarde et de

restauration
Scénario 1 : l’opération de sauvegarde ou de restauration prend beaucoup de temps
Les opérations de sauvegarde et de restauration sont intensives en opérations d’I/S. Le débit de
sauvegarde/restauration dépend de l’optimisation du sous-système d’opérations d’entreprise sous-jacent
pour gérer le volume d’opérations d’opérations d’entreprise. Si vous pensez que les opérations de
sauvegarde sont suspendues ou prennent beaucoup de temps, vous pouvez utiliser une ou plusieurs des
méthodes suivantes pour estimer le temps d’exécution ou pour suivre la progression des opérations de
sauvegarde et de restauration :
Le journal des SQL Server contient des informations sur les opérations de sauvegarde et de
restauration passées. Vous pouvez utiliser ces détails pour estimer le temps nécessaire à la
restauration de la base de données dans son état actuel. Voici un exemple de sortie du journal des
erreurs :
RESTORE DATABASE a correctement traitée 315 pages en 0,372 seconde (6,604 Mo/s)
Dans SQL Server 2016 et versions ultérieures, vous pouvez utiliser XEvent
backup_restore_progress_trace pour suivre la progression des opérations de sauvegarde et de
restauration.
Vous pouvez également utiliser la colonne percent_complete de sys.dm_exec_requests pour
suivre la progression des opérations de sauvegarde et de restauration en cours.
Les informations de débit liées aux opérations de sauvegarde et de restauration peuvent être
mesurées à l’aide des compteurs de l’écran de performance Débit de l’appareil en octets/s et débit
de sauvegarde/restauration/s. Pour plus d’informations, SQL Server, Backup Device Object.
Comment interroger la progression du processus de sauvegarde en cours d’exécution dans SQL
Server
Fonctionnement : que fait la restauration/sauvegarde ? Ce billet de blog peut vous aider à mieux
comprendre l’étape actuelle des opérations de sauvegarde ou de restauration.
Éléments à vérifier
1. Vérifiez si vous rencontrez l’un des problèmes connus répertoriés dans le tableau suivant. Envisagez si
vous devez implémenter les modifications ou appliquer les correctifs et les meilleures pratiques abordés
dans les articles correspondants.
L IEN EN L IGN E B A SE DE C O N N A ISSA N C ES O U L IVRES EXP L IC AT IO N ET A C T IO N S REC O M M A N DÉES
Optimisation des performances de sauvegarde et de La rubrique Books Online couvre différentes meilleures
restauration dans SQL Server pratiques que vous pouvez utiliser pour améliorer les
performances des opérations de
sauvegarde/restauration. Par exemple, vous pouvez
attribuer le privilège SE_MANAGE_VOLUME_NAME au
compte Windows qui exécute SQL Server pour permettre
l’initialisation instantanée des fichiers de données. Cela
peut produire des gains de performances significatifs.
2920151 correctifs et mises à jour recommandés pour Les correctifs système actuels peuvent inclure des
les clusters de Windows Server 2012 R2 correctifs pour les problèmes connus au niveau du
système qui peuvent entraîner des problèmes de
2822241 Windows 8 et Windows Server 2012 de mise à performances qui affectent des programmes tels que
jour : avril 2013 SQL Server. L’installation de ces mises à jour permet
d’éviter ces problèmes.
2878182 correctif : les processus en mode utilisateur Les opérations de sauvegarde sont intensives en E/S et
dans une application ne sont pas résponsibles sur les peuvent être affectées par ce bogue. Appliquez ce
serveurs qui s’exécutent Windows Server 2012 correctif pour éviter ces problèmes.
309422 choisir un logiciel antivirus à exécuter sur des Le logiciel antivirus peut contenir des verrous sur des
ordinateurs qui exécutent des SQL Server fichiers .bak. Cela peut affecter les performances des
opérations de sauvegarde et de restauration. Suivez les
instructions de cet article pour exclure les fichiers de
sauvegarde des analyses antivirus.
2820470 message d’erreur Différé lorsque vous essayez

d’accéder à un dossier partagé qui n’existe plus dans
Windows 8, Windows 8.1, Windows Server 2012 ou
Windows Server 2012 R2
967351 un fichier fortement fragmenté dans un volume

NTFS peut ne pas dépasser une certaine taille
304101 sauvegarde échoue lorsque vous sauvegardez

un volume système important
L IEN EN L IGN E B A SE DE C O N N A ISSA N C ES O U L IVRES EXP L IC AT IO N ET A C T IO N S REC O M M A N DÉES
2455009 FIX : performances lentes lorsque vous La présence de nombreux fichiers journaux virtuels peut
récupérez une base de données s’il existe de nombreux affecter le temps nécessaire à la restauration d’une base
fichiers VLF dans le journal des transactions dans SQL de données. Cela est particulièrement vrai lors de la
Server 2005, dans SQL Server 2008 ou dans SQL Server phase de récupération de l’opération de restauration.
2008 R2 Pour plus d’informations sur les autres problèmes
possibles qui peuvent être causés par la présence de
nombreux fichiers VLF, reportez-vous aux opérations de
base de données qui prennent beaucoup de temps, ou
elles déclenchent des erreurs lorsque le journal des
transactionscontient de nombreux fichiers journaux
virtuels.
Une opération de sauvegarde ou de restauration sur un Isolez le problème au réseau en essayant de copier un
emplacement réseau est lente fichier de même taille sur l’emplacement réseau à partir
du serveur qui exécute SQL Server. Vérifiez les
performances.
2. Recherchez d’autres messages d’erreur dans SQL Server journal des erreurs et Windows journal des
événements pour plus de pointeurs sur la cause du problème.
3. Si vous utilisez des logiciels tiers ou des plans de maintenance de base de données pour effectuer
plusieurs sauvegardes en même temps, pensez à modifier les planifications afin de réduire la contention
sur le lecteur sur lequel les sauvegardes sont écrites.
4. Travaillez avec votre administrateur Windows pour vérifier les mises à jour du microprogramme de votre
matériel.
Scénario 2 : échec des opérations de sauvegarde ou de restauration qui utilisent des
applications de sauvegarde tierces
SQL Server fournit une API nommée VDI (Virtual Backup Device Interface). Cette API permet aux éditeurs
de logiciels indépendants d’intégrer des SQL Server dans leurs produits afin de prendre en charge les
opérations de sauvegarde et de restauration. Ces API sont conçues pour fournir une fiabilité et des
performances maximales et pour prendre en charge la gamme complète des fonctionnalités de
sauvegarde et de restauration SQL Server de données. Cela inclut la gamme complète des fonctionnalités
de capture instantanée et de sauvegarde à chaud.
Étapes communes de dépannage
Pour les versions antérieures à SQL Server 2012, assurez-vous que le service SQLWriter est
démarré et que le compte de démarrage est définie sur Système local. Assurez-vous également
que la connexion NT AUTHORITY\SYSTEM existe dans SQL Server et qu’elle fait partie du rôle
serveur sysadmin de l’instance sur laquelle les sauvegardes sont effectuées.
Pour SQL Server 2012 et versions ultérieures, une nouvelle connexion nommée [NT
SERVICE\SQLWriter] est créée et mise en service en tant que connexion lors de l’installation.
Assurez-vous que cette connexion existe dans SQL Server et fait partie du rôle serveur sysadmin.
Assurez-vous que SqlServerWriter est répertorié lorsque la commande VSSADMIN LIST WRITERS
est exécuté à une invite de commandes sur le serveur qui exécute SQL Server. Ce rédacteur doit
être répertorié en tant qu’auteur et doit être dans l’état stable pour permettre aux sauvegardes
VSS de se terminer correctement.
Pour des pointeurs supplémentaires, vérifiez les journaux du logiciel de sauvegarde correspondant
et leurs sites de support.
SY M P TÔ M ES O U SC ÉN A RIO A RT IC L E DE L A K B
Échec des sauvegardes des bases de données 2987610 fix : Erreur lorsque vous back up a database
sensibles à la cas that has case-sensitive collation by using VSS in SQL
Server 2012 SP2
Les sauvegardes tierces réalisées à l’aide du rédacteur 2987610 fix : Erreur lorsque vous back up a database
VSS peuvent échouer et renvoyer des erreurs 8229. that has case-sensitive collation by using VSS in SQL
Server 2012 SP2
Comprendre le fonctionnement de la sauvegarde Fonctionnement : SQL Server - Ressources de

VDI sauvegarde VDI (VSS)
Azure Site recovery agent reports failure Échec de l’agent ASR ou d’une autre sauvegarde VSS
non-composant pour un serveur hébergeant SQL
Server 2008 R2
Autres ressources
How It Works: How many databases can be backed up simultaneously?
Scénario 3 : échec des opérations de sauvegarde et de restauration en raison de problèmes
d’autorisations
Les problèmes de propriété et d’autorisation sur le fichier physique de l’appareil de sauvegarde peuvent
interférer avec les opérations de sauvegarde et de restauration. SQL Server être en mesure de lire et
d’écrire sur l’appareil. En outre, le compte sous lequel le service SQL Server s’exécute doit avoir des
autorisations d’écriture sur le lecteur ou sur le partage réseau utilisé pour les sauvegardes.
Choses à faire
Pour plus d’informations, consultez la rubrique Sauvegarde vers un partage réseau dans SQL Server
documentation.
SY M P TÔ M E C O M M EN TA IRES
SQL Server ou SQL’agent est en cours d’exécution sous Accordez des autorisations sur le compte d’ordinateur
un compte système local et les sauvegardes échouent. sur le partage Domain\ComputerName$.
Microsoft recommande d’utiliser des comptes de

domaine dédiés qui possèdent uniquement les privilèges
requis afin d’isoler les services.
Autres ressources
Répertorie toutes les autorisations de dossier partagé ou les autorisations NTFS (PowerShell)
Scénario 4 : échec de l’opération de restauration en raison de sauvegardes endommagées
Activez l’option CHECKSUM de sauvegarde lors de l’effectuer pour éviter la sauvegarde d’une base de
données endommagée. Pour plus d’informations, voir Possible Media Errors During Backup and Restore
(SQL Server). Vous pouvez également activer l’indicateur de suivi 3023 pour activer la reprise de contrôle
lorsque vous effectuez des sauvegardes à l’aide des outils de sauvegarde. Pour plus d’informations, voir
Comment activer l’option CHECKSUM si les utilitaires de sauvegarde n’exposent pas l’option.
Si les fichiers de sauvegarde sont endommagés, les opérations de restauration peuvent échouer et
générer des erreurs semblables à ce qui suit.
RESTORE a détecté une erreur sur la page (0:0) dans la base de données
ADDITIONAL INFORMATION: The media family on device <device name> ' is incorrectly formed. SQL
Server ne peut pas traiter cette famille de médias. RESTORE HEADERONLY se termine anormalement.
(Microsoft SQL Server, Erreur : 3241)
Choses à faire
Exécutez la commande suivante en remplaçant par le nom de votre base de données et vos <test>
chemins d’accès aux fichiers :
RESTORE DATABASE test='d:\test.bak'

WITH NO_CHECKSUM, FILE=1, REPLACE, CONTINUE_AFTER_ERROR,
MOVE 'test' TO 'C:\test.mdf',
MOVE 'test_log' TO 'C:\test_log.ldf'
Pour plus d’informations, consultez le contenu Books Online suivant :

Réponse aux erreurs SQL Server de restauration causées par des sauvegardes endommagées Nous vous
recommandons également d’exécuter CHECKDB sur la base de données une fois l’opération de
restauration terminée.
Scénario 5 : problèmes divers
M ESURES C O RREC T IVES O U IN F O RM AT IO N S

SY M P TÔ M E/ SC ÉN A RIO SUP P L ÉM EN TA IRES
Les sauvegardes peuvent échouer lorsque le suivi des Consultez les articles suivants de la Base de
changements est activé sur les bases de données et connaissances Microsoft :
renvoyer des erreurs semblables à ce qui suit : 2682488 CORRECTIF : échec de l’opération de
sauvegarde dans un SQL Server 2008, dans une
Erreur : 3999, Gravité : 17, État : 1. base de données SQL Server 2008 R2 ou dans
une base de données SQL Server 2012 après
< Time Stamp t> spid< spid > Failed to flush the avoir activé le suivi des changements
commit table to disk in dbid 8 due to error 2601. Vérifier 2603910 CORRECTIF : la sauvegarde échoue
lelog des erreurs dans SQL Server 2008, SQL Server 2008 R2 ou
SQL Server 2012 si vous activez le suivi des
changements sur la base de données
2522893 FIX : une opération de sauvegarde sur
une base de données SQL Server 2008 ou SQL
Server 2008 R2 échoue si vous activez le suivi des
changements sur cette base de données
Problèmes de restauration des sauvegardes de bases de Déplacer une base de données protégée TDE vers une
données chiffrées autre SQL Server
La tentative de restauration d’une sauvegarde CRM à 2567984 erreur « La base de données ne peut pas être
partir de l’édition Enterprise échoue sur une édition démarrée dans cette édition de SQL Server » lors de la
Standard restauration d’une base de données Microsoft Dynamics
CRM données
FAQ sur les SQL Server de sauvegarde et de restauration
Comment vérifier l’état des opérations de sauvegarde ?
Découvrez comment interroger la progression du processus de sauvegardeen cours d’exécution dans
SQL Server .
Que dois-je faire en cas SQL Ser ver de secours en cours de sauvegarde ?
Redémarrer les opérations de restauration ou de sauvegarde par redémarrage d’une opération de
restauration interrompue (Transact-SQL)
Puis-je restaurer des sauvegardes de base de données à par tir d’anciennes versions de
programmes sur des versions plus récentes, et inversement ?
SQL Server sauvegarde ne peut pas être restaurée par une version de SQL Server ultérieure à la
version qui a créé la sauvegarde. Pour plus d’informations, voir la prise en charge de la compatibilité.
Comment puis-je vérifier mes sauvegardes SQL Ser ver base de données ?
Consultez les procédures documentées dans RESTORE Statements - VERIFYONLY (Transact-SQL).
Comment puis-je obtenir l’historique de sauvegarde des bases de données SQL Ser ver ?
Découvrez comment obtenir l’historique de sauvegarde des bases de données dans SQL Server.
Puis-je restaurer des sauvegardes 32 bits sur des ser veurs 64 bits, et inversement ?
Oui. Dans la rubrique Back Up and Restore of SQL Ser ver Databases, le format de stockage sur
disque SQL Server est le même dans les environnements 64 bits et 32 bits. Par conséquent, les
opérations de sauvegarde et de restauration fonctionnent dans les environnements 32 bits et 64 bits.
Une sauvegarde créée sur une instance de serveur en cours d’exécution dans un environnement peut
être restaurée sur une instance de serveur en cours d’exécution dans l’autre environnement.
Références complémentaires
Planifier et automatiser des sauvegardes de bases de données SQL Server dans SQL Server Express
Comment back up SQL Server databases in all the instances on a server (PowerShell)
SQL Server enregistre une opération de sauvegarde
dans la table d’historique des jeux de sauvegarde
lorsque vous utilisez VSS pour sauvegarder des
fichiers sur un volume
Cet article décrit un comportement « par conception » qui se produit lorsque vous utilisez VSS pour la back up
files sur un volume.
Symptômes
Lorsque vous utilisez une application vsS (Volume Shadow Copy Service) pour sauvegarder des fichiers sur un
volume qui inclut des fichiers de base de données SQL Server, SQL Server enregistre une opération de
sauvegarde dans la backupset table d’historique. Ce comportement se produit même si vous n’avez pas
réellement back up les fichiers de base de données de SQL Server.
Cause
Ce comportement se produit car l’application VSS appelle le service SQLWriter sur le système pendant
l’opération de sauvegarde. Pour plus d’informations sur la façon dont les applications VSS interagissent avec
SQL Writer, voir SQL Server Back up Applications - Volume Shadow Copy Service (VSS) et SQL Writer.
Précautions à prendre si vous utilisez les entrées de la table

d’historique du jeu de sauvegarde pour la récupération des données
Si vous souhaitez utiliser des entrées dans la table d’historique pour la récupération des données, vous devez
vérifier que les entrées représentent des opérations de sauvegarde backupset de base de données réelles.
Vérifiez qu’une entrée représente une opération de sauvegarde de

base de données native (par opposition à une sauvegarde de capture
instantanée VSS)
Pour ce faire, exécutez l’instruction suivante :
USE msdb
GO
SELECT server_name, database_name, backup_start_date, is_snapshot, database_backup_lsn

FROM backupset
Dans le résultat, notez la database_backup_lsn colonne et la is_snapshot colonne. Une entrée qui représente
une opération de sauvegarde de base de données native présente les caractéristiques suivantes :
La valeur de la database_backup_lsn colonne n’est pas 0 .
La valeur de la is_snapshot colonne est 0 .
Vérifier que le jeu de sauvegarde ne présente aucune erreur

Pour ce faire, exécutez l’instruction suivante :
WITH backupInfo AS( SELECT database_name AS [DatabaseName],

name AS [BackupName], is_damaged AS [BackupStatus],
backup_start_date AS [backupDate],
ROW_NUMBER() OVER(PARTITION BY database_name
ORDER BY backup_start_date DESC) AS BackupIDForDB
FROM msdb..backupset) SELECT DatabaseName
FROM backupinfo WHERE BackupIDForDB = 1 and BackupStatus=1
Si cette requête renvoie des résultats, cela signifie que vous n’avez pas de bonnes sauvegardes de base de
données après la date signalée. Nous vous recommandons vivement d’effectuer une sauvegarde de base de
données complète dès que possible et de vérifier que la sauvegarde complète de la base de données est propre.
Propriété is_damaged de propriété

La table de la base de données backupset msdb contient une ligne pour chaque jeu de sauvegarde. La propriété
de la table indique si des dommages à la base de données ont été détectés lors de la création is_damaged
backupset de la sauvegarde. Par conséquent, la sauvegarde peut être endommagée et ne peut pas être restauré.
Comportement des sauvegardes compressées
lorsque vous les appendez à un jeu multimédia
existant
Cet article présente le comportement des sauvegardes compressées lorsque vous les appendez à un jeu
multimédia existant.
Résumé
L’une des principales restrictions liées aux sauvegardes compressées est que les sauvegardes compressées et
non compressées ne peuvent pas exister dans un jeu multimédia. Cette restriction est documentée dans :
Compression de sauvegarde (SQL Server).
Cet article complète cette documentation et fournit plus d’informations sur le comportement attendu des
sauvegardes compressées par rapport au paramètre de configuration par défaut du serveur de compression de
sauvegarde.
Lorsque vous appendez une sauvegarde compressée à un support existant, elle hérite du paramètre de
compression du jeu multimédia. Si vous vous appuyez sur le paramètre de compression de sauvegarde et que
vous êtes en attente d’un média existant, vous risquez de vous retrouver avec une sauvegarde dans un état
sp_configure de compression différent de celui prévu.
Cela n’est vrai que dans les circonstances suivantes :

Vous devez l’appender à un jeu multimédia existant.
Vous vous appuyez sur l’option sp_configure et ne spécifiez pas l’option de niveau
backup compression default WITH COMPRESSION d’instruction Backup.
Lorsqu’un jeu multimédia est créé, des informations sur le fait que cet ensemble de médias soit pour une
sauvegarde compressée ou une sauvegarde normale sont écrites dans le fichier d’en-tête multimédia.
Les sauvegardes prises dans un jeu multimédia existant peuvent coexister uniquement si le paramètre de
compression de ces sauvegardes est identique à celui du jeu multimédia. Les trois facteurs suivants affectent le
comportement des sauvegardes compressées :
1. SQL Server’option de configuration de l’ordinateur : compression de sauvegarde par défaut
2. Options de jeu de sauvegarde : COMPRESSION ou NO_COMPRESSION
3. Que vous appending à un jeu multimédia existant ou que vous écrivant la sauvegarde dans un nouveau jeu
multimédia. Pour les médias existants, un facteur supplémentaire à prendre en compte est de savoir si le jeu
multimédia contient actuellement une sauvegarde compressée ou non compressée.
Le tableau suivant récapitule le comportement des sauvegardes compressées en fonction des trois facteurs ci-
dessus.
A P P EN D TO M EDIA SET
B A C K UP, IN ST RUC T IO N N EW M EDIA SET A P P EN D TO M EDIA SET ( UN C O M P RESSED)
Options des instructions de L’ensemble de médias L’exsting Media Set dispose

sauvegarde existant dispose d’une d’une sauvegarde non
sauvegarde compressée compressée
Niveau d’instruction de Success Back up Opération réussie Erreur

sauvegarde avec compressed
COMPRESSION clause
Niveau d’instruction de Sauvegarde de la réussite : Erreur Opération réussie

sauvegarde avec non compressée
NO_COMPRESSION clause
Instruction de sauvegarde La compression des La sauvegarde de la réussite La sauvegarde de la réussite

sans clause de compression réussites dépend du sera compressée sera décompressée
au niveau de l’instruction sp_configure
backup compression de
réussite
Comme vous pouvez le voir dans le tableau ci-dessus, lorsque nous utilisons le paramètre de compression par
défaut sur le serveur et que nous l’appendons à un jeu multimédia existant, la sauvegarde n’échoue jamais en
raison d’une insérialisation des paramètres de compression. Il fonctionne mais hérite du paramètre dans l’en-
tête du jeu multimédia. Toutefois, si vous spécifiez la ou les options de votre instruction Backup, une erreur se
produit en cas d’insérialisation entre la sauvegarde stockée dans le jeu multimédia et la sauvegarde actuelle
prise en compte dans le paramètre de COMPRESSION NO_COMPRESSION compression.
NOTE
Vous pouvez trouver le paramètre actuel de l’option par défaut backup compression en exécutant la commande dans le
sp_configure SQL Server Management Studio. Si vous êtes en attente d’un média existant, vous pouvez obtenir les
informations d’en-tête à l’aide de la commande headeronly de restauration. Pour plus d’informations, voir la section
Exemples plus loin dans cet article.
Exemples : Voici un exemple de script pour démontrer le comportement dans différents cas. Le comportement
est le même, que la sauvegarde se trouve sur une bande ou sur un disque.
La valeur de compression est 0 .
-- Note compression value, by default it should be 0

sp_configure 'backup compression'
-- Initial Backup completes successfully
BACKUP DATABASE test TO DISK = N'E:\testbackup.bak' WITH FORMAT, INIT,
NAME = N'testbackup-Full Database Backup', SKIP,NOUNLOAD, STATS = 10
GO
-- Check the backup and the header, and see the Compressed column value, it is 0
restore headeronly from DISK = N'E:\testbackup.bak'
-- Now backup using "with compression" and it will fail
-- as backups ( compressed and non compressed cannot be mixed within the same media set )
BACKUP DATABASE test TO DISK = N'E:\testbackup.bak'
WITH NAME = N'testbackup-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
GO
Après avoir exécuté le script sql, vous pouvez recevoir le message d’erreur 3098 et 3013 :
Activer la compression de sauvegarde par défaut au niveau du serveur.
-- Turn on default backup Compression at the server level

sp_configure 'backup compression',1 'backup compression',1
go
reconfigure
go
-- The sp_configure 'default compression' as this point is set to 1.
-- Given that you may expect the backup to be compressed and it will be if it -- is a new media set
-- However if you backup and append to the same media set,
-- the backup works -- but results in an uncompressed backup
BACKUP DATABASE test TO DISK = N'E:\testbackup.bak'
WITH NAME = N'testbackup-Full Database Backup', SKIP,NOREWIND,NOUNLOAD, STATS = 10
GO
Traitement de deux pages pour la base de test données, test_log fichier sur le fichier 2.
BACKUP DATABASE a correctement traitée 162 pages en 6,211 secondes (0,203 Mo/s).
Vérifiez l’en-tête Sauvegarde et jeu multimédia.
-- Check the backup and meadia set header. You will see that though Server default is set to
compressed, the backup given that it is appended to an existing media set inherits the compression
setting of the media set itself
-- You may expect this to have failed with the same error as when specifying the WITH COMPRESSION
clause in the backup statement given that compressed and non compressed backups cannot co-exist in
the media set.
--If you create a new mediaset using the FORMAT option, then the current compression setting is
inherited
-- Create a new media set using FORMAT Or by specifying a new file
BACKUP DATABASE test TO DISK = N'E:\testbackup.bak' WITH FORMAT, INIT, NAME = N'testbackup-Full
Database Backup', SKIP,NOUNLOAD, STATS = 10
GO
-- Check the backup and meadia set header
-- If you use the with INIT, the backup sets are overwritten but the media header is not
-- Toggle the backup compression setting back to 0
sp_configure 'backup compression',0
go
reconfigure
go
-- backup to the same media set with INIT
BACKUP DATABASE test TO DISK = N'E:\testbackup.bak' WITH INIT,
GO
-- Check the backup and media set header
-- Note that even though we changed backup compression to 0, the old media header is preserved which
has it as 1, and the backup goes as compressed
Une autre limitation est que les sauvegardes compressées ne peuvent pas coexister avec les sauvegardes
NT :
-- Take an NT Backup
-- You can verify the backup Header now, see it is not a SQL backup
-- backup to the same media set with INIT and compression and you get the error message
BACKUP DATABASE test TO TAPE = N'\\.\Tape0' WITH INIT, COMPRESSION,
GO
Back up to the same media set without initializing and NO compression.
-- backup to the same media set without initializing and NO compression and the backups ( NT and non-
compressed backup) can co-exist
BACKUP DATABASE test TO TAPE = N'\\.\Tape0'
WITH NAME = N'testbackup-Full Database Backup', SKIP,NOUNLOAD, STATS = 10
GO
-- You can verify the backup Header now,see the SQL and the NT backup
Restore headeronly from tape = N'\\.\Tape0'
-- Forcing a Compressed backup on a tape with an NT backup results in the error below
BACKUP DATABASE test TO TAPE = N'\\.\Tape0' with compression,
NAME = N'testbackup1 Full Database Backup', SKIP,NOUNLOAD, STATS = 10
GO
Message d’erreur 3098 et 3013

La sauvegarde ne peut pas être effectuée car « COMPRESSION » a été demandée après la mise en
forme du média avec une structure incompatible. Pour l’appendre à ce jeu multimédia, omettez «
COMPRESSION » ou spécifiez « NO_COMPRESSION ». Vous pouvez également créer un nouvel
ensemble multimédia à l’aide de WITH FORMAT dans votre instruction BACKUP. Si vous utilisez WITH
FORMAT sur un jeu multimédia existant, tous ses jeux de sauvegarde seront remplacés.

BACKUP DATABASE se termine anormalement.
Configuration des autorisations pour accéder aux
données distantes à partir d’une source de données
OLEDB dans SQL Server
Cet article explique comment désactiver les requêtes ad hoc qui utilisent la ou les fonctionnalités dans
OPENROWSET OPENDATASOURCE SQL Server.

Résumé
Vous pouvez utiliser ou des instructions dans un serveur SQL comme méthode ad hoc pour connecter et
accéder aux données à partir d’un fournisseur OLEDB distant, y compris une instance SQL Server OPENROWSET
OPENDATASOURCE distante. Ces instructions peuvent être utilisées pour accéder aux données distantes à partir de
sources de données OLE DB uniquement lorsque l’option de RegistreDisallowAdhocAccess est explicitement
définie sur 0 pour le fournisseur spécifié et que l’option de configuration avancée des requêtes distribuées Ad
Hoc est activée. Lorsque ces options ne sont pas définies, le comportement par défaut n’autorise pas l’accès ad
hoc.
Cet article fournit des détails supplémentaires sur la configuration de DisallowAdhocAccess via les
paramètres du Registre, ainsi que sur SQL Server Management Studio et le comportement par défaut.
Désactiver les instructions Transact-SQL

NOTE
Accès ad hoc aux sources de données OLE BD distantes à l’aide et désactivé par défaut et aucune OPENROWSET
OPENDATASOURCE configuration supplémentaire n’est nécessaire. Vous devez utiliser les procédures ci-dessous
uniquement si cet accès à distance a été explicitement activé.
Vous pouvez désactiver les instructions Transact-SQL qui utilisent des chaînes de connexion ad hoc avec des
fournisseurs OLE DB spécifiques dans les fonctions et les fonctions à l’aide de l’une des procédures ci-dessous
OPENROWSET OPENDATASOURCE :
Spécifier DisallowAdHocAccess la propriété du fournisseur dans SQL Server Management Studio (SSMS)
1. Ouvrez SSMS et développez fournisseurs sous Serveurs liés
2. Cliquez pour sélectionner le fournisseur OLE DB que vous souhaitez utiliser, puis cliquez sur le bouton
Options du fournisseur.
3. Faites défiler vers le bas et sélectionnez la case à cocher Disallow adhoc access property et cliquez sur
OK .
Modifiez manuellement le Registre et ajoutez la DisallowAdHocAccess valeur.
NOTE
Les deux illustrations ne sont que des exemples de la façon dont vous pouvez modifier le fournisseur OLE DB pour ODBC
et pour SQL Server fournisseur OLE DB. Si vous souhaitez utiliser un autre fournisseur OLE DB, vous devez modifier
l’entrée de ce fournisseur.
IMPORTANT
Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des
problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, veillez à suivre ces
étapes scrupuleusement. Pour une meilleure protection, sauvegardez le registre avant de le modifier. Vous pouvez alors le
restaurer en cas de problème. Pour plus d’informations sur la façon de back up et restore the registry, voir How to back
up and restore the registry in Windows.
Spécifier la propriété DisallowAdHocAccess lorsque vous créez un

serveur lié
Lorsque vous créez un serveur lié sur un ordinateur qui exécute SQL Server, vous pouvez spécifier la propriété
du fournisseur DisallowAdHocAccess OLE DB. Pour cela, procédez comme suit :
1. Ouvrez SQL Server Entreprise, puis cliquez pour sélectionner le dossier Sécurité du serveur en question.
2. Cliquez avec le bouton droit sur l’entrée Serveurs liés, puis cliquez sur Nouveau serveur lié.
3. Cliquez pour sélectionner le fournisseur OLE DB que vous souhaitez utiliser, puis cliquez sur le bouton
Options du fournisseur.
4. Faites défiler l’écran vers le bas et cochez la case Disallow adhoc access property (Ne pas suivre la
propriété d’accès). Continuez à terminer la création de votre entrée de serveur lié.
Modifier manuellement le Registre et ajouter la valeur

DisallowAdHocAccess
Une fois qu’un serveur lié est enregistré, la propriété DisallowAdHocAccess ne peut être définie que par le biais
d’un paramètre de Registre.
NOTE
Les deux illustrations ne sont que des exemples de la façon dont vous pouvez modifier le fournisseur OLE DB pour ODBC
et pour SQL Server fournisseur OLE DB. Si vous souhaitez utiliser un autre fournisseur OLE DB, vous devez modifier
l’entrée de ce fournisseur.
IMPORTANT
restaurer en cas de problème. Pour plus d’informations sur la façon de la back up et de la restauration du Registre, cliquez
sur le numéro d’article suivant pour afficher l’article de la Base de connaissances Microsoft : 322756 How to back up and
restore the Registry in Windows
Ajouter la valeur DisallowAdHocAccess

Pour ajouter la DisallowAdHocAccess valeur, suivez les étapes suivantes :
1. Démarrez l’Éditeur du Registre.
2. Recherchez et cliquez sur la clé dans le Registre :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLSer ver\Providers<ProviderName>
Exemple
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers\MSDASQL
3. Dans le menu Edition, cliquez sur Ajouter une valeur, puis ajoutez cette valeur de Registre :
Value name: DisallowAdHocAccess

Data type: REG_DWORD
Radix: Hex
Value data: 1
4. Quittez l’Éditeur du Registre.
Activer l’accès à distance ad hoc

Après avoir garanti que l’option de configuration avancée des requêtes distribuées Ad Hoc est activée, vous
devez définir explicitement l’option de Registre sur 0 pour DisallowAdhocAccess le fournisseur spécifié.
Pour modifier une valeur DisallowAdHocAccess existante, suivez les étapes suivantes :
1. Démarrez l’Éditeur du Registre.
2. Recherchez, puis cliquez sur la valeur DisallowAdHocAccess sous la clé dans le Registre :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLSer ver\Providers<ProviderName>
Exemple
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers\Microsoft.ACE.OLEDB.12.0
3. Dans le menu Modifier, cliquez sur DWORD , tapez 1, puis cliquez sur OK .
4. Quittez l’Éditeur du Registre. Pour une instance nommée, la clé de Registre est différente
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<Instance Name>\Providers\<ProviderName> :
NOTE
Une modification de la valeur de DisallowAdHocAscess 1 à 0 ne nécessite pas de redémarrage du service SQL, alors
qu’une modification de 0 à 1 nécessite un redémarrage du service SQL pour que la modification prise en vigueur soit
effective.
Avec la propriété définie sur 1, SQL Server n’autorise pas l’accès ad hoc via le fournisseur OLE DB spécifié et les
fonctions par rapport à DisallowAdHocAccess OPENROWSET ces OPENDATASOURCE fonctions. Si vous essayez
d’appeler ces fonctions dans des requêtes ad hoc, vous recevez un message d’erreur semblable à ce qui suit :
Serveur : Msg 7415, Niveau 16, État 1, Accès ad hoc à la ligne 1 au fournisseur OLE DB «
Microsoft.Jet.OLEDB.4.0 » a été refusé. Vous devez accéder à ce fournisseur via un serveur lié.
En d’autres termes, avec la propriété définie sur 1 pour un fournisseur OLE DB spécifique, vous devez utiliser
une configuration de serveur lié prédéfinë pour le fournisseur DisallowAdHocAccess OLE DB spécifique. Vous ne
pouvez plus transmettre une chaîne de connexion ad hoc qui fait référence à ce fournisseur à la OPENROWSET ou
à la OPENDATASOURCE fonction.
Voir aussi
OPENDATASOURCE (Transact-SQL)
OPENROWSET (Transact-SQL)
OleDbProviderSettings.DisallowAdHocAccess, propriété
Considérations sur les paramètres derow et de
autoshrink dans SQL Server

Résumé
Les paramètres derow et de autoshrink par défaut sont appropriés sur de nombreux SQL Server système.
Toutefois, dans certains environnements, vous pouvez être dans l’devoir d’ajuster les paramètres derow
automatique et d’autoshrink. Cet article fournit des informations d’arrière-plan pour vous aider à choisir ces
paramètres pour votre environnement.
Voici quelques éléments à prendre en compte si vous décidez d’affiner vos paramètres derow automatique et
d’autoshrink.
Comment configurer les paramètres

1. Vous pouvez configurer ou modifier les paramètres derow et de auto-hrink à l’aide de l’une des façons
suivantes :
Instruction ALTER DATABASE
Utiliser les options File et Filegroup pour modifier les paramètres de croissance automatique
Utilisez les options SET pour configurer AUTO_SHRINK paramètres.
NOTE
Pour plus d’informations sur la définition de ces paramètres au niveau du fichier de base de données, voir Ajouter
des données ou des fichiers journaux à une base de données.
Vous pouvez également configurer l’option derow automatique lorsque vous créez une base de données.
Pour afficher les paramètres actuels, exécutez la commande Transact-SQL suivante :
sp_helpdb [ [ @dbname= ] 'name' ]
2. N’oubliez pas que les paramètres derow automatique sont par fichier. Par conséquent, vous devez les
définir à au moins deux endroits pour chaque base de données (un pour le fichier de données principal et
un pour le fichier journal principal). Si vous avez plusieurs données et/ou fichiers journaux, vous devez
définir les options sur chaque fichier. En fonction de votre environnement, vous pouvez terminer avec
différents paramètres pour chaque fichier de base de données.
Considérations à prendre en compte AUTO_SHRINK

AUTO_SHRINK est une option de base de données dans SQL Server. Lorsque vous activez cette option pour une
base de données, cette base de données peut être réduit par une tâche en arrière-plan. Cette tâche en arrière-
plan évalue toutes les bases de données qui répondent aux critères de réduction et de réduction des données ou
des fichiers journaux.
Vous devez évaluer attentivement la définition de cette option pour les bases de données dans SQL Server
instance. Les opérations de croissance et de réduction fréquentes peuvent entraîner divers problèmes de
performances.
1. Si plusieurs bases de données subissent des opérations de réduction et de croissance fréquentes, cela
entraîne facilement une fragmentation au niveau du système de fichiers. Cela peut avoir un impact grave
sur les performances. Cela est vrai que vous utilisez les paramètres automatiques ou que vous
augmentez et réduit manuellement les fichiers fréquemment
2. Une fois AUTO_SHRINK réduit les données ou le fichier journal, une opération DML ou DDL ultérieure
peut ralentir considérablement si l’espace est nécessaire et que les fichiers doivent augmenter.
3. La AUTO_SHRINK en arrière-plan peut prendre des ressources lorsqu’il existe de nombreuses bases de
données qui doivent être réduit.
4. La AUTO_SHRINK en arrière-plan doit acquérir des verrous et d’autres synchronisations qui peuvent être
en conflit avec d’autres activités d’application normales.
Envisagez de définir les bases de données à une taille requise et de les pré-agrandir. Laissez l’espace inutilisé
dans les fichiers de base de données si vous pensez que les modèles d’utilisation de l’application en auront
besoin à nouveau. Cela peut empêcher la réduction et la croissance fréquentes des fichiers de base de données.
Considérations pour AUTOGROW

Si vous exécutez une transaction qui nécessite plus d’espace de journal qu’il n’est disponible et que vous
avez désactivé l’option de croissance automatique pour le journal des transactions de cette base de
données, le temps nécessaire à la fin de la transaction inclut le temps nécessaire à l’expansion du journal
des transactions par le montant configuré. Si l’incrémentation de croissance est importante ou qu’un
autre facteur la prend beaucoup de temps, la requête dans laquelle vous ouvrez la transaction peut
échouer en raison d’une erreur de délai d’accès. Le même type de problème peut résulter d’unerow
automatique de la partie données de votre base de données.
Si vous exécutez une transaction importante nécessitant l’expansion du journal, les autres transactions
nécessitant une écriture dans le journal des transactions devront également attendre la fin de l’opération
de croissance.
Si vos fichiers journaux contiennent de nombreuses croissances, il se peut que le nombre de fichiers
journaux virtuels (VLF) soit trop élevé. Cela peut entraîner des problèmes de performances liés aux
opérations de démarrage/en ligne de base de données, à la réplication, à la mise en miroir et à la capture
des données de modification (CAS). En outre, cela peut parfois entraîner des problèmes de performances
avec les modifications de données.
NOTE
Si vous combinez les options derow automatique et d’autoshrink, vous risquez de créer une surcharge inutile. Assurez-
vous que les seuils qui déclenchent les opérations de croissance et de réduction n’entraînent pas de changements
fréquents de taille. Par exemple, vous pouvez exécuter une transaction qui entraîne une croissance du journal des
transactions de 100 Mo au moment de sa validation. Un certain temps après cela, l’autoshrink démarre et réduit le journal
des transactions de 100 Mo. Ensuite, vous exécutez la même transaction et le journal des transactions augmente de 100
Mo à nouveau. Dans cet exemple, vous créez une surcharge inutile et potentiellement une fragmentation du fichier
journal, qui peut avoir une incidence négative sur les performances.
Si vous augmentez votre base de données par petits incréments, ou si vous la développez puis la réduit, vous
pouvez vous retrouver avec une fragmentation de disque. La fragmentation du disque peut entraîner des
problèmes de performances dans certaines circonstances. Un scénario d’incréments de petite croissance peut
également réduire les performances de votre système.
Dans SQL Server, vous pouvez activer l’initialisation de fichier instantané. L’initialisation instantanée des fichiers
accélère les allocations de fichiers uniquement pour les fichiers de données. L’initialisation de fichier instantané
ne s’applique pas aux fichiers journaux. Pour plus d’informations, voir Initialisation de fichier instantané de base
de données.
Meilleures pratiques pour larow automatique et l’autoshrink

Pour un système de production géré, vous devez considérer la croissance automatique comme une
simple mesure d’urgence en cas de croissance inattendue. Ne gérez pas la croissance de vos données et
journaux quotidiennement avec la croissance automatique.
Vous pouvez utiliser des alertes ou des programmes de surveillance pour surveiller la taille des fichiers et
développer les fichiers de manière proactive. Cela vous aide à éviter la fragmentation et vous permet de
déplacer ces activités de maintenance vers des heures creuses.
La réduction automatique et la réduction automatique doivent être évaluées avec soin par un
administrateur de base de données formé ; Ils ne doivent pas être non ingérés.
Votre incrémentation de larow automatique doit être suffisamment grande pour éviter les pénalités de
performances répertoriées dans la section précédente. La valeur exacte à utiliser dans votre paramètre de
configuration et le choix entre une croissance en pourcentage et une croissance spécifique de la taille mo
dépendent de nombreux facteurs dans votre environnement. Une règle générale que vous pouvez utiliser
pour les tests consiste à définir votre paramètre derow automatique sur environ 1 à 8 la taille du fichier.
Activer le paramètre de chaque fichier pour empêcher qu’un fichier ne croît à un point où il utilise
<MAXSIZE> tout l’espace disque disponible.
Maintenez la taille de vos transactions aussi petite que possible pour empêcher la croissance non
planifiée des fichiers.
Pourquoi dois-je me soucier de l’espace disque si les paramètres de

taille sont automatiquement contrôlés ?
Le paramètre de croissance automatique ne peut pas augmenter la taille de la base de données au-delà
des limites de l’espace disque disponible sur les lecteurs pour lesquels les fichiers sont définis. Par
conséquent, si vous vous appuyez sur la fonctionnalité de chiffrement automatique pour dimensioner vos
bases de données, vous devez toujours vérifier indépendamment l’espace disque disponible. Le
paramètre derow automatique est également limité par le paramètre MAXSIZE que vous sélectionnez
pour chaque fichier. Pour réduire le risque de manque d’espace, vous pouvez surveiller le compteur
Performance Monitor SQL Server: Databases Object: Data File(s) Size (KB) et configurer une alerte pour le
moment où la base de données atteint une certaine taille.
La croissance non planifiée des données ou des fichiers journaux peut prendre de l’espace que d’autres
applications s’attendent à être disponibles et peut entraîner des problèmes pour ces autres applications.
L’incrémentation de croissance de votre journal des transactions doit être suffisamment importante pour
rester en avance sur les besoins de vos unités de transaction. Même si la croissance automatique est
allumée, vous pouvez recevoir un message vous messageant que le journal des transactions est plein, s’il
ne peut pas devenir suffisamment rapide pour répondre aux besoins de votre requête.
SQL Server ne teste pas constamment les bases de données qui ont atteint le seuil configuré pour
l’autoshrink. Au lieu de cela, il examine les bases de données disponibles et trouve la première qui est
configurée pour l’autoshrink. Elle vérifie cette base de données et la réduit si nécessaire. Ensuite, il attend
plusieurs minutes avant de vérifier la base de données suivante configurée pour l’autoshrink. En d’autres
termes, SQL Server ne vérifie pas toutes les bases de données en même temps et les réduit toutes en
même temps. Il fonctionne dans les bases de données de manière round robin pour échelonner la charge
sur une période de temps. Par conséquent, en fonction du nombre de bases de données sur une instance
de SQL Server spécifique que vous avez configurée pour la réduction automatique, la réduction de la
base de données peut prendre plusieurs heures à partir du moment où la base de données atteint le
seuil.
Références
Résoudre les problèmes d’un journal des transactions complet (erreur SQL Server 9002)
Initialisation de fichier instantané de base de données
SQL Server Guide de gestion et d’architecture des journaux de transactions
Gérer la taille du fichier journal des transactions
Considérations lors de l’utilisation du moteur SQL
Server Full-Text de recherche pour la langue
japonaise
Cet article décrit les considérations qui s’appliquent lorsque vous utilisez le moteur SQL Server Full-Text
recherche pour le japonais.
Introduction
En japonais, une expression peut être constituée de deux ou plusieurs mots sans espace entre ces mots. Dans
Microsoft SQL Server, lorsque vous utilisez le moteur de recherche SQL Server Full-Text pour effectuer une
recherche de préfixe pour une expression japonaise, le moteur de recherche Full-Text ne considère pas
l’expression comme un terme préfixe. Au lieu de cela, le moteur Full-Text recherche considère l’expression
comme des termes de mot. En effet, un mot est défini comme une chaîne de caractères sans espaces ni
ponctuation. En outre, le moteur de recherche fonctionne uniquement en mode de correspondance de préfixe.
Le moteur de recherche ne fonctionne pas en mode suffixe correspondant.
Par exemple, vous créez un tableau et insérez des expressions japonaises en exécutant les instructions suivantes
dans SQL Server :
CREATE TABLE test(c1 int PRIMARY KEY,c2 nvarchar(255))
INSERT test VALUES(1,N'添付テスト')

INSERT test VALUES(2,N'Fw: テスト')
INSERT test VALUES(3,N'KK-Information:テスト')
INSERT test VALUES(4,N'[Q] ポリシーテスト')
INSERT test VALUES(5,N'KK-Information:タイトルフィルタテスト２')
INSERT test VALUES(6,N'テスト')
INSERT test VALUES(7,N'フィルタテスト３')
INSERT test VALUES(8,N'テストフィルタ１')
INSERT test VALUES(9,N'RE: テストメール ')
INSERT test VALUES(10,N'テストメール ')
INSERT test VALUES(11,N'White Listテスト')
INSERT test VALUES(12,N'フィルタリングテスト')
CREATE FULLTEXT CATALOG test AS DEFAULT;

GO
CREATE FULLTEXT INDEX ON test(c2) KEY INDEX PK__<IndexName>;

GO
Ensuite, vous exécutez les trois requêtes suivantes :

Requête 1
SELECT * FROM test WHERE CONTAINS(c2, N'テスト')
Le résultat de la requête 1 est le suivant :
c1c2
2Fw : テスト
3KK-Information :テスト
6テスト
Requête 2
SELECT * FROM test WHERE CONTAINS(c2, 'テスト*')
c1c2
2 Fw : テスト
3 KK-Information :テスト
6 テスト
8 テストフィルタ１
9 RE : テストメール
10 テストメール
Requête 3
SELECT * FROM test WHERE CONTAINS(c2, '*テスト*')
c1c2
2 Fw : テスト
6 テスト
9 RE : テストメール
À partir des résultats des requêtes, vous pouvez voir que le résultat de la requête 2 est le même que le
résultat de la requête 3, car la requête Full-Text ne fonctionne pas en mode suffixe correspondant. En
outre, テスト est un jeton qui diffère de ou ポリシーテスト de dans les テスト correspondances.
Pour tokeniser des expressions, vous devez utiliser un décomposeur de mots pour la famille de langues.
Les coupureurs de travail utilisent des espaces et d’autres signes pour reconnaître les expressions. Par
conséquent, certaines expressions ne peuvent pas être reconnues par l’outil d’coupure de mots et ne
peuvent pas être recherchés à l’aide Full-Text moteur de recherche en japonais. Pour plus d’informations
sur les coupureurs de mots, consultez la rubrique Desserreurs de mots et des rechercheurs de mots dans
la section Référence.
La meilleure pratique pour utiliser le moteur de recherche Full-Text en japonais consiste à tester les
expressions pour voir si les expressions sont affectées par la limitation. Si une expression se compose de
mots sans espaces, vous ne pouvez pas utiliser la fonctionnalité Full-Text pour rechercher l’expression. Au
lieu de cela, vous pouvez utiliser le mot clé LIKE avec des caractères génériques. Toutefois, les
performances de l’opération sont inférieures à celles de la like recherche Full-Text recherche. Vous
devez tenir compte de l’impact sur les performances de votre application.
Voici quelques exemples de requêtes du mot clé pour like rechercher des expressions.
Requête 4
SELECT * FROM test WHERE c2 like 'テスト%'
Voici le résultat :
c1c2
6 テスト
Requête 5
SELECT * FROM test WHERE c2 like '%テスト%'
c1c2
1 添付テスト
2 Fw : テスト
4 [Q] ポリシーテスト
5 KK-Information :タイトルフィルタテスト２
6 テスト
7 « « 700000000000000000000000000 テスト
8 « « 8 « 800000000000000000000 テスト
9 RE テスト :
10 « 1000000000000000000000 テスト
11 テスト
12 フィルタリングテスト
NOTE
Si vous utilisez le moteur de recherche Full-Text dans SQL Server, vous trouverez plus d’informations sur le contenu d’un
index de texte intégral à l’aide de la requête suivante :
SELECT * FROM sys.dm_fts_index_keywords(db_id('test'), object_id('test'))

GO
mot clé display_term column_id document_count

0x00660077 fw 2 1
0x0069006E0066006F0072006D006100740069006F006E informations 2 2
0x006B006B kk 2
0x006C00690073007430C630B930C8 list
0x00770068006900740065 blanc 2 1
0x30BF30A430C830EB30D530A330EB30BF30C630B930C80032 2 1
0x30C630B930C8 2 3
0x30C630B930C830D530A330EB30BF0031 2 1
0x30C630B930C830E130FC30EB 2 2
0x30D530A330EB30BF30C630B930C80033 2 1
0x30D530A330EB30BF30EA30F330B030C630B930C8 2 1
0x30DD30EA30B730FC30C630B930C8 ポ00000000000
0x6DFB4ED830C630B930C8 添付 ' 2 1
0xFF FIN DU FICHIER 2 12
(14 lignes affectées)
Dans l’exemple de résultat, seules trois lignes contiennent le mot テスト . » Le Full-Text de recherche traite le
mot テスト « « comme un テストメール jeton différent du mot ». Pour plus d’informations sur le moteur SQL
Server Full-Text recherche, visitez les sites web Microsoft suivants :
Recherche en texte intégral
Formulaires de conditions de requête pris en charge (recherche en texte intégral)
Configurer & les & des recherche pour la recherche (SQL Server)
Classement des résultats de la requête de recherche (recherche en texte intégral)
CONTAINS (Transact-SQL)
sys.dm_fts_index_keywords (Transact-SQL)
SQL Server Équipe de conseil client
SQL Server service se crashe lorsque vous exécutez
une requête de serveur lié Oracle
Cet article vous aide à résoudre un problème qui peut se produire lorsque vous exécutez une requête de
serveur lié Oracle.
Symptôme
Vous installez SQL Server sur un ordinateur qui exécute Windows Server.
Vous créez un serveur lié pour une base de données Oracle.
Vous activez l’option Autoriser le traitement dans la boîte de dialogue Options pour le fournisseur de
serveur lié.
NOTE
Par défaut, l’option n’est pas sélectionnée.
Vous exécutez une requête de serveur lié à l’aide du fournisseur OraOLEDB.

Dans ce scénario, le service SQL Server se crashe et aucun résultat n’est renvoyé pour la requête. En outre, vous
pouvez rencontrer les problèmes suivants :
Le message d’erreur suivant s’Windows journal des événements système :
Le SQL Server service (MSSQLSERVER) s’est terminé de manière inattendue. Il a effectué cette ou ces
1 fois.
Un fichier minidump du processus SQL Server est généré avec une altération du tas et vous recevez un
message d’exception semblable à ce qui suit :
Dans minidump.mdmp, instruction d’assembly sur ntdll! RtlReportCriticalFailure+62 dans

C:\Windows\System32\ntdll.dll de Microsoft Corporation a provoqué une exception inconnue
(0xc0000374) sur le thread 235
Ou parfois, une autre exception peut se présenter dans lelog des erreurs :
SqlDumpExceptionHandler : Le processus 74 a généré l’exception fatal c0000005
EXCEPTION_ACCESS_VIOLATION. SQL Server ce processus est mis fin.
La pile du fichier minidump contient des modules tiers à l’intérieur Sqlserver.exe processus. Par exemple,
le fichier minidump contient les informations suivantes dans les modules Oracle :
OraOLEDButl11
OraOLEDBrst11
OraOLEDBrst10
Full Call Stack: Function Arg 1 Arg 2 Arg 3 Arg 4
ntdll!RtlReportCriticalFailure+62 00000000`00000002 00000000`00000023 00000000`403cc8a2

00000000`00000003
ntdll!RtlpReportHeapFailure+26 00000000`403c95f0 00000000`403d7a78 00000000`403d7ab0
00000000`4d200e30
ntdll!RtlpHeapHandleError+12 00000000`04180000 00000000`00000000 00000000`00000000 00000000`00000000
ntdll!RtlpLogHeapFailure+a4 00000000`403d7b40 00000000`04180000 00000000`403d7b50 00000000`00000008
ntdll!RtlFreeHeap+1aa8f 00000000`00000020 00000000`403cd850 00000000`00000001 00000000`403d0024
ole32!CoTaskMemFree+36 00000000`403d6b00 00000000`00000001 00000000`4d200e30 00000000`00000024
OraOLEDButl11+1a5f 00000000`00000001 00000000`4d200e30 00000000`00000024 00000000`403d7ab8
0x403d6b00 00000000`4d200e30 00000000`00000024 00000000`403d7ab8 00000000`24492843
0x00000001 00000000`00000024 00000000`403d7ab8 00000000`24492843 00000000`403b8c00
0x4d200e30 00000000`403d7ab8 00000000`24492843 00000000`403b8c00 00000000`403c95f0
0x00000024 00000000`24492843 00000000`403b8c00 00000000`403c95f0 00000000`403ca610
0x403d7ab8 00000000`403b8c00 00000000`403c95f0 00000000`403ca610 00000000`403ca610
OraOLEDBrst11+12843 00000000`403c95f0 00000000`403ca610 00000000`403ca610 00000000`403c95f0
0x403b8c00 00000000`403ca610 00000000`403ca610 00000000`403c95f0 00000000`244928b1
0x403c95f0 00000000`403ca610 00000000`403c95f0 00000000`244928b1 00000000`403d7ab8
0x403ca610 00000000`403c95f0 00000000`244928b1 00000000`403d7ab8 00000000`403c95f0
0x403ca610 00000000`244928b1 00000000`403d7ab8 00000000`403c95f0 00000000`4966a260
0x403c95f0 00000000`403d7ab8 00000000`403c95f0 00000000`4966a260 00000000`05cd21e0
OraOLEDBrst11+128b1 00000000`403c95f0 00000000`4966a260 00000000`05cd21e0 00000000`00000000
0x403d7ab8 00000000`4966a260 00000000`05cd21e0 00000000`00000000 00000000`2449ca03
0x403c95f0 00000000`05cd21e0 00000000`00000000 00000000`2449ca03 00000000`4d200e30
0x4966a260 00000000`00000000 00000000`2449ca03 00000000`4d200e30 00000000`00000001
0x05cd21e0 00000000`2449ca03 00000000`4d200e30 00000000`00000001 00000000`05cd21e0
Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de
Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces
produits.
Cause
Ce problème se produit parce que les caractères spéciaux existent dans la requête sur -- le serveur lié Oracle.
Ces caractères sont utilisés comme symbole de commentaire.
Le processus SQL Server se crashe car le fournisseur de serveur lié tiers est chargé dans le processus SQL
Server et modifie de manière incorrecte la mémoire du tas qui n’y appartient pas. Si les fonctions heap à
l’intérieur d’un processus sont instables, pour la protection contre l’altération des données, le processus est
automatiquement arrêté par le système d’exploitation. Si le fournisseur de serveur lié tiers est activé avec
l’option Autoriser l’inprocessage, le processus SQL Server se crashe lorsque ce serveur lié tiers subit le
problème décrit.
Pour contourner ce problème, appliquez l'une des méthodes suivantes :
Supprimez le symbole de commentaires.
Remplacez le symbole de commentaires par le symbole commentaires : /* */ .
Contactez le fournisseur tiers pour obtenir des informations et des correctifs. Pour la dernière version du
fournisseur OLEDB, voir téléchargements 64 bitsdes composants d’accès aux données Oracle (ODAC).
L’autorisation Créer une base de données est
consignée dans le journal d’audit lorsque vous
exécutez RESTORE VERIFYONLY
Cet article fournit plus d’informations sur la raison pour laquelle un événement peut être journalisé lorsque
l’audit du serveur est spécifié sur CREATE DATABASE SQL Server instance.
Version du produit d’origine : Microsoft SQL Server 2014, SQL Server 2016, SQL Server 2017 sur Linux, SQL
Server 2017 sur Windows
Symptômes
Supposons que vous avez installé un audit SQL Server afin d’avoir une spécification d’audit de serveur qui
utilise DATABASE_CHANGE_GROUP l’événement. Lorsqu’un utilisateur s’exécute sur un fichier de sauvegarde de base
de données, l’autorisation est enregistrée dans RESTORE VERIFYONLY CREATE DATABASE le journal d’audit.
Cause
CREATE DATABASE L’autorisation est requise pour s’exécuter. RESTORE VERIFYONLY Lorsque cette autorisation est
vérifiée, un événement correspondant est consigné dans le journal d’audit pour la DATABASE_CHANGE_GROUP
spécification d’audit.
Pour contourner ce problème, utilisez une requête telle que la suivante pour filtrer les enregistrements du
journal d’audit liés à l’exécution RESTORE VERIFYONLY :
select * from fn_get_audit_file('C:\path\to\file.sqlaudit', default, default) where statement NOT LIKE

'%RESTORE VERIFYONLY%'
RESTORE Statements - VERIFYONLY (Transact-SQL)
GRANT Database Permissions (Transact-SQL).
SQL Server Moteur de base de
données’entrée/sortie requises
Cet article décrit les conditions requises SQL Server Moteur de base de données’entrée/sortie.
Introduction
SQL Server systèmes doivent prendre en charge la distribution garantie sur des supports stables, comme
indiqué dans les documents de téléchargement suivants :
SQL Server Conditions requises pour le programme de fiabilité des entrées/des personnes
SQL Server Exigences de révision du programme de fiabilité des entrées et des entrées (IO)
NOTE
Les deux documents ci-dessus s’appliquent également SQL Server 2014. Cette exigence inclut, sans s’y limiter, les
conditions suivantes :
Windows certification de logo

Ordre d’écriture
Stabilité de la mise en cache
Aucune réécriture de données
Les systèmes qui répondent à ces exigences SQL Server stockage de base de données. Les systèmes n’ont pas
besoin d’être répertoriés sur le site SQL Server solutions de stockage, mais ils doivent garantir que les
conditions requises sont remplies.
SQL Server maintient l’atomicité, la cohérence, l’isolation et la propriété de du dualité (UMA) à l’aide du
protocole Write-Ahead Logging (WAL).
WARNING
L’utilisation incorrecte de SQL Server avec une solution testée incorrectement peut entraîner une perte de données, y
compris la perte totale de base de données.
Assistance technique
Microsoft fournit une prise en charge complète des applications SQL Server et SQL Server basées sur des
applications. Toutefois, les problèmes qui ont ou sont dus à la solution d’O/S sont renvoyés au fabricant de
l’appareil. Les symptômes peuvent inclure, sans s’y limiter, les suivants :
Base de données endommagée
Altération de la sauvegarde
Perte de données inattendue
Transactions manquantes
Variations de performances d’I/S inattendues
Microsoft recommande l’utilisation de produits Windows logo certifiés. Pour déterminer si votre solution prend
en charge la « distribution garantie sur un support stable », comme indiqué dans le SQL Server Always-On,
consultez votre fournisseur. Nous vous recommandons également de contacter votre fournisseur pour vérifier
que vous avez correctement déployé et configuré la solution pour une utilisation de base de données
transactionnelle.
Il est courant pour un professionnel du Support Microsoft de vous demander de désactiver les travaux non
essentiels et de désactiver ou de supprimer des composants tiers, de déplacer des fichiers de base de données,
de désinstaller des pilotes et d’effectuer des actions similaires. Nous essayons toujours de réduire l’étendue du
problème pendant que nous travaillons à l’identifier. Une fois qu’un problème est identifié comme non lié aux
travaux ou produits tiers, ces travaux ou produits tiers peuvent être réintroduits en production.
Pour plus d’informations, consultez l’article suivant :
Microsoft ne certifie pas que les produits tiers fonctionneront avec Microsoft SQL Server
Vue d’ensemble de la stratégie de prise en charge des solutions logicielles de stockage tierces Microsoft
Le tableau suivant fournit des liens vers des informations supplémentaires relatives à des configurations
d’opérations d’opérations d’information spécifiques.
SQ L SERVER 2000 I/ O B A SIC S

SQ L SERVER P RIN C IP ES DE B A SE DES O / S, C H A P IT RE
2
ÉC RIT URE DE PA GES
P O IN T S DE C O N T RÔ L E DE B A SE DE DO N N ÉES ( SQ L
SERVER)
SQ L SERVER I/ O IN T ERN A L S
WAL Journal des transactions d’écriture avant

PROPRIÉTÉS DE LAS (atomicité, cohérence, isolation
et dulité)
Description des algorithmes de journalisation et de
stockage des données qui étendent la fiabilité des
données SQL Server
Fonctionnalités du système de fichiers SQL Server bases de données non pris en charge sur
les volumes compressés (à l’exception des fichiers en
lecture seule 2005)
Diminution des performances dans certaines
fonctionnalités de SQL Server lorsque vous utilisez
EFS pour chiffrer des fichiers de base de données
Mise en cache des I/S Informations sur l’utilisation de caches de disque avec
des SQL Server que chaque administrateur de base
de données doit connaître
Description de la mise en cache des contrôleurs de
disque dans SQL Server
2
SQ L SERVER I/ O IN T ERN A L S P O IN T S DE C O N T RÔ L E DE B A SE DE DO N N ÉES ( SQ L
SERVER)
Disposition et conception physiques Conception des bases de données Stockage physique

Vue d’ensemble des bases de données partagées
évolutives
Tempdb Microsoft SQL Server Besoins en matière de sous-

système d’I/S pour la base de données tempdb
Working with tempdb in SQL Server 2005
Optimisation des performances tempdb
Recommandations pour réduire la contention
d’allocation dans SQL Server base de données
tempdb
Utilitaires Utilisation de l’utilitaire SQLIOSim pour simuler SQL

Server activité sur un sous-système de disque
Diskspd : outil de test de stockage robuste
Diagnostics Les I/S de disque asynchrone apparaissent comme

synchrones sur Windows
SQL Server diagnostics ajoutés pour détecter les
problèmes d’I/S non signalés dus à des lectures
obsolètes ou à des écritures perdues
Erreur MSSQLSERVER 823
Enregistrement pour l’analyse basée sur les
ressources de l’enregistreur Windows
Performance Recorder
Ressources Xperf :
Les diagnostics dans SQL Server détecter les
opérations d’entreprise bloquées et bloquées
Erreur MSSQLSERVER 823
Description des causes courantes de SQL Server
message d’erreur 844 ou message d’erreur 845
NAS (Network Attached Stockage) Description de la prise en charge des fichiers de base de
données réseau dans SQL Server
iSCSI Prise en charge SQL Server sur les composants de

technologie iSCSI
2
SQ L SERVER I/ O IN T ERN A L S P O IN T S DE C O N T RÔ L E DE B A SE DE DO N N ÉES ( SQ L
SERVER)
Groupes de disponibilité AlwaysOn et de mise en miroir Conditions préalables, restrictions et

Recommandations pour les groupes de disponibilité
Always On
Conditions requises pour SQL Server la prise en
charge de la mise en miroir à distance des bases de
données utilisateur
Mise en miroir de bases de données :
Mise en miroir de bases de données SQL
Server 2005
Meilleures pratiques et considérations sur les
performances de la mise en miroir de bases
de données
Ces livres blancs s’appliquent également Microsoft SQL
Server 2008 et versions ultérieures de SQL Server.
Affinité des O/S INF : Comprendre comment définir l’SQL Server d’affinité
d’I/S
Tirets « - » ignorés dans la recherche avec des
requêtes SQL Full-Text et MSIDXS
Cet article vous aide à contourner le problème qui se produit lorsque vous effectuez une recherche en texte
intégral sur des données de caractères SQL Server ou lorsque vous utilisez une requête distribuée SQL avec le
fournisseur Microsoft Index Server OLE DB (MSIDXS) et une recherche d’extension de préfixe pour un mot
composé qui contient un tiret (par exemple, XYZ-A*).
Symptômes
Lors d’une recherche en texte intégral sur des données de caractères SQL Server ou lors de l’utilisation d’une
requête distribuée SQL avec le fournisseur Microsoft Index Server OLE DB (MSIDXS) et d’une recherche
d’extension de préfixe pour un mot composé qui contient un trait d’union (par exemple, « XYZ-A* ») les résultats
obtenus peuvent ne pas être comme prévu.
Cause
Une recherche en texte intégral considère un mot comme une chaîne de caractères sans espaces ni ponctuation.
L’occurrence d’un caractère non alphanumérique peut rompre un mot au cours d’une recherche. Étant donné
SQL Server recherche en texte intégral est un moteur basé sur le mot, la ponctuation n’est généralement pas
envisagée et est ignorée lors de la recherche dans l’index. Par conséquent, une clause comme celle qui
correspondrait à une ligne avec la valeur, l’échec de la recherche de CONTAINS
CONTAINS(testing, "computer-failure") mon ordinateur serait coûteux .
Pour contourner ce problème, essayez l’une des méthodes suivantes :
Utilisez uniquement des caractères alphanumériques lorsque vous utilisez les SQL Server’index de texte
intégral.
Lorsque le caractère non alphanumérique doit être utilisé dans les critères de recherche (principalement
le caractère tiret), utilisez la clause Transact-SQL au lieu des - LIKE FULLTEXT CONTAINS prédicats.
Microsoft SQL Server version 7.0 permet d’effectuer une requête en texte intégral sur les données de caractères
stockées dans SQL Server tables. Vous pouvez également utiliser une SQL distribuée avec le fournisseur
MSIDXS pour rechercher des données de système de fichiers. L’utilisation du tiret ( ) dans une recherche de
proximité n’est pas prise en charge - et peut donner des résultats inattendus.
Références
Pour plus d’informations SQL Server recherche en texte intégral, voir la SQL Server Books Online.
Pour plus d’informations sur l’utilisation de la clause CONTAINS avec le fournisseur MSIDXS (Microsoft
Index Server), voir la documentation du serveur d’index dans la documentation du pack d’options
Windows NT 4.0.
Défragmentation des lecteurs SQL Server base de
données
Cet article fournit des conseils concernant la défragmentation des lecteurs de SQL Server base de données.
Doit SQL Server disques défragmentés au niveau de la couche du

système d’exploitation
Cela dépend de l’état de fragmentation des lecteurs actuels. En règle générale, cela ne fait pas de mal et peut
vous aider, en supposant que vous suivez les précautions décrites dans la section Précautions lors de la
défragmentation de SQL Server base de données. Le seul point négatif est que vous devez arrêter SQL
Server à moins que l’outil de défragmentation ne prend en charge les fonctionnalités de données
transactionnelles. La bonne nouvelle est qu’après avoir exécuté la défragmentation, vous n’avez pas vraiment
besoin de le faire à nouveau, sauf si vous avez de nombreux fichiers autogrowth et autres qui se déplacent sur et
hors des disques. Assurez-vous de bien comprendre les stratégies de mise en cache en écriture que l’utilitaire
utilise. La mise en cache par un tel utilitaire peut impliquer un cache non alimenté par batterie, ce qui peut
enfreindre les exigences du protocole WAO.
Un défragmenteur de disque déplace tous les fichiers, y compris le fichier de base de données, dans des clusters
contigus sur un disque dur. Cela optimise et accélère l’accès aux fichiers. À l’exception du système d’exploitation
NT Windows, si vous ne défragmentez pas votre disque dur, le système d’exploitation peut avoir besoin
d’accéder à plusieurs emplacements physiques sur le disque pour récupérer le fichier de base de données, ce qui
ralentit l’accès aux fichiers.
Étant donné que l’accès aux données physiques est la partie la plus coûteuse d’une demande d’I/S, la
défragmentation peut offrir des gains de performances pour SQL Server et d’autres applications. Les blocs de
données liés au positionnement proches les uns des autres réduisent les besoins en matière d’opérations
d’entrée et de fin.
Divers utilitaires de défragmentation sont actuellement disponibles sur le marché. Certains utilitaires permettent
la défragmentation sur les fichiers ouverts, tandis que d’autres nécessitent une défragmentation de fichiers
fermés ou offrent de meilleures performance lorsqu’ils sont utilisés dans des conditions de fichier fermé. En
outre, certains utilitaires ont des fonctionnalités transactionnelles, contrairement à d’autres.
Précautions lors de la défragmentation de SQL Server de base de

données
Lorsque vous évaluez un utilitaire de défragmentation à utiliser avec SQL Server, assurez-vous que l’utilitaire
fournit des fonctionnalités de données transactionnelles. Plus précisément, choisissez un utilitaire de
défragmentation qui fournit les fonctionnalités de données transactionnelles suivantes :
Le secteur d’origine n’est pas considéré comme déplacé tant que le nouveau secteur n’a pas été
correctement établi et que les données ont été copiées.
L’utilitaire protège contre les défaillances système, telles qu’une coupure de courant, de manière
sécurisée, qui conserve les fichiers intacts logiquement et physiquement. Pour garantir l’intégrité des
données, un test pullthe-plug est vivement recommandé lorsqu’un utilitaire de défragmentation est en
cours d’exécution sur un fichier SQL Server base de données.
Le Write-Ahead de journalisation des données requiert la prévention des réécritures de secteur afin
d’éviter la perte de données. L’utilitaire doit conserver l’intégrité physique du fichier tant qu’il effectue
des mouvements de données. L’utilitaire doit fonctionner sur les limites de secteur d’une manière
transactionnelle pour conserver les fichiers SQL Server intacts.
L’utilitaire doit fournir des mécanismes de verrouillage appropriés pour garantir que le fichier conserve
une image cohérente pour toutes les modifications. Par exemple, l’utilitaire doit s’assurer que le secteur
d’origine ne peut pas être modifié lorsqu’il est copié vers un nouvel emplacement. Si des modifications
sont autorisées, l’utilitaire de défragmentation risque de perdre l’écriture.
Les défragmentateurs de disque critiques qui ne fournissent pas ces fonctionnalités de données
transactionnelles ne doivent pas être utilisés, sauf si l’instance de SQL Server utilisant les disques à
défragmenter a été fermée afin que vous ne défragmentiez pas les fichiers de base de données ouverts.
La défragmentation des fichiers ouverts pose plusieurs problèmes possibles que la défragmentation de fichier
fermé n’a généralement pas :
La défragmentation des fichiers ouverts affecte les performances. Les utilitaires de défragmentation
peuvent verrouiller des sections du fichier, ce qui empêche SQL Server effectuer une opération de lecture
ou d’écriture. Cela peut affecter la concurrence du serveur en cours d’exécution SQL Server. Contactez le
fabricant de l’outil de défragmentation pour savoir comment les fichiers sont verrouillés et comment cela
peut affecter SQL Server’accès.
La défragmentation des fichiers ouverts peut affecter la mise en cache et l’ordre d’écriture. Les utilitaires
basés sur des fichiers ouverts nécessitent des composants de chemin d’accès d’I/S . ces composants ne
doivent pas modifier l’ordre ou la nature prévue de l’opération d’écriture. Si les clients du protocole
d’écriture ou DER sont rompus, des dommages de base de données sont susceptibles de se produire. La
base de données et tous les fichiers associés sont considérés comme une entité unique. (Cela est abordé
dans de nombreux articles de la Base de connaissances Microsoft, SQL Server Livres en ligne et divers
livres blancs.) Toutes les écritures doivent conserver les séquences d’ordre d’écriture d’origine et les
fonctionnalités d’écriture par écriture.
Recommandations
Défragmentez le volume NTFS, sauf s’il a été formaté, avant de créer une base de données ou de déplacer
des bases de données existantes vers le volume.
Assurez-vous de planifier et de dimensionr vos données SQL fichiers journaux de manière appropriée lors de
la première création de la base de données.
Créez vos journaux de transaction SQL Server 2014 avec larowth automatique à l’esprit s’il sera utilisé.
Défragmentez le ou les disques sur lesquels résident vos journaux de transactions. Cela permet d’éviter la
fragmentation du fichier externe du journal des transactions. Ce problème peut se produire si vos fichiers ont
connu une grande quantité de connexions automatiques ou s’il ne s’agit pas d’un disque dédié qui contient
de nombreuses bases de données, journaux ou autres fichiers qui ont été modifiés. Dans ce cas, les fichiers (y
compris le fichier journal des transactions) peuvent être entrecoupés et fragmentés.
Si vous défragmentez des lecteurs de base de données qui sont des disques de cluster, les disques de cluster
doivent être mis en place pour suspendre la surveillance de l’état (également appelé mode maintenance).
Pour minimiser la fragmentation, ne réduisez pas vos fichiers de base de données. En outre, augmentez-les
manuellement en tailles qui minimisent l’activité de croissance.
Conservez vos fichiers de base de données sur des disques dédiés.
Effectuez une sauvegarde complète avant de défragmenter les emplacements qui contiennent des SQL
Server base de données et des fichiers de sauvegarde.
Références
Comment exécuter ChkDsk et défragmenter sur les volumes partagés de cluster Windows Server 2012
R2
Recommandations recommandations pour améliorer les performances SQL Server FILESTREAM
Une erreur 0x80040e97 se produit lorsque vous
utilisez la recherche de texte intégral intégrée dans
SQL Server
Cet article vous aide à résoudre le problème qui se produit lorsque vous indexez des documents de grande taille
à l’aide d’une recherche en texte intégral intégrée dans SQL Server.
Symptômes
Lorsque vous indexez des documents complexes ou de grande taille à l’aide d’une recherche en texte intégral
intégrée dans Microsoft SQL Server, vous pouvez recevoir des erreurs de délai d’Microsoft SQL Server
2010-06-07 15:02:44.64 spid10s Error '0x80040e97' occurred during full-text index population for table or
indexed view '[db1]. [dbo]. [Images] » (ID de table ou de vue indexée « 622625261 », ID de base de données
« 171 », valeur de clé de texte intégral « 2375057 ». Une nouvelle réindexation est tentée.
En outre, SQL Server pouvez redémarrer le processus FDHOST.exe de travail. Lorsque ce problème se produit,
un message d’erreur semblable à ce qui suit s’affiche dans SQL Server journal des erreurs :
Cause
Ce problème se produit si la lecture et le traitement des données XML prennent plus de 60 secondes pour
FDHOST.exe processus de lecture et de traitement des données XML.
Résolution
Pour résoudre ce problème, augmentez la valeur du délai d’délai d’indexation de texte intégral. Pour ce faire,
appelez sp_fulltext_service la procédure stockée qui possède le 'ft_timeout' paramètre. Par exemple,
l’exemple suivant augmente le délai d’indexation de texte intégral à 20 minutes pour n’importe quel document :
Exec sp_fulltext_service 'ft_timeout', 1200000
NOTE
Le deuxième paramètre est le délai d’indexation complète en millisecondes.
IMPORTANT
Redémarrez votre SQL Server pour que le nouveau paramètre prenne effet.
Lorsque SQL Server indexe des types de données tels que varbinary, varbinary(max), image ou xml, SQL Server
envoie des données au processus de daemon de filtre (FDHOST.exe). À tout moment au cours du processus
d’indexation, SQL Server n’attend pas plus de 60 secondes avant que le FDHOST.exe de réponse.
Pour les documents XML de grande taille, le filtre XML hébergé par le processus FDHOST.exe lit toutes les
données de SQL Server et stocke les données dans un fichier temporaire. Ensuite, FDHOST.exe le contenu XML
pour le filtrage et la cinglisation des mots. Si ce processus prend plus de 60 secondes, SQL Server arrête le lot et
retentre l’opération en utilisant une taille de lot plus petite. Si un document XML est de grande taille et que le
processus FDHOST.exe prend plus de 60 secondes pour filtrer et rompre les mots, vous pouvez obtenir une
erreur mentionnée dans la section Symptômes.
NOTE
Le problème peut se produire avec n’importe quel iFilter qui écrit des données dans un fichier temporaire.
Des 0x80040e97 peuvent également être produites pour d’autres raisons. Par exemple, vous pouvez voir le
même code d’erreur lorsque SQL Server des problèmes de chargement d’un iFilter. L’augmentation de la valeur
du délai d’dépassement dans ces cas-là peut masquer l’erreur et empêcher un dépannage efficace. Par
conséquent, nous vous recommandons de vérifier la taille du document et de vérifier que la taille du document
défaillant est exceptionnellement importante avant d’augmenter la valeur du délai d’délai.
Erreur 3156 lors de la restauration d’une base de
données avec un groupe de fichiers optimisé pour
la mémoire SQL Server
Symptômes
Lorsque vous essayez de restaurer une base de données dont le groupe de fichiers est optimisé pour la SQL
Server, vous recevez le message d’erreur suivant :

Le fichier <Database File> ' ' ne peut pas être restauré sur ' : <Driver> \ <Folder Path> \ <Database Folder>
'. Utilisez WITH MOVE pour identifier un emplacement valide pour le fichier.
Cause
Pendant le processus de restauration d’une base de données, SQL Server Moteur de base de données créera un
dossier pour un groupe de fichiers optimisé pour la mémoire. Ce problème se produit s’il existe déjà un dossier
du même nom dans le même chemin d’accès et que le dossier est utilisé par SQL Server ou d’autres processus.
Utilisez un nom de dossier différent ou un chemin d’accès de dossier différent lors de la restauration d’une base
de données.
Exemple de script
Exemple de script de création d’une base de données avec un groupe de fichiers
USE [master];
GO
CREATE DATABASE Contoso
ON PRIMARY
( NAME = 'Contoso_Primary',
FILENAME=
'C:\SQLserver\Contoso\Contoso_data.mdf',
SIZE=4MB,
MAXSIZE=10MB,
FILEGROWTH=1MB),
FILEGROUP Contoso_FG1
( NAME = 'Contoso_FG1',
FILENAME =
'C:\SQLserver\Contoso\Contoso_FG1.ndf',
SIZE = 1MB,
MAXSIZE=10MB,
FILEGROWTH=1MB)
ALTER DATABASE Contoso

ADD FILEGROUP [Contoso_FG1] CONTAINS MEMORY_OPTIMIZED_DATA
GO
Exemple de script de restauration de base de données
USE [master]
GO
RESTORE DATABASE [Contoso] FROM DISK = N'C:\backup\compress\Contoso\Contoso.bak' WITH FILE = 1,
MOVE N'Contoso_data' TO N'C:\SQLserver\Contoso\Contoso_data.mdf',
MOVE N'Contoso_log' TO N'C:\SQLServer\Contoso\Contoso_log.ldf',
MOVE N'<Database File>' TO N'<Driver>:\<Folder Path>\<Database Folder>',
Replace,
NOUNLOAD,
STATS = 5
GO
NOTE
Si le mot clé n’est pas utilisé, le mot clé dans le script garantit que le processus de restauration
<Database Folder> Replace est terminé sans erreur.
Voir aussi
MSSQLSERVER_3156
Erreur Msg 33111 après SQL Server rotation de clé
ou de certificat TDE
Cet article vous aide à résoudre le problème qui se produit après l’utilisation d’un certificat Transparent Data
Encryption (TDE) ou d’une rotation de clé, l’abandon de la certification d’origine, puis la sauvegarde d’un journal
à l’aide de COMPRESSION+MAXTRANSFERSIZE.
S’applique à : SQL Server 2019, SQL Server 2016, SQL Server 2014, SQL Server 2012
Symptômes
Une fois que vous avez effectué une rotation de clé ou un certificat Transparent Data Encryption (TDE), déposez
la certification d’origine, puis effectuez une sauvegarde du journal à l’aide de
COMPRESSION+MAXTRANSFERSIZE, vous recevez l’erreur suivante :
Msg 33111, Niveau 16, État 3, LineNumber

Impossible de trouver le certificat de serveur avec l’empreinte numérique « % ».
Msg 3013, Level 16, State 1, LineLineNumber
BACKUP LOG se termine anormalement.
Cause
Lors de la modification du certificat ou des clés, le fichier journal virtuel (VLF) actif, qui est chiffré par la clé
précédente, est fermé. Le vlf disponible suivant (ou le vlf nouvellement créé) sera utilisé et chiffré par la nouvelle
certification.
À ce stade, le fichier journal des transactions conserve les enregistrements journaux chiffrés par le certificat
précédent, ainsi que les enregistrements de journaux chiffrés par le nouveau certificat.
Lorsque vous effectuez une sauvegarde de journal avec les paramètres COMPRESSION+MAXTRANSFERSIZE,
les enregistrements journaux qui ont été chiffrés par le certificat précédent sont déchiffrés, puis chiffrés par le
nouveau certificat, puis enregistrés dans le fichier de sauvegarde.
Pour cette raison, la certification précédente est nécessaire pour le déchiffrement. La sauvegarde du journal
échouera si le certificat précédent n’existe pas.
Résolution
Restituer la certification précédente et réessayer la sauvegarde.
NOTE
Nous vous recommandons de conserver les sauvegardes de certification au cas où le problème se produira à l’avenir.
État
Microsoft étudie actuellement ce problème et publiera des informations supplémentaires dans cet article dès
qu’elles seront disponibles.
Références
Découvrez la description de la terminologie standard utilisée pour décrire les mises à jour logicielles Microsoft
que Microsoft utilise pour décrire les mises à jour logicielles.
Message d’avertissement contenant
HkHostBackupGetCheckpointFileInfoV2 et 1000016
journal d’SQL Server’erreurs
Cet article décrit un avertissement qui se produit lors de la backing d’une base de données en mémoire.
Version du produit d’origine : SQL Server 2016 Enterprise, SQL Server 2016 Enterprise Core
Symptômes
Supposons que vous avez une base de données en mémoire dans SQL Server. Si vous back up the in-memory
database, you may notice that the following warning message is logged in the SQL Server error log:
[AVERTISSEMENT] HkHostBackupGetCheckpointFileInfoV2 (). ID de base de données : [21]. Nom de

fichier de point de contrôle non valide. FileName : ffffffdd-fffffb17-fffd.00000022-000004e8-
0002.4b987b24-bf74-485d-b32e-e7ddfb496457.0-0. 1000016 .
(d:\b\s3\sources\sql\ntdbms\hekaton\sqlhost\sqlmin\hkhostbackup.cpp : 2958)
Le message d’avertissement commence par HkHostBackupGetCheckpointFileInfoV2 et se termine par
1000016 dans fileName. Les messages d’avertissement qui ont exactement ces valeurs sont sans danger et
vous pouvez les ignorer en toute sécurité. À un moment donné, SQL Server les supprimera automatiquement.
Le fichier dans le dossier $FSLOG est utilisé en interne pour l’intégrité des transactions Filestream. SQL Server
interprète incorrectement le message d’avertissement comme un point de contrôle valide de la base de données
en mémoire. Dans ce cas, SQL Server l’avertissement dans le journal SQL Server’erreurs.
Erreur lorsque vous créez une sauvegarde
instantanée de nombreuses bases de données en
même temps dans SQL Server
Cet article vous aide à résoudre le problème (message) que lorsque vous créez une sauvegarde instantanée de
nombreuses bases de données en même temps
ERROR Selected writer 'Microsoft Writer (Service State)' is in failed state dans SQL Server.

Symptômes
Dans Microsoft SQL Server, vous créez une sauvegarde instantanée de nombreuses bases de données en même
temps. Pour ce faire, vous utilisez le service VSS (Volume Shadow Copy Service) ou l’interface VDI (Virtual
Backup Device Interface). Dans ce scénario, l’opération de sauvegarde de capture instantanée échoue. En outre,
vous recevez le message d’erreur suivant si vous utilisez le service VSS pour créer la sauvegarde de capture
instantanée :
ERREUR : l’auteur sélectionné « Rédacteur Microsoft (État du service) » est dans l’état d’échec !
État : 8 (VSS_WS_FAILED_AT_PREPARE_SNAPSHOT)
Code d’échec du rédacteur : 0x800423f4 ( )
Writer ID: { WriterID }
ID d’instance : { InstanceID }
Vous recevez l’un des messages d’erreur suivants si vous utilisez l’environnement VDI pour créer la sauvegarde
de capture instantanée :
[Microsoft] [Pilote SQL Server ODBC] [SQL Server] Ressources insuffisantes pour créer un
programmeur de SSM.
Msg 3267, SevLevel 16, State 1, SQLState 42000
[Microsoft] [Pilote SQL Server ODBC] [SQL Server] Le thread de travail n’a pas pu être créé.
Msg 3013, SevLevel 16, State 1, SQLState 42000
Le message suivant peut être consigné dans le journal SQL Server’erreurs :
<Datetime> spid420 SubprocessMgr::EnqueueSubprocess : limite de « Nombre maximum de threads

de travail » atteinte
Le nombre de bases de données que vous essayez de récupérer lorsque ce problème se produit varie. Le
nombre de bases de données dépend des conditions suivantes :
La configuration des SQL Server
Autres activités dans SQL Server
Cause
Dans SQL Server, la sauvegarde instantanée de chaque base de données utilise cinq threads dans le Sqlservr.exe
de données. En outre, d’autres activités peuvent également utiliser des threads dans Sqlservr.exe processus.
Selon la configuration de SQL Server, les threads disponibles peuvent être utilisés si vous créez une sauvegarde
instantanée de nombreuses bases de données en même temps.
Pour contourner ce problème, créez une sauvegarde instantanée d’un nombre réduit de bases de données en
même temps.
Si vous exécutez une version 64 bits de SQL Server, vous pouvez envisager d’augmenter l’option de
configuration Des threads de travail max. Il n’est pas recommandé de modifier ce paramètre sur une version 32
bits de SQL Server.
Nous vous recommandons de créer une sauvegarde instantanée de moins de 35 bases de données en même
temps.
Erreur lorsque vous exécutez un objet CLR existant
ou créez un assembly
Cet article vous aide à résoudre deux problèmes différents qui peuvent se produire lors de l’utilisation d’objets
CLR sur une base de données qui a été déplacée à partir d’une instance différente de SQL Server.
Symptômes
Prenons le cas de figure suivant. Vous détachez ou remontez une base de données qui se trouve dans une
instance de SQL Server. L’instance de SQL Server est en cours d’exécution sur le serveur A. Par la suite, vous
attachez ou restituerez cette base de données à une instance de SQL Server qui est en cours d’exécution sur le
serveur B. Dans ce scénario, vous pouvez être face aux symptômes suivants :
Lorsque vous essayez d’exécuter un objet CLR (Common Language Runtime) existant avec l’autorisation
non sûre définie à partir de la base de données qui se trouve sur le serveur B, vous recevez le
external_access message d’erreur suivant :

Une erreur s’est produite dans le .NET Framework Microsoft lors de la tentative de chargement de l’ID
d’assembly 65536. Il se peut que le serveur manque de ressources ou que l’assembly ne soit pas
approuvé avec PERMISSION_SET = EXTERNAL_ACCESS ou UNSAFE. Exécutez à nouveau la requête
ou consultez la documentation pour voir comment résoudre les problèmes d’confiance de l’assembly.
Pour plus d’informations sur cette erreur :
System.IO.FileLoadException: Could not load file or assembly 'AssemblyName, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. Une erreur relative à la sécurité
s’est produite. (Exception de HRESULT : 0x8013150A) System.IO.FileLoadException :
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence
assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean
throwOnFileNotFound, Boolean forIntrospection) at
System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity,
StackCrawlMark& stackMark, Boolean forIntrospection) at
System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity,
StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.Load(String
assemblyString)
Lorsque vous essayez de créer un assembly dont l’autorisation ou l’autorisation non sûre est définie dans
la même base de données, vous recevez external_access le message d’erreur suivant :
Serveur : Msg 10327, Niveau 14, État 1, Ligne 1

CREATE ASSEMBLY for assembly 'AssemblyName' failed because assembly 'AssemblyName' is not
authorized for PERMISSION_SET = EXTERNAL_ACCESS. L’assembly est autorisé lorsque l’une des
valeurs suivantes est true : le propriétaire de la base de données (DBO) dispose de l’autorisation
ASSEMBLY DBO (EXTERNAL ACCESS ASSEMBLY) et la base de données a la propriété DE base de
données TRUSTWORTHY . ou l’assembly est signé avec un certificat ou une clé asymétrique qui
dispose d’une connexion correspondante avec l’autorisation ASSEMBLY D’ACCÈS EXTERNE.
Les problèmes se produisent même si vous avez déjà définie la propriété de base de données de confiance sur
ON .
Cause
Ce problème se produit car la connexion que vous utilisez pour créer la base de données sur le serveur A ne se
trouve pas dans l’instance de SQL Server sur le serveur B. Cette connexion peut être la connexion microsoft
Windows ou la connexion SQL Server connexion.
Pour contourner ce problème, utilisez l’une des méthodes suivantes.
NOTE
Avant d’utiliser les méthodes suivantes, veillez à activer la propriété de base de données de confiance.
Utilisez la procédure stockée pour changer le propriétaire de la base de données en sa ou en une

connexion sp_changedbowner disponible sur le serveur B. Par exemple, vous pouvez utiliser l’instruction
suivante pour changer le propriétaire de la base de données en sa :
USE <DatabaseName>
GO
EXEC sp_changedbowner 'sa'
NOTE
Dans cette instruction, <DatabaseName> il s’agit d’un espace réservé au nom de la base de données sur qui vous
travaillez. Le propriétaire modifié de la base de données doit avoir les autorisations correspondantes pour
effectuer une tâche donnée. Par exemple, le propriétaire de la base de données doit avoir l’autorisation CREATE
ASSEMBLY pour créer un assembly.
Ajoutez la connexion sur l’instance de SQL Server sur le serveur A qui est utilisée pour créer la base de
données à l’instance de SQL Server sur le serveur B.
Si la connexion est un compte de domaine, vous pouvez créer la même connexion sur le serveur B. Accordez
ensuite les autorisations requises à la connexion sur l’instance de SQL Server sur le serveur B.
Si la connexion est une connexion SQL Server, assurez-vous que le SID de cette connexion correspond à la
nouvelle connexion SQL Server que vous créez sur l’instance de SQL Server sur le serveur B. Pour ce faire,
spécifiez l’argument SID de CREATE LOGIN l’instruction.
Si vous accédez à l’objet CLR à partir d’une autre base de données et que cette base de données présente un SID
DBO non identique, le même problème peut se produire.
Pour plus d’informations, consultez le blog suivant : CSS SQL Server Engineers.
Références
CREATE LOGIN (Transact-SQL)
sp_changedbowner (Transact-SQL)
CREATE ASSEMBLY (Transact-SQL)
SQL Server index de recherche en texte intégral sur
la colonne XML n’indexe pas les valeurs d’attribut
pour les nodes internes
Cet article vous aide à résoudre le problème dans lequel SQL Server index de texte intégral sur la colonne XML
n’indexe pas les valeurs d’attribut pour les nodes internes.
Symptômes
Dans Microsoft SQL Server lors de l’indexation d’une colonne XML à l’aide de valeurs de nœud de texte intégral
uniquement et de valeurs d’attribut pour le nœud supérieur sont indexés. Les valeurs d’attribut d’un des nodes
internes ne sont pas indexées.
Cause
Ce comportement se produit car l’breakeur de mots XML fourni avec SQL Server ne retourne pas les valeurs
d’attribut pour les nodes internes (xmlfilt.dll - Version : 12.0.9735.0).
Résolution
Ce problème peut être résolu à l’aide de l’outil d’coupure de mots XML fourni avec le système d’exploitation
Windows lorsque SQL Server est en cours d’exécution sur Windows 7 ou Windows Server 2008 R2 (version
livrée avec Windows utilise un nom de fichier différent - xmlfilter.dll). Si vous exécutez SQL Server sur une
version inférieure de Windows, vous devez d’abord mettre à niveau vers ces systèmes d’exploitation, puis utiliser
la procédure suivante pour résoudre ce problème.
Procédure pour résoudre le problème sur les serveurs SQL en cours d’exécution sur Windows Server 2008 R2
et Windows 7 :
IMPORTANT
NOTE
Vous devez redémarrer SQL Server service après avoir suivi la procédure suivante pour que les modifications entrent en
vigueur.
1. Accédez à la ruche de Registre suivante sur votre ordinateur SQL Server et enregistrez-la sous
SQLMSSearch.reg.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<instance>\MSSearch\CLSID
NOTE
Remplacez le <instance> « » dans le chemin d’accès ci-dessus par l’ID d’instance approprié SQL Server/SQL Server.
Par exemple, « MSQL10. MSSQLSERVER » pour une instance par défaut ou « MSSQL10 . KATMAI » pour
une instance nommée « Katmai »
Pour plus d’informations, voir File Locations for Default and Named Instances of SQL Server.
2. Modifiez le fichier SQLMSSearch.reg avec le bloc-notes et remplacez toutes les occurrences de xmlfilt.dll
par, puis C:\Windows\system32\xmlfilter.dll enregistrez les modifications.
NOTE
Cela suppose que votre dossier Windows se trouve à C:\Windows l’emplacement .
Vous devez entrer chaque barre oblique inverse dans le nouveau chemin d’accès à deux reprises !
3. Cliquez sur le fichier SQLMSSearch.reg pour importer le contenu dans le Registre.

4. Exécutez les commandes T-SQL suivantes pour activer le nouveau paramètre dans SQL Server
exec sp_fulltext_service 'load_os_resources', 1

exec sp_fulltext_service 'verify_signature ', 0
exec sp_fulltext_service 'update_languages'
exec sp_fulltext_service 'restart_all_fdhosts'
5. Vérifiez la disponibilité des nouveaux paramètres avec cette commande T-SQL :
EXEC sp_help_fulltext_system_components 'fullpath','c:\windows\system32\xmlfilter.dll'
NOTE
Vous devez adapter la commande ci-dessus en fonction du chemin d Windows système correct sur votre système.
Assurez-vous également que toutes les langues (respectivement leur lcid), qui doivent afficher le nouveau
comportement, sont répertoriées dans la colonne « componentname » dans la sortie.
Étapes de la repro :
1. Créez un tableau simple comme suit :
CREATE TABLE [dbo].[testFTS]([idField] [int] PRIMARY KEY,

[xmlField] [xml] NOT NULL)
2. Activez FTS sur le champ xmlField (la langue de cél’est-à-dire que vous sélectionnez ici n’est pas
pertinente pour le repro).
3. Insérez un enregistrement dans cette table, comme suit :
insert into testFTS (idField, xmlField) values
(1, '<TopNode TopFirstAtt="TopAttValue" TopSecondAtt="Second Value">
<MiddleNode FirstAtt="ValueOne" SecondAtt="ValueTwo" ThirdAtt="ValueThree">
<BottomNode BottomAtt="BottomValue">
<InnerMostNode>Innermost Text</InnerMostNode>
</BottomNode>
</MiddleNode>
<MiddleNode FirstAtt="ValueFour" SecondAtt="ValueFive" ThirdAtt="ValueSix">
<BottomNode BottomAtt="OtherBottomValue" />
</MiddleNode>
<MiddleNode FirstAtt="ValueSeven" SecondAtt="ValueEight" ThirdAtt="ValueNine">
<BottomNode BottomAtt="LastValue" />
</MiddleNode>
<NodeWithValue>Testing whether this value will be indexed</NodeWithValue>
</TopNode>')
4. En interrogeant ce tableau particulier fts_index_keywords

select * from sys.dm_fts_index_keywords(db_id(),object_id('testFTS')) , les résultats suivants sont
obtenus :
M OT C L É DISP L AY _T ERM C O L UM N _ID DO C UM EN T _C O UN T
0x0069006E0064006500 indexé 2 1
7800650064
0x0069006E006E006500 innermost 2 1
72006D006F00730074
0x007300650063006F00 second 2 1
6E0064
0x007400650073007400 test 2 1
69006E0067
0x0074006500780074 text 2 1
0x0074006F0070006100 topattvalue 2 1
74007400760061006C0
0750065
0x00760061006C007500 valeur 2 1
65
0x007700680065007400 si 2 1
6800650072
0xFF FIN DU FICHIER 2 1
Ces termes d’affichage semblent se limiter à :

Valeurs de nœud, quelle que soit leur profondeur d’imbriquement dans le document XML.
Valeurs d’attribut uniquement pour le nœud supérieur et non pour les nœuds internes attendus.
Les index de texte intégral cessent de se remplir
pendant 30 minutes dans SQL Server
Cet article vous présente les problèmes qui peuvent se produire lorsque vous travaillez avec plusieurs index de
texte intégral et solutions pour contourner ces problèmes.
Symptômes
Supposons que vous avez Microsoft SQL Server installé sur un serveur. Plusieurs scénarios sont envisageables :
Scénarios 1 :
Vous avez plusieurs index de texte intégral dans une ou plusieurs bases de données, et la population de
ces index de texte intégral se termine presque en même temps.
Scénarios 2 :
Vous créez un catalogue de texte intégral qui contient de nombreux index de texte intégral et la
population de ces index de texte intégral se termine presque en même temps.
Scénarios 3 :
Vous resserez un ou plusieurs catalogues de texte intégral dans lesquels plusieurs index terminent le
remplit en même temps ou presque.
Scénarios 4 :
Vous exécutez manuellement Alter Full-Text Catalogue réorganiser pour un catalogue qui contient de
nombreux index de texte intégral.
Dans l’une de ces situations, si vous activez l’indicateur de suivi (TF) 7603 pour que la journalisation détaillée de
la population de texte intégral soit consignée dans le journal d’erreurs SQL Server, vous voyez des messages qui
ressemblent à ce qui suit :
Date/heure SPIDIFTS : CFTWICrawl::Close, l’analyse complète a pris fin, planifiant une fusion principale pour
CrawlType : 1, DBid 7, catid 5, tid 13847411
Date/Heure SPID CFTMasterMergeListManager::QueueMasterMerge queued MM item for DBid 7, catalog 5,
tblid 13847411
Date/heure SPID IFTS : CFTWIAutoCrawlFullPass::ExecUnit::D oUnitWork : analyse existante trouvée, donc
retourner sans la passe complète d’analyse automatique, DBid 7 Catid 5 Objid 13847411
En outre, vous voyez une attente de 30 minutes pour la fusion principale, et le journal signale que la fusion
principale a été abandonnée :
IFTS SPID date/heure : les éléments de travail de fusion principale ont été abandonnés car ils ont attendu en
préinit pendant plus de 30 minutes m_DBid 7, m_objid 13847411
L’opération de fusion maître d’avertissement SPID date/heure n’a pas été effectuée pour DBid 7, 13847411,
donc l’index d’interrogation sera lent. Veuillez exécuter modifier la réorganisation du catalogue en texte
intégral.
Date/Heure SPID CFTMasterMergeListManager::RemoveMasterMerge released MM item for DBid 7, catalog
5, tblid 13847411
Date/heure SPID La fusion principale a commencé à la fin de l’analyse complète de la table ou de la vue
indexée « [DB1]. [dbo]. [Tableau1]' a échoué avec HRESULT = '0x80000049'. L’ID de base de données est « 7
» et l’ID de table 13847411, ID de catalogue : 5.
Cause
La fusion principale s’exécute automatiquement à la fin d’une population complète ou incrémentielle par index.
Le processus de fusion principale réduit le nombre de fragments pour un index de texte intégral afin que les
requêtes utilisant l’index de texte intégral ne deviennent pas affectées par les performances de l’index de texte
intégral.
Le processus de fusion principale utilise plusieurs threads pour réduire la fragmentation par index de texte
intégral. SQL Server le nombre de fusions maîtres simultanées qui s’exécutent en même temps. Dès que le seuil
est atteint, tout index de texte intégral qui tente d’exécuter une fusion principale sera retardé de 30 minutes. La
mise à jour de l’index de texte intégral ne démarre pas pendant cette période d’attente. La fusion principale
reprend si l’une des deux choses suivantes se produit :
Lorsque la prochaine population incrémentielle réussie se termine et démarre une fusion principale.
Exécutez manuellement une fusion principale en exécutant la commande suivante :
ALTER FULLTEXT CATALOG catalog_name REORGANIZE
NOTE
Les deux options ci-dessus peuvent encore atteindre la limite de fusion principale en fonction du nombre de fusions
maîtres en cours d’exécution à ce moment-là.
Pour contourner ce besoin, essayez les méthodes suivantes :
Méthode 1 (recommandée) : limiter le nombre d’index de texte intégral dans le même catalogue.
Recommandé 7 ou moins. Les tables de grande taille doivent se faire dans leur propre catalogue de texte
intégral. Il s’agit d’une meilleure pratique pour les performances lorsque vous réorganisez ou réorganisez
des index. Cette méthode peut vous aider lorsque Change_tracking est auto.
Méthode 2 : définissez Change_Tracking manuelle, à l’aide de la commande suivante :
ALTER FULLTEXT INDEX ON table_name set Change_tracking = Manual
Ensuite, créez SQL Server tâches à répartir lorsque des populations incrémentielles sont exécutés. Cela se
traduit par moins de chevauchement lorsque vous exécutez une fusion principale après la population
d’index.
Microsoft SQL Server Besoins en matière de sous-
système d’I/S pour la base de données tempdb
Cet article présente les conditions requises pour le sous-système d’I/S pour la base de données tempdb SQL
Server.
Version du produit d’origine : Microsoft SQL Server 2005, SQL Server 2008, SQL Server 2012 SQL Server
2014
Résumé
Microsoft SQL Server nécessite que le sous-système d’E/S utilisé pour stocker les bases de données système et
utilisateur respecte entièrement les exigences de la journalisation Write-Ahead par le biais de principaux d’E/S
spécifiques. Ces exigences sont nécessaires pour respecter les propriétés DE LASO des transactions : Atomic,
Consistent, Isolated et Durable. Les détails sur les exigences de conformité du sous-système d’entrée/heure sont
fournis dans les références suivantes :
SQL Server 2000https://technet.microsoft.com/library/cc966500.aspx
NOTE
Cet article s’applique également SQL Server 2005 et versions ultérieures.
La liste suivante récapitule rapidement les conditions requises :

Les commandes d’écriture doivent être conservées.
La cohérence d’écriture dépendante doit être conservée.
Les écritures doivent toujours être sécurisées dans/sur un support stable.
La prévention des O/S de sécurité doit avoir lieu.
La maintenance de la délabilité reste essentielle pour toutes les autres bases de données, mais peut être
relâchée pour la base de données tempdb. Le tableau suivant récapitule plusieurs des besoins critiques en
matière d’opérations d’SQL Server bases de données.
B ESO IN S EN M AT IÈRE D’O / S B RÈVE DESC RIP T IO N SY ST ÈM E O U UT IL ISAT EUR T EM P DB
Ordre d’écriture Capacité du sous-système à Obligatoire Recommandé

maintenir l’ordre correct des
Cohérence d’écriture opérations d’écriture. Cela
dépendante peut être particulièrement
important pour la mise en
miroir de solutions, les
exigences de cohérence de
groupe et SQL
Server’utilisation du
protocole WAL.
B ESO IN S EN M AT IÈRE D’O / S B RÈVE DESC RIP T IO N SY ST ÈM E O U UT IL ISAT EUR T EM P DB
Lecture après écriture Possibilité pour le sous- Obligatoire Obligatoire

système de répondre aux
demandes de lecture avec la
dernière image de données
lors de l’émission de la
lecture une fois l’écriture
terminée.
Survie en cas de panne Possibilité pour les données Obligatoire Non applicable
de rester entièrement
intactes (durable) en cas de
panne, telle qu’un
redémarrage du système.
Prévention des O/S de Possibilité pour le système Obligatoire Recommandé

sécurité d’éviter le fractionnement
des demandes d’E/S
individuelles.
Réécriture de secteur Le secteur peut uniquement * Déconseillé, autorisé * Déconseillé, autorisé

être écrit dans son uniquement en cas de uniquement en cas de
intégralité et ne peut pas transaction transaction
être réécrit en raison d’une
demande d’écriture sur un
secteur à proximité.
Données renforcés L’attente que lorsqu’une Obligatoire Non applicable

demande d’écriture ou une
opération FlushFileBuffers
est correctement effectuée,
les données ont été
enregistrées dans un
support stable.
Alignement et taille du SQL Server interroge les Obligatoire Obligatoire

secteur physique emplacements de stockage
des données et des fichiers
journaux. Tous les appareils
sont requis pour prendre en
charge les attributs de
secteur permettant aux SQL
Server d’écrire sur des
limites physiques alignées
sur le secteur et dans des
multiples de la taille du
secteur.
Les réécritures de secteur transactionnel impliquent des opérations entièrement enregistrées par le sous-
système permettant à un secteur d’être entièrement déplacé, remplacé ou de revenir à l’image d’origine. Ces
réécritures sont généralement déconseillés en raison de la surcharge supplémentaire requise pour effectuer de
telles actions. Par exemple, il peut s’agit defragmentation d’un utilitaire qui déplace les données du fichier. Le
secteur d’origine dans le fichier ne peut pas être remplacé par le nouvel emplacement de secteur tant que le
nouveau secteur et les nouvelles données ne sont pas sécurisés. Le remappage du secteur doit se produire de
manière transactionnelle afin que toute défaillance, y compris une panne électrique, entraîne le rétablissement
des données d’origine. Assurez-vous que vous disposez de mécanismes de verrouillage disponibles au cours de
ce type de processus pour empêcher l’accès aux données non valide, ce qui a pour effet de bloquer les autres
clients de SQL Server E/S.
Survie en cas de panne
La base de données tempdb est un espace de scratch pour SQL Server et est reconstruite à chaque démarrage
SQL Server de base de données. L’initialisation a la place de tout besoin de données pour résister à un
redémarrage.
Opérations de réécriture de secteur transactionnel
Pour garantir la réussite des processus de récupération, tels que la restauration et la récupération sur incident,
les enregistrements journaux doivent être correctement stockés sur un support stable avant que la page de
données ne soit stockée et ne peuvent pas être réécrits sans respecter les propriétés transactionnelles. Pour ce
faire, le sous-système et les SQL Server doivent conserver des attributs spécifiques, tels que l’ordre d’écriture,
les écritures alignées sur le secteur et les tailles, ainsi que d’autres attributs de sécurité des E/S décrits dans les
documents mentionnés précédemment. Pour la base de données tempdb, la récupération sur incident est inutile,
car la base de données est toujours initialisée pendant SQL Server démarrage. Toutefois, la base de données
tempdb nécessite toujours des fonctionnalités de récupération. Par conséquent, certains attributs du protocole
WAL peuvent être relâchés.
L’emplacement de stockage de la base de données tempdb doit agir conformément aux protocoles de lecteur de
disque établis. De toutes façons, l’appareil sur lequel la base de données tempdb est stockée doit apparaître et
agir en tant que disque physique fournissant des fonctionnalités de lecture après écriture. Les opérations de
réécriture de secteur de transaction peuvent être une exigence supplémentaire d’implémentations spécifiques.
Par exemple, SQL Server ne prend pas en charge les modifications de base de données à l’aide de la
compression du système de fichiers NTFS, car la compression NTFS peut réécrire les secteurs du journal qui ont
déjà été écrits et considérés comme renforcés. Une défaillance lors de ce type de réécriture peut entraîner
l’inutilisation de la base de données, endommageant ainsi les données qui SQL Server déjà considérées comme
sécurisées.
NOTE
SQL Server 2005 a étendu la prise en charge ou la compression aux bases de données et groupes de fichiers en lecture
seule. Consultez la SQL Server 2005 Books Online pour plus d’informations.
Les opérations de réécriture de secteur transactionnel sont pertinentes pour toutes SQL Server de données qui
incluent la base de données tempdb. De plus en plus de technologies de stockage étendues utilisent des
appareils et des utilitaires qui peuvent réécrire des données qui SQL Server comme étant sécurisées. Par
exemple, certaines technologies émergentes effectuent une mise en cache en mémoire ou une compression de
données. Afin d’éviter de graves dommages de base de données, toute réécriture de secteur doit avoir une prise
en charge transactionnelle complète de telle sorte qu’en cas de défaillance, les données sont revenir aux images
de secteur précédentes. Cela garantit que les SQL Server ne sont jamais exposés à une interruption inattendue
ou à une condition de dommages de données.
Vous pourrez peut-être placer la base de données tempdb sur des sous-systèmes spécialisés, tels que des
disques RAM, un état plein ou d’autres implémentations à haut débit qui ne peuvent pas être utilisées pour
d’autres bases de données. Toutefois, les facteurs clés présentés dans la section « Plus d’informations » doivent
être pris en compte lorsque vous évaluez ces options.
NOTE
Les disques locaux dans les environnements en cluster de failover sont uniquement pris en charge avec des
implémentations à haut débit ou à état plein. Cela est dû au fait que le disque RAM ne peut être créé que sur une cible
iSCSI. En outre, les fonctionnalités de la cible iSCSI et du cluster de failover ne peuvent pas être utilisées sur le même hôte.
Plusieurs facteurs doivent être soigneusement évalués lorsque vous évaluez l’emplacement de stockage de la
base de données tempdb. Par exemple, l’utilisation de la base de données tempdb implique, sans s’y limiter,
l’encombrement mémoire, le plan de requête et les décisions d’O/S. Le réglage et l’implémentation appropriés
de la base de données tempdb peuvent améliorer l’évolutivité et la réactivité d’un système. Cette section décrit
les facteurs clés pour déterminer les besoins en stockage de la base de données tempdb.
Sous-systèmes haut débit
Il existe différentes implémentations de sous-système à haut débit disponibles sur le marché qui fournissent des
exigences de protocole de sous-système d’SQL Server D/S, mais qui ne fournissent pas de dulité du média.
IMPORTANT
Confirmez toujours auprès du fournisseur du produit pour garantir la conformité totale SQL Server besoins en matière
d’O/S.
Un disque RAM est un exemple courant d’une telle implémentation. Les disques RAM installent les pilotes
nécessaires et permettent à une partie du disque RAM principal d’apparaître et de fonctionner comme
n’importe quel lecteur de disque attaché au système. Tous les sous-systèmes d’entrée et de fin d’entreprise
doivent assurer la conformité totale avec SQL Server conditions requises en matière d’entrée et de fin
d’entreprise. Toutefois, il est évident qu’un disque RAM n’est pas un support durable. Par conséquent, une
implémentation telle qu’un disque RAM ne peut être utilisée que comme emplacement de la base de données
tempdb et ne peut être utilisée pour aucune autre base de données.
Clés à prendre en compte avant l’implémentation et le déploiement
Plusieurs points sont à prendre en considération avant le déploiement de la base de données tempdb sur ce
type de sous-système. Cette section utilise un disque RAM comme base de discussion, mais des résultats
similaires se produisent dans d’autres implémentations à haut débit.
Sécurité des I/S
La conformité de la lecture après écritures dans le secteur transactionnel et en écriture est une obligation. Ne
déployez jamais SQL Server sur un système qui ne prend pas entièrement en charge les besoins en matière
d’SQL Server D/S, ou vous risquez d’endommager et de perdre vos données.
Pages déjà mises en cache (cache DE RAM double)
Les tables temporaires sont comme toutes les autres tables d’une base de données. Ils sont mis en cache par le
pool de mémoires tampons et gérés par des opérations d’écriture différée. Le stockage de pages de tableau
temporaires sur un disque RAM entraîne une mise en cache double de ram, une dans le pool de mémoires
tampons et une sur le disque RAM. Cette action s’éloigne directement de la taille totale possible du pool de
mémoires tampons et réduit généralement les performances des SQL Server.
Abandon de la RAM
Le disque RAM désigne une partie de la RAM principale comme son nom l’indique. Plusieurs implémentations
de disques RAM et de caches de fichiers basés sur la RAM sont disponibles. Certaines activent également les
opérations de secours d’opérations d’opérations physiques. L’élément clé du cache de fichiers ram est qu’il
s’éloigne directement de la mémoire physique qui peut être utilisée par les SQL Server. Toujours avoir une
preuve forte que l’ajout d’un cache de fichiers basé sur la RAM améliore les performances de l’application et ne
diminue pas les autres performances de requête ou d’application.
Régler en premier
Une application doit se régler pour supprimer les tris et les hages inutiles et indésirables qui peuvent entraîner
l’utilisation de la base de données tempdb. Souvent, l’ajout d’un index peut supprimer complètement le besoin
de tri ou de hachage dans le plan, ce qui permet d’obtenir des performances optimales sans recourir à la base de
données tempdb.
Points d’avantages possibles
Les avantages de l’utilisation de la base de données tempdb sur un système à haut débit peuvent uniquement
être déterminés par des tests rigoureux et des mesures des charges de travail des applications. La charge de
travail doit être soigneusement mise en avant pour les caractéristiques dont la base de données tempdb peut
bénéficier, et la sécurité des I/S doit être confirmée avant le déploiement.
Les opérations de tri et de hachage fonctionnent avec les gestionnaires de mémoire SQL Server pour
déterminer la taille du scratch en mémoire pour chaque opération de tri ou de hachage. Dès que les données de
tri ou de hachage dépassent la zone de scratch en mémoire allouée, les données peuvent être écrites dans la
base de données tempdb. Cet algorithme a été étendu en SQL Server 2005, réduisant ainsi les exigences
d’utilisation de base de données tempdb par rapport aux versions antérieures de SQL Server.
Cau t i on
SQL Server est conçu pour prendre en compte les niveaux de mémoire et les activités de requête actuelles lors
de la prise de décisions de plan de requête qui impliquent l’utilisation d’opérations de base de données tempdb.
Par conséquent, les gains de performances varient considérablement en fonction des charges de travail et de la
conception des applications. Nous vous recommandons vivement d’effectuer les tests avec la solution préférée
pour déterminer les gains possibles et évaluer les exigences de sécurité des E/S avant un tel déploiement.
SQL Server utilise la base de données tempdb pour gérer diverses activités impliquant des tris, des hages, le
magasin de versions de lignes et des tables temp :
Les tableaux temporaires sont tenus à jour par les routines courantes de pool de mémoires tampons pour les
pages de données et n’offrent généralement pas d’avantages en terme de performances grâce aux
implémentations de sous-système spécialisées.
La base de données tempdb est utilisée comme zone de scratch pour les hèses et les tris. Il peut être utile de
réduire la latence des opérations d’opérations d’I/S. Toutefois, sachez que l’ajout d’un index pour éviter un
hachage ou un tri peut fournir un avantage similaire.
Exécutez les lignes de base avec et sans la base de données tempdb stockée sur le sous-système à haut débit
pour comparer les avantages. Une partie des tests doit inclure des requêtes sur la base de données utilisateur
qui n’impliquent pas de tris, de hésets ou de tables temporaires, puis vérifier que ces requêtes ne sont pas
affectées. Lorsque vous évaluez le système, les indicateurs de performances suivants peuvent être utiles.
IN DIC AT EUR DESC RIP T IO N / UT IL ISAT IO N
Lectures et écritures de pages L’amélioration des performances des systèmes d’exploitation

de base de données tempdb peut modifier le taux de lecture
et d’écriture des pages pour les bases de données utilisateur
en raison de la latence réduite associée aux I/S de base de
données tempdb. Pour les pages de base de données
utilisateur, le nombre global ne doit pas varier sur la même
charge de travail.
Lecture physique et écriture d’octets dans la base de Si le déplacement de la base de données tempdb vers un
données tempdb périphérique, tel qu’un disque RAM, augmente l’I/S réelle de
la base de données tempdb, cela indique que la mémoire qui
a été retiré du pool de mémoires tampons entraîne une
augmentation de l’activité de la base de données tempdb. Ce
modèle est un indicateur que la durée de vie des pages de
base de données peut également être affectée de manière
négative.
IN DIC AT EUR DESC RIP T IO N / UT IL ISAT IO N
Durée de vie des pages Un déclin de la durée de vie des pages peut indiquer une
augmentation des besoins physiques en matière
d’entrée/de-fin d’une base de données utilisateur. La
diminution du taux peut indiquer que la mémoire qui a été
retiré du pool de mémoires tampons force les pages de base
de données à quitter prématurément le pool de mémoires
tampons. Combinez-les avec les autres indicateurs et testez
pour bien comprendre les limites des paramètres.
Débit global L’objectif principal d’une modification de configuration de

Utilisation du processeur base de données tempdb est d’augmenter le débit global.
Extensibilité Vos tests doivent inclure une combinaison de charges de
Temps de réponse travail répétables qui peuvent être réduites pour déterminer
l’impact du débit.
Une implémentation de disque RAM basée sur la

compression peut fonctionner avec 10 utilisateurs. Toutefois,
avec une charge de travail accrue, cela peut pousser les
niveaux de processeur au-delà des niveaux souhaités et avoir
des effets négatifs sur le temps de réponse lorsque les
charges de travail sont élevées. Les tests de contrainte réels
et futurs tests de prévision de charge sont encouragés.
Fichiers de travail et actions de création de table de travail Si le déplacement de la base de données tempdb vers un
périphérique, tel qu’un disque RAM, modifie le plan de
requête en augmentant le nombre ou la taille des fichiers de
travail ou des tables de travail, cela indique que la mémoire
qui a été retiré du pool de mémoire tampon entraîne une
augmentation de l’activité de la base de données tempdb. Ce
modèle indique que la durée de vie des pages de base de
données peut également être affectée de manière négative.
Exemple de réécriture de secteur transactionnel

L’exemple suivant élabore la sécurité des données requise par les bases SQL Server données.
Supposons qu’un fournisseur de disque RAM utilise une implémentation de compression en mémoire.
L’implémentation doit être correctement encapsulée en fournissant l’apparence physique du flux de fichiers
comme si le secteur était aligné et resserré afin que SQL Server ne soit pas conscient et correctement sécurisé
de l’implémentation sous-jacente. Regardez l’exemple de compression de plus près.
O P ÉRAT IO N
Le secteur 1 est écrit sur l’appareil et compressé pour économiser de l’espace.
Le secteur 2 est écrit sur l’appareil et compressé avec le secteur 1 pour économiser de l’espace.
L’appareil peut effectuer les actions suivantes pour sécuriser les données du secteur 1 lorsqu’il est combiné aux
données du secteur 2.
O P ÉRAT IO N
Bloquer toutes les écritures dans les secteurs 1 et 2.

O P ÉRAT IO N
Décompressez le secteur 1 dans une zone de scratch, en laissant le secteur actuel 1 stockage en tant que données actives à
récupérer.
Compressez les secteurs 1 et 2 dans un nouveau format de stockage.
Bloquez toutes les lectures et écritures des secteurs 1 et 2.
Exchange ancien stockage pour les secteurs 1 et 2 avec un nouveau stockage.
En cas d’échec de la tentative d’échange (rollback) :

Restituer le stockage d’origine pour les secteurs 1 et 2.
Supprimez les secteurs 1 et 2 données combinées du point de scratch.
Échec de l’opération d’écriture du secteur 2.
Débloquer les lectures et les écritures pour les secteurs 1 et 2.
La possibilité de fournir des mécanismes de verrouillage autour des modifications du secteur et d’y faire
échouer les modifications en cas d’échec de la tentative d’échange de secteur est considérée comme conforme
de manière temporaire. Pour les implémentations qui utilisent le stockage physique pour le stockage étendu, il
inclut les aspects appropriés du journal des transactions pour sécuriser et récupérer les modifications qui ont
été appliquées aux structures sur disque afin de maintenir l’intégrité des fichiers de base de données SQL
Server.
Tout appareil qui permet la réécriture de secteurs doit prendre en charge les réécritures d’une manière
transactionnelle afin que SQL Server ne soit pas exposé à la perte de données.
NOTE
L’instance de SQL Server est redémarré lorsque des échecs d’I/S et de reprise en ligne se produisent dans la base de
données tempdb.
Soyez prudent lorsque vous déplacez la base de données tempdb

Soyez prudent lorsque vous déplacez la base de données tempdb, car si la base de données tempdb ne peut pas
être créée, SQL Server ne démarre pas. Si la base de données tempdb ne peut pas être créée, démarrez SQL
Server à l’aide du paramètre de démarrage (-f) et déplacez la base de données tempdb vers un emplacement
valide.
Pour modifier l’emplacement physique de la base de données tempdb, suivez les étapes suivantes :
1. Utilisez l’instruction et la clause MODIFY FILE pour modifier les noms de fichiers physiques de chaque
fichier dans la base de données tempdb afin de faire référence au nouvel emplacement physique, tel que
ALTER DATABASE le nouveau disque.
Alter database tempdb modify file

(name = tempdev, filename = 'C:\MyPath\tempdb.mdf')
Alter database tempdb modify file

(name = templog, filename = 'C:\MyPath\templog.ldf')
2. Arrêtez, puis redémarrez SQL Server.

Les certifications de produits partenaires ne sont pas une question de compatibilité ou de sécurité
Un produit tiers ou un fournisseur particulier peut recevoir une certification de logo Microsoft. Toutefois, la
certification des partenaires ou un logo Microsoft spécifique ne certifie pas la compatibilité ou l’aptitude à un
objectif particulier dans SQL Server.
Support
Si vous utilisez un sous-système avec SQL Server qui prend en charge les garanties d’opérations d’SQL Server
pour l’utilisation des bases de données transactionnelles, comme décrit dans cet article, Microsoft prend en
charge les applications basées sur SQL Server et SQL Server. Toutefois, les problèmes avec le sous-système ou
causés par celui-ci sont renvoyés au fabricant.
Pour les problèmes liés à la base de données tempdb, les services de support Microsoft vous demanderont de
déplacer la base de données tempdb. Contactez le fournisseur de votre appareil pour vérifier que vous avez
correctement déployé et configuré l’appareil pour une utilisation de base de données transactionnelle.
Microsoft ne certifie pas ou ne valide pas que les produits tiers fonctionnent correctement avec SQL Server. En
outre, Microsoft ne fournit aucune garantie, aucune garantie ou déclaration de l’aptitude d’un produit tiers à être
utilisé avec SQL Server.
Références
Pour plus d’informations, cliquez sur les numéros d’article suivants pour afficher les articles de la Base de
connaissances Microsoft :
Ajout SQL Server diagnostics supplémentaires pour détecter les problèmes d’I/S non signalés
Le message d’erreur 823 peut indiquer des problèmes matériels ou système dans SQL Server
Utilisation de la mise en cache des disques avec SQL Server
Description de la prise en charge des fichiers de base de données réseau dans SQL Server
Microsoft ne certifie pas que les produits tiers fonctionneront avec Microsoft SQL Server
Recommandations en matière de performances SQL Server sur les machines virtuelles Azure
Optimisation de vos plans de requête avec l’estimateur SQL Server Cardinality 2014
Performances des requêtes
Les informations contenues dans ce document représentent l’affichage actuel de Microsoft Corporation sur les
problèmes abordés à la date de publication. Étant donné que Microsoft doit répondre à l’évolution des
conditions du marché, il ne doit pas être interprété comme un engagement de la part de Microsoft, et Microsoft
ne peut pas garantir la précision des informations présentées après la date de publication.
Ce livre blanc est uniquement à des fins d’information. MICROSOFT N’OFFRE AUCUNE GARANTIE, EXPRESS,
IMPLICITE OU STATUTAIRE, CONCERNANT LES INFORMATIONS DE CE DOCUMENT.
L’utilisateur est tenu d’observer la réglementation relative aux droits d’auteur applicable dans son pays. Aucune
partie de ce document ne peut être reproduite, stockée ou introduite dans un système de restitution, ou
transmise à quelque fin ou par quelque moyen que ce soit (électronique, mécanique, photocopie,
enregistrement ou autre) sans la permission expresse et écrite de Microsoft Corporation.
Microsoft peut détenir des brevets, avoir déposé des demandes d’enregistrement de brevets ou être titulaire de
marques, droits d’auteur ou autres droits de propriété intellectuelle portant sur tout ou partie des éléments qui
font l’objet du présent document. Sauf stipulation expresse contraire d’un contrat de licence écrit de Microsoft, la
fourniture de ce document n’a pas pour effet de vous concéder une licence sur ces brevets, marques, droits
d’auteur ou autres droits de propriété intellectuelle.
© 2006 Microsoft Corporation. Tous droits réservés.
Microsoft, Windows, Windows Server et SQL Server sont des marques déposées ou des marques de Microsoft
Corporation aux États-Unis et/ou dans d’autres pays.
SQL Server systèmes doivent prendre en charge la « distribution garantie sur les supports stables » comme
indiqué dans la SQL Server des programmes de fiabilité des SQL Server’entreprise. Pour plus d’informations sur
les exigences en matière d’entrée et de sortie pour le moteur SQL Server base de données, voir Moteur de base
de données Microsoft SQL Server input/output requirements.
Améliorer les performances des requêtes en texte
intégral dans SQL Server
Cet article fournit une méthode pour améliorer les performances des requêtes qui utilisent des prédicats en
texte intégral SQL Server.
Version du produit d’origine : SQL Server 2008 Developer, SQL Server 2008 Enterprise, SQL Server 2008 R2
Datacenter, SQL Server 2008 R2 Developer, SQL Server 2008 R2 Enterprise, SQL Server 2008 R2 Standard, SQL
Server 2012 Developer, SQL Server 2012 Standard, SQL Server 2012 Web, SQL Server 2012 Enterprise
Résumé
Cet article décrit une méthode pour améliorer les performances des requêtes Microsoft SQL Server qui utilisent
des prédicats de recherche en texte intégral (tels que et ) et qui filtrent également CONTAINS CONTAINSTABLE les
données. Par exemple, cette méthode améliore les performances de la requête suivante :
select * from dbo.ftTest where CONTAINS(TextData, '"keyword"') and CDate > @date
Cette méthode vous permet de concevoir la requête, le schéma de table et l’index de texte intégral de telle sorte
que le moteur de recherche en texte intégral filtre les résultats avant qu’ils ne soient envoyés au moteur
relationnel. Par conséquent, le moteur relationnel n’a pas besoin de filtrer un jeu de données de grande taille.
Lorsque vous créez une requête de recherche en texte intégral, le facteur principal qui affecte les performances
de la requête est la quantité de données que le moteur de recherche en texte intégral doit traiter avant que les
données restantes ne sont envoyées au moteur relationnel. Dans SQL Server, vous pouvez améliorer les
performances de la requête en filtrant les lignes tôt pour réduire le nombre de lignes qui doivent être traitées
ultérieurement.
Dans les versions de SQL Server publiées avant SQL Server 2008, le moteur de recherche en texte intégral
renvoie toutes les lignes qui correspondent à un terme de recherche, puis le moteur relationnel applique tous
les filtres. Des améliorations ont été apportées à ce comportement SQL Server 2008, SQL Server 2008 R2 et
SQL Server 2012. Toutefois, il est difficile d’utiliser ces améliorations, car les index de recherche en texte intégral
sont organisés différemment des index de base de données. En outre, le moteur de recherche en texte intégral et
le moteur relationnel fonctionnent différemment. Par conséquent, la méthode que cet article décrit utilise la
fonction (TVF) pour filtrer les lignes tôt et pour réduire le nombre de lignes qui doivent être Table-Valued
traitées ultérieurement.
Par exemple, le plan de requête suivant renvoie 131051 lignes qui correspondent à une CONTAINS chaîne de
recherche. En outre, un opérateur de jointur dans le plan effectue un filtrage supplémentaire à l’aide d’une
recherche d’index.
Rows StmtText
-------------------- ---------------------------------------------------------------------------------------
-
1167 select CDate, ID from dbo.fttest where contains (c2, '"create"') and CDate> '08/05/2019'
1167 |--Merge Join(Left Semi Join, MERGE:([FTSdb].[dbo].[fttest].[ID])=(FulltextMatch.[docid]), RESIDUA

5858 |--Sort(ORDER BY:([FTSdb].[dbo].[fttest].[ID] ASC))
5858 | |--Clustered Index Seek(OBJECT:([FTSdb].[dbo].[fttest].[clidx1]), SEEK:([FTSdb].[
131051 |--Table-valued function
Toutefois, si la requête inclut la colonne de clé d’index unique en texte intégral en tant que prédicat, le moteur de
recherche en texte intégral peut utiliser le prédicat pour filtrer les résultats au niveau du texte intégral. Dans ce
cas, tvf renvoie une quantité de données beaucoup plus petite avant que le filtrage supplémentaire ne soit
appliqué. Par exemple, la requête suivante spécifie cinq valeurs qui doivent correspondre à la condition c2, et le
tvf renvoie uniquement les résultats qui correspondent aux cinq valeurs :
Rows StmtText
------------------------------------------------------------------------------------------------------------
-------------------------------
5 select CDate, ID from dbo.fttest where contains (c2, '"create"') and CDate > '08/05/2019' and ID in (
654051, 644051, 649106, 465, 105)
5 |--Nested Loops(Left Semi Join, OUTER REFERENCES:([FTSdb].[dbo].[fttest].[ID]))

5 |--Index Seek(OBJECT:([FTSdb].[dbo].[fttest].[idx1]), SEEK:([FTSdb].[dbo].[fttest].[ID]=(105) OR ...
5 |--Table-valued function
La capacité du moteur de recherche en texte intégral à faire descendre les valeurs utilisées par la clé d’index
unique est la base de la méthode suivante.
Si un prédicat contient une colonne de type de données, vous pouvez inclure des informations de date dans la
colonne de clé d’index unique afin que seules les lignes qui correspondent à ce DateTime prédicat soient émises.
Pour ce faire, vous devez incorporer logiquement les informations de date dans la colonne clé. Toutefois, vous de
devez également modifier le type de données de colonne clé et les applications qui utilisent la requête.
Pour implémenter la méthode, modifiez le type de données de l’ID de clé unique en texte intégral en BIGINT. Les
4 premiers octets de l’ID clé capturent les valeurs d’année, de mois et de date de la colonne de date, et les 4
derniers octets restent identiques. Par exemple, le premier octet de l’ID de clé peut faire référence à l’année,
l’octet suivant peut faire référence au mois et les 2 derniers octets peuvent faire référence à la date. L’application
doit prendre en charge ce changement de type de données.
Ensuite, traduisez un prédicat de plage en prédicat sur l’ID de clé. Par exemple, le x < CDate < y prédicat de
plage peut être traduit dans (x*2^32 < ID < y*2^32) le prédicat. Étant donné que le prédicat traduit est un
prédicat sur la touche de texte intégral, le prédicat est envoyé dans le texte intégral Streaming Table-Valued
Functions (STVF). Ce comportement effectue efficacement des recherches dans la plage de dates.
Message d’erreur lorsque vous exécutez l’instruction
DBCC CHECKDB sur une base de données qui
contient une ou plusieurs tables très grandes dans
SQL Server : Le délai d’attente s’est produit pendant
l’attente d’un verrou
Cet article présente un problème dans lequel vous recevez un message d’erreur lorsque vous essayez d’exécuter
l’instruction sur une base de données qui contient une DBCC CHECKDB grande table dans SQL Server.
Version du produit d’origine : SQL Server 2012, SQL Server 2008
Symptômes
Vous avez une base de données qui contient une ou plusieurs tables très grandes.
La taille des tableaux est généralement de plusieurs centaines de gigaoctets (Go).
Vous exécutez l’instruction CHECKDB DBCC sur la base de données dans SQL Server.
Dans ce scénario, un message d’erreur semblable à ce qui suit est écrit dans le journal SQL Server’erreurs :
<DateTime> Spid65 Timeout occurred while waiting for latch: class 'DBCC_MULTIOBJECT_SCANNER', id
00000002201DED0, type 4, Task 0x000000000C80BEB8 : 6, waittime 300, flags 0xa, owning task
0x0000000005A0AC58. Continue d’attendre.
Toutefois, DBCC CHECKDB l’instruction se termine correctement. Vous pouvez ignorer le message d’erreur en toute
sécurité.
Cause
Ce problème se produit parce qu’un délai d’SQL Server passe par les chaînes IAM (Index Allocation Map). Le
verrou mentionné dans le message d’erreur est utilisé pour empêcher d’autres threads d’accéder à une liste.
Cette liste est construite par un thread qui parcourt les chaînes IAM pour tous les index associés à un tableau
donné. Si la table est suffisamment grande pour que la traversée de ces chaînes IAM prenne plus de 5 minutes,
vous pouvez faire l’expérience du délai d’verrouillage. En outre, ce problème est généralement pire lorsque les
I/S disque sont lents.
Statut
S’applique à
SQL Server Développeur 2008
SQL Server 2008 Express
SQL Server 2008 Express avec services avancés
SQL Server 2008 R2 Datacenter
SQL Server 2008 R2 Developer
SQL Server 2008 R2 Enterprise
SQL Server 2008 R2 Express
SQL Server 2008 R2 Express avec services avancés
SQL Server 2008 R2 Standard
SQL Server 2008 R2 Édition Standard for Small Business
SQL Server 2008 R2 Web
SQL Server 2008 R2 Workgroup
SQL Server 2008 Standard
SQL Server Web 2008
SQL Server 2008 Workgroup
SQL Server Web 2012
SQL Server 2012 Enterprise Core
Description des algorithmes de journalisation et de
stockage des données qui étendent la fiabilité des
données SQL Server
Résumé
Cet article explique comment la journalisation Microsoft SQL Server et les algorithmes de données étendent la
fiabilité et l’intégrité des données.
Pour en savoir plus sur les concepts sous-jacents des moteurs et sur ARIES (Algorithm for Recovery and
Isolation Exploiting Sémantics), voir le document transactions ACM suivant sur les systèmes de base de données
(sous Volume 17, Numéro 1, mars 1992) :
ARIES : une méthode de récupération des transactions prise en charge Fine-Granularity verrouillage et
restaurations partielles à l’aide de la journalisation Write-Ahead journalisation
Le rédacteur principal de ce document est C. Mohan. Le document traite des techniques SQL Server pour
étendre la fiabilité et l’intégrité des données en relation avec les défaillances.
Nous vous recommandons de lire les articles suivants de la Base de connaissances Microsoft pour plus
d’informations sur la mise en cache et les discussions sur les modes d’échec alternatifs :
Description de la mise en cache des contrôleurs de disque dans SQL Server
Informations sur l’utilisation de caches de disque avec des SQL Server que chaque administrateur de
base de données doit connaître
Avant de commencer la discussion approfondie, certains des termes utilisés tout au long de cet article sont
définis dans le tableau suivant.
T ERM E DÉF IN IT IO N
Batterie Installation de sauvegarde de batterie distincte et localisée

directement disponible et contrôlée par le mécanisme de
mise en cache pour éviter la perte de données.
Il ne s’agit pas d’un système UPS (Uninterruptible Power
Supply). Un ups ne garantit aucune activité d’écriture et peut
être déconnecté du périphérique de mise en cache.
Cache Mécanisme de stockage intermédiaire utilisé pour optimiser

les opérations d’opérations physiques et améliorer les
performances.
T ERM E DÉF IN IT IO N
Dirty Page Page contenant les modifications de données qui n’ont pas
encore été vidées vers un stockage stable. Pour plus
d’informations sur les tampons de page sales, consultez la
rubrique « Écriture depages» SQL Server Books Online.
Le contenu s’applique également Microsoft SQL Server 2012
et versions ultérieures.
Échec Tout ce qui peut provoquer une panne inattendue du

processus de SQL Server de travail. Exemples : panne
d’alimentation, réinitialisation de l’ordinateur, erreurs de
mémoire, autres problèmes matériels, secteurs de mauvaise
qualité, pannes de disque, défaillances système, etc.
Flush Forçage d’une mémoire tampon de cache vers un stockage

stable.
Verrou Objet de synchronisation utilisé pour protéger la cohérence

physique d’une ressource.
Stockage nonvolatile Tout support qui reste disponible en cas de défaillance du

système.
Page épinglée Page qui reste dans le cache de données et ne peut pas être
vidée vers un stockage stable tant que tous les
enregistrements journaux associés ne sont pas sécurisés
dans un emplacement de stockage stable.
Stockage stable Identique au stockage nonvolatile.
Stockage volatile Tout support qui ne restera pas intact en cas d’échec.
protocole Write -Ahead Logging (WAL )

Le terme protocole est un excellent moyen de décrire LAR. Il s’agit d’un ensemble spécifique et défini d’étapes
d’implémentation nécessaires pour s’assurer que les données sont stockées et échangées correctement et
qu’elles peuvent être récupérées à un état connu en cas de défaillance. Tout comme un réseau contient un
protocole défini pour échanger des données de manière cohérente et protégée, le RÉSEAU d’échange de
données décrit également le protocole pour protéger les données.
Le document ARIES définit la loi DER comme suit :
Le protocole WAL indique que les enregistrements journaux représentant les modifications apportées à
certaines données doivent déjà se trouver dans un stockage stable avant que les données modifiées ne soient
autorisées à remplacer la version précédente des données dans un stockage nonvolatile. Autrement dit, le
système n’est pas autorisé à écrire une page mise à jour dans la version de stockage nonvolatile de la page tant
qu’au moins les parties d’annuler les enregistrements du journal, qui décrivent les mises à jour de la page, n’ont
pas été écrites dans un stockage stable.
Pour plus d’informations sur la journalisation à l’avance, consultez la rubrique Write-Ahead Transaction Log SQL
Server Books Online.
SQL Server et LAS
SQL Server utilise le protocole WAL. Pour s’assurer qu’une transaction est correctement committede, tous les
enregistrements journaux associés à la transaction doivent être sécurisés dans un stockage stable.
Pour clarifier cette situation, prenons l’exemple spécifique suivant.
NOTE
Pour cet exemple, supposons qu’il n’y a pas d’index et que la page concernée est la page 150.
BEGIN TRANSACTION
INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
Ensuite, décomposez l’activité en étapes de journalisation, comme décrit dans le tableau suivant.
STAT EM EN T A C T IO N S EF F EC T UÉES
BEGIN TRANSACTION Écrit dans la zone de cache du journal. Toutefois, il n’est pas
nécessaire de vider le stockage stable, car le SQL Server n’a
pas apporté de modifications physiques.
INSERT INTO tblTest

1. La page de données 150 est récupérée dans SQL Server
cache de données, si elle n’est pas déjà disponible.
2. La page est verrouillée, épinglée et marquée comme «
dirty » et les verrous appropriés sont obtenus.
3. Un enregistrement Insérer un journal est créé et ajouté au
cache du journal.
4. Une nouvelle ligne est ajoutée à la page de données.
5. Le verrou est relâché.
6. Les enregistrements journaux associés à la transaction ou
à la page n’ont pas besoin d’être vidés à ce stade, car toutes
les modifications restent dans un stockage volatile.
VALIDER LA TRANSACTION
1. Un enregistrement du journal de validation est créé et les
enregistrements journaux associés à la transaction doivent
être écrits dans un stockage stable. La transaction n’est pas
considérée comme étant engager tant que les
enregistrements journaux ne sont pas correctement affectés
à un stockage stable.
2. La page de données 150 reste dans SQL Server cache de
données et n’est pas immédiatement vidée vers un stockage
stable. Lorsque les enregistrements journaux sont
correctement sécurisés, la récupération peut rétablir
l’opération, si nécessaire.
3. Les verrous transactionnels sont libérés.
Ne vous confondez pas avec les termes « verrouillage » et « journalisation ». Bien qu’il soit important, le
verrouillage et la journalisation sont des problèmes distincts lorsque vous traitez la clé d’enregistrement en cas
de problème. Dans l’exemple précédent, SQL Server place généralement le verrou sur la page 150 pour le temps
nécessaire pour effectuer les modifications d’insertion physique sur la page, et non pendant toute la durée de la
transaction. Le type de verrou approprié est établi pour protéger la ligne, la plage, la page ou le tableau si
nécessaire. Pour plus d’informations sur les types de verrous, reportez-vous SQL Server sections de verrouillage
Books Online.
Si vous regardez l’exemple plus en détail, vous pouvez vous demander ce qui se produit lorsque les processus
LazyWriter ou CheckPoint s’exécutent. SQL Server tous les purges appropriés vers un stockage stable pour les
enregistrements journaux transactionnels associés à la page sales et épinglées. Cela permet de s’assurer que la
page de données du protocole WAL ne peut jamais être écrite dans un stockage stable tant que les
enregistrements journaux transactionnels associés n’ont pas été vidés.
SQL Server stockage stable et stable
SQL Server améliore les opérations de page de données et de journal en incluant la connaissance des tailles de
secteur de disque (généralement 4 096 octets ou 512 octets).
Pour conserver les propriétés DE LASO d’une transaction, l’SQL Server doit tenir compte des points d’échec. En
cas de défaillance, de nombreuses spécifications de disque ne garantissent qu’un nombre limité d’opérations
d’écriture de secteur. La plupart des spécifications garantissent la réalisation d’une écriture à secteur unique en
cas de défaillance.
SQL Server utilise des pages de données de 8 Ko et le journal (s’il est vidé) sur des multiples de la taille du
secteur. (La plupart des lecteurs de disque utilisent 512 octets comme taille de secteur par défaut.) En cas de
défaillance, les SQL Server peuvent prendre en compte des opérations d’écriture plus importantes qu’un secteur
en retentant la parité de journal et en faisant appel à des techniques d’écriture de nettoyage.
Détection de page de resserr
Cette option permet de détecter SQL Server opérations d’exploitation incomplètes provoquées par des pannes
de courant ou d’autres pannes du système. Lorsque la valeur est True, un bit est retourné pour chaque secteur
de 512 octets dans une page de base de données de 8 kilo-octets (Ko) chaque fois que la page est écrite sur le
disque. Si un bit se trouve dans un état incorrect lorsque la page est lue par SQL Server, la page a été écrite de
manière incorrecte . une page de papier est détectée. Les pages pleines sont détectées pendant la récupération,
car toute page écrite de manière incorrecte est susceptible d’être lue par la récupération.
Bien SQL Server pages de base de données soient de 8 Ko, les disques effectuent des opérations d’entreprise à
l’aide d’un secteur de 512 byte. Par conséquent, 16 secteurs sont écrits par page de base de données. Une page
pleine peut se produire si le système tombe en panne (par exemple, en raison d’une panne d’alimentation) entre
le moment où le système d’exploitation écrit le premier secteur de 512 byte sur le disque et la fin de l’opération
d’E/S de 8 Ko. Si le premier secteur d’une page de base de données est correctement écrit avant la défaillance, la
page de base de données sur le disque s’affiche comme mise à jour, bien qu’elle n’a peut-être pas réussi.
En utilisant des caches de contrôleurs de disque avec batterie, vous pouvez vous assurer que les données sont
écrites correctement sur le disque ou qu’elles ne sont pas écrites du tout. Dans ce cas, ne définissez pas la
détection de page de recherche sur « true », car cela n’est pas nécessaire.
NOTE
La détection des pages de recherche n’est pas activée par défaut dans SQL Server. Pour plus d’informations, voir le site
web MSDN suivant :
ALTER DATABASE SET Options (Transact-SQL)

Parité de journal
La vérification de la parité des journaux est similaire à la détection de page de ressaisie. Chaque secteur de 512
caractères contient des bits de parité. Ces bits de parité sont toujours écrits avec l’enregistrement journal et
évalués lors de la récupération de l’enregistrement journal. En forçant les écritures des journaux sur une limite
de 512 SQL Server, les opérations de validation sont écrites sur les secteurs de disque physique.
Impact sur les performances
Toutes les versions SQL Server ouvrir les fichiers journaux et de données à l’aide de la fonction Win32
CreateFile. Le membre dwFlagsAndAttributes inclut l’option lorsqu’ils sont ouverts FILE_FLAG_WRITE_THROUGH par
SQL Server.
FILE_FLAG_WRITE_THROUGH
Indique au système d’écrire via n’importe quel cache intermédiaire et d’aller directement sur le disque. Le
système peut toujours mettre en cache les opérations d’écriture, mais ne peut pas les vider.
L’option permet de s’assurer que lorsqu’une opération d’écriture renvoie une exécution réussie, les données sont
correctement stockées FILE_FLAG_WRITE_THROUGH dans un stockage stable. Cela s’aligne sur le protocole WAL qui
garantit les données.
De nombreux disques (SCSI et IDE) contiennent des caches intégrés de 512 Ko, 1 Mo ou plus. Toutefois, les
caches de disque reposent généralement sur un chargeur et non sur une solution avec batterie. Ces mécanismes
de mise en cache ne peuvent pas garantir des écritures sur un cycle d’alimentation ou un point de défaillance
similaire. Elles garantissent uniquement la fin des opérations d’écriture de secteur. C’est précisément pourquoi la
détection de parité d’écriture et de journal de construction a été intégrée SQL Server 7.0 et versions ultérieures.
À mesure que la taille des lecteurs augmente, les caches deviennent plus volumineux et peuvent exposer des
quantités de données plus importantes en cas de défaillance.
De nombreux fournisseurs de matériel fournissent des solutions de contrôleur de disque avec batterie. Ces
caches de contrôleurs peuvent conserver les données dans le cache pendant plusieurs jours et même permettre
au matériel de mise en cache d’être placé sur un deuxième ordinateur. Lorsque l’alimentation est correctement
restaurée, les données non écrites sont vidées avant que l’accès aux données supplémentaire ne soit autorisé.
Bon nombre d’entre elles permettent d’établir un pourcentage de cache de lecture ou d’écriture pour des
performances optimales. Certaines contiennent des zones de stockage de mémoire importantes. En fait, pour un
segment spécifique du marché, certains fournisseurs de matériel fournissent des systèmes de contrôleurs de
mise en cache de disque haute batterie avec 6 Go de cache. Celles-ci peuvent améliorer considérablement les
performances de la base de données.
Les implémentations de mise en cache avancées gèrent la demande en ne désactivant pas le cache du
contrôleur, car elles peuvent fournir de réelles fonctionnalités de réécriture en cas de réinitialisation du système,
de panne d’alimentation ou d’un autre FILE_FLAG_WRITE_THROUGH point d’échec.
Les transferts d’I/S sans l’utilisation d’un cache peuvent être plus longs en raison du temps mécanique
nécessaire pour déplacer les têtes de lecteur, les vitesses de rotation et d’autres facteurs limitants.
Ordre des secteurs
L’ordre des secteurs est une technique courante utilisée pour accroître les performances des O/S. Pour éviter les
mouvements mécaniques de la tête, les demandes de lecture/écriture sont triées, ce qui permet de récupérer ou
de stocker des données dans un mouvement plus cohérent de la tête.
Le cache peut contenir plusieurs demandes d’écriture de données et de journaux en même temps. Le protocole
WAL et l SQL Server de mise en œuvre du protocole WAL nécessitent le purgement des écritures du journal
dans un stockage stable avant que l’écriture de page puisse être émise. Toutefois, l’utilisation du cache peut
renvoyer le succès d’une demande d’écriture de journal sans que les données ne sont écrites sur le lecteur réel
(c’est-à-dire, écrites dans un stockage stable). Cela peut entraîner l’SQL Server la demande d’écriture de page de
données.
Avec l’implication du cache d’écriture, les données sont toujours considérées comme étant dans un stockage
volatile. Toutefois, à partir de l’appel WriteFile de l’API Win32, exactement SQL Server l’activité, un code de
retour réussi a été obtenu. SQL Server ou tout processus qui utilise l’appel d’API WriteFile peut déterminer
uniquement que les données ont correctement obtenu un stockage stable.
À des fins de discussion, supposons que tous les secteurs de la page de données sont triés pour être écrits avant
les secteurs des enregistrements journaux correspondants. Cela enfreint immédiatement le protocole WAA. Le
cache écrit une page de données avant les enregistrements du journal. À moins que le cache ne soit entièrement
alimenté par la batterie, une défaillance peut entraîner des résultats catastrophiques.
Lorsque vous évaluez les facteurs de performances optimaux pour un serveur de base de données, de
nombreux facteurs sont à prendre en compte. Le plus important est la question « Mon système autorise-t-il des
FILE_FLAG_WRITE_THROUGH fonctionnalités valides ? »
NOTE
Tout cache que vous utilisez doit entièrement prendre en charge une solution avec batterie. Tous les autres mécanismes
de mise en cache sont suspectés d’altération des données et de perte de données. SQL Server fait tout son possible pour
garantir la mise à jour de la qualité de l’accès en activant FILE_FLAG_WRITE_THROUGH .
Les tests ont montré que de nombreuses configurations de disque dur peuvent contenir une mise en cache
d’écriture sans la sauvegarde de batterie appropriée. Les lecteurs SCSI, IDE et EIDE tirez pleinement parti des
caches d’écriture. Pour plus d’informations sur la façon dont les SSD fonctionnent avec SQL Server, consultez
l’article du blog CSS SQL Server Engineers :
SQL Server et SSD - Notes de Learning RDORR - Partie 1
Dans de nombreuses configurations, le seul moyen de désactiver correctement la mise en cache d’écriture d’un
lecteur IDE ou EIDE est d’utiliser un utilitaire de fabricant spécifique ou des jumpers situés sur le lecteur lui-
même. Pour vous assurer que le cache d’écriture est désactivé pour le lecteur lui-même, contactez le fabricant
du lecteur.
Les lecteurs SCSI ont également des caches d’écriture. Toutefois, ces caches peuvent généralement être
désactivés par le système d’exploitation. En cas de question, contactez le fabricant du lecteur pour obtenir les
utilitaires appropriés.
Écriture de l’empilement de cache
L’empilement du cache d’écriture est similaire au secteur. La définition suivante a été directement tirée du site
web d’un fabricant de disque IDE de premier plan :
Normalement, ce mode est actif. Le mode cache d’écriture accepte les données d’écriture de l’hôte dans la
mémoire tampon jusqu’à ce que la mémoire tampon soit pleine ou que le transfert de l’hôte soit terminé.
Une tâche d’écriture de disque commence à stocker les données hôtes sur le disque. Les commandes d’écriture
de l’hôte continuent d’être acceptées et les données transférées vers la mémoire tampon jusqu’à ce que la pile
de commandes d’écriture soit pleine ou que la mémoire tampon de données soit pleine. Le lecteur peut réorder
les commandes d’écriture pour optimiser le débit du lecteur.
Réaffectation automatique d’écriture (AWR )
Une autre technique courante utilisée pour protéger les données consiste à détecter les secteurs de mauvaise
qualité lors de la manipulation des données. L’explication suivante provient du site web d’un fabricant de disque
IDE de premier plan :
Cette fonctionnalité fait partie du cache d’écriture et réduit le risque de perte de données pendant les opérations
d’écriture différée. Si une erreur de disque se produit pendant le processus d’écriture du disque, la tâche du
disque s’arrête et le secteur suspect est réaffecté à un pool de secteurs alternatifs situés à la fin du lecteur. Après
la réaffectation, la tâche d’écriture de disque se poursuit jusqu’à ce qu’elle soit terminée.
Cette fonctionnalité peut être puissante si la sauvegarde de batterie est fournie pour le cache. Cela permet une
modification appropriée au redémarrage. Il est préférable de détecter les erreurs de disque, mais la sécurité des
données du protocole WAL nécessiterait une nouvelle fois que cette action soit effectuée en temps réel et non de
manière différée. Dans les paramètres WR, la technique AWR ne peut pas tenir compte d’une situation dans
laquelle une écriture de journal échoue en raison d’une erreur de secteur, mais le lecteur est plein. Le moteur de
base de données doit immédiatement connaître la défaillance afin que la transaction puisse être correctement
abandonnée, que l’administrateur puisse être averti et que les mesures appropriées soient prises pour sécuriser
les données et corriger la situation de défaillance multimédia.
Sécurité des données
Un administrateur de base de données doit prendre plusieurs précautions pour garantir la sécurité des données.
Il est toujours bon de s’assurer que votre stratégie de sauvegarde est suffisante pour récupérer après une
défaillance catastrophique. Le stockage hors site et d’autres précautions sont appropriés.
Testez régulièrement l’opération de restauration de base de données dans une base de données secondaire
ou de test.
Assurez-vous que tous les périphériques de mise en cache peuvent gérer toutes les situations de panne
(coupure de courant, secteurs mauvais, lecteurs de mauvaises commandes, panne du système, verrouillages,
pics d’alimentation, et ainsi de suite).
Assurez-vous que votre périphérique de mise en cache :
A intégré la sauvegarde de batterie
Peut rééditer des écritures lors de l’alimentation
Peut être entièrement désactivé si nécessaire
Gère le remappage de secteurs non bon en temps réel
Activer la détection de pages de découverte. (Cela a peu d’effet sur les performances.)
Configurez les lecteurs RAID permettant un échange à chaud d’un lecteur de disque défectueux, si possible.
Utilisez des contrôleurs de mise en cache plus nouveaux qui vous permet d’ajouter davantage d’espace
disque sans redémarrer le système d’exploitation. Il peut s’agit d’une solution idéale.
Lecteurs de test
Pour sécuriser entièrement vos données, vous devez vous assurer que la mise en cache des données est
correctement gérée. Dans de nombreux cas, vous devez désactiver la mise en cache d’écriture du lecteur de
disque.
NOTE
Assurez-vous qu’un autre mécanisme de mise en cache peut gérer correctement plusieurs types d’échec.
Microsoft a effectué des tests sur plusieurs lecteurs SCSI et IDE à l’aide de SQLIOSim l’utilitaire. Cet utilitaire
simule une activité de lecture/écriture asynchrone importante sur un périphérique de données et un
périphérique de journal simulés. Les statistiques de performances des tests indiquent les opérations d’écriture
moyennes par seconde entre 50 et 70 pour un lecteur dont la mise en cache d’écriture est désactivée et une
plage de temps de travail par minute entre 5 200 et 7 200.
Pour plus d’informations sur SQLIOSim l’utilitaire, voir l’article suivant dans la Base de connaissances Microsoft :
Utilisation de l’utilitaire SQLIOSim pour simuler SQL Server activité sur un sous-système de disque
De nombreux fabricants d’ordinateurs commandent les lecteurs en désactivant le cache d’écriture. Toutefois, les
tests montrent que ce n’est pas toujours le cas. Par conséquent, testez toujours complètement.
Périphériques de données
Dans toutes les situations, à l’SQL Server, seuls les enregistrements journaux doivent être vidés. Lors
d’opérations non enregistrées, les pages de données doivent également être vidées vers un stockage stable . il
n’existe aucun enregistrement de journal individuel pour régénérer les actions en cas de défaillance.
Les pages de données peuvent rester en cache jusqu’à ce que le processus LazyWriter ou CheckPoint les vide
vers un stockage stable. L’utilisation du protocole WAL pour s’assurer que les enregistrements journaux sont
correctement stockés permet de s’assurer que la récupération peut récupérer une page de données à un état
connu.
Cela ne signifie pas qu’il est conseillé de placer des fichiers de données sur un lecteur mis en cache. Lorsque le
SQL Server vide les pages de données vers un stockage stable, les enregistrements du journal peuvent être
tronqués à partir du journal des transactions. Si les pages de données sont stockées dans un cache volatile, il est
possible de tronqué les enregistrements journaux qui seraient utilisés pour récupérer une page en cas de
défaillance. Assurez-vous que vos périphériques de données et de journaux s’accommodent correctement du
stockage stable.
Augmentation des performances
La première question qui peut vous être posée est la suivante : « J’ai un lecteur IDE qui était en cache. Mais
lorsque je l’ai désactivée, mes performances sont devenues inférieures aux attentes. Pourquoi ?
La plupart des lecteurs IDE testés par Microsoft s’exécutent à 5 200 TPM et les lecteurs SCSI à 7 200 TPM.
Lorsque vous désactivez la mise en cache d’écriture du lecteur IDE, les performances mécaniques peuvent
devenir un facteur.
Pour résoudre la différence de performances, la méthode à suivre est claire : « Corriger le taux de transactions ».
De nombreux systèmes de traitement des transactions en ligne (OLTP) nécessitent un taux de transactions élevé.
Pour ces systèmes, envisagez d’utiliser un contrôleur de mise en cache qui peut prendre en charge un cache
d’écriture approprié et fournir l’amélioration des performances souhaitée tout en garantissant l’intégrité des
données.
Pour observer des changements de performances significatifs qui se produisent SQL Server sur un lecteur de
mise en cache, le taux de transactions a été augmenté à l’aide de petites transactions.
Les tests montrent que l’activité d’écriture élevée des mémoires tampons inférieure à 512 Ko ou supérieure à 2
Mo peut entraîner un ralentissement des performances.
Prenons l'exemple suivant :
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))

GO
SET NOCOUNT ON
GO
INSERT INTO tblTest VALUES ('Test')

WHILE @@IDENTITY < 10000
Voici des exemples de résultats de test pour SQL Server :
SCSI(7200 RPM) 84 seconds

SCSI(7200 RPM) 15 seconds (Caching controller)
IDE(5200 RPM) 14 seconds (Drive cache enabled)

IDE(5200 RPM) 160 seconds
Le processus d’habillage de toute la série d’opérations en une seule transaction s’exécute en environ INSERT
quatre secondes dans toutes les configurations. Cela est dû au nombre de purges de journaux requises. Si vous
ne créez pas de transaction unique, toutes les transactions sont traitées INSERT comme une transaction
distincte. Par conséquent, tous les enregistrements journaux de la transaction doivent être vidés. Chaque purge a
une taille de 512 octets. Cela nécessite une intervention importante du lecteur mécanique.
Lorsqu’une transaction unique est utilisée, les enregistrements journaux de la transaction peuvent être
regroupés et une seule écriture plus importante peut être utilisée pour vider les enregistrements du journal
collectés. Cela réduit considérablement l’intervention mécanique.
WARNING
Nous vous recommandons de ne pas augmenter l’étendue de votre transaction. Les transactions de longue durée
peuvent entraîner un blocage excessif et indésirable, ainsi qu’une surcharge accrue. Utilisez les SQL Server:D de données
SQL Server des compteurs de performance pour afficher les compteurs basés sur le journal des transactions. Plus
précisément, le journal des octets vidés/s peut indiquer de nombreuses petites transactions qui peuvent entraîner une
activité de disque mécanique élevée.
Examinez les instructions associées au purgement du journal pour déterminer si la valeur Des octets du journal
vidés/s peut être réduite. Dans l’exemple précédent, une seule transaction a été utilisée. Toutefois, dans de
nombreux scénarios, cela peut entraîner un comportement de verrouillage non prévu. Examinez la conception
de la transaction. Vous pouvez utiliser du code semblable à ce qui suit pour exécuter des lots afin de réduire
l’activité de purge des journaux fréquente et faible :
BEGIN TRAN
GO

WHILE @@IDENTITY < 50
BEGIN
if(0 = cast(@@IDENTITY as int) % 10)

BEGIN
PRINT 'Commit tran batch'
COMMIT TRAN
BEGIN TRAN
END
END
GO
COMMIT TRAN
GO
SQL Server les systèmes doivent prendre en charge la distribution garantie sur des supports stables, comme
décrit dans le document de téléchargement SQL Server conditions requises pour la révision du programme de
fiabilité des SQL Server. Pour plus d’informations sur les exigences en matière d’entrée et de sortie pour le
moteur de base de données SQL Server, voir Moteur de base de données Microsoft SQL Server Input/Output
Requirements
Gérer le journal d’SQL Server journal des erreurs
Cet article explique comment gérer le journal d’SQL Server journal des erreurs.
Résumé
Le journal Microsoft SQL Server’erreurs contient de nombreuses informations générées par le SQL Server. Le
journal des erreurs contient des messages d’information, des avertissements et des informations sur les
événements critiques. Le journal des erreurs contient également des informations sur les messages générés par
l’utilisateur et des informations d’audit telles que les événements de connexion (réussite et échec).
Le journal des erreurs est un point de données précieux pour SQL Server administrateurs. En tant
qu’administrateur, vous devez gérer la taille des journaux d’erreurs afin de pouvoir les utiliser lorsqu’ils sont
nécessaires.
Le fichier journal des erreurs est initialisé chaque fois que l’instance de SQL Server est démarrée. Si l’instance de
SQL Server n’a pas été redémarré pendant un certain temps, le fichier journal des erreurs peut devenir
important. Si de nombreuses exceptions (par exemple, des violations d’accès) ou des événements critiques (par
exemple, des assertions SQL Server) se produisent, ces événements peuvent générer un grand nombre
d’informations écrites dans le journal d’erreurs SQL Server.
Réinitialisation des journaux SQL Server’erreurs

Vous pouvez utiliser la procédure stockée pour réinitialiser régulièrement les sp_cycle_errorlog journaux
d’erreurs. Pour plus d’informations, voir sp_cycle_errorlog (Transact-SQL).
Configuration du nombre et de la taille des journaux d SQL Server des

erreurs
Pour plus d’informations sur la configuration de la taille et du nombre de journaux d’erreurs SQL Server pour
une révision d’instance Configure SQL Server Error Logs.
Pour plus d’informations sur la configuration de ces valeurs à l’aide de T-SQL, consultez les billets de blog
suivants de Paul Randal et Jan Kare Lokna :
Limitation de la taille du fichier journal des erreurs SQL Server 2012
Limiter la taille du journal des erreurs
Afficher le journal SQL Server’erreurs dans SQL Server Management Studio (SSMS)

produits.
Transmettre une variable à une requête de serveur
lié
Cet article explique comment transmettre une variable à une requête de serveur liée.
Version du produit d’origine : SQL Server Livres en ligne
Résumé
Lorsque vous interrogez un serveur lié, vous effectuez fréquemment une requête pass-through qui utilise
OPENQUERY OPENROWSET le , ou OPENDATASOURCE instruction. Vous pouvez consulter les exemples de SQL Server
Books Online pour savoir comment faire à l’aide de chaînes Transact-SQL prédéfinées, mais il n’existe aucun
exemple de la façon de transmettre une variable à ces fonctions. Cet article fournit trois exemples de passage
d’une variable à une requête de serveur liée.
Pour transmettre une variable à l’une des fonctions pass-through, vous devez créer une requête dynamique.
Toutes les données qui incluent des guillemets doivent être particulièrement manipulées.
Transmettre des valeurs de base

Lorsque l’instruction Transact-SQL de base est connue, mais que vous devez transmettre une ou plusieurs
valeurs spécifiques, utilisez un code semblable à l’exemple suivant :
DECLARE @TSQL varchar(8000), @VAR char(2)

SELECT @VAR = 'CA'
SELECT @TSQL = 'SELECT * FROM OPENQUERY(MyLinkedServer,''SELECT * FROM pubs.dbo.authors WHERE state = '''''
+ @VAR + ''''''')'
EXEC (@TSQL)
Transmettre l’intégralité de la requête

Lorsque vous devez transmettre l’intégralité de la requête Transact-SQL ou le nom du serveur lié (ou les deux),
utilisez un code semblable à l’exemple suivant :
DECLARE @OPENQUERY nvarchar(4000), @TSQL nvarchar(4000), @LinkedServer nvarchar(4000)

SET @LinkedServer = 'MyLinkedServer'
SET @OPENQUERY = 'SELECT * FROM OPENQUERY('+ @LinkedServer + ','''
SET @TSQL = 'SELECT au_lname, au_id FROM pubs..authors'')'
EXEC (@OPENQUERY+@TSQL)
Utiliser la Sp_executesql stockée

Pour éviter les guillemets multicités, utilisez un code semblable à l’exemple suivant :
DECLARE @VAR char(2)
SELECT @VAR = 'CA'
EXEC MyLinkedServer.master.dbo.sp_executesql
N'SELECT * FROM pubs.dbo.authors WHERE state = @state',
N'@state char(2)',
@VAR
Voir aussi
Pour plus d’informations, voir les rubriques suivantes :
OPENROWSET (Transact-SQL)
OPENQUERY (Transact- SQL)
OPENDATASOURCE (Transact-SQL)
sp_executesql (Transact-SQL)
Interopérabilité des index Columnstore avec le
modèle de mémoire de grande page dans SQL
Server
Cet article vous aide à résoudre le problème de performances lorsque vous utilisez un modèle de mémoire de
fonctionnalité et de Columnstore Index grande page dans SQL Server.
Server 2019
Symptômes
Dans une instance de SQL Server, vous utilisez l’indicateur de suivi 834 comme indicateur de démarrage.
Cette opération permet d’activer les allocations de pages importantes par le gestionnaire de mémoire
SQL Server afin d’améliorer les performances de l’instance 64 bits.
Vous utilisez la Columnstore Index fonctionnalité.
Dans ce scénario, vous devez faire face à un ou plusieurs des problèmes de performances suivants :
Erreur du Scheduler non rapportant et vidages de mémoire associés dans le journal SQL Server’erreurs.
Les requêtes Columnstore déclenchent des problèmes de performances graves.
Une SQL Server instance déclenche des violations d’accès lorsque vous exécutez des requêtes
Columnstore.
Vous rencontrez l’erreur suivante lorsque vous exécutez sp_createstats :
Mémoire système insuffisante dans la réserve de ressources « par défaut » pour exécuter cette
requête
Résolution
Pour résoudre ce problème, supprimez l’indicateur de suivi 834 (-T834) de SQL Server paramètres de
démarrage sur SQL Server instances qui utilisent des index Columnstore. Dans ces environnements, Microsoft
ne recommande pas l’utilisation d’un modèle de mémoire et encourage les clients à revenir à un modèle
large page conventional de lock pages mémoire.
NOTE
À partir SQL Server 2019, l’indicateur de suivi (TF) 876 est disponible pour activer le modèle de mémoire de grande page
pour columnstore. Voir DBCC TRACEON - Trace Flags (Transact-SQL).
SQL Server mémoire
SQL Server pages de grande taille expliquées
Optimisation des options de SQL Server lors de l’exécution dans des charges de travail hautes performances
Message d’erreur 34052 et PBM génère des alertes
sur les stratégies qui ont un mode d’évaluation SQL
Server
Cet article vous aide à résoudre le problème où un travail d’agent SQL génère de fausses alertes lors de
l’utilisation de la gestion basée sur la stratégie (PBM).
Symptômes
Vous créez une stratégie à l’aide de PBM dans SQL Server.
Le mode d’évaluation de la stratégie est à l’heure prévue.
L’une des conditions de la stratégie contient la ExecuteSql() fonction.
Dans ce scénario, lorsque le travail de l’agent SQL Server est exécuté, l’agent génère de fausses alertes et le
message d’erreur suivant est consigné dans le fichier journal d’erreurs SQL Server :
Erreur : 34052, Gravité : 16, État : 1.

La stratégie <Policy name> ' ' a été violée.
NOTE
Ce problème ne se produit pas lorsque vous exécutez ce travail manuellement.
Cause
Ce problème se produit en raison de la violation d’une stratégie PBM créée. PbM place les messages de violation
de stratégie dans le journal des erreurs comme mécanisme de suivi. Cela indique que vous devez examiner la
configuration du serveur pour déterminer pourquoi la stratégie est enfreinte.
Le problème est dû à l’utilisation de la ExecuteSql() fonction dans la stratégie. Cette fonction permet à l’auteur
de la stratégie de créer une condition exprimée dans Transact-SQL et peut également exécuter n’importe quel
code Transact-SQL dans PBM. Par conséquent, par défaut, le contexte de sécurité sous lequel le code s’exécute est
un compte à faibles privilèges MS_PolicyTsqlExecutionLogin. Le compte MS_PolicyTsqlExecutionLogin n’a pas
d’autorisations pour une base de données en plus de la msdb base de données. Toutefois, lorsqu’un travail
programmé s’exécute, l’une des premières instructions ajoutées automatiquement est l’instruction use [
<DBName> ] . Cette instruction entraîne l’échec de la vérification de stratégie.
Lorsque vous exécutez ce travail manuellement, SQL Server utilise votre contexte de sécurité actuel. Tant que
vous êtes autorisé à exécuter les requêtes dans la stratégie, ce travail sera évalué correctement.
Pour résoudre ce problème, accordez au compte MS_PolicyTsqlExecutionLogin les droits corrects pour exécuter
les instructions nécessaires.
Par exemple, le rôle public est suffisamment bon pour que certaines requêtes s’exécutent. Ce rôle peut être
modifié si nécessaire en fonction des besoins de l’entreprise et des stratégies de l’entreprise. Toutefois, il est peu
probable qu’il change, car ce comportement est destiné à des raisons de sécurité.
La restauration ou la récupération peut échouer ou
prendre beaucoup de temps si la notification de
requête est utilisée dans une base de données
Cet article vous aide à résoudre le problème où la restauration ou la récupération peut échouer ou prendre
beaucoup de temps si la notification de requête est utilisée dans une base de données.
Symptômes
Vous remarquerez peut-être un ou plusieurs des symptômes suivants avec une base de données configurée
pour les abonnements aux notifications de requête :
Symptôme 1 : la restauration de la base de données à partir de sa sauvegarde peut échouer avec le
message d’erreur 1205 si NEW_BROKER option est spécifiée pendant l’opération de restauration. En
outre, les fichiers de vidage sont générés dans SQL Server dossier Errorlog de l’utilisateur.
Symptôme 2 : la restauration de la base de données à partir de sa sauvegarde échoue et la base de
données est déconnectée. En outre, les messages suivants sont enregistrés dans le journal SQL
Server’erreurs :
<Datetime> Erreur spid61 : 9768, Gravité : 16, État : 1.

<Datetime> spid61 Un utilisateur de base de données associé à la conversation sécurisée a été
abandonné avant que les informations d’identification n’ont été échangées avec le point de
terminaison éloigné. Évitez d’utiliser DROP USER pendant la création des conversations.
<Datetime> spid61 N’a pas pu vérifier les notifications de requête en attente dans la base de
données « 5 » en raison de l’erreur suivante lors de l’ouverture de la base de données : « Un
utilisateur de base de données associé à la conversation sécurisée a été abandonné avant l’échange
des informations d’identification avec le point de terminaison éloigné. Évitez d’utiliser DROP USER
pendant la création des conversations. Échec de l’opération de nettoyage des abonnements aux
notifications de requête. Consultez les erreurs précédentes pour plus d’informations.
<Datetime> spid61 Le journal de la base de données « Test » n’est pas disponible. Consultez le
journal des événements pour les messages d’erreur associés. Résolvez les erreurs et redémarrez la
base de données.
<Datetime> spid61 Lors de l’opération enregistrée dans la base de données « Test » une erreur s’est
produite au niveau de l’ID de l’enregistrement journal (1835:7401:137). En règle générale, l’échec
spécifique est consigné précédemment en tant qu’erreur dans le service Windows journal des
événements. Restituer la base de données ou le fichier à partir d’une sauvegarde ou réparer la base
de données.
NOTE
Vous pouvez rencontrer le problème lors de la phase de récupération de la base de données. La récupération est
également exécuté sur une base de données lorsque la base de données est mise en ligne, que le serveur est
redémarré, etc.
Symptôme 3 : la restauration de la base de données à partir de sa sauvegarde peut prendre beaucoup de

temps et les messages semblables à ce qui suit sont consignés SQL Server journal des erreurs :
Date Time SPID Query notification delivery could not send message on dialog '{ Dialog ID }.'. La
remise a échoué pour la notification ' ? <qn:QueryNotification
xmlns:qn="https://schemas.microsoft.com/SQL/Notifications/QueryNotification" id="2881"
type="change" source="database" info="restart" database_id="7"
sid="0x010500000000000515000000FA48F22A6990BA52422C73DFF9030000"> <qn:Message>
4a4c696b-645c-40fd-bfef-4f2bc7c599b4;eb99973e-3cc9-4c7e-b4b9 -47d8cf590c43</qn:Message>
</qn:QueryNotification>' because of the following error in service broker: 'The conversation handle
<Conversation Handler> " « is not found.'
NOTE
Vous pouvez rencontrer le problème lors de la phase de récupération de la base de données. La récupération est
également exécuté sur une base de données lorsque la base de données est mise en ligne, que le serveur est
redémarré, etc.
Cause
Cause du symptôme 1 : lorsque vous spécifiez une option NEW_BROKER lors de l’opération de restauration,
SQL Server tente de tronqué toutes les tables liées au Service Broker. La troncation nécessite SCH_M verrouiller
l’objet tronqué. La transaction principale contient donc un SCH_M sur sysdesend. Lorsqu’une base de données
est récupérée ou restaurée, par défaut, SQL Server tente de tirer toutes les notifications de requête en suspens,
ce qui nécessite l’insertion de lignes (messages) dans une table sysdesend. Cette opération nécessite un
verrouillage SCH_S la table. Toutefois, cette opération se produit sur une autre transaction et la tentative
d’acquisition SCH_S verrou est bloquée par le verrou SCH_M la première transaction. Par conséquent, le thread
qui exécute la restauration est désormais bloqué sur une ressource qu’il possède, une situation appelée blocage
autonome. Le blocage est détecté par le moniteur de blocage et le thread est interrompu, ce qui met fin à
l’opération de restauration.
Pour plus d’informations sur les verrous, voir Modes de verrouillage. Les autres symptômes mentionnés dans la
section Symptômes sont dus à des problèmes connus documentés dans les articles de résolution mentionnés
dans la section Résolution ci-dessous.
Résolution
Solution de contournement pour Symptôme 1 : vous pouvez contourner le problème en activant l’indicateur de
suivi au niveau de la session 9109 avant de tenter l’opération de restauration. Un exemple de script est illustré
ci-dessous :
dbcc traceon (9109)
go
RESTORE DATABASE [Test]
FROM DISK = N'C:\TestBackup.bak' WITH FILE = 1,
MOVE N'test_Data' TO N'C:\test.mdf',
MOVE N'test_Log' TO N'C:\test_1.ldf',
NOUNLOAD,
STATS = 1,
NEW_BROKER
go
dbcc traceoff (9109)
go
NOTE
Une fois la base de données entièrement restaurée ou récupérée, il est vivement recommandé de vérifier que les
notifications de requête sont bien tirées. Le moyen le plus simple d’y parvenir consiste à modifier l’état de la base de
données en lecture seule et à la revenir en lecture-écriture. Il existe d’autres façons de vérifier cela, notamment le
détachement et le rattachement de la base de données, le redémarrage SQL Server, etc.
Vous pouvez également éviter le problème en ne spécifiant pas l’option NEW_BROKER sur l’opération de
restauration et en l’utilisez avec l’option NEW_BROKER une fois la base de données ALTER DATABASE restaurée.
Pour plus d’informations, voir DBCC TRACEON - Trace Flags (Transact-SQL).
Exécuter un objet COM basé sur une DLL en dehors
SQL Server processus
Cet article explique comment exécuter un objet COM basé sur une DLL en dehors SQL Server processus.
Résumé
Microsoft SQL Server permet de charger et d’exécuter des objets COM (Component Object Model)
personnalisés par le biais d’un ensemble de procédures stockées OLE Automation ou de procédures stockées
étendues. Par défaut, les objets COM basés sur une DLL sont chargés comme dans le serveur de processus, ce
qui signifie que les objets COM ne sont pas uniquement chargés dans l’espace d’adressa traitement de la
mémoire SQL Server, mais qu’ils ont également un accès complet à cet espace d’adressa visite mémoire. Par
conséquent, un objet COM chargé dans l’espace SQL Server processus doit respecter les mêmes règles que
n’importe quel fichier DLL. Il est possible qu’un objet COM soit en train de SQL Server mémoire ou de fuite de
ressources, ce qui peut provoquer une instabilité.
S’il est suspecté qu’un objet COM affecte la robustesse du processus SQL Server, vous pouvez utiliser les étapes
de cet article pour insérer l’objet COM en dehors de l’espace SQL Server processus. L’implémentation de la
spécification DCOM (Distributed Component Object Model) de transparence de l’emplacement dans le système
d’exploitation a permis d’exécuter un objet COM basé sur DLL en dehors de l’espace SQL Server processus.
Le processus d’exécution d’un objet COM basé sur une DLL en dehors de l’espace d’adressarage de l’application
principale est appelé « remoting ». La remoting nécessite qu’un autre exécutable soit un processus de
substitution à la place du SQL Server exécutable. L’exécutable par défaut utilisé par le Gestionnaire de contrôle
de service DCOM (Rpcss.exe) est nommé Dllhost.exe. La structure de prise en charge DCOM utilise le fichier
Dllhost.exe pour charger la DLL dans son espace de traitement, puis utilise des paires proxy/stub pour marshaler
l’interface demandée de manière transparente au client, qui est dans ce cas le SQL Server. Ce exécutable peut
accepter plusieurs demandes d’interface/méthode simultanément. Une fois l’utilisation de l’interface terminée,
le Gestionnaire de contrôle de service DCOM (SCM) gère le nettoyage et le déchargement du fichier Dllhost.exe.
Il n’est pas prévu que les objets COM conservent les informations d’état entre les ins instantiations.
Les étapes suivantes peuvent s’appliquer à tout objet COM basé sur une DLL créé dans l’espace de traitement
SQL Server, qu’il soit ins instantié par le biais d’une procédure stockée étendue ou par le biais d’une procédure
stockée sp_OACreate étendue.
Les informations sur les deux méthodes de base que vous pouvez utiliser pour inssérer l’objet COM hors
processus suivent.
Le client COM demande l’accès à la remoting de l’objet

En modifiant la façon dont vous voquez l’objet COM, vous pouvez demander que l’objet soit créé en dehors de
l’espace d’adressa SQL Server’adresse.
Si l’objet COM est chargé à l’aide de la procédure, par sp_OACreate défaut, il est chargé en cours.
Toutefois, il existe un troisième paramètre facultatif à cette procédure que vous pouvez utiliser pour
indiquer le contexte de l’endroit où créer l’objet. Si ce paramètre n’est pas spécifié, la valeur par défaut de
5 (5) est utilisée, ce qui signifie que l’objet est exécuté à l’intérieur ou à l’extérieur du processus. Vous
devez modifier le paramètre sur quatre (4), ce qui indique à DCOM que ce composant doit s’exécuter en
tant qu’exécutable local. Utilisez une syntaxe similaire à l’exemple suivant pour informer explicitement
DCOM de l’exécuter hors processus à l’aide de sp_OACreate la procédure stockée :
DECLARE @object int

DECLARE @hr int
EXEC @hr = sp_OACreate 'SQLOLE.SQLServer', @object OUT, 4
Si l’objet COM est créé dans une procédure stockée étendue, le troisième paramètre de .
CoCreateInstance CoCreateInstanceEx CLSCTX_LOCAL_SERVER Ceci est illustré dans l’exemple de code
suivant à l’aide CoCreateInstance de :
HRESULT hr = CoCreateInstance(CLSID_Test, NULL, CLSCTX_LOCAL_SERVER,

IID_IUnknown, (void**)&piunknown);
Modifier le Registre pour forcer la remoting de l’objet

Si vous ne pouvez pas modifier le client COM pour demander la création de l’objet hors processus, deux
méthodes différentes existent pour forcer la création de l’objet hors processus.
Utilisez la visionneuse d’objets OLE/COM (Oleview.exe) livrée avec Visual C++ et recherchez le ProgID
sous tous les OLEComponent.Object objets. Sélectionnez l’objet COM, puis, dans le menu Objet,
CoCreateInstance sélectionnez Indicateurs. Assurez-vous que CLSCTX_LOCAL_SERVER seule la sélection est
sélectionnée. Ensuite, sous les onglets Implémentation et Serveur Inproc, sélectionnez Utiliser le
processus de substitution et laissez le chemin d’accès au substitut personnalisé vide, ce qui permet au
fichier Dllhost.exe d’être chargé et à la DLL COM de s’y trouver.
Utilisez les étapes suivantes pour mettre à jour manuellement le Registre.
WARNING
Toute modification incorrecte du Registre à l’aide de l’Éditeur du Registre ou d’une autre méthode peut entraîner
des problèmes sérieux. Ces problèmes peuvent nécessiter la réinstallation du système d'exploitation. Microsoft ne
peut pas garantir que ces problèmes puissent être résolus. Vous assumez l’ensemble des risques liés à la
modification du Registre.
1. Obtenez l’identificateur de classe (CLSID) de l’objet COM. Le CLSID est un nombre 128 bits et
considéré comme un identificateur global unique (GUID) utilisé pour identifier de manière unique
le composant, le module ou le fichier qui contient cet objet COM. Lors de la création d’objets COM
à l’aide des procédures stockées OLE Automation, le premier paramètre de la procédure stockée
est un identificateur programmatique ou le ProgID de l’objet OLE est utilisé pour dériver le CLSID.
Cette chaîne de caractères décrit la classe de l’objet OLE et a la forme suivante :
OLEComponent.Object
2. Vous pouvez utiliser l’identificateur programmatique pour rechercher l’identificateur de classe

d’un objet COM.
Ouvrez l’Éditeur du Registre (Regedit.exe) et, sous la clé, utilisez la méthode pour localiser une clé
avec le nom de votre < HKEY_CLASSES_ROOT Find OLEComponent.Object>. Vous le trouverez à
d’autres niveaux, mais il doit se trouver au niveau juste en dessous du HKEY_CLASSES_ROOT . Après
avoir localisé la clé, développez le dossier pour le nom de la clé et vous devez voir une sous-clé
nommée CLSID. Cliquez sur ce dossier pour voir les valeurs dans cette clé. Sur le côté droit de
l’écran se trouve un titre nommé (Valeur par défaut). Les données de cette clé doivent se faire sous
la forme suivante :
{59F929A0-74D8-11D2-8CBC-08005A390B09}
Notez cette valeur ou copiez-la dans Bloc-notes. Incluez les crochets.

3. Naviguez sous la HKEY_CLASSES_ROOT\CLSID clé et recherchez la sous-clé avec ce numéro de GUID.
Après avoir mis en surbrillez la clé, vous pouvez utiliser la fonction Rechercher dans l’Éditeur du
Registre (sous le menu Edition) et coller le GUID dans la boîte de HKEY_CLASSES_ROOT\CLSID
dialogue Rechercher. Assurez-vous que vous avez trouvé l’interface appropriée en inspectant la
sous-clé InprocServer32 sous cette clé, qui pointe vers l’emplacement de votre fichier DLL COM.
S’il existe une clé TypeLib, vérifiez cette valeur GUID. Cela doit être différent de ce que vous avez
noté à l’étape 1. Dans le cas contraire, vous avez le GUID TypeLib et non le GUID de l’objet COM. La
sous-clé ProgID aura la valeur « OLEComponent.Object.1 ». Celui qui se trouve à la fin est
uniquement pour cet exemple et est utilisé pour les informations de version.
4. Sous la sous-clé InprocServer32 du GUID, assurez-vous qu’une valeur existe et qu’elle est définie
sur Both ou Free pour vous assurer que le marshaling comprend le modèle de thread de l’objet
COM pour permettre l’exécution de COM en dehors de l’espace de processus ThreadingModel SQL
Server. S’il n’existe pas de valeur ou si elle est définie sur ThreadingModel Apartment, l’insération
d’objet COM risque de ne pas être cohérente.
NOTE
Si vous ajoutez la ThreadingModel valeur, veillez à tester votre objet COM avant de l’implémenter.
5. Mettez en surbrill niveau le numéro de GUID/sous-clé sous la HKEY_CLASSES_ROOT\CLSID clé. Dans le

menu Edition, cliquez sur Nouveau, puis sélectionnez Valeur de chaîne. Sous la colonne Nom,
tapez ce qui suit : AppID
6. Appuyez sur Entrée, puis insérez l’identificateur de classe ou le numéro GUID que vous avez noté à
l’étape 1 comme valeur. Le GUID doit être entre crochets comme dans l’exemple suivant :
{59F929A0-74D8-11D2-8CBC-08005A390B09}
L’identificateur d’application AppID est utilisé par DCOM pour associer la DLL à un fichier
exécutable.
7. Ajoutez une nouvelle sous-clé sous le nom et définissez son nom sur le même identificateur de
classe ou le même numéro GUID avec les HKEY_CLASSES_ROOT\AppID crochets insérés à l’étape
précédente.
8. Mettez en surbrillant le nom du GUID. Dans le menu Edition, cliquez sur Nouveau, puis
sélectionnez Valeur de chaîne. Sous la colonne Nom, tapez : DllSurrogate.
Laissez la colonne Données vide pour cette valeur. Étant donné que la colonne de données est vide,
cela indique à DCOM d’exécuter le fichier exécutable par défaut, Dllhost.exe et de charger l’objet
COM dans son espace de traitement.
9. Fermez l’Éditeur du Registre. Cliquez sur Démarrer , puis sur Exécuter . Dans la boîte de dialogue
Exécuter, tapez : DCOMCNFG.
Appuyez sur la touche Entrée pour ouvrir la boîte de dialogue Propriétés de configuration
COM distribuées. Cliquez sur l’onglet Propriétés par défaut et assurez-vous que l’option
Activer LE COM distribué sur cet ordinateur est sélectionnée. Si ce n’est pas le cas, sélectionnez-
le, puis cliquez sur Appliquer.
10. Assurez-vous que Windows compte d’utilisateur NT sous SQL Server est en cours d’exécution
dispose de l’autorisation Contrôle total sur les clés de Registre pour cet objet. Si les autorisations
ne sont pas suffisantes ou si les clés de Registre sont entrées de manière incorrecte, les erreurs
suivantes peuvent se produire lorsque vous créez l’objet COM :
Informations sur les erreurs OLE Automation

HRESULT : 0x80040154
Source : procédure étendue ODSOLE
Description : classe non enregistrée
Description : l’accès est refusé.
Description : échec de l’exécution du serveur
11. Testez et voyez si cela exécute le fichier Dllhost.exe et charge l’objet COM dans son espace de
traitement. Pour ce faire, le Kit Windows ressources NT se trouve sur Windows ordinateur NT sur
lequel SQL Server’exécution. Ouvrez une invite de commandes et, à partir de l’invite de
commandes, exécutez le fichier Tlist.exe, qui affiche tous les processus et leurs identificateurs de
processus associés, ou identificateurs de processus (PID). Dans le script Transact-SQL qui est
exécuté et après l’exécution de cet appel, mais avant la fin du script, utilisez ce qui suit pour
retarder la fin du script de 20 secondes supplémentaires sp_OACreate :
WAITFOR DELAY '000:00:20'
Exécutez le script, accédez immédiatement à l’invite de commandes et exécutez Tlist.exe fichier.

Notez le Dllhost.exe piD. Réexécutez Tlist.exe et passez le PID en tant que paramètre. Cela affiche
les DLLs qui sont chargées dans l’espace Dllhost.exe processus. L’objet COM basé sur une DLL doit
être répertorié comme s’exécutant dans ce processus. Une fois le script de retour, lTlist.exe de
nouveau révèle que le processus Dllhost.exe n’est plus en cours d’exécution.
Dans l’exemple de sortie suivant, ADODB. L’objet Connection est créé en dehors de l’espace SQL
Server processus. Cette capture instantanée à lTlist.exe été effectuée alors que l’objet COM existait
dans lDllhost.exe de traitement. Notez que le module Msado15.dll, qui est le module qui contient
l’objet COM, est chargé.
C:\>tlist dllhost
275 dllhost.exe
CWD: C:\NT40\system32\
CmdLine: C:\NT40\System32\dllhost.exe {00000514-0000-0010-8000-00AA006D2EA4}
-Embedding
VirtualSize: 19180 KB PeakVirtualSize: 19180 KB WorkingSetSize: 1780 KB
PeakWorkingSetSize: 1780 KB
NumberOfThreads: 3
278 Win32StartAddr:0x01001920 LastErr:0x00000000 State:Waiting
215 Win32StartAddr:0x00001b5e LastErr:0x00000000 State:Waiting
253 Win32StartAddr:0x00001b60 LastErr:0x000000cb State:Waiting
4.0.1381.105 shp 0x01000000 dllhost.exe
4.0.1381.130 shp 0x77f60000 ntdll.dll
4.0.1381.121 shp 0x77dc0000 ADVAPI32.dll
4.0.1381.133 shp 0x77f00000 KERNEL32.dll
4.0.1381.133 shp 0x77e70000 USER32.dll
4.0.1381.115 shp 0x77ed0000 GDI32.dll
4.0.1381.131 shp 0x77e10000 RPCRT4.dll
4.0.1381.117 shp 0x77b20000 ole32.dll
6.0.8267.0 shp 0x78000000 MSVCRT.dll
0x1f310000 msado15.dll
2.30.4265.1 shp 0x766f0000 OLEAUT32.dll
4.0.1381.72 shp 0x77bf0000 rpcltc1.dll
Références
OLE Automation Stored Procedures (Transact-SQL)
Planifier et automatiser les sauvegardes de bases de
données SQL Server dans SQL Server Express
Cet article présente l’utilisation d’un script transact-SQL et d’un programmeur de tâches Windows pour
automatiser les sauvegardes de bases de données SQL Server Express de manière programmée.
Résumé
SQL Server Express éditions ne proposent aucun moyen de planifier des travaux ou des plans de maintenance,
car le composant agent SQL Server n’est pas inclus dans ces éditions. Par conséquent, vous devez utiliser une
approche différente pour la back up de vos bases de données lorsque vous utilisez ces éditions.
Actuellement, SQL Server Express utilisateurs peuvent back up leurs bases de données à l’aide de l’une des
méthodes suivantes :
Utilisez SQL Server Management Studio ou Azure Data Studio. Pour plus d’informations sur l’utilisation de ces
outils pour la back up d’une base de données, voir les liens suivants :
Créer une sauvegarde de base de données complète
Didacticiel : Back up and restore databases using Azure Data Studio
Utilisez un script transact-SQL qui utilise la famille de commandes BACKUP DATABASE. Pour plus
d’informations, voir BACKUP (Transact-SQL).
Cet article explique comment utiliser un script Transact-SQL avec le Programmeur des tâches pour automatiser
les sauvegardes de bases de données SQL Server Express données de manière programmée.
NOTE
Cela s’applique uniquement SQL Server éditions express et non aux éditions SQL Server Express Base de données locale.
Vous devez suivre les quatre étapes suivantes pour SQL Server bases de données de gestion à l’aide Windows
de planification des tâches :
Étape A : créez une procédure stockée pour la back up de vos bases de données.
Connecter à votre instance SQL instance express et créez sp_BackupDatabases procédure stockée dans votre
base de données maître à l’aide du script à l’emplacement suivant :
SQL_Express_Backups
Étape B : Téléchargez l’outil SQLCMD (le cas échéant).
sqlcmd L’utilitaire vous permet d’entrer des instructions Transact-SQL, des procédures système et des fichiers
de script. Dans SQL Server 2014 et versions inférieures, l’utilitaire est livré dans le cadre du produit. À partir
SQL Server 2016, l’utilitaire est sqlcmd proposé en téléchargement séparé. Pour plus d’informations, examinez
l’utilitaire sqlcmd.
Étape C : Créer un fichier de lots à l’aide de l’éditeur de texte.
Dans un éditeur de texte, créez un fichier de lots nommé Sqlbackup.bat, puis copiez le texte de l’un des exemples
suivants dans ce fichier, selon votre scénario :
Tous les scénarios ci-dessous D:\SQLBackups s’utilisent en tant que titulaire d’une place. Le script doit être
ajusté à l’emplacement approprié du lecteur et du dossier de sauvegarde dans votre environnement.
Si vous utilisez l’authentification SQL, assurez-vous que l’accès au dossier est limité aux utilisateurs
autorisés, car les mots de passe sont stockés en texte clair.
NOTE
Le dossier du fichier exécutable se trouve généralement dans les variables Path du serveur une fois SQL Server installé ou
après l’avoir installé en tant SQLCMD qu’outil autonome. Toutefois, si la variable Path ne liste pas ce dossier, vous pouvez
ajouter son emplacement à la variable Path ou spécifier le chemin d’accès complet à l’utilitaire.
Exemple 1 : Sauvegardes complètes de toutes les bases de données dans l’instance nommée locale de
SQLEXPRESS à l’aide de l Windows authentification.
// Sqlbackup.bat
sqlcmd -S .\SQLEXPRESS -E -Q "EXEC sp_BackupDatabases @backupLocation='D:\SQLBackups\', @backupType='F'"
Exemple 2 : Sauvegardes différentielle de toutes les bases de données dans l’instance nommée locale de
SQLEXPRESS à l’aide d’un SQLLogin et de son mot de passe.
// Sqlbackup.bat
sqlcmd -U <YourSQLLogin> -P <StrongPassword> -S .\SQLEXPRESS -Q "EXEC sp_BackupDatabases@backupLocation
='D:\SQLBackups', @BackupType='D'"
NOTE
SQLLogin doit avoir au moins le rôle Opérateur de sauvegarde dans SQL Server.
Exemple 3 : Journal des sauvegardes de toutes les bases de données dans l’instance nommée locale de
SQLEXPRESS à l’aide Windows Authentification unique
// Sqlbackup.bat
sqlcmd -S .\SQLEXPRESS -E -Q "EXEC sp_BackupDatabases @backupLocation='D:\SQLBackups\',@backupType='L'"
Exemple 4 : Sauvegardes complètes de la base de données USERDB dans l’instance nommée locale de
SQLEXPRESS à l’aide de l’authentification Windows données
// Sqlbackup.bat
sqlcmd -S .\SQLEXPRESS -E -Q "EXEC sp_BackupDatabases @backupLocation='D:\SQLBackups\',
@databaseName='USERDB', @backupType='F'"
De même, vous pouvez effectuer une sauvegarde différentielle de USERDB en le césant dans « D » pour le
paramètre et une sauvegarde de journal de USERDB en le césant dans « L » pour @backupType le
@backupType paramètre.
Étape D : Planifier un travail à l’aide Windows de planification des tâches pour exécuter le fichier de lots que
vous avez créé à l’étape B. Pour ce faire, suivez les étapes suivantes :
1. Sur l’ordinateur qui s’SQL Server Express, cliquez sur Démarrer, puis dans la zone de texte tapez
Planification des tâches.

2. SousMeilleure correspondance, cliquezsur Programmeur des tâches pour le lancer.
3. Dans le Programmeur des tâches, cliquez avec le bouton droit sur Bibliothèque de planification des
tâches et cliquez sur Créer une tâche de base....
4. Entrez le nom de la nouvelle tâche (par exemple : SQLBackup) et cliquez sur Suivant .
5. Sélectionnez Tous les jours pour le déclencheur de tâche, puis cliquez sur Suivant.
6. Définissez la récurrence sur un jour et cliquez surSuivant .
7. Sélectionnez Démarrer un programme en tant qu’action, puis cliquez sur Suivant.
8. Cliquez sur Parcourir, cliquez sur le fichier de lots que vous avez créé à l’étape C, puis cliquez sur
Ouvrir.
9. Cochez la case Ouvrir la boîte de dialogue Propriétés pour cette tâche lorsque je clique sur Terminer.
10. Dans l’onglet Général,
a. Examinez les options de sécurité et assurez-vous que le compte d’utilisateur qui exécute la tâche
est le suivant (répertorié sous Lors de l’exécution de la tâche, compte d’utilisateur suivant :)
Le compte doit au moins avoir les autorisations Lecture et Exécution pour lancer l’utilitaire sqlcmd.
En outre,
Si vous utilisez Windows’authentification par lots dans le fichier de lots, assurez-vous que le
propriétaire des autorisations de tâche doit SQL sauvegardes.
Si vous SQL l’authentification par lots dans le fichier de lots, l’SQL utilisateur doit avoir les
autorisations nécessaires pour SQL sauvegardes.
b. Ajustez les autres paramètres en fonction de vos besoins.
TIP
En tant que test, exécutez le fichier de commandes de l’étape C à partir d’une invite de commandes qui est démarrée avec
le même compte d’utilisateur propriétaire de la tâche.
N’ignorez pas les choses suivantes lorsque vous utilisez la procédure documentée dans cet article :
Le service De planification des tâches doit être en cours d’exécution au moment où le travail est
programmé pour s’exécuter. Nous vous recommandons de définir le type de démarrage pour ce service
commeautomatique . Cela permet de s’assurer que le service sera en cours d’exécution même lors d’un
redémarrage.
Il doit y avoir beaucoup d’espace sur le lecteur sur lequel les sauvegardes sont en cours d’écriture. Nous
vous recommandons de nettoyer régulièrement les anciens fichiers du dossier de sauvegarde pour vous
assurer que vous ne manquez pas d’espace disque. Le script ne contient pas la logique de nettoyage des
anciens fichiers.
Références complémentaires
Vue d’ensemble du Programmeur de tâches
Configurer et dépanner un serveur lié à une base
de données Oracle dans SQL Server
Cet article explique comment configurer un serveur lié à partir d’un ordinateur exécutant Microsoft SQL Server
vers une base de données Oracle et fournit des étapes de dépannage de base pour les erreurs courantes que
vous pouvez connaître lorsque vous définissez un serveur lié sur une base de données Oracle.
Version du produit d’origine : Microsoft SQL Server 2005 Édition Standard, Microsoft SQL Server 2005
Developer Edition, Microsoft SQL Server 2005 Êdition Entreprise, Microsoft SQL Server 2005 Express Edition,
Microsoft SQL Server 2005 Workgroup Edition
Résumé
Cet article explique comment configurer un serveur lié à partir d’un ordinateur exécutant Microsoft SQL Server
vers une base de données Oracle et fournit des étapes de dépannage de base pour les erreurs courantes que
vous pouvez connaître lorsque vous définissez un serveur lié sur Oracle. La plupart des informations de cet
article s’appliquent aux environnements configurés pour utiliser le fournisseur MICROSOFT OLEDB pour Oracle
(MSDAORA). Évitez d’utiliser cette fonctionnalité dans de nouveaux travaux de développement et prévoyez de
modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez plutôt le fournisseur OLE DB
d’Oracle.
Pour plus d’informations sur la configuration d’un serveur lié à l’aide du fournisseur OLEDB d’Oracle, voir
Comment être opérationnel avec Oracle et les serveurs liés.
IMPORTANT
La version actuelle du pilote ODBC Microsoft pour Oracle est conforme à la spécification ODBC 2.5, tandis que le
fournisseur OLE DB pour Oracle est un fournisseur d’API OCI Oracle 7 natif. Le pilote et le fournisseur utilisent le client
SQL*Net (ou client Net8 pour Oracle 8x) et la bibliothèque OCI (Oracle Call Interface), ainsi que d’autres composants
clients Oracle, pour se connecter aux bases de données Oracle et récupérer des données. Les composants clients Oracle
sont importants et doivent être configurés correctement pour se connecter correctement aux bases de données Oracle à
l’aide du pilote et du fournisseur.
À partir de Microsoft Data Access Components (MDAC) version 2.5 et versions ultérieures, le pilote ODBC
Microsoft et le fournisseur OLE DB ne viennent en charge que Oracle 7 et Oracle 8i avec les limitations suivantes
:
Les types de données spécifiques à Oracle 8.x, tels que LESB, BLOB, BFILE, NCHAR, NCLOB et
NVARCHAR2, ne sont pas pris en charge.
La fonctionnalité Unicode sur les serveurs Oracle 7.x et 8.x n’est pas prise en charge.
Plusieurs instances de client Oracle, ou plusieurs domiciles Oracle, ne sont pas pris en charge, car elles
reposent sur la première occurrence de la maison Oracle dans la variable SYSTEM PATH.
Le renvoi de plusieurs jeux de résultats à partir d’une procédure stockée ou d’une instruction SQL par lot
n’est pas pris en charge à l’aide d’ADO ou d’OLEDB.
Les jointeurs externes imbrmbrées ne sont pas pris en charge.
La persistance XML n’est pas prise en charge.
La version supérieure à 8i n’est pas prise en charge à l’aide de ces pilotes.
NOTE
Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft.
Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.
Étapes de la mise en place d’un serveur lié à Oracle

1. Vous devez installer le logiciel client Oracle sur l’ordinateur qui exécute SQL Server où le serveur lié est
installé.
2. Installez le pilote que vous souhaitez sur l’ordinateur qui exécute SQL Server. Microsoft prend
uniquement en charge Fournisseur Microsoft OLE DB pour Oracle et le pilote ODBC Microsoft pour
Oracle. Si vous utilisez un fournisseur tiers ou un pilote tiers pour vous connecter à Oracle, vous devez
contacter le fournisseur respectif pour tout problème que vous pouvez avoir à l’aide de son fournisseur
ou de son pilote.
3. Si vous utilisez Fournisseur Microsoft OLE DB pour Oracle et le pilote ODBC Microsoft pour Oracle,
prenez en compte les facteurs suivants :
Le fournisseur OLE DB et le pilote ODBC inclus dans Microsoft Data Access Components (MDAC)
nécessitent SQL*Net 2.3.x ou une version ultérieure. Vous devez installer le logiciel client Oracle
7.3.x, ou une version ultérieure, sur l’ordinateur client. L’ordinateur client est l’ordinateur qui
exécute SQL Server.
Assurez-vous que MDAC 2.5, ou une version ultérieure, est installé sur l’ordinateur qui exécute
SQL Server. Avec MDAC 2.1 ou une version antérieure, vous ne pouvez pas vous connecter aux
bases de données qui utilisent Oracle 8. x ou version ultérieure.
Pour que MDAC 2.5, ou versions ultérieures, fonctionne avec le logiciel client Oracle, le Registre
doit être modifié sur l’ordinateur client qui exécute SQL Server comme indiqué dans le tableau
suivant.
Oracle
Client Microsoft Windows 2000 and later versions
--------------------------------------------------------------------------
7.x [HKEY_LOCAL_MACHINE\SOFTWARE
Microsoft\MSDTC\MTxOCI]
"OracleXaLib"="xa73.dll"
"OracleSqlLib"="SQLLib18.dll"
"OracleOciLib"="ociw32.dll"
8.0 [HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\MSDTC\MTxOCI]
"OracleXaLib"="xa80.dll"
"OracleSqlLib"="sqllib80.dll"
"OracleOciLib"="oci.dll"
8.1 [HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\MSDTC\MTxOCI]
"OracleXaLib"="oraclient8.dll"
"OracleSqlLib"="orasql8.dll"
"OracleOciLib"="oci.dll"
4. Redémarrez l’ordinateur qui s’exécute SQL Server après avoir installé le logiciel client Oracle.
5. Sur l’ordinateur qui exécute SQL Server, définissez un serveur lié à l’aide du script suivant.
-- Adding linked server (from SQL Server Books Online):

/* sp_addlinkedserver [@server =] 'server'[, [@srvproduct =] 'product_name']
[, [@provider =] 'provider_name']
[, [@datasrc =] 'data_source']
[, [@location =] 'location'] [, [@provstr =] 'provider_string']
[, [@catalog =] 'catalog']
*/
EXEC sp_addlinkedserver 'Ora817Link', 'Oracle', 'MSDAORA', 'oracle817'
-- Adding linked server login:

/* sp_addlinkedsrvlogin [@rmtsrvname =] 'rmtsrvname'[,[@useself =] 'useself']
[,[@locallogin =] 'locallogin']
[,[@rmtuser =] 'rmtuser']
[,[@rmtpassword =] 'rmtpassword']
*/
EXEC sp_addlinkedsrvlogin 'Ora817Link', 'FALSE',NULL, 'scott', 'tiger'
-- Help on the linked server:

EXEC sp_linkedservers
EXEC sp_helpserver
select * from sysservers
NOTE
Si vous utilisez le pilote ODBC Microsoft pour Oracle, vous pouvez utiliser le paramètre @datasrc pour spécifier
un nom de DSN. Pour une connexion sans DSN, la chaîne de fournisseur est fournie par le biais du @provstr
paramètre. Avec Fournisseur Microsoft OLE DB pour Oracle, utilisez l’alias de serveur Oracle configuré dans le
fichier TNSNames.Ora pour le @datasrc paramètre. Pour plus d’informations, voir la rubrique « sp_addlinkedserver
» dans SQL Server Books Online.
Messages d’erreur courants et résolution des problèmes

IMPORTANT
restaurer en cas de problème. Pour plus d’informations sur la façon de la back up et de la restauration du Registre, cliquez
sur le numéro d’article suivant pour afficher l’article de la Base de connaissances Microsoft : 322756 How to back up and
restore the Registry in Windows
Vous pouvez utiliser l’une des deux méthodes suivantes pour récupérer des informations étendues sur les
erreurs que vous pouvez voir lors de l’exécution d’une requête distribuée.
Méthode 1
Connecter à SQL Server l’SQL Server Management Studio et exécutez le code suivant pour activer
l’indicateur de suivi 7300.
DBCC Traceon(7300)
Méthode 2
Capturez l’événement « Erreurs OLEDB » qui se trouve dans la catégorie d’événement « Erreurs et
avertissements » dans SQL Profiler. Le format du message d’erreur est le suivant :
Interface::Method failed with hex-error code.
Vous pouvez rechercher du code d’erreur hexadm dans le fichier Oledberr.h inclus dans le Kit de
développement logiciel (SDK) MDAC.
Voici une liste des messages d’erreur courants qui peuvent se produire, ainsi que des informations sur la façon
de résoudre le message d’erreur.
NOTE
Si vous utilisez SQL Server version 2005 ou ultérieure, ces messages d’erreur peuvent être légèrement différents.
Toutefois, les ID d’erreur de ces messages d’erreur sont identiques à ceux des versions antérieures de SQL Server. Par
conséquent, vous pouvez les identifier par les ID d’erreur. Pour les problèmes liés aux performances, recherchez SQL Server
Books Online pour la rubrique Optimiser les requêtes distribuées.
Message 1
Erreur 7399 : le fournisseur OLE DB « %ls » pour le serveur lié « %ls » a signalé une erreur. %ls
Activer l’indicateur de suivi 7300 ou utiliser SQL Profiler pour capturer l’événement Erreurs OLEDB afin
de récupérer des informations d’erreur OLEDB étendues.
Message 2a
« ORA-12154 : TNS : n’a pas pu résoudre le nom du service »
Message 2b
« Le client Oracle(tm) et les composants réseau n’ont pas été trouvés. Ces composants sont fournis
par Oracle Corporation et font partie de l’installation logicielle cliente Oracle version 7.3.3 (ou
supérieure) »
Ces erreurs se produisent en cas de problème de connectivité au serveur Oracle. Examinez la section
Techniques pour résoudre les problèmes de connectivité au serveur Oracle ci-dessous pour résoudre
d’autres problèmes.
Message 3
Erreur 7302 : Impossible de créer une instance du fournisseur OLE DB « MSDAORA » pour le serveur
lié « %ls ».
Assurez-vous que MSDAORA.dll fichier est enregistré correctement. (Le MSDAORA.dll est le fournisseur
Microsoft OLE DB pour le fichier Oracle.) Utilisez RegSvr32.exe pour inscrire Fournisseur Microsoft OLE
DB pour Oracle.
NOTE
Si vous utilisez un fournisseur Oracle tiers et que votre fournisseur Oracle ne peut pas s’exécuter en dehors d’un
processus SQL Server, autorisez-le à s’exécuter in-process en modifiant les options du fournisseur. Pour modifier
les options du fournisseur, utilisez l’une des méthodes suivantes.
Méthode 1 Recherchez la clé de Registre suivante. Ensuite, modifiez la valeur de l’entrée AllowInProcess
(DWORD) sur 1. Cette clé de Registre se trouve sous le nom du fournisseur correspondant :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers\ProviderName .
Méthode 2 Définissez l’option Autoriser l’inprocesseur directement via SQL Server Entreprise lorsque vous
ajoutez un nouveau serveur lié. Cliquez sur Options du fournisseur, puis cochez la case Autoriser inProcess.
Message 4
Erreur 7303 : Impossible d’initialiser l’objet de source de données du fournisseur OLE DB «

MSDAORA » pour le serveur lié « %ls ». [Message renvoyé par le fournisseur OLE/DB : ORA-01017 :
nom d’utilisateur/mot de passe non valide ; connexion refusée] Suivi des erreurs OLE DB [OLE/DB
Provider 'MSDAORA' IDBInitialize::Initialize returned 0x80040e4d].
Ce message d’erreur indique que le serveur lié n’a pas de mappage de connexion correct. Vous pouvez
exécuter la sp_helplinkedsrvlogin procédure stockée pour définir correctement les informations de
connexion. Vérifiez également que vous avez spécifié les paramètres corrects pour la configuration du
serveur lié.
Message 5
Erreur 7306 : Impossible d’ouvrir la table « %ls » à partir du fournisseur OLE DB « MSDAORA » pour
le serveur lié « %ls ». La table spécifiée n’existe pas. [Message renvoyé par le fournisseur OLE/DB : La
table n’existe pas.] [Message renvoyé par le fournisseur OLE/DB : ORA-00942 : la table ou la vue
n’existe pas] Suivi des erreurs OLE DB [OLE/DB Provider 'MSDAORA' IOpenRowset::OpenRowset
returned 0x80040e37: The specified table does not exist.].
Erreur 7312 : Utilisation incorrecte du schéma et/ou du catalogue pour le fournisseur OLE DB « %ls »
pour le serveur lié « %ls ». Un nom en quatre partie a été fourni, mais le fournisseur n’expose pas les
interfaces nécessaires pour utiliser un catalogue et/ou un schéma.
Erreur 7313 : un schéma ou un catalogue non valide a été spécifié pour le fournisseur « %ls » pour le
serveur lié « %ls ».
Erreur 7314 : le fournisseur OLE DB « %ls » pour le serveur lié « %ls » ne contient pas la table « %ls ».
La table n’existe pas ou l’utilisateur actuel n’a pas d’autorisations sur cette table.
Si vous recevez ces messages d’erreur, il se peut qu’une table soit manquante dans le schéma Oracle ou
que vous ne soyez pas autorisé à le faire. Vérifiez que le nom du schéma a été tapé en minuscules. Le cas
alphabétique du tableau et des colonnes doit être tel que spécifié dans les tables système Oracle.
Côté Oracle, une table ou une colonne créée sans guillemets doubles est stockée en minuscules. Si la
table ou la colonne est entourée de guillemets doubles, la table ou la colonne est stockée telle qu’elle est.
L’appel suivant indique si la table existe dans le schéma Oracle. Cet appel indique également le nom exact
de la table.
sp_tables_ex @table_server=Ora817Link, @table_schema='your_schema_name'
Message 6
Erreur 7413 : Connexion au serveur lié « %ls » (fournisseur OLE DB « %ls »). Activez la délégation ou
utilisez une connexion SQL Server à distance pour l’utilisateur actuel. Msg 18456, Level 14, State 1,
Line 1 Login failed for user ' ' .
Ce message d’erreur indique qu’une requête distribuée est tentée pour une connexion authentifiée
microsoft Windows sans mappage de connexion explicite. Dans un environnement de système
d’exploitation dans lequel la délégation de sécurité n’est pas prise en charge, les connexions authentifiées
par Windows NT ont besoin d’un mappage explicite à une connexion à distance et à un mot de passe
créés à l’aide de sp_addlinkedsrvlogin .
Message 7
Erreur 7391 : L’opération n’a pas pu être effectuée car le fournisseur OLE DB « MSDAORA » pour le
serveur lié « %ls » n’a pas pu commencer une transaction distribuée. OLE DB error trace [OLE/DB
Provider 'MSDAORA' ITransactionJoin::JoinTransaction returned 0x8004d01b]
Vérifiez que les versions OCI sont correctement enregistrées, comme décrit plus tôt dans cet article.
NOTE
Si les entrées de Registre sont correctes, le fichier MtxOCI.dll est chargé. Si le MtxOCI.dll n’est pas chargé, vous ne
pouvez pas effectuer de transactions distribuées sur Oracle à l’aide de Fournisseur Microsoft OLE DB pour Oracle
ou à l’aide du pilote ODBC Microsoft pour Oracle. Si vous utilisez un fournisseur tiers et que vous recevez l’erreur
7391, vérifiez que le fournisseur OLE DB que vous utilisez prend en charge les transactions distribuées. Si le
fournisseur OLE DB prend en charge les transactions distribuées, vérifiez que le MSDTC (Microsoft Distributed
Transaction Coordinator) est en cours d’exécution et que l’accès réseau est activé.
Message 8
Erreur 7392 : Impossible de démarrer une transaction pour le fournisseur OLE DB « MSDAORA »
pour le serveur lié « %ls ». Suivi des erreurs OLE DB [OLE/DB Provider 'MSDAORA'
ITransactionLocal::StartTransaction returned 0x8004d013: ISOLEVEL=4096].
Le fournisseur OLE DB a renvoyé l’erreur 7392, car une seule transaction peut être active pour cette
session. Cette erreur indique qu’une instruction de modification de données est tentée contre un
fournisseur OLE DB lorsque la connexion se trouve dans une transaction explicite ou implicite, et que le
fournisseur OLE DB ne prend pas en charge les transactions imbrmbrées. SQL Server nécessite cette
prise en charge afin que, dans certaines conditions d’erreur, elle puisse mettre fin aux effets de
l’instruction de modification des données tout en continuant la transaction.
Si la valeur est ON, SQL Server ne nécessite pas la prise en charge des SET XACT_ABORT transactions
imbrmbrées du fournisseur OLE DB. Par conséquent, exécutez avant d’exécuter des instructions de
modification de données sur des tables distantes dans SET XACT_ABORT ON une transaction implicite ou
explicite. Faites-le au cas où le fournisseur OLE DB que vous utilisez ne prend pas en charge les
transactions imbrmbrées.
Techniques de résolution des problèmes de connectivité au serveur

Oracle
Pour déboguer les problèmes de connectivité Oracle avec le pilote ODBC Microsoft pour Oracle ou le
Fournisseur Microsoft OLE DB pour Oracle, suivez les étapes suivantes :
1. Utilisez l’utilitaire Oracle SQL Plus (utilitaire de requête basé sur une ligne de commande) pour vérifier
que vous pouvez vous connecter à Oracle et récupérer des données.
NOTE
Si vous ne pouvez pas vous connecter à Oracle et récupérer des données, vous avez une installation ou une
configuration des composants clients Oracle mauvaise ou vous n’avez pas correctement créé un alias de service
TNS (Transparent Network Substrate) pour le serveur Oracle lorsque vous avez utilisé l’utilitaire de configuration
simple SQL*Net ou Oracle Net8 Easy Configuration. Contactez votre administrateur de base de données Oracle
pour vérifier que les composants Oracle dont vous avez besoin sont correctement installés et configurés.
2. Vérifiez la version du client Oracle (version SQL Net) installée * sur l’ordinateur. Le pilote ODBC Microsoft
pour Oracle et le Fournisseur Microsoft OLE DB pour Oracle nécessitent l’installation de SQL*Net version
2.3 ou ultérieure sur l’ordinateur client.
La connectivité de SQL Plus (l’outil de requête client Oracle) peut sembler fonctionner, mais vous devez
redémarrer votre ordinateur pour que la connectivité ODBC/OLE DB fonctionne correctement.
NOTE
Lorsque vous utilisez Oracle 8i, le fichier .rgs est vide.
3. Si le client Oracle est installé et que vous recevez une erreur qui indique que les composants client Oracle
7.3 ou ultérieur doivent être installés sur l’ordinateur, vérifiez que la variable d’environnement PATH sur
l’ordinateur client contient le dossier dans lequel le client Oracle a été installé, par exemple,
Oracle_Root\Bin. Si vous ne trouvez pas ce dossier, ajoutez-le à la variable PATH pour résoudre l’erreur.
4. Vérifiez que le Ociw32.dll est dans le dossier Oracle_Root\bin. Ce .dll ne peut pas exister à un autre
emplacement sur l’ordinateur client. Assurez-vous que les DLL de composant client Oracle (par exemple,
le fichier Core40.dll et le fichier Ora.dll) n’existent pas en dehors du dossier Oracle_Root ou des * sous-
dossiers.
5. Vérifiez qu’une seule version du client Oracle est installée sur l’ordinateur. Plusieurs versions de SQL*Net
ne peuvent pas exister sur le même ordinateur client avec des interférences et des opérations critiques
(par exemple, recherche de TNS et d’alias).
6. Microsoft recommande d’avoir une installation locale du client Oracle et de ne pas le faire en m mappage
d’un client Oracle distant sur votre ordinateur, puis de l’inclure dans le chemin d’accès du système pour
vous connecter à Oracle via ODBC/OLE DB. Toutefois, le fournisseur et le pilote sont testés avec un client
Oracle installé localement et non sur un partage réseau.
Voir aussi
Historique des pilotes pour Microsoft SQL Server
Serveurs liés (Moteur de base de données)
L’espace utilisé par une table n’est pas
complètement libéré après l’utilisation d’une
instruction DELETE pour supprimer des données de
la table dans SQL Server
Cet article vous aide à contourner le problème qu’une table utilise ne peut pas être libéré après avoir utilisé une
instruction DELETE pour supprimer toutes les données de la table.
Symptômes
Après avoir utilisé une instruction DELETE dans Microsoft SQL Server pour supprimer des données d’une table,
vous remarquerez peut-être que l’espace utilisé par la table n’est pas complètement libéré. Lorsque vous essayez
ensuite d’insérer des données dans la base de données, vous pouvez recevoir le message d’erreur suivant :
Could not allocate space for object 'TableName ' in database 'DatabaseName ' because the 'PRIMARY'
filegroup is full.
NOTE
TableName représente le nom de la table. DatabaseName représente le nom de la base de données qui contient la
table.
Cause
Ce problème se produit car SQL Server libère uniquement toutes les pages qu’une table de tas utilise lorsque
les conditions suivantes sont vraies :
Une suppression se produit dans cette table.
Un verrou au niveau de la table est maintenu.
NOTE
Une table de tas est une table qui n’est pas associée à un index en cluster.
Si les pages ne sont pas désattribuées, les autres objets de la base de données ne peuvent pas réutiliser les
pages.
Toutefois, lorsque vous activez un niveau d’isolation de ligne dans une base de données SQL Server 2005, les
pages ne peuvent pas être libérées même si un verrou au niveau de la versioning-based table est maintenu.
Pour plus d’informations sur les niveaux d’isolation des lignes, voir la rubrique « Utilisation des niveaux
d’isolation basés sur le système de version de ligne » dans versioning-based SQL Server 2005 Books Online.
Pour contourner ce problème, utilisez l’une des méthodes suivantes :
Incluez un conseil TABLOCK dans l’instruction DELETE si un niveau d’isolation basé sur le contrôle de
version de ligne n’est pas activé. Par exemple, utilisez une instruction semblable à ce qui suit :
DELETE FROM <TableName> WITH (TABLOCK)
NOTE
<TableName> représente le nom de la table.
Utilisez l’instruction TRUNCATE TABLE si vous souhaitez supprimer tous les enregistrements de la table.
Par exemple, utilisez une instruction semblable à ce qui suit :
TRUNCATE TABLE <TableName>
Créez un index en cluster sur une colonne du tableau. Pour plus d’informations sur la création d’un index
en cluster sur une table, voir la rubrique « Création d’un index en cluster » dans SQL Server Books Online.
Description de la prise en charge SQL Server de
données sur les volumes compressés
Cet article décrit le comportement SQL Server de stockage des fichiers de base de données sur les lecteurs
compressés.
Résumé
SQL Server bases de données ne sont pas pris en charge sur les volumes compressés NTFS ou FAT, sauf dans
des circonstances particulières pour SQL Server 2005 et les versions ultérieures. Un volume compressé ne
garantit pas les écritures alignées sur le secteur, qui sont nécessaires pour garantir la récupération
transactionnelle dans certaines circonstances.
Pour SQL Server versions 2005 et ultérieures, le stockage des fichiers de base de données sur les lecteurs
compressés se comporte comme suit :
Si votre fichier de données appartient à un groupe de fichiers en lecture seule, le fichier est autorisé.
Si votre fichier de données appartient à une base de données en lecture seule, le fichier est autorisé.
Si votre fichier journal des transactions appartient à une base de données en lecture seule, le fichier est
autorisé.
Si vous essayez d’ouvrir une base de données en lecture/écriture avec des fichiers sur un lecteur
compressé, SQL Server génère l’erreur suivante :
Msg 5118, Level 16, State 2, Line 1 The file « < file_name > » is compressed but does not reside in a
read-only database or filegroup. Le fichier doit être décompressé.
Pour plus d’informations sur les exclusions pour les bases de données en lecture seule et les groupes de fichiers
en lecture seule dans SQL Server 2008, consultez le site web MSDN suivant :
Compression et groupes de fichiers en lecture seule
NOTE
Cette rubrique s’applique également SQL Server 2012 et versions ultérieures.
Bien qu’il soit physiquement possible d’ajouter SQL Server bases de données sur des volumes compressés, cela
n’est pas recommandé et nous ne le prisent pas en charge. Les raisons sous-jacentes de ce problème sont les
suivantes :
Performances
Les bases de données sur des volumes compressés peuvent entraîner une surcharge de performances
importante. Le montant varie en fonction du volume d’I/S et du rapport entre les écritures et les lectures.
Toutefois, une dégradation de plus de 500 % a été observée dans certaines conditions.
Récupération de base de données
Une récupération transactionnelle fiable de la base de données nécessite des écritures alignées sur le
secteur, et les volumes compressés ne la prisent pas en charge. Un deuxième problème concerne la
gestion de l’espace de récupération interne. SQL Server réserve en interne de l’espace alloué dans les
fichiers de base de données pour les récupérations. Il est possible sur les volumes compressés de
recevoir une erreur d’espace vide sur les fichiers préalloqués, ce qui interfère avec la récupération réussie.
Dans certains scénarios, une sauvegarde SQL Server vers un volume compressé ou un dossier compressé n’est
pas réussie. Lorsque ce problème se produit, vous recevez l’un des messages d’erreur suivants.
Dans Windows Vista et les versions ultérieures de Windows
STATUS_FILE_SYSTEM_LIMITATION l’opération demandée n’a pas pu être terminée en raison d’une

limitation du système de fichiers
Erreur du système d’exploitation 665(L’opération demandée n’a pas pu être effectuée en raison d’une
limitation du système de fichiers)
Dans les versions antérieures de Windows
STATUS_INSUFFICIENT_RESOURCES ressources système insuffisantes existent pour effectuer l’erreur

du système d’exploitation du service demandée 1450(Des ressources système insuffisantes existent
pour terminer la demande ou 33(Le processus ne peut pas accéder au fichier car un autre processus a
verrouillé une partie du fichier.)
Pour plus d’informations sur ce problème, voir un fichier fortement fragmenté dans un volume NTFS peut ne
pas croître au-delà d’une certaine taille.
NOTE
Le correctif logiciel pour Windows Vista et les versions ultérieures de Windows décrits dans l’article de la 967351 de la
Ko peut ne pas résoudre le problème des sauvegardes SQL Server qui ne sont pas réussies sur un volume compressé
ou sur un dossier compressé. Toutefois, ce correctif vous aidera à médiationr le problème.
Après avoir appliqué le correctif logiciel décrit dans l’article de la base de 967351, vous devez mettre en forme le
lecteur sur lequel la compression est activée à l’aide du /L paramètre. Lorsque vous formatez le lecteur sur lequel la
compression est activée à l’aide du paramètre, le segment Octets par enregistrement de fichier passe de 1 024 octets à
/L 4 096 octets.
SQL Server sauvegardes sur des volumes compressés peuvent économiser de l’espace disque. Toutefois, ils
peuvent augmenter l’utilisation du processeur pendant l’opération de sauvegarde. Nous vous recommandons
toujours d’utiliser les installations de sommes de contrôle BACKUP pour garantir l’intégrité des données.
SQL Server systèmes doivent prendre en charge la distribution garantie sur des supports stables, comme
indiqué dans la SQL Serverdes programmes de fiabilité des SQL Server'
Pour plus d’informations sur les exigences en matière d’entrée et de sortie pour le moteur de base de données
SQL Server, voir Moteur de base de données Microsoft SQL Server d’entrée/sortie requises
Description de la prise en charge des fichiers de
base de données réseau dans SQL Server
Cet article décrit la prise en charge des fichiers de base de données réseau dans SQL Server et explique
comment configurer SQL Server pour stocker une base de données sur un serveur réseau ou un serveur de
stockage NAS.
Résumé
Microsoft recommande généralement d’utiliser un réseau san (Stockage Area Network) ou un disque connecté
localement pour le stockage de vos fichiers de base de données Microsoft SQL Server, car cette configuration
optimise les performances SQL Server et la fiabilité. Par défaut, l’utilisation de fichiers de base de données
réseau stockés sur un serveur réseau ou un serveur NAS (Network Attached Stockage) n’est pas activée pour les
SQL Server.
Toutefois, vous pouvez configurer SQL Server pour stocker une base de données sur un serveur réseau ou un
serveur NAS. Les serveurs utilisés à cet effet doivent respecter SQL Server conditions requises pour l’ordre
d’écriture des données et les garanties d’écriture par écriture. Ces informations sont détaillées dans la section
Plus d’informations.
Les conditions suivantes décrivent l’utilisation des fichiers de base de données réseau stockés sur un serveur
réseau ou un serveur NAS :
Cette utilisation est activée par défaut dans Microsoft SQL Server 2008 R2 et versions ultérieures.
Cette utilisation nécessite que l’indicateur de suivi de démarrage -T1807 fonctionne dans Microsoft SQL
Server 2008 et versions antérieures. Pour plus d’informations sur la façon d’activer les indicateurs de
suivi de démarrage, Moteur de base de données options de démarrage du service.
Windows Périphériques whQL (Hardware Quality Lab)

Les serveurs Microsoft Windows et réseaux ou serveurs de stockage NAS qui sont qualifiés pour le laboratoire
de qualité du matériel (WHQL) Windows répondent automatiquement aux commandes d’écriture de données et
aux garanties d’écriture par écriture requises pour prendre en charge un périphérique de stockage SQL Server.
Microsoft prend en charge les problèmes liés à l’application et au stockage dans ces configurations.
NOTE
Pour être prise en charge par SQL Server, la solution de stockage NAS doit également répondre à toutes les conditions
requises répertoriées dans le document de téléchargement : SQL Server programme de fiabilité des entrées et des
produits .
Autres appareils
Si vous utilisez un périphérique de stockage non qualifié WHQL avec des SQL Server qui prend en charge les
garanties d’opérations d’I/S pour l’utilisation des bases de données transactionnelles décrites dans cet article,
Microsoft prend entièrement en charge les applications SQL Server et SQL Server. Toutefois, les problèmes avec
l’appareil ou son sous-système de stockage, ou causés par celui-ci, sont renvoyés au fabricant de l’appareil. Si
vous utilisez un dispositif de stockage non qualifié WHQL qui ne prend pas en charge les garanties d’opérations
d’opérations d’exploitation pour l’utilisation des bases de données transactionnelles décrites dans cet article,
Microsoft ne peut pas assurer la prise en charge des applications basées sur SQL Server ou SQL Server. Pour
déterminer si votre périphérique de stockage non qualifié WHQL prend en charge les garanties d’opérations
d’I/S d’utilisation des bases de données transactionnelles décrites dans cet article ou conçues pour une
utilisation de base de données, consultez le fournisseur de votre appareil. En outre, contactez le fournisseur de
votre appareil pour vérifier que vous avez correctement déployé et configuré l’appareil pour une utilisation de
base de données transactionnelle.
Par défaut, dans SQL Server 2008 et les versions antérieures, vous ne pouvez pas créer une base de données
SQL Server sur un partage de fichiers réseau. Toute tentative de création d’un fichier de base de données sur un
emplacement réseau mappé ou UNC génère l’un des messages d’erreur suivants :
Message d'erreur 1
5105 « Erreur d’activation de périphérique »
Message d'erreur 2
5110 « Le fichier « file_name » se trouve sur un périphérique réseau non pris en charge pour les
fichiers de base de données. »
Ce comportement est normal. L’indicateur de suivi 1807 contourne la vérification et vous permet de configurer
SQL Server des fichiers de base de données réseau. SQL Server et la plupart des autres systèmes de base de
données d’entreprise utilisent un journal des transactions et la logique de récupération associée pour maintenir
la cohérence de la base de données transactionnelle en cas de défaillance du système ou d’arrêt non ingérable.
Ces protocoles de récupération s’appuient sur la possibilité d’écrire directement sur le support disque afin que
lorsqu’une demande d’écriture d’entrée/sortie du système d’exploitation soit revenir au gestionnaire de base de
données, le système de récupération peut s’assurer que l’écriture est terminée ou que l’exécution de l’écriture
peut être garantie. Toute défaillance d’un composant logiciel ou matériel respectant ce protocole peut entraîner
une perte de données partielle ou totale ou une altération en cas de défaillance du système. Pour plus
d’informations sur ces aspects des protocoles de journalisation et de récupération dans SQL Server, voir
Description des algorithmesde journalisation et de stockage de données qui étendent la fiabilité des données
dans SQL Server .
Microsoft ne prend pas en charge SQL Server fichiers de base de données en réseau sur des serveurs NAS ou
de stockage réseau qui ne répondent pas à ces exigences d’écriture et d’écriture.
En raison des risques d’erreurs réseau qui compromettent l’intégrité de la base de données, ainsi que des
implications éventuelles en matière de performances qui peuvent résulter de l’utilisation de partages de fichiers
réseau pour stocker des bases de données, Microsoft recommande de stocker les fichiers de base de données
sur des sous-systèmes de disque locaux ou sur des réseaux sans (SAN) Stockage.
Un système NAS (Network Attached Storage) est un système de stockage basé sur des fichiers que les clients
attachent via le redirecteur réseau à l’aide d’un protocole réseau (tel que TCP/IP). Par défaut, si l’accès à une
ressource de disque nécessite qu’un partage soit mappé, ou si la ressource disque apparaît en tant que serveur
distant via un chemin UNC (par exemple, Nom_serveur\Nom_Share) sur le réseau, le système de stockage de
disque n’est pas pris en charge comme emplacement pour les bases de données \ SQL Server.
Problèmes de performances
SQL Server, comme d’autres systèmes de base de données d’entreprise, peut placer une charge importante sur
un sous-système d’O/S. Dans la plupart des applications de base de données de grande taille, la configuration et
l’optimisation des O/S physiques jouent un rôle important dans les performances globales du système. Il existe
trois principaux facteurs de performances des opérations d’opérations d’entreprise à prendre en compte :
Bande passante d’I/S : bande passante agrégée, généralement mesurée en mégaoctets par seconde et qui
peut être soutenue par un périphérique de base de données.
Latence d’O/S : la latence, généralement mesurée en millisecondes, entre une demande d’I/S par le système
de base de données et le point où la demande d’O/S est terminée.
Coût de l’UC : coût de l’UC hôte, généralement mesuré en microsecondes processeur, pour que le système de
base de données remplisse une seule unité d’UC.
L’un de ces facteurs d’O/S peut devenir un goulot d’étranglement et vous devez tenir compte de tous ces
facteurs lorsque vous concevez un système d’O/S pour une application de base de données.
Dans sa forme la plus simple, une solution NAS utilise une pile logicielle de redirecteur réseau standard, une
carte d’interface réseau standard et des composants Ethernet standard. L’inconvénient de cette configuration est
que tous les fichiers D/S sont traitées via la pile réseau et sont soumis aux limites de bande passante du réseau
lui-même. Cela peut créer des problèmes de performances et de fiabilité des données, en particulier dans les
programmes qui nécessitent des niveaux élevés d’I/S de fichier, tels que SQL Server. Dans certaines
configurations NAS testées par Microsoft, le débit d’E/S était d’un tiers (1/3) celui d’une solution de stockage
directement attachée sur le même serveur. Dans cette même configuration, le coût processeur pour effectuer
une O/S via le périphérique NAS était deux fois plus élevé que celui d’une unité d’UC locale. À mesure que les
périphériques NAS et l’infrastructure réseau évoluent, ces ratios peuvent également s’améliorer par rapport au
stockage connecté direct ou aux réseaux sans. En outre, si vos données d’application sont principalement mises
en cache dans le pool de mémoires tampons de base de données et que vous ne rencontrez aucun des goulots
d’étranglement d’O/S décrits, les performances sur un système NAS sont probablement adéquates pour votre
application.
Considérations sur la sauvegarde et la restauration

SQL Server fournit l’interface VDI (Virtual Device Interface) pour la sauvegarde. L’environnement VDI fournit aux
éditeurs de logiciels de sauvegarde un moyen très performant, évolutif et fiable d’effectuer des sauvegardes
automatiques et de restaurer SQL Server bases de données.
Le logiciel de sauvegarde fonctionne sur des fichiers de base de données stockés sur des périphériques NAS via
VDI sans prise en charge spéciale spécifique au nas. Toutefois, cela se traduit par un trafic réseau supplémentaire
pendant la sauvegarde et la restauration. Lors de la sauvegarde via VDI, SQL Server lit les fichiers à distance et
transmet les données au logiciel de sauvegarde tiers qui s’exécute sur l’ordinateur SQL Server. L’opération de
restauration est analogue.
Pour éviter la surcharge réseau supplémentaire, le fournisseur de sauvegarde doit fournir une prise en charge
spécifique nas par le fournisseur de sauvegarde et le fournisseur NAS. SQL Server VDI permet au logiciel de
sauvegarde de tirer parti des technologies matérielles (fractionnement en miroir) ou logicielles (copie sur
écriture) pris en charge par les périphériques NAS pour effectuer des copies rapides des fichiers de base de
données localement sur le NAS. Ces technologies évitent non seulement la surcharge de copie des fichiers sur le
réseau pour la sauvegarde, mais elles peuvent également réduire les temps de restauration par ordre de
magnitude.
Les sauvegardes stockées sur NAS sont vulnérables aux mêmes défaillances qui affectent les fichiers de base de
données stockés sur le NAS. Vous devez envisager de protéger ces sauvegardes en les copiant sur d’autres
supports.
Cau t i on
Vous pouvez être en état d’altération de la base de données dans la sauvegarde si vous utilisez des technologies
de sauvegarde NAS sans SQL Server prise en charge VDI. Ce type d’altération inclut des pages corrompues ou
des incohérences entre les fichiers journaux et de données s’ils sont stockés sur des appareils distincts. SQL
Server pouvez pas détecter les pages ou les incohérences tant que vous n’avez pas restauré la base de données
et accédez aux données endommagées. Microsoft ne prend pas en charge l’utilisation de technologies de
sauvegarde NAS qui ne sont pas coordonnées avec SQL Server.
La prise en charge des sauvegardes et la prise en charge des fournisseurs NAS pour SQL Server VDI varient.
Pour plus d’informations sur la prise en charge VDI, consultez vos fournisseurs de logiciels NAS et de
sauvegarde.
Microsoft invite les clients qui envisagent de déployer une solution NAS pour les bases de données SQL Server
à consulter leur fournisseur NAS pour s’assurer que la conception de la solution de bout en bout est pour une
utilisation de base de données. De nombreux fournisseurs NAS ont des guides de meilleures pratiques et des
configurations certifiées pour cette utilisation. Microsoft recommande également aux clients de comparer leurs
performances d’O/S pour s’assurer qu’aucun des facteurs d’O/S mentionnés précédemment ne provoque un
goulot d’étranglement dans leur application.
La liste suivante décrit la prise en charge des fichiers basés sur le réseau sur SQL clusters de failover :
SQL Server 2008 R2 et versions antérieures : non pris en charge
SQL Server 2012 et versions ultérieures : pris en charge
Pour plus d’informations, consultez la rubrique SQL Server Books Online suivante :
Installer les SQL Server avec le stockage de partage de fichiers SMB
Notes supplémentaires
Une utilisation incorrecte du logiciel de base de données avec un produit NAS, ou une utilisation de base de
données avec un produit NAS mal configuré, peut entraîner une perte de données, y compris la perte totale de
base de données. Si le périphérique NAS ou le logiciel réseau ne respectent pas complètement les garanties de
données, telles que l’écriture ou l’écriture, le matériel, les logiciels ou même les pannes d’alimentation peuvent
sérieusement compromettre l’intégrité des données.
Références
DBCC TRACEON - Trace Flags (Transact-SQL)
SQL Server Conditions requises pour le programme de fiabilité des entrées et des services d’entreprise.
SQL Server Moteur de base de données’entrée/sortie requises
Prise en charge SQL Server sur les composants de
technologie iSCSI
Cet article présente la prise en charge des SQL Server sur les composants de technologie iSCSI.
Résumé
Microsoft prend en charge Microsoft SQL Server lorsqu’il est déployé sur des composants technologiques iSCSI
(Internet Small Computer System Interface) qui ont reçu la qualification du programme Designed for Windows
Logo Program. SQL Server installations qui utilisent iSCSI nécessiteront ces périphériques matériels iSCSI en
plus des cartes réseau requises pour les communications réseau classiques.
iSCSI est un protocole de transport SCSI pour le mappage des données de stockage orientées bloc sur des
réseaux TCP/IP. Lorsque vous déployez SQL Server dans un environnement iSCSI, Microsoft vous recommande
d’utiliser la prudence appropriée. L’implication d’un réseau peut introduire des composants qui ne sont
généralement pas vus comme des chemins d’accès d’I/S haut débit.
Les systèmes d’exploitation Microsoft présentent les appareils iSCSI sous forme de lecteurs ordinaires. Pour les
utilisateurs et les applications, y SQL Server, la destination distante est encapsulée. Pour optimiser le débit,
veillez à vous assurer que l’ordinateur exécutant SQL Server est configuré pour optimiser les activités de mise
en cache et assurez-vous que la latence impliquée dans le trafic iSCSI est réduite.
SQL Server systèmes doivent prendre en charge la « distribution garantie sur les supports stables » comme
indiqué dans la SQL Server des programmes de fiabilité des SQL Server’entreprise. Pour plus d’informations sur
les exigences en matière d’entrée et de sortie pour le moteur de base de données SQL Server, voir Moteur de
base de données Microsoft SQL Server’entrée/sortie requises.
Erreur « La transaction n’est plus valide » lorsque le
courrier de la base de données ne parvient pas à
envoyer un message SQL Server
Cet article vous aide à résoudre le problème où le courrier de base de données ne parvient pas à envoyer un
message.
Version du produit d’origine : SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017 sur
Linux, SQL Server 2017 sur Windows
Symptômes
Supposons qu’un utilisateur qui exécute Microsoft SQL Server ne peut pas envoyer de courrier de base de
données. Dans ce cas, le journal de messagerie de base de données (sysmail_event_log) affiche l’entrée suivante
:
Informations sur les exceptions : Type d’exception :

Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException
Message : la transaction n’est plus valide.
Données : System.Collections.ListDictionaryInternal
TargetSite : Void ValidateConnectionAndTransaction()
HelpLink: NULL
Source : DatabaseMailEngine
Informations StackTrace : sur
Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.ValidateConnectionAndTra
nsaction()
at Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.RollbackTransaction()
at
Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.GetDataFromQueue(DataAcces
sAdapter da, Int32 lifetimeMinimumSec)
at Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems(String
dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel, Byte[] encryptionKey,
Int32 connectionTimeout)',@proc
NOTE
L’expression qui n’est plus valide apparaît ainsi dans le champ Message pour signifier que la transaction n’est plus
valide.
Vous pouvez voir le même message dans le journal des applications. Le message électronique restera à l’état «
nouvelle tentative » et ne sera pas envoyé tant que le programme DatabaseMail.exe externe ne pourra
sysmail_unsentitems pas s’exécuter correctement.
Cause
L SQL Server de connexion par défaut utilise SET NUMERIC_ARITHABORT ON . Lorsque vous sp_send_dbmail
exécutez , le message électronique est mis en file d’attente vers ExternalMailQueue . Lorsqu’un message
apparaît dans la file d’attente, la procédure stockée d’activation déclenche DatabaseMail.exe exécutable externe.
Lorsque DatabaseMail.exe est connecté à SQL Server, il s’exécute afin de lire les messages de sp_readrequest
la file d’attente. Pendant l’exécution sp_readrequest de , vous pouvez remarquer que l’exception se produit.
L’instruction suivante est exécuté (vous devez collecter le suivi au niveau de SELECT l’instruction pour voir cette
sp_readrequest SELECT instruction) :
DatabaseMail - DatabaseMail - Id\<ProcessId> \<NTUserName> \<SPID> \<StartTime>

msdb \<LoginSid> \<SessionLoginName>
-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort on
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
2 - Pooled 1 1 - Non-DAC
RPC:Starting <BinaryData> 4 <NTUserName> DatabaseMail - DatabaseMail - Id<ProcessId> <NTUserName> <SPID>
<StartTime> sp_readrequest msdb <LoginSid> <SessionLoginName> exec sp_readrequest @receive_timeout=600000
SP:StmtStarting <BinaryData> 4 <NTUserName> DatabaseMail - DatabaseMail - Id<ProcessId> <NTUserName> <SPID>

<StartTime> sp_readrequest msdb <LoginSid> <SessionLoginName>
SELECT @mailitem_id = MailRequest.Properties.value('(MailItemId)[1]', 'int')

FROM @xmlblob.nodes('
declare namespace requests="https://schemas.microsoft.com/databasemail/requests]";/requests:SendMail')
AS MailRequest(Properties)
If SET NUMERIC_ARITHABORT ON is set as default connection option, this SELECT statement will encounter error
1934 and an exception will occur:
Exception 4 <servername> DatabaseMail - DatabaseMail - Id<ProcessId> <NTUserName> <SPID> <StartTime> 1934

msdb <LoginSid> <SessionLoginName> SELECT failed because the following SET options have incorrect settings:
'NUMERIC_ROUNDABORT'.
Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or
filtered indexes and/or query notifications and/or XML data type methods and/or spatialindex operations.
Lorsque DatabaseMail.exe rencontre l’exception, une récupération est tentée, mais échoue. L’exception entraîne
la sortie de l’étendue de la transaction. Pour cette raison, un message de transaction qui n’est plus valide est
consigné dans le journal de messagerie de la base de données.
Toutefois, la cause première du problème est que l’erreur 1934 se produit en raison d’une option SET
incompatible lorsque la méthode de type de données XML ( ) est utilisée dans
MailRequest.Properties.value('(MailItemId)[1]', 'int') l’instruction. SELECT
Vérifier le message d’erreur

Vérifiez si le message d’erreur dans le journal de messagerie de base de données est le même message
(La transaction n’est plus valide).
Rassemblez un suivi du profileur en activé les événements au niveau de l’instruction, les erreurs et les
avertissements et les événements Broker.
Vérifiez le paramètre SQL Server’instance de connexion pour les options de connexion par défaut. Pour
ce faire, ouvrez SQL Ser ver Management Studio, cliquez avec le bouton droit sur Ser veur, puis
sélectionnez > Propriétés Connexions Options de connexion par défaut abandon > > numérique .
Résolution
Pour résoudre ce problème, modifiez l’option de connexion par défaut sur SET NUMERIC_ROUNDABORT
OFF .
Le SQL Server journal des transactions de la base
de données n’augmente pas par rapport à la valeur
de croissance de fichier configurée
Cet article vous aide à résoudre le problème où le fichier journal des transactions de SQL Server base de
données n’augmente pas par la valeur de croissance de fichier configurée.
Version du produit d’origine : SQL Server 2008, SQL Server 2008 R2
Symptômes
La valeur de croissance de fichier configurée pour le fichier journal des transactions de la base de données SQL
Server est de 4 gigaoctets (Go) ou de multiples (par exemple, 8 Go, 12 Go, et ainsi de suite). Toutefois, le fichier
journal des transactions n’augmente pas de cette valeur. Au lieu de cela, le fichier journal des transactions
augmente par incréments de 250 kilo-octets (Ko). En outre, vous remarquerez qu’il y a beaucoup de fichiers
journaux virtuels dans le fichier journal des transactions.
Résolution
Pour SQL Ser ver 2008 R2
Le correctif de ce problème a été publié pour la première fois dans la base de données KB2633145
(package de mise à jour cumulative 11 pour SQL Server 2008 R2).
NOTE
Étant donné que les builds sont cumulatives, chaque nouvelle version de correctif contient tous les correctifs et
tous les correctifs de sécurité inclus dans la version précédente du correctif SQL Server 2008 R2. Nous vous
recommandons d’envisager d’appliquer la version de correctif la plus récente qui contient ce correctif. Pour plus
d’informations, voir les builds SQL Server 2008 R2 publiées après SQL Server version 2008 R2.
Pour SQL Ser ver 2008 R2 Ser vice Pack 1

Le correctif de ce problème a été publié pour la première fois dans la mise à jour cumulative 4. Pour plus
d’informations sur l’obtention de ce package de mise à jour cumulative pour SQL Server 2008 R2, voir
Package de mise à jour cumulative 4 pour SQL Server 2008 R2 Service Pack 1.
NOTE
Étant donné que les builds sont cumulatives, chaque nouvelle version de correctif contient tous les correctifs et
tous les correctifs de sécurité inclus dans la version précédente du correctif SQL Server 2008 R2. Nous vous
recommandons d’envisager d’appliquer la version de correctif la plus récente qui contient ce correctif. Pour plus
d’informations, voir les builds SQL Server 2008 R2 publiées après SQL Server version 2008 R2.
Modifiez la valeur de croissance du fichier SQL Server journal des transactions de la base de données de façon à
ce qu’il ne soit pas divisible de 4 Go.
Vous pouvez utiliser la requête suivante pour identifier le fichier journal des transactions SQL Server base de
données de données :
SELECT name FROM sys.master_files name

FROM sys.master_files WHERE database_id = DB_ID('<db name>')
AND type = 1
AND is_percent_growth = 0
AND growth % 524288 = 0
Pour plus d’informations sur les produits ou outils qui vérifient automatiquement la croissance des fichiers de 4
Go ou de multiples sur votre instance de SQL Server et sur les versions du produit SQL Server, consultez le
tableau suivant :
VERSIO N S DE P RO DUIT S
P O UR L ESQ UEL L ES L A
LO GIC IEL DE RÈGL E T IT RE DE L A RÈGL E DESC RIP T IO N DE L A RÈGL E RÈGL E EST ÉVA L UÉE
System Center Advisor SQL Server de base de System Center Le conseiller SQL Server 2008, SQL
données peut ne pas détermine si le fichier Server 2008 R2
augmenter à l’aide de la journal des transactions de
valeur de croissance la base de données SQL
configurée Server est configuré pour
une valeur de croissance de
4 Go ou plusieurs et génère
un avertissement si c’est le
cas. Examinez les
informations fournies dans
la section Informations
collectées de l’avertissement
et a apporté les
modifications nécessaires au
journal des transactions
concerné.
Si le journal des transactions contient un grand nombre de fichiers journaux virtuels, vous rencontrerez une
récupération de base de données longue. Pour plus d’informations, voir Les opérations de base de données
prennent beaucoup de temps, ou elles déclenchent des erreurs lorsque le journal des transactions contient de
nombreux fichiers journaux virtuels.
Résoudre les erreurs de cohérence de base de
données signalées par DBCC CHECKB
Cet article explique comment résoudre les erreurs signalées par la commande DBCC CHECKDB.
Symptômes
Lorsque le DBCC CHECKDB (ou d’autres commandes similaires telles que CHECKTABLE) est exécuté, un message
comme le suivant est écrit dans le SQL Server ERRORLOG :
Date/Heure spid53 DBCC CHECKDB (mydb) exécuté par MYDOMAIN\theuser a trouvé 15 erreurs et réparé
les erreurs. Durée écoulée : 0 heure 0 minute 0 seconde. La capture instantanée de base de données interne
a un point de fractionnement LSN = 00000026:0000089d:0001 et le premier LSN =
00000026:0000089c:0001. Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur
n’est requise.
Ce message indique le nombre d’erreurs de cohérence de base de données trouvées et le nombre d’erreurs
réparées (si une option de réparation a été utilisée avec la commande). Ce message est également écrit dans le
journal des événements de l’application Windows en tant que message de niveau Informations avec
EventID=8957 (même si des erreurs sont signalées, ce message est un message de niveau Informations).
Informations dans le message commençant par « capture instantanée de base de données interne... » s’affiche
uniquement si DBCC CHECKDB a été exécuté en ligne, dans lequel la base de données n’est pas en SINGLE_USER
mode. En effet, pour une base de données CHECKDB DBCC en ligne, une capture instantanée de base de
données interne est utilisée pour présenter un ensemble cohérent de données à vérifier.
Cet article n’explique pas comment résoudre chaque erreur spécifique signalée par DBCC CHECKDB, mais plutôt
l’approche générale si des erreurs sont signalées. Toute référence à CHECKDB dans cet article s’applique
également DBCC CHECKTABLE et CHECKFILEGROUP sauf mention.
Cause
DBCC CHECKDB vérifie la cohérence physique et logique des pages de base de données, des lignes, des pages
d’allocation, des relations d’index, de l’intégrité référentielle des tables système et d’autres vérifications de
structure. Si l’une de ces vérifications échoue (selon les options que vous avez choisies), des erreurs sont
signalées dans le cadre de la commande.
La cause de ces problèmes peut varier en raison de l’altération du système de fichiers, des problèmes du
système matériel sous-jacent, des problèmes de pilotes, des pages endommagées en mémoire ou des
problèmes liés au moteur SQL Server. Consultez la section Résolution pour plus d’informations sur la recherche
de la cause des erreurs signalées.
Résolution
La première solution, la meilleure si le DBCC CHECKDB signale des erreurs de cohérence, consiste à restaurer à
partir d’une sauvegarde appropriée connue. Toutefois, si vous ne pouvez pas restaurer à partir d’une
sauvegarde, CHECKDB fournit une fonctionnalité pour réparer les erreurs. Si des problèmes au niveau du
système, tels que le système de fichiers ou le matériel, peuvent être à l’origine de ces problèmes, nous vous
recommandons de les corriger d’abord avant de restaurer ou d’exécutez la réparation.
Lorsque vous exécutez DBCC CHECKDB, une recommandation est fournie pour indiquer l’option de réparation
minimale requise pour réparer toutes les erreurs. Ces messages peuvent ressembler à ce qui suit :
CHECKDB a trouvé 0 erreur d’allocation et 15 erreurs de cohérence dans la base de données « mydb ».
repair_allow_data_loss est le niveau de réparation minimal pour les erreurs trouvées par DBCC CHECKDB
(mydb).
La recommandation de réparation est le niveau minimal de réparation pour tenter de résoudre toutes les
erreurs de CHECKDB. Cela ne signifie pas que cette option de réparation corrigera en réalité toutes les erreurs.
En outre, toutes les erreurs signalées ne peuvent pas nécessiter ce niveau de réparation pour résoudre l’erreur.
Cela signifie que toutes les erreurs signalées par CHECKDB lorsqu’elles sont recommandées
repair_allow_data_loss entraînent une perte de données. La réparation doit être exécuté pour déterminer si la
résolution d’une erreur entraîne une perte de données. Une technique permettant d’affiner le niveau de
réparation de chaque table consiste à utiliser DBCC CHECKTABLE pour toute table signalant une erreur. Cela
indique le niveau minimal de réparation pour un tableau donné.
Pour trouver la cause des erreurs de cohérence de base de données, envisagez les méthodes ci-après :
Vérifiez la Windows journal des événements système pour les erreurs de niveau système, de pilote ou de
disque.
Vérifiez l’intégrité du système de fichiers avec chkdsk.
Exécutez les diagnostics fournis par vos fabricants de matériel pour l’ordinateur et/ou le système de disque.
Travaillez avec votre fournisseur de matériel ou votre fabricant d’appareils pour vous assurer que :
Les périphériques matériels et la configuration s’Moteur de base de données Microsoft SQL Server
aux exigences d’entrée/sortie.
Les pilotes de périphérique et les autres composants logiciels de prise en charge de tous les appareils
dans le chemin d’accès d’I/S sont mis à jour.
Envisagez d’utiliser un utilitaire tel que SQLIOSim sur le même lecteur que les bases de données qui ont
signalé les erreurs de cohérence. SQLIOSim est un outil indépendant du moteur SQL Server pour tester
l’intégrité des O/S pour le système de disque. SQLIOSim est SQL Server 2008 et ne nécessite pas de
téléchargement séparé.
Recherchez les autres erreurs signalées par SQL Server telles que les violations d’accès ou les assertions.
Assurez-vous que vos bases de données utilisent PAGE_VERIFY CHECKSUM l’option. Si des erreurs de sommes
de contrôle sont signalées, il s’agit d’indicateurs qui indiquent que les erreurs de cohérence se sont produites
après que SQL Server a écrit des pages sur le disque afin que votre système de disque soit minutieusement
vérifié, voir Comment résoudre les problèmes de Msg 824 dans SQL Server pour plus d’informations sur les
erreurs de sommes de contrôle.
Recherchez les erreurs Msg 832 dans ERRORLOG. Ces indicateurs montrent que les pages peuvent être
endommagées lorsqu’elles sont en cache avant d’être écrites sur le disque. Pour plus d’informations, voir
comment résoudre les problèmes de Msg 832 SQL Server.
Essayez de restaurer une sauvegarde de base de données dont vous savez qu’elle est « propre » (aucune
erreur provenant de CHECKDB) et que les sauvegardes du journal des transactions que vous connaissez
s’étendent pendant toute la durée de l’erreur. Si vous pouvez « relire » ce problème en restaurant une
sauvegarde de base de données « propre » et des journaux des transactions, contactez le Support technique
Microsoft pour obtenir de l’aide.
Les erreurs de collecte de données peuvent être un problème lors de l’insertion ou de la mise à jour de
données non valides dans SQL Server tables. Pour plus d’informations sur la résolution des erreurs de
collecte de données, voir Troubleshooting DBCC Error 2570 in SQL server 2005.
Pour plus d’informations sur la syntaxe de DBCC CHECKDB et des informations/options sur l’exécution de la
commande, voir DBCC CHECKDB (Transact-SQL).
Si des erreurs ont été trouvées par CHECKDB, des messages supplémentaires tels que les suivants sont signalés
dans le journal d’erreurs à des fins de rapport d’erreurs :
Date/Time spid53 Using 'dbghelp.dll' version '4.0.5'

Date/Heure spid53 **Thread de vidage - spid = 0, EC = 0x00000000855F5EB0
Date/Heure spid53 ***Vidage de pile envoyé àFilePath\FileName
Date/Time spid53 * *******
Date/Heure spid53 *
Date/Heure spid53 * DÉBUT DU VIDAGE DE PILE :
Date/Time spid53 * Date/Timespid 53
Date/Heure spid53 *
Date/Heure spid53 * Corruption de la base de données DBCC
Date/Timespid53 *
Date/Heure spid53 * Mémoire tampon d’entrée 84 octets -
Date/Heure spid53 * dbcc checkdb(mydb)
Date/Heure spid53 *
Date/Time spid53 * *******
Date/Heure spid53 * -------------------------------------------------------------------------------
Date/Heure spid53 * Vidage de pile court
Date/Time spid53 Stack Signature for the dump is 0x00000000000001E8
Date/Heure spid53 Le processus de vidage externe retourne le code 0x20002001.
Les informations d’erreur ont été envoyées au rapport d’erreurs Watson.

Les fichiers utilisés pour le rapport d’erreurs incluent un fichier.txt <nnn> SQLDump. Ce fichier peut être utile à
des fins historiques, car il contient une liste des erreurs trouvées à partir de CHECKDB dans un format XML.
Pour savoir à quel moment DBCC CHECKDB a été exécuté pour la dernière fois sans qu’aucune erreur n’a été
détectée pour une base de données (la dernière nouvelle checkDB connue), recherchez dans le journal des
erreurs SQL Server un message comme le suivant pour votre base de données ou base de données système (ce
message est écrit en tant que message de niveau d’information dans le journal des événements d’application
Windows avec EventID = 17573) :
Date/Heure spid7s CHECKDB pour la base de données « master » terminée sans erreurs
onDate/Time22:11:11.417 (heure locale). Il s’agit d’un message d’information uniquement . aucune action de
l’utilisateur n’est requise
Message d’erreur : le fournisseur OLE DB
SQLOLEDB n’a pas pu commencer une transaction
distribuée
Cet article vous aide à contourner le problème que le message d’erreur du fournisseur OLE DB SQLOLEDB n’a
pas pu commencer une transaction distribuée.
Symptômes
Lorsque vous essayez d’utiliser Microsoft SQL Server pour démarrer une transaction distribuée entre des
serveurs liés exécutant Windows Server, vous pouvez recevoir le message d’erreur suivant :
Le fournisseur OLE DB SQLOLEDB n’a pas pu commencer une transaction distribuée
Le message suivant peut apparaître sur l’ordinateur fournisseur OLE DB :
La nouvelle transaction ne peut pas être inscrite dans le coordinateur de transaction spécifié.
Cause
Ce comportement se produit si le service DTS (Distributed Transaction Coordinator) est désactivé ou si l’accès
DTC réseau est désactivé. Par défaut, l’accès DTC réseau est désactivé dans Windows Server.
Pour contourner ce problème, installez l’accès DTC réseau sur les deux serveurs :
1. Cliquez sur Démarrer , puis sur Panneau de configuration .
2. Cliquez sur Ajouter ou supprimer des programmes, puis sur Ajouter/Supprimer Windows
composants.
3. Dans la zone Composants, cliquez sur Ser veur d’applications, puis sur Détails.
4. Cliquez pour activer la case à cocher Activer l’accès DTC réseau, puis cliquez sur OK.
5. Cliquez sur Suivant, puis suivez les instructions qui apparaissent à l’écran pour terminer le processus
d’installation.
6. Arrêtez, puis redémarrez le service Coordinateur des transactions distribuées.
7. Arrêtez puis redémarrez tous les services de gestionnaire de ressources qui participent à la transaction
distribuée (par exemple, Microsoft SQL Server serveur de files d’attente de messages Microsoft).
L’utilisation de pilotes d’hôte virtuel peut entraîner
SQL Server Moteur de base de données problèmes
de cohérence des données
Cet article vous aide à résoudre le problème où l’utilisation de pilotes d’hôte virtuel peut entraîner SQL Server
Moteur de base de données problèmes de cohérence des données.
Symptômes
Vous pouvez remarquer qu’une instance de Microsoft SQL Server signale un ou plusieurs des messages d’erreur
suivants dans le journal des erreurs SQL Server et dans le journal des événements d’application :
Erreur 824 : SQL Server détecté une erreur d’E/S logique basée sur la cohérence : pageid incorrect
(prévu 1:425920 ; 65535:0). Elle s’est produite lors d’une lecture de page (1:425920) dans l’ID de base
de données 2 au décalage 0x000000cff80000 dans le fichier « D:\DBName.mdf ». Des messages
supplémentaires dans le SQL Server d’erreurs ou le journal des événements système peuvent fournir
plus de détails. Il s’agit d’une condition d’erreur grave qui menace l’intégrité de la base de données et
doit être corrigée immédiatement. Effectuer une vérification de la cohérence de base de données
complète (DBCC CHECKDB). Cette erreur peut être causée par de nombreux facteurs . Pour plus
d’informations, voir SQL Server Books Online.
2011-02-24 00:20:32.55 Erreur spid65 : 605, Gravité : 21, État : 3. 2011-02-24 00:20:32.55 spid65
Échec de la tentative d’extraction de la page logique (1:17479052) dans la base de données 8. Il
appartient à l’unité d’allocation 0 et non à 72057610609819648.
Erreur 823 Le système d’exploitation a renvoyé l’erreur pageid incorrecte (prévue 1:306208 ; 65535:0)
à SQL Server lors d’une lecture au 0x00000095840000 décalage dans le fichier « R:\DBName.mdf ».
Des messages supplémentaires dans le SQL Server d’erreurs et le journal des événements système
peuvent fournir plus de détails. Il s’agit d’une condition d’erreur grave au niveau du système qui
menace l’intégrité de la base de données et qui doit être corrigée immédiatement. Effectuer une
vérification de la cohérence de base de données complète (DBCC CHECKDB). Cette erreur peut être
causée par de nombreux facteurs . Pour plus d’informations, voir SQL Server Books Online.
Erreur 18400 Le thread de point de contrôle en arrière-plan a rencontré une erreur irrécable. Le
processus de point de contrôle se termine afin que le thread puisse nettoyer ses ressources. Il s’agit
d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise.
La sauvegarde a détecté une altération du journal dans la base de données DBName. Le contexte est
FirstSector. LogFile : 2 'R:\DBName.LDF' VLF SeqNo: x3c1c3 VLFBase: x6a850000 LogBlockOffset:
x6bbcde00 SectorStatus : 2 LogBlock.StartLsn.SeqNo: x560053 LogBlock.StartLsn.Blk: x2d0043 Size:
x53 PrevSize: x5c.
Vous pouvez également remarquer que la commande DBCC CHECKDB signale des problèmes de cohérence de
base de données.
Cause
L’équipe du support technique et des services client (CSS) de Microsoft a déterminé que le pilote d’hôte virtuel
suivant peut provoquer le comportement :
Nom du pilote : C:\WINDOWS\SYSTEM32\DRIVERS\XGVHBA.SYS
Nom du fournisseur : Xsigo Systems
Xsigo Systems (fournisseur du pilote d’hôte virtuel) indique qu’il s’agit d’un problème avec le pilote d’hôte
virtuel XGVHBA.SYS lorsque la version est entre 2.6.0.0 et 2.7.1.0.
Résolution
Contactez Xsigo Systems pour obtenir une version du pilote qui est corrigée. La version fixe est la version 2.7.3.0
et les versions ultérieures. Ensuite, configurez les adaptateurs Xsigo Virtual HBA pour utiliser les pilotes mis à
jour.
MSSQLSERVER_824
MSSQLSERVER_823
produits.
Les mots qui ont des points décimaux non plus ne
sont pas renvoyés par un sécateur de mots anglais
dans SQL Server
Cet article vous aide à résoudre le problème où une recherche à l’aide d’un sécateur de mots anglais ne
retourne pas les mots qui ont des points décimaux de début dans SQL Server 2017 sur Windows, SQL Server
2016, 2014 et 2012.
Symptômes
Dans un sécateur de mots en anglais, vous utilisez un index de texte intégral pour indexer le contenu qui
contient des mots qui ont des points décimaux de début, tels .325 que , .434 . .646 Lorsque vous essayez de
localiser des lignes dans l’index en recherchant la valeur décimale (par exemple, ), aucune ligne .325 n’est
renvoyée.
Utilisez l’inserreur de mots neutre.
Placez un zéro devant la virgule décimale lorsque vous utilisez un sécateur de mots anglais. Par exemple,
utilisez 0.325 plutôt que dans votre .325 recherche. L’décomposeur de mots anglais gère correctement
l’indexation et la recherche lorsqu’il rencontre des zéros non élevés.

1. Créez un index de texte intégral pour créer un index qui contient des mots qui ont des points décimaux de
premier plan, tels que .325 , et ainsi de .434 .646 suite.
2. Utilisez la requête de texte intégral suivante pour rechercher ces valeurs à l’aide d’un sécateur de mots
anglais dont le LCID est 1033 :
Select * from sys.dm_fts_parser('"Ring, .325 x .434 .646 Platinum"', 1033, 0,0)
Résultats
O C C URREN C SP EC IA L _T ER DISP L AY _T ER
M OT C L É GRO UP _ID P H RA SE_ID E M M REM A RQ UES
0x00770061 1 0 1 Corresponda Anneau

007300680 nce exacte
0650072
0x002E0033 1 0 2 Corresponda .325 Conserve la

00310033 nce exacte décimale
0x006E006E 1 0 2 Corresponda nn0d325

033003100
33
0x0078 1 0 3 Noise Word x
0x006E006E 1 0 4 Corresponda .434 Conserve la

038
0x006E006E 1 0 4 Corresponda nn434

038
0x00300034 1 0 5 Corresponda .646 Conserve la


00340036 nce exacte
0x00730068 1 0 6 Corresponda Pays-De-La

0069006D nce exacte
3. Essayez d’effectuer une .325 recherche (y compris la virgule décimale) :
Select * from sys.dm_fts_parser('.325', 1033, 0,0) Using English word breaker to specify the ".325"
search term.
NOTE
Nous n’avons pas de correspondance.
Résultats
0x00330031 1 0 1 Corresponda 325 Supprime la

0033 nce exacte décimale lors
de la
recherche et
325 <>
,325, donc
aucune ligne
renvoyée

033
Dans cet exemple, si vous entrez comme valeur .325 de recherche, aucune ligne n’est renvoyée. En effet,
nous avons indexé les données en conservant la virgule décimale, mais l’analyseur lexique anglais
supprime la virgule au cours du processus de recherche. Par conséquent, nous faisons une recherche par
inadvertance sur 325 au lieu .325 de , et aucune correspondance n’est trouvée.
La recherche d’un index de texte intégral à l’aide d’un sécateur de mots anglais pour les mots qui ont des
points décimaux de début fonctionne correctement si nous utilisons l’outil de coupure de mots neutre.
4. Exécutez la requête suivante à l’aide de l’outil d’coupure de mots neutre :
Select * from sys.dm_fts_parser('"Ring, .325 x .434 .646 Platinum"', 0, 0,0)
Résultats
0x00770061 1 0 1 Corresponda Anneau

0650072


033003100
33
0x0078 1 0 3 Noise Word x


034003300
38


030003400
36
0x00730068 1 0 6 Corresponda Pays-De-La

0069006D nce exacte
À présent, la recherche .325 fonctionne comme prévu.
Select * from sys.dm_fts_parser('.325', 0, 0,0) Specifying Neutral word breaker.
Résultats
0x002E0033 1 0 1 Corresponda .325

00310033 nce exacte

033003100
33
La désinstallation du pilote laisse des traces lorsque
ODBC 13(.1)/17(.1) est installé sur Windows
Sur un ordinateur Windows avec les pilotes ODBC 17 et ODBC 13 installés, la désinstallation de l’un ou l’autre
de ces pilotes laisse les restes de la version désinstallée. Cet article fournit plus d’informations sur le problème
et la résolution du problème.
Symptômes
Supposons que le pilote ODBC Microsoft 13/13.1 pour SQL Server et le pilote ODBC 17/17.1 pour SQL Server
sont installés sur le même ordinateur Windows. Si vous désinstallez l’une ou l’autre version, le pilote désinstallé
reste visible, mais devient inutilisable dans l’administrateur de source de données ODBC (odbcad32.exe). En
outre, certaines entrées de Registre correspondantes restent sous la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI
Cause
Ce problème se produit en raison d’un problème de programme d’installation ODBC 17/17.1.
Résolution
Ce problème a été résolu dans le pilote ODBC 17.2. Pour résoudre ce problème :
1. Désinstallez le pilote ODBC 17/17.1.
2. Installez ODBC 17.2ou une version ultérieure du pilote.
Référence
Pilote ODBC Microsoft 17.2 SQL Server publié
Les utilisateurs peuvent ne pas être en mesure de se
connecter à distance SQL serveur à l’aide du
protocole TCP/IP
Cet article vous aide à résoudre le problème où vous ne pouvez pas vous connecter à distance à SQL à l’aide du
protocole TCP/IP.
Symptômes
Lorsque vous utilisez Microsoft SQL Server, vous pouvez voir un ou plusieurs des symptômes suivants :
Seuls les utilisateurs qui ont l’autorisation CONTROL SERVER (par exemple, les membres du rôle serveur
fixe syadmin) peuvent se connecter via TCP/IP. Les utilisateurs qui n’ont pas cette autorisation ne peuvent
pas se connecter à distance via le protocole TCP/IP à l’aide Windows ou SQL Server’authentification.
NOTE
Vous remarquerez que les connexions utilisateur élevées s’afficheront uniquement en mode gestion dynamique
sys.dm_exec_sessions (Transact-SQL), mais pas en mode sys.dm_exec_connections (Transact-SQL).
Les connexions locales et distantes utilisant le protocole Named Pipes, ainsi que les connexions locales
utilisant le protocole de mémoire partagée continuent de fonctionner parfaitement.
En outre, les messages suivants sont enregistrés dans le fichier SQL Server Errorlog :
À SQL Server démarrer :

Le fournisseur TCP du serveur n’a pas réussi à écouter ['any' <ipv6> 1963]. Le port Tcp est déjà en
cours d’utilisation.
Le transport de protocole Service Broker ne peut pas écouter sur le port 1963, car il est utilisé par un
autre processus.
Pour les connexions qui ont échoué :

SQL Server 2008 et versions ultérieures :

Échec de la connexion de l’utilisateur « MyDomain\TestAcc ». Raison : la validation de l’accès au
serveur basé sur un jeton a échoué avec une erreur d’infrastructure. Recherchez les erreurs
précédentes.
Cause
L’erreur se produit lorsque vous configurez un point de terminaison TCP pour Service Broker à l’aide du port
que l’instance SQL Server est configurée pour utiliser. Vous pouvez obtenir la liste des points de terminaison en
exécutant la requête suivante :
select * from sys.tcp_endpoints
NOTE
Comme expliqué dans la rubrique Books Online sur sys.tcp_endpoints (Transact-SQL),cet affichage ne contient pas
d’informations sur les ports et protocoles que l’instance SQL Server est actuellement configurée pour utiliser. Pour
rechercher ces informations, utilisez Gestionnaire de configuration SQL Server.
Résolution
Méthode 1 : déposer le point de terminaison à l’origine du problème à l’aide de la commande DROP
ENDPOINT (Transact-SQL).
Par exemple, pour déposer un point de terminaison TestEP nommé, vous pouvez utiliser la commande
suivante :
DROP ENDPOINT TestEP
Méthode 2 : modifier le point de terminaison pour utiliser un autre port à l’aide de la commande ALTER
ENDPOINT (Transact-SQL).
Par exemple, pour modifier un point de terminaison nommé TestEP pour utiliser un autre port, vous
pouvez utiliser la commande suivante :
ALTER ENDPOINT TestEP as tcp (listener_port=1980)
Des problèmes similaires peuvent également se produire avec d’autres points de terminaison TCP tels que ceux
créés pour la mise en miroir de base de données et les messages d’erreur au démarrage SQL Server changent
en conséquence.
Kerberos Configuration Manager pour SQL Server
est disponible
Cet article décrit l’outil de diagnostic Microsoft Kerberos Configuration Manager pour SQL Server.
À propos de Kerberos Configuration Manager

Cet outil est disponible en téléchargement à partir du Centre de téléchargement Microsoft :
Microsoft® Kerberos Configuration Manager pour SQL Server®
Le Gestionnaire de configuration Kerberos pour SQL Server est un outil de diagnostic qui permet de résoudre
les problèmes de connectivité liés à Kerberos avec SQL Server, SQL Server Reporting Services (SSRS) et SQL
Server Analysis Services (SSAS). Il peut effectuer les fonctions suivantes :
Collectez des informations sur le système d’exploitation, Microsoft SQL Server instances et les écouteurs de
groupe de disponibilité Always On installés sur un serveur.
Signaler toutes les configurations de nom principal de service (SPN) et de délégation sur le serveur.
Identifiez les problèmes potentiels dans les SSN et les délégations.
Résoudre les problèmes potentiels de SPN.
Cet outil permet de résoudre les exceptions suivantes :
401
NOTE
Ce message d’erreur est pour les erreurs http, les erreurs SSRS et d’autres erreurs similaires.
Échec de connexion pour l’utilisateur 'NTAUTHORITY\ANONYMOUS'

Échec de connexion pour l’utilisateur '(null)'
Échec de la connexion de l’utilisateur
Impossible de générer le contexte SSPI
Pour plus d’informations sur Kerberos Configuration Manager, consultez les informations suivantes :
1. Instructions d’installation et sections Informations supplémentaires sur la page de téléchargement
2. Les billets de blog suivants sur TechCommunity :
a. Publication : mise à jour pour Kerberos Configuration Manager pour SQL Server
b. Publication : Microsoft Kerberos Configuration Manager pour SQL Server 4.1 - Microsoft Tech
Community
Pour démarrer l’outil :
1. Une fois l’installation terminée, accédez au dossier d’installation (l’emplacement du dossier par défaut est
C:\Program Files\Microsoft\Kerberos Configuration Manager for SQL Server\ )
2. Double-cliquez sur KerberosConfigMgr.exe pour démarrer l’application.
3. Pour résoudre le problème de connectivité avec SQL Server, connectez-vous à l’ordinateur de destination à
l’aide d’un compte d’utilisateur de domaine qui dispose des autorisations utilisateur sur cet ordinateur.
4. Pour résoudre le problème de connectivité avec SSRS, connectez-vous à l’ordinateur de destination à l’aide
d’un compte d’utilisateur de domaine qui dispose d’autorisations administratives sur cet ordinateur.
Pour générer la liste SPN à par tir de la ligne de commande :
1. Allez à la ligne de commande.
NOTE
Pour résoudre le problème de connectivité avec SSRS, démarrez la fenêtre de ligne de commande en tant
qu’administrateur.
2. Basculez vers le dossier où KerberosConfigMgr.exe se trouve.

3. Tapez KerberosConfigMgr.exe -q -l .
4. Pour plus d’option de ligne de commande, tapez KerberosConfigMgr.exe -h .
Pour enregistrer les informations de configuration Kerberos d’un ser veur :

1. Connecter serveur Windows cible.
2. Cliquez sur le bouton Enregistrer dans la barre d’outils.
3. Spécifiez l’emplacement où vous souhaitez que le fichier soit enregistré. Il peut se trouver sur un lecteur local
ou un partage réseau.
4. Le fichier sera enregistré au format .XML format.
Pour afficher les informations de configuration Kerberos d’un ser veur à par tir du fichier
enregistré :
1. Cliquez sur le bouton Charger dans la barre d’outils.
2. Ouvrez le fichier XML généré par Kerberos Configuration Manager.
Pour générer un script pour corriger le SPN à par tir de la ligne de commande :
1. Cliquez sur le bouton Générer pour l’entrée SPN.
2. Le script généré peut être utilisé par un utilisateur qui dispose des autorisations pour corriger le SPN sur le
serveur.
Pour voir les fichiers journaux de cet outil :
Par défaut, un fichier journal est généré chaque fois que l’application est exécuté dans le dossier de données
d’application de l’utilisateur : %APPDATA%\Microsoft\KerberosConfigMgr .
Pour Aide :
Option 1 : placez le pointeur sur la commande d’une boîte à outils.
Option 2 : Exécuter KerberosConfigMgr.exe -h à partir de la ligne de commande.
Option 3 : cliquez sur le bouton Aide dans la barre d’outils.
S’applique à
SQL Server 2005 Developer Edition
SQL Server 2005 Enterprise Edition
SQL Server 2005 Enterprise X64 Edition
SQL Server Version d’évaluation 2005
SQL Server 2005 Express Edition
SQL Server 2005 Édition Standard
SQL Server 2005 Standard X64 Edition
SQL Server 2005 Workgroup Edition
SQL Server 2008 Developer
SQL Server 2008 Édition Standard for Small Business
SQL Server Web 2008
SQL Server Web 2012
SQL Server Web 2014
Résolution des erreurs de connectivité SQL Server
Cet article vous aide à résoudre différents problèmes de connectivité SQL serveur.
NOTE
Pour une visite guidée de cet article, voir Résolution des erreurs de connectivité SQL Server.
Version du produit d’origine : Microsoft SQL Server

Conditions préalables
Pour utiliser efficacement cet dépannage, vous pouvez collecter les informations suivantes.
1. Texte complet du message d’erreur avec les codes d’erreur et si l’erreur est intermittente (se produit
uniquement parfois) ou cohérente (se produit tout le temps).
2. Leslogs d’SQL Server à partir des lesquels vous pouvez noter les remarques suivantes :
a. Nom de domaine complet (FQDN) de l’ordinateur SQL Server ou en cas d’installations en cluster,
nom virtuel du nom de domaine complet. Si vous utilisez une instance nommée, notez le nom de
l’instance.
NOTE
Vous pouvez rechercher la chaîne « Nom du serveur » pour obtenir ces informations dans lelog des
erreurs.
b. Bibliothèques réseau et ports sur SQL instance est à l’écoute. Exemples de messages :
Canaux nommés : le fournisseur de connexion local du serveur est prêt à accepter la connexion
sur [ \ \ .\pipe\sql\query ]. TCP/IP et numéro de port : le serveur est à l’écoute sur [ ::1 1433].
3. Journaux d’événements système et d’applications SQL Server et des systèmes clients.

4. Si les connexions échouent à partir d’une application, la chaîne de connexion de l’application. Ceux-ci se
trouvent généralement dansWeb.config fichiers pour ASP.NET applications.
Liste de vérification
Assurez SQL le serveur est démarré et que le message suivant s’SQL Server ErrorLog :
SQL Server est maintenant prêt pour les connexions client. Il s’agit d’un message d’information ;
aucune action de l’utilisateur n’est requise.
Vérifiez la connectivité de base sur l’adresse IP et vérifiez les problèmes :

ping -a <SQL Server machine>, ping -a <SQL Server IP address> Si vous remarquez des problèmes,
travaillez avec votre administrateur réseau pour résoudre le même problème.
Vérifiez si SQL est à l’écoute sur les protocoles appropriés en vérifiant ErrorLog.
Vérifiez si vous êtes en mesure de vous connecter à SQL serveur à l’aide d’un fichier UDL. Si elle
fonctionne, il se peut qu’il y a un problème avec la chaîne de connexion. Pour obtenir des instructions sur
la procédure sur le test UDL, Connecter vers SQL serveur à l’aide d’une section de fichier UDL.
Vérifiez si vous êtes en mesure de vous connecter à SQL Server à partir d’autres systèmes clients et de
connexions utilisateur différentes. Si vous le pouvez, le problème peut être spécifique au client ou à la
connexion qui rencontre le problème. Vérifiez les journaux Windows événements sur le client
problématique pour les pointeurs supplémentaires. Vérifiez également si les pilotes réseau sont à jour.
Si vous rencontrez des échecs de connexion, assurez-vous que l’utilisateur dispose d’une connexion au
niveau du serveur et des autorisations appropriées pour se connecter à la base de données à qui
l’utilisateur tente de se connecter.
Une erreur liée au réseau ou à l’instance s’est produite lors de

l’établissement d’une connexion SQL Server
Pour plus d’informations sur l’erreur pertinente, consultez la section Vérifier les erreurs de connexion suivante.
Vérifier les erreurs de connexion
L’erreur liée au réseau A ou à l’instance s’est produite lors de l’établissement d’une connexion à SQL
Server’erreur représente un ou plusieurs des messages d’erreur suivants :
Une erreur liée au réseau ou à l’instance s’est produite lors de l’établissement d’une connexion SQL
Server. Le serveur n’a pas été trouvé ou n’est pas accessible. Vérifiez que le nom de l’instance est correct
et que SQL Server est configuré pour autoriser les connexions distantes.
provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified
SQL Server Native Client Erreur de lien de données
[Microsoft SQL Server Native Client 10.0]: Login timeout expired

[Microsoft SQL Server Native Client 10.0]: A network-related or instance-specific error has occurred
while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance
name is correct and if SQL Server is configured to allow remote connections. For more information
see SQL Server Books Online.
[Microsoft SQL Server Native Client 10.0]: SQL Server Network Interfaces: Error Locating
Server/Instance Specified [xFFFFFFFF].
fournisseur : Fournisseur TCP, erreur : 0

Une tentative de connexion a échoué car la partie connectée n’a pas répondu correctement après un
certain temps, ou la connexion établie a échoué car l’hôte connecté n’a pas réussi à répondre.
Microsoft SQL Server, Erreur : 10060
provider: Named Pipes Provider, error:40 - Could not open a connection to SQL Server
Microsoft SQL Server, Erreur :53
Le chemin d’accès réseau est in trouvé
[Microsoft] [SQL Server Native Client 11.0] Fournisseur TCP : aucune connexion n’a pu être réalisée
car l’ordinateur cible l’a activement refusée.
[Microsoft] [SQL Server Native Client 11.0] Expiration du délai d’expiration de la connexion
[Microsoft] [SQL Server Native Client 11.0] Une erreur liée au réseau ou à l’instance s’est produite
lors de l’établissement d’une connexion SQL Server. Le serveur n’est pas trouvé ou n’est pas
accessible. Vérifiez si le nom de l’instance est correct et si SQL Server est configuré pour autoriser les
connexions à distance. Pour plus d’informations, voir SQL Server Books Online.
Vous pouvez commencer à résoudre les problèmes à partir de cette section : Causes courantes de divers
problèmes de connexion.
Causes courantes de divers problèmes de connexion
Recherchez chacune des causes applicables à votre instance ci-dessous et, pour chacune des causes applicables,
essayez les résolutions correspondantes.
Cause 1 : nom de serveur incorrect spécifié dans la chaîne de connexion ou dans la boîte de dialogue nom du serveur
Pour confirmer :
Assurez-vous que le nom du serveur que vous spécifiez correspond à ce que vous avez dans le journal
des erreurs.
Accédez au fichier Editing ASP.NET Configuration Files pour votre application et assurez-vous que la
section Chaînes de connexion pointe vers le nom de serveur approprié et utilise les chaînes de
connexion SQL Server correctes pour les applications Web ASP.NET.
NOTE
Pour obtenir par programme les chaînes de connexion à partir de votre application, reportez-vous à l’exemple
dans la procédure : Lire les chaînes de connexion à partir du Web.config .
Cause 2 : Alias incorrect sur l’ordinateur client

Les alias sont généralement utilisés dans les environnements lorsque vous devez vous connecter à SQL Server
avec un autre nom ou lorsqu’il existe des problèmes de résolution de noms dans le réseau. Un alias incorrect sur
l’ordinateur client peut entraîner l’échec des connexions à partir de vos applications vers le serveur incorrect.
Points à essayer :
Ouvrez SQL Server’utilitaire réseau client en tapantcliconfg.exe dans votre commande Exécuter.
Vérifiez si des alias sont définis pour le serveur à qui vous essayez de vous connecter.
Si ce n’est pas le cas, faites les choses suivantes :
1. Cliquez sur Modifier et renommez l’alias de serveur. (par exemple, si votre nom de serveur est
MySQL, renommez-le MySQL_test) et réessayez la connexion. Si la connexion fonctionne, cela
indique que vous avez un alias incorrect, probablement à partir d’une ancienne configuration qui
n’est plus nécessaire. Si vous continuez à faire l’expérience de l’erreur, renommez l’alias à son nom
d’origine et procédez à l’étape suivante.
2. Vérifiez les paramètres connection de l’alias et assurez-vous qu’ils sont corrects. Voici quelques-
uns des scénarios courants qui peuvent entraîner des problèmes de connectivité :
Adresse IP incorrecte pour le paramètre Nom du serveur. Assurez-vous que cette adresse IP
correspond à l’entrée du SQL ErrorLog.
Nom de serveur incorrect dans le paramètre Nom du serveur. Par exemple, si votre alias de
serveur pointe sur le nom de serveur correct, si le paramètre Nom du serveur a une valeur
incorrecte, les connexions échouent.
Si vous utilisez un alias de canaux nommé, assurez-vous que le nom du canal a le format
correct.
Pour la connexion à l’instance par défaut nommée Mydefaultinstance, le nom du canal
doit être \\Mydefaultinstance\pipe\sql\query
Pour la connexion à une instance nommée MySQL\Named, le nom du canal doit être
\\MySQL\pipe\MSSQL$Named\sql\query
Cause 3 (instance par défaut) : pare-feu entre le client et le serveur bloquant le port SQL Server instance est à l’écoute sur
Instance par défaut : une instance par défaut s’exécute généralement sur le port 1433. Certaines installations
utilisent également un port non standard (autre que 1433) pour l’exécution SQL instances. Le pare-feu peut
bloquer l’un d’eux.
Points à essayer :
Déterminez le numéro de port SQL instance est en cours d’exécution. Si l’instance par défaut de votre
serveur SQL utilise un port non standard, consultez l’SQL Server Exécution de l’instance « Par défaut »
sur un port TCP non par défaut (ou non standard): : conseils pour que la connectivité des applications
fonctionne.
Essayez d’attendre le numéro de port SQL Server au nom du serveur en utilisant le format
<servername> , numéro de port et voir si cela fonctionne. Par exemple, si votre nom d’instance SQL est
MySQLDefaultinstance et qu’il s’exécute sur le port 2000, spécifiez le nom du serveur en tant que
MySQLServer, 2000 et voyez si cela fonctionne. Si elle fonctionne, cela indique que le pare-feu bloque le
port.
S’il est confirmé, ajoutez le port à la liste d’exclusions du pare-feu. Pour obtenir des instructions, déplacez-
vous vers la section Configuration des pare-feu.
Cause 4(instance nommée) : SQL navigateur n’est pas démarré
Les applications clientes qui se connectent à une instance nommée de SQL Server utilisent le service navigateur
SQL sur le système sur lequel SQL est en cours d’exécution pour édifier le port sur lequel SQL est à l’écoute. Si le
service de navigateur n’est pas démarré, les connexions échouent.
Points à essayer :
Sur le système exécutant votre instance SQL Server, utilisez le gestionnaire de configuration SQL Server ou
l’applet Services dans le Panneau de configuration et démarrez le service SQL Browser s’il n’est pas déjà
démarré. Pour plus d’informations, voir How to: Start and Stop the SQL Server Browser Service
Cause 5 (instance nommée) : le port UDP 1434 utilisé par SQL navigateur est bloqué sur le réseau
Si votre instance SQL est une instance nommée, elle peut avoir été configurée pour utiliser des ports
dynamiques ou un port statique. Dans les deux cas, les bibliothèques réseau sous-jacentes interrogent le service
de navigateur SQL qui s’exécute sur votre ordinateur SQL Server via le port UDP 1434 pour éumer le numéro
de port de l’instance nommée. Si un pare-feu entre le client et le serveur bloque ce port UDP, la bibliothèque
cliente ne peut pas déterminer le port (une exigence de connexion) et la connexion échoue.
Pour confirmer :
Méthode 1 :
1. Notez le port sur SQL instance est à l’écoute à partir du SQL Server Errorlog.
2. Essayez de vous connecter à l’instance nommée en utilisant le numéro de port qui est appendé au
nom du serveur en utilisant le format <nom_serveur\nom_instance>, numéro_port et voir si cela
fonctionne. Si elle fonctionne, cela indique que le pare-feu bloque le port UDP 1434. Par exemple, si le
nom de votre instance SQL est MySQL\Namedinstance et qu’elle s’exécute sur le port 3000, spécifiez
le nom du serveur en tant que MySQL\Namedinstance, 3000 et voyez si cela fonctionne. Si elle
fonctionne, cela peut signifier que le port UDP 1434 est bloqué ou que le port statique est bloqué ou
les deux. Pour vérifier s’il s’agit du port UDP ou du port statique à l’aide de Portqry à partir de la
méthode 2 ci-dessous.
Méthode 2 :
1. Utilisez l’outil PortqryUI avec votre instance nommée et observez la sortie qui en résulte. Si le
message vous indique que le port UDP 1434 est filtré, cela indique que le port est bloqué sur le
réseau. Pour obtenir des instructions sur l’utilisation de l’outil, utilisez l’outil PortqryUI avec SQL Server
section.
Points à essayer :
Déterminez d’abord si SQL Server instance est à l’écoute sur un port dynamique ou statique et utilisez la
procédure qui est pertinente pour votre scénario. Pour savoir si SQL est à l’écoute sur les ports dynamiques et
statiques, déplacez-vous vers Indiquer si SQL est à l’écoute dans la section Ports dynamiques ou statiques.
Cas 1 : ports dynamiques. Dans ce cas, vous devez vous assurer que le service de navigateur SQL est bien
démarré et que le port UDP 1434 n’est pas bloqué sur le pare-feu entre le client et le serveur. Si vous ne
pouvez pas faire l’une ou l’autre d’entre elles, vous devez basculer votre instance SQL Server pour utiliser
un port statique et utiliser la procédure documentée dans Configurer un serveur pour écouter sur un
port TCP spécifique.
Cas 2 : la configuration du port statique et SQL navigateur ne sont pas en cours d’exécution ou UDP 1434
ne peut pas être ouvert sur le pare-feu. Dans ce cas, vous devez vous assurer que le port statique est
spécifié dans votre chaîne de connexion et que ce port n’est pas bloqué par le pare-feu. Pour obtenir des
instructions, déplacez-vous vers la section Configuration des pare-feu.
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
Configuration des pare -feu
Si vous utilisez un pare-Windows, utilisez la procédure documentée dans la rubrique SQL Server Books
Online :
Configurez un pare-Windows pour Moteur de base de données Access.
Si vous utilisez un pare-feu personnalisé, travaillez avec votre administrateur réseau pour ouvrir les ports
nécessaires.
Vous trouverez ci-dessous quelques captures d’écran rapides montrant la configuration requise d’un pare-feu
Windows pour les connexions réussies à une instance par défaut et à une instance nommée.
Instance par défaut de SQL Server à l’écoute sur le port par défaut 1433 sur Windows 2012 R2. Dans ce
scénario, vous devez vous assurer qu’une exception est ajoutée au port TCP 1433 dans le pare-feu
Windows.
1. Ouvrez Windows pare-feu sur le système hébergeant SQL instance par défaut du serveur et
cliquez sur Nouvelle règle sous Règles de trafic entrant.
2. Sélectionnez l’option Port, puis cliquez sur Suivant.
3. Dans l’écran suivant :

Sélectionnez TCP comme protocole.
Sélectionnez des por ts locaux spécifiques et spécifiez la valeur 1433, puis cliquez sur
Suivant .
4. Dans l’écran suivant, sélectionnez Autoriser la connexion, puis cliquez sur Suivant.
5. Dans l’écran suivant, sélectionnez l’option qui convient le mieux à votre environnement, puis
cliquez sur Suivant.
6. Dans l’écran suivant, donnez le nom à votre règle et fournissez une description claire pour
référence ultérieure, puis cliquez sur Terminer.
7. Une fois l’option effectuée, vous devez voir que la règle est créée et activée par défaut.
Ajout d’une exception au port UDP 1434 pour activer les connexions à une instance nommée de SQL
serveur :
1. Ouvrez Windows pare-feu sur le système hébergeant SQL instance par défaut du serveur et
cliquez sur Nouvelle règle sous Règles de trafic entrant.
2. Sélectionnez l’option Port, puis cliquez sur Suivant.

3. Dans l’écran suivant :
Sélectionnez UDP comme protocole.
Sélectionnez des por ts locaux spécifiques et spécifiez la valeur 1434, puis cliquez sur
Suivant .
4. Dans l’écran suivant, sélectionnez Autoriser la connexion, puis cliquez sur Suivant.
5. Dans l’écran suivant, sélectionnez l’option qui convient le mieux à votre environnement, puis
cliquez sur Suivant.
6. Dans l’écran suivant, donnez le nom à votre règle et fournissez une description claire pour
référence ultérieure, puis cliquez sur Terminer.
7. Une fois l’option effectuée, vous devez voir que la règle est créée et activée par défaut.
Utilisation de l’outil PortqryUI avec SQL Server
Emplacement de téléchargement : PortqryUI
1. Lancez l’outil PortqryUI sur votre ordinateur client. (l’ordinateur sur lequel vous avez des problèmes de
connexion, pour les applications web, il peut s’y avoir le serveur IIS)
2. Spécifiez le nom de serveur de SQL Server instance de SQL ou le nom de serveur de SQL dans l’adresse IP
ou le nom de domaine complet de destination à interroger.
3. Sélectionnez Ser vice de requête prédéféré et sélectionnez SQL service dans la liste liste.
4. Cliquez sur Requête, examinez la sortie et utilisez le tableau suivant pour obtenir des pointeurs
supplémentaires.
C A USES P OT EN T IEL L ES DES

P RO B L ÈM ES DE
T Y P E D’IN STA N C E SO RT IE DE P O RTQ RY C O N N EXIO N Q UE FA IRE ?
P RO B L ÈM ES DE
Instance par défaut Port TCP 1433 (service ms- Indique l’une des Assurez-vous SQL
sql-s) : NON À L’ÉCOUTE informations suivantes : est démarré.
SQL n’est pas Vérifiez SQL journal
démarré. d’erreurs pour le
Le protocole TCP/IP numéro de port et
n’est pas activé SQL utilisez-le dans vos
liste de protocoles chaînes de
du serveur. connexion au format
SQL est à l’écoute <servername> ,
sur un port autre numéro de port.
que le port par Travaillez avec votre
défaut. (vérifier lelog administrateur
des erreurs) réseau/windows
Le pare-feu entre le pour vous assurer
client et le serveur que le port TCP
bloque le port. 1433 n’est pas
bloqué par un pare-
feu sur le réseau ou
par le pare-feu
Windows sur le
système SQL Server.
Remarque Si vous
souhaitez résoudre un
problème de pare-feu,
déplacez-vous vers la
section Configuration des
pare-feu.
Instance par défaut Port TCP 1433 (service ms- La bibliothèque Vérifiez si le nom du
sql-s) : LISTENING cliente peut se serveur est
connecter à correctement
l’ordinateur SQL spécifié dans la
serveur, mais un chaîne de connexion.
autre problème dans Si la chaîne de
la couche connexion utilise le
d’application peut numéro de port, elle
être à l’origine du est correctement
problème. spécifiée dans la
chaîne de connexion.
Tous les anciens alias
définis dans la zone.
P RO B L ÈM ES DE
Instance nommée Port UDP 1434 (service ms- Indique l’une des Le service est
sql-m) : FILTRÉ informations suivantes : démarré.
SQL instance SQL service de
nommée n’est pas navigateur est
démarrée. démarré.
SQL navigateur n’a Travaillez avec votre
pas démarré sur le administrateur
système hébergeant réseau/windows
SQL instance. pour vous assurer
Le port UDP 1434 que le port UDP
est bloqué par un 1434 n’est pas
pare-feu sur le bloqué par un pare-
serveur SQL ou sur feu sur le réseau ou
le réseau entre le par le pare-feu
client et le serveur. Windows sur le
système SQL Server.
Remarque Si vous
souhaitez résoudre un
problème de pare-feu,
déplacez-vous vers la
section Configuration des
pare-feu.
Instance nommée Le port UDP 1434 est À La bibliothèque Le nom du serveur

L’ÉCOUTE cliente peut se est correctement
connecter à spécifié dans la
l’ordinateur SQL chaîne de connexion.
serveur, mais un Le numéro de port
autre problème dans est incorrectement
la couche spécifié dans la
d’application peut chaîne de connexion.
être à l’origine du Tous les anciens alias
problème. définis dans la zone.
Exemples de sorties :
Instance par défaut sur le port par défaut : scénario de travail
Instance par défaut sur le port par défaut : scénario de non-travail
Instance nommée : scénario de travail : (nom de l’instance : SQL 2014, nom d’hôte : SQLCONNVM)
Instance nommée : Scénario de non-travail : (nom de l’instance : SQL 2014, nom d’hôte : SQLCONNVM)
Pour plus d’informations, voir la section Configuration des pare-feu.
Savoir si SQL est à l’écoute sur les ports dynamiques et statiques
1. Dans Gestionnaire de configuration SQL Server, dans le volet console, développez SQL Server
Configuration réseau, développez Protocoles pour, puis double-cliquez sur TCP/IP .
2. Dans la boîte de dialogue Propriétés TCP/IP, sous l’onglet Adresses IP, plusieurs adresses IP
apparaissent au format IP1 , IP2 , jusqu’à IPAll . L’une d’elles est pour l’adresse IP de l’adaptateur de
boucle, 127.0.0.1. Des adresses IP supplémentaires apparaissent pour chaque adresse IP sur l’ordinateur.
(Vous verrez probablement les adresses IP version 4 et IP version 6.) Cliquez avec le bouton droit sur
chaque adresse, puis cliquez sur Propriétés pour identifier l’adresse IP à configurer.
3. Si la boîte de dialogue Ports dynamiques TCP contient 0, cela indique que le Moteur de base de données
est à l’écoute sur les ports dynamiques. S’il contient un nombre spécifique, cela signifie que l’instance de
base de données est à l’écoute sur un port statique.
Pour plus d’informations, voir Configurer un serveur pour écouter sur un port TCP spécifique.
Aucune connexion n’a pu être réalisée car l’ordinateur cible l’a

activement refusée
Pour plus d’informations sur l’erreur d’absence de connexion, déplacez-vous vers la section Message d’erreur
complet.
Message d’erreur complet
Vous pouvez obtenir une erreur semblable à celle-ci :
[Microsoft] [SQL Server Native Client 11.0] Fournisseur TCP : aucune connexion n’a pu être réalisée car
l’ordinateur cible l’a activement refusée.
[Microsoft] [SQL Server Native Client 11.0] Expiration du délai d’expiration de la connexion.
[Microsoft] [SQL Server Native Client 11.0] Une erreur liée au réseau ou à l’instance s’est produite lors de
l’établissement d’une connexion SQL Server. Le serveur n’est pas trouvé ou n’est pas accessible. Vérifiez si le
nom de l’instance est correct et si SQL Server est configuré pour autoriser les connexions à distance. Pour
plus d’informations, voir SQL Server Books Online.
SQL Server n’existe pas ou l’accès est refusé

Échec de l’opération de tableau croisé dynamique : nous ne pouvons
pas localiser un serveur pour charger le modèle de données du
workbook
Impossible de générer un message d’erreur de contexte SSPI

L’interface SSPI (Security Support Provider Interface) est un ensemble d’API Windows qui permet la délégation
et l’authentification mutuelle sur n’importe quelle couche de transport de données générique, telle que les
sockets TCP/IP. Par conséquent, sSPI permet à un ordinateur exécutant un système d’exploitation Windows de
déléguer en toute sécurité un jeton de sécurité utilisateur d’un ordinateur à un autre sur n’importe quelle
couche de transport qui peut transmettre des octets bruts de données.
L’erreur de contexte SSPI impossible à générer est générée lorsque le SSPI utilise l’authentification Kerberos
pour déléguer sur TCP/IP et que l’authentification Kerberos ne peut pas effectuer les opérations nécessaires pour
déléguer correctement le jeton de sécurité utilisateur à l’ordinateur de destination qui exécute SQL Server.
Pour plus d’informations sur les raisons pour lesquelles les opérations Kerberos ne peuvent pas être effectuées,
passer à la section Résolution des problèmes d’authentification en raison de problèmes Kerberos pour passer en
revue et implémenter les étapes.
Résolution des problèmes d’authentification en raison de problèmes Kerberos
Des échecs d’authentification Kerberos peuvent se produire pour diverses raisons. Les causes principales et les
résolutions correspondantes sont mises en évidence ci-dessous :
T Y P E DE P RO B L ÈM E RÉSO L UT IO N S SUGGÉRÉES
Problèmes SPN : Consultez la section Utilisation du Gestionnaire de

SPN manquants : le SPN n’est pas enregistré dans configuration Kerberos pour diagnostiquer et résoudre les
Active Directory. problèmes de SPN et de délégation afin de diagnostiquer et
Entrées SPN incorrectes : le SPN existe, mais le de résoudre les problèmes de SPN.
numéro de port est incorrect ou il existe sur un autre
compte que le compte SQL Service. Remarque Pour une compréhension approfondie des SNS,
SPN en double : le même SPN existe sur plusieurs Kerberos et d’autres concepts connexes, examinez les
comptes dans active directory. informations de l’article de la base de connaissances suivant :
Comment résoudre le message d’erreur « Impossible de
générer le contexte SSPI »
SQL Comptes de service non fiables pour la délégation. Si Utilisez l’onglet délégation du Gestionnaire de
vous utilisez un compte système local, le serveur configurationKerberos pour confirmer et travailler avec votre
intermédiaire doit être approuvé pour la délégation dans administrateur Active Directory afin d’activer la délégation
Active Directory. pour le compte. Consultez l’utilisation du Gestionnaire de
configuration Kerberos pour diagnostiquer et résoudre les
problèmes de SPN et de délégation pour plus d’informations
dans le paragraphe suivant.
T Y P E DE P RO B L ÈM E RÉSO L UT IO N S SUGGÉRÉES
Résolution de nom incorrecte : le nom de votre serveur peut ping -a <your_target_machine> (utiliser -4 et -6 pour
se résoudre en une adresse IP différente de celle inscrite par IPv4 et IPv6 spécifiquement)
le serveur DNS de votre réseau. ping -a <Your_remote_IPAddress> nslookup (tapez
votre nom d’ordinateur local et distant et votre adresse IP
plusieurs fois)
Recherchez les incohérences et les incohérences sur les

résultats renvoyés. L’correctité de la configuration DNS sur le
réseau est essentielle pour SQL connexion. Une entrée DNS
erronée peut être à l’origine de toutes sortes de problèmes
de connectivité ultérieurement.
Pare-feu ou autres périphériques réseau empêchant les Pour plus d’informations, consultez les liens suivants :
connexions entre le client et le contrôleur de domaine : les Conditions requises pour les ports d’Active Directory
SSN sont stockés dans Active Directory et si les clients ne et des services de domaine Active Directory
parviennent pas à communiquer avec aD, la connexion ne Outils et outils d’authentification Kerberos
peut pas poursuivre. Paramètres
NOTE
1. Lorsqu’une instance du SQL Server Moteur de base de données démarre, SQL Server tente d’inscrire le SPN pour
le service SQL Server service. Lorsque l’instance est arrêtée, SQL Server tente d’désinsser le SPN. Pour ce faire, le
compte SQL service nécessite des droits ReadSer vicePrincipalName et WriteSer vicePrincipalName dans
l’annuaire actif. Toutefois, si le compte de service ne comprend pas ces droits, l’inscription automatique au SPN ne
se produit pas et vous devez travailler avec votre administrateur Active Directory pour les inscrire pour les
instances SQL afin d’activer l’authentification Kerberos. Dans ce scénario, si vous utilisez une instance nommée, il
sera plus pratique d’utiliser un port statique pour cette instance. Si vous utilisez des ports dynamiques, le numéro
de port peut changer chaque fois que le service est redémarré et que le SPN enregistré manuellement pour
l’instance n’est plus valide. Pour plus d’informations, voir Register a Service Principal Name for Kerberos
Connections.
2. Dans les environnements où SQL est regroupée, l’inscription automatique des SPN n’est pas recommandée, car
l’inscription du SPN dans Active Directory peut prendre plus de temps que le temps nécessaire à la mise en ligne
de SQL. Si l’inscription du SPN ne se produit pas dans le temps, cela peut empêcher SQL de se connecter, car
l’administrateur de cluster n’est pas en mesure de se connecter SQL serveur.
Utilisation du Gestionnaire de configuration Kerberos pour diagnostiquer et résoudre les problèmes de SPN et de délégation
1. Téléchargez Microsoft® Kerberos Configuration Manager pour SQL Server® et installez-le sur un
ordinateur client.
2. Lancez l’outil à l’aide d’un compte de domaine de préférence avec un compte qui dispose de privilèges
suffisants pour créer des noms de service dans votre annuaire Active Directory. Consultez l’image ci-
dessous :
3. Connecter à SQL Server vous souhaitez collecter les informations relatives aux erreurs Kerberos :
4. Une fois connecté, vous pouvez voir différents onglets comme indiqué ci-dessous :
Système : dispose des informations système de base.
SPN : Fournit au SPN des informations sur les instances de chacune des instances de SQL
trouvées sur le serveur cible et fournit différentes options, comme indiqué ci-dessous. Utilisez cet
onglet pour rechercher les SNS manquants ou mal configurés et les boutons Générer ou Corriger
pour résoudre ces problèmes.
L’option Générer vous permet de créer le script de génération de SPN. Cliquez sur le
bouton Générer pour lancer la boîte de dialogue suivante :
Cette option crée un fichier cmd, qui peut être exécuté à partir de l’invite de commandes
pour générer le SPN.
Le contenu des generateSPNs sera similaire à ce qui suit :
:: This script is generated by the Microsoft(c) SQL Server(c) Kerberos Configuration
Manager tool.
:: The script may update the system information, SPN settings and Delegation
configurations of a given server.
:: SPN and Delegation configuration updates require Windows Domain Administrator
permission to execute.
:: A Domain Admin should review the configurations recommended by this tool and take
appropriate actions to enable Kerberos authentication.
:: Please contact Microsoft Support if Kerberos connection problem persists.
:: The file is intended to be run in domain "<DomainName>.com"
:: Corrections for MSSQLSvc/<HostName>.<DomainName>.com **SetSPN -s
MSSQLSvc/<HostName>.<DomainName>.com UserName**
Il utilise simplement l’option SetSPN pour créer un SPN sous le compte de service pour
SQL Server.
L’option de correction ajoute le SPN tant que vous avez le droit d’ajouter le SPN et affiche
l’info-conseil suivante :
NOTE
L’outil fournit uniquement les options Fix et Generate pour les instances par défaut et les
instances nommées avec des ports statiques. Pour les instances nommées utilisant le port
dynamique, il est recommandé de passer de ports dynamiques à statiques ou de donner au
compte de service les autorisations nécessaires pour enregistrer et désinsser le SPN chaque fois
que le service est démarré. Dans le cas contraire, vous devez désins inscrire et réenregistrer
manuellement les SNS correspondants chaque fois que SQL service est démarré.
Onglet Délégation : l’onglet identifie les problèmes avec la configuration du compte de

service pour la délégation. Cela est particulièrement utile pour résoudre les problèmes liés
au serveur. Par exemple, si les SNS s’exécutent correctement mais que vous avez encore des
problèmes avec des requêtes de serveur liées, cela peut indiquer que le compte de service
n’est pas configuré pour déléguer les informations d’identification. Pour plus
d’informations, ez la rubrique en ligne Livres sur la configuration des serveurs liés pour la
délégation.
5. Une fois que vous avez corrigé les SPN, réexécutez l’outil Gestionnaire de configuration Kerberos et
assurez-vous que les onglets SPN et Délégation ne signalent plus les messages d’erreur et retentent la
connexion à partir de votre application.
Pour plus d’informations, examinez les liens suivants :
SQL Server Référence rapide kerberos et SPN
Kerberos Configuration Manager pour SQL Server est disponible
Supplément technique Kerberos pour Windows
Comment être opérationnel avec Oracle et les serveurs liés
Échec de connexion pour l’utilisateur

Il peut y avoir une erreur plus spécifique. Sélectionnez l’erreur exacte que vous recevez :
Échec de connexion de l’utilisateur « AUTORITÉ NT\OUVERTURE DE SESSION ANONYME »
Échec de connexion pour l’utilisateur '(null)'
Échec de connexion pour l’utilisateur est vide
Échec de la connexion pour l’utilisateur <username> ' '
Échec de la connexion pour l’utilisateur <domain> \ <username> ' '
Échec de la connexion pour l’utilisateur <computername$> ' '
Échec de connexion de l’utilisateur « AUTORITÉ NT\OUVERTURE DE SESSION ANONYME »
Il existe au moins trois scénarios pour ce problème. Utilisez le tableau suivant pour passer en compte chaque
scénario applicable et suivre les étapes de résolution appropriées.
C A USE P OT EN T IEL L E RÉSO L UT IO N S SUGGÉRÉES
Scénarios de double saut sur le même ordinateur : vous Pour les scénarios de double saut sur le même ordinateur,
essayez d’utiliser un double saut, mais les informations ajoutez des entrées de Registre DisableLoopbackCheck ou
d’identification NTLM sont utilisées à la place de Kerberos. BackConnectionHostNames comme suit :
DisableLoopbackCheck. Permet d’y faire les choses de
la bonne façon
Scénarios de double saut sur plusieurs ordinateurs : l’erreur Passer à la section : Résolution des problèmes
peut se produire en cas d’échec des connexions Kerberos en d’authentification en raison de problèmes Kerberos en bas
raison de problèmes de SPN. pour voir les détails.
Aucun double saut n’est impliqué. Si aucun double saut n’est impliqué, cela peut également
signifier qu’il existe des SNS dupliqués et que le client
s’exécute en tant que LocalSystem ou un autre compte
d’ordinateur qui obtient les informations d’identification
NTLM au lieu des informations d’identification Kerberos.
Passer à la section : Résolution des problèmes

d’authentification en raison de problèmes Kerberos pour
diagnostiquer et résoudre les problèmes de SPN.
Windows stratégie de sécurité locale a peut-être été Sur Windows 2008 R2/Windows 7 et ultérieures, la sécurité
configurée pour empêcher l’utilisation du compte réseau des options de sécurité des stratégies de sécurité
d’ordinateur pour les comptes locaux. locales peut être configurée pour ne pas utiliser le compte
d’ordinateur pour les comptes locaux et utiliser les
informations d’identification anonymes à la | | place.
Échec de connexion pour le message de l’utilisateur « (null) »
Cela signifie que LSASS n’a pas pu déchiffrer le jeton de sécurité à l’aide des informations d SQL Server de
compte de service. La raison principale est que le SPN est associé à un compte erroné.
Pour diagnostiquer et résoudre ces problèmes de SPN, déplacez-vous vers la section Résolution des problèmes
d’authentification en raison des problèmes Kerberos.
Échec de connexion pour l’utilisateur est vide
Par exemple, vous pouvez voir une erreur semblable à ce qui suit :
Source: NETLOGON
Date: 8/12/2012 8:22:16 PM
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <computer name>
Description:This computer was not able to set up a secure session with a domain controller in domain due to
the following: The remote procedure call was cancelled. This may lead to authentication problems. Make sure
that this computer is connected to the network. If the problem persists, please contact your domain
administrator.
Empty string means that SQL tried to hand-off the credentials to LSASS but there was some problem. Either
LSASS was not available or the domain controller could not be contacted.
Check the event logs on the client and the server machines to see if there are any network or Active
Directory related messages around the time of failure and if you do, work with your domain administrator to
fix the issues.
La connexion a échoué pour <username> l’utilisateur ' ou la connexion a échoué pour l’utilisateur <domain> \
<username> ' '
Si le nom de domaine n’est pas spécifié, il s’agit d’un SQL connexion. S’il est spécifié, il s’agit d’une connexion
Windows-Integrated défaut. Examinez le tableau suivant pour déterminer les causes et les résolutions
potentielles.
C A USE ÉTA P ES DE RÉSO L UT IO N
La base de données demandée est hors ligne ou n’est pas Vérifiez les autorisations et la disponibilité de la base de
disponible. données dans SQL Server Management Studio.
L’utilisateur n’a pas d’autorisations sur la base de données Essayez de vous connecter en tant qu’autre utilisateur
demandée. dispose de droits sysadmin.
Pour obtenir des conseils supplémentaires, examinez la résolution des problèmes : Échec de connexion pour
l’utilisateur « x».
Échec de la connexion de l’utilisateur <domaine\nom_ordinateur$>'
Vous pouvez également le voir avec les applications IIS qui utilisent la connexion anonyme ou la connexion de
formulaire où le compte d’utilisateur n’est pas usurpé. Le compte iis anonyme (IUSR) ou le compte du pool
d’applications est à la place emprunt d’identité. Le compte IUSR est un compte local et le compte du pool
d’applications peut également être un compte local.
Cette erreur se produit généralement si l’utilisateur est connecté avec un compte local plutôt qu’un compte de
domaine. Si la connexion aux services est hors zone, les informations d’identification de l’ordinateur peuvent
être transmises. Dans certains cas, vous pouvez ajouter ce compte en tant que connexion sur le serveur
principal. Dans d’autres cas, vous pouvez vous connecter avec un compte de domaine et lui fournir les
autorisations appropriées pour accéder au service distant.
Vérifier les erreurs d’expiration du délai d’expiration

L’erreur Expiration du délai d’expiration représente un ou plusieurs des messages d’erreur suivants :
Expiration du délai d’expiration. Le délai d’expiration s’est produit avant la fin de l’opération ou le serveur ne
répond pas.
System.Data.SqlClient.SqlException (0x80131904) : expiration du délai de connexion.

Le délai d’attente s’est écoulé lors de la tentative d’utiliser l’accusé de réception d’une connexion préalable.
Cela peut être dû à l’échec de la connexion préalable ou à l’échec de la réponse du serveur dans le temps.
La durée passée lors de la tentative de connexion à ce serveur était l’initialisation de [pré-connexion] = 23 ;
handshake=14979; ---> System.ComponentModel.Win32Exception (0x80004005) : l’opération d’attente a
été hors délai.
System.Data.SqlClient.SqlException (0x80131904) : expiration du délai d’expiration.

Le délai d’expiration s’est produit avant la fin de l’opération ou le serveur ne répond pas.
System.ComponentModel.Win32Exception (0x80004005) : l’opération d’attente a été hors délai.
Expiration du délai de connexion.

Le délai d’attente s’est écoulé lors de la tentative d’utiliser l’accusé de réception d’une connexion préalable.
Cela peut être dû à l’échec de la connexion préalable ou à l’échec de la réponse du serveur dans le temps.
La durée passée lors de la tentative de connexion à ce serveur était l’initialisation de [pré-connexion]
=21036 ; handshake=0; (Microsoft SQL Server, Erreur : -2).
NOTE
Les deuxième et troisième messages d’erreur se produisent lorsque .Net Framework 4.5 ou supérieur est installé.
Vous pouvez commencer à résoudre les problèmes à partir de la section suivante : Résolution des messages
expirés de délai d’expiration.
Résolution des problèmes de messages expirés
Un délai d’délai est le moment où un quelque chose prend plus de temps qu’il n’est autorisé. Nous abandonnons
essentiellement ce que nous essayions de faire pour ne pas attendre indéfiniment et éventuellement bloquer
d’autres éléments et bloquer une application. Du point de vue de la connectivité, dans sa forme de base, nous
pouvons voir cela de deux manières. L’un est un délai de connectivité, l’autre un délai d’accès à la requête. Vous
devez donc d’abord examiner la pile d’appels complète du message d’erreur pour déterminer s’il s’agit d’un délai
d’accès ou d’un délai d’accès à une commande.
NOTE
Les valeurs par défaut de ces paramètres qui peuvent être définies par le biais du code, de la chaîne de connexion et
d’autres méthodes sont les suivantes :
Délai de connexion : 15 secondes
Délai d’out de requête ou de commande : 30 secondes
Une pile d’appels de délai d’délai de connexion ressemble à ceci :
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion

of the operation or the server is not responding.
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean
breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32
error)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject
stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()
at System.Data.SqlClient.TdsParser.ConsumePreLoginHandshake(Boolean encrypt,Boolean trustServerCert,
Boolean& marsCapable)
at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds
connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean
trustServerCert, Boolean integratedSecurity, SqlConnectionowningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfoserverInfo, String
newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword,
Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions,
Int64 timerStart)
at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject,
SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity,
SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection
owningObject, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object
poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection,
DbConnectionPool pool, DbConnectionOptions options)
at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject) at
System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)
at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection,
DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open() <-- SqlConnection along with Open tells us that we are
trying to open a connection. So, this is not related to a query.
Un délai d’accès à la commande dans .NET 2.0 Framework ressemble à ceci :

System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion
of the operation or the server is not responding.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader
dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior,
String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior
cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior
runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior
runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteScalar() <-- SqlCommand is used to work with a query, not
a connection. ExecuteScalar is used to actually execute a query. You could also see other items like
an ExecuteReader or ExecuteNonQuery for example.
Étapes de résolution : ces deux problèmes peuvent être liés à l’environnement SQL Server problèmes. Par
exemple, il peut s’agit d’un réseau lent ou d’un problème de performances de requête. Il n’existe pas de règles
strictes et rapides, car ce qui pourrait être fait ici et d’autres enquêtes peuvent être nécessaires quant à ce qui
pourrait être à l’origine du problème. Il est beaucoup plus courant d’augmenter le délai d’out de requête que
d’augmenter le délai de connexion. En effet, lorsque vous essayez de vous connecter à une source de données, la
connexion se produit généralement rapidement (généralement en quelques millisecondes).
TYPE C H O SES À FA IRE
Délai de connexion
1. Augmentez ConnectionTimout dans votre application.
2. Vérifiez si le port utilisé par SQL est bloqué sur le réseau à
l’aide d’un outil tel que Por tqr y . Pour obtenir des
instructions sur son utilisation, SQL Server à l’aide de l’outil
PortqryUI.
Délai d’out de la commande

Augmentez la valeur CommandTimeout dans votre
application et a affiner les requêtes exécutées sur le back-
end.
Pour plus d’conseils et de suggestions, consultez : Résolution des problèmes : Expiration du délai d’expiration.
Délai d’attente écoulé avant l’obtention d’une connexion à partir du

pool
Elle est généralement causée si les connexions ne sont pas correctement fermées et que l’erreur complète peut
ressembler à ce qui suit :
System.InvalidOperationException : expiration du délai d’expiration. Le délai d’attente s’est écoulé avant

l’obtention d’une connexion à partir du pool.
Cela peut être dû au fait que toutes les connexions en pool étaient en cours d’utilisation et que la taille maximale
du pool a été atteinte. Cela peut généralement être évité par expiration du délai d’expiration. Le délai d’attente
s’est écoulé avant l’obtention d’une connexion à partir du pool.
Connecter serveur SQL à l’aide d’un fichier UDL

Pour plus d’informations sur le test des connexions à SQL Server à l’aide d’un fichier de liaison de données
universelle, voir les connexions de test suivantes à SQL Server à l’aide d’une section de fichier de liaison de
données universelle.
Tester les connexions à SQL Server à l’aide d’un fichier de liaison de données universelle
Les fichiers UDL offrent un moyen simple et efficace de tester les connexions à votre serveur SQL à partir de vos
clients ou d’autres systèmes.
1. Activez l’option pour afficher les extensions de fichier dans votre Windows explorer. Pour cela :
a. Sur Windows 8 et les systèmes ultérieurs : allez à Options de l’Explorateur de fichiers dans le
Panneau de contrôle ou tapez simplement Masquer dans la recherche Windows et dans l’onglet
Affichage, décochez Masquer les extensions pour les types de fichiers connus.
b. Windows 7 et versions antérieures :
2. Accédez au dossier dans lequel vous souhaitez créer le fichier de liaison de données universelle (.udl) (par
exemple c:\temp)
3. Créez un fichier texte (sqlconn.txt) et renommez l’extension .txt .udl. (cliquez sur Oui pour le message
d’avertissement concernant la modification de l’extension de nom de fichier)
4. Double-cliquez sur le fichier .udl de l’étape 3 et faites ce qui suit :
a. Dans l’onglet Fournisseur, sélectionnez le fournisseur que vous utilisez dans votre application (par
exemple, SQL Server Native Client)
b. Dans l’onglet Connexion, sélectionnez ou entrez votre SQL Server et le reste des paramètres
pertinents pour votre application
5. Cliquez ensuite sur Tester la connexion.
Pour plus d’informations et de captures d’écran, consultez le billet de blog suivant sur MSDN :
Informations de base : « Test UDL »
Encore des problèmes
Nous sommes désolés que ce guide ne vous ait pas permis de résoudre votre problème. Nous vous
recommandons d’aller au SQL Community Microsoft pour obtenir de l’aide. Voici quelques ressources
supplémentaires que vous pourriez trouver utiles :
Étapes à suivre pour résoudre SQL problèmes de connectivité
Résolution des problèmes de connexion au serveur et à la base de données
Résoudre les problèmes de connexion au SQL Server Moteur de base de données
Le certificat reçu du serveur distant a été émis par
une erreur d’autorité de certification non SQL
Server
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez d’établir une connexion
chiffrée à SQL Server.
Symptômes
Lorsque vous vous connectez SQL Server, vous pouvez recevoir le message d’erreur suivant :
Une connexion a été établie avec succès avec le serveur, mais une erreur s’est produite lors du processus de
connexion. (fournisseur : fournisseur SSL, erreur : 0 - La chaîne de certificats a été émise par une autorité qui
n’est pas fiable.) (.Net SqlClient Fournisseur de données)
En outre, le message d’erreur suivant est consigné dans le journal des Windows système
Log Name: System

Source: Schannel
Date: 10/13/2020 3:03:31 PM
Event ID: 36882
Task Category: None
Level: Error
Keywords:
User: USERNAME
Computer: COMPUTERNAME
Description:
The certificate received from the remote server was issued by an untrusted certificate authority. Because of
this, none of the data contained in the certificate can be validated. The TLS connection request has failed.
The attached data contains the server certificate.
Cause
Cette erreur se produit lorsque vous essayez d’établir une connexion chiffrée à SQL Server à l’aide d’un certificat
non vérifiable. Cela peut se produire dans les scénarios suivants :
A UTO RIT É
ÉM ET T RIC E DE
C ERT IF IC AT
P RÉSEN T E DA N S L E
M A GA SIN
A UTO RIT ÉS DE
C ERT IF IC AT IO N
C H IF F REM EN T C ÔT É C H IF F REM EN T C ÔT É RA C IN ES DE
SC ÉN A RIO SERVEUR C L IEN T T Y P E DE C ERT IF IC AT C O N F IA N C E
A UTO RIT É
ÉM ET T RIC E DE
C ERT IF IC AT
P RÉSEN T E DA N S L E
M A GA SIN
A UTO RIT ÉS DE
C ERT IF IC AT IO N
C H IF F REM EN T C ÔT É C H IF F REM EN T C ÔT É RA C IN ES DE
SC ÉN A RIO SERVEUR C L IEN T T Y P E DE C ERT IF IC AT C O N F IA N C E
1 Oui Non Vous devez mettre Non

en service un
certificat à partir
d’une source non
fiable (l’autorité
émettrice du
certificat n’est pas
répertoriée en tant
qu’autorité de
confiance dans
autorités de
certification racines
de confiance sur
l’ordinateur client)
2 Désactivé Oui SQL Server certificat Les certificats auto-

auto-généré signés ne s’affiche
pas dans ce magasin.
Lors de l’établissement de connexions chiffrées à SQL Server, le canal sécurisé (Schannel) crée la liste des
autorités de certification de confiance en recherchant le magasin Autorités de certification racines de confiance
sur l’ordinateur local. Pendant la mise en relation TLS, le serveur envoie son certificat de clé publique au client.
L’émetteur d’un certificat de clé publique est appelé autorité de certification. Le client doit s’assurer que
l’autorité de certification est une autorité de certification en qui le client a confiance. Pour ce faire, vous
connaîtrez à l’avance la clé publique des CAs de confiance. Lorsque Schannel détecte un certificat émis par une
autorité de certification non habilitée, comme dans les deux cas ci-dessus, vous obtenez le message d’erreur
répertorié dans la section Symptômes.
Résolution
Si vous utilisez intentionnellement un certificat provenant d’une autorité non fiable ou un certificat auto-signé
pour chiffrer les connexions à SQL Server, vous pouvez utiliser l’une des options suivantes :
Pour le scénario 1 : ajoutez l’autorité de certification au magasin Autorités de certification racines de confiance
sur l’ordinateur client qui lance une connexion chiffrée. Pour ce faire, complétez le certificat de serveur et
installez l’autorité de certification racine sur les procédures de l’ordinateur client répertoriées ci-dessous dans
cette séquence.
Exporte le certificat de serveur.
L’exemple utilise un fichier nommé caCert.cer comme fichier de certificat. Vous devez obtenir ce fichier de
certificat à partir du serveur. Les étapes suivantes expliquent comment exporter le certificat de serveur vers un
fichier :
1. Cliquez sur Démarrer, puis Exécutez, puis tapez MMC. (MMC est un acronyme de Microsoft
Management Console.)
2. Dans MMC, ouvrez les cer tificats.
3. Développez Personnel, puis Cer tificats.
4. Cliquez avec le bouton droit sur le certificat de serveur, puis sélectionnez Toutes les tâches\Expor ter.
5. Cliquez sur Suivant pour aller au-delà de la boîte de dialogue d’accueil de l’Assistant Exportation de
certificat.
6. Confirmez que non, n’expor tez pas la clé privée est sélectionnée, puis cliquez sur Suivant .
7. Assurez-vous que le fichier binaire X.509 codé DER (. CER) ou X.509 codé en base 64 (. CER) est
sélectionné, puis cliquez sur Suivant .
8. Entrez un nom de fichier d’exportation.
9. Cliquez sur Suivant, puis sur Terminer pour exporter le certificat.
Installer l’autorité de certification racine sur l’ordinateur client
1. Démarrez le logiciel en snap-in Certificats pour la MMC sur l’ordinateur client, puis ajoutez le logiciel en
snap-in Certificats.
2. Dans la boîte de dialogue Certificats en ligne, sélectionnez Compte d’ordinateur, puis suivant .
3. Dans le volet Sélectionner un ordinateur, choisissez Ordinateur local : (l’ordinateur sur qui cette console
est en cours d’exécution), puis choisissez Terminer .
4. Choisissez OK pour fermer la boîte de dialogue Ajouter ou supprimer des snap-ins.
5. Dans le volet gauche de la MMC, développez le nœudCer tificats (ordinateur local).
6. Développezle nœud Autorités de certification racines de confiance, cliquez avec le bouton droit sur le
sous-foldeur Certificats, sélectionnez Toutes les tâches, puis sélectionnezImpor ter.
7. Dans l’Assistant Impor tation de certificat, sur la page d’accueil, choisissez Suivant .
8. On the File to Import page, chooseBrowse .
9. Accédez à l’emplacement du fichier de certificat caCert.cer, sélectionnez le fichier, puis choisissezOuvrir .
10. Dans la page Fichier à importer, choisissezSuivant .
11. Dans la page Magasin de certificats, acceptez la sélection par défaut, puis choisissezSuivant .
12. On the Completing the Cer tificate Impor t Wizard page, choose Finish .
Pour les scénarios 1 et 2 : définissez le paramètre Cer tificat de serveur de confiance sur true dans votre
application cliente.
Pour plus d’informations sur la façon de le faire, voir les rubriques suivantes :
Utilisation du chiffrement sans validation dans SQL Server Native Client.
Connexion avec chiffrement à l’aide du pilote JDBC Microsoft pour SQL Server.
Utilisation du chiffrement avec Sqlclient.
NOTE
Si vous utilisez SQL Server Management Studio, vous pouvez cliquer sur l’onglet Options et cocher la case Option de
certificat ser veur de confiance sous l’onglet Propriétés de connexion.
Attention : Les connexions SSL chiffrées à l’aide d’un certificat auto-signé ne fournissent pas une sécurité
renforcée. Elles sont exposées aux man-in-the-middle attaques. Vous ne devez pas vous appuyer sur SSL à l’aide
de certificats auto-signés dans un environnement de production ou sur des serveurs connectés à Internet.
Si la configuration abordée dans les sections précédentes de cet article n’est pas souhaitée, vous pouvez utiliser
l’une des options suivantes pour résoudre ce problème :
Configurer le moteur de base de données pour qu’il utilise le chiffrement selon la procédure dans Activer
les connexions chiffrées au Moteur de base de données
Si le chiffrement n’est pas requis :
Désactivez les paramètres de chiffrement (le cas caser) dans votre application cliente.
Désactivez le chiffrement côté serveur à l’SQL Server Configuration Manager. Pour plus
d’informations sur la façon de faire, voir Configurer le serveur.
Il se peut que vous ne soyez pas en mesure d’établir
une connexion distante SQL Server à partir d’un
déclencheur CLR
Cet article vous aide à résoudre le problème dans lequel vous ne pouvez pas établir de connexion distante SQL
Server à partir d’un déclencheur CLR.
Symptômes
Lorsque vous déployez un déclencheur CLR qui accède aux données à partir d’une SQL Server distante à l’aide
de l’authentification Windows après avoir usurpé l’identité du compte d’utilisateur à l’aide de
WindowsImpersonationContext, vous obtenez le message d’erreur suivant lors de l’exécution du déclencheur.
Msg 6522, Level 16, State 1, Procedure mytrigger, Line 1

Une erreur .NET Framework’est produite lors de l’exécution d’une routine définie par l’utilisateur ou d’une
erreur « mytrigger » agrégée :
System.InvalidOperationException : l’accès aux données n’est pas autorisé dans ce contexte. Le contexte est
une fonction ou une méthode non marquée avec DataAccessKind.Read ou SystemDataAccessKind.Read, est
un rappel pour obtenir des données à partir de la méthode FillRow d’une fonction table valeur, ou est une
méthode de validation UDT.
System.InvalidOperationException :
at System.Data.SqlServer.Internal.ClrLevelContext.CheckSqlAccessReturnCode(SqlAccessApiReturnCode eRc)
at System.Data.SqlServer.Internal.ClrLevelContext.GetCurrentContext(SmiEventSink sink, Boolean
throwIfNotASqlClrThread, Boolean fAllowImpersonation)
at System.Data.SqlServer.Internal.ClrLevelContext.GetCurrentContext(Boolean throwIfNotASqlClrThread,
Boolean fAllowImpersonation)
at System.Data.SqlServer.Internal.ClrLevelContext.SuperiorTransaction.Promote()
at System.Transactions.TransactionStatePSPEOperation.PSPEPromote(InternalTransaction tx)
at System.Transactions.TransactionStateDelegatedBase.EnterState(InternalTransaction tx)
at System.Transactions.EnlistableStates.Promote(InternalTransaction tx)
at System.Transactions.Transaction.Promote()
at System.Transactions.TransactionInterop.ConvertToOletxTransaction(Transaction transaction)
at System.Transactions.TransactionInterop.GetExportCookie(Transaction transaction, Byte[] whereabouts)
at System.Data.SqlClient.SqlInternalConnection.GetTransactionCookie(Transaction transaction, Byte[]
whereAbouts)
at System.Data.SqlClient.SqlInternalConnection.EnlistNonNull(Transaction tx)
at System.Data.SqlClient.SqlInternalConnection.Enlist(Transaction tx)
at System.Data.SqlClient.SqlInternalConnectionTds.Activate(Transaction transaction)
at System.Data.ProviderBase.DbConnectionInternal.ActivateConnection(Transaction transaction)
at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConn...
L’instruction a été terminée.
Cause
Ce comportement est inhérent au produit. Le code CLR qui s’exécute SQL Server est toujours appelé dans le
contexte du compte de processus. Lorsqu’un déclencheur CLR qui contient du code pour accéder aux données à
partir d’un serveur SQL distant est exécuté, le serveur SQL promeut automatiquement la transaction DML/DDL
vers une transaction distribuée et se connecte au serveur distant à l’aide de l’identité SQL Server. Dans le cas où
WindowsImpersonationContext est utilisé pour usurper l’identité de l’utilisateur appelant, pour les connexions
au serveur SQL distant, la promotion de la transaction de contexte vers une transaction de distribution échoue,
ce qui entraîne l’erreur mentionnée dans la section symptômes.
Résolution
Si vous avez besoin de la fonctionnalité d’emprunt d’identité de l’appelant à l’intérieur d’un déclencheur CLR
SQL, gérez les transactions explicitement dans votre code. Utilisez la méthode pour supprimer l’SQL gestion des
transactions et gérer la transaction distante avec validation ou rollback en conformité
TransactionScopeOption.Supress avec vos besoins. Reportez-vous à la section Étapes à reproduire ci-dessous
pour obtenir un exemple sur la façon de reproduire ce problème et pour obtenir un exemple sur l’utilisation de
la méthode ci-dessus pour résoudre le problème.
Ouvrez SQL Server Management Studio, puis connectez-vous à votre instance de SQL Server 2008.
Créez une base de données de test à l’aide du script suivant.
CREATE DATABASE dbTriggerTest

GO
ALTER DATABASE dbTriggerTest SET TRUSTWORTHY ON
GO
USE dbTriggertest
GO
CREATE TABLE t(c1 int)
GO
sp_configure 'clr enabled', 1

GO
reconfigure
GO
Dans Microsoft Visual Studio 2008, créez un projet Visual C# à l’aide SQL Server Project modèle.
Nommez le projet SQLCLRTriggerProject.
Dans le menu Project, sélectionnez Propriétés SQLCLRTriggerProject et configurez la section Base de
données pour qu’elle pointe vers la base de données créée précédemment dans la procédure
(dbTriggerTest) et définissez le niveau d’autorisation sur Externe.
Dans le menu Project, sélectionnez Ajouter un nouvel élément.
Sélectionnez Déclencheur dans la boîte de dialogue Ajouter un nouvel élément.
Tapez un nom pour le nouveau déclencheur.
Remplacez le code du déclencheur nouvellement créé par l’exemple de code suivant.
Liste de code problématique:
using System;
using System.Data;
using System.Data.SqlClient;
using Microsoft.SqlServer.Server;
using System.Security.Principal;
public partial class Triggers

{
[Microsoft.SqlServer.Server.SqlTrigger(Name = "mytrigger", Target = "t", Event = "FOR insert")]
public static void mytrigger()
{
WindowsIdentity clientId = null;
WindowsImpersonationContext impersonatedUser = null;
// Get the client ID.

clientId = SqlContext.WindowsIdentity;
// This outer try block is used to thwart exception filter

// attacks which would prevent the inner finally
// block from executing and resetting the impersonation
try
{
try
{
impersonatedUser = clientId.Impersonate();
if (impersonatedUser != null)
{
SqlConnection conn = new SqlConnection(@"Data Source=<Your server name>;Initial
Catalog=master;Integrated Security=SSPI");
conn.Open();
SqlCommand cmd = conn.CreateCommand();
cmd.CommandText = "select * from sys.sysobjects";
cmd.CommandType = CommandType.Text;
cmd.ExecuteNonQuery();
}
}
finally
{
// Undo impersonation.
impersonatedUser.Undo();
}
}
catch
{
throw;
}
}
}
Déployez le projet dans la base de données créée à l’étape 2 à l’aide de l’option Déployer Project SQLCLR
dans le menu Build.
Ouvrez SQL Server Management Studio, puis connectez-vous à l’instance de SQL Server 2008 où le
déclencheur est déployé.
Vous devriez voir les deux éléments suivants créés sous la base de données de dbTriggerTest test.
Déclencheurs - mytrigger
Assemblys - SQLCLRTriggerProject
Vérifiez que l’autorisation définie sur l’assembly est définie sur Accès externe à l’aide du volet de
propriétés de SQLCLRTriggerProject l’assembly dans Management Studio.
Exécutez l’instruction suivante pour reproduire le problème.
insert into t values (1)
Remplacez la liste de code problématique par l’exemple de code suivant pour résoudre le problème.
Liste de codes fixes :
using System;
using System.Data;
using Microsoft.SqlServer.Server;
using System.Security.Principal;
using System.Transactions;
public partial class Triggers

{
[Microsoft.SqlServer.Server.SqlTrigger(Name = "mytrigger", Target = "t", Event = "FOR insert")]
public static void mytrigger()
{
using (new TransactionScope(TransactionScopeOption.Suppress))
{
WindowsIdentity clientId = null;
WindowsImpersonationContext impersonatedUser = null;
// Get the client ID.
clientId = SqlContext.WindowsIdentity;
// This outer try block is used to thwart exception filter
// attacks which would prevent the inner finally
// block from executing and resetting the impersonation
try
{
SqlTransaction tran = null;
try
{
impersonatedUser = clientId.Impersonate();
{
SqlConnection conn = new SqlConnection(@"Data Source=<Your server
name>;Initial Catalog=master;Integrated Security=SSPI");
conn.Open();
tran = conn.BeginTransaction();
SqlCommand cmd = conn.CreateCommand();
cmd.Transaction = tran;
cmd.CommandText = "select * from sys.sysobjects";
cmd.CommandType = CommandType.Text;
cmd.ExecuteNonQuery();
tran.Commit();
}
}
catch (Exception ex)
{
if (null != tran)
tran.Rollback();
throw ex;
}
finally
{
// Undo impersonation.
impersonatedUser.Undo();
}
}
catch
{
throw;
}
}
}
}
INSERT EXEC a échoué car la procédure stockée a
modifié le schéma de l’erreur de table cible SQL
Server 2016
Cet article vous aide à contourner le problème où une procédure stockée dans une base de données qui utilise
la fonctionnalité Magasin de données de requête échoue régulièrement.
Symptômes
Vous disposez d Microsoft SQL Server base de données 2016 qui utilise la fonctionnalité magasin de
données de requête.
Vous avez une procédure stockée qui effectue un appel à une autre procédure stockée à l’aideINSERT...EXE
syntaxe C.
Le magasin de données de requête exécute régulièrement un nettoyage automatique à mesure que la taille
augmente jusqu’à sa taille maximale configurée et que le magasin de données de requête change
fromREAD_WRITEtoREAD_ONLY d’état.
Dans ce scénario, l’exécution de procédure stockée parente échoue régulièrement et vous recevez un message
d’erreur semblable à ce qui suit :

INSERT EXEC a échoué car la procédure stockée a modifié le schéma de la table cible.
Cause
Lorsque le magasin de données de requête exécute un nettoyage automatique, ce purge est prévu hors du
magasin de données de requête. La requête rencontre une opération de recompilage, car le plan est absent du
magasin de données de requête, mais le plan est toujours présent dans le cache des procédures. Par conception,
lorsque l’opération de recompiler se produit, SQL Server envoie l’erreur 556 pour empêcher l’exécution en
double de la procédure enfant, ce qui entraînerait le retour de résultats incorrects.
Pour contourner ce problème, suivez les étapes suivantes :
1. Augmentez la taille du magasin de données de requête. Cela permet de réduire la fréquence ou la probabilité
que le magasin de données de requête efface le plan et entre en READ_ONLY mode d’exploitation.
2. Ajoutez la gestion des erreurs à votre code pour capturer l’erreur 556, puis resoumettre INSERT EXEC la
requête.
3. Effacer le cache de procédure lorsque le magasin de données de requête revient à READ_WRITE l’état à partir
READ_ONLY de .
En raison des modifications apportées au magasin de données de requête en Microsoft SQL Server 2017, ce
problème ne se produit pas SQL Server 2017. This issue won’t be fixed in SQL Server 2016.
L’exécution SQL Server CLR échoue avec
TypeInitializationException
Cet article vous aide à contourner le problème où l’exécution d’objets CLR SQL Server échoue et renvoie une
exception System.TypeInitializationException.
Symptômes
IMPORTANT
Cet article contient des informations qui vous montrent comment réduire les paramètres de sécurité ou désactiver les
fonctionnalités de sécurité sur un ordinateur. Vous pouvez apporter ces modifications pour contourner un problème
spécifique. Avant d’apporter ces modifications, nous vous recommandons d’évaluer les risques associés à l’implémentation
de cette solution de contournement dans votre environnement particulier. Si vous implémentez cette solution de
contournement, prenez les mesures supplémentaires appropriées pour protéger l’ordinateur.
Après avoir installé une mise à jour .NET Framework applicable pour corriger une vulnérabilité décrite dans
CVE-2020-1147,l’exécution d’objets de base de données de création avec l’intégration CLR (Common Language
Runtime) qui lisent le XML dans des objets d’aide à la sécurité DataSet et DataTable échoue. Cela se produit en
raison d’une exception System.TypeInitializationException qui a une exception FileNotFoundException
imbrique. Ce problème indique que l’assembly System.Drawing n’a pas pu être chargé.
Pour référence, voir l’exemple suivant :
Msg 6522, Level 16, State 1, Procedure [your CLR object], Line 0 [Batch Start Line 0] A .NET Framework error
occurred during execution of user-defined routine or aggregate « your CLR object »:
System.TypeInitializationException : l’initialiseur de type pour « Scope » a lancé une exception. --->
System.IO.FileNotFoundException: Could not load file or assembly 'System.Drawing, Version=4.0.0.0,
Culture=neutral, PublicKeyToken= <Token> ' or one of its dependencies. Le fichier spécifié est introuvable.
System.TypeInitializationException :
at System.Data.TypeLimiter.Scope.IsTypeUnconditionallyAllowed(Type type)
at System.Data.TypeLimiter.Scope.IsAllowedType(Type type)
at System.Data.TypeLimiter.EnsureTypeIsAllowed(Type, TypeLimiter capturedLimiter) at
System.Data.DataColumn.UpdateColumnType(Type type, StorageType typeCode)
chez System.Data.DataColumn.. ctor(String columnName, Type dataType, String expr, MappingType type)
at System.Data.XSDSchema.HandleElementColumn(XmlSchemaElement elem, DataTable table, Boolean
isBase)
at System.Data.XSDSchema.HandleParticle(XmlSchemaParticle pt, DataTable table, ArrayList tableChildren,
Boolean isBase)
at System.Data.XSDSchema.HandleComplexType(XmlSchemaComplexType ct, DataTable table, ArrayList
tableChildren, Boolean isNillable)
at System.Data.XSDSchema.InstantiateTable(XmlSchemaElement node, XmlSchemaComplexType typeNode,
Boolean isRef)
at System.Data.XSDSchema.HandleTable(XmlSchemaElement node)
at System.Data.XSDSchema.HandleParticle(XmlSchemaParticle pt, DataTable table, ArrayList tableChildren,
Boolean isBase)
at System.Data.XSDSchema.HandleComplexType(XmlSchemaComplexType ct, DataTable table, ArrayList
tableChildren, Boolean isNillable)
at System.Data.XSDSchema.InstantiateTable(XmlSchemaElement node, XmlSchemaComplexType typeNode,
Boolean isRef)
at System.Data.XSDSchema.HandleTable(XmlSchemaElement node)
at System.Data.XSDSchema.LoadSchema(XmlSchemaSet schemaSet, DataSet ds)
at System.Data.DataSet.InferSchema(XmlDocument xdoc, String[] excludedNamespaces, XmlReadMode
mode)
at System.Data.Data...
Résolution
This issue has been fixed in the October 13, 2020 republishing of the .NET Framework July 2020 Security-Only
Updates.
Pour plus d’informations, notamment sur la façon d’obtenir le correctif, voir .NET Framework republishing of
July 2020 Security Only Updates.
WARNING
Cette solution de contournement peut rendre un ordinateur ou un réseau plus vulnérable aux attaques par des
utilisateurs malveillants ou par des logiciels malveillants tels que des virus. Nous ne recommandons pas cette solution de
contournement, mais fournissons ces informations afin que vous pouvez implémenter cette solution de contournement à
votre propre discrétion. Son utilisation relève de votre responsabilité.
Pour les applications qui désérialisent des données XML nontrues dans une instance de l’un ou l’autre des
objets, nous vous recommandons d’utiliser une autre méthode pour accéder DataSet DataTable aux données.
Pour les applications qui lisent uniquement des données XML fiables, vous pouvez essayer l’une des solutions
de contournement suivantes.
NOTE
Les solutions de contournement 1 et 2 sont privilégiées, car les modifications sont apportées localement. La solution de
contournement 3 est à l’échelle du système.
WARNING
Ces solutions de contournement suppriment les restrictions de type pour désérialiser le XML en instances et DataSet
DataTable objets. Cela peut ouvrir un vide de sécurité si l’application lit des entrées non confiance.
Solution de contournement 1 : Appeler AppContext.SetSwitch

Modifiez le début du code SQL clr pour définir leSwitch.System. Commutateur
Data.AllowArbitrar yDataSetTypeInstantiation sur true . Vous devez le faire pour chaque objet CLR
SQL applicable. Voir l’exemple ci-dessous.
Pour plus d’informations, consultez les conseils de sécurité DataSet et DataTable.
Solution de contournement 2 : créer ou modifier le fichierSqlservr.exe.config pour chaque instance
applicable
Cette solution de contournement s’applique uniquement à l’instance elle-même.
IMPORTANT
Nous ne pouvons pas garantir que cette modification ne sera pas écrasée par SQL Server mises à jour ou mises à
niveau d’instances. Nous vous recommandons de déterminer si la modification persiste après une mise à jour ou
une mise à niveau d’instance.
1. Recherchez leSqlservr.exe.config dans les emplacements de fichiers des instances par défaut et
nommées de SQL Server:
%ProgramFiles%\Microsoft SQL Server\<Instance_ID>.<Instance Name>\MSSQL\Binn\
2. Dans le nœud, mais en dehors des nœuds <runtime> imbrmbrés, ajoutez la ligne suivante :
<AppContextSwitchOverrides value="Switch.System.Data.
AllowArbitraryDataSetTypeInstantiation=true"/>
3. Enregistrez le fichier et redémarrez l’instance.

Consultez l’exemple suivant d’une instance SQL Server 2016.
Solution de contournement 3 : créer l’assembly System.Drawing

Créez manuellement l’assembly System.Drawing dans SQL Server à partir du fichier DLL du Global
Assembly Cache (GAC), puis re-créez des assemblys qui utilisent DataSet.ReadXML ou
DataTable.ReadXML. Par exemple :
CREATE ASSEMBLY [Drawing] FROM

'C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Drawing\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Draw
ing.dll' WITH PERMISSION_SET = UNSAFE GO
Solution de contournement 4 : créer une sous-clé de Registre

IMPORTANT
Suivez attentivement les étapes de cette solution de contournement. Des problèmes graves peuvent se produire si
vous modifiez le Registre de façon incorrecte. Avant de modifier le Registre, sauvegardez-le pour restauration en
cas de problèmes.
Cette solution de contournement affecte toutes les applications .NET sur le serveur. Par conséquent, vous
ne devez utiliser cette méthode qu’en dernier recours si vous ne pouvez pas utiliser les autres solutions
de contournement.
1. Ouvrez l’Éditeur du Registre.
2. Recherchez la sous-clé suivante :
KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext
3. Créez une REG_SZ, comme suit.
SW ITC H . SY ST EM .
DATA . A L LO WA RB IT RA RY DATA SET T Y P EIN STA N T IAT IO
NOM N
Valeur true
4. Redémarrez toutes SQL Server instances.

Voir l’exemple ci-dessous.
Ce problème est dû à l’action d’une mise à jour de sécurité .NET Framework récente pour corriger la validation
du .NET Framework de contenu XML. SQL Server Les objets CLR qui ne lisent pas le XML dans les instances de
l’un ou l’autre des objets DataSet DataTable ne seront pas affectés.
Un index filtré que vous créez avec le prédicat IS
NULL n’est pas utilisé dans SQL Server
Cet article vous aide à résoudre le problème qui se produit lorsque vous créez l’index avec l’expression de
prédicat Column IS NULL dans SQL Server.
Symptômes
Vous créez un index filtré avec l’expression de prédicat Column IS NULL dans SQL Server.
Le champ Colonne n’est pas inclus dans la structure d’index. (Autrement dit, le champ Colonne n’est pas
une clé ou une colonne incluse dans la définition d’index filtrée.)
Par exemple, vous créez la requête suivante :
CREATE UNIQUE CLUSTERED INDEX i_action_rn on dbo.filter_test (rn)

CREATE NONCLUSTERED INDEX i_action_filt_action_date_type ON dbo.filter_test (action_type)
WHERE action_date IS NULL
NOTE
Cette requête n’utilise pas l’index filtré suivant :
select count(*) from dbo.filter_test where action_date is null and action_type=1
Dans ce scénario, l’index filtré n’est pas utilisé. Au lieu de cela, l’index en cluster est utilisé.
Résolution
Pour résoudre ce problème, incluez la colonne testée comme NULL dans les colonnes renvoyées. Vous pouvez
également ajouter cette colonne en tant qu’inclure des colonnes dans l’index.
CREATE NONCLUSTERED INDEX New_i_action_filt_action_date_type ON dbo.filter_test (action_type) include

(action_date) WHERE action_date IS NULL
Créer des index filtrés
Index clustered et nonclustered décrits
SQL Server et Azure SQL Database’amélioration de
la gestion de certains types de données et des
opérations peu courantes
Cet article explique comment les structures persistantes dans votre base de données SQL Server peuvent être
validées dans le cadre du niveau de compatibilité de mise à niveau, et comment les structures affectées peuvent
être reconstruites après la mise à niveau du niveau de compatibilité.
Le moteur de base de données Microsoft SQL Server 2016 et Azure SQL Database comprend des améliorations
dans les conversions de types de données et plusieurs autres opérations. La plupart de ces améliorations offrent
une plus grande précision lorsque vous travaillez avec des types à pointe flottante et avec des types date/heure
classiques.
Ces améliorations sont toutes disponibles lorsque vous utilisez un niveau de compatibilité de base de données
d’au moins 130. Cela signifie que pour certaines expressions (pour la plupart rares), vous pouvez voir des
résultats différents pour certaines valeurs d’entrée après avoir mis à niveau la base de données vers le niveau de
compatibilité 130 ou un paramètre supérieur. Ces résultats peuvent être reflétés dans :
structures persistantes dans la base de données ;
données de table incluses soumises aux contraintes CHECK
colonnes calculées persistantes
index de référencement de colonnes calculées
index filtrés et vues indexées.
Si vous avez une base de données créée dans une version antérieure de SQL Server, nous vous recommandons
d’une validation supplémentaire après la mise à niveau vers SQL Server 2016 ou version ultérieure et avant de
modifier le niveau de compatibilité de la base de données.
Si vous constatez que l’une des structures persistantes de votre base de données est affectée par ces
modifications, nous vous recommandons de reconstruire les structures affectées après avoir mis à niveau le
niveau de compatibilité de la base de données. En faisant cela, vous bénéficierez de ces améliorations dans SQL
Server 2016 ou ultérieure.
Cet article explique comment les structures persistantes dans votre base de données peuvent être validées dans
le cadre de la mise à niveau vers le niveau de compatibilité 130 ou un paramètre supérieur, et comment les
structures affectées peuvent être reconstruites après avoir changé le niveau de compatibilité.
Étapes de validation lors d’une mise à niveau vers un niveau de

compatibilité de base de données
À compter SQL Server 2016, les deux SQL Server et Azure SQL Database des améliorations apportées à la
précision des opérations suivantes :
Conversions de types de données rares. Elles incluent notamment les éléments suivants :
Float/integer to/from datetime/smalldatetime
Real/float to/from numeric/money/smallmoney
Float to Real
Certains cas de DATEPART / DATEDIFF et DEGRÉS
CONVERT qui utilise un style NULL
Pour utiliser ces améliorations de l’évaluation des expressions dans votre application, modifiez le niveau de
compatibilité de vos bases de données sur 130 (pour SQL Server 2016) ou 140 (pour SQL Server 2017 et Azure
SQL Database). Pour plus d’informations sur toutes les modifications et quelques exemples qui montrent les
modifications, voir la section Annexe A.
Les structures suivantes dans la base de données peuvent persister les résultats d’une expression :
Données de tableau soumises aux contraintes CHECK
Colonnes calculées persistantes
Index qui utilisent des colonnes calculées dans la clé ou des colonnes incluses
Index filtrés
Vues indexées
Vous avez une base de données qui a été créée par une version antérieure de SQL Server, ou qui a déjà
été créée dans SQL Server 2016 ou une version ultérieure, mais à un niveau de compatibilité 120 ou un
niveau antérieure.
Vous utilisez toutes les expressions dont la précision a été améliorée dans le cadre de la définition des
structures persistantes dans votre base de données.
Dans ce scénario, vous pouvez avoir des structures persistantes affectées par les améliorations de précision
implémentées à l’aide du niveau de compatibilité 130 ou supérieur. Si tel est le cas, nous vous recommandons
de valider les structures persistantes et de reconstruire toute structure affectée.
Si vous avez affecté des structures et que vous ne les ressaisisez pas après avoir changé le niveau de
compatibilité, vous pouvez obtenir des résultats de requête légèrement différents. Les résultats dépendent de
l’utilisation d’un index, d’une colonne calculée ou d’un affichage particulier et de la violation d’une contrainte
par les données d’une table.
NOTE
Indicateur de suivi 139 dans SQL Server
L’indicateur de suivi global 139 est introduit dans SQL Server 2016 CU3 et Service Pack (SP) 1 pour forcer une
sémantique de conversion correcte dans l’étendue des commandes de vérification DBCC telles que **DBCC
CHECKDB,**DBCC CHECKTABLE et DBCC CHECKCONSTRAINTS lorsque vous analysez la logique de conversion et de
précision améliorée introduite avec le niveau de compatibilité 130 sur une base de données ayant un niveau de
compatibilité précédent.
WARNING
L’indicateur de suivi 139 n’est pas destiné à être activé en continu dans un environnement de production et doit être
utilisé dans le seul but d’effectuer les vérifications de validation de base de données décrites dans cet article. Par
conséquent, il doit être désactivé à l’aide du suivi dbcc (139, -1) dans la même session, une fois les vérifications de
validation terminées.
L’indicateur de suivi 139 est pris en charge à SQL Server 2016 CU3 et SQL Server 2016 SP1.
Pour mettre à niveau le niveau de compatibilité, suivez les étapes suivantes :
1. Effectuez la validation pour identifier les structures persistantes affectées :
a. Activez l’indicateur de suivi 139 en exécutant DBCC TRACEON(139, -1).
b. Exécutez les commandes DBCC CHECKDB/TABLE et CHECKCONSTRAINTS.
c. Désactivez l’indicateur de suivi 139 en exécutant DBCC TRACEOFF(139, -1).
2. Modifiez le niveau de compatibilité des bases de données sur 130 (pour SQL Server 2016) ou 140 (pour SQL
Server 2017 et Azure SQL Database).
3. Reconstruire toutes les structures que vous avez identifiées à l’étape 1.
NOTE
Les indicateurs de suivi Azure SQL Database les indicateurs de suivi de paramètres ne sont pas pris en charge dans Azure
SQL Database. Par conséquent, vous devez modifier le niveau de compatibilité avant d’effectuer la validation :
1. Mettre à niveau le niveau de compatibilité des bases de données vers 140.

2. Faites une validation pour identifier les structures persistantes impactées.
3. Reconstruire les structures que vous avez identifiées à l’étape 2.
L’Annexe A contient une liste détaillée de toutes les améliorations apportées à la précision et fournit un
exemple pour chacune d’elles.
L’annexe B contient un processus détaillé pas à pas pour valider et reconstruire les structures affectées.
Les annexes C et D contiennent des scripts pour aider à identifier les objets potentiellement affectés
dans la base de données. Par conséquent, vous pouvez étendue vos validations et générer des scripts
correspondants pour exécuter les vérifications. Pour déterminer plus facilement si des structures
persistantes dans vos bases de données sont affectées par les améliorations de précision apportées au
niveau de compatibilité 130, exécutez le script de l’Annexe D afin de générer les vérifications de validation
correctes, puis exécutez ce script pour la validation.
Annexe A : Modifications du niveau de compatibilité 130

Cette annexe fournit des listes détaillées des améliorations apportées à l’évaluation des expressions dans le
niveau de compatibilité 130. Chaque modification inclut un exemple de requête associé. Les requêtes peuvent
être utilisées pour afficher les différences entre l’exécution dans une base de données qui utilise un niveau de
compatibilité pré-130 par rapport à une base de données qui utilise le niveau de compatibilité 130.
Les tableaux suivants indiquent les conversions de types de données et les opérations supplémentaires.
Conversions de types de données
RÉSULTAT P O UR RÉSULTAT P O UR
L E N IVEA U DE L E N IVEA U DE
EXEM P L E DE C O M PAT IB IL IT É C O M PAT IB IL IT É
DE À REM P L A C EZ REQ UÊT E < 130 = 130
float, real, datetime ou Augmentez la DECLARE @f 1.19999996141 1.2

numeric, decimal, smalldatetime précision de FLOAT = 1.2 975
money ou l’arrondi. DECLARE @d
smallmoney Auparavant, le DATETIME = @f
jour et l’heure SELECT CAST(
étaient convertis @d AS FLOAT)
séparément et
les résultats
étaient tronqués
avant de les
combiner.
DateHeure bigint, int ou Une date/heure DECLARE @h 0 -1

smallint négative dont la DATETIME = -
partie heure est 0,5 SELECT @h ,
exactement une CAST( AS @h
demi-journée ou INT)
une coche d’une
demi-journée est
arrondie de
manière
incorrecte (le
résultat est 1).
datetime ou float, real, Précision DECLARE @p0 - -

smalldatetime numeric, money améliorée pour DATETIME = 0,00138344907 0,00138344907
ou smallmoney les 8 derniers '1899-12-31 407406, 407407,
bits de précision 23:58:00.470' 0xBF56AA9B21D 0xBF56AA9B21D
dans certains DECLARE @f 85800 8583B
cas. FLOAT =
CONVERT(FLOAT
, @p0 ) SELECT
@f , CAST( @f AS
VARBINARY(8))
float real Les contrôles de SELECT CAST Dépassement 3,402823E+38

limite sont moins (3,40282347000 arithmétique
stricts. E+038 AS REAL)
numeric, money float Lorsque l’échelle DECLARE @n 0x47200000000 0x47200000000

et smallmoney d’entrée est zéro, NUMERIC(38, 00000 00001
il existe une 0)=
imprécision 4153837486827
arrondie lorsque 8625639929991
vous combinez 208632320
les quatre DECLARE @f
parties FLOAT = CAST(
numériques. AS @n FLOAT)
SELECT
CONVERT(BINAR
Y(8), @f )
numeric, money float Lorsque l’échelle DECLARE @n 0x41678C29C06 0x41678C29C06

et smallmoney d’entrée n’est NUMERIC(18, 522C4 522C3
pas zéro, il y a 10) =
une imprécision 12345678.0123
arrondie lorsque 456781
vous divisez par DECLARE @f
10^échelle. FLOAT = CAST(
@n AS FLOAT)
SELECT CAST( @f
AS BINARY(8))
réel ou flottant numeric Précision DECLARE @f 0.2 0.1

d’arrondi float =
améliorée dans 0,14999999999
certains cas. 9999999 SELECT
CAST( @f AS
numeric(1, 1))
réel ou flottant numeric Précision DECLARE @v 0.00000000000 0.00000000000

améliorée decimal(38, 18) 0000000 0000001
lorsque vous = 1E-18 SELECT
arrondissez à @v
plus de 16
chiffres dans
certains cas.
réel ou flottant money ou Amélioration de DECLARE @f 5629499534213 5629499534213

smallmoney la précision float = 2SET @f 12.2048 12.25
lorsque vous = POWER( , @f
convertissez de 49) + POWER(
grands nombres @f , -2) SELECT
dans certains CAST( @f AS
cas. money)
(n) (var)char numeric Une entrée de DECLARE Dépassement 1.1

plus de 39 @value arithmétique
caractères ne nchar(100) =
déclenche plus '1.11111111111
nécessairement 1111111111111
un dépassement 1111111111111
arithmétique. 1111111'
SELECT CAST(
@value AS
decimal(2,1))
(n) (var)char bit Prend en charge DECLARE La conversion a 1

les espaces et les @value échoué lors de la
signes de tête. nvarchar(100) = conversion de la
'1' SELECT CAST( valeur nvarchar «
@value AS bit) 1 » en bits de
type de données.
DateHeure heure ou Précision DECLARE 00:00:00.003000 00:00:00.003333

datetime2 améliorée @value datetime 0 3
lorsque vous = '1900-01-01
convertissez en 00:00:00.003'
types date/heure SELECT CAST(
avec une @value AS
précision plus time(7))
élevée. N’ignorez
pas que les
valeurs de
date/heure sont
stockées en tant
que ticks qui
représentent le
1/300e de
seconde. Les
nouveaux types
d’heure et de
date/heure2
stockent un
nombre discret
de chiffres, où le
nombre de
chiffres
correspond à la
précision.
heure ou DateHeure Arrondi amélioré DECLARE 1900-01-01 1900-01-01

datetime2 dans certains @value time(4) 00:00:00.007 00:00:00.003
cas. =
'00:00:00.0045'
SELECT CAST(
@value AS
datetime)
Opération
RÉSULTAT P O UR L E RÉSULTAT P O UR L E
EXEM P L E DE N IVEA U DE N IVEA U DE
O P ÉRAT IO N REM P L A C EZ REQ UÊT E C O M PAT IB IL IT É <130 C O M PAT IB IL IT É 130
Utilisation de la DEGREES divise par DECLARE @arg1 57.29577951308232 57.29577951308232

fonction intégrée pi/180, où il a été numeric = 1 SELECT 3000 2865
RADIANS ou précédemment DEGREES( @arg1 )
DEGREES qui utilise multiplié par 180/pi.
le type de données Similaire pour
numérique. RADIANS.
Ajout ou soustraction L’arrondi se produit DECLARE @p1 8.8 8.9

numérique lorsque toujours après numeric(38, 2) = -
l’échelle d’un l’ajout/soustraction, 1,15 DECLARE @p2
opérande est alors qu’auparavant il numeric(38, 1) = 10
supérieure à l’échelle pouvait parfois se SELECT @p1 + @p2
du résultat. produire auparavant.
RÉSULTAT P O UR L E RÉSULTAT P O UR L E
EXEM P L E DE N IVEA U DE N IVEA U DE
O P ÉRAT IO N REM P L A C EZ REQ UÊT E C O M PAT IB IL IT É <130 C O M PAT IB IL IT É 130
CONVERT avec le CONVERT avec le SELECT CONVERT 0 NULL

style NULL. style NULL renvoie (SMALLINT, '0',
toujours la valeur NULL) ;
NULL lorsque le type
cible est numérique.
DATEPART qui La valeur n’est plus DECLARE @dt 3000 3333

utilise l’option tronquée au niveau DATETIME = '01-01-
microsecondes ou de la milliseconde 1900 00:00:00.003';
nanosecondes, avec avant la conversion SELECT
le type de données en micro ou DATEPART(MICROSE
date/heure. nanosecondes. COND, @dt );
DATEDIFF qui utilise La valeur n’est plus DECLARE @d1 3000 3333
l’option tronquée au niveau DATETIME = '1900-
microsecondes ou de la milliseconde 01-01 00:00:00.003'
nanosecondes, avec avant la conversion DECLARE @d2
le type de données en micro ou DATETIME = '1900-
date/heure. nanosecondes. 01-01 00:00:00.007'
SELECT
DATEDIFF(MICROSEC
OND, @d1 , @d2 )
Comparaison entre La valeur date/heure DECLARE @d1 1900-01-01 1900-01-01

les valeurs datetime n’est plus tronquée DATETIME = '1900- 00:00:00.0030000, 00:00:00.0033333,
et datetime2 avec au niveau 01-01 00:00:00.003' 1900-01-01 1900-01-01
des valeurs non zéro milliseconde lorsque DECLARE @d2 00:00:00.003 égal 00:00:00.003
pour les vous exécutez une DATETIME2(3) = unequal
millisecondes. comparaison avec @d1 SELECT CAST(
une valeur @d1 AS
datetime2. Cela datetime2(7)),
signifie que certaines @d2SELECT CASE
valeurs WHEN ( @d1 = @d2
précédemment ) THEN 'equal' ELSE
comparées égales ne 'unequal' END
sont plus égales.
Fonction ROUND Les résultats de SELECT -0.418 -0.417

qui utilise le type de l’arrondi diffèrent. ROUND(CAST (-
données float. 0.4175 AS FLOAT), 3)
Annexe B : Étapes de vérification et de mise à jour des structures

persistantes
Nous vous recommandons de déterminer si la base de données possède des structures persistantes affectées
par les modifications apportées au niveau de compatibilité 130 et de reconstruire les structures affectées.
Cela s’applique uniquement aux structures persistantes qui ont été créées dans la base de données sur une
version antérieure de SQL Server ou à l’aide d’un niveau de compatibilité inférieur à 130. Les structures
persistantes qui sont potentiellement affectées sont les suivantes :
Données de tableau soumises aux contraintes CHECK
Index qui utilisent des colonnes calculées dans la clé ou des colonnes incluses
Index filtrés
Vues indexées
Dans ce cas, exécutez la procédure suivante.
Étape 1 : Vérifier le niveau de compatibilité des bases de données
1. Vérifiez le niveau de compatibilité de votre base de données à l’aide de la procédure documentée dans
l’affichage ou modifiez le niveau de compatibilité d’une base de données.
2. Si le niveau de compatibilité de base de données est inférieur à 130, nous vous recommandons d’effectuer la
validation décrite à l’étape 2 avant d’augmenter le niveau de compatibilité à 130.
Étape 2 : Identifier les structures persistantes affectées
Déterminez si la base de données contient des structures persistantes affectées par l’amélioration de la logique
de précision et de conversion dans le niveau de compatibilité 130 de l’une des manières suivantes :
DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS , qui valide toutes les structures dans la base de
données.
DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS , qui valide les structures liées à une seule
table.
L’option WITH EXTENDED_LOGICAL_CHECKS est nécessaire pour s’assurer que les valeurs persistantes sont
comparées aux valeurs calculées et pour indicateurs des cas dans lesquels il existe une différence. Étant donné
que ces vérifications sont étendues, le runtime des instructions DBCC qui utilisent cette option est plus long que
l’exécution des instructions DBCC sans cette option. Par conséquent, pour les bases de données de grande taille,
il est recommandé d’utiliser DBCC CHECKTABLE pour identifier des tables individuelles.
DBCC CHECKCONSTRAINTS peut être utilisé pour valider les contraintes CHECK. Cette instruction peut être
utilisée au niveau de la base de données ou de la table.
Les instructions DBCC CHECK** doivent toujours être exécutés pendant une fenêtre de maintenance, en raison
de l’impact potentiel des vérifications sur la charge de travail en ligne.
Validation au niveau de la base de données La validation au niveau de la base de données convient aux
bases de données de petite taille et de taille moyenne. Utilisez la validation au niveau de la table pour les bases
de données de grande taille.
DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS est utilisé pour valider toutes les structures
persistantes dans la base de données.
DBCC CHECKCONSTRAINTS est utilisé pour valider toutes les contraintes CHECK dans la base de données.
DBCC CHECKCONSTRAINTS est utilisé pour valider l’intégrité des contraintes. Utilisez le script suivant pour
valider la base de données :
USE [database_name]
GO
DBCC TRACEON(139, -1)
GO
DBCC CHECKCONSTRAINTS
GO
DBCC TRACEOFF(139, -1)
GO
L’utilisation de l’indicateur de suivi permet de s’assurer que les vérifications sont effectuées à l’aide de la logique
de précision et de conversion améliorée, qui est dans le niveau de compatibilité 130, forçant la sémantique de
conversion correcte même lorsque le niveau de compatibilité de la base de données est inférieur.
Si l’instruction CHECKCONSTRAINTS est terminée et ne retourne pas de jeu de résultats, aucune action
supplémentaire n’est nécessaire.
Si l’instruction retourne un jeu de résultats, chaque ligne des résultats indique une violation d’une contrainte et
inclut également les valeurs qui enfreignent la contrainte.
Enregistrez les noms des tables et des contraintes, ainsi que les valeurs à l’origine de la violation (colonne «
Where » dans le jeu de résultats).
L’exemple suivant montre un tableau avec une contrainte CHECK et une seule ligne qui satisfait à la contrainte
sous des niveaux de compatibilité inférieurs, mais qui enfreint la contrainte sous le niveau de compatibilité 130.
ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL=120
GO
CREATE TABLE dbo.table1
c2 datetime,
c3 datetime,
c4 int,
CONSTRAINT chk1 CHECK (c4= (DATEDIFF (ms, c2,c3)))
GO
INSERT dbo.table1 (c2, c3, c4) VALUES
(
convert(datetime, '1900-01-01 00:00:00.997'),
convert(datetime, '1900-01-01 00:00:01'), 3

)
GO
GO
GO
GO
La commande CHECKCONSTRAINT renvoie les résultats suivants.

TA B L EA U C O N T RA IN T E OÙ
[dbo]. [tableau1] [chk1] [c2] = '1900-01-01 00:00:00.997'

AND [c3] = '1900-01-01
00:00:01.000' AND [c4] = '3'
Ce résultat indique que la contrainte [chk1] est enfreinte pour la combinaison de valeurs de colonnes dans le «
Where ».
DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS
DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS valide toutes les structures persistantes dans la base
de données. Il s’agit de l’option la plus pratique, car une instruction unique valide toutes les structures de la base
de données. Toutefois, cette option n’est pas adaptée aux bases de données de grande taille en raison de
l’utilisation prévue de l’instruction.
Utilisez le script suivant pour valider la base de données entière :
USE [database_name]
GO
GO
DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS, NO_INFOMSGS, TABLERESULTS
GO
GO
de précision et de conversion améliorée, qui est dans le niveau de compatibilité 130, forçant la sémantique de
conversion correcte même lorsque le niveau de compatibilité de la base de données est inférieur.
Si l’instruction CHECKDB est terminée correctement, aucune action supplémentaire n’est nécessaire.
Si l’instruction est terminée par des erreurs, suivez les étapes suivantes :
1. Enregistrez les résultats de l’exécution de l’instruction DBCC, trouvée dans le volet des messages de SQL
Server Management Studio (SSMS), dans un fichier.
2. Vérifier que l’une des erreurs signalées est liée à des structures persistantes
Tableau 1 : Structures persistantes et messages d’erreur correspondants pour les incohérences
T Y P E DE ST RUC T URE A F F EC T É M ESSA GES D’ERREUR O B SERVÉS P REN EZ N OT E DE
Colonnes calculées persistantes Msg 2537, Level 16 Table error: object ID d'<object_id>'objet et ID d’index
ID <object_id> , index ID <index_id> , <index_id>
. Échec de la vérification
d’enregistrement (colonne calculée
valide). Les valeurs sont .
T Y P E DE ST RUC T URE A F F EC T É M ESSA GES D’ERREUR O B SERVÉS P REN EZ N OT E DE
Index référencing des colonnes Erreur de tableau Msg 8951 : table ID d'<object_id>'objet et ID d’index
calculées dans la clé ou colonnes '<table_name>' (ID <object_id>). La <index_id>
incluses Index filtrés ligne de données n’a pas de ligne
d’index correspondante dans l’index «
<index_name> » (ID <index_id>) Et/ou
erreur de tableau Msg 8952 : table '
<table_name> ' (ID <table_name>). La
ligne d’index dans l’index '' (ID
<index_id>) ne correspond à aucune
ligne de données. En outre, il peut y
avoir des erreurs secondaires 8955
et/ou 8956. Il contient des détails sur
les lignes exactes impactées. Ceux-ci
peuvent être ignorés pour cet exercice.
Vues indexées Msg 8908 La vue indexée « ID d’objet <object_id>

<view_name> » (ID d’objet
<object_id>) ne contient pas toutes les
lignes produites par la définition
d’affichage. And/or Msg 8907 The
indexed view '<view_name>' (object ID
<object_id>) contains rows that were
not produced by the view definition.
Une fois que vous avez terminé la validation au niveau de la base de données, allez à l’étape 3.
Validation au niveau de l’objet
Pour les bases de données plus volumineuses, il est utile de valider les structures et les contraintes d’une table
ou d’une vue à la fois pour réduire la taille des fenêtres de maintenance ou pour limiter les contrôles logiques
étendus uniquement aux objets potentiellement affectés.
Utilisez les requêtes de la section Annexe C pour identifier les tableaux potentiellement affectés. Le script de la
section Annexe D peut être utilisé pour générer des contraintes CHECKTABLE et CHECKCONSTRAINTS
basées sur les requêtes répertoriées dans la section Annexe C.
Pour valider les contraintes liées à une seule table ou vue, utilisez le script suivant :
USE [database_name]
GO
GO
DBCC CHECKCONSTRAINTS()
GO
GO
de précision et de conversion améliorée, qui est dans le niveau de compatibilité 130, forçant la sémantique
améliorée même lorsque le niveau de compatibilité de la base de données est inférieur.
Si l’instruction CHECKCONSTRAINTS est terminée et ne retourne pas de jeu de résultats, aucune action
supplémentaire n’est nécessaire.
Si l’instruction retourne un jeu de résultats, chaque ligne des résultats indique une violation d’une contrainte et
fournit également les valeurs qui enfreignent la contrainte.
Enregistrez les noms des tables et des contraintes, ainsi que les valeurs à l’origine de la violation (colonne
Where dans le jeu de résultats).
DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS
Pour valider les structures persistantes liées à une seule table ou vue, utilisez le script suivant :
USE [database_name]
GO
GO
DBCC CHECKTABLE() WITH EXTENDED_LOGICAL_CHECKS, NO_INFOMSGS, TABLERESULTS
GO
GO
Si l’instruction CHECKTABLE est terminée correctement, aucune action supplémentaire n’est nécessaire.
Si l’instruction est terminée par des erreurs, suivez les étapes suivantes :
1. Enregistrez les résultats de l’exécution de l’instruction DBCC, trouvée dans le volet des messages SSMS, dans
un fichier.
2. Vérifiez que les erreurs signalées sont liées à des structures persistantes, comme indiqué dans le tableau 1.
Une fois que vous avez terminé la validation au niveau du tableau, allez à l’étape 3.
Étape 3 : Mise à niveau vers le niveau de compatibilité 130
Si le niveau de compatibilité de la base de données est déjà de 130, vous pouvez ignorer cette étape.
Le niveau de compatibilité de la base de données peut être modifié en 130 à l’aide du script suivant :
USE [database_name]
GO
GO
NOTE
Étant donné que des modifications sont apportées à l’optimiseur de requête sous le niveau de compatibilité 130, nous
vous recommandons d’activer le magasin de requêtes avant de modifier le niveau de compatibilité. Pour plus
d’informations, voir la section Conserver la stabilité des performances lors de la mise à niveau vers des SQL Server plus
nouvelles dans les scénarios d’utilisation du magasin de requêtes.
Étape 4 : Mettre à jour les structures persistantes
Si aucune incohérence n’a été trouvée lors de la validation effectuée à l’étape 2, vous avez terminé la mise à
niveau et pouvez ignorer cette étape. Si des incohérences ont été trouvées à l’étape 2, des actions
supplémentaires sont requises pour supprimer les incohérences de la base de données. Les actions requises
dépendent du type de structure concerné.
IMPORTANT
Ne faites les actions de réparation de cette étape qu’une fois le niveau de compatibilité de base de données passé à 130.
Back up your database (or databases)

Nous vous recommandons d’effectuer une sauvegarde complète de la base de données avant d’effectuer les
actions que la section suivante décrit. Si vous utilisez Azure SQL Database, vous n’avez pas besoin d’une
sauvegarde vous-même . vous pouvez toujours utiliser la fonctionnalité de restauration à un point dans le
temps pour revenir dans le temps en cas de problème avec l’une des mises à jour.
Contraintes CHECK
La correction des violations de contrainte CHECK nécessite la modification des données de la table ou de la
contrainte CHECK elle-même.
À partir du nom de la contrainte (obtenu à l’étape 2), vous pouvez obtenir la définition de contrainte comme suit
:
SELECT definition FROM sys.check_constraints
WHERE object_id= OBJECT_ID(N'constraint_name')
Pour inspecter les lignes de tableau affectées, vous pouvez utiliser les informations Where précédemment
renvoyées par l’instruction DBCC CHECKCONSTRAINTS :
SELECT *
FROM [schema_name].[table_name]
WHERE Where_clause
Vous devez mettre à jour les lignes affectées ou modifier la définition de contrainte pour vous assurer que la
contrainte n’est pas violée.
Mise à jour des données de table
Il n’existe aucune règle en dur indiquant comment les données doivent être mises à jour. En règle générale, pour
chaque instruction Where différente renvoyée par DBCC CHECKCONSTRAINTS, vous exécutez l’instruction de
mise à jour suivante :
UPDATE [schema_name].[table_name] SET new_column_values
WHERE Where_clause
Prenons l’exemple de tableau suivant avec une contrainte et une ligne qui ne respecte pas la contrainte dans le
niveau de compatibilité 130 :
go
c2 datetime,
c3 datetime,
c4 int,
CONSTRAINT chk1 CHECK (c4= (DATEDIFF (ms, c2, c3)))
GO
INSERT dbo.table1 (c2, c3, c4) VALUES
(convert(datetime, '1900-01-01 00:00:00.997'),
convert(datetime, '1900-01-01 00:00:01'), 3)
GO
Dans cet exemple, la contrainte est simple : la colonne c4 doit être égale à une expression impliquant c2 et c3.
Pour mettre à jour le tableau, affectez cette valeur à c4 :
GO
UPDATE dbo.table1 SET c4 = datediff (ms, c2,c3)
WHERE [c2] = '1900-01-01 00:00:00.997' AND [c3] = '1900-01-01 00:00:01.000' AND [c4] = '3'
GO
Notez que la clause WHERE utilisée dans l’instruction de mise à jour correspond aux informations Where
renvoyées par DBCC CHECKCONSTRAINTS .
Mise à jour de la contrainte CHECK
Pour modifier une contrainte CHECK, vous devez la déposer et la créer à nouveau. Nous vous recommandons
de faire les deux dans la même transaction, juste au cas où il existe des problèmes avec la définition de
contrainte mise à jour. Vous pouvez utiliser le transact-SQL :
BEGIN TRANSACTION
ALTER TABLE [schema_name].[table_name]
DROP CONSTRAINT [constraint_name]
ALTER TABLE [schema_name].[table_name]
ADD CONSTRAINT [constraint_name]
CHECK (new_constraint_definition)
COMMIT
GO
The following example updates the constraint chk1 in dbo.table1:
BEGIN TRANSACTION
ALTER TABLE dbo.table1
DROP CONSTRAINT chk1
ALTER TABLE dbo.table1
ADD CONSTRAINT chk1
CHECK (c4 <= DATEDIFF (ms, c2, c3))
COMMIT
GO

Le moyen le plus simple de mettre à jour les colonnes calculées persistantes consiste à mettre à jour l’une des
colonnes référencés par la colonne calculée. La nouvelle valeur de la colonne peut être identique à l’ancienne, de
telle manière que l’opération ne modifie aucune donnée utilisateur.
Suivez ces étapes pour chaque object_id liées aux incohérences dans les colonnes calculées que vous avez
notées à l’étape 2.
1. Identifiez les colonnes calculées :
Exécutez la requête suivante pour récupérer le nom de la table et les noms des colonnes calculées
persistantes pour les object_id :
SELECT QUOTENAME(s.name) + N'.' + QUOTENAME(t.name) AS 'table',

QUOTENAME(c1.name) AS 'persisted computed column',
c1.column_id AS 'computed_column_id' ,
definition AS 'computed_column_definition'
FROM sys.tables t
JOIN sys.computed_columns c1 ON t.object_id=c1.object_id
AND c1.is_persisted=1
JOIN sys.schemas s on t.schema_id=s.schema_id
WHERE t.object_id=object_id
2. Identifiez les colonnes référencés :

Exécutez la requête suivante pour identifier les colonnes référencés par la colonne calculée. Notez l’une des
referenced_column_names :
SELECT QUOTENAME(s.name) + N'.' + QUOTENAME(o.name) AS 'referencing object',
o.type_desc AS 'object type', referenced_minor_id AS 'referenced_column_id', c.name AS
'referenced_column_name'
FROM sys.sql_expression_dependencies sed
JOIN sys.computed_columns c1 ON sed.referencing_id=c1.object_id AND
sed.referencing_minor_id=c1.column_id
JOIN sys.objects o ON sed.referencing_id=o.object_id
JOIN sys.schemas s ON o.schema_id=s.schema_id
JOIN sys.columns c ON o.object_id=c.object_id AND sed.referenced_minor_id=c.column_id
WHERE referencing_class=1 AND referenced_class=1 AND referencing_id=object_id AND
referencing_minor_id=computed_column_id
3. Exécutez une instruction UPDATE impliquant l’une des colonnes référencés pour déclencher une mise à
jour de la colonne calculée :
L’instruction suivante déclenche une mise à jour de la colonne référencé par la colonne calculée et
déclenche également une mise à jour de la colonne calculée.
UPDATE [schema_name].[table_name]
SET referenced_column_name=ISNULL(referenced_column_name, referenced_column_name)
L’expression ISNULL dans l’instruction est conçue de telle sorte que la valeur de la colonne
d’origine ne soit pas modifiée, tout en s’assure que la colonne calculée est mise à jour à l’aide de la
logique d’évaluation des expressions du niveau de compatibilité DB 130.
Sachez que pour les très grandes tables, vous ne souhaitez peut-être pas mettre à jour toutes les
lignes d’une seule transaction. Dans ce cas, vous pouvez exécuter la mise à jour par lots en
ajoutant une clause WHERE à l’instruction update qui identifie une plage de lignes ; basée sur la clé
primaire, par exemple .
4. Identifiez les index qui font référence à la colonne calculée.
SELECT i.name AS [index name]

FROM sys.index_columns ic JOIN sys.indexes i ON ic.object_id=i.object_id AND ic.index_id=i.index_id
WHERE i.object_id=object_id AND ic.column_id=computed_column_id
Cette requête identifie les index qui font référence à la colonne calculée persistante. Tout index de ce type doit
être reconstruit. Pour ce faire, suivez les étapes de la section suivante.
Index, index filtrés et vues indexées
Les incohérences dans les index correspondent aux erreurs 8951 et 8952 (pour les tables) ou 8907 et 8908
(pour les affichages) dans la sortie DBCC CHECK* de l’étape 2.
Pour réparer ces incohérences, exécutez DBCC CHECKTABLE avec REPAIR_REBUILD. Cela répare les structures
d’index sans perte de données. Toutefois, la base de données doit être en mode utilisateur unique et n’est donc
pas disponible pour les autres utilisateurs pendant la réparation.
Vous pouvez également reconstruire manuellement les index affectés. Cette option doit être utilisée si la charge
de travail ne peut pas être mise hors connexion, car la reconstruction d’index peut être effectuée en tant
qu’opération EN LIGNE (dans les éditions prises en charge de SQL Server).
Reconstruire les index
Si la définition de la base de données en mode utilisateur unique n’est pas une option, vous pouvez reconstruire
individuellement les index à l’aide de ALTER INDEX REBUILD, pour chaque index identifié à l’étape 2.
Utilisez la requête suivante pour obtenir les noms de table et d’index pour une object_id données index_id.
SELECT QUOTENAME(SCHEMA_NAME(o.schema_id)) + N'.' + QUOTENAME(o.name) AS 'table', i.name AS 'index_name'
FROM sys.objects o JOIN sys.indexes i ON o.object_id=i.object_id
WHERE o.object_id = object_id AND i.index_id = index_id
Use the following statement to rebuild the index:
ALTER INDEX index_name ON [schema_name].[table_name] REBUILD WITH (ONLINE=ON)
NOTE
Si vous utilisez des éditions Standard, Web ou Express, la build d’index en ligne n’est pas prise en charge. Par conséquent,
l’option WITH (ONLINE=ON) doit être supprimée de l’instruction ALTER INDEX.
L’exemple suivant illustre la reconstruction d’un index filtré :
GO
c2 datetime,
c3 float
GO
INSERT dbo.table2 (c2,c3) VALUES ('1899-12-31 23:58:00.470', -0.00138344907407406)
GO
CREATE INDEX ix_1 ON dbo.table2(c2)
WHERE (c2=-0.00138344907407406)
GO
ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL=130GOALTER INDEX ix_1 ON [dbo].[table2] REBUILD WITH
(ONLINE=ON)
GO
Si vous avez des plans de maintenance réguliers, nous vous recommandons d’inclure cette reconstruction
d’index dans le cadre de votre maintenance programmée.
Réparer à l’aide du DBCC
Pour chaque (object_id) liées à un index avec des incohérences que vous avez notées à l’étape 2, exécutez le
script suivant pour effectuer la réparation. Ce script définit la base de données en mode utilisateur unique pour
l’opération de réparation. Dans le pire des cas, la réparation effectue une reconstruction complète de l’index.
USE [database_name]
GO
ALTER DATABASE CURRENT SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DBCC CHECKTABLE (object_id, REPAIR_REBUILD) WITH EXTENDED_LOGICAL_CHECKS, NO_INFOMSGS, TABLERESULTS
GO
ALTER DATABASE CURRENT SET MULTI_USER
GO
Annexe C : Requêtes pour identifier les tableaux candidats

Les scripts suivants identifient les tableaux candidats que vous souhaitez peut-être valider à l’aide de DBCC
CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS, en fonction de l’existence de structures et de contraintes
persistantes qui utilisent des types de données affectés par les améliorations apportées au niveau de
compatibilité 130.
L’ensemble de requêtes suivant liste des détails sur les tables et les structures potentiellement affectées qui
nécessitent une validation supplémentaire.
Vues indexées
La requête suivante renvoie toutes les vues indexées faisant référence à des colonnes à l’aide de types de
données affectés ou à l’aide de l’une des fonctions intégrées concernées :
SELECT QUOTENAME(SCHEMA_NAME(o.schema_id)) + N'.' + QUOTENAME(o.name) AS 'view', QUOTENAME(i.name) AS
'index',QUOTENAME(sed.referenced_schema_name) + N'.' + QUOTENAME(sed.referenced_entity_name) AS 'referenced
table', QUOTENAME(c.name) AS 'referenced column', t.name AS 'data type',
-- if the data type is numeric, integer, or money, the only cases that warrent additional checks
-- with DBCC is if the view definition contains a float or datetime value, or a conversion to such value
s.definition
JOIN sys.objects o ON sed.referencing_id = o.object_id AND o.type=N'V'
JOIN sys.indexes i ON o.object_id=i.object_id
JOIN sys.sql_modules s ON s.object_id=o.object_id
JOIN sys.columns c ON sed.referenced_id=c.object_id AND sed.referenced_minor_id=c.column_idJOIN sys.types t

ON c.system_type_id=t.system_type_id
WHERE referencing_class=1 AND referenced_class=1 AND (c.system_type_id IN
( 59 --real
, 62 --float
, 58 --smalldatetime
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint
) OR s.[definition] LIKE '%DATEDIFF%'
OR s.[definition] LIKE '%CONVERT%'
OR s.[definition] LIKE '%CAST%'
OR s.[definition] LIKE '%DATEPART%'
OR s.[definition] LIKE '%DEGREES%')

La requête suivante renvoie toutes les tables avec des colonnes calculées faisant référence à d’autres colonnes à
l’aide de types de données affectés ou à l’aide de l’une des fonctions intégrées affectées, où la colonne est
persistante ou référencé à partir d’un index.
SELECT QUOTENAME(sed.referenced_schema_name) + N'.' +

QUOTENAME(sed.referenced_entity_name) AS 'candidate table with computed column',
QUOTENAME(c1.name) AS 'computed column', c1.is_persisted,QUOTENAME(c2.name) AS 'referenced column', t.name

AS 'data type',
-- with DBCC is if the column definition contains a float or datetime value, or a conversion to such value
c1.definition
JOIN sys.computed_columns c1 ON sed.referencing_id=c1.object_id AND sed.referencing_minor_id=c1.column_id
JOIN sys.columns c2 ON sed.referenced_id=c2.object_id AND sed.referenced_minor_id=c2.column_id
JOIN sys.types t ON c2.system_type_id=t.system_type_idWHERE referencing_class=1 AND referenced_class=1
AND (c2.system_type_id IN
( 59 --real
, 62 --float
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint
) OR c1.[definition] LIKE '%DATEDIFF%'
OR c1.[definition] LIKE '%CONVERT%'
OR c1.[definition] LIKE '%DATEPART%'
OR c1.[definition] LIKE '%DEGREES%')
AND (
-- the column is persisted
c1.is_persisted=1
-- OR the column is included in an index
OR EXISTS (SELECT 1 FROM sys.index_columns ic WHERE ic.object_id=c1.object_id AND ic.column_id=c1.column_id)
)
Index filtrés
La requête suivante renvoie toutes les tables avec index filtrés qui font référence à des colonnes dans la
condition de filtre qui ont des types de données affectés :
QUOTENAME(sed.referenced_entity_name) AS 'candidate table with filtered index',
QUOTENAME(i.name) AS 'referencing index',
QUOTENAME(c.name) AS 'referenced column',
t.name AS 'data type',
-- with DBCC is where the filter condition contains a float or datetime value
i.filter_definition AS 'filter condition'
JOIN sys.indexes i ON sed.referencing_id=i.object_id AND sed.referencing_minor_id=i.index_id
JOIN sys.columns c ON sed.referenced_id=c.object_id AND sed.referenced_minor_id=c.column_id
JOIN sys.types t ON c.system_type_id=t.system_type_id
WHERE referencing_class=7 AND referenced_class=1 AND i.has_filter=1
AND c.system_type_id IN ( 59 --real
, 62 --float
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint
Vérifier les contraintes

La requête suivante répertorie toutes les tables avec des contraintes de vérification qui font référence aux types
de données affectés ou aux fonctions intégrées :
QUOTENAME(sed.referenced_entity_name) AS 'candidate table with check constraint',
QUOTENAME(c.name) AS 'constraint_name', c.definition AS 'constraint_definition',
QUOTENAME(col.name) AS 'referenced column', t.name AS 'data type'
JOIN sys.check_constraints c ON sed.referencing_id=c.object_id AND sed.referencing_class=1
JOIN sys.columns col ON sed.referenced_id=col.object_id AND sed.referenced_minor_id=col.column_id
JOIN sys.types t ON col.system_type_id=t.system_type_id
WHERE referencing_class=1 AND referenced_class=1 AND (col.system_type_id IN
( 59 --real
, 62 --float
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint)
OR c.[definition] LIKE '%DATEDIFF%'
OR c.[definition] LIKE '%CONVERT%'
OR c.[definition] LIKE '%DATEPART%'
OR c.[definition] LIKE '%DEGREES%')
Annexe D : Script pour créer des instructions CHECK*

Le script suivant combine les requêtes de l’annexe précédente et simplifie les résultats en présentant une liste de
tableaux et d’affichages sous la forme d’instructions CHECKCONSTRAINTS et CHECKTABLE.
DECLARE @CRLF nvarchar(10) = CHAR(13) + CHAR(10);

DECLARE @sql nvarchar(max) = N'DBCC TRACEON(139,-1); ' + @CRLF ;
SELECT @sql += N'DBCC CHECKTABLE (N''' + object_for_checktable + N''') WITH EXTENDED_LOGICAL_CHECKS,

NO_INFOMSGS, TABLERESULTS; ' + @CRLF
FROM
(
--indexed views
SELECT DISTINCT QUOTENAME(SCHEMA_NAME(o.schema_id)) + N'.' + QUOTENAME(o.name) AS 'object_for_checktable'
FROM sys.sql_expression_dependencies AS sed
INNER JOIN sys.objects AS o ON sed.referencing_id = o.object_id AND o.type = N'V'
INNER JOIN sys.indexes AS i ON o.object_id = i.object_id
INNER JOIN sys.sql_modules AS s ON s.object_id = o.object_id
INNER JOIN sys.columns AS c ON sed.referenced_id = c.object_id AND sed.referenced_minor_id = c.column_id
INNER JOIN sys.types AS t ON c.system_type_id = t.system_type_id
WHERE referencing_class = 1 AND referenced_class=1

AND (c.system_type_id IN
( 59 --real
, 62 --float
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint
) OR s.[definition] LIKE N'%DATEDIFF%'
OR s.[definition] LIKE N'%CONVERT%'
OR s.[definition] LIKE N'%CAST%'
OR s.[definition] LIKE N'%DATEPART%'
OR s.[definition] LIKE N'%DEGREES%')
UNION
--persisted computed columns

SELECT DISTINCT QUOTENAME(sed.referenced_schema_name) + N'.' + QUOTENAME(sed.referenced_entity_name) AS
'object_for_checktable'
INNER JOIN sys.computed_columns AS c1 ON sed.referencing_id = c1.object_id AND sed.referencing_minor_id =
c1.column_id
INNER JOIN sys.columns AS c2 ON sed.referenced_id=c2.object_id AND sed.referenced_minor_id = c2.column_id
INNER JOIN sys.types AS t ON c2.system_type_id = t.system_type_id
WHERE referencing_class = 1 AND referenced_class = 1
AND (c2.system_type_id IN
( 59 --real
, 62 --float
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint
) OR c1.[definition] LIKE N'%DATEDIFF%'
OR c1.[definition] LIKE N'%CONVERT%'
OR c1.[definition] LIKE N'%DATEPART%'
OR c1.[definition] LIKE N'%DEGREES%')
AND (
-- the column is persisted
c1.is_persisted = 1
-- OR the column is included in an index
OR EXISTS (SELECT 1 FROM sys.index_columns AS ic
WHERE ic.object_id = c1.object_id AND ic.column_id=c1.column_id)
)
UNION
--indexed views
'object_for_checktable'
INNER JOIN sys.indexes AS i ON sed.referencing_id = i.object_id AND sed.referencing_minor_id = i.index_id
INNER JOIN sys.columns AS c ON sed.referenced_id = c.object_id AND sed.referenced_minor_id = c.column_id
INNER JOIN sys.types AS t ON c.system_type_id = t.system_type_id
WHERE referencing_class = 7 AND referenced_class = 1 AND i.has_filter = 1
AND c.system_type_id IN (
59 --real
, 62 --float
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint
)) AS a
SELECT @sql += N'DBCC CHECKCONSTRAINTS (N''' + object_for_checkconstraints + N'''); ' + @CRLF

FROM
(

'object_for_checkconstraints'
INNER JOIN sys.check_constraints AS c ON sed.referencing_id = c.object_id AND sed.referencing_class = 1
INNER JOIN sys.columns AS col ON sed.referenced_id = col.object_id AND sed.referenced_minor_id =
col.column_id
INNER JOIN sys.types AS t ON col.system_type_id = t.system_type_id
WHERE referencing_class = 1 AND referenced_class = 1 AND (col.system_type_id IN
( 59 --real
, 62 --float
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint
) OR c.[definition] LIKE N'%DATEDIFF%'
OR c.[definition] LIKE N'%CONVERT%'
OR c.[definition] LIKE N'%DATEPART%'
OR c.[definition] LIKE N'%DEGREES%')
) a
SET @sql += N'DBCC TRACEOFF(139,-1);';
PRINT @sql;
--to run the script immediately, use the following command:

--EXECUTE sp_executesql @sql;
GO
Itérer dans un jeu de résultats à l’aide de Transact-
SQL dans SQL Server
Cet article décrit différentes méthodes que vous pouvez utiliser pour itérer dans un jeu de résultats à l’aide de
Transact-SQL dans SQL Server.
Résumé
Cet article décrit différentes méthodes que vous pouvez utiliser pour simuler une logique FETCH-NEXT de types
de curseur dans une procédure stockée, un déclencheur ou un lot SQL transaction.
Utiliser des instructions transact-SQL pour itérer dans un jeu de

résultats
Il existe trois méthodes que vous pouvez utiliser pour itérer dans un jeu de résultats à l’aide d’instructions
Transact-SQL.
L’une des méthodes est l’utilisation de tables temporaires. Avec cette méthode, vous créez un instantané de
l’instruction initiale et l’utilisez comme base pour SELECT le curseur. Par exemple :
/********** example 1 **********/

declare @au_id char( 11 )
set rowcount 0
select * into #mytemp from authors
set rowcount 1
select @au_id = au_id from #mytemp
while @@rowcount <> 0
begin
set rowcount 0
select * from #mytemp where au_id = @au_id
delete #mytemp where au_id = @au_id
set rowcount 1
select @au_id = au_id from #mytemp<BR/>
end
set rowcount 0
Une deuxième méthode consiste à utiliser la fonction pour parcourir un tableau une ligne min à la fois. Cette
méthode capture les nouvelles lignes qui ont été ajoutées après le début de l’exécution de la procédure stockée,
à condition que la nouvelle ligne possède un identificateur unique supérieur à la ligne actuelle en cours de
traitement dans la requête. Par exemple :
/********** example 2 **********/
declare @au_id char( 11 )
select @au_id = min( au_id ) from authors

while @au_id is not null
begin
select * from authors where au_id = @au_id
select @au_id = min( au_id ) from authors where au_id > @au_id
end
NOTE
Les exemples 1 et 2 supposent qu’il existe un identificateur unique pour chaque ligne du tableau source. Dans certains
cas, il n’existe aucun identificateur unique. Si c’est le cas, vous pouvez modifier la méthode de table temp pour utiliser une
colonne de clé nouvellement créée. Par exemple :
/********** example 3 **********/

set rowcount 0
select NULL mykey, * into #mytemp from authors
set rowcount 1
update #mytemp set mykey = 1
while @@rowcount > 0

begin
set rowcount 0
select * from #mytemp where mykey = 1
delete #mytemp where mykey = 1
set rowcount 1
update #mytemp set mykey = 1
end
set rowcount 0
Références
ROW_NUMBER (Transact-SQL)
Stratégie de prise en charge des assemblys .NET
Framework non testés dans l’environnement
hébergé SQL Server CLR
Cet article décrit la stratégie de prise en charge des assemblys Microsoft .NET Framework non testés dans
l’environnement hébergé par le CLR (Common Language Runtime) .NET Framework dans SQL Server.
Test et prise en charge de l’assembly

Lorsque vous inscrivez un assembly qui fait référence à un assembly .NET Framework non testé dans SQL
Server, vous pouvez recevoir le message d’avertissement suivant :
WARNING
L’assembly AssemblyName .Net Frameworks que vous enregistrez n’est pas entièrement testé dans SQL
Server’environnement hébergé.
Le message signifie que l’assembly .NET Framework n’a pas été testé dans l SQL Server de l’environnement
hébergé par le CLR. Par conséquent, l’assembly n’est pas pris en charge dans SQL Server environnement
hébergé par le CLR.
Un assembly .NET Framework non testé peut quitter son processus hôte lorsqu’une condition critique telle
qu’une condition de faible mémoire se produit. Vous pouvez utiliser l’assembly dans l SQL Server de
l’environnement hébergé par le CLR à vos propres risques. Toutefois, SQL Server services de support client
(CSS) ne vous aideront pas à utiliser et à résoudre les problèmes associés à un assembly de .NET Framework
non pris en charge. Si CSS détermine qu’un assembly particulier non pris en SQL Server des problèmes, vous
pouvez être invité à arrêter d’utiliser l’assembly. En outre, vous pouvez être invité à arrêter temporairement
d’utiliser l’assembly lorsque CSS dépannera un problème SQL Server si nécessaire.
Inscription de l’assembly
Il existe deux types d’assemblys .NET : pure et mixte. Les assemblys .NET purs contiennent uniquement des
instructions MSIL. Les assemblys mixtes contiennent des instructions d’ordinateur nonmanagées et des
instructions MSIL. Les assemblys mixtes sont généralement compilés dans un compilateur C++ à l’aide du
commutateur « clr » et contiennent également des instructions d’ordinateur conçues à partir du code C++ natif.
Lorsque vous utilisez un assembly .NET Framework qui ne figure pas dans la liste prise en charge, vous devez
utiliser l’instruction CREATE ASSEMBLY pour inscrire l’assembly et les assemblys référencés dans la base de
données SQL Server. L SQL Server CREATE ASSEMBLY permet uniquement l’enregistrement .NET Framework
assemblys pures. Si l’assembly ou tout assembly référencé n’est pas un assembly .NET Framework pur (et, par
conséquent, est un assembly mixte), vous recevez le message d’erreur suivant :

CREATE ASSEMBLY for assembly <assembly name> ' failed because assembly ' <assembly name> is
malformed or not a pure .NET assembly.
En-tête PE non vérifiable/stub natif.
Dans ce cas, vous ne pouvez pas utiliser l’assembly .NET Framework avec SQL CLR, sauf si l’assembly se trouve
dans la liste prise en charge documentée dans cet article. En outre, un assembly .NET Framework peut changer
d’assembly pur à un assembly mixte entre les versions. Si vous utilisez un assembly qui ne figure pas dans la
liste prise en charge, il se peut que l’assembly fonctionne dans une version du .NET Framework mais pas dans
une autre. Cette restriction ne s’applique pas aux assemblys de la liste prise en charge, car ces assemblys ne
doivent pas être enregistrés à l’aide de l’instruction CREATE ASSEMBLY.
En outre, vous devez gérer ces assemblys après avoir mis à niveau .NET Framework. Message d’erreur lorsque
vous exécutez une routine CLR ou utilisez un assembly dans SQL Server :
Assembly in host store has a different signature than assembly in GAC. (Exception de HRESULT :
0x80131050)
Assemblys pris en charge dans un environnement SQL Server CLR

Les assemblys .NET Framework sont pris en charge dans un environnement SQL Server CLR :
Microsoft.VisualBasic.dll
Mscorlib.dll
System.Data.dll
System.dll
System.Xml.dll
Microsoft.VisualC.dll
CustomMarshalers.dll
System.Security.dll
System.Web.Services.dll
System.Data.SqlXml.dll
System.Transactions.dll
System.Data.OracleClient.dll
System.Configuration.dll
SQL Server requête qui tape une colonne Unicode
dans un classement binaire renvoie des résultats
incorrects
Cet article vous aide à résoudre le problème qui se produit lorsqu’une instruction contient une ou plusieurs
clauses définies pour une colonne Unicode et qui permettent de taper la colonne Unicode dans un autre IN Or
classement collate binaire.
Symptômes
Vous avez une table dans une base SQL Server de données dans laquelle les conditions suivantes sont vraies :
Le tableau contient une colonne Unicode. Par exemple, le tableau possède une colonne nchar(5).
Le classement de la colonne Unicode est Latin1_General_BIN .
La même colonne Unicode fait partie d’un index. Toutefois, les instructions T-SQL qui sont exécutés sur ce
tableau peuvent renvoyer des résultats incorrects. Ce problème se produit lorsque les conditions suivantes
sont remplies :
L’instruction T-SQL contient une ou plusieurs clauses définies IN pour la même colonne Or Unicode.
L’instruction T-SQL contient pour taper la colonne collate Unicode dans un autre classement binaire.
Exemple de requête :
CREATE TABLE [dbo].[Table_1]([Col1] [smallint] NOT NULL,

[Col2] [nchar](5),
[Col3] [nchar](5) COLLATE Latin1_General_BIN NOT NULL, -- Col3 , a Unicode Column with "Latin1_General_BIN"
collation
CONSTRAINT [PK__Table_1] PRIMARY KEY CLUSTERED -- Primary Key on all the 3 columns
([Col1] ASC,
[Col2] ASC,
[Col3] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
select * from Table_1 where Col1 = 1 and Col2 = '1' and Col3 collate Chinese_PRC_BIN IN (N'1' ,N'2') --
This statement using "IN" and "collate" might give incorrect results.
go
select * from Table_1 where Col1 = 1 and Col2 = '1' and (Col3 collate Chinese_PRC_BIN = N'1' or Col3 collate
Chinese_PRC_BIN = N'2') -- This statement using "OR" and "collate" might give incorrect results.
go
Pour contourner ce problème, assurez-vous que la colonne Unicode (Col3 dans l’exemple de requête de la
section Symptômes) répond à l’une des conditions suivantes :
Est du type de données char(5) ou nvarchar(5).
Est défini à l’aide du même classement pour lequel le classement est souhaité (sachez que ce n’est qu’un
exemple ; d’autres Chinese_PROC_BIN Chinese_PROC_BIN classements binaires s’appliquent également).
Est d’un classement autre que Latin1_General_BIN .
Est compilé sur le classement CI. Par exemple : collate Chinese_PRC_90_CI_AI IN (N'1 ', N'2 ') .
Est comparé à une constante qui correspond à la longueur de colonne. Par exemple,
collate Chinese_PRC_BIN IN (N'1 ', N'2 ') .
Ne fait pas partie de l’index, ou une analyse de tableau est forcée à l’aide de l’indicateur FORCESCAN de
tableau.
Fonctions telles que RTRIM et utilisées pour forcer une analyse de LTRIM tableau.
Pour reproduire ce problème, exécutez le script suivant :
CREATE DATABASE Test_DB
GO
use Test_DB
go
CREATE TABLE [dbo].[Table_1]([Col1] [smallint] NOT NULL,

[Col2] [nchar](5),
[Col3] [nchar](5) COLLATE Latin1_General_BIN NOT NULL, -- Col3 , a Unicode Column with "Latin1_General_BIN"
collation
CONSTRAINT [PK__Table_1] PRIMARY KEY CLUSTERED -- Primary Key on all the 3 columns
([Col1] ASC,
[Col2] ASC,
[Col3] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
-- Populate the table with a sample script as below
declare @x as int
declare @y as int
set @x=1
set @y=1
while (@x<=2)
begin
while (@y<=1000)
begin
insert into Table_1 values (@x,@y,@y)
set @y=@y+1
end
set @x=@x +1
end
go
select * from Table_1 where Col1 = 1 and Col2 = '1' and Col3 collate Chinese_PRC_BIN = N'1' -- Expected
output of one row.
go
select * from Table_1 where Col1 = 1 and Col2 = '1' and Col3 collate Chinese_PRC_BIN in (N'1' ,N'2') -- No
rows returned when output for Col3= N'1' is expected.
go
select * from Table_1 where Col1 = 1 and Col2 = '1' and (Col3 collate Chinese_PRC_BIN = N'1' or Col3 collate
Chinese_PRC_BIN = N'2') -- No rows returned when output for Col3= N'1' is expected.
go
S’applique à
SQL Server Web 2014
SQL Server Web 2012
SQL Server 2008 R2 Parallel Data Warehouse
SQL Server Web 2008
Supprimer des lignes en double d’une table SQL
Server à l’aide d’un script
Cet article fournit un script que vous pouvez utiliser pour supprimer des lignes en double d’un tableau dans
Microsoft SQL Server.
Résumé
Il existe deux méthodes courantes que vous pouvez utiliser pour supprimer des enregistrements en double
d’SQL Server table. Pour la démonstration, commencez par créer un exemple de table et de données :
create table original_table (key_value int )
insert into original_table values (1)


Ensuite, essayez les méthodes suivantes pour supprimer les lignes en double du tableau.
Méthode 1
Exécutez le script suivant :
SELECT DISTINCT *
INTO duplicate_table
FROM original_table
GROUP BY key_value
HAVING COUNT(key_value) > 1
DELETE original_table
WHERE key_value
IN (SELECT key_value
FROM duplicate_table)
INSERT original_table
SELECT *
FROM duplicate_table
DROP TABLE duplicate_table
Ce script prend les actions suivantes dans l’ordre donné :

Déplace une instance d’une ligne en double du tableau d’origine vers une table en double.
Supprime toutes les lignes de la table d’origine qui se trouvent également dans la table en double.
Déplace les lignes du tableau en double vers la table d’origine.
Dépose la table en double.
Cette méthode est simple. Toutefois, vous devez avoir suffisamment d’espace disponible dans la base de
données pour créer temporairement la table en double. Cette méthode incurse également une surcharge, car
vous déplacez les données.
En outre, si votre table possède une colonne IDENTITY, vous devez utiliser SET IDENTITY_INSERT ON lorsque
vous restituerez les données dans la table d’origine.
Méthode 2
La ROW_NUMBER qui a été introduite dans Microsoft SQL Server 2005 simplifie cette opération :
DELETE T
FROM
(
SELECT *
, DupRank = ROW_NUMBER() OVER (
PARTITION BY key_value
ORDER BY (SELECT NULL)
)
FROM original_table
) AS T
WHERE DupRank > 1
Ce script prend les actions suivantes dans l’ordre donné :

Utilise la fonction pour partitionner les données en fonction de l’une ou plusieurs colonnes ROW_NUMBER
key_value séparées par des virgules.
Supprime tous les enregistrements qui ont reçu une DupRank valeur supérieure à 1. Cette valeur indique que
les enregistrements sont des doublons.
En raison de (SELECT NULL) l’expression, le script ne trie pas les données partitionées en fonction d’une
condition quelconque. Si votre logique de suppression des doublons nécessite de choisir les enregistrements à
supprimer et les enregistrements à conserver en fonction de l’ordre de tri des autres colonnes, vous pouvez
utiliser l’expression ORDER BY pour ce faire.
La méthode 2 est simple et efficace pour les raisons suivantes :
Il n’est pas nécessaire de copier temporairement les enregistrements en double dans une autre table.
Il n’est pas nécessaire de joindre la table d’origine à elle-même (par exemple, à l’aide d’une sous-demande
qui renvoie tous les enregistrements en double à l’aide d’une combinaison de GROUP BY et HAVING).
Pour de meilleures performances, vous devez avoir dans la table un index correspondant qui utilise la clé
d’index et inclut toutes les colonnes de tri que vous avez peut-être utilisées dans key_value l’expression
ORDER BY.
Toutefois, cette méthode ne fonctionne pas dans les versions obsolètes de SQL Server qui ne prend pas en
charge la fonction ROW_NUMBER. Dans ce cas, vous devez utiliser la méthode 1 ou une méthode similaire à la
place.
Faire pivoter un tableau dans SQL Server
Cet article explique comment faire pivoter un tableau dans SQL Server.
Résumé
Cet article explique comment faire pivoter un SQL Server tableau. Supposons que vous avez une table nommée
QTRSALES . Le tableau possède les colonnes et les données YEAR QUARTER au format AMOUNT suivant.
NOTE
Il n’existe aucune ligne pour le quatrième trimestre de 1996 :
Y EA R T RIM EST RE M O N TA N T
1995 1 125,000.90
1995 2 136,000.75
1995 3 212,000.34
1995 4 328,000.82
1996 3 728,000.35
1996 2 422,000.13
1996 1 328,000.82
À présent, supposons que vous vouliez faire pivoter la table afin de pouvoir voir les données au format suivant :
Y EA R Q1 Q2 Q3 Q4
1995 125,000.90 136,000.75 212,000.34 328,000.82
1996 328,000.82 422,000.13 728,000.35 0.00
La requête que vous utiliseriez pour faire pivoter la table se trouve dans la section suivante de cet article.
Exemple de requête pour faire pivoter la table

Voici la requête que vous utiliseriez pour faire pivoter la table :
SELECT YEAR,
Q1= ISNULL((SELECT AMOUNT FROM QTRSALES WHERE QUARTER = 1 AND YEAR =
Q.YEAR),0),
Q.YEAR),0),
Q.YEAR),0),
Q.YEAR),0)
FROM QTRSALES Q
GROUP BY YEAR
Requête pour les tables de grande taille

Pour les tables de grande taille, cette requête sera plus rapide :
year=q.year,
SUM(CASE quarter WHEN 1 THEN amount ELSE 0 END) as Q1,
SUM(CASE quarter WHEN 4 THEN amount ELSE 0 END) as Q4
FROM qtrsales q
GROUP BY year
Référence
FROM - Utilisation de PIVOT et UNPIVOT
Vous pouvez faire face à des problèmes de délai
d’SQL des objets CLR via Visual Studio
Cet article vous aide à résoudre le problème de délai d’SQL lors du déploiement d’objets CLR Visual Studio.
Symptômes
Lorsque vous déployez SQL objets CLR de Visual Studio à SQL Server, vous pouvez être en mesure de faire face
à diverses erreurs similaires à ce qui suit :
Message d’erreur 1 :
Erreur : échec du démarrage de la transaction de chargement de base de données.

Erreur : L’opération n’a pas pu être achevée
Message d’erreur 2 :
Déploiement du fichier : TEstAssembly.dll, Chemin d’accès : E:\cases\CL

MY\TEstAssembly\TEstAssembly\obj\Debug\TEstAssembly.dll ... Erreur : Le délai d’expiration a expiré.
Le délai d’expiration s’est produit avant la fin de l’opération ou le serveur ne répond pas.
Toutefois, si vous déployez les mêmes objets CLR à l’aide de la commande SQL Server Management Studio vous
CREATE ASSEMBLY n’avez aucun problème.
Cause
Le problème se produit lorsque les objets CLR SQL sont si importants qu’il faut beaucoup de temps pour les
déployer sur SQL Server. La valeur de délai d’avance par défaut pour les connexions est de 15 secondes et de 30
secondes pour les requêtes, respectivement. Lors du déploiement d’assemblys de grande taille, l’instruction
exécutée sur le système SQL Server backend peut prendre plus de 30 secondes pour renvoyer l’erreur décrite
dans la CREATE ASSEMBLY section Symptômes.
Résolution
Augmentez les valeurs de délai d’Visual Studio requête et de connexion à l’aide des procédures documentées ci-
dessous.
Modification du délai d’out de la requête
1. In Visual Studio IDE, navigate to Tools -> Options -> Database Tools -> Quer y and View Designers .
2. Vous pouvez soit décocher l’option Annuler la requête longue, soit modifier la valeur d’Annuler après
l’option **** en une valeur supérieure.
Modification du délai de connexion
1. Dans Visual Studio IDE, activez l’Explorateur de serveurs en naviguant jusqu’à -> l’Explorateur de
ser veurs.
2. Dans l’Explorateur de serveurs, cliquez avec le bouton droit sur la connexion SQL Server où les objets
CLR sont déployés et choisissez Modifier la connexion.
3. Cliquez sur le bouton Avancé dans la fenêtre Modifier la connexion.
4. Dans la fenêtre Propriétés avancées, modifiez la valeur Connecter délai d’Connecter section
Initialisation à une valeur supérieure.
L’utilisation de procédures stockées étendues ou
SP_OA procédures stockées pour charger le CLR
dans SQL Server n’est pas prise en charge

Résumé
SQL Server 2005 et versions ultérieures hébergent le CLR (Common Language Runtime) et des procédures,
fonctions, déclencheurs, types et agrégats de prise en charge écrits dans des langages CLR. Dans ces versions,
vous ne pouvez pas charger CLR à l’aide de procédures stockées étendues ou sp_OA de procédures stockées.
L.NET Framework assembly fournit un environnement robuste pour l’facturation d’assemblys à
System.Runtime.InteropServices partir de code nonmanaté. Toutefois, il existe plusieurs dissensions techniques
entre les implémentations internes du CLR et SQL Server :
Threading
Pour améliorer les performances, le CLR implémente thread local Stockage.
En outre, le CLR utilise uniquement la planification basée sur les threads et ne prend pas en charge la
planification en mode fibre. Toutefois, SQL Server peut utiliser la planification en mode fibre. Pour configurer
cette propriété, exécutez la procédure stockée à l’aide de sp_configure l’option de regroupement léger. Pour
plus d’informations sur cette rubrique, examinez l’option de configurationdu serveur de regroupement léger.
Mémoire
L’utilisation de procédures stockées étendues et d’OLE Automation s’exécutent dans l’espace d’adressare de la
mémoire virtuelle de la SQL Server. La mémoire SQL Server par défaut n’est qu’une fraction de la mémoire que
les SQL Server peuvent potentiellement utiliser et le CLR est en concurrence avec les implémentations
existantes pour ces ressources mémoire.
Interopérabilité COM
Cette section traite spécifiquement de l’utilisation d’OLE Automation dans SQL Server et s’applique aux objets
COM in-process et out-of-process. Assembly meta data for function interfaces implements a typed mechanism
for any invocations.
Dans le cadre de cette conception, le wrapper COM Callable pour un assembly doit utiliser un mécanisme
externe de mappage d’un ClassID à un membre d’une classe gérée. En raison de ce mappage explicite, il n’est
pas possible d’établir une liste racine d’interfaces disponibles du point de vue nonmanage.
La procédure stockée étendue utilise l’interface pour déterminer la prise en charge sp_oaCreate
IUnknown::QueryInterface de l’objet pour une interface particulière. L’interopérabilité entre le CLR et le code
nonmanadé repose sur l’interface IDispatch pour implémenter les interfaces. Étant donné qu’il n’existe pas
d’équivalent à une méthode à un assembly CLR, vous ne pouvez pas créer QueryInterface une instance de
l’objet.
Erreur 9002. Le journal des transactions de la base
de données est plein en raison
AVAILABILITY_REPLICA message d’erreur SQL
Server
Cet article vous aide à résoudre l’erreur 9002 qui se produit lorsque le journal des transactions devient grand ou
à court d’espace dans SQL Server.
Symptômes
Vous avez Microsoft SQL Server 2012 ou une version ultérieure installée sur un serveur.
L’instance de SQL Server est un réplica principal dans l’environnement des groupes de disponibilité
AlwaysOn.
L’option de connexion automatique pour les fichiers journaux de transactions est définie dans SQL
Server.
Dans ce scénario, le journal des transactions peut devenir important et ne plus avoir assez d’espace disque ou
dépasser l’option MaxSize définie pour le journal des transactions au niveau du réplica principal et vous recevez
un message d’erreur semblable à ce qui suit :
Erreur : 9002, Gravité : 17, État : 9. Le journal des transactions de la base de données '%.*ls' est plein en
raison de la AVAILABILITY_REPLICA'
Cause
Cela se produit lorsque les modifications consignées dans le réplica principal ne sont pas encore renforcés sur le
réplica secondaire. Pour plus d’informations sur le processus de synchronisation des données dans
l’environnement AlwaysOn, vous pouvez passer en revue :
Processus de synchronisation des données
Résolution des problèmes

Il existe deux scénarios qui peuvent entraîner une croissance des journaux dans une base de données de
disponibilité et la AVAILABILITY_REPLICA ' log_reuse_wait_desc :
Scénario 1 : Latence de livraison des modifications consignées à un niveau secondaire
Lorsque des transactions modifient des données dans le réplica principal, ces modifications sont
encapsulées dans des blocs d’enregistrement de journal et ces blocs journal sont remis et renforcés dans
le fichier journal de base de données au niveau du réplica secondaire. Le réplica principal ne peut pas
réécrire les blocs de journaux dans son propre fichier journal tant que ces blocs de journaux n’ont pas été
remis et renforcés dans le fichier journal de base de données correspondant dans tous les réplicas
secondaires. Tout retard dans la remise ou le renforcement de la remise de ces blocs à n’importe quel
réplica du groupe de disponibilité empêchera la troncation des modifications enregistrées dans la base
de données au niveau du réplica principal et provoquera l’expansion de l’utilisation du fichier journal.
Pour plus d’informations, voir : Latence du réseau élevée ou faible débit réseau entraîne la construction
du journal sur le réplica principal
Scénario 2 : Redo Latence
Une fois renforcé dans le fichier journal de base de données secondaire, un thread de redéployage dédié
dans l’instance de réplica secondaire applique les enregistrements journaux contenus au ou aux fichiers
de données correspondants. Le réplica principal ne peut pas réécrire les blocs de journaux dans son
propre fichier journal tant que tous les threads de nouveau dans tous les réplicas secondaires n’ont pas
appliqué les enregistrements journaux contenus.
Si l’opération de redoyage sur un réplica secondaire n’est pas en mesure de suivre la vitesse à laquelle les
blocs de journaux sont renforcés sur ce réplica secondaire, cela entraîne une croissance du journal au
niveau du réplica principal. Le réplica principal peut uniquement tronqué et réutiliser son propre journal
des transactions au point que tous les threads de réplica secondaire ont appliqué. S’il existe plusieurs
fichiers secondaires, comparez la colonne truncation_lsn de l’affichage gestion dynamique sur les
différents fichiers secondaires pour identifier la base de données secondaire qui retarde le plus la
troncation des sys.dm_hadr_database_replica_states journaux.
Vous pouvez utiliser le tableau de bord AlwaysOn et les affichages de gestion dynamique pour vous aider
à surveiller la file d’attente d’envoi du journal et sys.dm_hadr_database_replica_states la file d’attente de
redessin. Voici quelques champs clés :
CHAMP DESC RIP T IO N
log_send_queue_size Quantité d’enregistrements journaux qui ne sont pas

arrivés au réplica secondaire
log_send_rate Taux d’envoi des enregistrements journaux aux bases de

données secondaires
redo_queue_size La quantité d’enregistrements journaux dans les fichiers

journaux du réplica secondaire qui n’a pas encore été
refaire, en kilo-octets (Ko)
redo_rate La vitesse à laquelle les enregistrements journaux sont

en cours de redone sur une base de données secondaire
donnée, en kilo-octets (Ko)/seconde
last_redone_lsn Numéro de séquence de journal réel du dernier

enregistrement de journal qui a été resaisyé sur la base
de données secondaire. last_redone_lsn est toujours
inférieure à last_hardened_lsn
last_received_lsn ID de bloc de journal identifiant le point vers lequel tous

les blocs de journaux ont été reçus par le réplica
secondaire qui héberge cette base de données
secondaire. Reflète un ID de bloc de journal ajouté avec
des zéros. Il ne s’agit pas d’un numéro de séquence de
journal réel.
Par exemple, exécutez la requête suivante sur le réplica principal afin de signaler le réplica avec la
première truncation_lsn et est la limite supérieure que le principal peut récupérer dans son propre
journal des transactions :
SELECT ag.name AS [availability_group_name]

, d.name AS [database_name]
, ar.replica_server_name AS [replica_instance_name]
, drs.truncation_lsn , drs.log_send_queue_size
, drs.redo_queue_size
FROM sys.availability_groups ag
INNER JOIN sys.availability_replicas ar
ON ar.group_id = ag.group_id
INNER JOIN sys.dm_hadr_database_replica_states drs
ON drs.replica_id = ar.replica_id
INNER JOIN sys.databases d
ON d.database_id = drs.database_id
WHERE drs.is_local=0
ORDER BY ag.name ASC, d.name ASC, drs.truncation_lsn ASC, ar.replica_server_name ASC
Les mesures correctives peuvent inclure, sans s’y limiter, les actions suivantes :
Assurez-vous qu’il n’y a pas de goulot d’étranglement de ressources ou de performances au niveau
du secondaire.
Assurez-vous que le thread Redo n’est pas bloqué au niveau du secondaire. Utilisez l’événement
étendu pour identifier le moment où cela se produit et sur quels objets le lock_redo_blocked thread
de redo est bloqué.
Après avoir identifié la base de données secondaire qui se produit, essayez une ou plusieurs des méthodes
suivantes pour contourner ce problème temporairement :
Sortir la base de données du groupe de disponibilité pour le secondaire en cause.
NOTE
Cette méthode entraîne la perte du scénario haute disponibilité/récupération d’urgence pour le secondaire. Vous
de devez peut-être configurer à nouveau le groupe de disponibilité à l’avenir.
Si le thread de redéployage est fréquemment bloqué, désactivez la fonctionnalité en modifiant le

paramètre du Readable Secondary ALLOW_CONNECTIONS réplica sur SECONDARY_ROLE NON .
NOTE
Cela empêche les utilisateurs de lire les données dans le réplica secondaire qui est la cause première du blocage.
Une fois que la file d’attente de retour à la normale a été réduite à une taille acceptable, envisagez d’activer à
nouveau la fonctionnalité.
Activez le paramètre derow automatique s’il est désactivé et s’il y a de l’espace disque disponible.
Augmentez la valeur MaxSize pour le fichier journal des transactions s’il a été atteint et s’il y a de l’espace
disque disponible.
Ajoutez un fichier journal des transactions supplémentaire si le fichier actuel a atteint la valeur système
maximale de 2 To ou si de l’espace supplémentaire est disponible sur un autre volume disponible.
Pour plus d’informations sur la raison pour laquelle un journal des transactions augmente de façon
inattendue ou devient plein dans SQL Server, voir : Troubleshoot a Full Transaction Log (SQL Server Error
9002)
Pour plus d’informations sur le problème de blocage des opérations de redoin, voir : AlwaysON -
HADRON Learning Series: lock_redo_blocked/redo worker Blocked on Secondary Replica
Pour plus d’informations AVAILABILITY_REPLICA colonnes log_reuse_wait basées sur un journal, voir :
Facteurs qui peuvent retarder la troncation des journaux
Pour plus d’informations sur sys.dm_hadr_database_replica_states l’affichage, voir :
sys.dm_hadr_database_replica_states (Transact-SQL)
Pour plus d’informations sur la surveillance et le dépannage des modifications consignées qui n’arrivent
pas et ne sont pas appliquées en temps voulu, voir : Surveiller les performances pour les groupes de
disponibilité AlwaysOn
S’applique à
SQL Server 2017 Standard Windows
Résoudre les problèmes des bases de données de
disponibilité AlwaysOn dans l’état Récupération en
attente ou Suspect dans SQL Server
Cet article décrit les erreurs et les limitations d’une base de données de disponibilité dans Microsoft SQL Server
qui est dans un état ou dans un état et comment restaurer la base de données à toutes les fonctionnalités d’un
groupe de Recovery Pending Suspect disponibilité.
Résumé
Supposons qu’une base de données de disponibilité définie dans un groupe de disponibilité AlwaysOn passe à
un Recovery Pending ou à un état Suspect SQL Server. Si cela se produit sur le réplica principal du groupe de
disponibilité, la disponibilité de la base de données est affectée. Dans ce cas, vous ne pouvez pas accéder à la
base de données via les applications clientes. En outre, vous ne pouvez pas supprimer ou supprimer la base de
données du groupe de disponibilité.
Par exemple, supposons SQL Server est en cours d’exécution et qu’une base de données de disponibilité est
définie sur Recovery Pending l’état Suspect ou l’état. Lorsque vous interrogez les vues de gestion dynamique
(DMV) sur le réplica principal à l’aide du script SQL suivant, la base de données peut être signalée dans un état
ou dans un état comme suit NOT_HEALTHY RECOVERY_PENDING SUSPECT :
SELECT
dc.database_name,
d.synchronization_health_desc,
d.synchronization_state_desc,
d.database_state_desc
From
sys.dm_hadr_database_replica_states d
JOIN sys.availability_databases_cluster dc ON d.group_database_id = dc.group_database_id
AND d.is_local = 1
database_name synchronization_health_desc synchronization_state_desc database_state_desc

-------------------- ------------------------------ ------------------------------ ---------------------
<DatabaseName> NOT_HEALTHY NOT SYNCHRONIZING RECOVERY_PENDING
(1 row(s) affected)
En outre, cette base de données peut être signalée comme étant dans l’état Non synchronisé/Récupération
en attente ou Suspect dans SQL Server Management Studio.
Lorsque la base de données est définie dans un groupe de disponibilité, elle ne peut pas être abandonnée ou
restaurée. Par conséquent, vous devez prendre des mesures spécifiques pour récupérer la base de données et la
remettre en production.
Le contenu suivant décrit les erreurs et les limitations d’une base de données de disponibilité qui se trouve dans
un état En attente de récupération dans différentes situations.
L’état de la base de données empêche la restauration de la base de données
Vous essayez d’exécuter le script de SQL suivant afin de restaurer la base de données qui possède le
RECOVERY paramètre :
RESTORE DATABASE <DatabaseName> WITH RECOVERY
Lorsque vous exécutez ce script, vous recevez le message d’erreur suivant, car la base de données est
définie dans un groupe de disponibilité :

RESTORE ne peut pas fonctionner sur database DatabaseName, car il est configuré pour la mise en
miroir de base de données ou a rejoint un groupe de disponibilité. Si vous avez l’intention de
restaurer la base de données, utilisez ALTER DATABASE pour supprimer la mise en miroir ou la base
de données de son groupe de disponibilité.
RESTORE DATABASE se termine anormalement.
L’état de la base de données empêche la suppression de la base de données

Vous essayez d’exécuter le script de SQL suivant afin de déposer la base de données :
DROP DATABASE <DatabaseName>
Lorsque vous exécutez ce script, vous recevez le message d’erreur suivant, car la base de données est
définie dans un groupe de disponibilité :

La base de données DatabaseName est actuellement jointe à un groupe de disponibilité. Avant de
pouvoir supprimer la base de données, vous devez la supprimer du groupe de disponibilité.
L’état de la base de données empêche la suppression de la base de données du groupe de disponibilité

Vous essayez d’exécuter le script de SQL suivant pour supprimer la base de données du groupe de
disponibilité :
ALTER DATABASE <DatabaseName> SET hadr OFF
Lorsque vous essayez d’exécuter ce script, vous recevez le message d’erreur suivant, car la base de
données de disponibilité appartient au réplica principal :

DatabaseName ne peut pas être joint ou non au groupe de disponibilité AvailabilityGroupName.
Cette opération n’est pas prise en charge sur le réplica principal du groupe de disponibilité.
En raison de ce message d’erreur, vous pouvez être contraint de faire échouer la base de données. Une
fois la base de données échouée, le réplica propriétaire de la base de données de récupération en attente
est dans le rôle secondaire. Dans ce cas, essayez à nouveau d’exécuter le script SQL suivant afin de
supprimer la base de données du groupe de disponibilité sur le réplica secondaire :
ALTER DATABASE <DatabaseName> SET hadr OFF
Toutefois, vous ne pouvez toujours pas supprimer la base de données du groupe de disponibilité et vous
recevez le message d’erreur suivant, car la base de données est toujours dans l’état Récupération en
attente :
Msg 921, Level 16, State 112, Line 1

DatabaseName n’a pas encore été récupéré. Patientez et recommencez.
Résolution lorsque la base de données est dans le rôle secondaire

Pour résoudre ce problème, prenez les mesures générales suivantes :
Supprimez du groupe de disponibilité le réplica qui héberge la base de données endommagée lorsque la
base de données est dans le rôle secondaire.
Résolvez les problèmes qui affectent le système et qui peuvent avoir contribué à la défaillance de la base de
données.
Restituer le réplica au groupe de disponibilité.
Pour exécuter ces actions, connectez-vous au nouveau réplica principal, puis exécutez le script SQL pour
supprimer le réplica qui héberge la base de données de disponibilité ALTER AVAILABILITY GROUP qui a échoué.
Pour cela, procédez comme suit.
Ces étapes supposent que le réplica principal héberge d’abord la base de données endommagée. Par
conséquent, un failover doit d’abord se produire pour faire passer le réplica qui héberge la base de données
endommagée dans un rôle secondaire.
1. Connecter le serveur qui exécute SQL Server et qui héberge le réplica secondaire.
2. Exécutez le script SQL suivant :
ALTER AVAILABILITY GROUP <AvailabilityGroupName> FAILOVER
3. Exécutez le script SQL pour supprimer le réplica qui héberge la base de données endommagée du groupe
de disponibilité :
ALTER AVAILABILITY GROUP AvailabilityGroupName REMOVE REPLICA ON '<SQLServerNodeName>'
4. Résolvez tous les problèmes sur le serveur qui exécute SQL Server et qui peuvent contribuer à la
défaillance de la base de données.
5. Ajoutez de nouveau le réplica au groupe de disponibilité.
Résolution lorsque le réplica principal est le seul réplica dans le

groupe de disponibilité
Si le réplica principal héberge la base de données endommagée et est le seul réplica de travail dans le groupe de
disponibilité, le groupe de disponibilité doit être supprimé. Une fois le groupe de disponibilité supprimé, votre
base de données peut être récupérée à partir d’une sauvegarde, ou d’autres efforts de récupération d’urgence
peuvent être appliqués pour restaurer les bases de données et reprendre la production.
Pour abandonner le groupe de disponibilité, utilisez le script SQL suivant :
DROP AVAILABILITY GROUP <AvailabilityGroupName>
À ce stade, vous pouvez essayer de récupérer la base de données problématique. Vous pouvez également
restaurer la base de données à partir de la dernière copie de sauvegarde de bonne qualité connue.
Résolution lorsque vous déposez le groupe de disponibilité

Lorsque vous déposez un groupe de disponibilité, la ressource d’écoute est également abandonnée et
interrompt la connectivité des applications aux bases de données de disponibilité.
Pour réduire le temps mort de l’application, utilisez l’une des méthodes suivantes pour maintenir la connectivité
de l’application via l’écoute et abandonner le groupe de disponibilité :
Méthode 1 : associer l’écoute à un nouveau groupe de disponibilité (rôle ) dans le Gestionnaire du cluster
deover
Cette méthode vous permet de maintenir l’écoute tout en laissant et en recréant le groupe de disponibilité.
1. Sur l’instance SQL Server l’écoute du groupe de disponibilité existant dirige les connexions, créez un
groupe de disponibilité vide. Pour simplifier ce processus, utilisez la commande Transact-SQL pour créer
un groupe de disponibilité sans réplica secondaire ou base de données :
USE master
GO
CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH (
ENDPOINT_URL = 'tcp://sqlnode1:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL
)
2. Démarrez le Gestionnaire du cluster de failover, puis cliquez sur Rôles dans le volet gauche. Dans le volet
qui répertorie les rôles, sélectionnez le groupe de disponibilité d’origine.
3. Dans le volet du milieu inférieur sous l’onglet Ressources, cliquez avec le bouton droit sur la ressource du
groupe de disponibilité, puis cliquez sur Propriétés. Cliquez sur l’onglet Dépendances, supprimez la
dépendance à l’écoute, puis cliquez sur OK.
4. Sous les ressources, cliquez avec le bouton droit sur l’écoute, cliquez sur Autres actions, puis cliquez sur
Affecter à un autre rôle.
5. Dans la boîte de dialogue Affecter la source au rôle, sélectionnez le nouveau groupe de
disponibilité, puis cliquez sur OK.
6. Dans le volet Rôles, sélectionnez le nouveau groupe de disponibilité. Dans le volet du milieu inférieur,
sous l’onglet Ressources, vous devez maintenant voir le nouveau groupe de disponibilité et la ressource
d’écoute. Cliquez avec le bouton droit sur la nouvelle ressource de groupe de disponibilité, puis cliquez
sur Propriétés.
7. Cliquez sur l’onglet Dépendances, sélectionnez la ressource d’écoute dans la zone de dépôt, puis
cliquez sur OK.
8. Dans SQL Server Management Studio, utilisez l’Explorateur d’objets pour vous connecter à l’instance de
SQL Server qui héberge le réplica principal du nouveau groupe de disponibilité. Cliquez sur Haute
disponibilité AlwaysOn, cliquez sur le nouveau groupe de disponibilité, puis sur Écouteurs de
groupe de disponibilité. Vous devez trouver l’écoute.
9. Cliquez avec le bouton droit sur l’port d’écoute, cliquez sur Propriétés, tapez le numéro de port
approprié pour l’port d’écoute, puis cliquez sur OK.
Cela permet de s’assurer que les applications qui utilisent l’écoute peuvent toujours l’utiliser pour se connecter à
l’instance de SQL Server qui héberge les bases de données de production sans interruption. Le groupe de
disponibilité d’origine peut maintenant être complètement supprimé et re-créé. Les bases de données et les
réplicas peuvent également être ajoutés au nouveau groupe de disponibilité.
Si vous re-créez le groupe de disponibilité d’origine, vous devez réaffecter l’écoute au rôle de groupe de
disponibilité, configurer la dépendance entre la nouvelle ressource du groupe de disponibilité et l’port d’écoute,
puis réaffecter le port à l’écoute. Pour cela, procédez comme suit :
1. Démarrez le Gestionnaire du cluster de failover, puis cliquez sur Rôles dans le volet gauche. Dans le volet qui
répertorie les rôles, cliquez sur le nouveau groupe de disponibilité qui héberge l’écoute.
2. Dans le volet du milieu inférieur sous l’onglet Ressources, cliquez avec le bouton droit sur l’écoute, cliquez
sur Autres actions, puis cliquez sur Affecter à un autre rôle. Dans la boîte de dialogue, choisissez le groupe
de disponibilité re-créé, puis cliquez sur OK.
3. Dans le volet Rôles, cliquez sur le groupe de disponibilité re-créé. Dans le volet du milieu inférieur, sous
l’onglet Ressources, vous devez maintenant voir le groupe de disponibilité re-créé et la ressource d’écoute.
Cliquez avec le bouton droit sur la ressource de groupe de disponibilité re-créée, puis cliquez sur
Propriétés.
4. Cliquez sur l’onglet Dépendances, sélectionnez la ressource d’écoute dans la zone de dépôt, puis cliquez
sur OK.
5. Dans SQL Server Management Studio, utilisez l’Explorateur d’objets pour vous connecter à l’instance de SQL
Server qui héberge le réplica principal du groupe de disponibilité re-créé. Cliquez sur Haute disponibilité
AlwaysOn, cliquez sur le nouveau groupe de disponibilité, puis sur Écouteurs de groupe de
disponibilité. Vous devez trouver l’écoute.
6. Cliquez avec le bouton droit sur l’port d’écoute, cliquez sur Propriétés, tapez le numéro de port approprié
pour l’port d’écoute, puis cliquez sur OK.
Méthode 2 : associer l’écoute à une instance de cluster de SQL Server existante (SQLFCI )
Si vous hébergez votre groupe de disponibilité sur une instance SQL Server de clustering de failover (SQLFCI),
vous pouvez associer la ressource en cluster d’écoute au groupe de ressources en cluster SQLFCI pendant que
vous déposez et re-créez le groupe de disponibilité.
1. Démarrez le Gestionnaire du cluster de failover, puis cliquez sur Rôles dans le volet gauche.
2. Dans le volet qui répertorie les rôles, sélectionnez le groupe de disponibilité d’origine.
3. Dans le volet du milieu inférieur sous l’onglet Ressources, cliquez avec le bouton droit sur la ressource du
groupe de disponibilité, puis cliquez sur Propriétés.
4. Cliquez sur l’onglet Dépendances, supprimez la dépendance à l’écoute, puis cliquez sur OK.
5. Dans le volet du milieu inférieur sous l’onglet Ressources, cliquez avec le bouton droit sur l’écoute, cliquez
sur Autres actions, puis cliquez sur Affecter à un autre rôle.
6. Dans la boîte de dialogue Affecter une ressource au rôle, cliquez sur l’instance SQL Server FCI, puis
cliquez sur OK.
7. Dans le volet Rôles, sélectionnez le groupe SQLFCI. Dans le volet du milieu inférieur, sous l’onglet
Ressources, vous devez maintenant voir la nouvelle ressource d’écoute.
Cela permet de s’assurer que les applications qui utilisent l’écoute peuvent toujours l’utiliser pour se connecter à
l’instance de SQL Server qui héberge les bases de données de production sans interruption. Le groupe de
disponibilité d’origine peut maintenant être supprimé et re-créé. Les bases de données et les réplicas peuvent
également être ajoutés au nouveau groupe de disponibilité.
Une fois le groupe de disponibilité re-créé, réaffectez l’écoute au rôle de groupe de disponibilité. Ensuite,
définissez la dépendance entre la nouvelle ressource de groupe de disponibilité et l’port d’écoute, puis
réaffectez le port à l’port d’écoute :
1. Démarrez le Gestionnaire du cluster de failover, puis cliquez sur Rôles dans le volet gauche.
2. Dans le volet qui répertorie les rôles, cliquez sur le rôle SQLFCI d’origine.
3. Dans le volet du milieu inférieur, sous l’onglet Ressources, cliquez avec le bouton droit sur l’écoute, cliquez
sur Autres actions, puis cliquez sur Affecter à un autre rôle.
4. Dans la boîte de dialogue, cliquez sur le groupe de disponibilité re-créé, puis cliquez sur OK.
5. Dans le volet Rôles, sélectionnez le nouveau groupe de disponibilité.
6. Sous l’onglet Ressources, vous devriez voir le nouveau groupe de disponibilité et la ressource d’écoute.
Cliquez avec le bouton droit sur la nouvelle ressource de groupe de disponibilité, puis cliquez sur
Propriétés.
7. Cliquez sur l’onglet Dépendances, sélectionnez la ressource d’écoute dans la zone de dépôt, puis cliquez
sur OK.
8. Dans SQL Server Management Studio, utilisez l’Explorateur d’objets pour vous connecter à l’instance de SQL
Server qui héberge le réplica principal du nouveau groupe de disponibilité.
9. Cliquez sur Haute disponibilité AlwaysOn, cliquez sur le nouveau groupe de disponibilité, puis sur
Écouteurs de groupe de disponibilité. Vous devez trouver l’écoute.
10. Cliquez avec le bouton droit sur l’port d’écoute, cliquez sur Propriétés, tapez le numéro de port approprié
pour l’port d’écoute, puis cliquez sur OK.
Méthode 3 : drop the availability group, and then re -create the availability group and listener with the same
listener name
Cette méthode entraîne une petite panne pour les applications qui sont actuellement connectées, car le groupe
de disponibilité et l’écoute sont supprimés, puis re-créés :
1. Déposez le groupe de disponibilité.
NOTE
Cela permet également de déposer l’écoute.
2. Créez immédiatement un groupe de disponibilité vide qui inclut la définition de l’écoute, sur le serveur
qui héberge les bases de données de production.
Par exemple, supposons que l’écoute de votre groupe de disponibilité soit une aglisten. L’instruction
Transact-SQL suivante crée un groupe de disponibilité sans base de données principale ou secondaire,
mais elle crée également un listener nommé aglisten. Les applications peuvent utiliser ce listener pour se
connecter.
USE master
GO
CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH (
ENDPOINT_URL = 'tcp://sqlnode1:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL
) LISTENER 'aglisten' (
WITH IP ((N'11.0.0.25', N'255.0.0.0')),
PORT = 1433
)
GO
3. Récupérez la base de données endommagée. Ensuite, ajoutez-le et le réplica secondaire au groupe de

disponibilité.
Le délai se produit lorsque vous vous connectez à
un SQL Server de disponibilité AlwaysOn 2012
Cet article vous aide à résoudre le problème qui se produit lorsque vous vous connectez à un SQL Server de
groupe de disponibilité AlwaysOn 2012 dans un environnement multi-sous-réseau.
Version du produit d’origine : SQL Server 2012 Developer, SQL Server 2012 Enterprise, SQL Server 2012
Express, SQL Server 2012 Standard, SQL Server 2012 Web, SQL Server 2012 Enterprise Core
Symptômes
Après avoir configuré l’listener du groupe de disponibilité pour un groupe de disponibilité AlwaysOn dans
Microsoft SQL Server 2012, il se peut que vous ne soyez pas en mesure d’envoyer un ping à l’écoute ou de vous
y connecter à partir d’une application.
Par exemple, lorsque vous essayez de vous connecter à un SQL Server à l’aide de , la connexion SQLCMD est hors
de l’attente. En outre, vous recevez un message d’erreur semblable à ce qui suit :
Sqlcmd : Erreur : Microsoft SQL Native Client : le délai d’expiration de la connexion a expiré.
NOTE
Ces symptômes sont généralement intermittents ou concernent le changement de la ressource du groupe de
disponibilité.
La capture d’écran suivante montre un exemple de ce qui se produit lorsque vous essayez d’envoyer un test ping
à l’écoute pour la disponibilité de aglisten . La capture d’écran montre également une connexion SQL Server à
l’aide de la commande lorsque vous incluez le paramètre deover SQLCMD de plusieurs sous-réseaux. -M
NOTE
Vous pouvez utiliser la commande avec le paramètre comme indiqué dans la capture d’écran pour vous SQLCMD -M
connecter à l’écoute.
Cause
Ce problème se produit parce que votre application utilise un fournisseur de données hérité qui ne prend pas en
charge le nouveau paramètre ou n’est pas configuré MultiSubnetFailover pour utiliser ce paramètre.
Ce paramètre est pris en charge dans les versions plus récentes du pilote SQLClient qui est inclus avec le .NET
Framework 4 et avec les versions ultérieures du .NET Framework, et est de nouveau porté vers le .NET
Framework 3.5.
NOTE
La commande est un outil de test de connectivité simple qui ne prend pas en PING charge le nouveau paramètre.
Résolution
Vous pouvez utiliser l’une des résolutions suivantes selon votre cas :
Pour résoudre cette situation lorsque les fournisseurs de données prendre en charge le paramètre,
ajoutez le paramètre à votre chaîne de connexion et définissez-le MultiSubNetFailover
MultiSubNetFailover sur true .
Pour résoudre cette situation lorsque vos clients hérités ne peuvent pas utiliser la propriété, vous pouvez
modifier la valeur de MultiSubnetFailover l’écoute RegisterAllProvidersIP sur 0 . Pour ce faire, exécutez
la commande suivante à partir de l Windows PowerShell interface de ligne de commande suivante :
Import-Module FailoverClusters
Get-ClusterResource <*Your listener name*>|Set-ClusterParameter RegisterAllProvidersIP 0
NOTE
Une fois la valeur définie sur 0, l’adresse IP en ligne actuelle doit être désins inscrite à partir du serveur DNS et l’adresse IP
hors connexion doit être inscrite sur le serveur DNS lorsqu’un failover se RegisterAllProvidersIP produit. Cela peut
entraîner un retard de connexion pour le prochain failover.
Lorsque vous essayez de vous connecter à un répondeur défini sur plusieurs sous-réseaux, l’opération peut
échouer si le pilote client tente de se connecter à l’aide de l’une des adresses IP hors connexion de l’écoute.
Lorsqu’un listener est créé, une adresse IP est désignée pour chaque sous-réseau unique où un réplica de
groupe de disponibilité est hébergé. Par exemple, si un listener est créé pour un groupe de disponibilité qui
possède des réplicas qui existent dans deux sous-réseaux, deux adresses IP sont définies dans l’écoute. Une
adresse est utilisée par une application qui peut se connecter à une instance de SQL Server dans le sous-réseau
1, et l’autre adresse est utilisée lorsqu’une application se connecte à une instance de SQL Server dans le sous-
réseau 2.
En arrière-plan, l’écouteur crée une ressource Windows point d’accès client de cluster. L’une de ses propriétés
RegisterAllProvidersIP est . Lorsqu’un listener est créé, il est définie sur 1 et toutes les adresses IP de l’écoute
sont enregistrées dans le serveur DNS. Cette configuration permet de réduire le temps de reconnexion pour les
clients.
Étant donné que l’enregistrement DNS contient toutes les adresses IP, un client qui tente de se connecter à
l’écoute doit savoir comment gérer cette situation. Le paramètre permet au pilote client d’essayer les connexions
en parallèle à toutes les MultiSubnetFailover adresses IP de l’écoute. Sans ce paramètre, le pilote client essaiera
de se connecter de manière séquentielle à toutes les MultiSubnetFailover adresses IP de l’écoute. Les
connexions séquentielles peuvent entraîner un long délai d’connexion ou de connexion.
NOTE
Le problème mentionné dans cet article affecte également les environnements SharePoint configurés pour utiliser le
réplica en lecture seule secondaire d’un groupe de disponibilité AlwaysOn. Pour résoudre ce problème, effectuez l’une des
actions suivantes s’applique à votre version de SharePoint :
Pour SharePoint 2007 : il s’agit d’une application héritée. Par conséquent, SharePoint 2007 ne peut pas
être configuré pour utiliser le MultiSubnetFailover paramètre. À la place, vous devez utiliser la
commande Windows PowerShell décrite dans la section Résolution.
Pour SharePoint 2010 : les packages de mise à jour cumulative sont désormais disponibles et ajoutent la
prise en charge du MultiSubnetFailover paramètre. Pour plus d’informations sur les packages de mise à
jour, consultez l’article suivant :
Une mise à jour introduit la prise en charge des fonctionnalités AlwaysOn dans SQL Server 2012
ou une version ultérieure pour .NET Framework 3.5 SP1
Description du package SharePoint Foundation 2010 (Wss-x-none.msp) : 30 octobre 2012
Références
Délais d’attente de connexion lorsque vous utilisez l’listener de groupe de disponibilité AlwaysOn avec le
paramètre MultiSubnetFailover
Utilitaire sqlcmd
Prise en charge de SqlClient pour la haute disponibilité, récupération d’urgence
Une mise à jour introduit la prise en charge des fonctionnalités AlwaysOn dans SQL Server 2012 ou une
version ultérieure pour .NET Framework 3.5 SP1
SQL Server notes de publication de 2012
Créer ou configurer un listener de groupe de disponibilité (SQL Server)
SQL Server Clustering multi-sous-réseaux (SQL Server)
Délai de connexion dans le groupe de disponibilité multi-sous-réseau
L’exécution des requêtes prend plus de temps SQL
Server réplicas secondaires Always On
Cet article vous aide à résoudre le problème de problèmes de performances des requêtes sur les réplicas
secondaires en lecture seule.
Symptômes
Supposons que vous avez une base Microsoft SQL Server de données membre du groupe de disponibilité
Always On qui contient une ou plusieurs tables de grande taille qui ont un clustered row-store index. Une
requête d’une ou de plusieurs tables de grande taille se termine plus rapidement sur le réplica principal que sur
un réplica secondaire.
Notes
La requête entraîne une analyse d’index en cluster d’une grande partie de la table.
La requête utilise l’indication NOLOCK.
Les opérateurs de plan d’exécution et l’ordre des opérateurs sont identiques pour les exécutions rapides et
lentes.
L’interrogation sys.dm_db_index_physical_stats révèle une fragmentation significative de l’index en cluster.
L’unjoining the database from the Always On Availability Group improves performance on the same (former)
secondary replica instance, so that it is similar to performance on the primary replica.
Cause
Lorsque l’isolation de capture instantanée est appliquée, les conseils NOLOCK sont ignorés. La différence de
durée d’exécution entre les réplicas principaux et secondaires se produit car l’indication NOLOCK est ignorée
sur le réplica secondaire en lecture seule où l’isolation de capture instantanée est appliquée, mais pas sur le
réplica principal où l’isolation de capture instantanée n’est pas appliquée par défaut. Cela entraîne l’application
de l’ordre de clé sur le réplica secondaire pour l’analyse de l’index en cluster. Sur le réplica principal, l’indication
NOLOCK est prioritaire et affecte le comportement. Lorsque l’index en cluster est hautement fragmenté,
l’application de l’ordre de clé pour l’analyse sur le réplica secondaire en lecture seule entraîne l’émission de SQL
Server sur une seule page. Toutefois, sur le réplica principal, SQL Server analyse une unité d’allocation pour lire
plusieurs pages par demande d’IO.
Résolution
Pour résoudre ce problème, ré reconstruire l’index sur le réplica principal. Cette opération se propage ensuite
aux réplicas secondaires. Pour plus d’informations, voir Recommandations maintenance d’index avec les
groupes de disponibilité AlwaysOn.
Les informations statistiques réelles sur les opérations d’exécution et le plan d’exécution peuvent ne pas aider au
diagnostic SET STATISTICS IO lorsque ce problème se produit. Celles-ci vous donnent des informations sur le
nombre de pages lues, mais pas sur le nombre d’opérations d’IO pour lire les pages.
Au lieu de cela, recherchez d’abord la fragmentation de l’index en cluster. En outre, vous pouvez collecter les
compteurs de processus Opérations de lecture des opérations d’O de l’observateur de performances/s et
Octets/s deux fois lorsque vous exécutez la requête avec la base de données dans le groupe de disponibilité, et à
nouveau à partir de la même instance lorsque la base de données est supprimée du groupe de disponibilité et
mise en ligne. Si la fragmentation de l’index provoque des lectures sur une seule page sur le réplica secondaire,
mais pas sur le réplica principal, vous vous attendez à voir un plus grand nombre d’IO/s de lecture/s et un plus
petit nombre d’octets de lecture/s lorsque la base de données se trouve dans le groupe de disponibilité par
rapport à ce qui n’est pas le cas.
En outre, ce comportement peut se produire, mais pas de manière significative dans tous les environnements.
Par exemple, un sous-système d’entrée/heure qui peut gérer l’augmentation du niveau d’entrée/seconde avec
une latence minimale et un débit similaire peut permettre à ce problème de passer à travers le monde.
Résolution des problèmes deover automatique dans
SQL Server environnements AlwaysOn
Cet article vous aide à résoudre les problèmes qui se produisent lors du SQL Server.
Résumé
Microsoft SQL Server Les groupes de disponibilité AlwaysOn peuvent être configurés pour le failover
automatique. Par conséquent, si un problème d’état d’santé est détecté sur l’instance de SQL Server qui héberge
le réplica principal, le rôle principal peut être transitioné vers le partenaire de transfert automatique (réplica
secondaire). Toutefois, le réplica secondaire ne peut pas toujours être transitioné vers le rôle principal, mais
uniquement vers le rôle de résolution. À moins que le réplica principal ne retourne dans un état sain, il n’y a pas
de réplica dans le rôle principal. En outre, les bases de données de disponibilité sont inaccessibles.
Cet article répertorie certaines causes courantes de l’échec du failover automatique. En outre, cet article décrit
les étapes que vous pouvez effectuer pour diagnostiquer la cause de ces échecs.
Symptômes du déclenchement réussi d’un failover automatique

Lorsqu’un changement automatique est déclenché sur l’instance de SQL Server qui héberge le réplica principal,
le réplica secondaire passe au rôle de résolution, puis au rôle principal. En outre, vous recevez des messages
d’erreur dans le SQL Server journal de connexion qui ressemblent à ce qui suit :
L’état du réplica de disponibilité locale dans le groupe de disponibilité ' ' est devenu « RESOLVING_NORMAL
» <Group name> à « PRIMARY_PENDING »
L’état du réplica de disponibilité locale dans le groupe de disponibilité ' ' est devenu « <Group name>
PRIMARY_PENDING » à « PRIMARY_NORMAL »
NOTE
Le réplica secondaire passe d’un état RESOLVING_NORMAL à un état PRIMARY_NORMAL’état.
Symptômes en cas d’échec duover automatique

Si un événement de changement automatique échoue, le réplica secondaire ne passe pas au rôle principal. Par
conséquent, le réplica de disponibilité signale que ce réplica est en état de résolution. En outre, les bases de
données de disponibilité indiquent qu’elles ne sont pas en état de synchronisation et que les applications ne
peuvent pas accéder à ces bases de données.
Par exemple, dans l’image suivante, SQL Server Management Studio signale que le réplica secondaire est en état
de résolution car le processus de transfert automatique n’a pas pu faire passer le réplica secondaire au rôle
principal :
Cet article décrit plusieurs raisons possibles pour lesquelles le failover automatique peut échouer et comment
diagnostiquer chaque cause.
Cas 1 : la valeur « Nombre maximal d’échecs dans la période spécifiée

» est épuisée
Le groupe de disponibilité possède Windows propriétés de ressource de cluster, telles que le nombre maximal
d’échecs dans la propriété Période spécifiée. Cette propriété permet d’éviter le déplacement indéfini d’une
ressource en cluster en cas d’échec de plusieurs nœuds.
Pour déterminer et diagnostiquer s’il s’agit de la cause de l’échec du Windows, consultez le journal du cluster
Windows (Cluster.log), puis vérifiez la propriété. Pour cela, procédez comme suit :
Étape 1 : Passer en revue les données du journal Windows cluster (Cluster.log)
1. Utilisez Windows PowerShell pour générer le journal Windows cluster sur le nœud de cluster qui
héberge le réplica principal. Pour ce faire, exécutez l’cmdlet suivante dans une fenêtre PowerShell
avec élévation de SQL Server qui héberge le réplica principal :
Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
NOTE
Le paramètre -TimeSpan 15 de cette étape est utilisé dans l’hypothèse que le problème en cours de
diagnostic s’est produit au cours des 15 minutes précédentes.
Par défaut, le fichier journal est créé dans %WINDIR%\cluster\reports.
2. Ouvrez le fichier Cluster.log dans Bloc-notes pour passer en revue le journal Windows cluster.
3. Cliquez sur Modifier Bloc-notes, puis sur Rechercher, puis recherchez la chaîne « failoverCount »
à la fin du fichier. Examinez les résultats et vous devez trouver un message qui ressemble à ce qui
suit :
Sans faire échouer le groupe <Resource name> , failoverCount 3, failoverThresholdSetting

<Number> , computedFailoverThreshold 2
Étape 2 : Vérifier le nombre maximal d’échecs dans la propriété Period spécifiée

1. Démarrez le Gestionnaire du cluster de failover.
2. Dans le volet de navigation, cliquez sur Rôles.
3. Dans le volet Rôles, cliquez avec le bouton droit sur la ressource en cluster, puis cliquez sur
Propriétés.
4. Cliquez sur l’onglet Failover et vérifiez le nombre maximal d’échecs dans la valeur Période
spécifiée.
NOTE
Le comportement par défaut spécifie que si la ressource en cluster échoue trois fois sur une période de six
heures, elle doit rester dans l’état d’échec. Pour un groupe de disponibilité, cela signifie que le réplica est
laissé dans l’état RÉSOLUTION.
Conclusion
Après avoir analysé le journal, vous constatez que la valeur de failoverCount de 3 est supérieure à la valeur
computedFailoverThreshold de 2. Par conséquent, Windows cluster de disponibilité ne peut pas terminer
l’opération deover de la ressource du groupe de disponibilité pour le partenaire deover.
Résolution
Pour résoudre ce problème, augmentez le nombre maximal d’échecs dans la valeur de période spécifiée.
NOTE
L’augmentation de cette valeur risque de ne pas résoudre le problème. Il peut y avoir un problème plus critique qui
entraîne l’échec du groupe de disponibilité plusieurs fois sur une courte période, qui est de 15 minutes par défaut.
L’augmentation de cette valeur peut uniquement provoquer l’échec du groupe de disponibilité plus de fois avant de rester
dans un état d’échec. Nous vous recommandons de faire un effort de dépannage agressif pour déterminer pourquoi le
changement automatique se produit toujours.
Cas 2 : Autorisations de compte NT insuffisantes\Autorisations de

compte SYSTÈME
La SQL Server Moteur de base de données ressource DLL se connecte à l’instance de SQL Server qui héberge le
réplica principal à l’aide d’ODBC afin de surveiller l’état d’état. Les informations d’identification d’ouverture de
session utilisées pour cette connexion sont SQL Server compte de connexion NT AUTHORITY\SYSTEM. Par
défaut, ce compte de connexion local se vu accorder les autorisations suivantes :
Modifier un groupe de disponibilité
Connecter SQL
Afficher l’état du ser veur
Si le compte de connexion NT AUTHORITY\SYSTEM ne dispose d’aucune de ces autorisations sur le partenaire
de changement automatique (réplica secondaire), SQL Server ne peut pas démarrer la détection de l’état d’état
lorsqu’un changement automatique se produit. Par conséquent, le réplica secondaire ne peut pas passer au rôle
principal. Pour déterminer et diagnostiquer s’il en est la cause, examinez le journal Windows cluster. Pour cela,
procédez comme suit :
1. Utilisez Windows PowerShell pour générer le journal Windows cluster sur le nœud du cluster. Pour ce
faire, exécutez l’cmdlet suivante dans une fenêtre PowerShell avec élévation de niveaux sur l’instance de
SQL Server qui héberge le réplica secondaire qui n’a pas été transitionn dans le rôle principal :
Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
2. Ouvrez le fichier Cluster.log dans Bloc-notes pour passer en revue le journal Windows cluster.
3. Vous pouvez trouver des messages d’erreur qui ressemblent à ce qui suit :
Échec de l’exécuter. L’utilisateur n’est pas autorisé à effectuer cette action.

Conclusion
Le fichier Cluster.log signale qu’il existe un problème d’autorisation SQL Server exécute la commande de
diagnostic. Dans cet exemple, l’échec est dû à la suppression de l’autorisation d’état du serveur d’affichage du
compte de connexion NT AUTHORITY\SYSTEM sur l’instance de SQL Server qui héberge le réplica secondaire
d’une paire deover automatique.
Résolution
Pour résoudre ce problème, accordez des autorisations suffisantes au compte de connexion NT
AUTHORITY\SYSTEM pour la détection d’SQL Server Moteur de base de données DLL de la ressource.
Cas 3 : les bases de données de disponibilité ne sont pas

synchronisées
Pour que le système soit automatiquement mis en panne, toutes les bases de données de disponibilité définies
dans le groupe de disponibilité doivent être synchronisées entre le réplica principal et le réplica secondaire.
Lorsqu’un failover automatique se produit, cette condition de synchronisation doit être remplie pour s’assurer
qu’il n’y a aucune perte de données. Par conséquent, si une base de données de disponibilité dans le groupe de
disponibilité est synchronisée ou n’est pas synchronisée, le transfert automatique ne réussira pas à faire passer
le réplica secondaire au rôle principal.
Pour plus d’informations sur les conditions requises pour un failover automatique, voir les conditions requises
pour une section Deover automatique et les réplicas de validation synchrone prise en charge deux sections de
paramètres de l’article : Les modes de failover et de failover (groupesde disponibilité Always On).
Pour déterminer et diagnostiquer s’il s’agit de la cause de l’échec du SQL Server journal des erreurs. Vous devez
trouver un message d’erreur semblable à ce qui suit :
Une ou plusieurs bases de données ne sont pas synchronisées ou n’ont pas rejoint le groupe de disponibilité
Pour vérifier si les bases de données de disponibilité ont l’état SYNCHRONISÉ, suivez les étapes suivantes :
1. Connecter au réplica secondaire.
2. Exécutez le script SQL suivant afin de vérifier la valeur de toutes les bases de données de disponibilité du
groupe de disponibilité qui n’ont is_failover_ready pas été échouées.
NOTE
Une valeur nulle pour l’une des bases de données de disponibilité peut empêcher le failover automatique, et cette
valeur indique que la base de données de disponibilité n’a pas été SYNCHRONISÉe.
Select database_name, is_failover_ready from sys.dm_hadr_database_replica_cluster_states where

replica_id in (select replica_id from sys.dm_hadr_availability_replica_states)
Conclusion
Pour que le groupe de disponibilité soit réussi, toutes les bases de données de disponibilité doivent être à
SYNCHRONIZED l’état. Pour plus d’informations sur les modes de disponibilité, ez le lien suivant :
Modes de disponibilité dans les groupes de disponibilité AlwaysOn
Cas 4 : Impossible de faire échouer, la configuration « Forcer le

chiffrement de protocole » a été sélectionnée pour les protocoles
clients
Pour vérifier cette configuration :
1. Lancez Gestionnaire de configuration SQL Server.
2. Dans le volet gauche, cliquez avec le bouton droit sur SQL Native Client configuration 11.0 et choisissez
Propriétés.
3. In dialog check Force Encr yption , if set to Yes , change to No .
4. Testez à nouveau leoverover.
Conclusion
SQL Server La surveillance de l’état AlwaysOn utilise une connexion ODBC locale pour surveiller SQL
Server’état. Le chiffrement par protocole de force doit être activé uniquement dans la section Configuration du
client de Gestionnaire de configuration SQL Server, si SQL Server lui-même a été configuré pour forcer le
chiffrement dans Gestionnaire de configuration SQL Server sous la section Configuration du réseau S QL
Ser ver. Pour plus d’informations, voir : Activer les connexions chiffréesau Moteur de base de données .
Résoudre les problèmes SQL Server AlwaysOn
Cet article vous aide à résoudre le problème courant de configuration AlwaysOn sur SQL serveur.
NOTE
Pour une visite guidée de l’expérience de cet article, voir Résolution des problèmes SQL Server problèmes AlwaysOn.
Enterprise
Quels sont les problèmes auxquels vous êtes confronté ?

Les données CSS de Microsoft indiquent qu’un pourcentage significatif de problèmes de clients est
souvent traité précédemment dans une mise à jour un jour publiée, mais qu’il n’est pas appliqué de
manière proactive et recommande donc l’installation continue et proactive des CUS dès qu’elles sont
disponibles. Pour plus d’informations, voir : Annonce des mises à jour du SQL Server de maintenance
incrémentielle (ISM).
Pour vérifier les dernières UTIL disponibles pour votre version, voir : Comment déterminer la version,
l’éditionet le niveau de mise à jour de SQL Server et ses composants .
Vous pouvez consulter les outils utiles de dépannage et de surveillance des groupes de disponibilité
AlwaysOn dans le Guide de dépannage et de surveillance des groupes de disponibilité AlwaysOn pour en
savoir plus sur les outils que vous pouvez utiliser pour diagnostiquer différents types de problèmes et
pour surveiller les groupes de disponibilité. Le guide propose également des scénarios supplémentaires
qui peuvent ne pas être abordés dans cette visite guidée.
Nœud parent de la documentation des groupes de disponibilité AlwaysOn et fournit une référence
d’arrêt pour diverses questions, voir : Groupes de disponibilité AlwaysOn (SQL Server).
J’ai besoin de pointeurs sur la configuration des groupes de

disponibilité AlwaysOn
Si vous recherchez de la documentation sur la configuration AlwaysOn, consultez les documents suivants :
Getting Started with AlwaysOn Availability Groups (SQL Server) - The document provides answers to many
questions you may have related to Availability groups, setup etc. Le fait de suivre toutes les étapes de ce
document et de passer en revue les conditions préalables, les restrictions et les Recommandations pour les
groupes de disponibilité AlwaysOn (SQL Server) permettra d’éviter de nombreux problèmes que vous pouvez
être en mesure d’exécuter avec la configuration et la maintenance de groupes de disponibilité dans votre
environnement.
Ressources supplémentaires
Étape par étape : création d’SQL Server de disponibilité AlwaysOn 2012
Guides d’architecture AlwaysOn
Lien externe : SQL Server groupes de disponibilité AlwaysOn
Si ces informations ne sont pas utiles, consultez les informations supplémentaires sur les groupes de
disponibilité AlwaysOn.
J’ai des difficultés à configurer des groupes de disponibilité AlwaysOn

Les groupes de disponibilité AlwaysOn sont en général désactivés, les comptes sont configurés de manière
incorrecte, le point de terminaison de mise en miroir de base de données n’existe pas, le point de terminaison
est inaccessible (SQL Server Erreur 1418), l’accès réseau n’existe pas et une commande de jointage de base de
données échoue (SQL Server Erreur 35250). Examinez le document suivant pour obtenir de l’aide sur la
résolution de ces problèmes :
Résoudre les problèmes de configuration des groupes de disponibilité AlwaysOn (SQL Server)
Liens supplémentaires : Corriger : Erreur 41009 lorsque vous essayez de créer plusieurs groupes de disponibilité
Si le problème existe toujours, consultez plus d’informations sur les groupes de disponibilité AlwaysOn.
J’ai des problèmes avec la configuration de l’écoute (19471, 19476 et

autres erreurs)
L’un des problèmes de configuration les plus courants rencontrés par les clients est la création d’un listener de
groupe de disponibilité. Les erreurs sont similaires à ce qui suit :
Msg 19471, Level 16, State 0, Line 2The WSFC cluster could not bring the Network Name resource
with DNS name '' online. Le nom DNS peut avoir été pris ou être en conflit avec les services de noms
existants, ou le service de cluster WSFC n’est peut-être pas en cours d’exécution ou peut être
inaccessible. Utilisez un autre nom DNS pour résoudre les conflits de noms ou consultez le journal du
cluster WSFC pour plus d’informations.
Msg 19476, Level 16, State 4, Line 2The attempt to create the network name and IP address for the
listener failed. Le service WSFC peut ne pas être en cours d’exécution ou inaccessible dans son état
actuel, ou les valeurs fournies pour le nom du réseau et l’adresse IP peuvent être incorrectes. Vérifiez
l’état du cluster WSFC et validez le nom du réseau et l’adresse IP auprès de l’administrateur réseau.
La plupart du temps, l’échec de création de l’écoute qui a entraîné les messages ci-dessus est dû à un manque
d’autorisations pour l’objet CNO (Cluster Name Object) dans Active Directory pour créer et lire l’objet ordinateur
d’écoute. Pour résoudre ce problème, consultez les articles suivants :
Échec de la création d’un répondeur avec le message « Le cluster WSFC n’a pas pu mettre en ligne la
ressource Nom du réseau »
Résolution des problèmes de création d’un listener de groupe de disponibilité AlwaysOn SQL Server
2012
Configurer un listener pour un groupe de disponibilité Always On
Le failover automatique ne fonctionne pas comme prévu

Si vous remarquez que le failover automatique ne fonctionne pas comme prévu pendant le test ou en
production, voir : Résolution des problèmes de failover automatique dans les environnements AlwaysOn SQL
Server 2012.
Une configuration incorrecte du nombre maximal d’échecs dans la période spécifiée est l’une des principales
causes pour que le principal ne passe pas automatiquement au secondaire. La valeur par défaut de ce paramètre
est N-1, où N est le nombre de réplicas. Pour plus d’informations, voir : Limite maximale d’échecs du cluster de
failover (groupe).
J’ai des problèmes de connexion aux groupes de disponibilité

AlwaysOn
Après avoir configuré l’écoute de groupe de disponibilité pour un groupe de disponibilité AlwaysOn dans SQL
Server 2012, il se peut que vous ne soyez pas en mesure d’envoyer un ping à l’écoute ou de vous y connecter à
partir d’une application. Vous pouvez obtenir une erreur semblable à celle-ci :
Sqlcmd : Erreur : Microsoft SQL Native Client : le délai d’expiration de la connexion a expiré.
Pour résoudre ce problème et les erreurs similaires, examinez les questions suivantes :
Erreur de délai et vous ne pouvez pas vous connecter à un SQL Server de groupe de disponibilité AlwaysOn
2012 dans un environnement amulti-subnet
Délai de connexion dans le groupe de disponibilité multi-sous-réseau
Liens d’informations supplémentaires :
Une mise à jour introduit la prise en charge des fonctionnalités AlwaysOn dans SQL Server 2012 ou une
version ultérieure pour the.NET Framework 3.5 SP1
SQL Server Clustering multi-sous-réseaux (SQL Server)
J’ai des problèmes lors de la configuration des groupes de

disponibilité AlwaysOn dans ma VM Azure (IaaS)
1. De nombreux problèmes liés à AlwaysOn se produisent en raison d’une configuration incorrecte de
l’écoute. Si vous avez des problèmes de connexion à l’écoute,
a. Veillez à lire toutes les limitations de l’écoute ILB et à suivre toutes les étapes documentées dans
l’article suivant en vous intéressant particulièrement à la configuration des dépendances, à
l’adresse IP et à divers autres paramètres du script PowerShell.
b. Si vous n’êtes pas sûr, vous pouvez supprimer et recréer l’écoute comme dans le document ci-
dessus.
2. Si vous avez récemment déplacé votre VM vers un autre service ou si les adresses IP ont changé, vous
devez mettre à jour la valeur de la ressource d’adresse IP pour refléter la nouvelle adresse et recréer le
point de terminaison à charge équilibrée pour votre ag. Vous pouvez mettre à jour l’adresse IP à l’aide des
commandes Get / Set comme suit :
Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"
Documents recommandés :
Configurer un équilibreur de charge pour un groupe SQL Server de disponibilité Always On dans des
machines virtuelles Azure
Recommandations et meilleures pratiques lors du déploiement SQL Server groupes de disponibilité
AlwaysOn dans Microsoft Azure (IaaS)
Le passage du principal au secondaire prend beaucoup de temps, ou

inversement.
Après un failover automatique ou un failover manuel planifié sans perte de données sur un groupe de
disponibilité, il se peut que vous trouviez que le temps de récupération dépasse votre objectif de temps de
récupération (RTO). Pour résoudre les causes et les résolutions potentielles, voir : Résolution des problèmes : Le
groupe de disponibilité a dépassé le RTO.
Les modifications apportées au réplica principal ne sont pas reflétées

ou ralenties pour être répliquées vers le réplica secondaire.
Vous remarquerez peut-être que les modifications apportées au réplica principal ne sont pas propagées en
secondaire en temps voulu. Pour résoudre ces problèmes, essayez les éléments suivants :
Pour les environnements SQL Server 2012 et SQL Server 2014, voir : CORRECTIF : Synchronisation lente
lorsque les disques ont des tailles de secteur différentes pour les fichiers journaux de réplica principal et
secondaire dans les environnements SQL Server AG et Logshipping.
Vérifiez si les nodes secondaires sont dans un état Suspendu dans l’administrateur de cluster.
Review this Troubleshooting article: Troubleshoot: Changes on the Primary Replica are not Reflected on
the Secondary Replica.
Comment gérer la taille du journal des transactions pour mes bases

de données AG
Vous pouvez réduire la taille des journaux de transactions en configurant des sauvegardes régulières sur des
serveurs principaux ou secondaires.
Pour plus d’informations, examinez les rubriques suivantes :
Décharger les sauvegardes prise en charge vers les réplicas secondaires d’un groupe de disponibilité
Effectuer des sauvegardes du journal des transactions à l’aide du groupe de disponibilité AlwaysOn Read-
Only réplicas secondaires - Partie 1
Si ces informations ne sont pas utiles, consultez les informations supplémentaires sur les groupes de
disponibilité AlwaysOn.
Les serveurs principaux ou secondaires se sont déférés dans l’état de

résolution ou vous faites face à des changements inattendus
Vérifiez les journaux des événements système et d’application pour les problèmes matériels et d’autres
erreurs et travaillez avec le fournisseur pour les résoudre.
Si vous utilisez des ordinateurs virtuels, vérifiez leur base de connaissances pour voir s’il existe des
problèmes récemment signalés qui peuvent contribuer au problème. Par exemple, une perte de paquets
importante au niveau du système d’exploitation invité sur la vNIC VMXNET3 dans ESXi (2039495) a
provoqué des problèmes avec la configuration ag.
Plus d’informations :
Diagnostiquer un échec inattendu ou un groupe de disponibilité en état DE RÉSOLUTION
Lien externe : SQL SERVER - Groupe de disponibilité AlwaysOn bloqué à l’état de résolution pendant
longtemps
Pas en mesure de mettre les ressources en ligne

Vérifiez si la récupération des bases de données prend beaucoup de temps en vérifiant les messages dans le
SQL ErrorLog.
Foire aux questions

1. Est-il possible d’avoir deux écouteurs pour un groupe de disponibilité ?
Oui, vous pouvez configurer plusieurs écouteurs pour le même groupe de disponibilité. Voir : Comment
créer plusieurs écouteurs pour le même groupe de disponibilité (Goden Yao).
2. Est-il possible d’avoir une car te réseau distincte pour le trafic toujours sur le trafic et la
connectivité client ?
Oui, vous pouvez avoir une carte réseau dédiée pour le trafic AlwaysOn. Voir : Configurer le groupe de
disponibilité pour communiquer sur un réseau dédié.
3. Quelles éditions viennent en charge les instances de cluster de failover Always On ?
Cette rubrique dans SQL Server Books Online contient plus d’informations : Éditions et fonctionnalités
SQL Server 2016.
4. Comment récupérer en cas de défaillance sur tous les nodes de votre cluster ?
Voir : WSFC Disaster Recovery through Forced Quorum (SQL Server).
5. Où puis-je trouver des informations sur la prise en charge des transactions distribuées dans
les configurations AG ?
Voir : Transactions - groupes de disponibilité et mise en miroir de bases de données.
6. Comment mettre à jour les configurations AlwaysOn ?
Voir : Mise à niveau des instances de réplica de groupede disponibilité Always On.
7. Comment ajouter une base de données TDE (Transparent Data Encr yption) à la configuration
AG ?
Pour ajouter la base de données TDE activée à AG, voir : Comment configurer Always On pour une base
de données TDE.
8. Comment configurer des aler tes pour vérifier si la secondaire est en retard par rappor t au
principal ?
Vous pouvez utiliser le script suivant :
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id as database_id,
is_ag_replica_local = CASE
WHEN ar_state.is_local = 1 THEN N'LOCAL'
ELSE 'REMOTE'
END,
ag_replica_role = CASE
WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
ELSE ar_state.role_desc
END,
dr_state.last_hardened_lsn, dr_state.last_hardened_time,
datediff(s,last_hardened_time, getdate()) as 'seconds behind primary'
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
ON ag.group_id = ar.group_id)
JOIN sys.dm_hadr_availability_replica_states AS ar_state
ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
on ag.group_id = dr_state.group_id and dr_state.replica_id = ar_state.replica_id
9. Comment être aler té si l’état de la base de données n’est pas synchronisé ?

Vous pouvez utiliser le script suivant :
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,

dr_state.database_id as database_id,
is_ag_replica_local = CASE
WHEN ar_state.is_local = 1 THEN N'LOCAL'
ELSE 'REMOTE'
END,
ag_replica_role = CASE
WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
ELSE ar_state.role_desc
END,
ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
ON ag.group_id = ar.group_id )
JOIN sys.dm_hadr_availability_replica_states AS ar_state
ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
ON ag.group_id = dr_state.group_id and dr_state.replica_id = ar_state.replica_id
Vous pouvez également consulter les liens suivants pour obtenir des méthodes supplémentaires pour
surveiller les groupes AlwaysOn :
Gestion basée sur une stratégie pour les problèmes opérationnels avec les groupes de
disponibilité Always On
Lien externe : utilisation de la gestion basée sur la stratégie pour SQL Server groupes de
disponibilité des alertes de perte de données
Comportement du témoin dynamique sur le clustering Windows Server 2012 R2
Plus d’informations sur les groupes de disponibilité AlwaysOn

Guide de résolution et de surveillance des groupes de disponibilité AlwaysOn
Groupes de disponibilité Always On : solution de haute disponibilité et de récupération d’urgence
Les bases de données en miroir sont déconnectées
après le redémarrage du miroir de base de données
dans SQL Server
Cet article vous aide à résoudre le problème où les bases de données en miroir sont laissées dans un état
Déconnecté ou En récupération.
Symptôme
Vous avez un ordinateur qui exécute une instance secondaire de Microsoft SQL Server dans un miroir de
base de données à deux serveurs.
L’utilisation du processeur atteint 100 % sur l’ordinateur et vous ne pouvez pas arrêter le service SQL
Server à l’aide SQL Server outils de gestion.
Vous terminez le processus de l’instance SQL Server secondaire à l’aide du Gestionnaire des tâches.
Vous redémarrez l’instance secondaire de SQL Server.
Dans ce scénario, toutes les bases de données en miroir sont dans un état Déconnecté ou En cours de
récupération. En outre, un message d’erreur semblable à ce qui suit est consigné dans le journal SQL
Server’erreurs pour chaque base de données :
Contournement de la récupération pour la base de données « Nom de la base de données » car elle est
marquée comme une base de données de mise en miroir de base de données inaccessible. Il existe un
problème avec la session de mise en miroir. La session n’a pas de quorum ou les liens de communication
sont rompus en raison de problèmes liés aux liens, à la configuration du point de terminaison ou aux
autorisations (pour le compte de serveur ou le certificat de sécurité). Pour accéder à la base de données,
recherchez ce qui a changé dans la configuration de la session et annuler la modification.
Cause
Ce problème se produit en raison de problèmes dans les points de terminaison SQL Server de mise en miroir de
bases de données.
Résolution
Pour résoudre ce problème, utilisez les méthodes suivantes. Si la première méthode ne résout pas le problème,
utilisez la deuxième méthode.
Méthode 1
Recyclez le point de terminaison sur la base de données miroir. Pour cela, procédez comme suit :
1. Sur la base de données principale, exécutez le script de SQL suivant pour arrêter le point de terminaison :
ALTER ENDPOINT <Endpoint Name> STATE=STOPPED
2. Exécutez le script SQL suivant pour redémarrer le point de terminaison :
ALTER ENDPOINT <Endpoint Name> STATE=STARTED
NOTE
Si la communication entre les points de terminaison ne redémarre pas après l’exécution des scripts, exécutez les
scripts sur le miroir de base de données. Toutefois, la base de données peut entrer dans un état Suspendu une fois
que vous avez fait cela. Si ce problème se produit, exécutez le script SQL suivant :
ALTER DATABASE < **Database Name** > SET PARTNER RESUME
Méthode 2
Supprimez et re-créez les points de terminaison de mise en miroir de bases de données sur les deux serveurs.
Une SQL Server de cluster passe à l’état « échec »
lorsque vous essayez de mettre la ressource en ligne
SQL Server
Cet article vous aide à résoudre le problème qui se produit si des clés de Registre spécifiques aux ressources
sont manquantes.
Symptômes
Lorsque vous essayez d’SQL Server de cluster en ligne pour une instance virtuelle de Microsoft SQL Server,
vous remarquerez peut-être le comportement suivant :
La SQL Server de cluster passe à l’état « échec » et n’est pas mise en ligne.
Vous recevez une combinaison des messages d’erreur suivants sur l’ordinateur propriétaire de la SQL
Server cluster.
Un événement semblable à celui-ci se trouve dans le journal des événements système :
Date : 05/08/2004
Heure : 1:11:19 AM
Source : ClusSvc
Catégorie : Mgr deover
Tapez : Erreur
ID d’événement : 1069
Utilisateur : N/A
Ordinateur : <Computer Name> Description :
La ressource de cluster « SQL Server ( ) » dans le groupe <SQL Server instance name> de
ressources ' ' a <Cluster group name> échoué.
Un message d’erreur semblable au suivant se trouve dans le fichier journal du cluster :
00000644.00000944::2003/11/30-18:11:30.360 SQL Server : [sqsrvres] Impossible de lire la

propriété <SQLServer> « VirtualServerName ». Erreur : d.
00000644.00000944::2003/11/30-18:11:30.360 SQL Server <SQLServer> : [sqsrvres]
OnlineThread : Erreur lors de la mise en ligne de la ressource.
Les messages d’erreur semblables aux suivants sont dans le SQL Server journal des erreurs :
2003-11-30 17:00:37.27 Serveur Erreur : 17826, Gravité : 18, État : 1

2003-11-30 17:00:37.27 Server Could not set up Net-Library 'SSNETLIB'..
2003-11-30 17:00:37.27 spid13 Démarrage de la base de données « SPB ».
2003-11-30 17:00:37.27 spid12 Démarrage de la base de données « BD_MTA ».
2003-11-30 17:00:37.27 spid14 Démarrage de la base de données « BD_SPF ».
2003-11-30 17:00:37.27 Serveur Erreur : 17059, Gravité : 18, État : 0
2003-11-30 17:00:37.27 serveur Erreur du système d’exploitation -1073723998 : ..
Serveur 2003-11-30 17:00:37.27 Impossible de charger des netlibs.
Le serveur 2003-11-30 17:00:37.27 n SQL Server pas pu générer le thread FRunCM.
Cause
Les clés de Registre spécifiques aux ressources qui correspondent à la ressource de cluster SQL Server que vous
essayez de mettre en ligne sont manquantes. Ce problème se produit également si les valeurs qui
correspondent aux clés de Registre spécifiques aux ressources ne sont pas correctes.
Résolution
IMPORTANT
Pour résoudre ce problème, vous devez manuellement créer à nouveau les clés de Registre spécifiques aux
ressources qui correspondent à la ressource SQL Server cluster. Pour cela, procédez comme suit :
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapez Regedit, puis cliquez sur OK.
2. Dans l’Éditeur du Registre, recherchez et sélectionnez la clé de Registre :
HKEY_LOCAL_MACHINE\Cluster\Resources\<GUID>\Parameters .
3. Créez les valeurs de Registre suivantes dans la clé de Registre Parameters :

Pour une instance par défaut de SQL Server :
InstanceName
Nom de la valeur : InstanceName
Type de valeur : REG_SZ
Données de valeur : MSSQLSERVER
VirtualServerName
Nom de la valeur : VirtualServerName
Données de valeur : <Name of the virtual SQL server>
Pour une instance nommée de SQL Server :
InstanceName
Nom de la valeur : InstanceName
Données de valeur : <SQL Server instance name corresponding to the virtual server>
VirtualServerName
Nom de la valeur : VirtualServerName
Données de valeur : <Name of the virtual SQL server>
4. Quittez l’Éditeur du Registre.Après avoir créé les clés de Registre spécifiques à la ressource, vous pouvez
mettre la ressource SQL Server cluster en ligne.
Si vous remarquez qu’une ressource de cluster agent SQL Server ne peut pas être mise en ligne, vous
devez créer le même ensemble de clés spécifiques aux ressources qui correspondent à la ressource de
cluster de l’agent SQL Server.
Comment créer manuellement les clés de Registre propres aux ressources pour SQL Server de cluster
Message d’erreur lors de l’installation SQL Server
sur un cluster Windows Server
Cet article vous aide à résoudre le problème qui se produit lorsque vous installez SQL Server sur Windows
cluster de serveurs.
Symptômes
Lorsque vous installez Microsoft SQL Server sur un cluster Windows server, la règle de validation de cluster du
processus d’installation peut échouer. En outre, le message d’erreur suivant peut s’afficher :
Erreur : « Erreurs de vérification du cluster du service de cluster Microsoft (MSCS) » a échoué. Le cluster n’a
pas été vérifié ou il y a des erreurs ou des échecs dans le rapport de vérification. Consultez la KB953748 ou
SQL en ligne pour plus d’informations »
Le fichier journal d’installation peut contenir un message semblable à ce qui suit :
2008-05-20 05:27:18 Slp : Évaluation de la règle : Cluster_VerifyForErrors

2008-05-20 05:27:18 Slp : Règle en cours d’exécution sur l’ordinateur : SQLNode_Name
2008-05-20 05:27:18 Slp : Évaluation de la règle effectuée : Échec
2008-05-20 05:27:18 Slp : Message d’évaluation de la règle : le cluster n’a pas été vérifié ou il y a des erreurs
ou des échecs dans le rapport de vérification.
Par exemple, le fichier journal d’installation (Detail.txt) peut se présenter dans le dossier :
%ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\Log\20090316_112604 .
Pour une validation réussie, la règle aura une entrée qui ressemble à ce qui suit :
Computer_name : Cluster_VerifyForErrors : Transmis
Cause
Le processus de validation peut échouer dans différentes conditions. Lorsque ce problème se produit, vous
devez effectuer une validation manuelle pour vous assurer que la configuration matérielle est correcte avant
d’essayer une solution de contournement mentionnée dans cet article. Vous pouvez utiliser les références
mentionnées dans la section Références pour plus d’informations sur la validation des clusters dans les
environnements Windows Server. Cela permet d’éviter d’autres problèmes que vous risquez de résoudre à
l’avenir, si vous utilisez la solution de contournement lorsque des problèmes sous-jacents existent.
Pour contourner ce problème, vous devez résoudre le problème à l’origine de l’échec de la validation. Si vous
pouvez déterminer que le problème à l’origine de l’échec de la validation peut être résolu ultérieurement, vous
pouvez utiliser l’option d’installation de ligne de commande de cet article pour ignorer le message d’erreur et
essayer d’installer l’instance du cluster de SQL Server. Si vous faites cela, avant d’utiliser à nouveau le système,
vous devez toujours résoudre le problème sous-jacent qui a provoqué l’échec de la validation.
NOTE
Si vous essayez cette option d’installation de ligne de commande et que le programme d’installation de SQL Server
échoue, assurez-vous que la configuration matérielle du cluster est valide, puis contactez les services de support
technique Microsoft (CSS) pour obtenir de l’aide supplémentaire.
À l’invite de commandes, modifiez le lecteur de disque dur et le dossier qui contient SQL Server(Setup.exe).
Tapez ensuite l’une des commandes suivantes pour ignorer la règle de validation :
Pour une configuration de Add-Note intégrée, exécutez la commande sur chaque nœud ajouté
Setup/SkipRules=Cluster_VerifyForErrors/Action=InstallFailoverCluster :
Pour une installation avancée ou d’entreprise, exécutez la commande :

Setup/SkipRules=Cluster_VerifyForErrors/Action=CompleteFailoverCluster
Si vous recevez cet échec de validation lorsque vous ajoutez un nœud à une installation deover existante,
exécutez la commande sur chaque nœud ajouté
Setup /SkipRules=Cluster_VerifyForErrors /Action=AddNode :
NOTE
La configuration d’une instance de cluster de SQL Server de Windows Server contenant des erreurs dans le rapport de
validation du cluster de serveur Windows n’est pas pris en compte. Pour qu’SQL Server instance de cluster de point de
contrôle soit dans un scénario pris en charge, le rapport de validation du cluster Windows server ne peut pas contenir
d’erreurs. Confirmez avec CSS que la configuration de cluster est dans un état pris en charge.
Le SkipRules paramètre d’installation n’est pas une fonctionnalité documentée. Vous ne devez pas utiliser ce
paramètre pour ignorer d’autres règles à l’exception de la règle, sauf si Cluster_VerifyForErrors CSS vous en
fait l’indication.
SQL Server de validation de cluster de failover

À l’aide de l’Assistant Validation de cluster, vous pouvez exécuter un ensemble de tests axés sur une collection de
serveurs que vous avez l’intention d’utiliser comme des serveurs dans un cluster. Ce processus de validation de
cluster teste le matériel et les logiciels sous-jacents directement et individuellement, afin d’obtenir une
évaluation précise de la prise en charge du clustering de SQL Server dans une configuration donnée.
Procédure à prendre en cas d’échec des tests de validation

Dans la plupart des cas, si des tests de la règle de validation de cluster échouent, Microsoft ne considère pas la
solution comme prise en charge. Il existe des exceptions à cette règle, comme dans le cas de clusters
multisessulaires (géographiquement dispersés) où il n’y a pas de stockage partagé. Dans ce scénario, le résultat
attendu de l’Assistant Validation de cluster est que les tests de stockage échoueront. Il s’agit toujours d’une
solution prise en charge si le reste des tests se termine correctement.
Le type de test qui échoue est une recommandation pour l’action corrective à prendre. Par exemple, si le test de
stockage List all disks échoue et si les tests de stockage ultérieurs ne s’exécutent pas parce qu’ils échouent
également, contactez le fournisseur de stockage pour résoudre les problèmes. De même, si un test réseau lié aux
adresses IP échoue, discutez avec l’équipe d’infrastructure réseau.
Références
Valider le matériel pour un cluster de failover
Instances de cluster de failover Always On (SQL Server)
Installer les SQL Server à partir de l’invite de commandes
Lorsque vous exécutez l’Assistant Validation d’une configuration sur un ordinateur Windows Server 2008
ou sur un ordinateur Windows Vista, la validation n’est pas validée.
Créer des bases de données ou modifier des
emplacements de fichiers disque sur un lecteur de
cluster partagé sur lequel SQL Server n’a pas été
installé à l’origine
Cet article explique comment créer des bases de données ou modifier des emplacements de fichiers disque sur
un lecteur de cluster partagé sur lequel SQL Server n’a pas été installé à l’origine.
Résumé
Après avoir installé une instance de serveur virtuel SQL Server, vous pouvez créer des bases de données ou
déplacer des données existantes ou des fichiers journaux sur un disque de cluster partagé secondaire. Pour créer
des bases de données ou déplacer des données ou des fichiers journaux existants, l’autre disque que SQL Server
doit utiliser doit être ajouté en tant que dépendance à la ressource SQL Server dans l’administrateur de cluster.
Si vous tentez de créer une base de données sur un autre lecteur de cluster partagé lorsque la ressource SQL
Server ne dépend pas de ce disque, vous pouvez recevoir une erreur semblable à celle-là :
Serveur : Msg 5184, Niveau 16, État 2, Ligne 1. Impossible d’utiliser le fichier « %.*ls » pour le serveur en
cluster. Seuls les fichiers mis en forme sur lesquels la ressource de cluster du serveur a une dépendance
peuvent être utilisés.
Serveur : Msg 1802, Niveau 16, État 1, Ligne 1
ÉCHEC DE LA CRÉATION D’UNE BASE DE DONNÉES. Certains noms de fichiers répertoriés n’ont pas pu être
créés. Vérifiez les erreurs précédentes.
Une erreur similaire s’affiche lorsque vous essayez de déplacer ou d’ajouter des fichiers à une base de données
existante sur un lecteur de cluster partagé qui n’est pas dans le groupe SQL Server et qui n’a pas non plus la
dépendance SQL Server ressources.
En outre, si vous essayez de créer un catalogue d’index de texte intégral sur un disque dont la ressource SQL
Server ne dépend pas, l’erreur suivante s’affiche :
Serveur : Msg 7627, Level 16, State 1, Procedure sp_fulltext_database, Line 61 Full-text catalog in directory
'Y:\FTDATA' for clustered server cannot be created. Seuls les répertoires sur un disque du groupe de clusters
du serveur peuvent être utilisés.
Pour ajouter un disque en tant que dépendance au SQL Server, le disque de cluster partagé doit résider dans le
même groupe dans l’administrateur de cluster que les ressources SQL Server cluster.
Pour déplacer le disque de cluster partagé, sélectionnez le disque que vous souhaitez déplacer vers le groupe de
SQL Server, puis cliquez avec le bouton droit sur cette ressource. Cliquez sur Modifier le groupe. Une fois que
le disque se trouve dans le même groupe dans lequel réside la ressource SQL Server, suivez les étapes suivantes
pour l’ajouter en tant que SQL Server dépendance :
1. Ouvrez l’administrateur de cluster.
2. Assurez-vous que toutes les ressources de disque physique qui contiennent SQL Server bases de données
sont dans le même groupe que la SQL Server ressource.
3. Cliquez avec le bouton droit SQL Server ressource, puis mettre la ressource dans un état hors connexion en
cliquant sur Mettre hors connexion.
4. Cliquez avec le bouton droit sur SQL Server ressource, puis cliquez sur Propriétés.
5. Sélectionnez l'onglet Dépendances .
6. Cliquez sur Modifier pour ajouter le disque à la liste des dépendances de cette ressource.
7. Remettre la SQL Server en ligne, puis placer les fichiers SQL Server sur ce disque de cluster partagé.
Une erreur se produit lorsque vous installez SQL
Server 2016 sur un disque de volume partagé de
cluster
Cet article vous aide à contourner le problème d’autorisations qui se produit lorsque vous installez SQL Server
2016 sur un disque de volume partagé de cluster (CSV).
Version du produit d’origine : SQL Server 2016 Standard, SQL Server 2016 Enterprise
Symptômes
Supposons que vous essayiez d’installer une instance de Microsoft SQL Server 2016 sur un disque CSV, vous
pouvez recevoir une erreur ressemblant à ce qui suit :
TITRE : configuration Microsoft SQL Server 2016

L’erreur suivante s’est produite :
Échec de la mise à jour du paramètre d’autorisation pour le dossier « C:\ClusterStorage\volume1\Data1 ». '
Le paramètre d’autorisation de dossier était supposé être « D:P(A;OICI;FA;; ; ; BA)(A;OICI;FA;;; SY)(A;OICI;FA;;;
CO)(A;OICI;FA;;)'.
Cliquez sur « Réessayer » pour réessayer l’action qui a échoué ou cliquez sur « Annuler » pour annuler cette
action et poursuivre l’installation.
Cause
Le bouton Autorisations héritées est activé pour le dossier choisi pour les emplacements de base de données.
La solution de contournement pour ce problème est la suivante :
Supposons que nous utilisons le dossier C:\ClusterStorage\Volume1\Data1\ comme exemple.
1. Accédez à C:\ClusterStorage\Volume1\ .
2. Cliquez avec le bouton droit sur le dossier Data1, puis sélectionnez le bouton Propriétés.
3. Sélectionnez l’onglet Sécurité, puis le bouton Avancé en bas.
4. Sélectionnez le bouton Désactiver l’héritage, puis sélectionnez Convertir les autorisations héritées en
autorisations explicites sur cette option d’objet.
5. Réessayez l’installation.
Re-créer manuellement les clés de Registre propres
aux ressources pour SQL Server cluster
Cet article montre comment créer manuellement les clés de Registre spécifiques aux ressources pour SQL
Server de cluster lorsque vous supprimez une ressource de l’administrateur de cluster.
Résumé
Les ressources de cluster SQL Server (SQL Server, agent SQL Server et recherche en texte intégral) contiennent
toutes des clés de Registre spécifiques aux ressources qui doivent être présentes pour mettre la ressource en
ligne. Si vous supprimez une ressource de l’administrateur de cluster, vous pouvez la créer à nouveau
manuellement. Les étapes peuvent uniquement être utilisées pour ajouter des ressources qui dépendent de SQL
Server. Elles ne peuvent pas être utilisées pour les ressources dont SQL Server dépend. Consultez la section Plus
d’informations de cet article pour ajouter manuellement la ressource. Ces étapes supposent que vous avez déjà
utilisé le programme d SQL Server de cluster pour installer correctement tous les fichiers et composants du
cluster. Cette procédure ne décrit pas tous les fichiers, modifications ou clés de Registre que le programme
d’installation effectue dans une nouvelle installation de cluster.
Chaque ressource que l’administrateur de cluster répertorie a une clé de Registre qui se trouve sous
HKEY_LOCAL_MACHINE (HKLM) HKLM\Cluster\Resources\GUID . Un GUID est créé lorsque vous ajoutez la ressource et
diffère d’un ordinateur à l’autre. Chaque clé contient une valeur Name qui contient le nom de ressource affiché
par l’administrateur de cluster. Sous chaque clé de ressource se trouve une sous-clé Parameters dans laquelle la
ressource peut stocker des informations de paramètre spécifiques à la ressource.
SQL Server, SQL Server agent de recherche et les informations de recherche en texte intégral dans cette sous-clé
Parameters. Si les informations sont manquantes, des erreurs telles que les suivantes sont consignées dans le
fichier journal du cluster lorsque vous essayez de mettre la ressource en ligne :
SQL Server : [sqsrvres] Impossible de lire la propriété « VirtualServerName ». Erreur : d.

Recherche Microsoft Recherche en texte intégral de l’instance de service : une erreur s’est produite lors de
l’opération en ligne pour l’exemple de recherche en texte intégral : 80070002 - Le système ne peut pas
trouver le fichier spécifié.
Re-créer manuellement une ressource

Pour créer manuellement une ressource dans l’administrateur de cluster, vous devez ajouter les valeurs de
Registre suivantes sous la clé qui représente la ressource :
SQL Server
Nom : InstanceName
Type : REG_SZ
Valeur : nom de l’instance de SQL Server que représente le serveur virtuel. Utilisez MSSQLSERVER pour utiliser
l’instance par défaut.
Nom : VirtualServerName
Type : REG_SZ
Valeur : nom du serveur virtuel que vous avez affecté au serveur
SQL Server Agent
Nom : InstanceName
Type : REG_SZ
Valeur : nom de l’instance de SQL Server que représente le serveur virtuel. Utilisez MSSQLSERVER pour utiliser
l’instance par défaut.
Nom : VirtualServerName
Type : REG_SZ
Valeur : nom du serveur virtuel affecté au serveur
Full-Text recherche
Nom : ApplicationName
Type : REG_SZ
Valeur : SQL Server$instance_nom, où instance_name est l’instance de SQL Server à utiliser. Pour utiliser une
instance par défaut, utilisez SQLServer.
Nom : ApplicationPath
Type : REG_SZ
Valeur : chemin d’accès complet au dossier qui contient les fichiers de données Fulltext. En règle générale, il se
trouve dans \MSSQL\FTDATA pour une instance par défaut et dans MSSQL$instancename\FTDATA pour une
instance nommée.
Ajouter les clés de Registre à l’aide de lCluster.exe de registre
IMPORTANT
Vous pouvez utiliser cette méthode uniquement dans une situation critique. Par exemple, vous pouvez utiliser cette
méthode lorsque vous ne pouvez pas démarrer l’instance de SQL Server. Toutefois, vous pouvez utiliser le programme
d’installation pour re-créer le serveur virtuel.
Vous pouvez utiliser l’utilitaire Cluster.exe pour ajouter les clés de Registre. Pour ce faire, vous devez exécuter
une commande semblable à la commande suivante à l’invite de commandes :
cluster res "ResourceName" /priv KeyName = KeyValue:STR
NOTE
Vous devez remplacer ResourceName par le nom de la ressource SQL Server appropriée, de la ressource agent SQL
Server ou de la ressource Full-Text search.
Vous devez remplacer KeyName par les noms de clé de Registre appropriés. Par exemple, InstanceName,
VirtualServerName sont des noms de clé de Registre.
Vous devez remplacer KeyValue par la valeur appropriée pour la clé. Pour la clé de Registre InstanceName, vous
pouvez affecter le nom de l’instance de SQL Server que le serveur virtuel représente pour la valeur de clé. Vous pouvez
utiliser MSSQLSERVER comme nom de l’instance pour l’instance par défaut.
Stratégie de support Microsoft pour les
configurations en cluster de SQL Server avec
Windows Server
Cet article décrit la stratégie de support Microsoft pour les configurations en cluster de SQL Server avec
Windows Server.
Résumé
Cet article décrit la stratégie de support Microsoft pour SQL Server clustering deover. Les services de support
technique Microsoft (CSS) prend en charge le clustering de SQL Server de SQL Server basé sur les
fonctionnalités de clustering de clustering de Windows dans les produits suivants :
Windows Serveur 2008 Êdition Entreprise
Windows Server 2008 Datacenter Edition
Windows Server 2008 R2 Entreprise Edition
Windows Server 2008 R2 Datacenter Edition
Window Server 2012
Windows Server 2016 Standard et Datacenter Editions
NOTE
Windows Server 2012 et Windows Server 2012 R2 doivent passer en revue la stratégie de prise en charge de Microsoft
de la Windows clusters de serveurs de serveurs.
Les stratégies suivantes pour n’importe quelle version SQL Server prise en charge lorsqu’elle est installée en
tant qu’instance SQL Server cluster de SQL Server.
IMPORTANT
Le terme clusters de ser veurs signifie les ordinateurs qui exécutent le service de cluster Microsoft. La Windows Server
2003 fournit les types de services de clustering suivants :
Cluster de serveurs (cluster deover)

Équilibrage de la charge réseau
Serveur de cluster de calcul
Seules les solutions de cluster de serveurs peuvent être utilisées avec SQL Server pour la haute disponibilité en
cas de perte d’un nœud ou en cas de problème avec une instance de SQL Server. L’équilibrage de la charge
réseau peut être utilisé dans certains cas avec des installations en lecture seule SQL Server’installation. SQL
Server Les instances de cluster de failover nécessitent chacune un groupe unique. Cette exigence est vraie sur
les ressources de disque de cluster qui utilisent des lettres de lecteur propres au cluster et à chaque instance de
cluster de SQL Server de cluster de SQL Server. Chaque instance de cluster de SQL Server doit également avoir
au moins une adresse IP unique. Selon la version installée, plusieurs adresses IP uniques peuvent être possibles.
En outre, chaque instance de cluster de failover doit avoir à la fois des noms de serveur virtuel et d’instance
propres au domaine auquel le cluster appartient.
Solutions de cluster autres que Windows clustering de failover
Si vous regroupez des SQL Server avec un produit de clustering autre que le clustering Microsoft Server, votre
contact de support principal est le fournisseur de solutions de cluster tiers pour tout problème de support lié à
SQL Server. SQL Server été développé et testé à l’aide du clustering Microsoft Server. Les fournisseurs de
solutions de clustering tiers qui SQL Server installations de clustering doivent être votre principal contact pour
tout problème d’installation, de performance ou de comportement de cluster. CSS fournit une prise en charge
commerciale raisonnable pour les installations de clusters tiers de la même manière que pour une version
autonome de SQL Server.
SQL Server 2008 et SQL Server 2008 R2

Pour SQL Server éditions 2008 et SQL Server 2008 R2, consultez les rubriques suivantes de SQL Server Books
Online :
Pour plus d’informations sur le nombre de nodes pris en charge, voir la rubrique suivante : Éditions et
fonctionnalités SQL Server 2016
NOTE
Même s’il s’agit SQL Server 2008 R2 Books Online, le même contenu s’applique SQL Server 2008.
Pour plus d’informations sur les systèmes d’exploitation pris en charge pour le clustering de SQL Server
failover, reportez-vous à la section « Vérifier votre Paramètres de système d’exploitation » dans la
rubrique suivante : Avant d’installer le clustering deover
En résumé, les éditions SQL Server 2008 et SQL Server 2008 R2 peuvent prendre en charge jusqu’à 8
nodes sur Windows Server 2003 et 16 sur Windows Server 2008 et les versions ultérieures en ce qui a
trait aux installations AlwaysOn.
SQL Server 2012, SQL Server 2014 et SQL Server 2016
Reportez-vous aux articles MSDN suivants pour chacune des versions :
Clustering de basculement Windows Server (WSFC) avec SQL Server
Stratégie de failover pour les instances de cluster de failover
Windows Clustering de serveur avec SQL Server
Stratégie de failover pour les instances de cluster de failover
Windows Clustering de serveur avec SQL Server 2016
SQL Server 2016 pour les instances de cluster de failover
Lecteurs montés
L’utilisation de lecteurs montés n’est pas prise en charge sur un cluster qui inclut une installation Microsoft SQL
Server’installation. Pour plus d’informations, voir SQL Server prise en charge des volumes montés.
Volumes partagés de cluster (CSV)

Utilisez les volumes partagés de cluster pour SQL Server dans un cluster de SQL Server 2014 n’est pas pris en
charge.
Reportez-vous aux articles suivants sur l’utilisation de CSV avec SQL Server 2014 ou une version ultérieure de
SQL Server :
Déploiement de SQL Server 2014 avec des volumes partagés de cluster
Volumes partagés de cluster
Utiliser des volumes partagés de cluster dans un cluster de failover
Utilisation des serveurs contrôleurs de domaine dans Windows cluster

de serveurs de failover (WSFC)
SQL Server instances de cluster de failover ne sont pas pris en charge sur les nodes d’instance de cluster de
failover configurés en tant que contrôleurs de domaine.
Migration ou modification de SQL Server instances de cluster de

failover vers un nouveau domaine
SQL Server 2005 et versions ultérieures ne peuvent pas être migrées vers un nouveau domaine. Vous devrez
désinstaller et réinstaller les composants du cluster deover. Pour plus d’informations sur le déplacement d’un
cluster Windows Server d’un domaine à un autre, voir Déplacer un cluster Windows Server d’un domaine vers
un autre.
CRITIQUE - Avant la désinstallation, SQL Server doit être définie pour utiliser la sécurité en mode mixte ou les
nouveaux comptes de domaine ajoutés aux connexions SQL Server et le dossier DATA contenant les bases de
données système doit être renommé afin que ce dossier puisse être remplacé une fois réinstallé afin de réduire
le temps d’indispérable. Aucune suppression des SQL Server de support, SQL Server Native Client, des services
d’intégration ou des composants de station de travail ne doit être effectuée. Sauf si vous allez reconstruire le
nœud dans son intégralité.
WARNING
Si, pendant la désinstallation, vous obtenez des erreurs, il est probable que le nœud devra être reconstruit sinon
l’installation ne se réinstalle pas correctement.
Prise en charge de la virtualisation
Pour plus d’informations sur l’installation de clusters de SQL Server dans un environnement de virtualisation de
matériel, voir Stratégie de prise en charge pour les produits Microsoft SQL Server qui s’exécutent dans un
environnement de virtualisation de matériel.
Références
Pour plus d’informations, consultez la rubrique clustering de SQL Server livres en ligne ou sur le site web
MSDN.
S’applique à
Microsoft Windows des ressources de cluster de
SQL Server
Cet article présente les dépendances de ressources par défaut dans SQL Server et les restrictions sur ces
dépendances.
Server 2008
Résumé
Lorsque vous installez SQL Server sur un cluster en tant qu’instance de cluster de SQL Server de SQL Server, un
ensemble spécifique de ressources SQL Server qui ont des dépendances sur d’autres ressources dans le groupe
de clusters est créé.
IMPORTANT
Ne modifiez pas l’arborescence des dépendances par défaut à l’exception des modifications répertoriées dans cet article ou
des modifications répertoriées dans l’article suivant de la Base de connaissances Microsoft : prise en charge SQL Server
pour les dossiers montés
Exemple 1 - Dépendances d’instances SQL Server de cluster de SQL

Server par défaut
Dans ce diagramme, notez les remarques suivantes :

Le disque de cluster 1 n’a pas de dépendances requises.
Adresse IP : xxx.xxx.xxx.xxx aucune dépendance n’est requise.
Adresse IP : xxxx:xxxx:xx:xxxx:xxxx:xxxx:xxxx:xxxx aucune dépendance n’est requise.
Name: SOFTY dependencies are IP Address: xxxx:xxxx:xx:xxxx:xxxx:xxxx:xxxx:xxxx and IP Address:
xxx.xxx.xxx.xxx .
SQL Les dépendances requises du nom de réseau (SOFTY) sont l’adresse IP.
SQL Server dépendances sont le disque de cluster 1 et le nom : SOFTY.
SQL Server n’a pas de dépendances requises.
SQL Server Les dépendances de l’agent sont SQL Server.
SQL Server L’agent n’a pas de dépendances requises.
Exemple 2 : SQL Server instances de failover Analysis Services 2008

Les dépendances Analysis Services (LOCALINSTANCE) sont le disque de cluster 2 et le nom :
STANDALONE2008R.
Analysis Services (LOCALINSTANCE) n’a aucune dépendance requise.
Adresse IP : xxx.xxx.xxx.xxx aucune dépendance n’est requise.
Adresse IP : xxxx:xxxx:xx:xxxx:xxxx:xxxx:xxxx:xxxx aucune dépendance n’est requise.
Name: STANDALONE2008R dependencies are IP Address: xxxx:xxxx:xx:xxxx:xxxx:xxxx:xxxx:xxxx and IP
Address: xxx.xxx.xxx.xxx .
SQL Les dépendances requises du nom de réseau (STANDALONE2008R) sont l’adresse IP.
SQL Server (LOCALINSTANCE) sont cluster Disk 2 et Name: STANDALONE2008R .
SQL Server (LOCALINSTANCE) n’a pas de dépendances requises.
SQL Server Les dépendances d’agent (LOCALINSTANCE) SQL Server (LOCALINSTANCE).
SQL Server L’agent (LOCALINSTANCE) n’a pas de dépendances requises.
Exemple 3 : SQL Server instance de bas de la charge 2008 avec un

point de montage

Cluster Disk 4, Mountpoint dependencies are Cluster Disk 1.
Cluster Disk 4, Mountpoint n’a pas de dépendances requises.
Adresse IP : xxx:xxxx:c0:xxxx:xxxx:c597:8cb0:49f2 aucune dépendance n’est requise.
Name: SOFTY dependencies are IP Address: xxx:xxxx:c0:xxxx:xxxx:c597:8cb0:49f2 and IP Address:
xxx.xxx.xxx.88 .
SQL Les dépendances requises du nom de réseau (SOFTY) sont l’adresse IP.
SQL Server dépendances sont Name: SOFTY, Cluster Disk 4, Mountpoint et Cluster Disk 1.
SQL Server n’a pas de dépendances requises.
NOTE
La double dépendance vis-à-vis du point de montage consiste à s’assurer que les SQL Server ne peuvent pas démarrer et
charger des bases de données sans que les disques physiques ne sont disponibles. Cela permet d’éviter l’altération de la
base de données.
L’arborescence des dépendances par SQL Server a les implications suivantes :

La ressource SQL Server agent de gestion dépend de la SQL Server ressource.
La SQL Server dépend de la ressource SQL nom de réseau, des ressources de disque physiques et des
dossiers montés qui contiennent les fichiers de base de données.
La SQL de nom de réseau dépend de la ressource SQL’adresse IP.
La SQL’adresse IP de l’ordinateur et les ressources de disque physique ne dépendent d’aucune ressource
Pour plus d’informations sur l’ajout de dépendances à SQL Server ressource :
Comment ajouter des dépendances dans SQL Server 2008
Comment ajouter des dépendances dans SQL Server 2008 R2
Comment ajouter des dépendances dans SQL Server 2012
Comment ajouter des dépendances à un SQL Server 2016 ou une version ultérieure de SQL Server
Limitations et restrictions
Si vous ajoutez d’autres ressources au groupe SQL Server, ces ressources doivent toujours avoir leurs propres
ressources de nom de réseau SQL et leurs propres ressources d SQL’adresse IP. N’utilisez pas les ressources de
nom de SQL réseau existantes SQL ressources d’adresse IP pour d’autres SQL Server. Si SQL Server ressources
sont partagées avec d’autres ressources ou sont mal définies, vous pouvez être en face des problèmes suivants :
Des pannes qui ne sont pas prévues peuvent se produire.
Une altération de la base de données peut se produire.
Les installations du Service Pack risquent de ne pas réussir.
Il est possible SQL Server programme d’installation de l’ordinateur ne soit pas réussi. Si cela se produit, vous
ne pouvez pas installer d’instances supplémentaires de SQL Server ni effectuer de maintenance de routine.
SQL Server ne peuvent pas être en ligne.
Il se peut que les disques ne soient pas disponibles SQL Server’utilisation.
Considérations supplémentaires
FtP avec réplication SQL Server : pour les instances de SQL Server qui utilisent FTP avec la réplication SQL
Server, votre service FTP doit utiliser l’un des mêmes disques physiques que l’installation de SQL Server qui
est définie pour utiliser le service FTP.
SQL Server de ressources : si vous ajoutez une ressource à un groupe SQL Server et que vous avez une
dépendance sur la ressource SQL Server pour vous assurer que SQL Server est disponible, nous vous
recommandons d’ajouter une dépendance sur la ressource agent SQL Server au lieu d’ajouter une
dépendance à la ressource SQL Server. Pour vous assurer que l’ordinateur qui exécute SQL Server reste
hautement disponible, configurez la ressource de l’agent SQL Server afin qu’elle n’affecte pas le groupe SQL
Server en cas d’échec de la ressource agent SQL Server.
Partages de fichiers et ressources d’imprimante : une exception est le partage de fichiers utilisé par la SQL
Server FILESTREAM. Une ressource d’imprimante ne doit pas faire SQL Server groupe. Les ressources de
partage de fichiers ou d’imprimante nécessitent leur propre nom réseau et ressource IP sur un cluster de
Windows Server 2003. Les partages de fichiers et les ressources d’imprimante nécessitent également leur
propre nom réseau et ressource IP pour un point d’accès au client sur Windows Server 2008 et versions
ultérieures. Pour une instance de cluster de Windows Server 2008 ou une version ultérieure, utilisez
l’Assistant Création d’un dossier partagé pour spécifier un nom unique et d’autres paramètres pour le dossier
partagé.
Performances : une diminution des performances et une perte de service sur l’ordinateur qui exécute SQL
Server peut se produire lorsque les conditions suivantes sont vraies :
Une ressource de cluster de partage de fichiers qui n’utilise pas la fonctionnalité FILESTREAM est
installée sur la même ressource de disque physique sur laquelle SQL Server est installée.
Une ressource de cluster d’imprimantes est installée sur la même ressource de disque physique sur
laquelle SQL Server est installée.
Considérations sur MSDTC
Lisez les Recommandations MSDTCsur SQL Cluster de failover , qui doit être le point de départ pour toute
discussion sur les dépendances MSDTC, selon qu’elle est requise ou non.
Ce FAQ sur les Recommandations MSDTC (forum aux questions) consiste à répondre aux questions courantes et
aux meilleures pratiques avec MSDTC (Microsoft Distributed Transaction Coordinator) lorsqu’il est utilisé avec
les instances de clustered de SQL Server pour inclure les recommandations actuelles et les meilleures pratiques.
Lorsque vous ajoutez une ressource MSDTC à un groupe SQL Server, vous pouvez utiliser l’un des disques SQL
Server ou un autre disque. Toutefois, pour que la ressource fonctionne correctement et pour pouvoir utiliser
l’applet de la cmdlet Test-DTC PowerShell, vous devez utiliser le nom de réseau et l’adresse IP des serveurs SQL
et renommer votre ressource MSDTC en nom de serveur virtuel SQL Servers.
À partir de Windows Server 2012 et plus tard lors de la création d’un coordinateur de transactions distribuées à
l’aide du Gestionnaire de cluster, vous n’avez pas le choix dans le nom des ressources. Il s’agit toujours du
Nouveau coordinateur de transactions distribuées, et vous n’avez pas la possibilité de renommer la ressource
dans le Gestionnaire de cluster.
PowerShell en exemple, cette commande vous permet de renommer le Nouveau coordinateur de transactions
distribuées en nom de votre choix. Dans cet exemple, le nom est modifié en MSDTC.
Exemple (PowerShell) :
Get-ClusterResource "New Distributed Transaction Coordinator" | %{ $_.Name = MSDTC }
S’applique à
SQL Server 2017 Windows (toutes les éditions)
Configurer la sécurité pour la SQL Server des
journaux de bord
Cet article explique comment configurer la sécurité pour la SQL Server des journaux de livraison et fournit des
informations sur le problème qui peut se produire lorsque vous configurez la sécurité pour la SQL Server des
journaux de livraison.
Résumé
Cet article fournit des informations sur la configuration de la sécurité pour la livraison des journaux de livraison.
Il existe plusieurs problèmes à prendre en compte lors de la configuration de la sécurité pour la copie des
journaux de transaction SQL Server qui vont du compte de démarrage pour SQL Server pour partager les
autorisations pour le partage réseau où résident les sauvegardes du journal des transactions. Ces problèmes
sont décrits dans cet article.
Compte de domaine
Si vous avez placé des SQL Server dans un domaine, Microsoft vous recommande d’utiliser un compte de
domaine pour démarrer SQL Server services. Vous devez utiliser un compte de domaine si vous comptez
configurer SQL Server pour qu’il s’exécute en tant que serveur virtuel sous Windows clustering. Un compte de
domaine offre l’avantage d’une maintenance minimale en cas de modification de mot de passe. Toutefois, il se
peut que vous ne soyez pas en mesure de démarrer SQL sous un compte de domaine si SQL Server réside sur
un serveur qui se trouve dans un groupe de travail.
Compte réseau local

Vous pouvez utiliser SQL Server pour démarrer sous un compte réseau créé localement. Dans le cas où l’accès
réseau est requis par un processus SQL Server, ce qui est le cas si vous avez configuré SQL Server pour utiliser
la livraison des journaux de bord, vous pouvez utiliser la sécurité réseau pass-through. Avec la sécurité pass-
through, tous les ordinateurs accessibles par SQL Server doivent avoir le même compte réseau avec le même
mot de passe et les mêmes autorisations appropriées, configurés localement. En outre, lorsque le processus SQL
Server demande des ressources au deuxième ordinateur, la sécurité réseau traditionnelle est contourné si le
même compte (sous lequel le service SQL Server demande est démarré) existe avec le même mot de passe. Tant
que le compte sur le deuxième ordinateur est configuré avec suffisamment d’autorisations pour effectuer la
tâche demandée par l’SQL Server, la tâche réussit.
Compte système local

Vous pouvez également configurer SQL Server pour démarrer sous le compte système local. La modification du
mot de passe du compte LocalSystem peut entraîner l’échec de certains services essentiels à la stabilité du
système. Ce compte est local pour l’ordinateur où il réside, ce qui signifie que le contexte de sécurité utilisé par
SQL Server services est local. Comme indiqué dans la section Compte réseau local, vous ne pouvez pas utiliser
la sécurité de réseau pass-through lorsque vous démarrez SQL Server sous le compte LocalSystem, car les mots
de passe du compte LocalSystem sur différents ordinateurs sont différents. Le démarrage des SQL Server sous
ce compte lorsque l’accès aux ressources réseau est requis entraîne très probablement l’échec de l’exécution des
tâches.
Pour plus d’informations sur les droits minimaux requis pour qu’un compte réseau démarre et exécute
correctement les services SQL Server et SQL Server Agent, voir Setting up Windows Service Accounts.
Comprendre le modèle SQL Server sécurité de l’entreprise

Pour bien comprendre les implications en matière de sécurité, il est important de comprendre le modèle de
sécurité que Microsoft a implémenté SQL Server 2000. Lorsque vous créez une connexion, elle est ajoutée à la
syslogins table dans la base de données MASTER. Pour chaque base de données à qui cette connexion
nouvellement ajoutée est fournie, elle est ajoutée à la sysusers table de cette base de données. Le mappage
syslogins entre la table et la table se trouve sur le champ sysusers SID.
Si une base de données utilisateur est déplacée vers un autre serveur, les valeurs SID sont transférés à partir du
serveur précédent. La sécurité de la base de données est rompte lorsque les connexions sur le deuxième serveur
ne sont pas créées avec les mêmes valeurs SID ou si la sécurité n’est pas correctement configurée en raison de
l’inconvenance des valeurs SID.
Pour plus d’informations, voir Comment résoudre les problèmes d’autorisation lorsque vous déplacez une base
de données entre des serveurs en cours d’exécution SQL Server.
Exigences de sécurité
Partage de sauvegarde
Configurez le partage réseau configuré pour contenir les sauvegardes du journal des transactions afin
d’avoir des autorisations de lecture/modification pour le compte sous lequel les services SQL Server (sur
le serveur secondaire configuré pour la copie des journaux de transaction) démarrent.
Le partage réseau configuré pour contenir les sauvegardes du journal des transactions doit être
configuré pour avoir des autorisations de lecture/modification pour le compte sous lequel les services
SQL Server, sur le serveur secondaire configuré pour la copie des journaux de transaction, sont en cours
de démarrage. Ce partage est accessible par la tâche Copier sur le serveur secondaire pour copier les
sauvegardes du journal des transactions dans le dossier local sur le serveur secondaire respectif. Le
travail Charger charge ensuite ces sauvegardes à partir du dossier local.
Envoi de journaux de trafic entre domaines
Si les ordinateurs qui exécutent SQL Server sont placés dans un environnement multi-domaines,
Microsoft recommande de configurer des relations d’confiance entre tous les domaines impliqués dans la
livraison des journaux de bord. Toutefois, si vous ne pouvez pas établir d’relations d’confiance entre les
domaines, vous pouvez utiliser la sécurité de connexion réseau pour la livraison des journaux. Reportez-
vous à la section de cet article qui traite de l’option de démarrage du compte réseau LocalSystem pour
SQL Server services associés.
Sélection du mode d’authentification Connecter pour surveiller le serveur
Vous pouvez sélectionner l’authentification Windows ou l’authentification SQL (par les serveurs
principaux et secondaires) pour vous connecter pour surveiller le serveur et mettre à jour les tables de
surveillance. Vous pouvez le sélectionner lors de la configuration de la livraison des journaux ou une fois
que vous avez installé l’envoi des journaux et qu’il est fonctionnel. Par défaut, les SQL Server
l’authentification Windows utilisateur ; toutefois, si vous sélectionnez l’authentification SQL, une nouvelle
log_shipping_monitor_probe de connexion SQL est créée sur les serveurs principal, secondaire et
moniteur s’il n’en existe pas. Si vous sélectionnez SQL l’authentification à cet effet, configurez SQL Server
pour utiliser l’option SQL et Windows’authentification.
Configuration de la sécurité sur le serveur secondaire pour les bases
de données de veille
Si vous configurez la base de données secondaire en mode veille, vous pouvez accéder à cette base de données
en lecture seule. En restaurant la base de données secondaire dans ce mode, cela peut fournir un moyen
d’exécuter des rapports hors connexion, ce qui permet de décharger une partie du travail à partir du système de
production. Toutefois, pour que la base de données de veille puisse prendre en charge la fonctionnalité de
lecture seule, vous de devez peut-être appliquer les mêmes paramètres de sécurité sur le serveur secondaire.
Étant donné que la base de données est en état de veille, vous ne pouvez même pas apporter de modifications
aux fins de configuration de la sécurité. Dans ce cas, vous devez créer toutes les connexions SQL Server avec les
mêmes valeurs SID sur le serveur secondaire. Windows connexions conservent automatiquement les mêmes
SID, car le GUID Windows est globalement unique, même lors de l’utilisation de plusieurs domaines.
Pour plus d’informations sur la création de connexions SQL avec le même SID sur différents serveurs, voir
Comment accorder l’accès aux connexions SQLsur une base de données de veille lorsque l’invité est désactivé
dans SQL Server .
Configuration de la sécurité lors de la modification du rôle

La procédure de modification de rôle pour la livraison des journaux de bord implique la promotion d’un serveur
secondaire à prendre le relais en tant que serveur principal. Vous pouvez le faire avec ou sans que le serveur
principal soit en ligne. Dans le cadre du changement de rôle, jusqu’à quatre procédures stockées sont exécutées.
L’une de ces procédures stockées, permet de corriger les valeurs SID des connexions qui résident dans la base
de données de veille juste avant qu’elles ne soit disponibles pour être utilisés comme base de données
sp_resolve_logins principale.
Dans le cadre de cette procédure stockée, un fichier de la table de l’ancien serveur principal est .bcp chargé
dans une table syslogins temporaire. Chaque connexion présente dans cette table temporaire est ensuite
comparée à la table de la base de données MASTER du serveur secondaire et à la table de la syslogins
sysusers base de données secondaire. Pour chaque connexion dans la table temporaire qui possède une
connexion avec le même nom dans la table et le même SID que celui de la table de la base de données
secondaire, le SID est corrigé (dans la base de données secondaire) en utilisant pour correspondre à celui qui se
trouve dans la syslogins sysusers sp_change_users_login syslogins table.
La configuration de la sécurité à l’aide de cette procédure stockée nécessite les opérations suivantes :
SQL connexions doivent déjà être créées sur le serveur secondaire. Pour ce faire, utilisez la tâche DTS De
connexions de transfert expliquée dans la rubrique SQL Server Books Online : Comment configurer et
effectuer la modification du rôle d’expédition de journaux .
Vous devez fournir un .bcp fichier de la table à partir du serveur syslogins principal. Ce fichier doit
être à jour, car un fichier non à jour peut entraîner l’échec de la correction sp_resolve_logins des
connexions.
Vous devez respecter les trois conditions suivantes avant de pouvoir réellement corriger les sp_resolve_logins
connexions dans la base de données secondaire :
1. Le nom de connexion du fichier de la table doit correspondre au nom de la table à .bcp syslogins
partir du serveur syslogins principal.
2. La valeur SID doit correspondre entre le fichier de connexion et .bcp la table dans la base de données
sysusers secondaire.
3. La valeur SID de la base de données secondaire doit être différente de la valeur SID de la table de la base
de données syslogins MASTER sur le serveur secondaire.
Si vous créez des connexions SQL Server comme décrit au Q303722, il n’est pas besoin d’exécuter cette
procédure stockée, car toutes les connexions ont déjà été présentées avec la même valeur SID dans la table
(dans la base de données MASTER sur le serveur secondaire) et la table (dans la base de données syslogins
sysusers secondaire).
Foire aux questions

Question : La livraison des journaux propage-t-elle automatiquement les modifications liées
à la sécurité sur un ser veur secondaire ?
Réponse : oui. Étant donné que toutes les modifications apportées aux tables système sont des opérations
consignées, celles-ci sont propagées automatiquement sur le ou les serveurs secondaires.
Question : Pouvez-vous avoir deux connexions sur le ser veur secondaire avec le même SID ?
J’en ai besoin, car j’utilise le même ordinateur SQL Ser ver pour gérer plusieurs bases de
données de veille à par tir de plusieurs ser veurs.
Réponse : non. SQL Server de sécurité ne permet pas d’avoir deux connexions avec le même SID. S’il
existe un conflit sur le SID lors de l’utilisation de la livraison de journaux avec plusieurs serveurs, la seule
façon de corriger cela consiste à abandonner la connexion en conflit sur le serveur principal, puis à la
créer avec un SID qui n’existe pas sur le serveur secondaire.
Le moniteur de connexion lève de manière
incorrecte le numéro d’erreur 14420 au lieu de 14421
lorsque la base de données secondaire n’est plus
synchronisée
Cet article vous aide à résoudre le problème où le moniteur Logshipping lève de manière incorrecte le numéro
d’erreur 14420 au lieu de 14421 lorsque la base de données secondaire n’est plus synchronisée.
Symptômes
Prenons la configuration suivante d’un environnement de livraison de journaux de route :
Le serveur A héberge l’instance du serveur principal et la base de données.
Le serveur B héberge l’instance de serveur secondaire et la base de données.
Le serveur C héberge une instance de serveur de surveillance dans laquelle le travail Moniteur de livraison
de journaux est configuré pour utiliser un compte proxy usurpé pour les connexions au serveur A et au
serveur B.
Lorsque vous utilisez cette configuration, le travail du moniteur de livraison des journaux de livraison lève à tort
le message d’erreur 14420 au lieu de 14421 lorsque la base de données secondaire n’est pas synchronisée. La
description de ces messages d’erreur SQL Server 2005 et SQL Server 2008 est la suivante :
Erreur : 14420, Gravité : 16, État : 1

La base de données primaire de copie des journaux de données %s.%s a un seuil de sauvegarde de %d
minutes et n’a pas effectué d’opération de journal de sauvegarde pendant %d minutes. Vérifiez les
informations du journal de l’agent et de l’écran de connexion.

La base de données secondaire de livraison de journaux %s.%s a un seuil de restauration de %d minutes et
n’est plus synchronisée. Aucune restauration n’a été effectuée pendant %d minutes. La latence restaurée est
de %d minutes. Vérifiez les informations du journal de l’agent et de l’écran de connexion.
Le message d’alerte 14221 indique que la différence entre l’heure actuelle (UTC) et la valeur de la table sur le
serveur moniteur est supérieure à la valeur définie pour le seuil d’alerte de restauration, tandis que le
last_restored_date_utc log_shipping_monitor_secondary message d’alerte 14220 indique que la différence
entre l’heure UTC et la valeur de la table sur le serveur moniteur est supérieure à la valeur définie pour le seuil
d’alerte de last_backup_date_utc log_shipping_monitor_primary sauvegarde.
Cause
Le problème survient en raison d’un problème dans l’interface utilisateur de la livraison des journaux de route.
Lorsque vous créez le travail de moniteur pour le secondaire, 14220 est transmis au lieu de 14221.
Résolution
Pour résoudre le problème, corrigez la valeur du paramètre pour la base de données secondaire en exécutant
l’instruction suivante sur le serveur @threshold_alert moniteur (serveur C) :
use master
go
sp_change_log_shipping_secondary_database @secondary_database = 'dbname', @threshold_alert = 14421
Description du message d’erreur 14420 et du message d’erreur 14421 qui se produisent lorsque vous utilisez la
livraison des journaux de SQL Server
Comprendre la .NET Framework requise pour les
différentes versions de SQL Server
Cet article décrit la .NET Framework requise pour différentes versions SQL à partir de SQL Server 2005.
Server 2008, SQL Server 2005
Résumé
Différentes versions de Microsoft SQL Server ont des versions .NET Framework différentes en tant que
conditions préalables à l’installation, et la procédure d’installation du .NET Framework peut être différente sur
différents systèmes d’exploitation. Pour les versions plus récentes SQL Server, ces informations sont couvertes
dans le cadre des rubriques relatives à la configuration matérielle et logicielle requise, comme répertorié ci-
dessous :
Configuration matérielle et logicielle requise pour SQL Server 2019
Pour les versions SQL Server 2008R2 et versions antérieures, la .NET Framework requise varie en fonction de
l’édition de SQL Server que vous installez. Cet article décrit ces conditions requises et vous fournit les
informations nécessaires pour pouvoir installer les .NET Framework requises.
1. Utilisez Table 1 les conditions préalables de Microsoft DotNET Framework pour SQL Server pour vérifier la
.NET Framework requise pour la version et l’édition que vous installez.
2. Vérifiez si le .NET Framework est déjà inclus dans le système d’exploitation ou si vous devez le télécharger
séparément des téléchargements Microsoft répertoriés dans Table 2 la section .NET Frameworks for SQL
Server sur différents systèmes d’exploitation et la section liens de téléchargement.
3. Utilisez la dernière colonne pour vérifier si des procédures spéciales sont requises pour installer
l’infrastructure Table 2 sur le système d’exploitation cible. Si l’entrée est Oui, recherchez les procédures
nécessaires dans les sections ultérieures de ce document. Si l’entrée est Non, vous pouvez télécharger
l’infrastructure correspondante à partir du lien correspondant et Table 2 l’installer sur le système
d’exploitation cible.
Microsoft .NET Framework conditions préalables pour SQL Server

2008 R2 et les versions antérieures de SQL Server
Le tableau suivant récapitule les exigences de version .NET Framework pour les différentes versions et éditions
de SQL Server et explique si le produit est inclus dans le support d’installation et s’il est installé dans le cadre de
l’installation.
Tableau 1 :
. VERSIO N DE N ET IN STA L L É DA N S L E C A DRE
SQ L VERSIO N O U ÉDIT IO N F RA M EW O RK IN C L US AVEC L E P RO DUIT ? DE L’IN STA L L AT IO N ?
SQL Server 2005 (toutes les 2.0 Oui Non

éditions)
SQL Server 2008 express 2.0 SP2 Non Non

(cœur)
SQL Server 2008 sur 2.0 SP2 Oui Oui

Windows Server 2003 (64
bits), IA-64
SQL Server 2008 (toutes les 3.5 SP1 Oui Oui

autres éditions)
Pour SQL Server 2008 et pour les installations de cluster de SQL Server 2008 R2 et Express Edition, le
programme d’installation n’installe pas .NET Framework 3.5 Service Pack 1 sur les systèmes qui exécutent
Windows Server 2008 R2 Edition. Pour plus d’informations sur l’activer .NET Framework 3.5 SP1 sur ces
systèmes, voir la section Comment installer ou activer .NET Framework 3.5 SP1 sur Windows.
.NET Frameworks for SQL Server on Windows Server 2008 R2 and

earlier operating systems
Le tableau suivant indique si le .NET Framework requis pour SQL Edition et la version que vous installez est
inclus dans le système d’exploitation cible. Le tableau indique également si des étapes supplémentaires sont
nécessaires pour installer ou activer l’infrastructure sur le système d’exploitation correspondant et fournit un
lien de téléchargement pour les fichiers redistribuables .NET Framework correspondants.
Tableau 2 :
DES
P RO C ÉDURES
SP ÉC IA L ES
SO N T - EL L ES
PA R DÉFA UT REQ UISES
IN C L US AVEC AVEC L ES REDIST IST R P O UR
L E SY ST ÈM E SY ST ÈM ES IN STA L L É OU IN STA L L ER L E
VERSIO N DE N UM ÉRO DE D’EXP LO ITAT I D’EXP LO ITAT I AVEC VISUA L T ÉL ÉC H A RGE REDIST IST ISM
. N ET VERSIO N ON ON ST UDIO . N ET R L E L IEN E?
2.0 2.0.50727.42 Windows Serv Aucun Microsoft 2.0 Non

er 2003 R2 Visual
Studio 2005
3.5 SP1 3.5.30729.1 Windows Serv Aucun Aucun 3.5 SP1 Oui, pour
er 2008 R2 Windows
Server 2008
R2
Comment installer ou activer .NET Framework 3.5 SP1 sur Windows

Pour installer .NET Framework sur Windows 8 et les versions ultérieures du système d’exploitation, voir Installer
le .NET Framework 3.5sur Windows 10, Windows 8.1 et Windows 8 .
Dans Windows Server 2008 R2, la .NET Framework est une fonctionnalité et son installation est différente des
versions précédentes du système d Windows d’exploitation. La procédure suivante explique comment vérifier
que le .NET Framework 3.5.1 est installé. La procédure explique également comment déterminer si le .NET
Framework n’est pas installé et comment vous pouvez l’ajouter dans ces environnements.
Comment déterminer si le .NET Framework 3.5 SP1 est installé

Pour déterminer si le .NET Framework 3.5.1 est installé sur Windows Server 2008 R2, suivez les étapes suivantes
:
1. Sélectionnez Démarrer, Sélectionnez Outils d’administration, puis Sélectionnez Gestionnaire de
ser veur.
2. Sélectionnez les fonctionnalités pour afficher toutes les fonctionnalités installées dans le volet sur le côté
droit.
3. Vérifiez que .NET Framework 3.5.1 figure dans la liste des fonctionnalités installées.
Si .NET Framework 3.5.1 n’est pas répertorié comme fonctionnalité installée, utilisez l’une des méthodes
suivantes pour l’installer.
Méthode 1 : utiliser le Gestionnaire de serveur
1. Dans le Gestionnaire de ser veur, sélectionnez Ajouter des fonctionnalités pour afficher la liste des
fonctionnalités possibles.
2. Dans l’interface Sélectionner des fonctionnalités, développez .NET Framework l’entrée Fonctionnalités
3.5.1.
3. Après avoir développé .NET Framework fonctionnalités 3.5.1, vous voyez deux cases à cocher. Une case à
cocher est .NET Framework 3.5.1 et l’autre est pour l’activation WCF. Cliquez pour cocher la case en
regard .NET Framework 3.5.1, puis sélectionnez Suivant .
NOTE
Si vous ne développez pas l.NET Framework 3.5.1 Features et vérifiez-le, l’Assistant Ajout de fonctionnalités
suivant est démarré :
Si l’Assistant démarre, sélectionnez Annuler, développez .NET Framework Fonctionnalités 3.5.1, puis
cochez la case .NET Framework 3.5.1.
4. Vous ne pouvez pas installer .NET Framework 3.5.1, sauf si les services et fonctionnalités de rôle
requis sont également installés.
5. Dans la sélection Confirmer l’installation, examinez les sélections, puis sélectionnez Installer.
6. Laissez le processus d’installation se terminer, puis sélectionnez Fermer.
Méthode 2 : Utiliser Windows PowerShell
1. Cliquez sur Démarrer, sélectionnez Tous les programmes, puis sélectionnez Accessoires.
2. Développez Windows PowerShell, cliquez avec le bouton Windows PowerShell, puis sélectionnez
Exécuter en tant qu’administrateur. sélectionnez Oui dans la zone Contrôle de compte d’utilisateur.
3. À l’invite de commandes PowerShell, tapez les commandes suivantes, puis appuyez sur Entrée après chaque
commande :
Import-Module ServerManager
Add-WindowsFeature as-net-framework
NOTE
Pour plus d’informations, voir la capture d’écran :
Références
Log WebLog de Stebner
.NET Framework Prise en charge Windows Server 2008
Tentative d’effectuer une erreur d’opération non
autorisée lorsque vous avez installé ou mis à jour
SQL Server instances
Cet article vous aide à résoudre le problème d’échec de la configuration ou de la mise à jour SQL Server
instances de données et renvoie un message d’erreur.
S’applique à : SQL Server 2019 sur Windows, SQL Server 2017 sur Windows, SQL Server 2016, SQL Server
2014, SQL Server 2012
Symptômes
Vous avez un ordinateur qui exécute Windows 10, version 20H2 et le navigateur Microsoft Edge de
n’importe quelle version de la version 84.0.522.52 à 86.0.622.55.
Vous essayez de mettre à jour une instance existante de Microsoft SQL Server 2012 à 2019, ou d’installer
une nouvelle instance SQL Server avec une mise à jour (slipstream).
Dans ce scénario, un échec se produit pendant le processus de mise à jour et vous recevez le message d’erreur
suivant :
Tentative d’effectuer une opération non autorisée.
En outre, une entrée est enregistrée dans le fichier journal d’installation de SQL Server, Detail.txt, qui indique que
l’échec s’est produit lors de la tentative d’ouverture de la sous-clé de Registre Microsoft Edge .
Cause
Le SQL Server du programme d’installation ne peut pas émaner la sous-clé de Registre suivante :
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft Edge
Résolution
Pour résoudre ce problème, utilisez l’une des méthodes suivantes, selon le cas :
Méthode 1
Si vous exécutez Windows 10 64 bits, version 20H2 (19042.xxx), vous devez installer la version
86.0.622.56 du navigateur Edge ou une version ultérieure qui inclut le correctif pour ce problème. Pour
voir le numéro de version dans Edge, sélectionnez Paramètres > à propos de Edge.
Pour mettre à jour manuellement le navigateur Edge, suivez les étapes suivantes :
1. Démarrer Microsoft Edge .
2. Sélectionnez le Paramètres (ellipses) dans le coin supérieur droit.
3. Dans le menu Paramètres, sélectionnez Aide et commentaires > sur Microsoft Edge .
NOTE
Edge recherche automatiquement les mises à jour.
4. Pour terminer l’installation de la mise à jour Edge, sélectionnez Redémarrer.

Méthode 2
IMPORTANT
Suivez attentivement les étapes de cette méthode. Des problèmes graves peuvent se produire si vous modifiez le
Registre de façon incorrecte. Avant de modifier le Registre, sauvegardez-le pour restauration en cas de problèmes.
Ajoutez l’autorisation Contrôle total au compte Administrateurs. Pour cela, procédez comme suit :
1. Démarrez l’Éditeur du Registre. Pour ce faire, sélectionnez Démarrer, tapez regedit, puis
sélectionnez Éditeur du Registre dans les résultats de la recherche.
2. Dans l’Éditeur du Registre, cliquez avec le bouton droit sur
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft Edge la sous-
clé, puis sélectionnez Autorisations.
3. Dans la fenêtre Autorisations qui s’ouvre, sélectionnez Avancé.
4. En haut de la fenêtre Sécurité avancée Paramètres, sélectionnez Modifier en dessous du
propriétaire répertorié.
5. Dans la fenêtre Sélectionner un utilisateur, un ordinateur, un compte de service ou un groupe,
tapez le nom de votre compte d’utilisateur Windows (ou votre adresse de messagerie si vous avez
un compte Microsoft) dans la zone Entrer le nom de l’objet à sélectionner, puis sélectionnez Vérifier
les noms pour valider le nom du compte.
6. Sélectionnez deux fois OK .
7. Dans la fenêtre Autorisations, sélectionnez le groupe Utilisateurs, puis cochez la case
Autoriser les autorisations Contrôle total.
NOTE
Pour accorder des autorisations uniquement à votre compte d’utilisateur au lieu du groupe Utilisateurs,
sélectionnez Ajouter, suivez les étapes de l’Assistant Ajout, puis accordez les autorisations Contrôle total à
ce compte.
8. Sélectionnez OK pour revenir à la fenêtre principale de l’Éditeur du Registre.
SQL Server Le programme d’installation s’attend à ce que les administrateurs ont des autorisations d’accès en
lecture/écriture sur toutes les sous-clés sous , où le programme d’installation recherche les mises à jour SQL
Server HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall installées. Toutefois, dans
certains cas, le système fournit aux administrateurs uniquement des autorisations de lecture sur les sous-clés,
comme c’est le cas, par exemple, sur Microsoft Edge.
Une prochaine SQL Server mise à jour de maintenance modifiera l’exigence d’accès afin que le programme
d’installation n’a besoin que d’autorisations de lecture sur toutes les sous-clés sous
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall .
Description du dossier Cache de mise à jour dans
SQL Server
Cet article explique pourquoi ce dossier est créé et à quoi il est utilisé.
Server 2017 sur Windows (toutes les éditions)
Résumé
Le dossier Cache de mise à jour Microsoft SQL Server est trouvé à l’emplacement :
C:\Program Files\Microsoft SQL Server\<m.n>\Setup Bootstrap\Update Cache .
Cet article fournit des informations pour vous aider à comprendre pourquoi ce dossier est créé et à quoi il est
utilisé.
Quand ce dossier est-il créé et à quoi ser t-il ?
Lorsque vous installez une mise à jour SQL Server (mise à jour cumulative, mise à jour critique ou
Service Pack), le support d’installation de mise à jour est mis en cache dans SQL Server cache de mise à
jour. Les entrées sont créées à partir du contenu du dossier multimédia mis en cache et sont utilisées
pour désinstaller (si nécessaire) la mise à jour la plus récente qui a été appliquée à Add/Remove Programs
un composant particulier. Le dossier peut contenir plusieurs mises à jour antérieures, ce qui permet la
suppression séquentielle de ces mises à jour si nécessaire.
Une variante de ce modèle se produit lorsqu’un composant a été installé par un fichier MSI autonome au
lieu de SQL Server le programme d’installation. Ces composants sont remplacés sur place en remplaçant
le fichier MSI précédent par le nouveau, sans conserver un historique des versions précédentes. Le fichier
MSI d’origine est requis pour les opérations de désinstallation et de réparation.
Quand ce dossier est-il nettoyé ou supprimé ?
Lorsque tous les correctifs sont supprimés de toutes les instances ou lorsque le produit est désinstallé.
Pourquoi le dossier continue-t-il à augmenter en taille ?
La taille du dossier augmente à chaque mise à jour appliquée à SQL Server instance. Cette croissance se
produit car chaque version antérieure doit être mise en cache. Ce comportement garantit que vous
pouvez toujours accéder à une mise à jour antérieure si nécessaire.
Que se passe-t-il si vous supprimez ce dossier ou si vous supprimez son contenu ?
Si le dossier cache de mise à jour ou certains correctifs sont supprimés de ce dossier, vous ne pouvez plus
désinstaller une mise à jour de votre instance SQL Server, puis revenir à une version de mise à jour
antérieure. Dans ce cas, les entrées pointent vers des binaires non existants et, par conséquent, le
processus Add/Remove Programs de désinstallation ne fonctionne pas. Par conséquent, Microsoft vous
encourage vivement à conserver le dossier et son contenu intacts.
S’applique à
SQL Server Web 2012
SQL Server Web 2014
SQL Server Web 2016
Message d’erreur lorsque vous essayez d’installer
SQL Server 2008 R2
Cet article vous aide à résoudre les diverses erreurs qui se produisent lorsque vous essayez d’installer SQL
Server 2008 R2.
Version du produit d’origine : SQL Server 2008 R2 Original KB number: 2449398
Symptômes
Lorsque vous essayez d’installer Microsoft SQL Server 2008 R2, vous recevez un ou plusieurs des messages
d’erreur suivants ou vous recevez un ou plusieurs des symptômes suivants. En outre, vous ne pouvez pas
poursuivre l’installation.
Messages d’erreur ou symptômes d’installation
Le système ne peut pas ouvrir l’appareil ou le fichier spécifié.
Setup.rll n’est pas conçu pour s’exécuter sur Windows ou il contient une erreur.
Le programme d’installation a rencontré une erreur inattendue lors de l’installation de ce package.
Setup.exe badimage.
Une erreur s’est produite pendant le processus de connexion en raison d’un support non bon.
Le fichier cabinet « Sql.cab » requis pour cette installation est endommagé et ne peut pas être utilisé.
Erreur de lecture à partir d’un fichier
Symptôme 1
Vous ne pouvez pas sélectionner l’installation x64 bits.
Symptôme 2
Certains composants sont manquants dans la page Sélectionner un composant du programme
d’installation.
Messages d’erreur dans SQL Server fichiers journaux du programme d’installation
NOTE
Pour plus d’informations SQL Server les fichiers journaux du programme d’installation, consultez la rubrique SQL Server
Books Online: View and Read SQL Server Setup Log Files.
Erreur 2337
SQL Server’installation a échoué.
Une erreur réseau s’est produite lors de la tentative de lecture du fichier.
La localisation ENU n’est pas prise en charge par cet SQL Server Multimédia.
Le handle de démarrage Moteur de base de données de l'Summary.txt n’a pas pu être trouvé
La source du fichier « p76pctiy.dll » n’est pas compressée (sql_engine_core_shared)
Message d’erreur de l’Observateur d’événements
Échec de l’initialisation du timer SQLSQM.
Cause
Ce problème peut se produire pour l’une des raisons suivantes :
Le support d’installation est endommagé.
La source d’installation est endommagée.
Résolution
Pour résoudre le problème, utilisez l’une des méthodes suivantes :
Téléchargez de SQL Server image à partir de l’emplacement d’origine, puis réexécutez le programme
d’installation.
Si vous avez installé SQL Server sur un réseau d’ordinateur, réinstallez-le à partir d’un lecteur local, puis
réexécutez le programme d’installation.
Renommons le fichier Setup.rll. Pour cela, procédez comme suit :
1. Ouvrez Windows Explorer. Pour ce faire, cliquez sur Démarrer, sur Tous les programmes, sur
Accessoires, puis sur Windows Explorer.
2. Recherchez, puis cliquez sur le dossier :
C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\SQLServer2008R2\resources\1033 .
3. Cliquez avec le bouton droit sur Setup.rll, puis cliquez sur Renommer.
Voir l’image
4. Tapez setup.rll.old, puis appuyez sur Entrée .

5. Réexécutez le programme d’installation.
Si vous utilisez une version localisée de SQL Server, vous pouvez modifier les paramètres du système
d’exploitation pour prendre en charge les versions localisées. Pour plus d’informations sur la modification
des paramètres du système d’exploitation, voir Comment : modifier les paramètres du système
d’Paramètres pour prendre en charge les versions localisées.
IMPORTANT
Les installations de différentes versions linguistiques de SQL Server instances sur le même ordinateur ne sont pas
pris en charge.
Les messages d’erreur mentionnés dans la section Symptômes peuvent avoir d’autres causes. Si les étapes de la
section Résolution ne résolvent pas le problème, vous pouvez être confronté à un autre problème.
Pour plus d’informations sur l’installation SQL Server 2008 R2, voir How to: Install SQL Server 2008 R2
(Setup).
Pour plus d’informations sur les problèmes connus lors de l’installation de SQL Server sur Windows 7 ou
sur Windows Server 2008 R2, voir Problèmes connus lors de l’installation de SQL Server sur Windows 7
ou Windows Server 2008 R2.
S’applique à
Code d’erreur du journal des événements
d’application 1642 même si la mise à jour SQL
Server été appliquée avec succès
Cet article fournit plus d’informations sur le message d’erreur 1642 qui est signalé dans le journal des
événements de l’application si la mise à jour SQL Server mise à jour est appliquée avec succès.
Version du produit d’origine : SQL Server 2016, SQL Server 2014, SQL Server 2012 Developer, SQL Server
2012
Symptômes
Lorsque vous installez une mise à jour cumulative sur Microsoft SQL Server, l’installation peut se terminer
correctement. Toutefois, il se peut que vous trouviez l’erreur suivante consignée dans le journal des événements
d’application du système :
Source: MsiInstaller
Date: date time
Event ID: 1024
Task Category: None
Level: Error
Keywords: Classic
User: SYSTEM
Computer: host_name
Description:
Product: SQL Server 2016 Database Engine Services - Update ' {DDCDC225-F14E-411F-925A-7CF68238240F}' could
not be installed. Error code 1642. Windows Installer can create logs to help troubleshoot issues with
installing software packages. Use the following link for instructions on turning on logging support:
http://go.microsoft.com/fwlink/?LinkId=23127
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="MsiInstaller" />
<EventID Qualifiers="0">1024</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="date time" />
< EventRecordID>463708</EventRecordID>
< Channel>Application</Channel>
<Computer>host_name</Computer>
<Security UserID="user_id" />
</System>
<EventData>
<Data>SQL Server 2016 Database Engine Services</Data>
< Data>{DDCDC225-F14E-411F-925A-7CF68238240F}</Data>
<Data>1642</Data>
<Data>(NULL)</Data>
<Data>(NULL)</Data>
<Data>(NULL)</Data>
<Data>
</Data>
<Binary>7B42463645333843342D443830312D343530382D394536312D3236463545303544363045437D207B44444344433232352D46
3134452D343131462D393235412D3743463638323338323430467D2031363432</Binary>
</EventData>
</Event>
Cause
Ce problème se produit dans plusieurs scénarios dans lesquels un échec du package du programme
d’installation MSI est consigné dans le journal des événements de l’application, car l’appel d’installation à l’API
ne reçoit pas de liste de fichiers à partir du MsiGetPatchFileList MSP (Windows Installer patch file).
Résolution
Vous pouvez ignorer ce message en toute sécurité dans le journal des événements de l’application lorsque les
conditions suivantes sont vraies :
Le programme d’installation SQL Server mise à jour cumulative s’est correctement terminé.
Aucun message d’erreur n’est enregistré dans Summary.txt fichier.
Pour plus d’informations, voir View and Read SQL Server Setup Log Files.
Erreur si vous modifiez le chemin d’accès au
répertoire des composants partagés sur l’écran
Sélection de fonctionnalité lorsque vous installez
SQL Server 2008 sur un ordinateur
Cet article vous aide à résoudre le problème qui se produit lorsque vous modifiez le chemin d’accès dans le
répertoire des composants partagés de l’écran Sélection des composants de l’Assistant Installation d’Install SQL
Server 2008.
Symptômes
Vous essayez d’installer Microsoft SQL Server 2008 sur un ordinateur exécutant une version Itanium (IA-64) de
Windows. Toutefois, si vous modifiez le chemin d’accès dans le répertoire des composants partagés de l’écran
Sélection des composants de l’Assistant Installation d’Install SQL Server 2008, vous recevez le message d’erreur
suivant lorsque vous cliquez sur Suivant :
La INSTANCESHAREDWOWDIR valeur de ligne de commande n’a pas été spécifiée.
Cause
Ce problème se produit car l’Assistant Installation SQL Server 2008 ne vous permet pas de spécifier le chemin
d’accès au dossier InstallSharedWowDir. Ce chemin d’accès est requis pour installer des composants partagés
dans l’installation SQL Server 2008. Vous pouvez uniquement spécifier le chemin d’accès au dossier
InstallSharedDir.
NOTE
Pour plus d’informations sur les paramètres INSTALLSHAREDDIR et INSTALLSHAREDWOWDIR, consultez la section Plus
d’informations.
Pour contourner ce problème, utilisez l’une des méthodes suivantes.
Méthode 1 : Utiliser le chemin d’accès par défaut

Si vous pouvez utiliser le chemin d’accès par défaut pour les composants partagés, ne modifiez pas le chemin
d’accès dans la zone Répertoire des composants partagés de l’écran Sélection des composants de l’Assistant
Installation d’Install SQL Server 2008. Si vous modifiez le chemin d’accès, vous recevez le message d’erreur
spécifié dans la section Symptômes. Si cela se produit, cliquez sur Annuler, puis redémarrez l’installation SQL
Server 2008.
Méthode 2 : utiliser le paramètre d’installation
/INSTALLSHAREDWOWDIR
Si vous devez spécifier un autre emplacement de dossier pour les composants partagés, suivez les étapes
suivantes :
1. Démarrez l SQL Server 2008 à l’aide du paramètre /INSTALLSHAREDWOWDIR à l’invite de commandes. Le
paramètre spécifie l’emplacement où installer les fichiers de composants /INSTALLSHAREDWOWDIR partagés
32 bits.
2. Dans l’écran Sélection des composants, spécifiez le dossier pour installer les fichiers de composants
partagés 64 bits dans le répertoire des composants par tagés.
Lorsque vous installez SQL Server 2008 sur un ordinateur exécutant une version 64 bits de Windows, les
fichiers de composants partagés sont installés par les paramètres d’installation dans deux dossiers par défaut
distincts, comme répertorié dans le tableau suivant :
PA RA M ÈT RE D’IN STA L L AT IO N DO SSIER PA R DÉFA UT F IC H IERS IN STA L L ÉS
INSTALLSHAREDDIR Program Files\Microsoft SQL Fichiers de composants partagés 64

Server bits
INSTALLSHAREDWOWDIR Program Files(x86)\Microsoft SQL Fichiers de composants partagés 32

Server bits
Pour plus d’informations sur ces paramètres et d’autres paramètres d’installation pour l’installation SQL Server,
voir le fichier SQL Server Setup Help (S10ch_setup.chm). Le fichier S10ch_setup.chm se trouve dans le dossier
du DVD SQL Server 2008 : drive:\IA64\Help\1033 .
NOTE
L’espace réservé au lecteur est la désignation de lecteur de votre lecteur DVD.
Références
How to: Install SQL Server 2008 from the Command Prompt
Message d’erreur expiré pour la période
d’évaluation lors de l’SQL serveur
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez des outils Microsoft SQL Server
tels que SQL Server Management Studio (SSMS) ou SQL Profileur.
Symptômes
Vous pouvez rencontrer le message d’erreur suivant lorsque vous utilisez des outils SQL Server tels que SQL
Server Management Studio (SSMS) ou SQL Profileur :
La période d’évaluation a expiré. Pour plus d’informations sur la mise à niveau de votre logiciel d’évaluation,
consultez la https://www.microsoft.com/sql/howtobuy
En outre, vous pouvez voir le message d’erreur suivant lorsque vous essayez de vous connecter à une
installation SQL Server instance expirée :
Une erreur liée au réseau ou à l’instance s’est produite lors de l’établissement d’une connexion SQL Server.
Le serveur n’a pas été trouvé ou n’est pas accessible. Vérifiez que le nom de l’instance est correct et que SQL
Server est configuré pour autoriser les connexions distantes. (fournisseur : fournisseur de canaux nommé,
erreur : 40 - Could not open a connection to SQL Server)
NOTE
Le message d’erreur de connectivité est un message générique et n’est pas toujours lié à une installation expirée d’SQL
Server instance.
Cause
Le problème se produit généralement lorsque vous exécutez une instance d’évaluation de SQL Server et que la
période d’évaluation a expiré.
NOTE
Dans le cas de SQL Server 2008, vous pouvez voir ce message d’erreur même après la mise à niveau vers une version
sous licence en raison d’un bogue connu.
Résolution
Cas 1 : vous avez une version expirée de l’SQL d’évaluation du ser veur
NOTE
Cela s’applique également aux scénarios où seuls les outils sont installés à partir d’une version d’évaluation.
Pour mettre à niveau l’édition d’évaluation vers une édition de vente au détail, vous pouvez consulter les
rubriques suivantes dans Books Online :
Mise à niveau vers une autre édition de SQL Server 2012 (installation)
Mises à niveau de & version prise en charge (SQL Server 2016)
NOTE
Dans l’une de ces rubriques, vous pouvez sélectionner l’outil de sélection de version dans la partie
supérieure pour sélectionner une rubrique pertinente pour votre environnement. For SQL Server 2008
you can also refer to the KB article: Upgrade to a Different Edition of SQL Server (Setup). For SQL Server
2005, check the following KB article Upgrade to a Different Edition of SQL Server (Setup)
Cas 2 : passage d’une édition d’évaluation d’entreprise à une édition express

Dans certains cas, vous pouvez décider de passer d’une édition d Enterprise d’évaluation à une édition
Express. Étant donné qu’aucun chemin de mise à niveau n’est disponible, vous pouvez consulter l’article
suivant sur le déplacement de vos bases de données utilisateur de l’édition d’évaluation vers l’édition
express.
Scénario 1 : vous pouvez toujours démarrer votre version d SQL Ser ver d’évaluation
Consultez la rubrique suivante dans SQL Server Books Online sur la façon de déplacer des bases
de données utilisateur : Détachement et attachement de base de données (SQL Server)
NOTE
La taille de base de données relationnelle maximale SQL éditions Express est de 10 gigaoctets (Go).
Scénario 2 : vous ne pouvez pas démarrer une édition expirée de votre édition d
Enterprise d’évaluation car la période d’évaluation a expiré
Si la taille de la base de données est inférieure à 10 gigaoctets (Go), vous pouvez suivre les étapes
suivantes :
1. Installez une édition express du produit.
2. Recherchez les fichiers de données (mdf et ldf) de votre base de données.
3. Attachez ces fichiers à l SQL édition express.
NOTE
Avant d’attacher les fichiers de données à SQL Express Edition, si ces fichiers se trouvent
actuellement dans le répertoire de données par défaut de l’ancienne instance, vous pouvez
déplacer les fichiers de base de données de leur emplacement actuel vers le nouveau répertoire de
données pour la nouvelle installation ou vers un autre emplacement sur le serveur.
Cas 3 : vous êtes en cours d’exécution dans ce problème dans les environnements SQL
Ser ver 2008 même après la mise à niveau vers une version sous licence de SQL Ser ver
Dans ce cas, vous avez les options suivantes.
NOTE
Vous remarquerez également ce problème sur les systèmes où vous avez installé à l’origine l’édition d’évaluation
des outils partagés, puis la mise à niveau vers une version sous licence.
Option 1
Appliquez le Service Pack 1 SQL Server 2008 avant de mettre à niveau l’édition d’évaluation vers
une édition sous licence.
NOTE
Si vous avez déjà effectué la mise à niveau de l’édition avant d’appliquer le Service Pack 1 pour SQL server
2008, vous devez suivre toutes les étapes mentionnées dans la section Option 2 pour résoudre le
problème. Le Service Pack évitera uniquement les problèmes qui impliquent des mises à niveau d’édition
ultérieures.
Option 2
Utilisez la procédure suivante pour résoudre le problème :
IMPORTANT
Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre.
Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par
conséquent, veillez à suivre ces étapes scrupuleusement. Pour une meilleure protection, sauvegardez le
registre avant de le modifier. Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations
sur la façon de la back up et de la restauration du Registre, voir l’article suivant : Comment le restaurer
dans Windows.
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapez Regedt32, puis cliquez sur OK.
2. Recherchez et cliquez sur la clé suivante dans l’Éditeur du Registre :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\ConfigurationState
3. Dans le volet droit de l’Éditeur du Registre, sélectionnez la valeur CommonFiles DWord.

4. Dans le menu Edition , cliquez sur Modifier .
5. Tapez 3, puis cliquez sur OK.
6. Quittez l’Éditeur du Registre.
7. Réexécutez la procédure Mise à niveau vers une autre édition de SQL Server (installation)
pour terminer la mise à niveau de tous les composants vers une édition sous licence.
Vérifier si la SSMS expirera

1. Démarrez SQL Ser ver Management Studio .
2. Sélectionnez le menu Aide, puis le sous-menu À propos de... dans la liste. Vous allez aborder le problème
décrit dans l’article si le composant Microsoft SQL Ser ver Management Studio’expire dans les jours « x
» qui s’y viennent.
S’applique à
SQL Server Web 2008
SQL Server Web 2012
La vérification de la règle Fusion ATL échoue
lorsque vous essayez de désinstaller une instance
SQL Server 2008 ou lorsque vous essayez de
supprimer un nœud SQL Server 2008 d’un cluster
deover
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez de désinstaller une instance
SQL Server ou lorsque vous essayez de supprimer un nœud SQL Server d’un cluster deover.
Symptômes
Lorsque vous essayez de désinstaller une instance Microsoft SQL Server ou lorsque vous essayez de supprimer
un nœud SQL Server d’un cluster deover, la vérification de la règle Fusion ATL échoue. Lorsque cela se produit,
le programme d’installation échoue et vous recevez le message d’erreur suivant : un redémarrage de
l’ordinateur est nécessaire en raison d’une fusion ATL rompue. Vous devez redémarrer votre ordinateur avant de
continuer.
Cause
Ce problème se produit lorsque les conditions suivantes sont remplies :
Le SQL Server fichiers de support du programme d’installation a été supprimé par la tentative de
désinstallation actuelle ou par l’action de suppression de nœud.
L’assembly Fusion ATL n’a pas été installé dans le Global Assembly Cache (GAC). Étant donné qu’une
désinstallation ou une action de suppression de nœud n’installe pas le composant d’installation SQL
Server Setup Support Files, la règle Fusion ATL échoue.
Pour contourner ce problème, installez manuellement les fichiers de support du programme d’installation SQL
Server à partir du support d’installation avant d’exécuter la désinstallation ou l’action de suppression du nœud
du fichier SQL Server Setup. Pour cela, procédez comme suit :
1. Insérez le support d SQL Server d’installation d’origine.
2. Dans Windows Explorer, recherchez le fichier Sqlsupport.msi dans le dossier suivant
Drive:\Platform\setup :
NOTE
L’espace réservé au lecteur représente la lettre de lecteur du support d’installation. L’espace réservé de plateforme
représente l’architecture de processeur de votre installation. Par exemple, l’architecture du processeur peut être
désignée comme x86, x64 ou IA-64.
3. Double-cliquez sur Sqlsupport.msi fichier.
4. Suivez les instructions pour terminer l’installation des fichiers de SQL Server du programme
d’installation.
Les UC SQL Server non applicables sont
répertoriées dans WSUS, MU ou ConfMgr
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez les mises à jour logicielles
WSUS, Microsoft Update (MU) ou Microsoft System Center Configuration Manager pour appliquer des mises à
jour à Microsoft SQL Server.
Version du produit d’origine : SQL Server 2016, SQL Server 2014, SQL Server 2012 Enterprise, SQL Server
2012, SQL Server 2017 sur Windows (toutes les éditions), SQL Server 2014
NOTE
La logique de détection de Microsoft Update est mise à jour pour les nouvelles mises à jour cumulatives et les mises à
jour GDR à l’avenir. Cet article est valide pour les publication de maintenance suivantes :
SQL Server de mise à jour SQL Server 2014 : toutes les publications de mise à jour un jour
SQL Server 2016 : toutes les publications cu pour les lignes de base RTM et SP1. SP2 baseline CU releases through
CU13
SQL Server 2017 : publication de cu cu de référence RTM via CU18
SQL Server 2019 : Aucun
Toutes les publication de sécurité jusqu’en 2020
Pour plus d’informations sur les mises à jour de la logique de détection pour les nouvelles mises à jour cu et les
futures mises à jour de sécurité, voir Mises à jour de la logique de détection Microsoft Update pour la
maintenance SQL Server.
Symptômes
Lorsque vous utilisez les mises à jour logicielles WSUS, MU ou System Center Configuration Manager pour
appliquer des mises à jour à SQL Server, vous remarquez que certaines des mises à jour cumulatives
répertoriées ne s’appliquent pas à votre installation SQL Server.
Cause
SQL Server mises à jour sont publiées dans le service de mise à jour. Les canaux de distribution tels que
Windows service de mise à jour automatique intégré et system Configuration Manager Software Updates
Management peuvent analyser update pour SQL Server mises à jour.
Chaque SQL Server mise à jour répertoriée dans Update possède une liste de règles d’applicabilité qui sont
évaluées afin de déterminer si une mise à jour est applicable.
Pour qu’une mise à jour un jour soit affichée comme applicable à une installation SQL Server, au moins une
mise à jour à jour doit être installée sur cette ligne de base des mises à jour.
NOTE
La ligne de base dans ce contexte fait référence à une version RTM ou Service Pack.
Par exemple, envisagez un scénario dans lequel la dernière mise à jour cumulative pour SQL Server 2014
Service Pack 2 (SP2) est la mise à jour cumulative 6 (CU6). Actuellement, la dernière mise à jour installée sur le
système est SQL Server 2014 SP2. Vous exécutez une analyse de mise à jour du système et vous remarquez
qu’aucune UTIL n’est répertoriée comme applicable. Vous téléchargez et installez manuellement SQL Server
mise à jour cumulative 2014 SP2 1. Vous exécutez à nouveau l’analyse de la mise à jour et vous remarquez
maintenant que SQL Server 2014 SP2 cumulative 6 est répertorié comme applicable.
Résolution
Pour résoudre ce problème, téléchargez et installez manuellement SQL Server mise à jour cumulative qui
s’applique à la build de référence. Une fois cette mise à jour effectuée, la dernière mise à jour cumulative publiée
dans la mise à jour est répertoriée le cas échéant.
Ce comportement est inhérent au produit. L’administrateur système peut installer une mise à jour un jour pour
déterminer la branche de maintenance à SQL Server suivre.
Chaque ligne de base de maintenance (RTM ou Service Pack) comprend deux branches de maintenance :
Branche GDR (General Distribution Release) qui contient uniquement security et autres correctifs
critiques.
Branche cu qui contient la sécurité et d’autres correctifs critiques, ainsi que tous les autres correctifs pour
la ligne de base.
Actuellement, la logique de détection de mu est construite afin que les instances sur une ligne de base de
maintenance ou le long de la branche GDR soient proposées à la branche GDR.
Les utilisateurs doivent installer de manière proactive au moins une mise à jour un cu pour aligner l’instance sur
la branche cu. Toutefois, une fois cette étape effectuée, vous ne pouvez pas revenir à la branche GDR tant que la
ligne de base de l’instance n’a pas été réinitialisée en passant au Service Pack suivant ou que toutes les CUS de
la ligne de base ne sont pas désinstallées manuellement. Si toutes les CUS sont désinstallées, cela déplace
l’instance vers la branche de RDA ou la ligne de base de maintenance.
Cette logique permet de réduire le nombre par défaut de modifications requises dans le cas d’une mise à jour
de sécurité ou d’une autre mise à jour critique. Les instances qui se trouve sur la branche CU doivent
nécessairement accepter toutes les mises à jour dans le cas où une version de sécurité ou une autre version
critique requise est fournie pour la ligne de base. Cela inclut toutes les modifications cumulatives non de
sécurité pour la ligne de base jusqu’au point de la mise à jour de sécurité requise.
S’applique à
SQL Server Web 2016
SQL Server Web 2014
SQL Server Web 2012
SQL Server’installation échoue si le compte
d’installation n’a pas certains droits d’utilisateur
Cet article vous aide à résoudre le problème qui se produit lors de l’installation ou de la mise à niveau Microsoft
SQL Server une fois la sécurité renforcée.
Version du produit d’origine : SQL Server 2008, SQL Server 2008 R2, SQL Server 2012
Symptômes
Prenons le cas de figure suivant. Pour renforcer la sécurité, vous supprimez certains droits d’utilisateur par
défaut sur le groupe Administrateurs local sur un Windows d’exploitation. En préparation de la configuration de
SQL Server sur ce système, vous ajoutez le compte d’installation au groupe Administrateurs local.
Dans ce scénario, si vous installez ou SQL Server, le processus d’installation peut échouer et vous recevez divers
messages d’erreur comme indiqué dans les sections suivantes.
Scénario 1 : Pour une nouvelle installation, le programme d’installation échoue et vous recevez le
L’accès est refusé En outre, vous pouvez remarquer des messages d’erreur semblables à ce qui suit
dans le fichier Detail.txt : 2009-01-02 13:00:17 SQLEngine: --SqlServerServiceSCM : Attente de
l’événement nt « Global\sqlserverRecComplete$NIIT » à créer 2009-01-02 13:00 0:20 SQLEngine: --
SqlServerServiceSCM: Waiting for nt event 'Global\sqlserverRecComplete$NIIT' or sql process
handle to be signaled 2009-01-02 13:00:20 Slp: Configuration action failed for feature
SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC. 2009-01-02 13:00:20 Slp :
Accès refusé 2009-01-02 13:00:20 Slp : Échec de l’action de configuration pour la fonctionnalité
SQL_Engine_Core_Inst lors du minutage ConfigRC et scénario ConfigRC. 2009-01-02 13:00:20 Slp :
System.ComponentModel.Win32Exception : Accès refusé 2009-01-02 13:00:20 Slp : sur
System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean
throwIfExited) 2009-01-02 13:00:20 Slp: at System.Diagnostics.Process.GetProcessHandle(Int32
access, Boolean throwIfExited) 2009-01-02 13:00:20 Slp: at
System.Diagnostics.Process.OpenProcessHandle() 2009-01-01- 02 13:00:20 Slp : à
System.Diagnostics.Process.get_Handle() 2009-01-02 13:00:20 Slp :
Microsoft.SqlServer.Configuration. SqlEngine.SqlServerServiceBase.WaitSqlServerStart(Process
processSql) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration.
SqlEngine.SqlServerServiceSCM.StartSqlServer(String[] parameters) 2009-01-02 13:00:20 Slp: at
Microsoft.SqlServer.Configuration. SqlEngine.SqlServerStartup.StartSQLServerForInstall(String
sqlCollation, String masterFullPath, Boolean isConfiguringTemplateDBs) 2009-01-02 13:00:20 Slp: at
Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.ConfigSQLServerSystemDataba
ses(EffectiveProperties properties, Boolean isConfiguringTemplateDBs, Boolean useInstallInputs)
2009-01-02 13:00:20 Slp: at
Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.DoCommonDBStartConfig(Con
figActionTiming timing) 2009-01-02 13:00:20 Slp: at Microsoft.SqlServer.Configuration.
SqlEngine.SqlEngineDBStartConfig.Install(ConfigActionTiming timing, Dictionary
2 actionData, PublicConfigurationBase spcb) 2009-01-02 13:00:20 Slp: at
scenario, ConfigActionTiming timing, Dictionary
2 actionData, PublicConfigurationBase spcbCurrent) 2009-01-02 13:00:20 Slp: at
Microsoft.SqlServer.Configuration.SqlConfigBase.SqlFeatureConfigBase.Execute(ConfigActionScenari
o scenario, ConfigActionTiming timing, Dictionary'2 actionData, PublicConfigurationBase
spcbCurrent) 2009-01-02 13:00:20 Slp: at
Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.ExecuteAction(String actionId)
2009-01-02 13:00:20 Slp: at
errorStream) 2009-01-02 13:00:20 Slp : Exception : System.ComponentModel.Win32Exception. 2009-
01-02 13:00:20 Slp : Source : Système. 2009-01-02 13:00:20 Slp : Message : l’accès est refusé.
Scénario 2 : les mises à niveau vers SQL Server 2008 signaleront le message d’erreur suivant sur la
Engine_SqlEngineHealthCheck règle :
Nom de la règle : Engine_SqlEngineHealthCheck la description de la règle : vérifie si le service SQL

Server peut être redémarré ; ou pour une instance en cluster, si la ressource SQL Server est en ligne.
Résultat : Message/Action corrective en échec : le service SQL Server ne peut pas être redémarré ; ou
pour une instance en cluster, la ressource SQL Server n’est pas en ligne. Vous pouvez remarquer des
messages d’erreur semblables à ce qui suit dans le fichier Detail.txt 2009-05-27 17:50:20 SQLEngine :
: Vérification du point de contrôle du moteur « GetSqlServerProcessHandle_1 » 2009-05-27 17:50:20
SQLEngine: --SqlServerServiceSCM: Waiting for nt event 'Global\sqlserverRecComplete$SQL10' to
be created 2009-05-27 17:50:22 SQLEngine: --SqlServerServiceSCM: Waiting for nt event
'Global\sqlserverRecComplete$SQL10' ou le handle de processus sql doit être signalé 2009-05-27
17:50:22 SQLEngine: --FacetSqlEngineHealthCheck: Engine_SqlEngineHealthCheck: Error: Access is
denied
Scénario3 : Échec d’une nouvelle installation SQL Server 2012 ou SQL Server 2008 R2
Vous voyez le message d’erreur suivant lorsque vous essayez d’installer une nouvelle instance de SQL
Server 2012 ou SQL Server 2008 R2 :
Échec de la règle « Privilèges de compte d’installation ». Le compte qui exécute le programme

d’installation SQL Server n’a pas un ou tous les droits suivants : le droit de back up files and
directories, the right to manage auditing and the security log and the right to debug programs. Pour
continuer, utilisez un compte avec ces deux droits.
Scénario 4 : l’installation SQL Server 2012 ou une instance ultérieure échoue lorsque vous spécifiez un
partage réseau (chemin UNC) pour l’emplacement du répertoire de sauvegarde. Lorsque ce problème se
produit, vous recevez le message d’erreur suivant :
SQL Server d’installation n’a pas le privilège SeSecurityPrivilege sur le serveur de fichiers spécifié
dans le chemin <UNC backup location> d’accès. Ce privilège est nécessaire dans l’action de
paramètre de sécurité des dossiers SQL Server programme d’installation. Pour accorder ce privilège,
utilisez la console stratégie de sécurité locale sur ce serveur de fichiers pour ajouter SQL Server de
configuration à la stratégie « Gérer le journal d’audit et de sécurité ». Ce paramètre est disponible
dans la section « Attributions des droits d’utilisateur » sous Stratégies locales dans la console
Stratégie de sécurité locale.
NOTE
Ce problème se produit car le compte SQL Server d’installation n’a pas d’autorisations sur le serveur de fichiers
SeSecurityPrivilege qui héberge le partage réseau.
Cause
Ce comportement est inhérent au produit. Outre l’ajout du compte d’utilisateur qui exécute le programme
d’installation en tant qu’administrateur local, le compte d’utilisateur du programme d’installation requiert les
droits d’utilisateur par défaut suivants pour que l’installation se termine correctement.
N O M C O M P L ET DE L’O B JET DE ST RAT ÉGIE LO C A L E DRO IT DE L’UT IL ISAT EUR
Fichiers et répertoires de sauvegarde SeBackupPrivilege
Programmes de débogage SeDebugPrivilege
Gérer le journal d’audit et de sécurité SeSecurityPrivilege
NOTE
Pour plus d’informations sur les autorisations requises pour installer SQL Server, voir la section « Conditions préalables »
des articles MSDN suivants :
How to: Install SQL Server 2008 (Setup)

Installer SQL Server 2012 à partir de l’Assistant Installation (installation)
En outre, si le partage de fichiers SMB est utilisé comme option de stockage pour le répertoire de données ou
tout autre répertoire (répertoire de base de données utilisateur, répertoire des journaux de base de données
utilisateur, répertoire TempDB, répertoire de journaux TempDB ou répertoire de sauvegarde), les autorisations
supplémentaires suivantes sont requises pour le compte d’installation sur le système de fichiers SMB, comme
indiqué dans l’article MSDN suivant : Installer SQL Server avec le stockage de partage de fichiersSMB
DO SSIER DE PA RTA GE DE RÉSEA U SM B C O N T RÔ L E TOTA L SQ L C O M P T E D’IN STA L L AT IO N
Dossier de partage de réseau SMB CONTRÔLE TOTAL SQL Server service d’agent SQL Server
et de sécurité
SMB Fileserver SeSecurityPrivilege SQL Compte d’installation
Résolution
Pour ajouter les droits au compte d’administrateur local, suivez les étapes suivantes :
1. Connectez-vous à l’ordinateur en tant qu’utilisateur ayant des informations d’identification administratives.
2. Cliquez sur Démarrer, cliquez sur Exécuter, tapez Admintools du contrôle, puis cliquez sur OK.
3. Double-cliquez sur Stratégie de sécurité locale.
4. Dans la boîte de dialogue Paramètres sécurité locale, cliquez sur Stratégies locales, double-cliquez sur
Attribution des droits d’utilisateur, puis double-cliquez sur Fichiers et réper toires de sauvegarde.
5. Dans la boîte de dialogue Fichiers de sauvegarde et propriétés des répertoires, cliquez sur Ajouter un
utilisateur ou un groupe.
6. Dans la boîte de dialogue Sélectionner un utilisateur ou des groupes, tapez le compte d’utilisateur utilisé
pour l’installation, puis cliquez deux fois sur OK.
7. Répétez la procédure pour les deux autres stratégies mentionnées dans la section Cause.
8. Dans le menu Fichier, cliquez sur Quitter pour fermer la boîte de dialogue Sécurité Paramètres locale.
Pour vérifier la liste des privilèges actuellement associés au compte utilisé pour le programme
d’installation, vous pouvez utiliser l’outil AccessChk.exe client. Pour télécharger cet outil, voir AccessChk
v6.13.
Utilisation : accesschk.exe- a <setup account> *
Par exemple : c:\tools\accesschk.exe -a testdc\setupaccount *
Sample output:
SeSecurityPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeSystemtimePrivilege
SeShutdownPrivilege
SeRemoteShutdownPrivilege
SeTakeOwnershipPrivilege
SeDebugPrivilege
SeSystemEnvironmentPrivilege
SeSystemProfilePrivilege
SeProfileSingleProcessPrivilege
SeIncreaseBasePriorityPrivilege
SeLoadDriverPrivilege
SeCreatePagefilePrivilege
SeIncreaseQuotaPrivilege
SeChangeNotifyPrivilege
SeUndockPrivilege
SeManageVolumePrivilege
SeImpersonatePrivilege
SeCreateGlobalPrivilege
SeTimeZonePrivilege
SeCreateSymbolicLinkPrivilege
SeInteractiveLogonRight
SeNetworkLogonRight
SeBatchLogonRight
SeRemoteInteractiveLogonRight
Configurer les Windows de service et les autorisations de service

Foire aux questions
Pourquoi SeSecurityPrivilege est-il requis sur le serveur de fichiers pour le répertoire de
sauvegarde sur le partage UNC ?
Cette autorisation est requise pour récupérer des listes de contrôle d’accès dans le répertoire de
sauvegarde par défaut afin de vous assurer que le compte de service SQL Server dispose des
autorisations complètes sur le dossier. Cela définit également les ACA si des autorisations sont
manquantes pour le compte de service SQL afin qu’il puisse effectuer une sauvegarde sur
l’annuaire. Le programme d’installation effectue ces vérifications pour le répertoire de sauvegarde
par défaut de sorte que si la sauvegarde est effectuée sur l’installation de l’annuaire de sauvegarde
par défaut, l’utilisateur ne rencontre pas d’erreur ou de problème (en raison d’autorisations
manquantes) lorsque vous effectuez une sauvegarde sur le répertoire par défaut.
NOTE
SeSecurityPrivilege est nécessaire pour modifier les ALA get/set à partir des répertoires et des sous-
répertoires. C’est le cas car même les utilisateurs qui ont des autorisations CONTRÔLE TOTAL sur les
répertoires ne sont pas autorisés à obtenir/définir des informations OWNER et Audit à partir de l’annuaire.
Pourquoi l’erreur décrite dans le scénario 4 se produit-elle SQL Server 2012 et les versions
ultérieures de SQL Server ?
Dans SQL Server 2012 et versions ultérieures, Microsoft a commencé à prise en charge des
données et des fichiers journaux sur le partage de fichiers SMB. Dans le cadre de cette
amélioration, l’expérience d’installation a été améliorée pour renforcer les contrôles afin que les
clients ne rencontrent pas d’erreurs ou de problèmes en raison d’autorisations insuffisantes après
l’installation. Dans les versions antérieures à SQL Server 2012, les clients peuvent toujours
configurer le chemin d’accès du partage réseau pour le répertoire de sauvegarde lorsque le
compte du service SQL n’est pas autorisé à effectuer la sauvegarde. Toutefois, ils rencontreront une
erreur après l’installation dans cette situation. Ces scénarios sont désormais interdits lorsque vous
démarrez la vérification d’SQL 2012 sur un partage réseau.
Le répertoire de données utilisateur dans le Registre
n’est pas un message d’erreur valide lors de
l’installation SQL Server mise à jour cumulative ou
d’un Service Pack
Cet article vous aide à résoudre le problème qui se produit lorsque vous installez une mise à jour cumulative ou
un Service Pack pour SQL Server instance.
Symptômes
Lors de l’installation d’une mise à jour cumulative ou d’un Service Pack pour une instance SQL Server, le
processus d’installation peut échouer avec l’un des messages d’erreur suivants:
Répertoire de données utilisateur non valide dans le Registre. Vérifiez la clé DefaultData sous la ruche
d’instance pointe vers un répertoire valide.
Code d’erreur : 0x851A0043
Répertoire des journaux d’utilisateurs non valide dans le Registre. Vérifiez la clé DefaultLog sous la ruche
d’instance pointe vers un répertoire valide.
Code d’erreur : 0x851A0044
Lorsque le problème se produit, le fichier journal SQL Server’installationSummary.txtdes messages semblables

à l’un des suivants :
Detailed results:
Feature: Database Engine Services
Status: Failed: see logs for details
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, and then try the setup process again.
Component name: SQL Server Database Engine Services Instance Features
Component error code: 0x851A0043
Error description: The User Data directory in the registry is not valid. Verify DefaultData key under
the instance hive points to a valid directory.
Error help link: http://go.microsoft.com/fwlink?

LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=11.0.7001.0&EvtType=0xD8FB5E
BA%400x97A656BB%401306%4067&EvtType=0xD8FB5EBA%400x97A656BB%401306%4067
Detailed results:
Feature: Database Engine Services
Status: Failed: see logs for details
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, and then try the setup
process again.
Component name: SQL Server Database Engine Services Instance Features
Component error code: 0x851A0044
Error description: The User Log directory in the registry is not valid. Verify DefaultLog key
under the instance hive points to a valid directory.
Error help link: http://go.microsoft.com/fwlink?

LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=11.0.7001.0&EvtType=0xD8FB5E
BA%400x97A656BB%401306%4068&EvtType=0xD8FB5EBA%400x97A656BB%401306%4068
Cause
Le problème se produit lorsque les emplacements par défaut des nouveaux fichiers de données ou journaux
d’une base de données pointent vers un emplacement non valide.
Résolution
Utilisez la procédure suivante pour résoudre le problème.
Étape 1 : définissez la valeur du répertoire de données par défaut et la valeur du répertoire des journaux
par défaut sur des chemins d’accès aux dossiers valides.
Vous pouvez définir la valeur du répertoire de données par défaut et la valeur du répertoire des journaux
par défaut à l’aide SQL Server Management Studio l’Éditeur du Registre.
Méthode 1 : utiliser SQL Server Management Studio
1. Dans l’Explorateur d’objets, cliquez avec le bouton droit sur un serveur et cliquez sur
Propriétés.
2. Dans le panneau gauche, cliquez sur la page Paramètres de la base de données.
3. Dans les emplacements par défaut de la base de données, affichez les emplacements par
défaut actuels pour les nouveaux fichiers de données et les nouveaux fichiers journaux. Pour
modifier un emplacement par défaut, entrez un nouveau chemin d’accès par défaut dans le
champ Données ou Journal, ou cliquez sur le bouton Parcourir pour rechercher et sélectionner
un nom de chemin d’accès.
Méthode 2 : Utilisation de l’éditeur du Registre :
IMPORTANT
Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre.
Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par
conséquent, veillez à suivre ces étapes scrupuleusement. Pour une meilleure protection, sauvegardez le
registre avant de le modifier. Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations
sur la façon de back up et restore the registry, voir How to back up and restore the registry in Windows.
1. Démarrez l’Éditeur du Registre (Regedt32.exe) à partir de la ligne de commande.
2. Recherchez, puis cliquez sur la sous-clé de Registre :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>\MSSQLServer .
NOTE
Dans cette sous-clé de Registre, <MSSQL.x> la valeur correspondante pour votre système. Pour
obtenir cette valeur, recherchez et cliquez sur la sous-clé de Registre :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL\
3. Dans le panneau droit, cliquez sur l’entrée de Registre DefaultData et entrez un chemin
d’accès valide (s’il pointe vers un emplacement incorrect).
4. Dans le panneau droit, cliquez sur l’entrée de Registre DefaultLog et entrez un chemin
d’accès valide (s’il pointe vers un emplacement incorrect).
NOTE
La meilleure pratique de protection de vos fichiers de données et fichiers journaux consiste à s’assurer
qu’ils sont protégés par des listes de contrôle d’accès (ACA). Les ACA doivent être définies sur la racine du
répertoire sous lequel les fichiers sont créés.
Étape 2 : Réessayez l’installation du Service Pack ou de la mise à jour cumulative pour l’instance
concernée.
NOTE
Le programme d’installation indique que l’instance a déjà été mise à niveau et qu’il ne vous permettra pas de
sélectionner uniquement le composant Services de base de données. Vous devez sélectionner toutes les
fonctionnalités de cette instance pour que le programme d’installation continue.
Références
Afficher et lire les fichiers journaux SQL Server du programme d’installation
Descriptions du schéma d’attribution de noms et de
la zone de correction pour SQL Server packages de
mise à jour logicielle
Cet article décrit le schéma d’attribution de noms et la zone de correction pour SQL Server packages de mise à
jour logicielle.
Informations sur le package et types de publication

Microsoft a adopté un schéma d’attribution de noms normalisé pour tous les packages de mise à jour logicielle
SQL Server créés et distribués.
Un package de mise à jour logicielle est un fichier exécutable (.exe ou .msi) qui contient un ou plusieurs fichiers
qui peuvent être appliqués aux installations SQL Server pour corriger un problème spécifique. Les packages de
mise à jour logicielle sont distribués par les services de support technique aux clients dont les ordinateurs sont
affectés par un problème spécifique.
Microsoft a adopté un schéma d’attribution de noms pour les packages de mise à jour logicielle pour les raisons
suivantes :
Crée une cohérence entre les packages de mise à jour logicielle.
Recherchez plus facilement des packages logiciels mis à jour et des articles de la Base de connaissances.
Identification claire de la langue et de la version SQL Server pour laquelle le package de mise à jour logicielle
est applicable.
Chaque package de mise à jour logicielle sélectionné au moment du téléchargement est contenu dans un
exécutable à extraction autonome qui facilite l’installation et le déploiement du package de mise à jour logicielle.
SQL Server packages de mise à jour logicielles sont généralement de deux types de publication principaux :
GDR (General Distribution Release) : les publication de GDR sont réservées aux correctifs clés identifiés
par la prise en charge SQL Server afin d’affecter potentiellement un large éventail de clients.
Correctif : les libérations de correctifs sont généralement pour les correctifs aux problèmes isolés qui
n’affectent pas une base de clients importante ; tandis que le produit est dans le support classique. Le
correctif est publié dans deux types principaux :
COD (Critical On Demand) ou OD (On Demand) : les releases COD ou OD sont réservées aux
demandes critiques des clients lorsque les fonctionnalités métiers clés sont compromises par le
problème rencontré. En tant que nature de la demande, ces mises à jour ne suivent pas une
cadence régulière.
Mise à jour cumulative : les mises à jour cumulatives sont des demandes non critiques qui
fournissent des correctifs pour les problèmes isolés qui n’affectent pas les fonctionnalités métiers
clés. La mise à jour à jour un produit est publiée à une cadence de deux mois tandis que le produit
et le Service Pack sont dans le support classique.
Pour en savoir plus sur l’ism et les différents types de publication, qui SQL Server maintenance suit, voir un
modèle de maintenance incrémentielle est disponible à partir de l’équipe SQL Server pour fournir des
correctifspour les problèmes signalés.
Schéma d’attribution de noms pour SQL Server packages de mise à

jour logicielle
SQL Server packages de mise à jour logicielle peuvent être facilement identifiés à l’aide du schéma d’attribution
de noms suivant.
Schéma du nom du package de mise à jour logicielle
Pour faire la distinction entre les différents packages de mise à jour logicielle disponibles en ligne, le
schéma suivant est utilisé :
<product name or product program name>_<SP number or RTM>_<servicing release>_<KB article
number>_<build number optional>_<architecture identifier>
Extrait du SQL Ser ver de nom de fichier

Une fois que le package SQL Server de mise à jour logicielle principale a été téléchargé et extrait, le nom
de fichier ressemble à ce qui suit :
<product name or component>-<KB article number>-<build number optional>-<version optional>-
<architecture Identifier>-<language code optional>.exe
Schéma de nom du Feature Pack extrait

Une fois qu’un package de mise à jour logicielle pour un Feature Pack a été téléchargé et extrait, le nom
de fichier ressemble à ce qui suit :
[nom de fichier du Feature Pack].msi
ProductName Il s’agit du nom complet du produit, qui inclut les informations de version du
produit. Par SQL Server, cet attribut peut être l’un des suivants :
SQLServer2005
SQLServer2008
SQLServer2008R2
SQLServer2012
Numéro SP ou RTM Niveau de Service Pack du produit ou du composant sur le dessus. RTM
indique le produit sans Service Packs installé.
Numéro d’ar ticle de la Ko Numéro d’article de la Base de connaissances Microsoft associé à la
mise à jour logicielle.
Version de maintenance Type de publication de la mise à jour logicielle. Pour plus
d’informations, consultez la section Informations sur le package et types de publication.
COD : critique à la demande
OD : à la demande
CU : mise à jour cumulative suivie du numéro de version de la mise à jour cumulative
Identificateur d’architecture Ce champ est utilisé pour indiquer l’architecture de processeur sur
laquelle le package de correctifs logiciels particulier s’exécute. Les options actuelles sont les
suivantes :
x86 : ce package s’exécute sur des plateformes x86.
ia64 : ce package s’exécute sur les plateformes Itanium IA-64 pour la 64 bits.
x64 : ce package s’exécute uniquement sur les systèmes AMD x64 et compatibles.
Version Champ facultatif qui indique la version de la version du logiciel.
Numéro de build Champ facultatif utilisé pour indiquer le numéro de build SQL Server inclus
dans la mise à jour logicielle.
Par exemple, dans SQL2000-KB840223-8.00.1007-ia64-ENU.exe, la version de build de SQL Server est
8.00.1007. Cela correspond à la version de fichier de Sqlservr.exe et à la valeur renvoyée par
@@version run rapport à cette instance de serveur.
Package de mise à jour logicielle et mappage des noms de fichiers

extraits
Les tableaux suivants illustrent le mappage entre le nom de fichier de téléchargement sur la page de
téléchargement de correctifs et le nom réel du package une fois téléchargé et extrait.
SQL Server package de mise à jour logicielle

N O M DU PA C K A GE DE M ISE À JO UR
PA C K A GE LO GIC IEL L E N O M DE SQ L SERVER EXT RA IT
Package cu pour SQL Server 2005 SQLServer2005_SPx_CUxx_kbxxxxxx_9_ SQLServer2005-KBxxxxxxx-Arch-

00_xxxx_Arch Lang.exe
Package cu pour SQL Server 2008 SQLServer2008_RTM_CUxx_kbxxxxxx_1 SQLServer2008- KBxxxxxxx-Arch.exe

0_00_xxxx_Arch
SQLServer2008_SPx_CUxx_kbxxxxxx_10
_00_xxxx_Arch
Package cu pour SQL Server 2008 R2 SQLServer2008R2_RTM_CUxx_kbxxxxxx SQLServer2008R2-KBxxxxxxx-Arch.exe

_10_50_xxxx_Arch
SQLServer2008R2_SPx_CUxx_kbxxxxxx_
10_50_xxxx_Arch
Package cu pour SQL Server 2012 SQLServer2012_RTM_CUxx_kbxxxxxx_1 SQLServer2012-KBxxxxxxx-Arch.exe

1_00_xxxx_Arch
SQLServer2012_SPx_CUxx_kbxxxxxx_11
_00_xxxx_Arch
SQL Server Feature Pack

SQL Native Client 2005_SPx_SNAC_CUxx_kbxxxxxx_9_00_ sqlncli.msi

xxxx_Arch
2008_RTM_SNAC_CUxx_kbxxxxxx_10_0
0_xxxx_Arch
2008_SPx_SNAC_CUxx_kbxxxxxx_10_00
_xxxx_Arch
2008R2_RTM_SNAC_CUxx_kbxxxxxx_10
_50_xxxx_Arch
2008R2_SPx_SNAC_CUxx_kbxxxxxx_10_
50_xxxx_Arch
SQL Rédacteur 2005_SPx_SQLWriter_CUxx_kbxxxxxx_9 SQLWriter.msi

_00_xxxx_Arch
AS OLE DB pour SQL Server 2005 2005_SPx_ASOLEDB_CUxx_kbxxxxxx_9_ SQLServer2005_ASOLEDB9.msi

00_xxxx_Arch
AS OLE DB pour SQL Server 2008 2008_RTM_ASOLEDB_CUxx_kbxxxxxx_1 SQLServer2008_ASOLEDB10.msi

0_00_xxxx_Arch
2008_SPx_ASOLEDB_CUxx_kbxxxxxx_1
0_00_xxxx_Arch
2008R2_RTM_ASOLEDB_CUxx_kbxxxxx
x_10_50_xxxx_Arch
2008R2_SPx_ASOLEDB_CUxx_kbxxxxxx
_10_50_xxxx_Arch
AS OLE DB pour SQL Server 2012 2012_RTM_ASOLEDB_CUxx_kbxxxxxx_1 SQL_AS_OLEDB.msi

1_00_xxxx_Arch
2012_SPx_ASOLEDB_CUxx_kbxxxxxx_1
1_00_xxxx_Arch
ADMOMD.net 2005_SPx_ADMOMD_CUxx_kbxxxxxx_9 SQLServer2005_ADOMD.msi

_00_xxxx_Arch
XMO/SMO (Shared Management 2005_SPx_XMO_CUxx_kbxxxxxx_9_00_x SQLServer2005_XMO.msi

Objects) pour SQL Server 2005 xxx_Arch
XMO/SMO (Shared Management 2008_RTM_SMO_CUxx_kbxxxxxx_10_0 SharedManagementObjects.msi

Objects) pour SQL Server 2008, SQL 0_xxxx_Arch
Server 2008 R2 et SQL Server 2012 2008_SPx_SMO_CUxx_kbxxxxxx_10_00
_xxxx_Arch
2008R2_RTM_SMO_CUxx_kbxxxxxx_10
_50_xxxx_Arch
2008R2_SPx_SMO_CUxx_kbxxxxxx_10_
50_xxxx_Arch
2012_RTM_SMO_CUxx_kbxxxxxx_11_0
0_xxxx_Arch
2012_SPx_SMO_CUxx_kbxxxxxx_11_00
_xxxx_Arch
Reporting Services for SharePoint for 2005_SPx_RSShrPnt_CUxx_KBxxxxx_9_0 SharePointRS.msi

SQL Server 2005 0_xxxx_arch
Reporting Services for SharePoint for 2008_RTM_RSShrPnt_CUxx_KBxxxxx_10 rsSharePoint.msi (x86 et x64

SQL Server 2008, SQL Server 2008 R2 _00_xxxx_arch uniquement)
et SQL Server 2012 2008_SPx_RSShrPnt_CUxx_KBxxxxx_10_
00_xxxx_arch
2008R2_RTM_RSShrPnt_CUxx_KBxxxxx_
10_50_xxxx_arch
2008R2_SPx_RSShrPnt_CUxx_KBxxxxx_
10_50_xxxx_arch
2012_RTM_RSShrPnt_CUxx_KBxxxxx_11
_00_xxxx_arch
2012_SPx_RSShrPnt_CUxx_KBxxxxx_11_
00_xxxx_arch
Reporting Services for SharePoint for 2008R2_RTM_RSShrPnt_CUxx_KBxxxxx_ rsSharePoint.msi (x64 uniquement)

SQL Server 2008 R2 10_50_xxxx_arch
2008R2_SPx_RSShrPnt_CUxx_KBxxxxx_
10_50_xxxx_arch
Report Builder Click Once 2008_RTM_RBClckOnc_CUxx_kbxxxxx_ RB2ClickOnce.msi (x86 et x64

10_00_xxxx_Arch uniquement)
2008_SPx_RBClckOnc_CUxx_kbxxxxx_1
0_00_xxxx_Arch
Report Builder for SQL Server 2008 2008_RTM_RprtBlder_CUxx_KBxxxx_10 ReportBuilder.msi (x86 uniquement)
_00_xxxx_Arch
2008_SPx_RprtBlder_CUxx_KBxxxx_10_
00_xxxx_Arch
Report Builder pour SQL Server 2008 2008R2_RTM_RprtBlder_CUxx_KBxxxx_ ReportBuilder3.msi

R2 10_50_xxxx_Arch
2008R2_SPx_RprtBlder_CUxx_KBxxxx_1
0_50_xxxx_Arch
Sap BI 2008_RTM_SapBI_CUxx_kbxxxxxx_10_0 SapBI.msi

0_xxxx_Arch
2008_SPx_SapBI_CUxx_kbxxxxxx_10_00
_xxxx_Arch
2008R2_RTM_SapBI_CUxx_kbxxxxxx_10
_50_xxxx_Arch
2008R2_SPx_SapBI_CUxx_kbxxxxxx_10_
50_xxxx_Arch
2012_RTM_SapBI_CUxx_kbxxxxxx_11_0
0_xxxx_Arch
2012_SPx_SapBI_CUxx_kbxxxxxx_11_00
_xxxx_Arch
Stream Insight 2008R2_RTM_StrmNsght_CUxx_KBxxxx StreamInsightClient.msi

x_10_50_xxxx_arch
2008R2_SPx_StrmNsght_CUxx_KBxxxxx
_10_50_xxxx_arch
2012_RTM_StrmNsght_CUxx_KBxxxxx_
11_00_xxxx_arch
2012_SPx_StrmNsght_CUxx_KBxxxxx_1
1_00_xxxx_arch
Synchronisation 2008R2_RTM_Synch_CUxx_KBxxxxx_10 Synchronization.msi

_50_xxxx_arch
2008R2_SPx_Synch_CUxx_KBxxxxx_10_
50_xxxx_arch
PowerPivot client Excel client 2008R2_RTM_PPExcel_CUxx_KBxxxxx_1 PowerPivot_for_Excel_x86.msi

0_50_xxxx_arch
2008R2_SPx_PPExcel_CUxx_KBxxxxx_10
_50_xxxx_arch
2012_RTM_PPExcel_CUxx_KBxxxxx_11_
00_xxxx_arch
2012_SPx_PPExcel_CUxx_KBxxxxx_11_0
0_xxxx_arch
Stream Insight et Server 2008R2_RTM_PPServer_CUxx_KBxxxxx_ StreamInsight.msi

10_50_xxxx_arch
2008R2_SPx_PPServer_CUxx_KBxxxxx_1
0_50_xxxx_arch
2012_RTM_PPServer_CUxx_KBxxxxx_11
_00_xxxx_arch
2012_SPx_PPServer_CUxx_KBxxxxx_11_
00_xxxx_arch
Master Data Services 2008R2_RTM_MDS_CUxx_KBxxxxx_10_ MasterDataServices.msi (x64

50_xxxx_arch uniquement)
2008R2_SPx_MDS_CUxx_KBxxxxx_10_5
0_xxxx_arch
Data-Tier Application Framework 2012_RTM_DAC_CUxx_KBxxxxx_11_00_ DACFramework.msi

xxxx_arch
2012_SPx_DAC_CUxx_KBxxxxx_11_00_x
xxx_arch
ADOMD.NET 2012_RTM_ADMOMD_CUxx_kbxxxxxx_ SQL_AS_ADOMD.msi

11_00_xxxx_Arch
2012_SPx_ADMOMD_CUxx_kbxxxxxx_1
1_00_xxxx_Arch
Base de données locale 2012_RTM_LocalDB_CUxx_KBxxxxx_11_ SqlLocalDB.msi

00_xxxx_arch
2012_SPx_LocalDB_CUxx_KBxxxxx_11_0
0_xxxx_arch
Service de langue SQL Transact 2012_RTM_TSQLLAN_CUxx_KBxxxxx_1 TSqlLanguageService.msi

1_00_xxxx_arch
2012_SPx_TSQLLAN_CUxx_KBxxxxx_11
_00_xxxx_arch
Meilleures pratiques En tant que meilleure pratique, envisagez de fournir un nom que vous pouvez utiliser pour
identifier facilement les packages lors des téléchargements.
Descriptions du package
Cette section décrit chacun des packages répertoriés et leurs objectifs. L’installation d’un package MSI plus
ancien sur un package MSI plus ancien supprime l’ancienne version au profit de la version la plus récente. La
désinstallation d’une mise à jour du Feature Pack à l’aide d’un package MSI supprime complètement le
composant. Toutefois, pour le package cu principal, la désinstallation du fichier .exe entraîne une mise à jour vers
la version précédemment installée.
SQL Ser ver package de mise à jour logicielle
Nom de fichier
SQLServer2005-KBxxxxxxx-Arch-Lang.exe (For SQL Server 2005)
SQLServer2008-KBxxxxxxx-Arch.exe (For SQL Server 2008)
SQLServer2008R2-kbxxxxxx-Arch (For SQL Server 2008 R2)
SQLServer2012-kbxxxxxx-Arch (For SQL Server 2012)
Objectif
Le package SQL Server de mise à jour logicielle met à jour l’instance SQL Server à l’aide d’une collection
de tous les correctifs logiciels SQL Server créés depuis la publication du produit. Le package applique les
mises à jour à tous les composants installés si une mise à jour a été réalisée. Ce package met à jour SQL
Server DB &, Analysis Service, Integration Services, Reporting Services, Replication Engine et
Manageability.
SQL Ser ver Native Client
Nom de fichier
sqlncli.msi (For SQL Server 2005, 2008, 2008 R2, 2012)
Objectif
SQL Server Native Client est une bibliothèque de liens dynamiques (DLL) unique contenant le fournisseur
OLE DB SQL et SQL pilote ODBC. Il contient la prise en charge de l’run-time pour les applications utilisant
des API de code natif (ODBC, OLE DB et ADO) pour se connecter à SQL Server. SQL Server Native Client
utiliser pour créer de nouvelles applications ou améliorer les applications existantes qui doivent tirer parti
de nouvelles fonctionnalités SQL Server existantes. Ce programme d’installation pour SQL Server Native
Client installe les composants clients nécessaires au moment de l’utilisation pour tirer parti des nouvelles
fonctionnalités SQL Server et installe éventuellement les fichiers d’en-tête nécessaires au développement
d’une application qui utilise l’API SQL Server Native Client.
Générateur de rappor ts
Nom de fichier
ReportBuilder.msi (For SQL Server 2008)
ReportBuilder3.msi (For SQL Server 2008 R2)
Objectif
Report Builder un environnement intuitif de authoring de rapports pour les entreprises et les utilisateurs
avec pouvoir avec une Office l’apparence. Report Builder prend en charge toutes les fonctionnalités du
langage rdl (Report Definition Language), notamment la disposition flexible des données, les
visualisations de données et les fonctionnalités de texte richement mises en forme de SQL Server
Reporting Services. Le téléchargement fournit un programme d’installation autonome pour Report
Builder.
Repor t Builder Click Once
Nom de fichier
RB2ClickOnce.msi (For SQL Server 2008, SQL Server 2008 R2)
Objectif
La version Click Once de Report Builder conçue pour être démarrée à partir du Gestionnaire de rapports
ou d’SharePoint bibliothèque.
Repor ting Ser vices pour SharePoint
Nom de fichier
SharePointRS.msi (For SQL Server 2005)
rsSharePoint.msi (For SQL Server 2008, SQL Server 2008 R2 et SQL Server 2012)
Objectif
SQL Server Reporting Services Le SharePoint technologies vous permet de tirer parti des fonctionnalités
de gestion et de traitement des rapports SQL Server 2005 et 2008 dans SharePoint. Le téléchargement
fournit un élément Web De la Visionneuse de rapports, des pages d’application web et la prise en charge
de l’utilisation de Windows SharePoint Services.
SQL Rédacteur
Nom de fichier
SQLWriter.msi (For SQL Server 2005)
Objectif
Le Service SQL Writer offre des fonctionnalités de sauvegarde et de restauration des SQL Server via
l’infrastructure du service de copie parallèle de volume. Lors de l’exécution, Moteur de base de données
verrouille et dispose d’un accès exclusif aux fichiers de données. Lorsque le Service SQL Writer n’est pas
en cours d’exécution, les programmes de sauvegarde exécutés dans Windows n’ont pas accès aux fichiers
de données et les sauvegardes doivent être effectuées à l’aide SQL Server sauvegarde. Utilisez la Service
SQL Writer pour autoriser les programmes Windows de sauvegarde à copier SQL Server fichiers de
données SQL Server en cours d’exécution.
AS OLE DB
Nom de fichier
SQLServer2005_ASOLEDB9.msi (For SQL Server 2005)
SQLServer2008_ASOLEDB10.msi (For SQL Server 2008 et SQL Server 2008 R2)
SQL_AS_OLEDB.msi (For SQL Server 2012)
Objectif
Le fournisseur Analysis Services OLE DB est un composant COM que les développeurs de logiciels
peuvent utiliser pour créer des applications côté client qui parcourent les métadonnées et les données de
requête stockées dans SQL Server Analysis Services. Ce fournisseur implémente à la fois la spécification
OLE DB et les extensions de la spécification pour le traitement analytique en ligne (OLAP) et l’exploration
de données.
NOTE
SQL Server Le fournisseur Analysis Services OLE DB requiert Core XML Services (MSXML) 6.0.
XMO/SMO (Shared Management Objects)

Nom de fichier
SQLServer2005_XMO.msi (For SQL Server 2005)
SharedManagementObjects.msi (For SQL Server 2008, SQL Server 2008 R2 et SQL Server 2012)
Objectif
Le package de la collection d’objets de gestion comprend plusieurs éléments clés de l’API de gestion SQL
Server 2005, notamment Analysis Management Objects (AMO), Replication Management Objects (RMO)
et SQL Server Management Objects (SMO). Les développeurs et les DBA peuvent utiliser ces composants
pour gérer par programme SQL Server 2005.
NOTE
SQL Server La collection d’objets de gestion nécessite core XML Services (MSXML) 6.0 et SQL Server Native Client.
ADMOMD.net
Nom de fichier
SQLServer2005_ADOMD.msi (For SQL Server 2005)
Objectif
ADOMD.NET est un modèle objet .NET Framework qui permet aux développeurs de logiciels de créer des
applications côté client qui parcourent les métadonnées et les données de requête stockées dans SQL
Server 2005 Analysis Services. ADOMD.NET est un fournisseur ADO.NET avec des améliorations pour le
traitement analytique en ligne (OLAP) et l’exploration de données.
SapBI
Nom de fichier
SapBI.msi (For SQL Server 2008, SQL Server 2008 R2 et SQL Server 2012)
Objectif
Le connecteur pour SAP BI est un ensemble de composants gérés pour le transfert de données vers ou à
partir d’un système SAP NetWeaver BI version 7.0. Le composant est conçu pour être utilisé avec les
éditions Enterprise et développeur de SQL Server 2008 ou 2008 R2 Integration Services. Pour installer le
composant, exécutez le programme d’installation spécifique à la plateforme pour les ordinateurs x86, x64
ou Itanium, respectivement. Pour plus d’informations, consultez la rubrique Lisez-moi et la rubrique
d’installation dans le fichier d’aide.
Stream Insight (client)
Nom de fichier
StreamInsightClient.msi (For SQL 2008 R2 et SQL Server 2012)
Objectif
Pour les utilisateurs actuels de StreamInsight, un agrégateur de données au moment de l’utilisation.
StreamInsight permet aux développeurs de logiciels de créer des solutions innovantes dans le domaine
du traitement d’événements complexes qui répondent à ces besoins. Il permet de surveiller, de miner et
de développer des informations à partir de flux de données continus et non liés et de corréler les
événements en constante évolution avec des charges utiles enrichies en temps quasi réel. Les
développeurs de solutions spécifiques au secteur et les développeurs d’applications personnalisées ont la
possibilité d’innover et d’utiliser des technologies éprouvées, flexibles et familières et de s’appuyer sur les
compétences de développement existantes lors de l’utilisation de la plateforme StreamInsight.
Stream Insight (ser veur)
Nom de fichier
StreamInsight.msi (For SQL Server 2008 R2 et SQL Server 2012)
Objectif
StreamInsight permet aux développeurs de logiciels de créer des solutions innovantes dans le domaine
du traitement d’événements complexes qui répondent à ces besoins. Il permet de surveiller, de miner et
de développer des informations à partir de flux de données continus et non liés et de corréler les
événements en constante évolution avec des charges utiles enrichies en temps quasi réel. Les
développeurs de solutions spécifiques au secteur et les développeurs d’applications personnalisées ont la
possibilité d’innover et d’utiliser une technologie Microsoft éprouvée, flexible et familière et de s’appuyer
sur les compétences de développement existantes lors de l’utilisation de la plateforme StreamInsight.
Synchronisation
Nom de fichier
Synchronization.msi (For SQL 2008 R2)
Objectif
Microsoft Sync Framework est une plateforme de synchronisation complète qui permet la collaboration
et l’accès hors connexion pour les applications, les services et les appareils. À l’aide du runtime Microsoft
Sync Framework (MSF), les développeurs peuvent créer des écosystèmes de synchronisation qui
intègrent n’importe quelle application, avec toutes les données de n’importe quel magasin à l’aide de
n’importe quel protocole sur n’importe quel réseau. Sync Services for ADO.NET fait partie du MSF. Sync
Services for ADO.NET permet la synchronisation entre ADO.NET bases de données activées. Étant donné
que les services de synchronisation pour ADO.NET font partie du MSF, toute base de données qui utilise
les services de synchronisation pour ADO.NET peut ensuite échanger des informations avec d’autres
sources de données qui sont pris en charge par MSF, telles que les services web, les systèmes de fichiers
ou les magasins de données personnalisés. Pour plus d’informations sur MSF, consultez le Centre de
développement Microsoft Sync Framework.
PowerPivot Excel client
Nom de fichier
PowerPivot_for_Excel_x86.msi (For SQL Server 2008 R2 et SQL Server 2012)
Objectif
Microsoft® PowerPivot pour Microsoft® Excel 2010 est un outil d’analyse de données qui fournit une
puissance de calcul sans correspondance directement dans les logiciels que les utilisateurs connaissent et
aiment déjà : Microsoft® Excel. Vous pouvez transformer des quantités de données de masse à une
vitesse incroyable en informations significatives pour obtenir les réponses dont vous avez besoin en
quelques secondes. Vous pouvez facilement partager vos résultats avec d’autres personnes.
Master Data Ser vices
Nom de fichier
MasterDataServices.msi (For SQL 2008 R2)
L’Master Data Services permet aux entreprises de normaliser les données sur qui les personnes
s’appuient pour prendre des décisions stratégiques. Grâce à Master Data Services, les organisations
informatiques peuvent centraliser la gestion des biens de données critiques à l’échelle de l’entreprise et
sur divers systèmes, permettre à davantage de personnes de gérer en toute sécurité les données maîtres
directement et de garantir l’intégrité des informations au fil du temps.
Infrastructure d’application de la couche Données
Nom de fichier
DACFramework.msi (For SQL Server 2008 R2 et SQL Server 2012)
Objectif
L’infrastructure SQL Server d’application de la couche Données est un composant basé sur le .NET
Framework et qui fournit des services de cycle de vie d’application pour le développement et la gestion
de bases de données. Les services de cycle de vie des applications incluent l’extraction, la construction, le
déploiement, la mise à niveau, l’importation et l’exportation pour les applications de niveau données dans
SQL Azure, SQL Server 2012, SQL Server 2008 R2, SQL Server 2008 et SQL Server 2005 à SQL Server
Data Tools et SQL Server Management Studio.
Fournisseur OLEDB pour DB2
Nom de fichier
DB2OLEDB.msi (For SQL Server 2008 R2)
DB2OLEDBV4.msi (For SQL Server 2012)
Objectif
Le fournisseur OLE DB pour DB2 v4.0 offre un ensemble de technologies et d’outils permettant d’intégrer
des données vitales stockées dans des bases de données IBM DB2 à de nouvelles solutions. SQL Server
développeurs et administrateurs peuvent utiliser le fournisseur de données avec les services
d’intégration, Analysis Services, la réplication, Reporting Services et le processeur de requêtes
distribuées.
Base de données locale
Nom de fichier
SqlLocalDB.msi (For SQL Server 2012)
Objectif
Nouveauté de la famille SQL Server Express, Base de données locale est une version légère d’Express qui
dispose des mêmes fonctionnalités de programmabilité, mais elle s’exécute en mode utilisateur et
dispose d’une installation rapide, de configuration nulle et d’une courte liste des conditions préalables.
Utilisez cette méthode si vous avez besoin d’un moyen simple pour créer et utiliser des bases de données
à partir du code. Express peut être regroupé avec des Visual Studio, d’autres outils de développement de
base de données ou incorporé à une application qui nécessite des bases de données locales.
Ser vice de langue SQL Transact
Nom de fichier
TSqlLanguageService.msi (For SQL Server 2012)
Objectif
Le SQL Server Transact-SQL Language Service est un composant basé sur le .NET Framework. Ce
composant fournit des services de validation d’IntelliSense et d’IntelliSense pour Transact-SQL pour SQL
Server 2012, SQL Server 2008 R2 et SQL Server 2008.
Explication de la colonne Corriger les zones dans les articles de la

base de données de la liste de correctifs pour les mises à jour
cumulatives et les Service Packs
UN C O RREC T IF DA N S C E DO M A IN E P EUT RÉSO UDRE L ES
Z O N E DE C O RREC T IO N P RO B L ÈM ES L IÉS ( M A IS SA N S S’Y L IM IT ER)
UN C O RREC T IF DA N S C E DO M A IN E P EUT RÉSO UDRE L ES
Z O N E DE C O RREC T IO N P RO B L ÈM ES L IÉS ( M A IS SA N S S’Y L IM IT ER)
Analysis Services (SSAS) Problèmes ou erreurs liés à des opérations ou des

composants d’Analysis Services (par exemple, traitement
d’un cube, exceptions lorsque vous utilisez des composants
analysis services, et ainsi de suite).
Connectivité Problèmes ou erreurs qui peuvent se produire lorsqu’un

programme se connecte à un serveur SQL suite à un bogue
ou à un problème avec le fournisseur client (par exemple,
System.Data, SQL OLE DB, etc.).
Services de qualité des données (DQS) Problèmes ou erreurs lorsque vous utilisez DQS ou ses
composants.
Disponibilité élevée Always On, Clustering, Log shipping, Database mirroring,

and so on
Services d’intégration (SSIS) Problèmes ou erreurs associés à des composants liés à SSIS
(par exemple, BI studio, service SSIS, et ainsi de suite).
Outils de gestion Problèmes ou erreurs lors de l’utilisation de différents outils

serveur SQL (tels que SQL Server management studio,
Profiler, Assistant Paramétrage du moteur de base de
données et d’autres outils SQL client).
Master Data Services (MDS) Problèmes ou erreurs lorsque vous utilisez MDS et ses
composants.
Reporting Services (SSRS) Problèmes ou erreurs lorsque vous utilisez des composants
Reporting Services (par exemple, serveur de rapports,
gestionnaire de rapports, concepteur de rapports, et ainsi de
suite).
Installation et installation Problèmes ou erreurs d’installation de SQL Server ou d’un

de ses composants.
SQL performances Requêtes ou problèmes de performances à l’échelle du

serveur.
SQL sécurité Problèmes ou erreurs pour l’authentification, l’autorisation,

Transparent Data Encryption (TDE), l’audit, la conformité
FIPS, le renforcement du serveur, etc.
SQL Service Problèmes liés à l’utilisation d’AVS, d’exceptions, de

scheduleurs non réplicables, d’arrêt de réponse du serveur,
de vérifications DBCC, d’opérations de sauvegarde ou de
restauration, de mise en miroir de bases de données, de
récupération de base de données, de fuites de mémoire,
d’altération, de requêtes serveur distribuées ou liées, de
réplication, etc.
XML Tous les problèmes liés aux MSXML, System.XML, XML Lite,
etc.
Foire aux questions
1. J’ai SQL Ser ver 2008. Dois-je appliquer le package de mise à jour logicielle SQL Ser ver et le
package SQL Ser ver Native Client sur le ser veur pour obtenir tous les correctifs SNAC (par
exemple, envisagez un scénario de ser veur lié où le ser veur est également un client) ?
Si le client et le serveur sont sur le même ordinateur, l’installation individuelle du package SQL Server
Native Client’est pas nécessaire. Si le client et le serveur sont séparés, appliquez le package SQL Native
Client au client et appliquez le package de mise à jour logicielle SQL Server au serveur pour obtenir
toutes les mises à jour.
2. J’ai SQL Ser ver 2005. Dois-je appliquer le package SQL Ser ver de mise à jour logicielle et le
package SQL Ser ver Native Client sur le ser veur pour obtenir tous les correctifs SNAC ?
Oui, le package SQL Server de mise à jour logicielle et le package SQL Native Client sont requis pour
mettre à jour le serveur et doivent être téléchargés séparément.
3. Dois-je installer le Feature Pack et le package SQL Ser ver Software Update ?
Chaque article de la base de données de la base de données identifiera clairement les packages qui
doivent être appliqués à l’ordinateur pour obtenir le correctif décrit. SNAC et d’autres MSI (SQLWriter,
XMO, RS Sharepoint, RB Clickonce, etc.) sont des versions de pointe à chaque cu, même s’il n’existe aucun
nouveau correctif.
4. Comment ajusterons-nous les ko une fois que nous atteindons 999999 ?
Nos ko sont actuellement à six chiffres, mais nous passerons bientôt à 7. Le schéma indiqué ci-dessus
dans ce document utilise la base de données de la lettre plus cinq X pour un total de sept caractères afin
d’afficher notre schéma attendu une fois que nous avons franchi la marque 1 000 000. En attendant,
continuez à utiliser la ko à six chiffres donnée.
5. Comment puis-je appliquer leSQLWriter.msi feature pack ?
Pour l’instant, vous devrez exécuter leSQLWriter.msiaprès la cu ou le package COD que vous avez
téléchargé pour corriger.
S’applique à
SQL Server Web 2012
SQL Server Web 2008
Mises à jour de la logique de détection Microsoft
Update pour la maintenance SQL Server de
données
S’applique à : SQL Server 2019, SQL Server 2017, SQL Server 2016
Historiquement, les lignes de base de maintenance (RTM ou Service Pack) incluent les branches de maintenance
suivantes :
Branche GDR (General Distribution Release) qui contient uniquement la sécurité et d’autres correctifs
critiques.
Une branche de mise à jour cumulative qui contient la sécurité et d’autres correctifs critiques, ainsi que tous
les autres correctifs pour la ligne de base.
La logique de détection Microsoft Update (MU) a été construite de sorte que les instances à la ligne de base de
maintenance ou le long de la branche GDR seraient proposées des mises à jour à partir de la branche GDR.
Auparavant, les utilisateurs deviez installer de manière proactive au moins une mise à jour un cu pour aligner
l’instance sur la branche cu pour la maintenance via mu. Toutefois, après cela, vous n’avez pas pu revenir à la
branche GDR pour cette instance tant que l’une des modifications suivantes n’a pas été apportée :
La planification a été réinitialisée en passant au Service Pack suivant.
L’instance a été revenir à la branche GDR ou à la ligne de base de maintenance en désinstallant toutes les
CUS.
Cette logique a été établie pour minimiser les modifications apportées à l’instance si une mise à jour de sécurité
ou une autre mise à jour critique était requise. Les instances de la branche cu doivent prendre toutes les mises à
jour publiées pour la ligne de base lorsqu’une sécurité requise ou une autre version critique s’affiche. Cela inclut
toutes les modifications non de sécurité jusqu’à la mise à jour de sécurité requise.
Toutefois, cette logique a créé des problèmes pour les utilisateurs qui tentent de gérer la maintenance de routine
de grands ensembles d’instances à l’aide de WSUS. Cela est dû au fait que la logique de mu n’a pas pu être
utilisée sans mettre à jour manuellement tous les clients afin de pouvoir y participer. Pour contourner ce
problème et éviter d’inverser des instances dans le train de mise à jour un jour sans le consentement explicite de
l’utilisateur, les modifications suivantes ont été apportées à la logique de détection de mu pour la maintenance
de la mise à jour un jour de routine et les libérations de sécurité pour les version de maintenance les plus
récentes des lignes de base prises en charge :
Mises à jour cumulatives : la logique de détection de mu permet désormais aux instances nettoyées qui sont
à la ligne de base (RTM ou SP, sans mise à jour de maintenance) ou qui sont déjà mises à jour le long de la
branche cu de recevoir la mise à jour. Il n’est pas besoin d’installer une mise à jour de mise à jour pour
qu’une instance soit proposée. Toutefois, si l’instance a une mise à jour GDR, l’instance doit toujours être
mise à jour manuellement en dehors de mu pour devenir gérable via l’automatisation de mu (WSUS).
Security Releases (GDRs) : la logique des publication de sécurité est désormais divisée en canaux suivants :
Un canal de mises à jour automatiques (Microsoft Update) conserve l’ancien comportement
historique qui nécessite l’installation d’une mise à jour un jour sur l’instance afin que la version de la
branche cu de la version de sécurité soit proposée. Cela permet de protéger les instances contre la
réception de toutes les mises à jour au lieu de recevoir uniquement les mises à jour critiques et liées à
la sécurité, sans preuve que l’utilisateur a explicitement choisi le mode de maintenance plus étendu.
Canal WSUS/Catalogue qui utilise la nouvelle logique de détection qui permet d’appliquer la version
de branche cu de la version de sécurité à une nouvelle instance de référence. Il s’agit du canal de la
version qui sera présenté aux utilisateurs qui vont sur le site web du catalogue Microsoft Update.
Cette nouvelle logique de détection mise à jour s’applique aux mises à jour de mise à jour des mises à jour et
des GDR suivantes :
SQL Server 2016 Service Pack 2 : CU14 et les CUS ultérieures
SQL Server 2017 RTM : CU19 et les CUS ultérieures
SQL Server 2019 RTM : toutes les UTIL
GDR et version de sécurité : tout commence en 2021
NOTE
Pour SQL Server 2019, la ligne de base rtm peut être la ligne de base de la version RTM (15.0.2000.5 ) ou la version de
référence rtm + RTM GDR (15.0.2070.41 ). Les deux versions fonctionnent pour cette version. Pour la version SQL
Server 2014 SP3 (12.3.6024.0 ), le nouveau modèle sera implémenté pour les versions de sécurité GDR sur la branche
CU à partir de 2021. Pour plus d’informations sur l’ancien modèle de détection Microsoft Update, voir les mises à jour
SQL Server non applicables sont répertoriées dans WSUS, MU ou ConfMgr.
Une erreur d’autorisation se produit lorsque vous
utilisez un point de montage de volume dans SQL
Server configuration
Cet article vous aide à résoudre le problème qui se produit lorsque vous affectez un dossier racine du point de
montage de volume aux SQL Server système.
Version du produit d’origine : SQL Server, Windows Server 2012 Datacenter, Windows Server 2012 Datacenter,
Windows Server 2012 Standard, Windows Server 2012 Standard
Symptômes
Lorsque vous installez Microsoft SQL Server sur Windows Server 2012, l’installation échoue si vous affectez un
dossier système SQL Server (tel que l’emplacement des fichiers DATA ou LOG) à un dossier racine de point de
montage de volume. En outre, le message d’erreur suivant s’affiche :
Lors de la mise à jour du paramètre d’autorisation pour le dossier « T:\DATA\System Volume Information »
la mise à jour du paramètre d’autorisation a échoué pour le fichier « T:\DATA\System Volume
Information\ResumeKeyFilter.Store ». Le paramètre d’autorisation de dossier était supposé être «
D:P(A;OICI;FA;; ; ; BA)(A;OICI;FA;;; SY)(A;OICI;FA;;; CO)(A;OICI;FA;;; S-1-5-80-3880718306-3832830129-
1677859214-2598158968-1052248003) ».
Cause
Ce problème se produit car SQL Server le programme d’installation n’est pas autorisé à accéder au
\System Volume Information\ResumeKeyFilter.Store fichier.
Résolution
Pour résoudre ce problème, créez un sous-dossier dans le point de montage du volume et affectez le nouveau
sous-dossier aux dossiers système SQL Server dossiers.
Lorsque SQL Server le programme d’installation SQL Server des dossiers système, le programme d’installation
tente de modifier les autorisations des dossiers et des fichiers qu’ils contiennent. Toutefois, si vous définissez les
dossiers système sur un dossier racine du point de montage du volume, le fichier
\System Volume Information\ResumeKeyFilter.Store est créé Windows Server 2012. SQL Server Le programme
d’installation ne peut pas modifier les autorisations, car SYSTEM est la seule autorisation définie
ResumeKeyFilter.Store sur ce fichier.
Supprimer une installation partielle d’SQL serveur
Cet article décrit la procédure de suppression d’une installation partielle de SQL serveur.
Symptômes
Lorsque vous essayez de réinstaller une instance de SQL Server après l’échec de l’installation la première fois
sur le même serveur, vous remarquerez peut-être que la deuxième tentative échoue également.
Cause
Ce problème se produit car, après l’échec de la première installation, une instance partiellement installée de SQL
Server existe sur le serveur. Le programme SQL Server’installation ne permet pas de revenir en arrière en cas
d’échec de l’installation. L’instance partiellement installée n’inclut pas l’édition de SQL Server que vous essayiez
d’installer, telle que l’édition Enterprise, l’édition Standard ou l’édition d’évaluation. Lorsque vous essayez
d’installer la même version sur le même serveur, le programme d’installation trouve l’instance existante.
Toutefois, le programme d’installation ne peut pas déterminer la version de SQL Server à installer. Par
conséquent, l’installation échoue.
Résolution
Utilisez la procédure suivante pour résoudre le problème :
1. Assurez-vous que vous avez des sauvegardes valides des bases de données pour chaque instance SQL
sur le système.
2. Accédez à Summary.Txt fichier journal d’installation du fichier et notez la commande d’installation
suggérée par le programme d’installation.
3. À l’aide d’une invite de commandes avec élévation de niveau élevé, accédez à l’emplacement de «
setup.exe » pour le répertoire des supports d’installation et exécutez la commande à <SQL Version
upgrading to> l’étape 1.
NOTE
Il est très important de vous assurer que vous exécutez les commandes sur la bonne instance, sinon vous risquez
de désinstaller une instance de travail.
4. Lancez l’interface graphique de l’Assistant Centre d’installation à partir du groupe SQL Server
programme d’installation ou en réessaiant le programme d’installation.
5. Accédez à l’élément de menu Outils et cliquez sur Installed SQL Server rapport de découverte des
fonctionnalités et vérifiez qu’il n’y en a <instance name> plus. Instances INACTIVEs affichées dans le
rapport.
6. Réessayez le programme d’installation qui ne s’est pas terminé à l’origine.
NOTE
Si vous voyez toujours des instances inactives dans le rapport de découverte même après la procédure ci-dessus, utilisez
la procédure documentée dans la procédure De correction d’un échec SQL 2005, 2008, R2 ou 2012 Install/Upgrade -
MSSQLSERVER. INACTIF pour corriger l’installation SQL Server partielle sur le système.
Voir aussi
Désinstaller une instance existante de SQL Server (installation)
Restaurer les fichiers de cache Windows installer
manquants et résoudre les problèmes qui se
produisent pendant une mise à jour SQL Server
jour
Cet article décrit différentes procédures que vous pouvez utiliser pour résoudre diverses erreurs qui se
produisent lors de l’installation d’un Service Pack SQL Server ou d’une mise à jour cumulative en raison de
l’altération du cache du programme d’installation windows.
NOTE
Le processus décrit dans cet article fournit une assistance d’urgence uniquement et non un correctif permanent. Les
clients qui utilisent ce processus d’urgence doivent valider leur cache du programme d’installation Windows à l’aide du
package de vérification du cache du programme d’installation Windows, comme indiqué dans l’article de la base de
données de la base de données. Le cachedu programme d’installation Windows manquant nécessite une reconstruction
de l’ordinateur.
Symptômes
Lorsque vous essayez d’installer un Service Pack Microsoft SQL Server ou une mise à jour cumulative, vous
pouvez rencontrer différents messages d’erreur, qui peuvent indiquer des problèmes Windows cache du
programme d’installation. Le cache Windows Installer, situé dans le dossier c:\windows\installer, stocke les
fichiers importants pour les applications installées à l’aide de la technologie Windows Installer et ne doit pas
être supprimé. Si le cache du programme d’installation a été compromis, vous ne pouvez pas voir
immédiatement de problèmes tant que vous n’avez pas effectué une action telle que la désinstallation, la
réparation ou la mise à jour SQL Server.
Lorsque vous installez SQL Server, le programme d’installation Windows stocke les fichiers critiques dans le
cache Windows Installer (la valeur par défaut est C:\Windows\Installer). Ces fichiers sont requis pour la
désinstallation et la mise à jour des applications. Les fichiers manquants ne peuvent pas être copiés entre les
ordinateurs, car ils sont uniques.
Microsoft recommande que pour les installations SQL Server vous utilisez d’abord le processus de réparation
décrit dans les articles suivants pour vérifier votre installation actuelle :
How to: Rebuild the Registry for SQL Server 2005
How to: Repair a Failed SQL Server 2008 Installation
How to: Repair a Failed SQL Server 2008 R2 Installation
How to: Repair a Failed SQL Server 2012 Installation
Vous devez exécuter la réparation à partir du support d’installation d’origine à l’aide de la ligne de commande :
setup.exe/ACTION=REPAIR/INDICATEPROGRESS=TRUE .
Réparez d’abord les composants et fonctionnalités partagés courants, puis répétez la commande pour réparer
les instances installées. Pendant le processus de réparation, la boîte de dialogue d’installation disparaît. Tant que
la fenêtre de progression n’affiche pas d’erreur, le processus de réparation se déroule comme prévu. Si le fichier
cache du programme d’installation d’un composant spécifique est manquant, le processus de réparation
rencontre une erreur.
Cause
Ces problèmes peuvent se produire lorsque le fichier de base de données Windows Installer (.msi) ou le fichier
correctif Windows Installer (.msp) est manquant dans le cache Windows Installer. Le cache Windows installer se
trouve dans le dossier : %windir%\installer.
Lorsqu’un produit est installé à l’aide de Windows Installer, une version du fichier .msi d’origine est stockée dans
le cache Windows Installer. Chaque mise à jour du produit, telle qu’un correctif logiciel, une mise à jour
cumulative ou une configuration de Service Pack, stocke également le fichier .msp ou .msi approprié dans le
cache Windows Installer.
Toute mise à jour future du produit, telle qu’un correctif logiciel, une mise à jour cumulative ou une
configuration de Service Pack, repose sur les informations des fichiers stockés dans le cache Windows Installer.
Sans ces informations, la nouvelle mise à jour ne peut pas effectuer les transformations requises.
Résolution
Pour résoudre ces problèmes, utilisez l’une des procédures suivantes.
Procédure 1.a.: Utiliser l’outil FixMissingMSI

Dans cette procédure, vous allez utiliser l’outil FixMissingMSI pour identifier les fichiers MSI et MSP manquants
dans le cache Windows Installer. En tant qu’étape supplémentaire, vous pouvez pointer l’outil vers les
emplacements multimédias d’origine et mettre en récupération les fichiers manquants.
Vous pouvez télécharger l’outil FixMissingMSI à partir du GitHub.
Pour plus d’informations, voir SQL Setup ToolSuite Introduction (1) -FixMissingMSI.
Procédure 1.b.: Utiliser le script FindSQLInstalls.vbs script

Pour effectuer les étapes de cette procédure, vous devez copier le script FindSQLInstalls.vbs dans le dossier
FixMissingMSI du référentiel GitHub vers un dossier local sur l’ordinateur sur lequel vous essayez de mettre à
jour votre installation SQL Server.
NOTE
Le script FindSQLInstalls.vbs collecte les informations pour corriger les chemins d’accès de package non valides. Ce script
est utilisé par rapport aux emplacements sources pour s’assurer que tous les packages MSP se trouve dans le répertoire
Windows cache du programme d’installation. Après l’exécution des commandes indiquées dans les lignes Action
nécessaires dans le fichier de sortie du script, les packages manquants sont ajoutés à nouveaux si le support source
d’origine est disponible.
Pour résoudre ces problèmes à l’aide d’un script, suivez les étapes suivantes :
1. Cliquez ici pour aller à la page FindSQLInstalls.vbs brut sur GitHub.
2. Sélectionnez tout le contenu de cette page, copiez-le et collez-le dans un fichier texte. Enregistrez le fichier
texte sous FindSQLInstalls.vbs.
3. Ouvrez une invite de commandes avec élévation de niveau élevé dans le répertoire dans lequel vous avez
enregistréFindSQLInstalls.vbsfichier, puis exécutez la commande :
Cscript FindSQLInstalls.vbs %computername%_sql_install_details.txt .
4. Ouvrez le fichier de l’étape 2 dans un éditeur de Bloc-notes, et identifiez les problèmes à l’origine de
l’échec. Pour ce faire, recherchez dans le fichier texte des modèles de chaînes tels que les suivants :
Ne pas
!!!
5. En fonction des résultats de l’étape 3, prenez les étapes requises.
NOTE
Pour plus d’informations sur ces étapes, voir la section Exemples.
6. Répétez les étapes 2 à 4 jusqu’à ce que le fichier texte créé à l’étape 2 ne contienne plus de texte qui
référence des chemins d’accès non valides ou des fichiers manquants pour le composant en cours de
mise à jour.
Exemples
Les exemples suivants sont des entrées et des explications d’actions décrites dans le fichier de sortie généré
lorsque vous exécutez le script FindSQLInstalls.vbs.
Exemple 1 : Fichiers d’installation manquants

Voici un exemple de sortie générée lorsque vous manquez un package .msi dans le dossier de cache Windows
Installer.
================================================================================
PRODUCT NAME : Microsoft SQL Server 2008 Database Engine Services
================================================================================
Product Code: {9FFAE13C-6160-4DD0-A67A-DAC5994F81BD}
Version : 10.2.4000.0
Most Current Install Date: 20110211
Target Install Location:
Registry Path: HKEY_CLASSES_ROOT\Installer\Products\C31EAFF906160DD46AA7AD5C99F418DB\SourceList
Package : sql_engine_core_inst.msi
Install Source: \x64\setup\sql_engine_core_inst_msi\
LastUsedSource: m;1;G:\x64\setup\sql_engine_core_inst_msi\
La ligne LastUsedSource pointe vers l’emplacement utilisé pour exécuter le programme d’installation.
Dans la ligne LastUsedSource, l’entrée m; signifie média et indique que la source d’origine est cd/DVD.
Dans l’exemple suivant, la source est un CD ou un DVD dans le lecteur G. Si l’installation s’est produite à partir
d’un dossier de fichiers ou d’un partage réseau, la ligne LastUsedSource commence par une entrée n; suivie
d’une entrée Numeric_Data_Name; et du chemin d’accès réel :
!!!! sql_engine_core_inst.msi DOES NOT exist on the path in the path G:\x64\setup\sql_engine_core_inst_msi\
!!!!
Action needed, re-establish the path to G:\x64\setup\sql_engine_core_inst_msi\
La ligne Action nécessaire vous indique le chemin d’accès complet qui doit exister afin de mettre à jour les
fichiers manquants pour le support d’installation d’origine :
Fichier cache du programme d’installation : C:\WINDOWS\Installer\19b4d2.msi
La ligne Du fichier cache du programme d’installation confirme le nom du fichier cache du programme
d’installation :
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!! C:\WINDOWS\Installer\19b4d2.msi DOES NOT exist

in the Installer cache. !!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
La section suivante de la sortie vous informe des actions qui sont requises pour résoudre les fichiers manquants
:
Action requise, recréer ou rétablir le chemin d’accès au répertoire :

G:\x64\setup\sql_engine_core_inst_msi\puis réexécuter ce script pour mettre à jour le cache du programme
d’installation et obtenir les résultats Le chemin d’accès sur la ligne ci-dessus doit exister à l’emplacement
racine pour résoudre ce problème avec votre fichier msi/msp in trouvé ou endommagé. Dans certains cas,
vous devrez copier manuellement le fichier manquant ou remplacer manuellement le fichier problème qui le
remplace : Copiez « G:\x64\setup\sql_engine_core_inst_msi\sql_engine_core_inst.msi »
C:\WINDOWS\Installer\19b4d2.msi Remplacez le fichier existant si vous y êtes invité.
Exemple 2 : Correctifs manquants

Les correctifs manquants peuvent entraîner des entrées semblables à celles de l’exemple 1. La plupart du temps,
vous remarquerez des entrées dans la ligne Patch LastUsedSource qui font référence à un correctif, et cette ligne
ressemble à Patch LastUsedSource: n;1;c:\0ca91e857a4f12dd390f0821a3\HotFixSQL\Files\ ceci :
Cette sortie indique les éléments suivants concernant l’installation du correctif :
Le correctif d’origine a été installé en double-cliquant sur le fichier exécutable du correctif.
Le programme d’installation du correctif a utilisé un dossier temporaire, c:\0ca91e857a4f12dd390f0821a3 lors
de l’installation du correctif.
Pour re-créer le chemin d’accès, vous devez exécuter le même exécutable et ajouter le paramètre :
/x:c:\0ca91e857a4f12dd390f0821a3 .
NOTE
Cette commande force l’exécutable à extraire les fichiers à l’emplacement manquant précédent, ce qui re-crée la structure
requise pour mettre à jour le cache du programme d’installation Windows avec les fichiers manquants. L’emplacement réel
varie et un seul correctif, tel qu’un Service Pack, peut être extrait à plusieurs emplacements. Chaque produit installé inclut
une section qui contient les informations suivantes pour les correctifs installés :
Nom complet :
URL de l’article de la Base de données : http://support.microsoft.com/?kbid=<value>
Patch LastUsedSource :
La ligne URL de l’article de la Base de données de la Base de données peut vous aider à télécharger n’importe
quel support de correctif, si nécessaire.
Procédure 2 : restaurer manuellement les fichiers

Pour restaurer manuellement les fichiers manquants dans le cache Windows Installer, suivez les étapes suivantes
:
1. Collectez les détails complets sur le fichier manquant à partir du message d’erreur, du fichier journal
d’installation ou des entrées de Registre qui sont conservées par le programme d’installation Windows.
Par exemple, dans le message d’erreur 1 de la section Symptômes, toutes les informations requises pour
résoudre le problème sont présentes dans le message d’erreur :
PatchName : « Correctif 1702 pour SQL Server 2008 R2 (KB981355) (64 bits) »
Fichier MSP d’origine utilisé par le correctif : sql_engine_core_inst.msp
Fichier MSP mis en cache : c:\Windows\Installer\1fdb1aec.msp
2. Si vous n’avez pas tous les détails, consultez la section Procédure 2 : Restaurer manuellement les fichiers
pour les étapes à suivre pour collecter ces détails.
3. Consultez les requêteset recherchez l’article de la Ko associé à ce correctif. Dans cet exemple, vous devez
rechercher KB981355.
4. Téléchargez ce package de correctifs sur votre ordinateur. Veillez à télécharger le package de correctifs qui
correspond à la plateforme requise. Dans cet exemple, le package est SQLServer2008R2-KB981355-
x64.exe.
5. Extrayez le contenu du package de correctifs à l’aide de la syntaxe :
C:\Temp>SQLServer2008R2-KB981355-x64.exe /x C:\Temp\SQLServer2008R2-KB981355-x64\ .
6. Recherchez le fichier msp d’sql_engine_core_inst.msp. Le fichier doit se présenter dans le dossier suivant :
C:\Temp\SQLServer2008R2-KB981355-x64\x64\setup\sql_engine_core_inst_msi\ .
7. Copiez ce fichier msp d’origine dans le cache Windows installer %windir%\installer\ suivant :
8. Renommez le fichier msp d’origine, sql_engine_core_inst.msp, sur le nom : fichier msp mis en cache
1fdb1aec.msp.
Vous pouvez démarrer le programme d’installation de la mise à jour qui a entraîné l’erreur et reprendre le
processus de mise à jour. Vous pouvez rencontrer ce message pour un fichier cache Windows Installer
manquant pour un autre composant ou pour une autre mise à jour du même produit.
Pour obtenir la liste de tous les fichiers de cache Windows Installer manquants liés aux composants du produit
SQL Server, vous pouvez télécharger l’outil BPA SQL Server 2008 R2 mentionné dans la section Plus
d’informations.
Si le message d’erreur fait référence à un fichier de base de données Windows Installer manquant (.msi), vous
n’avez pas besoin d’effectuer les étapes 2 à 4. Au lieu de cela, vous pouvez passer directement à l’étape 5. Vous
devez localiser les .msi du support d’origine que vous avez utilisé pour installer le produit. Si ce message
d’erreur a été généré pour sql_engine_core_inst.msi, vous devez localiser ce fichier à partir du support
d’installation sous la structure de dossiers : \x64\setup\sql_engine_core_inst_msi\ . Les autres étapes sont les
mêmes.
Rechercher le package de correctifs et les détails du produit pour un

fichier .msp manquant
Différentes versions du produit génèrent différents messages d’erreur pour ce problème. Les messages d’erreur
mentionnés dans la section Symptômes apparaissent pour les programmes d’installation pour les mises à jour
SQL Server 2008 SP1. Pour les autres mises à jour, vous recevez des messages d’erreur qui peuvent ne pas
spécifier clairement quel fichier correctif est manquant dans le cache Windows Installer et les détails de mise à
jour spécifiques. Pour ces messages d’erreur, les fichiers journaux d’installation contiennent des informations sur
le Windows cache du programme d’installation. Un exemple de journal d’installation ressemble à ce qui suit :
MSI (s) (FC:F8) [13:48:58:649]: Opening existing patch 'C:\WINDOWS\Installer\145258.msp'.
MSI (s) (FC:F8) [13:48:58:649]: Couldn't find local patch 'C:\WINDOWS\Installer\145258.msp'. Looking for it
at its source.
MSI (s) (FC:F8) [13:48:58:649]: Resolving Patch source.
MSI (s) (FC:F8) [13:48:58:649]: Note: 1: 2203 2:
D:\cda162709d239766830bae5ce12b\HotFixSQL\Files\sqlrun_sql.msp 3: -2147287037
MSI (s) (FC:F8) [13:48:58:649]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (FC:F8) [13:49:29:961]: Product: Microsoft SQL Server 2005 -- Installation failed.
MSI (s) (FC:F8) [13:49:29:992]: MainEngineThread is returning 1635
This patch package could not be opened. Verify that the patch package exists and that you can access it, or
contact the application vendor to verify that this is a valid Windows Installer patch package.
D:\SQL2K5\Servers\Setup\SqlRun_SQL.msi
Si vous examinez attentivement ce journal d’installation, il vous fournit déjà les informations sur le fichier MSP
d’origine qui a été utilisé par le correctif : sqlrun_sql.msp.
Pour plus d’informations sur le fichier .msp manquant dans le cache Windows Installer, suivez les étapes
suivantes :
1. Recherchez le fichier .msp manquant dans la sous-clé Windows registre correctifs du programme
d’installation :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches\
2. Recherchez le GUID du correctif.

3. Recherchez le GUID de correctif dans la sous-clé Windows registre des produits d’installation suivants :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\
Pour l’exemple de journal d’installation, les informations sur le fichier .msp manquant et ses détails de correctif
correspondants sont présentes dans les entrées de Registre suivantes :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-
18\Patches\A3B085EA74A9A7640A496636F7EF9A44
Valeur : 0
Nom : LocalPackage
Données : C:\WINDOWS\Installer\145258.msp
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-
18\Products\1EB3A031CC585314E87AA527E46EECC2\Patches\A3B085EA74A9A7640A496636F7EF9A44
Valeur : 6
Nom : DisplayName
Données : GDR 2050 for SQL Server Database Services 2005 ENU (KB932555)
Vous avez maintenant tous les points d’information pour démarrer les étapes de résolution des fichiers
manquants dans le cache Windows Installer.
NOTE
Si vous utilisez SQL Server 2008 Service Pack 3 (SP3) ou une version ultérieure, vous pouvez également recevoir un
message d’erreur similaire pour les fichiers .msi manquants. À l’aide de ce message d’erreur, vous pouvez rapidement
déterminer le fichier manquant, le Service Pack à télécharger et l’endroit où vous pouvez trouver le téléchargement.
Pour plus d’informations sur l’obtention du Service Pack, voir KB2546951 -Liste des problèmes résolus par SQL
Server 2008 Service Pack 3 .
Procédure 3 : Restauration à partir de sauvegardes d’état système
Vous pouvez restaurer à partir de sauvegardes d’état système, comme décrit dans le cache Windows Installer
nécessite une reconstruction de l’ordinateur.
NOTE
Les messages d’erreur suivants se trouvent en tant que messages texte dans le journal des événements ou dans les
journaux d’installation situés dans l’un des dossiers suivants, et ils indiquent que vous devez réparer votre instance
concernée en cours de poursuite :
Pour SQL Server 2008 et SQL Server 2008 R2 : C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap
Pour SQL Server 2012 : C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap
Pour SQL 2005 (toutes les succursales)
M ESSA GE D’ERREUR LO RSQ UE L E

M ESSA GE D’ERREUR LO RSQ UE L E PA C K A GE DE C A C H E DU
PA C K A GE D’IN STA L L AT IO N ( M SI) P RO GRA M M E D’IN STA L L AT IO N
VERSIO N DE P RO DUIT EST M A N Q UA N T ( M SP ) EST M A N Q UA N T
SQL Server 2005 1636 Impossible d’installer Windows 1636 Impossible d’installer Windows
fichier MSI du programme fichier MSP du programme
d’installation d’installation
NOTE
Vous devez examiner les fichiers journaux d’installation pour déterminer si des fichiers cache sont manquants. Pour
plus d’informations sur la façon de faire, voir la section Résolution.
For SQL Ser ver 2008 SP1

SQL Server 2008 SP1 Aucun message d’erreur TITLE : échec SQL Server du
programme d’installation.
------------------------------
SQL Server Le programme
d’installation a rencontré l’erreur : le
fichier correctif ne peut pas
être ouver t. Le fichier est :
c:\WINNT\Installer\FileName.ms
p. Code d'0x84B20001.
------------------------------
Par SQL Ser ver 2008 SP3 build-only (les branches CU/GDR ne sont pas applicables)
SQL Server 2008 SP3 Le fichier MSI mis en cache Le fichier correctif mis en cache
C:\Windows\Installer\FileName.msi C:\Windows\Installer\FileName.msp
est manquant. Son fichier d’origine est manquant. Le fichier d’origine de
est et a été installé pour le ce fichier mis en cache est , qui peut
sql_engine_core_inst.msi être installé à partir du Service Pack
produit SQL Server 2008 Moteur de 3 pour
base de données Services à partir sql_engine_core_inst.msp SQL
NetworkPath de , version , langue Server 2008 (KB2546951) (64 bits),
VersionNumber ENU . version VersionNumber
NOTE
Vous recevez le message d’erreur suivant lorsque vous effectuez une mise à niveau :
Pour SQL Ser ver 2008 R2 SP1 uniquement (les branches CU/GDR ne sont pas applicables)

SQL Server 2008 R2 SP1 TITLE : échec SQL Server du Le fichier correctif mis en cache
programme d’installation. C:\Windows\Installer\FileName.msp
------------------------------ est manquant. Le fichier d’origine de
SQL Server Le programme ce fichier mis en cache est , qui peut
d’installation a rencontré l’erreur être installé à partir du Service Pack
suivante 1 pour
:C:\Windows\Installer\FileName sql_engine_core_inst_loc.msp
.msi. SQL Server 2008 R2 (KB2528583)
------------------------------ (64 bits), version VersionNumber .
NOTE
For SQL Ser ver 2008 R2 SP2

SQL Server 2008 R2 SP1 Le fichier MSI mis en cache Le fichier correctif mis en cache
C:\Windows\Installer\FileName.msi C:\Windows\Installer\FileName.msp
est manquant. Son fichier d’origine est manquant. Le fichier d’origine de
estsql_engine_core_inst.msi et il a ce fichier mis en cache est
été installé pour le produit SQL sql_engine_core_inst_loc.msp, qui
Server 2008 R2 SP1 Moteur de base peut être installé à partir du Service
de données Services à partir de , Pack 1 pour SQL Server 2008 R2
version , NetworkPath langue (KB2528583) (64 bits), version
VersionNumber LanguageName . VersionNumber .
NOTE
Pour SQL Ser ver 2012 antérieure à CU2

Il n’existe aucun message pour les fichiers MSP ou MSI manquants. Toutefois, le code d’erreur 1714 est
consigné dans le journal d’installation.
In the Summary.txt file: Component name: SQL Server Setup Support Files Component error code: 1714
Dans le fichierDetail.txt:
Date/Time Slp: Sco: FileFilePath does not exist

Date/Time Slp: Sco: FileFilePathdoes not exist
Date/Time Slp: Checkpoint: PREINSTALL_SQLSUPPORT_CPU64_ACTION
Date/Time Slp: Sco: Attempting to create base registry key HKEY_LOCAL_MACHINE, machineServer Name
Date/Time Slp: Sco: Attempting to open registry subkey
Software\Microsoft\Windows\CurrentVersion\Installer
Date/Time Slp: Sco: Attempting to get registry value InstallerLocation
Date/Time Slp: Windows installer version : 5.0.7601.17514
Date/Time Slp: Sco: Waiting for service 'msiserver' to accept the stop request.
Date/Time Slp: Sco: Attempting to open SC Manager
Date/Time Slp: Sco: Attempting to open service handle for service msiserver
Date/Time Slp: Invoking QueryServiceStatus Win32 API
Date/Time Slp: Sco: Attempting to close service handle for service msiserver
Date/Time Slp: Sco: Attempting to close SC Manager
Date/TimeSlp: Target package: "FilePath"
Date/TimeSlp: MSI Error: 1714 The older version of Microsoft SQL Server 2012 Setup (English) cannot
be removed. Contact your technical support group.
Date/TimeSlp: InstallPackage: MsiInstallProduct returned the result code 1603.
Date/TimeSlp: Using MSI error code to detect the retry option: 1714
Date/TimeSlp: No retry-able MSI return code detected.
Pour SQL Ser ver 2012 CU2 (et les cu ou SP ultérieures)

SQL Server 2008 R2 SP1 Le fichier MSI mis en cache Le fichier correctif mis en cache
C:\Windows\Installer\FileName.msi c:\Windows\Installer\FileName.msp
est manquant. Son fichier d’origine est manquant. Son fichier d’origine
est et il a été installé pour le produit
sql_engine_core_inst.msp est ,
C:\Windows\Installer\sql_FeatureName.msi
qui peut être installé à partir de ,
Microsoft SQL ServerVersion à version
partir C:\originalfolder de , Hotfix 2316 for SQL Server
version , langue VersionNumber 2012 (KB2679368) (64-bit)
Language . VersionNumber . Le fichier correctif

mis en cache
C:\Windows\Installer\FileName.msp
est manquant. Son fichier d’origine
est , qui peut être installé à partir du
correctif logiciel
C:\Windows\Installer\sql_FeatureName.msp
<HotfixNumber> pour SQL Server
2012 KB Number, version
VersionNumber .
NOTE
Dans certaines conditions dans SQL Server 2012, il se peut que le support RTM ne soit pas enregistré
correctement. Lorsque vous désinstallez une mise à jour cumulative ou un Service Pack dans ces circonstances, le
programme d’installation peut vous inviter à vous faire une demande de support RTM. Pour contourner ce
problème, indiquez le chemin d’accès au support RTM pendant le processus de suppression des correctifs.
Références
Base de données du programme d’installation
Packages de correctifs
Référentiel GitHub
SQL Server service peut ne pas démarrer après
l’installation du correctif
Cet article vous aide à résoudre le problème qui se produit après que le programme d’installation de correctifs a
installé un correctif et tenté de redémarrer le système.
Symptôme
Il se peut que vous receviez un message vous SQL Server service n’a pas pu démarrer. Le SQL Server ne
parvient pas à redémarrer une fois que le programme d’installation du correctif a installé un correctif et a tenté
de redémarrer le système. Le message d’erreur s’affiche à l’écran ou s’affiche dans Summary.txt journal.
Cause
Cela peut être dû à un service SQL en cours d’exécution, mais le mot de passe a expiré. Lorsque le programme
d’installation des correctifs tente de redémarrer le service SQL échoue au redémarrage.
Résolution
Étapes de résolution des problèmes :
Si vous recevez un message vous SQL Server service n’a pas réussi à démarrer, pour résoudre le problème,
vérifiez les points suivants :
Déterminez l’erreur. Un message s’affiche dans l’interface utilisateur ou dans le journalsummary.txt situé à
l’emplacement suivant %programfiles%\Microsoft SQL Server\100\Setup Bootstrap\Log .
Vérifiez si le type de service de démarrage est automatique ou manuel.
Vérifiez que le compte et le mot de passe sont valides et qu’ils n’ont pas expiré. Un service peut avoir été
précédemment en cours d’exécution avec un compte ou un mot de passe non valide.
Si le service du moteur de base de données ne démarre pas, après avoir vérifié les informations
d’identification et le démarrage du service, vérifiez errorLOG. ErrorLOG peut se trouver à
C:\Program Files\Microsoft SQL Server\<Instance ID>\MSSQL\LOG l’emplacement .
Le programme d’installation cesse de répondre
lorsque vous essayez de mettre SQL Server niveau
vers une autre version
Cet article vous aide à résoudre le problème qui se produit lors de la mise à niveau d’une version antérieure de
SQL Server vers SQL Server 2012.
Symptômes
Lorsque vous essayez de mettre à niveau une SQL Server d’une version principale vers une autre version
principale (par exemple, la mise à niveau de SQL Server 2012 vers SQL Server 2017), le programme
d’installation semble cesser de répondre pendant l’étape SQLEngineConfigAction_upgrade.
Lorsque ce problème se produit, les informations d’installation semblables à ce qui suit sont consignées à la fin
du Detail.txt fichier :
(01) 2012-05-03 06:18:29 SQLEngine: --SqlEngineSetupPrivate: Setting Security Descriptor D:(<GUID value>) on
Directory <Data directory>
(01) 2012-05-03 06:18:29 Slp: Sco: Attempting to set security descriptor for directory <Data Directory>,
security descriptor D:( (<GUID value>))
(01) 2012-05-03 06:18:29 Slp: Sco: Attempting to normalize security descriptor D:( (<GUID value>))
(01) 2012-05-03 06:18:29 Slp: Sco: Attempting to replace account with sid in security descriptor D:( (<GUID
value>))
(01) 2012-05-03 06:18:29 Slp: ReplaceAccountWithSidInSddl -- SDDL to be processed: D:( (<GUID value>))
(01) 2012-05-03 06:18:29 Slp: ReplaceAccountWithSidInSddl -- SDDL to be returned: D:( (<GUID value>))
(01) 2012-05-03 06:18:29 Slp: Sco: Directory <Data Directory>is a volume mount point. VolumeName is \\?
\Volume{<VolumeID> }\
(01) 2012-05-03 08:27:50 Slp: Sco: Add DACL to underlying volume '\\?\Volume{<VolumeID }\' for directory
'<Data directory>’from SDDL 'D:((<GUID value>))'
NOTE
Le Detail.txt se trouve dans le dossier : \Program Files\Microsoft SQL Server\nnn\Setup Bootstrap\Log\timestamp .
Cause
Ce problème peut se produire si de nombreux sous-dossiers et fichiers contiennent SQL Server données.
NOTE
Ce problème est plus susceptible de se produire si la base de données est intégrée au système de fichiers NTFS à l’aide de
la fonctionnalité FILESTREAM ou FILETABLE.
Résolution
Aucune action n’est requise pour résoudre ce problème. Pour terminer la mise à niveau, laissez le programme d
SQL Server 2012 se terminer.
Le problème décrit dans la section Symptômes se produit car le programme SQL Server programme
d’installation appelle Windows SetSecurityInfo API. L’API applique une liste de contrôle d’accès discrétionnaire
(DACL) aux sous-dossiers et aux fichiers qui SetSecurityInfo contiennent SQL Server données. Ce processus
peut prendre du temps.
Références
Fonction SetSecurityInfo (aclapi.h)
Problèmes connus d’installation SQL Server sur
Windows 7 ou Windows Server 2008 R2
Cet article décrit certains problèmes connus et conditions préalables lorsque vous prévoyez d’installer SQL
Server sur Windows 7 ou Windows Server 2008 R2.
Version du produit d’origine : SQL Server, Windows Server, Windows
Résumé
Cet article décrit les problèmes connus lorsque vous installez Microsoft SQL Server sur un ordinateur exécutant
Windows 7 ou Windows Server 2008 R2.
Pour toutes les éditions à l’exception de l’édition Express d’SQL Server 2008 qui s’exécute sur Windows 7
ou sur Windows Server 2008 R2, vous devez avoir installé au moins SQL Server 2008 Service Pack 1
(SP1).
NOTE
Express Edition inclut déjà le Service Pack 1.
Dans cet article, Windows 7 indique la version cliente de Windows 7. Windows Server 2008 R2 indique la
version du serveur Windows 7.
Pour plus d’informations sur la configuration matérielle et logicielle requise pour les différentes versions
de SQL Server, voir Hardware and Software Requirements for Installing SQL Server 2012.
Pour obtenir des notes de publication qui documentent différents problèmes connus au moment de la
publication du produit, consultez la SQL Server 2012 Release Notes.
Problèmes détectés
Windows 7 n’utilise pas la propriété pour déterminer si l’authentification RequireKerberos Kerberos est
activée.
Étant donné Windows 7 n’utilise pas la propriété pour déterminer si l’authentification Kerberos est
activée pour une ressource nom réseau, l’installation du cluster de SQL Server RequireKerberos 2008
échoue.
Lorsque la stratégie FIPS (Federal Information Processing Standard) est activée dans Windows 7 ou dans
Windows Server 2008 R2, la validation du cluster échoue lors de l’installation SQL Server 2008.
Lorsque la stratégie FIPS est activée dans Windows 7 ou dans Windows Server 2008 R2, la validation du
cluster échoue pendant l’installation de SQL Server 2008. Par conséquent, le programme d’installation
échoue.
Pour résoudre ces deux problèmes, vous devez installer SQL Server 2008 avec SQL Server 2008 (SP1) ou
une mise à jour ultérieure pour les installations en cluster. Pour plus d’informations sur l’obtention SQL
Server 2008 SP1, consultez l’article suivant :
KB968382 : comment obtenir le dernier Service Pack pour SQL Server 2008
Pour plus d’informations sur la mise à jour SQL Server le programme d’installation dans un
environnement en cluster ou dans un environnement non réservé, consultez l’article suivant :
Mise à jour ou mise à jour d’une installation SQL Server 2008
SQL Server 2008 peut échouer sur Windows Server 2008 R2
L’installation SQL Server 2008 peut échouer sur Windows Server 2008 R2 si le .NET Framework n’est pas
activé. Ce problème se produit car l’installation .NET Framework 3.5 est une condition préalable à cette
installation.
Sur Windows Server 2008 R2, la .NET Framework 3.5 est incluse en tant que Windows composant. Par
défaut, la .NET Framework 3.5 n’est pas activée. Pour éviter cet échec d’installation, vous devez activer la
.NET Framework 3.5 à partir du composant Windows Features avant d’exécuter l’installation SQL Server
2008.
Le programme d SQL Server 2008 peut échouer
Le programme d SQL Server 2008 peut échouer et vous recevez l’erreur suivante :
Invoke ou BeginInvoke ne peut pas être appelé sur un contrôle tant que la poignée de fenêtre n’a pas
été créée.
Vous pouvez installer une mise à jour cumulative pour résoudre ce problème. Pour plus d’informations,
consultez l’article suivant :
CORRECTIF : Message d’erreur lorsque vous installez SQL Server 2008 sur un ordinateur exécutant
Windows 7 : « Invoke ou BeginInvoke ne peut pas être appelé sur un contrôle tant que la poignée de
fenêtre n’a pas été créée. »
Version minimale requise pour Windows 7 ou Windows Server 2008

R2
Avant d’installer SQL Server sur un ordinateur exécutant Windows 7 ou Windows Server 2008 R2, vous devez
vous assurer que vous remplissez les conditions préalables minimales suivantes, en fonction de votre situation.
SQL Server 2008

Installations en cluster
Vous devez installer SQL Server 2008 avec SQL Server 2008 Service Pack 1 ou une mise à jour ultérieure
(également appelée version int flux).
Installations non exclusives
Vous devez installer SQL Server 2008, puis SQL Server 2008 Service Pack 1 ou une mise à jour
ultérieure.
NOTE
SQL Server 2008 express runtime est pris en charge sur Windows 7 et Windows 2008 R2.
Pour plus d’informations sur la configuration matérielle et logicielle requise pour l’installation de SQL Server
2008, consultez la SQL Server 2016 et 2017: Configuration matérielle et logicielle requise.
Le .NET Framework
Vous devez activer .NET Framework 3.5 SP1 avant d’installer SQL Server 2008 sur un ordinateur exécutant
Windows Server 2008 R2. La .NET Framework 3.5 SP1 est une condition préalable pour SQL Server 2008. SQL
Server 2008 installera le .NET Framework 3.5 SP1 s’il n’est pas déjà installé. Toutefois, pour le clustering de .NET
Framework, le .NET Framework 3.5 SP1 doit être installé avant l’installation du cluster de SQL Server 2008.
Dans Windows Server 2008 R2, l'.NET Framework est un composant système. Par conséquent, vous ne pouvez
pas installer le .NET Framework à partir d’un point de redistribution. Vous devez installer les .NET Framework à
partir du rôle serveur ou à l’aide ServerManagerCmd.exe.
Vous n’avez pas à installer le .NET Framework dans les scénarios suivants :
Sur un ordinateur qui exécute Windows Server 2008 R2 et sur lequel le .NET Framework 3.5 SP1 est
installé.
Sur un ordinateur qui exécute Windows 7.
NOTE
Par défaut, .NET Framework 3.5 SP1 est installé dans Windows 7.
S’applique à
Windows Server 2008 R2 Datacenter
Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Standard
Windows Server 2008 R2 Web Edition
Windows 7 Entreprise
Windows 7 Professionnel
Windows 7 Édition Intégrale
Problèmes SQL Server configuration connus de
2008 R2 SQL Server 2008
Cet article traite des problèmes de configuration et de migration propres à SQL Server 2008 R2 et SQL Server
2008 sur un ordinateur exécutant Windows Server 2012 R2, Windows Server 2012, Windows 8.1 ou Windows
8.
Problème 1 : vous ne pouvez pas désinstaller SQL Server 2008 Express

Edition ou SQL Server 2008 R2 Express Edition
Symptômes
Vous pouvez recevoir un message d’erreur semblable au suivant lorsque vous essayez de désinstaller SQL
Server 2008 R2 ou SQL Server 2008 Express Edition :
La fonctionnalité suivante n’a pas pu être installée :

.NET Framework 3.5 (inclut .NET 2.0 et 3.0)
Résolution
Pour plus d’informations sur la résolution de ce problème, voir Cannot uninstall, repair, add new features to, or
add a new instance to SQL Server 2008 or SQL Server 2008 R2 in Windows 8.
Pour contourner ce problème, effectuez l’une des opérations suivantes :
Activez la .NET Framework 3.5 avant de désinstaller SQL Server 2008 Express Edition.
Copiez le fichier MediaInfo.xml du support d’installation SQL Server 2008 R2 ou SQL Server 2008
Express Edition dans le dossier suivant avant d’essayer de désinstaller SQL Server 2008 R2 ou SQL
Server 2008 Express Edition :
\Program Files (x86)\Microsoft SQL Server\100\Setup Bootstrap\SQLServer2008R2
Problème 2 : la règle « Vérification du service de cluster » échoue

lorsque vous essayez d’installer une instance de cluster de SQL Server
2008 R2
Symptômes
Lorsque vous essayez d’installer une instance de cluster de SQL Server 2008 R2, l’installation échoue lors de la
règle de vérification du ser vice de cluster. Lorsque vous affichez les détails, vous recevez un message d’erreur
Cause
Ce problème se produit si la bibliothèque de MSClus.dll COM n’est pas activée.
NOTE
Les SQL Server de configuration de cluster 2008 et SQL Server 2008 R2 dépendent de la bibliothèque de MSClus.dll
COM. Si cette bibliothèque n’est pas activée sur le nœud de cluster, le programme d’installation échoue.
Résolution
Pour résoudre ce problème, procédez de l’une des façons suivantes :
Activez la fonctionnalité Serveur d’automatisation du cluster deover sur chaque nœud à l’aide du
Gestionnaire de serveur. Dans le Gestionnaire de serveur, développez Outils d’administration de
serveur distant, développez Outils d’administration des fonctionnalités, développez Outils de clustering
de failover, puis cliquez pour sélectionner Failover Cluster Automation Ser ver .
Exécutez l’Windows PowerShell cmdlet suivante sur chaque nœud pour activer la fonctionnalité Serveur
d’automatisation du cluster deover :
add-windowsfeature RSAT-Clustering-AutomationServer
NOTE
Vous devez exécuter cette cmdlet à une invite de commandes avec élévation de élévation de niveaux.
Problèmes SQL Server configuration et de
migration connus en 2012
Cet article décrit les problèmes SQL Server configuration et de migration 2012.
Problèmes d’installation et de migration spécifiques SQL Server 2012

Remarques générales
Par défaut, Windows 8 inclut la .NET Framework 4.0. Windows 8.1 et Windows Server 2012 R2
incluent la .NET Framework 4.5, et Windows 10 et Windows Server 2016 incluent la .NET
Framework 4.6. Toutefois, les SQL Server 2012 suivants dépendent de la .NET Framework 3.5 :
SQL Server 2012 Moteur de base de données
Service de réplication
SQL Server Data Tools
Service de qualité des données
Service de données master
Mode natif de Reporting Service
Full-Text recherche
Par conséquent, nous vous recommandons d’activer .NET 3.5 Framework avant d’installer SQL
Server 2014 ou SQL Server 2012 dans un environnement autonome ou en cluster pour éviter les
échecs de configuration SQL Server possibles.
Pour plus d’informations sur l’activer .NET 3.5 Framework, lisez les articles suivants :
Installez la .NET Framework 3.5sur Windows 10, Windows 8.1 et Windows 8 .
Activer .NET Framework 3.5 à l’aide de l’Assistant Ajout de rôles et de fonctionnalités
Certains SQL Server installation et d’installation 2012 sont résolus dans les dernières mises à jour
cumulatives SQL Server 2012. Par conséquent, nous vous recommandons de créer un package
d’installation slipstream qui inclut SQL Server 2012 et CU3 ou une mise à jour ultérieure à l’aide du
paramètre /Update. Pour plus d’informations sur la façon de faire, voirSQL Server 2012 Setup just got
smarter or How to patch SQL Server 2012 Setup with an updated setup package (using UpdateSource to
get a smart setup).
SQL Server 2012 qui peuvent se produire lorsque la .NET Framework

3.5 n’est pas activée
Problème 1 : SQL cluster de SQL ou des installations autonomes
Symptômes
Sur les serveurs où .NET Framework 3.5 n’est pas déjà installé ou sur les serveurs dont l’accès à Internet
est restreint, le programme d’installation SQL Server 2012 n’installe pas les composants qui dépendent
de .NET Framework 3.5. Par conséquent, l’installation SQL Server 2012 peut être incomplète.
NOTE
Windows 8.1 ou Windows Server 2012 R2 ne vous permet pas de poursuivre l’installation.
Un message d’erreur semblable à celui-ci peut s’afficher pendant SQL Server 2012 lorsque le .NET
Framework n’est pas activé.
Prévention
Pour éviter ce problème, activez la .NET Framework 3.5 sur tous les serveurs du cluster ou sur le serveur
autonome avant d’installer SQL Server 2012.
Résolution
Pour résoudre ce problème sur un serveur autonome, activez la .NET Framework 3.5, puis ré-exécutez le
programme d’installation pour ajouter les fonctionnalités supplémentaires.
Pour résoudre ce problème dans un environnement en cluster, désinstallez les instances de SQL Server
2012 incomplètes, activez .NET Framework 3.5, puis réinstallez SQL Server 2012.
NOTE
Dans un environnement en cluster, vous ne pouvez pas ajouter les fonctionnalités qui ont été ignorées en
exécutant à nouveau SQL Server configuration 2012.
Pour résoudre ce problème sur un serveur autonome, activez la .NET Framework 3.5, puis ré-exécutez
SQL Server le programme d’installation.
Problème 2 : les utilisateurs sont invités à télécharger et installer le .NET Framework 3.5
Symptômes
Les utilisateurs peuvent être invités à télécharger et installer le .NET Framework 3.5 lorsqu’ils essaient
d’installer CU1 ou CU2. Ce problème peut se produire même si les composants installés ne dépendent
pas de la .NET Framework 3.5.
Dans ce cas, les utilisateurs peuvent recevoir un message d’erreur semblable à ce qui suit.
Cause
Il s’agit d’un problème connu dans SQL Server 2012 CU1 et CU2.
NOTE
This issue is fixed in Cumulative Update 3 for SQL Server 2012 and later versions.
Prévention
Pour éviter ce problème, faites l’une des choses suivantes :
Activez la .NET Framework 3.5, appliquez le package de mise à jour CU1 ou CU2, puis désactivez .NET
Framework 3.5.
NOTE
Vous ne devez désactiver la .NET Framework 3.5 que si votre installation n’inclut pas de composants qui
dépendent de la .NET Framework 3.5.
Installez SQL Server 2012 à partir d’un package d’installation inclut SQL Server 2012 et CU3 ou une
version ultérieure.
Appliquer la mise à jour cumulative 3 ou une version ultérieure. Pour plus d’informations, voir les
builds SQL Server 2012 publiées après SQL Server 2012.
Problème 3 : les aler tes Windows du mode de compatibilité des applications sont affichées
lors d’une installation sans aver tissement
Symptômes
Dans Windows 8.1, Windows 8, Windows Server 2012 R2, Windows Server 2012, Windows 10 et
Windows Server 2016, le .NET Framework est un composant de fonctionnalité à la demande (FOD). En
outre, les stratégies système Windows 10, Windows 8.1 et Windows 8 et les stratégies système Windows
Server 2016, Windows Server 2012 R2 et Windows Server 2012 exigent que les utilisateurs soient
avertis lorsque les composants FOD sont activés.
NOTE
Par défaut, la .NET Framework 4.0 est activée dans Windows 8 et Windows Server 2012. En outre, .NET Framework
4.5 est activé dans Windows 8.1 et Windows Server 2012 R2, et .NET Framework 4.6 est activé dans Windows 10
et Window Server 2016. Toutefois, la .NET Framework 3.5 est désactivée.
Par conséquent, un avertissement du mode de compatibilité du programme qui invite les utilisateurs à
télécharger et installer le .NET Framework 3.5 peut s’afficher lors d’une installation sans avertissement.
Ces alertes de compatibilité de programme ne peuvent pas être supprimées. Les captures d’écran des
avertissements sont affichées comme suit :
Windows Server 2012 R2 et Windows Server 2012 - Serveur complet
Windows Server 2012 R2 et Windows Server 2012 - Server Core
Prévention
Pour éviter ce problème, l’utilisateur peut activer la .NET Framework 3.5 avant d’effectuer une installation
en mode silencieux.
Autres SQL Server d’installation 2012

Problème 1 : une exception .NET Framework non .NET Framework peut être générée lorsque
vous essayez d’installer une deuxième instance de SQL Ser ver 2012
Symptômes
Vous installez une instance de SQL Server 2012.
Un .NET Framework de configuration utilisateur 4.0 est créé lorsque vous installez l’instance de SQL
Server 2012. En outre, la .NET Framework 3.5 est activée pendant l’installation.
Vous essayez d’installer une deuxième instance de SQL Server 2012.
Dans ce scénario, une exception nonmenée peut être générée. Vous pouvez recevoir un message d’erreur
Une erreur s’est produite lors de la création du handler de section de configuration pour
l'Microsoft.SqlServer.Configutilisateur. LandingPage.Properties. Paramètres : Le système de fichier ou
d’assembly n’a pas pu être chargé, Version=4.0.0.0, Culture=neutral, PublicKeyToken=xxxxx ou l’une
de ses dépendances. Le fichier spécifié est introuvable.
(C:\Users\Administrator\AppData\Local\Microsoft_Corporation\LandingPage.exe_StrongName_
ryspccglaxmt4nhllj5z3thycltsvyyx\11.0.0.0\user.config)
Cause
Dans Windows 8 et Windows Server 2012, ce problème se produit car le .NET Framework 4.0 est activé
par défaut dans Windows 8 et Windows Server 2012. Par conséquent, un .NET Framework de
configuration utilisateur 4.0 est créé lorsque vous installez SQL Server 2012. En outre, la .NET Framework
3.5 est activée pendant l’installation.
Lorsque vous essayez d’installer la deuxième instance de SQL Server 2012, l’installation utilise .NET
Framework 2.0, car la .NET Framework 3.5 est déjà installée. Cela entre en conflit avec le paramètre dans
le fichier de configuration de l’utilisateur, ce qui provoque l’exception non gestion.
Dans Windows 8.1 et Windows Server 2012 R2, ce problème se produit car le .NET Framework 4.5 est
activé par défaut dans Windows 8.1 et Windows Server 2012 R2. Par conséquent, un .NET Framework de
configuration utilisateur 4.5 est créé lorsque vous installez SQL Server 2012. En outre, la .NET Framework
3.5 est activée pendant l’installation.
Framework 2.0, car la .NET Framework 3.5 est déjà installée. Ce conflit avec le paramètre dans la
configuration de l’utilisateur provoque l’exception nonmenée.
Dans Windows 10 et Windows Server 2016, ce problème se produit car la .NET Framework 4.6 est
activée par défaut. Par conséquent, un .NET Framework de configuration utilisateur 4.6 est créé lorsque
vous installez SQL Server 2012. En outre, la .NET Framework 3.5 est activée pendant l’installation.
Framework 2.0, car la .NET Framework 3.5 est déjà installée. Cela entre en conflit avec le paramètre dans
le fichier de configuration de l’utilisateur, ce qui provoque l’exception non gestion.
Prévention
Pour éviter ce problème, supprimez le fichierUser.config dans le dossier suivant avant d’installer la
deuxième instance de SQL Server 2012 :
%userprofile%\AppData\Local\Microsoft_Corporation\LandingPage.exe_StrongName_ryspccglaxmt4nhllj5z3thycltsvyyx\11.0.0.0
Résolution
NOTE
This issue is fixed in Microsoft SQL Server 2012 Service Pack 1 (SP1).
Si le Service Pack 1 est déjà installé sur la première instance, vous ne devez pas connaître ce problème. Si
vous ne pouvez pas installer le Service Pack 1 sur la première instance, faites l’une des choses suivantes :
Installez la deuxième instance SQL Server 2012 à partir d’un package d’installation inclut SQL
Server 2012 et Microsoft SQL Server 2012 Service Pack 1. Après l’installation de la nouvelle
instance, vous devez appliquer SQL Server 2012 Service Pack 4 ou une mise à jour ultérieure. Pour
plus d’informations,voir Comment obtenir le dernier Service Pack pour SQL Server 2012.
Pre-patch by using the SQL Server 2012 SP4 files and then install SQL Server 2012:
Sur un ordinateur sur lequel SQL Server 2012 RTM n’est pas installé :
1. Téléchargez et installez SQL Server 2012 SP4.
2. Dans l’écran Termes du contrat de licence, cliquez sur la case à cocher J’accepte les
termes du contrat de licence, puis cliquez sur Suivant .
NOTE
Les fichiers d’installation sont installés et l’Assistant d’installation se ferme
automatiquement.
3. Vérifiez l’installation. Pour ce faire, démarrez Ajouter ou supprimer des

programmes et vérifiez que les informations suivantes sont répertoriées :
Microsoft SQL Server installation 2012, version 11.0.7001.0
Deux entrées pour Microsoft Visual C++.
Sur un ordinateur qui possède une instance existante de SQL Server 2012 RTM :
1. Téléchargez et installez SQL Server 2012 SP4.
2. Extrayons les fichiers SP4 dans un dossier local. Par exemple, extrayons les fichiers
SP4 dans c:\sp4 .
NOTE
Vous ne pouvez pas exécuter SQL Server 2012 SP4 dans ce scénario.
3. Dans le dossier où vous avez extrait les fichiers SP4, double-cliquez sur
SqlSuppor t.msi puis cliquez sur Oui .
4. Vérifiez l’installation. Pour ce faire, démarrez Ajouter ou supprimer des programmes
et vérifiez que le programme d’installation Microsoft SQL Server 2012, version
11.0.7001.0 est répertorié.
NOTE
Consultez la section Instructions d’installation de la page SQL Server 2012 SP4 pour déterminer le
téléchargement correct pour votre serveur.
Problème 2 : vous ne pouvez pas installer un cluster de SQL Ser ver 2012 avec la
fonctionnalité par tage de flux de fichiers activée sur Windows Ser ver 2012 R2 ou Windows
Ser ver 2012
Symptômes
Vous pouvez recevoir un message d’erreur semblable à celui-ci lorsque vous essayez d’installer un
nouveau cluster de SQL Server 2012 avec la fonctionnalité de partage activée sur FileStream Windows
Server 2012 :
Une erreur s’est produite lors de l’affectation de la valeur « System.Byte[] » à la propriété privée «
Security0x20Descriptor » pour la ressource « SQL Server Filestream share (FILESTREAM) ». Erreur :
échec de l’appel du code de cluster à partir d’un fournisseur. Message d’exception : in trouvé.
Cause
Ce problème se produit car la prise en charge de la propriété Security Descriptor a été abandonnée dans
Prévention
Pour éviter ce problème, installez le cluster deover sans activer la FileStream fonctionnalité de partage.
Une fois l’installation terminée, activez la FileStream fonctionnalité Partager.
Résolution
NOTE
This issue is fixed in Microsoft SQL Server 2012 Service Pack 1 (SP1).
Pour résoudre ce problème, désinstallez l’instance de cluster qui a échoué à l’aide de l’option Ajouter ou
Supprimer des programmes, puis installez le cluster deover sans la fonctionnalité FileStream de
partage activée. Une fois l’installation terminée, activez la FileStream fonctionnalité Partager.
Problème 3 : Erreur lors de SQL Ser ver 2012 : « Une tentative de chargement d’un
programme avec un format incorrect a été tentée »
Symptômes
Vous installez une version 64 bits de Windows 10, Windows 8.1 ou Windows 8.
Vous essayez d’installer SQL Server 2012 en mode Windows sur Windows (WoW).
L’installation SQL Server 2012 inclut Reporting Services.
Dans ce scénario, l’installation échoue. En outre, vous recevez un message d’erreur semblable à ce qui suit
:
Échec de l’opération avec 0x8007000B

Une tentative de chargement d’un programme avec un format incorrect a été tentée.
Prévention
Pour éviter ce problème, installez le composant IIS ASP.NET 3.5 à l’aide du Gestionnaire de serveur avant
d’installer SQL Server 2012. Pour plus d’informations, voir ASP.NET 2.0 et ASP.NET 3.5ne fonctionnent pas
après la désinstallation de ASP.NET 4.5 dans Windows 8 ou Windows Server 2012 .
Problème 4 : vous ne pouvez pas installer une instance de cluster SQL Ser ver 2012 Êdition
Entreprise de point de contrôle
Symptômes
Vous pouvez :
Vous créez un package d’installation inclut SQL Server 2012 et CU1.
Vous pré-patchez à l’aide de CU1 avant d’installer SQL Server 2012.
Vous installez SQL Server 2012 à l’aide de l’option UIMODE=EnableUIOnSer verCore.
Dans ce scénario, l’installation échoue. Vous recevez un message d’erreur semblable à ce qui suit.
Les détails de l’erreur ressemblent à ce qui suit.
Cause
Ce problème se produit car la fonctionnalité est implicitement sélectionnée avec le composant DQ
engine pendant l’installation.
NOTE
La DQ fonctionnalité n’est pas prise en charge en mode Server Core.
Résolution
NOTE
Le problème est résolu dans SQL Server 2012 RTM CU3 et SQL Server 2012 Service Pack 1.

Créez un package d’installation inclut SQL Server 2012 et CU3.
Pre-patch the setup support files by running the CU3 installation package.
Problème 5 : Message d’erreur lorsque vous essayez de mettre à niveau le nœud de cluster
vers SQL Ser ver 2012 : « Les propriétés communes de la ressource 'SQL Network Name ( )
n’ont pas pu être enregistrées <SQL Name> »
Pour plus d’informations sur ce problème et sur la façon de le résoudre, consultez l’erreur « Les
propriétés communes de la ressource « nom du réseau SQL () » n’ont pas pu être enregistrées lorsque
vous essayez de mettre à niveau le nœud de cluster vers SQL Server 2012.
Problème 6 : Message d’erreur lorsque vous utilisez l’API OpenSQLFileStream : «
System.ComponentModel.Win32Exception (0x80004005) : la demande n’est pas prise en
charge. »
Symptômes
Vous installez une instance de SQL Server 2008 R2 sur un serveur qui exécute Windows Server 2012.
Vous devez mettre à niveau l’instance SQL Server 2008 R2 vers SQL Server 2012 Service Pack 1
(SP1).
Vous utilisez OpenSQLFileStream l’API.
Dans ce cas, un message d’erreur semblable au suivant s’affiche :
System.ComponentModel.Win32Exception (0x80004005) : la demande n’est pas prise en charge.
Cause
Ce problème se produit car la mise à niveau SQL Server 2012 supprime à tort la clé de Registre suivante :
HKEY_LOCALMACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\FsctlAllowList\FSCTL_SQL_FILESTREAM_FETCH_OLD_CONTENT
Pour contourner ce problème, utilisez l’Éditeur du Registre pour re-créer la clé de Registre suivante :
HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\FsctlAllowList
Dword: FSCTL_SQL_FILESTREAM_FETCH_OLD_CONTENT
Value: 0x92560
Références
Pour plus d’informations sur le déploiement de .NET Framework 3.5, voirMicrosoft .NET Framework 3.5
Deployment Considerations.
Pour plus d’informations sur l’utilisation de ASP.NET 3.5 et ASP.NET 4.5 dans IIS 8.0, voirIIS 8.0 Using
ASP.NET 3.5 and ASP.NET 4.5.
Pour plus d’informations sur les problèmes qui peuvent se produire après l’installation de ASP.NET 4.5,
voirASP.NET 2.0 et ASP.NET 3.5ne fonctionnent pas après la désinstallation de ASP.NET 4.5 dans Windows
8 ou Windows Server 2012 .
Pour plus d’informations sur l’installation du clustering de Windows Server 2012, voir Installation de la
fonctionnalité et des outils ducluster deWindows Server 2012 .
Voir aussi
Comprendre les .NET Framework requises pour différentes versions de SQL Server.
Installer SQL Server 2008 X64 et SQL Server 2008
Reporting services X86 côte à côte sur Windows
2008 X64
Cet article montre comment installer SQL Server 2008 x64 et SQL Server 2008 Reporting services X86 côte à
côte sur Windows 2008 X64.
Symptômes
Vous exécutez un Windows 2008 qui exécute la version x64 du SQL Server de base de données 2008. Dans ce
scénario, si vous essayez d’installer la version x86 du composant SQL Server 2008 Reporting Services à l’aide
de « Ajouter des fonctionnalités à une instance existante de SQL Server 2008 », le programme d’installation
signale le message d’erreur suivant dans la page Règles d’installation.
RUL E ÉTAT
Installation de la même architecture Échec
Si vous cliquez sur l’état Échec, vous verrez le message suivant :
La règle « installation de la même architecture » a échoué.

L’architecture du processeur d’installation des fonctionnalités est différente de l’instance spécifiée. Pour
continuer, ajoutez des fonctionnalités à cette instance avec la même architecture.
Cause
Le comportement est de par sa conception. Lorsque vous avez choisi l’option d’ajout de fonctionnalités à
l’instance existante, la règle vérifie si les fonctionnalités ajoutées sont de la même architecture de processeur
que les fonctionnalités existantes pour cette instance et, si ce n’est pas le cas, elle bloque
Same architecture installation l’installation. En d’autres termes, vous ne pouvez pas installer une version 64
bits d’un composant (comme le moteur de base de données) et une version 32 bits d’un autre composant
(comme Reporting Services) pour la même instance de serveur SQL.
Résolution
Utilisez la procédure suivante pour installer l’édition 32 bits du composant Reporting Services :
1. Lancez SQL Server centre d’installation en exécutant setup.exe à partir du support d’installation.
2. Dans la section Options, sélectionnez le type de processeur en tant que x86.
3. Dans la section Installation, sélectionnez Nouvelle installation SQL Server autonome ou ajoutez des
fonctionnalités à une installation existante.
4. Dans l’écran Type d’installation pendant le processus d’installation, sélectionnez Effectuer une nouvelle
instance de SQL Ser ver 2008 et poursuivez l’installation pour effectuer une installation d’installation en
fichiers uniquement (Reporting Services) de l’instance reporting services et configurer la même instance à
une étape ultérieure à l’aide du Gestionnaire de configuration reporting services.
Vous ne pouvez pas mettre à jour un cluster SQL
Server 2012 lorsque le programme d’installation
vérifie Cluster_IsOnlineIfClustered règle
Cet article vous aide à résoudre le problème qui se produit lorsque le programme d’installation vérifie la
Cluster_IsOnlineIfClustered règle.

Symptômes
Dans un environnement de cluster, vous installez une instance de Microsoft SQL Server 2012.
Vous essayez d’installer SQL Server Service Packs ou des mises à jour cumulatives sur le serveur qui
contient cette instance.
Dans ce cas, l’opération d’installation échoue au début du processus. Plus précisément, l’opération échoue
lorsque le programme d’installation vérifie la Cluster_IsOnlineIfClustered règle. En outre, un message
semblable à ce qui suit est consigné dans Detail.txt fichier :
<Time Stamp> Slp: Init rule target object:

Microsoft.SqlServer.Configuration.Cluster.Rules.ClusterServiceFacet
<Time Stamp> Slp: The given key was not present in the dictionary.
<Time Stamp> Slp: at Microsoft.SqlServer.Chainer.Infrastructure.ServiceContainer.GetService(Type
serviceType)
at Microsoft.SqlServer.Chainer.Infrastructure.ServiceContainer.GetService[T]()
at Microsoft.SqlServer.Chainer.Infrastructure.ServiceContainer.get_Cluster()
at
Microsoft.SqlServer.Configuration.Cluster.Rules.ClusterServiceFacet.Microsoft.SqlServer.Configuration.RulesE
ngineExtension.IRuleInitialize.Init(String ruleId)
at Microsoft.SqlServer.Configuration.RulesEngineExtension.RulesEngine.Execute(Boolean stopOnFailure)
<Time Stamp> Slp: Rule initialization failed - hence the rule result is assigned as Failed
NOTE
Le Detail.txt se trouve à %ProgramFiles%\Microsoft SQL Server\110\Setup Bootstrap\Log\<YYYYMMDD_HHMM>
l’emplacement .
Cause
Ce problème se produit en raison d’un espace de noms MSCluster non valide dans Windows Management
Instrumentation (WMI).
Résolution
Pour résoudre ce problème, suivez les étapes suivantes :
1. À l’invite de commandes d’administration, cd %systemroot%\system32\wbem tapez, puis appuyez sur
Entrée.
2. Tapez la commande : regsvr32 cluswmi.dll et appuyez sur Entrée.
3. Tapez la commande suivante : mofcomp.exe ClusWMI.mof et appuyez sur Entrée.
4. Réexécutez le programme d’installation des Service Packs ou des mises à jour cumulatives sur le serveur.
Pour identifier que ce problème est dû à l’espace de noms WMI pour le cluster, suivez les étapes suivantes :
1. Connectez-vous en tant que compte qui est administrateur sur le cluster et exécute SQL Server
configuration.
2. Exécutez la commande à l’invite de commandes d’administration : wbemtest
3. Dans la fenêtre Windows Testeur d’instrumentation de gestion, cliquez sur Connecter....

4. Tapez root\MSCluster dans l’espace de noms, puis cliquez sur Connecter bouton. Dans ce cas, vous
pouvez recevoir un message d’erreur semblable à ce qui suit :
Number: 0x8004100e
Installation : WMI
Description : espace de noms non valide
NOTE
En tant que test supplémentaire, vous pouvez exécuter la requête suivante dans Windows PowerShell :
select name from <MSCluster_Cluster>
Si le problème n’est pas dû à un espace de noms MSCluster non valide, le résultat attendu est que le nom du
réseau de cluster est renvoyé.
S’applique à
SQL Server Web 2012
Mise à jour ou mise à jour d’une installation SQL
Server 2008
Cet article explique comment mettre à jour ou installer une installation de SQL Server 2008.
Introduction
Cet article explique comment mettre à jour ou glisser une installation de Microsoft SQL Server 2008 qui a
échoué à l’aide de la dernière mise à jour cumulative (CU) ou du Dernier Service Pack (SP). Utilisez ces
instructions lorsque vous ne pouvez pas installer SQL Server 2008 en raison d’un problème connu dans le
programme d’installation. La section SQL Server 2008 Setup hotfixes répertorie les articles de la Base de
connaissances Microsoft qui décrivent les problèmes d’installation connus et explique comment obtenir la
dernière mise à jour.
Deux situations sont à prendre en compte :
Vous essayez d’installer SQL Server 2008. Vous rencontrez un échec d’installation et les fichiers d’installation
sont installés sur l’ordinateur.
Vous souhaitez éviter de manière proactive les problèmes d’installation connus à l’aide d’une configuration
de mise à jour.
Il est recommandé de mettre à jour ou d’inséperper le SQL Server 2008 d’origine à l’aide du Service Pack 1, car
le Service Pack permet de mettre à jour l’intégralité du produit. Une mise à jour unique basée sur la version SQL
Server 2008 d’origine peut uniquement mettre à jour le SQL support technique.
Pour obtenir des réponses aux questions fréquemment posées sur le flux, consultez la rubrique SQL Server
2008 Slipstream Frequently Asked Questions on SQL Server Setup.
IMPORTANT
Pour SQL Server 2012 et les versions ultérieures, vous devez utiliser le paramètre /UpdateSource pour mettre à jour SQL
Server fichiers d’installation. Pour obtenir un exemple sur la façon de faire, voir Comment mettre à jour le programme
d’installation SQL Server 2012avec un package d’installation mis à jour (à l’aide de UpdateSource pour obtenir une
configuration intelligente).
Lorsque vous exécutez la version d’origine du programme d’installation SQL Server 2008, le programme
d’installation se copie lui-même sur l’ordinateur local, puis réexécute à partir de la copie locale. Par conséquent,
s’il existe une version ultérieure des fichiers de support sur l’ordinateur, le programme d’installation exécute ces
fichiers mis à jour. Par conséquent, vous pouvez mettre à jour SQL Server de support du programme
d’installation 2008 avant d’exécuter Setup.exe fichier.
À partir SQL Server 2008 Service Pack 1, vous pouvez mettre à jour SQL Server 2008 à l’aide de l’infrastructure
slipstream. Lorsque vous installez le Service Pack 1 à l’aide de la procédure d’ajout ou d’installation sur une
installation SQL Server 2008 existante, une entrée est créée pour le Service Pack dans Ajouter ou supprimer des
programmes. Vous pouvez désinstaller le Service Pack à l’aide de cette entrée.
Pour vérifier si un Service Pack est installé correctement, exécutez le rapport de découverte SQL disponible dans
le Centre d’installation SQL Server 2008. Vous devriez voir que les fonctionnalités sont de la version 10. n . xxxx ,
où n représente la version du Service Pack. Par exemple, 10.1. xxxx représente le Service Pack 1.
Mettre à jour une installation de SQL Server 2008

Lorsque vous essayez d’installer SQL Server 2008 à partir d’un DVD ou d’un partage réseau, l’installation
échoue en raison d’un problème avec la version finale du programme d’installation.
Les étapes suivantes décrivent comment mettre à jour SQL Server installation de 2008 lorsqu’un problème
d’installation se produit :
1. Si les fichiers de support du programme d’installation de SQL Server 2008 sont installés sur l’ordinateur,
vous appliquez une mise à jour de mise à jour (CU) ou un correctif logiciel pour mettre à jour les fichiers
de support du programme d’installation de SQL Server 2008, puis réexécutez le programme
d’installation à partir du DVD ou du partage réseau.
2. Si les fichiers SQL Server du programme d’installation 2008 ne sont pas installés, consultez la section «
Exécution proactive de l’installation ».
Pour déterminer si les fichiers de prise en charge du programme d’installation de SQL Server 2008 sont
installés sur l’ordinateur, affichez l’entrée à l’aide d’Ajouter ou de supprimer des programmes dans le Panneau de
configuration dans les systèmes d’exploitation qui sont antérieures à Windows Vista. Dans Windows Vista ou les
versions ultérieures de Windows, affichez l’entrée à l’aide des programmes et des fonctionnalités du Panneau de
contrôle. Pour appliquer une mise à jour un correctif ou un correctif logiciel et exécuter le programme
d’installation, suivez les étapes suivantes :
1. Si un correctif est disponible par le biais d’un correctif logiciel, téléchargez la mise à jour cu ou le correctif
logiciel, puis installez-le sur l’ordinateur en exécutant le fichier .exe ou à l’aide de la ligne de commande.
Le package détecte les fichiers de SQL Server du programme d’installation 2008 sur l’ordinateur, puis
applique une nouvelle version du fichier SQLSupport.msi.
2. Exécutez à nouveau le programme d’installation à partir du DVD ou du partage réseau. Le programme
d’installation détecte qu’une version ultérieure du fichier SQLSupport.msi est disponible sur l’ordinateur
et que le programme d’installation s’exécute à partir de la version locale sur l’ordinateur au lieu du DVD
ou du partage réseau.
Limites
Les limitations suivantes s’appliquent lorsque vous mettez à jour le programme d’installation ou utilisez la
procédure slipstream :
IMPORTANT
Vous devez désinstaller une installation qui a échoué si le Summary.txt journal indique que vous devez le
désinstaller.
Si vous utilisez la procédure slipstream pour mettre à niveau une installation vers une installation
Wow64, vous devez effectuer l’une des étapes supplémentaires suivantes :
Spécifiez le paramètre /Action sur la ligne de commande en plus du paramètre /x86.
Dans la page Options du Centre d’installation, sélectionnez x86 .
Si vous ajoutez des fonctionnalités à une instance où le service de base de données est déjà installé par le
biais de l’flux, l’installation risque d’échouer. Pour contourner ce problème, vous devez ajouter une
fonctionnalité à l’aide du support source SQL Server 2008 d’origine ou mettre à niveau l’instance vers
SP1, puis utiliser l’infrastructure slipstream.
Lorsque vous copiez des packages slipstream, utilisez des chemins d’accès qui ne contiennent pas
d’espaces. Si vous spécifiez un emplacement qui contient des espaces pour l’un ou l’autre des paramètres,
une défaillance se produit lors de la configuration /PCUSOURCE /CUSOURCE d’slipstream.
Exécution proactive de la configuration

Vous pouvez utiliser deux méthodes pour mettre à jour une installation de SQL Server 2008. Nous vous
recommandons d’utiliser la première méthode en raison des avantages suivants de l’infrastructure d’flux :
Vous pouvez rapidement mettre à jour SQL Server 2008 SP1 en une seule installation.
Réduisez les temps de redémarrage.
Améliorez l’expérience d’installation globale.
Évitez les problèmes de configuration connus.
Pour utiliser ces méthodes, l’administrateur doit obtenir les fichiers de support du programme d’installation SQL
Server 2008 mis à jour en téléchargeant la dernière mise à jour, le correctif logiciel ou le Service Pack. Pour plus
d’informations sur les correctifs d’installation inclus dans le dernier correctif logiciel et pour plus d’informations
sur le téléchargement du correctif logiciel, voir la section SQL Server 2008 Setup hotfixes. Après avoir obtenu
les fichiers de support SQL Server du programme d’installation 2008 mis à jour, utilisez l’une des méthodes
suivantes.
Utiliser la procédure slipstream pour mettre à jour SQL Server 2008

Cette méthode vous permet de mettre à jour l’intégralité du produit lorsque vous exécutez le programme
d’installation SQL Server 2008 après avoir suivi l’une des procédures suivantes :
Procédure 1 : Étapes de base du flux

Suivez les étapes suivantes pour créer une drop slipstream que vous pouvez utiliser pour installer le support
d’origine et un Service Pack en même temps.
1. Installez les conditions préalables suivantes pour SQL Server 2008.
.NET Framework 2.0 SP2 pour SQL Server 2008 Express Edition
.NET Framework 3.5 SP1 pour les autres éditions
Pour télécharger et installer .NET Framework 3.5 SP1, voir Microsoft .NET Framework 3.5 Service
Pack 1.
Windows Installer 4,5
Pour télécharger et installer Windows Installer 4.5, visitez le site Web Microsoft suivant
:https://go.microsoft.com/fwlink/?LinkID=49112
2. Téléchargez le package service pack qui correspond à votre architecture système. Par exemple,
téléchargez le package x64 de SQL Server 2008 Service Pack 1 si votre système est basé sur x64.
3. Extrayer le Service Pack en exécutant la commande : SQLServer2008SP1-KB968369-x64-ENU.exe /x:C:\SP1 .
4. Exécutez le Service Pack pour installer les fichiers d’installation sur l’ordinateur. Vous recevrez une boîte
de dialogue Fichiers de suppor t du programme d’installation si les fichiers de support du
programme d’installation n’ont pas été installés. Vous pouvez également exécuter le fichier suivant pour
installer les fichiers de support d’installation : C:\SP1\x64\setup\1033\sqlsupport.msi
5. Exécutez le Setup.exe à partir du support source SQL Server 2008 en spécifiant le paramètre /PCUSource.
Par exemple : Setup.exe /PCUSource=C:\SP1 .
Procédure 2 : Création d’un drop fusionné

Cette procédure décrit comment créer un nouveau média source qui inséra le support source d’origine et SQL
Server 2008 Service Pack 1. Lorsque vous créez ce drop fusionné, vous pouvez installer SQL Server 2008 SP1
en une seule étape.
NOTE
Il est recommandé d’effectuer d’abord une installation d’entrée à partir de la nouvelle liste de contrôle sur un
ordinateur de test avant de la déployer dans l’environnement de production.
Ces étapes sont pour la version anglaise de SQL Server 2008. Toutefois, elle fonctionne pour n’importe quelle
langue de SQL Server 2008 si vous obtenez la langue correcte du package de Service Pack.
1. Copiez le support source SQL Server 2008 dans c:\SQLServer2008_FullSP1 .

2. Téléchargez le package Service Pack 1. Les noms de package sont les suivants :
SQLServer2008SP1-KB968369-IA64-ENU.exe
SQLServer2008SP1-KB968369-x64-ENU.exe
SQLServer2008SP1-KB968369-x86-ENU.exe
3. Extrayons les packages comme suit :
SQLServer2008SP1-KB968369-IA64-ENU.exe/x:c:\SQLServer2008_FullSP1\PCU
SQLServer2008SP1-KB968369-x64-ENU.exe/x:c:\SQLServer2008_FullSP1\PCU
SQLServer2008SP1-KB968369-x86-ENU.exe/x:c:\SQLServer2008_FullSP1\PCU
NOTE
Veillez à effectuer cette étape pour toutes les architectures afin de vous assurer que le support d’origine est
correctement mis à jour.
4. Exécutez les commandes suivantes pour copier le fichier Setup.exe et le fichier Setup.rll de l’emplacement
extrait vers l’emplacement multimédia source d’origine.
robocopy C:\SQLServer2008_FullSP1\PCU c:\SQLServer2008_FullSP1 Setup.exe

robocopy C:\SQLServer2008_FullSP1\PCU c:\SQLServer2008_FullSP1 Setup.rll
5. Exécutez les commandes suivantes pour copier tous les fichiers (et non les dossiers), à l’exception
Microsoft.SQL.Chainer.PackageData.dll fichier, pour mettre à jour
C:\SQLServer2008_FullSP1\PCU\Architecture C:\SQLServer2008_FullSP1\Architecture les fichiers d’origine.
robocopy C:\SQLServer2008_FullSP1\pcu\x86 C:\SQLServer2008_FullSP1\x86 /XF
Microsoft.SQL.Chainer.PackageData.dll
robocopy C:\SQLServer2008_FullSP1\pcu\x64 C:\SQLServer2008_FullSP1\x64 /XF

robocopy C:\SQLServer2008_FullSP1\pcu\ia64 C:\SQLServer2008_FullSP1\ia64 /XF

NOTE
Si vous copiez accidentellement le fichier Microsoft.SQL.Chainer.PackageData.dll, vous pouvez recevoir le message
d’erreur suivant lorsque vous exécutez le Setup.exe fichier.
SQL Server Le programme d’installation a rencontré l’erreur suivante :

L’action spécifiée LandingPage n’est pas prise en charge pour l’SQL Server correction.
Code d'0x84BF0007
Si ce problème se produit, restituer le fichier Microsoft.SQL.Chainer.PackageData.dll la version d’origine.

6. Déterminez si vous avez le fichier Defaultsetup.ini dans les dossiers suivants :
C:\SQLServer2008_FullSP1\x86
C:\SQLServer2008_FullSP1\x64
C:\SQLServer2008_FullSP1\ia64
Si vous avez le fichier Defaultsetup.ini dans les dossiers, ouvrez le fichier Defaultsetup.ini, puis ajoutez
PCUSOURCE= ».\PCU » au fichier comme suit :
;SQLSERVER2008 Configuration File
[SQLSERVER2008]
...
PCUSOURCE=".\PCU"
Si vous n’avez pas le fichier Defaultsetup.ini dans les dossiers, créez le fichier Defaultsetup.ini dans les
dossiers et ajoutez le contenu suivant au fichier :
;SQLSERVER2008 Configuration File
[SQLSERVER2008]
PCUSOURCE=".\PCU"
NOTE
Ce fichier indique au programme d’installation où localiser le support source SP1 que vous avez extrait à l’étape 3.
7. Démarrez le programme d’installation.

NOTE
Vous ne devez pas effectuer la procédure d’SQL Server 2008 Service Pack 1 pour l’édition SQL Server 2008 Express. SQL
Server 2008 Express Edition SP1 est déjà un drop fusionné. Toutefois, vous pouvez utiliser la procédure slipstream pour
appliquer une mise à jour cumulative SQL Server 2008 Express edition.
Vérifier si vous avez terminé une mise à jour slipstream

Dans la page Règles d’installation, un élément Mettre à jour la règle de langue du média d’installation
s’affiche dans la liste des règles.
Dans la page Prêt à l’installation, le nœud Action indique qu’il s’agit d’une installation de flux. En
outre, un nœud Slipstream est affiché dans la liste.
Dans le fichier journal de synthèse, vous pouvez trouver le paramètre PCUSource.
Après l’installation, si vous exécutez le rapport de découverte des fonctionnalités SQL Server à partir du
Centre d’installation, vous devriez voir que les fonctionnalités sont de la version 10.1. xxxx .
Mettre à jour les SQL Server de support du programme d’installation

2008
Vous pouvez utiliser deux options pour installer les fichiers de SQL Server du programme d’installation de 2008.
Nous vous recommandons d’utiliser cette méthode pour installer SQL Server d’installation 2008 avant SQL
Server SP1.
NOTE
Pour les deux options, seuls les fichiers de SQL Server du programme d’installation 2008 sont mis à jour. Pour mettre à
jour l’ensemble du produit, vous devez exécuter le package de correctifs une fois le produit correctement installé.
Option 1 : installer le fichier SQLSupport.msi directement

Cette option est idéale pour l’exécution d’un programme d’installation corrigé sur un petit nombre d’ordinateurs.
1. Installez tous les composants prérequis SQL Server 2008 s’ils ne sont pas déjà installés. Microsoft
Windows Installer 4.5 doit être installé. Vous devez installer .NET Framework 2.0 SP2 pour SQL Server
2008 Express Edition et .NET Framework 3.5 SP1 pour les autres éditions. Vous devez télécharger la .NET
Framework 3.5 SP1 à partir d’Internet et appliquer le SP1 manuellement.
NOTE
Sur la plateforme IA-64, la .NET Framework 3.5 n’est pas prise en charge et la .NET Framework 2.0 SP2 est
requise. Vous pouvez installer la .NET Framework 2.0 SP2 à partir du média source. Le .NET Framework 2.0
SP2 se trouve dans le dossier suivant sur le support source
Drive_Letter:\ia64\redist\2.0\NetFx20SP2_ia64.exe :
Sur les plateformes x86 et x64, vous devez installer .NET Framework 3.5 SP1.
2. Double-cliquez sur le package de correctifs pour installer les fichiers de SQL Server du programme
d’installation 2008. Une fois que vous avez extrait le contenu du package, les fichiers de support SQL
Server du programme d’installation 2008 seront installés. Le package de correctifs terminera
l’installation sans vous en informer une fois l’installation terminée. Pour confirmer que les fichiers sont
installés, affichez l’entrée à l’aide de l’élément Ajouter ou supprimer des programmes du Panneau de
Windows Vista. Dans Windows Vista ou versions ultérieures de Windows, affichez l’entrée à l’aide de
l’élément Programmes et fonctionnalités du Panneau de contrôle.
3. Démarrez le programme d’installation à partir du DVD ou du partage réseau.
Option 2 : Mettre à jour les fichiers multimédias d’origine

Cette option est la meilleure pour l’exécution d’une configuration corrigé sur de nombreux ordinateurs,
déploiements de grande taille ou lorsqu’un administrateur souhaite rendre cette configuration corrigé
disponible pour les utilisateurs. Il est important de suivre ces étapes avec soin et entièrement avant de mettre
cette option à la disposition d’autres personnes.
1. Téléchargez le correctif logiciel qui inclut les fichiers de support du programme d SQL Server 2008 mis à
jour que vous souhaitez utiliser pour mettre à jour les fichiers multimédias d’origine. Vous devez
télécharger les correctifs pour les plateformes x86, x64 et IA-64, car le média d’origine contient les fichiers
pour chaque plateforme.
2. À l’invite de commandes, tapez la commande suivante, puis appuyez sur Entrée pour extraire le contenu
du package hotfix_package_name/x:c:\kb _number_of_hotfix package\architecture :
L’espace réservé d’architecture représente les différentes plateformes matérielles. Par exemple, il peut
représenter l’un des dossiers suivants :
x86
x64
IA64
Les exemples suivants montrent comment utiliser cette commande :
SQLServer2008-KB956717-IA64.exe /x:c:\kb956717\ia64
SQLServer2008-KB956717-x64.exe /x:c:\kb956717\x64
SQLServer2008-KB956717-x86.exe /x:c:\kb956717\x86
3. Copiez le contenu du DVD SQL Server 2008 sur le disque dur local.
4. Copiez les fichiers suivants :
Copiez les Setup.exe et Setup.rll du dossier qui contient la copie
C:\kb_number_of_hotfix package\folder locale du media\ dossier.
Copiez tous les fichiers (et non les sous-dossiers) du dossier d’architecture, à l’exception du
fichier Microsoft.SQL.Chainer.PackageData.dll, du dossier vers le dossier qui contient la copie
C:\kb_number_of_hotfix package\architecture\architecture\ locale du media\architecture\ dossier.
5. Démarrez le programme d’installation à partir du dossier local.
NOTE
En raison des modifications de schéma introduites dans les packages de mise à jour cumulative RTM pour SQL Server
2008 qui commencent par le package de mise à jour cumulative 8, vous pouvez recevoir le message d’erreur suivant
lorsque vous exécutez le programme d’installation. Vous pouvez recevoir le message d’erreur suivant après avoir mis à
jour les fichiers de support du programme d’installation à l’aide de la procédure décrite dans l’option 2 :
2010-01-14 15:34:36 Slp : Type d’exception :

Microsoft.SqlServer.Chainer.Infrastructure.ChainerInfrastructureException
2010-01-14 15:34:36 Slp : Message :
2010-01-14 15:34:36 Slp : l’attribut « Path » n’est pas déclaré.
Pour éviter ce problème de validation, nous vous recommandons de copier le fichier

Microsoft.SQL.Chainer.PackageData.dll à partir du support RTM et de conserver le fichier
Microsoft.SQL.Chainer.Package.dll d’origine au même emplacement que Microsoft. SQL. Fichier
Chainer.Package.Package.xsd. Faites-le pour vous assurer que les deux fichiers .dll sont synchronisés. Cette
combinaison de .dll fichiers installe la version RTM de SqlSupport.msi (10.00.1600.22). Pour bénéficier des
correctifs de bogues présents dans la mise à jour cumulative, utilisez l’une des méthodes suivantes :
Méthode 1
Installez manuellement le fichier SQL support technique .msi'architecture particulière à partir de
l’emplacement d’extraction du package de mise à jour cumulative suivant CU8\<CPU>\setup\sqlsupport.msi
:
Méthode 2
Outre les fichiers répertoriés à l’étape 4 de l’option 2, les fichiers décrits dans les étapes suivantes doivent
être copiés avant de commencer l’installation à partir d’un dossier local. Pour copier les fichiers, en
suivant ces étapes.
1. Copiez le Microsoft.SQL.Chainer.Package.dll du dossier RTM vers la copie locale du
<media>\<architecture folder> dossier.
2. Copiez Sqlsupport.msi fichier. Parmi les emplacements suivants, copiez le fichier du premier
emplacement vers la copie locale du deuxième emplacement :
C:\<kb_number_of_hotfix package>\<architecture>\setup\Sqlsupport.msi
<media>\<architecture folder>\setup\
SQL Server de configuration 2008

Pour plus d’informations sur les problèmes d’installation connus et sur les correctifs à prendre pour résoudre
ces problèmes, cliquez sur les numéros d’article suivants pour consulter les articles de la Base de connaissances
Microsoft :
KB957453 - CORRECTIF : lorsque vous installez SQL Server 2008, l’installation échoue et le message
d’erreur « Attributs ne correspondent pas » est consigné dans le fichier Summary.txt
KB957459 - CORRECTIF : message d’erreur lorsque vous essayez d’ajouter un deuxième nœud à un
cluster de SQL Server 2008 : « La référence SKU actuelle n’est pas valide »
NOTE
Si d’autres problèmes de configuration sont identifiés, d’autres articles de la Base de connaissances Microsoft seront
publiés et inclus dans cette liste.
Obtenir des correctifs de configuration pour SQL Server 2008

Un package de mise à jour cumulative pris en charge est désormais disponible auprès de Microsoft. Toutefois, il
est destiné à corriger uniquement les problèmes décrits dans cet article. Appliquez-le uniquement aux systèmes
qui rencontrent ces problèmes spécifiques. Ce package de mise à jour cumulative peut recevoir des tests
supplémentaires. Par conséquent, si vous n’êtes pas gravement affecté par l’un de ces problèmes, nous vous
recommandons d’attendre le service pack SQL Server 2008 suivant qui contient les correctifs logiciels de ce
package de mise à jour cumulative. Pour plus d’informations sur le package de mise à jour cumulative, cliquez
sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :
KB956717 - Package de mise à jour cumulative 1 pour SQL Server 2008
S’applique à
SQL Server Web 2008
Erreur lors de la mise à niveau du nœud de cluster
vers SQL Server 2012
Cet article fournit une solution au problème qui se produit lorsque vous essayez de mettre à niveau une
instance SQL Server 2008 ou SQL Server 2008 R2 vers SQL Server 2012 sur un cluster deover.
Symptômes
Vous avez un cluster de Microsoft SQL Server deux nœuds qui s’exécute sur un cluster de Windows
Server 2012'exécution. Par exemple, le nœud principal est le nœud A et le nœud passif le nœud B.
NOTE
L’instance de SQL Server est une instance SQL Server 2008 ou SQL Server 2008 R2.
Vous essayez de mettre à niveau le nœud principal (nœud A) vers SQL Server 2012 en utilisant le
processus documenté dans : Mettre à niveau une instance de cluster de failover.
Les propriétés courantes de la ressource « SQL Network Name ( SQL Name ) »n’ont pas pu être
enregistrées. Erreur : échec de l’appel du code de cluster à partir d’un fournisseur. Message d’exception : une
ou plusieurs valeurs de propriété pour cette ressource sont en conflit avec une ou plusieurs valeurs de
propriété associées à ses ressources dépendantes.
NOTE
SQL Le nom est un espace réservé pour le nom SQL Server réseau.
Même si ce problème provoque un échec de mise à niveau sur le nœud A, le groupe de ressources SQL Server échoue
avec succès sur le nœud mis à niveau B. En outre, étant donné que l’opération deover prend moins d’une minute,
toutes les ressources sont en ligne sans perturber sensiblement la connectivité client. Toutefois, pour terminer le
processus de mise à niveau sur le nœud A, vous devez suivre des étapes supplémentaires mentionnées dans la section
Résolution.
Cause
Ce problème se produit en raison des modifications apportées au clustering Windows Server 2012 de pointage.
Résolution
Cette section couvre les actions suivantes :
Terminez la mise à niveau sur le nœud A.
Empêchez le problème d’affecter les nouvelles mises à niveau.
Terminer la mise à niveau sur le nœud A

Avant de commencer ce processus, ez compte des opérations suivantes :
Vous ne pouvez pas supprimer le nœud A à l’aide de l’opération Remove Node. Cette opération
supprime l’instance SQL Server de cluster de failover. Par conséquent, vous ne pouvez pas le réparer.
Vous ne pouvez pas désinstaller l’instance SQL Server de cluster de failover à l’aide de La
désinstallation d’un programme . Cette opération ne fonctionne pas.
Vous ne pouvez pas utiliser une édition incorrecte du support d’installation (par exemple, SQL Server
2008 ou SQL Server 2008 R2) pour exécuter l’opération Supprimer le nœud. Cette opération
endommagé l’état de l’ordinateur.
Pour terminer la mise à niveau pour le nœud A, il existe deux phases :
Phase 1 : Nettoyage après l’échec de la tentative de mise à niveau sur le nœud A pour restaurer l’état
préalable à la mise à niveau
1. Fermez le programme d’installation et la boîte de dialogue d’erreur s’ils ne sont pas déjà fermés,
laissez le programme de mise à niveau se terminer et signalez que l’opération de mise à niveau a
échoué.
2. Supprimez le nœud A de la liste des propriétaires possibles afin d’éviter d’y revenir
accidentellement. Pour modifier la liste des propriétaires possibles, vous pouvez :
a. Démarrez le logiciel en snap-in du Gestionnaire du cluster de failover sur n’importe quel nœud
deover.
b. Sous Rôles, sélectionnez l SQL Server de cluster de failover dans le volet supérieur.
c. Cliquez sur Ressources dans le volet inférieur, cliquez avec le bouton droit sur la ressource
Nom du serveur, puis sélectionnez Propriétés.
d. Cliquez sur Stratégies avancées dans la boîte de dialogue Propriétés.
e. Cochez ou supprimez les cases à cocher nécessaires pour chaque nœud afin d’ajouter ou de
supprimer les nœuds.
3. Ouvrez lesummary.txt à l’emplacement suivant :
%Program Files%\Microsoft SQL Server\110\Setup Bootstrap\Log
Recherchez la commande de dépannage suivante dans summary.txt fichier :

setup /q /action=uninstall /instanceid=FOOINST /features=AS
4. Ouvrez une invite de commandes en tant qu’administrateur et utilisez la commande de dépannage

avec le chemin d’accès du fichier d’installation SQL Server 2012 (setup.exe). Par exemple, vous
utilisez une commande qui ressemble à ce qui suit :
*SQL Server 2012 media path* \setup.exe /q /action=uninstall /instanceid=FOOINST /features=AS
NOTE
SQL Ser ver 2012 media path is a placeholder for the path of the SQL Server 2012 media.
Cette commande s’exécute en mode silencieux et se termine généralement dans les cinq minutes.
Vous pouvez copier et coller les arguments de ligne de commande du fichier summary.txt pour éviter
les erreurs d’entrée. Toutefois, la fonctionnalité doit être transmise en tant que paramètre identique à ce
qui est suggéré dans AS summary.txt fichier. Une entrée incorrecte de cette commande (en particulier
le paramètre) entraîne l’échec de l’opération de nettoyage et risque de laisser l’ordinateur instanceid
endommagé.
Vérifiez le summary.txt pour vérifier que l’opération de nettoyage s’est correctement terminée.
Phase 2 : Mise à niveau du nœud A vers SQL Server 2012

1. Démarrez le SQL Server d’installation 2012 en mode interface utilisateur.
2. Sélectionnez l’option Mise à niveau sous le menu Installation à partir de la page d’accueil, puis
allez dans la boîte de dialogue Configuration de l’instance.
3. Sélectionnez le nom d’instance correct, puis entrer la valeur correcte dans le champ ID
d’instance.
NOTE
En continuant l’exemple de la phase 1, la valeur de l’ID d’instance est FOOINST .
Le programme d’installation ne détermine pas automatiquement l’ID d’instance. Par conséquent, vous
ne pouvez pas utiliser l’ID d’instance pré-compilé par défaut dans le champ ID d’instance.
Vous pouvez consulter le fichiersummary.txt pour trouver l’ID d’instance correct.
4. Terminez le processus de mise à niveau.

5. Une fois le nœud A correctement mis à niveau, ajoutez-le à la liste des propriétaires possibles sur
la ressource Nom de serveur de l’instance de cluster SQL Server de changement de nom.
Empêcher le problème d’affecter les nouvelles mises à niveau

Pour éviter ce problème, utilisez l’une des options suivantes :
Option 1
1. Ne pas mettre à niveau plus de la moitié des nodes passifs en premier, pour éviter de traverser le
seuil de majorité.
NOTE
Si vous avez un nombre even de nodes de cluster, ne pas mettre à niveau plus de la moitié des nodes
passifs.
Si vous avez un nombre impair de nodes de cluster, veillez à mettre à niveau moins de la moitié des
nodes dans le cluster. Si la plupart des nodes du cluster sont mis à niveau, ce problème se produit
lorsque le groupe de ressources de cluster échoue.
2. Ajoutez manuellement les nodes passifs mis à niveau à la liste des propriétaires possibles pour la
ressource Nom du serveur.
3. Supprimez les nodes non mis à niveau de la liste des propriétaires possibles.
4. Faire échouer manuellement le groupe SQL Server cluster vers l’un des nodes mis à niveau.
5. Mettre à niveau les autres nodes non mis à niveau.
6. Lorsque tous les nodes non mis à niveau sont mis à niveau, ajoutez-les manuellement à la liste des
propriétaires possibles sur la ressource Nom du serveur.
Option 2
This issue is fixed in SQL Server 2012 Service Pack 1 (SP1). Vous pouvez effectuer le processus de mise à
niveau sur chaque nœud de cluster à l’aide des binaires du programme d’installation du Service Pack.
Pour ce faire, il existe deux méthodes.
Méthode A
1. Téléchargez SQL Server 2012 SP1 sur un disque dur local (par exemple vers ) ou sur un
partage réseau (par exemple, ) accessible par tous les c:\sp1 \\share name\sp1 nodes.
2. Démarrez une invite de commandes en tant qu’administrateur et exécutez l’une des
commandes suivantes :
<Download path>\setup.exe/action=upgrade/updatesource=c:\sp1
<Download path>\setup.exe/action=upgrade/updatesource=\\share name\sp1
3. Effectuer toutes les étapes du programme d’installation.
NOTE
Vous pouvez vérifier si la mise à niveau utilise les fichiers binaires d’installation SQL Server 2012
SP1 en vérifiant le fichier detail.log à l’emplacement suivant :
%Program Files%\Microsoft SQL Server\110\Setup Bootstrap\Log\<Time stamped folder>
Confirmez que les informations de version situées au début du fichier journal indiquent que
la version SQL Server 2012 est antérieure à la version 11.0.2100.60. Par exemple, le fichier
journal peut contenir les éléments suivants :
Méthode B
1. Téléchargez SQL Server 2012 SP1 sur un disque dur local (par exemple vers ) ou sur un
partage réseau (par exemple, ) accessible par tous les c:\sp1 \\share name\sp1 nodes.
2. Démarrez une invite de commandes en tant qu’administrateur et exécutez la commande
suivante :
Download path\SQL Server 2012 Service Pack 1 Package Name.exe/Q
Cette commande permet de pré-patcher le nœud avec les SQL Server d’installation de
2012 SP1.
NOTE
Vous ne pouvez pas installer le fichier SqlSupport.msi seul, car cela entraîne l’échec de l’opération
d’installation de SQL Server 2012 et une erreur de non-MSVCR100.dll s’affiche. Utilisez le /Q
paramètre pour éviter cette erreur. Ce paramètre installe le fichier Sqlsupport.msi et les
composants d’runtime Visual C++.
3. Effectuer toutes les étapes du programme d’installation.

Télécharger le Service Pack 1 pour SQL Server 2012
S’applique à
SQL Server Web 2012
Avertissement concernant l’ordre de liaison réseau
dans la page Règles de prise en charge du
programme d’installation
Cet article vous aide à résoudre le problème qui se produit lorsque vous installez SQL Server 2008 dans un
cluster deover.
Symptômes
Lorsque vous installez Microsoft SQL Server 2008 dans un cluster deover, vous recevez un message
d’avertissement concernant l’ordre de liaison réseau dans la page Règles de support du programme
d’installation.
NOTE
L’avertissement s’affiche même si l’ordre de liaison est correct : IsDomainNetworkTopOfBindings .
Vérifie si le serveur de domaine de l’ordinateur se trouve sur le réseau qui est lié au haut de l’ordre réseau.
Le réseau de domaine n’est pas le premier réseau lié. Cela ralentit l’activité des opérations de domaine et peut
entraîner des temps d’arrêt qui entraînent des échecs. Utilisez la configuration Windows réseau avancé pour
modifier l’ordre de liaison.
Cause
Ce problème peut se produire lorsque vous avez une carte réseau désactivée ou une carte réseau fantôme sur
l’ordinateur.
NOTE
Une carte réseau qui est éumée dans le Registre Windows mais qui est masquée dans le Gestionnaire de périphériques est
appelée carte réseau dédentée. This issue may occur when you change a network connection’s TCP/IP configuration from
DHCP to a static IP. Ce problème peut également se produire lorsque vous avez ajouté et supprimé plusieurs fois des
cartes réseau.
Résolution
Pour résoudre ce problème, supprimez les cartes réseau désactivées ou dédentées. Pour cela, procédez comme
suit :
1. À l’invite de commandes, tapez les lignes de commande suivantes :
set devmgr_Show_Nonpresent_Devices=1
start devmgmt.msc
start ncpa.cpl
NOTE
Veillez à appuyer sur Entrée après chaque ligne.
2. Dans le Gestionnaire de périphériques, développez les cartes réseau.

3. Comparez la liste des cartes réseau dans le Gestionnaire de périphériques à la liste des cartes réseau
affichées dans connexions réseau. Les cartes réseau présentes dans le Gestionnaire de périphériques,
mais pas dans les connexions réseau, sont des cartes réseau fantômes.
4. S’il existe des cartes réseau désactivées, activez ces cartes dans le Gestionnaire de périphériques ou dans
les connexions réseau.
5. S’il existe des cartes réseau dédentées, supprimez-les dans le Gestionnaire de périphériques.
6. Démarrez SQL Server configuration.
7. Une fois l’installation terminée, ouvrez Connexions réseau, puis désactivez les cartes réseau que vous ne
souhaitez pas.
Références
Créer une instance de cluster de failover Always On (installation)
Instances de cluster de failover Always On (SQL Server).
Résultats incohérents en calculs MKL en raison
d’une variable d’environnement manquante dans
Microsoft R Server ou Machine Learning Server
Cet article vous aide à résoudre le problème où vous obtenez des résultats incohérents en raison d’une variable
d’environnement manquante.
S’applique à : SQL Server 2017 sur Windows, Microsoft Machine Learning Server (R Server)
Symptômes
Lorsque vous exécutez Microsoft R Server 9.0, 9.1, 9.2, 9.3.x ou Microsoft Machine Learning Server dans le cadre
de Microsoft SQL Server 2017, vous découvrez des résultats incohérents dans les calculs MKL (Intel Math Kernel
Library). This issue occurs because of a missing MKL_CBWR environment variable.
Cause
Ce problème se produit parce qu’une nouvelle fonctionnalité a été ajoutée à la bibliothèque MkL Intel incluse
avec Microsoft R Server et SQL Server 2017. Pour plus d’informations sur cette fonctionnalité, voir Introduction
à la reproductibilité numérique conditionnelle (CNR)
Résolution
Pour résoudre ce problème, configurez la reproductibilité numérique conditionnelle dans Microsoft R Server ou
Machine Learning Server en configurant la variable d’environnement MKL_CBWR=AUTO System. Pour cela,
1. Dans le Panneau de contrôle, sélectionnez System and Security > System Advanced > System
Paramètres Environment > Variables .
2. Créez une variable utilisateur ou système et spécifiez les valeurs suivantes :
Définissez le nom de la variable sur MKL_CBWR .
Définissez la valeur de variable sur AUTO .
3. Redémarrez Microsoft R Server.
État
Microsoft a confirmé qu’il s’agit d’un problème dans les produits Microsoft.
Dans les futures versions Microsoft R Server, le paramètre MKL_CBWR=AUTO sera le paramètre par défaut.
Références
Problèmes connus dans SQL Server Machine Learning Services Exclusion de responsabilité des informations
tierces
produits.
La colonne bloquée dans la table sysprocesses est
remplie pour les attentes de verrou
Cet article indique que la colonne bloquée dans le tableau est remplie pour sysprocesses les attentes de verrou.
Résumé
Dans SQL Server, vous pouvez remarquer que la colonne bloquée dans la table système est remplie pour les
attentes de verrou en plus des sysprocesses attentes de verrouillage. Parfois, vous pouvez remarquer de
courtes périodes de temps lorsqu’un ID de processus de serveur unique (SPID) est signalé comme se bloquant
lui-même. Ce comportement est normal.
Les latches sont utilisées pour synchroniser l’accès aux pages de données mises en cache et à d’autres objets en
mémoire. En règle générale, les verrous sont maintenus brièvement et les temps d’attente des verrous sont
relativement petits. SQL Server des diagnostics pour vous aider à résoudre les cas dans lesquels un SPID attend
un long moment pour un verrou. Ces diagnostics provoquent la réflexion de la colonne bloquée dans la table
système sur le propriétaire d’un verrou qui bloque la demande de verrou sysprocesses d’un autre SPID.
La propriété du verrou est uniquement suivi pour les verrous verrous qui sont en mode verrouillage exclusif
(EX) ou de mise à jour (UP). La propriété n’est pas suivi pour les verrous verrous qui sont en mode verrou
partagé . Cela signifie que la colonne bloquée ne sera pas remplie pour certaines demandes de verrou.
La plupart du temps, vous pouvez ignorer la valeur dans la colonne bloquée si les conditions suivantes sont
vraies :
La valeur dans la waittime colonne est faible.
Le waittype spid est un type d’attente de verrou.
Pour plus d’informations sur les valeurs possibles dans la colonne, voir waittype sys.dm_os_wait_stats
(Transact-SQL).
Lorsqu’un SPID attend un verrou de page d’I/S, vous remarquerez peut-être que la colonne bloquée signale
brièvement que le SPID se bloque lui-même. Ce comportement est un effet secondaire de la façon dont les
latches sont utilisées pour les opérations d’entrée et de fin sur les pages de données. Lorsqu’un thread émettra
une demande d’O/S, le SPID qui émettra la demande d’O/S acquiert un verrou sur la page. Toutes SQL Server
opérations d’opérations d’SQL Server sont asynchrones. Par conséquent, le SPID essaiera d’acquérir un autre
verrou sur la même page si le SPID qui a émis la demande d’I/S doit attendre la fin de la demande. Ce deuxième
verrou est bloqué par le premier verrou. Par conséquent, la colonne bloquée signale que le SPID se bloque lui-
même. Lorsque la demande d’O/S se termine, le premier verrou est relâché. Ensuite, la deuxième demande de
verrou est accordée.
Par exemple, les conditions suivantes peuvent se produire :
1. SPID 55 souhaite lire une page de données qui n’existe pas dans le pool de mémoires tampons.
2. SPID 55 acquiert un verrou EX sur la page. Étant donné que la page n’existe pas encore en mémoire, le
mode verrou demandé est EX. Le mode verrouillage EX force d’autres SPID qui souhaitent également
accéder à la page à attendre la fin de la demande d’I/S. Le mode verrou EX empêche également d’autres
SPID d’émettre une demande d’E/S en double pour la même page.
3. SPID 55 demande de lecture de la page à partir du disque.
4. Étant donné que SPID 55 souhaite lire la page, SPID 55 doit attendre la fin de la demande d’O/S. Pour
attendre la fin de la demande d’E/S, SPID 55 tente d’acquérir un autre verrou qui a le mode verrou
partagé (SH) sur la même page. Étant donné qu’un verrou EX a déjà été acquis, la demande de
verrouillage SH est bloquée et le SPID est suspendu. Étant donné que le verrou EX qui bloque la demande
de verrouillage SH a également été acquis par SPID 55, le SPID est temporairement signalé comme
bloquant lui-même.
5. Lorsque la demande d’O/S se termine, le verrou EX de la page est libéré.
6. La libération du verrou EX donne le verrou SH à SPID 55.
7. SPID 55 peut désormais lire la page.
Entre les étapes 4 et 5, le tableau indique que sysprocesses SPID 55 est bloqué seul avec un type d’attente
PAGEIOLATCH_ XX . Dans ce type d’attente, XX peut être SH, UP ou EX. Ce comportement indique que SPID 55 a
émis une demande d’I/S et que SPID 55 attend la fin de la demande d’O/S.
Les opérations qui analysent SQL Server du pool de
mémoires tampons sont lentes sur les ordinateurs
mémoire de grande taille
Cet article décrit que l’analyse du pool SQL Server tampon de mémoire tampon peut prendre beaucoup de
temps sur des ordinateurs mémoire de grande taille.
Résumé
Certaines opérations dans SQL Server déclenchent une analyse du pool de mémoires tampons (le cache qui
stocke les pages de base de données en mémoire). Voici quelques opérations qui peuvent déclencher une
analyse de pool de mémoires tampons :
Démarrage de base de données
Arrêt/redémarrage de la base de données
Le failover AG
Suppression d’une base de données
Suppression d’un fichier d’une base de données
Sauvegarde complète/différentielle d’une base de données
Restauration d’une base de données
Restauration du journal des transactions
Restauration en ligne
DBCC CheckDB/CheckTable
Sur les systèmes avec une grande quantité de mémoire (1 To ou plus), l’analyse du pool de mémoires tampons
prend beaucoup de temps, ce qui ralentit l’opération qui a déclenché l’analyse.
Il n’existe actuellement aucun correctif à ce problème. S’il est essentiel que l’opération en question se termine
rapidement, envisagez d’effacer le pool de mémoires tampons à l’aide des commandes suivantes
USE <DatabaseName>; CHECKPOINT; GO :
Si le serveur possède plusieurs bases de données, répétez les commandes ci-dessus pour toutes les bases de
données utilisateur sur le serveur.
Une fois que toutes les bases de données sur le serveur ont été point de contrôle, exécutez la commande
DBCC DROPCLEANBUFFERS ;
WARNING
L’abandon de tampons nettoyés du pool de mémoires tampons supprime toutes les pages de base de données non
modifiées de la mémoire. Cela nécessite des requêtes ultérieures pour lire les données des fichiers de base de données sur
le disque et peut entraîner une dégradation grave des performances.
Pour plus d’informations sur les problèmes qui peuvent survenir à partir de pools de mémoires tampons de
grande taille, voir SQL Server : ram large et point de contrôle DB.
À partir SQL Server CU23 2017 et SQL Server 2019 CU9,la journalisation suivante et XEvents ont été ajoutés
pour vous aider à identifier les analyses de pool de mémoires tampons longues :
message errorlog
Si une analyse prend plus de 10 secondes, un message est imprimé comme suit :
L’analyse du pool de mémoires tampons a pris 14 secondes : ID de base de données 7, commande «

BACKUP DATABASE » et « FlushCache » opération, mémoires tampons analysées 115, nombre total de
mémoires tampons itérées 204640239, temps d’attente de 0 ms. Voir ' https://go.microsoft.com/fwlink/?
linkid=2132602 ' ' pour plus d’informations.
XEvent buffer_pool_scan_complete
Si une analyse prend plus d’une seconde, un événement XEvent est enregistré comme suit lorsque l’événement
est activé. Le seuil est plus petit pour pouvoir éventuellement capturer à une granularité plus fine.
EL A P SED_T IM SC A N N ED_B U TOTA L _IT ERA

NAME DATA B A SE_ID E_M S C O M M A N DE O P ERAT IO N F F ERS T ED_B UF F ERS
buffer_pool_s 7 1308 BASE DE FlushCache 243 19932814

can_complete DONNÉES DE
SAUVEGARDE
Diminution des performances pour les SQL Server
lorsque vous exécutez une clause d’agrégation TOP,
MAX ou MIN sur des colonnes autres que la
colonne de partitionnement
Cet article vous aide à contourner le problème dans lequel vous rencontrez une baisse des performances pour
les SQL Server lorsque vous exécutez ou l’agrégation de TOP MAX MIN clauses sur des colonnes.
Symptômes
Supposons que vous avez des tables partitionées dans Microsoft SQL Server. Lorsque vous exécutez TOP une
clause ou une clause MAX d’agrégation sur des colonnes des tables, vous pouvez être en situation de diminution
MIN des performances.
NOTE
Ce problème ne se produit que sur la colonne de partitionnement.
Pour contourner ce problème, créer une requête qui collecte les éléments TOP N de chaque partition. Ensuite,
recherchez les éléments TOP N de cette collection d’éléments.
Par exemple, vous disposez d’un tableau T1 qui possède quatre partitions et la fonction de partition est PF1 . La
table est partitionée sur la colonne PCOL et possède un index sur idx_c1 T1.c1 . Vous pouvez rencontrer le
problème de performances lorsque vous exécutez la requête suivante :
SELECT TOP 3 T1.c1, T1.c2
FROM dbo.T1
ORDER BY T1.c1

1. Recherchez les trois principaux éléments d’une partition donnée <par tition_number > :
SELECT TOP 3 T1.c1, T1.c2

FROM dbo.T1
WHERE $PARTITION.PF1(PCOL) = < **partition_number** > AS A(c1, c2)
ORDER BY T1.c1;
2. Recherchez les trois principaux éléments des quatre partitions :

SELECT TOP 3 A.c1, A.c2
FROM (VALUES((1),(2),(3),(4)) AS P( partition_number )
CROSS APPLY ( SELECT TOP 3 (T1.c1, T2.c2)
FROM dbo.T1
WHERE $PARTITION.PF1(T1.PCOL) = P.partition_number
ORDER BY T1.c1 ) AS A
ORDER BY A.c1
3. Malheureusement, si la table est repartitionée, vous devez réécrire ces requêtes pour utiliser le nouveau
nombre de partitions. Toutefois, vous pouvez également obtenir le nombre de partitions à partir de
sys.partitions . Par conséquent, au lieu d’utiliser une liste constante de partitions, vous pouvez utiliser
le script SQL suivant :
SELECT TOP 3 A.c1, A.c2

FROM sys.partitions AS P
CROSS APPLY ( SELECT TOP 3 T1.c1, T2.c2)
FROM dbo.T1
WHERE $PARTITION.PF1(T1.col1) = P.partition_number
ORDER BY T1.c1 ) AS A
WHERE P.object_id = OBJECT_ID('dbo.T1')
AND P.index_id = INDEXPROPERTY( OBJECTID('dbo.T1'), 'idx_c1', 'INDEXID')
ORDER BY a;
NOTE
Cet article utilise TOP N avec un ordre par clause comme exemple. MAX et MIN les clauses ont des problèmes
similaires. Par conséquent, il est possible de les contourner en les transformant en requêtes TOP 1, avec l’ordre
croissant ou décroit.
Lorsque vous interrogez les lignes TOP N d’une colonne indexée sur une table non partitionée, la requête
présente généralement de bonnes performances. Cela est dû au fait que le plan de requête analyse un index
pour déterminer les éléments principaux.
Toutefois, pour une table partitionée, ce n’est actuellement pas le cas, car les index peuvent également être
partitionés. Cela signifie que vous ne pouvez pas simplement interroger les index pour déterminer les éléments
N supérieurs. Ces éléments peuvent être répartis sur toutes les partitions. Par exemple, prenons le cas suivant
où vous avez une table « a » avec deux partitions P0 et P1 partitionn es autour de 0 :
PA RT IT IO N CLÉ VA L EUR
P0 -2 1
P0 -1 1
P0 0 12
P1 1 1
P1 2 1
P1 3 15
PA RT IT IO N CLÉ VA L EUR
Étant donné que chaque index est partitioné, SQL Server pas analyser l’index en même temps pour déterminer
la valeur maximale. Au lieu de cela, il analyse chaque élément du tableau pour déterminer la valeur maximale.
Dans un tableau qui compte des millions de lignes, ce processus peut être inefficace.
Problèmes de performances et de cohérence
lorsque certains modules sont chargés dans SQL
Server d’adressaie
Cet article vous aide à résoudre le problème qui se produit lorsque certains modules sont chargés dans SQL
Server’espace d’adressal.
Symptômes
Lorsque certains modules sont chargés dans l’espace d Microsoft SQL Server de traitement d'Sqlservr.exe, vous
pouvez rencontrer les symptômes suivants :
Rapports de diverses conditions et messages d’erreur liés à un blocage (par exemple, un message de SQL
Server de planification tel que 17883, des messages de délai d’application, un blocage grave au sein SQL
Server)
Réponse lente de la SQL Server même si la charge simultanée n’est pas anormalement importante
Exceptions (telles que les violations d’accès), messages d’erreur critique concernant la cohérence de la base
de données, messages d’assertion ou arrêt de processus inattendu
Utilisation du processeur à 100 % et temps de récupération de base de données longs lorsque vous utilisez
des tables OLTP en mémoire dans SQL Server
Échecs inattendus ou inexpliqués lorsque SQL Server processus de gestion Windows appels d’API
Cause
Ces problèmes se produisent car les applications ou autres logiciels installés sur un serveur exécutant SQL
Server peuvent charger certains modules dans le processus SQL Server (Sqlservr.exe). Cela peut être effectué
pour obtenir une exigence de logique métier spécifique, une fonctionnalité améliorée ou la surveillance des
intrusions. Ces modules peuvent effectuer des activités non pris en compte qui incluent la déviation des API
Win32 importantes et des routines SQL Server et l’appel d’API à risque. En outre, certains problèmes
intrinsèques au sein de ces modules peuvent entraîner l’altération de diverses structures de mémoire qui sont
nécessaires au SQL Server de fonctionnement correct.
WARNING
utilisateurs malveillants ou par des logiciels malveillants tels que des virus. Nous ne recommandons pas cette solution de
contournement, mais fournissons ces informations afin que vous pouvez implémenter cette solution de contournement à
votre propre discrétion. Son utilisation relève de votre responsabilité.

1. Identifiez le module chargé dans le processus SQL Server et qui est à l’origine du problème.
2. Effectuez les actions suivantes pour le module en question :
a. Configurez l’application pour qu’elle ne charge pas le module spécifique dans SQL Server processus.
b. Contactez le fournisseur du module ou de l’application pour vérifier les mises à jour. Appliquez toutes
les mises à jour disponibles.
c. Dans de rares cas, vous de devez supprimer le module et ses logiciels associés pour restaurer la
stabilité du SQL Server et du système.
NOTE
Dans certains cas, vous pouvez être dans l’devoir d’effectuer toutes ces actions.
L’équipe du support technique microsoft (CSS) a identifié les modules suivants qui peuvent provoquer les
symptômes mentionnés dans la section « Symptômes ». Cette liste sera mise à jour à mesure que de nouveaux
problèmes seront trouvés. Cette liste est fournie pour vous aider à identifier le processus mentionné dans la
section « Résolution ». Ce processus implique généralement la collecte d’un ensemble itératif de données de
diagnostic et de suivi pour la durée du problème.
Les modules suivants peuvent entraîner des problèmes de performances et de stabilité lorsqu’ils sont chargés
dans le SQL Server suivant :
ENTAPI.DLL
ENTAPI.DLL est chargé dans le processus SQL Server si vous installez Mc AntivirusScan Enterprise sur un
serveur exécutant Microsoft SQL Server, puis configurez ce logiciel pour surveiller les SQL Server.
Lorsque ce module est chargé, les API Win 32 importantes sont également SQL Server processus. Si vous
remarquez que ce module est chargé dans le processus SQL Server, configurez Mc AntivirusScan
Enterprise pour exclure SQL Server (Sqlservr.exe) de diverses surveillances avancées, telles que la
Protection contre le dépassement de mémoire tampon.
HIPI.DLL, HcSQL.dll, HcApi.dll, HcThe.dll
Ces fichiers DLL sont chargés dans le processus SQL Server si vous installez le logiciel de prévention des
intrusions de l’hôte Mc Llc sur le même système que SQL Server. Si vous remarquez que ce module est
chargé dans un processus SQL Server, configurez la prévention des intrusions hôtes Mc Antivirus pour
exclure les SQL Server (Sqlservr.exe) de sa liste de surveillance.
SOPHOS_DETOURED.DLL et SOPHOS_DETOURED_x64.DLL, SWI_IFSLSP_64.dll
Ces fichiers DLL sont chargés dans le processus SQL Server si vous installez le programme Antivirus
Sophos sur un serveur en cours d’exécution SQL Server. Si vous remarquez que ce module est chargé
dans le processus SQL Server, vous pouvez configurer la sous-clé de Registre AppInit_Dlls pour éviter de
charger ce module dans SQL Server processus.
PIOLEDB.DLL et PISDK.DLL
Ces fichiers DLL sont chargés dans le processus SQL Server si vous utilisez le fournisseur PI OLEDB pour
accéder aux données à partir d’un serveur PI ou si vous utilisez des procédures stockées étendues qui
utilisent le SDK PI. Si vous remarquez que ces modules sont chargés dans le processus SQL Server,
contactez le fournisseur de ces modules pour configurer le fournisseur OLEDB en tant que fournisseur
hors processus. Cette configuration permet d’éviter la nécessité de charger ces modules dans SQL Server
processus.
.DLL UMPPC,SCRIPTCONTROL.DLL
Ces fichiers DLL sont chargés dans l’espace d’adressaison de l’agent SQL Server ou SQL Server si vous
activez le paramètre de prévention « Données supplémentaires du mode utilisateur » pour les
programmes de protection anti-virus/point de terminaison CrowdStrike. Vous remarquerez peut-être des
échecs SQL Server’agent tente de créer de nouveaux processus lors de l’exécution de travaux. Vous
pouvez également rencontrer des échecs lors de la tentative de lancement SQL Server Management
Studio.
DLL relative au noir carbone
perfiCrcPerfMonMgr.dll
Ce fichier DLL est chargé dans le processus SQL Server si vous installez le client Trend Micro OfficeScan.
Reportez-vous au paramètre de liste d’exclusion des fournisseurs de logiciels dans la liste
d’exclusionsd’analyse recommandée pour les produits trend Micro Endpoint .
Pour plus d’informations sur la façon de définir des stratégies d’exclusion pour Sqlservr.exe dans le logiciel
d’application abordé dans cet article, consultez le manuel du produit ou contactez le fournisseur du logiciel.
produits.
Les informations et la solution de ce document représentent l’affichage actuel de Microsoft Corporation sur ces
problèmes à la date de publication. Cette solution est disponible par le biais de Microsoft ou d’un fournisseur
tiers. Microsoft ne recommande pas spécifiquement un fournisseur tiers ou une solution tierce que cet article
pourrait décrire. Il peut également y avoir d’autres fournisseurs tiers ou solutions tierces que cet article ne décrit
pas. Étant donné que Microsoft doit répondre à l’évolution des conditions du marché, ces informations ne
doivent pas être interprétées comme un engagement de Microsoft. Microsoft ne peut pas garantir ou approuver
la précision des informations ou des solutions présentées par Microsoft ou par un fournisseur tiers mentionné.
Microsoft n’offre aucune garantie et exclut toutes les représentations, garanties et conditions, qu’elles soient
express, implicites ou statutaires. Celles-ci incluent, sans s’y limiter, les représentations, les garanties ou les
conditions de titre, de non-contrefaçon, de condition satisfaisante, de qualité et d’aptitude à un usage particulier,
en ce qui concerne tout service, solution, produit ou tout autre matériel ou information. En aucun cas Microsoft
ne sera responsable de toute solution tierce mentionné dans cet article.
Références
Des déviations ou des techniques similaires peuvent entraîner des comportements inattendus avec SQL
Server
Comment exécuter un objet COM basé sur une DLL en dehors SQL Server processus
S’applique à
SQL Server 2005 Express Edition services avancés
SQL Server Web 2012
SQL Server Web 2014
SQL Server Web 2016
SQL Server Développeur 2017 sur Windows
SQL Server 2017 Enterprise sur Windows
SQL Server 2017 Enterprise Core sur Windows
SQL Server 2017 Standard Windows
L’utilisation de pilotes de filtre système peut
entraîner SQL Server Moteur de base de données
dégradation des performances et des problèmes de
cohérence
Cet article vous aide à résoudre le problème qui se produit lorsque certains pilotes de filtre sont chargés sur un
ordinateur en cours d’exécution SQL Server.
Symptômes
Vous pouvez rencontrer les symptômes suivants lorsque certains pilotes de filtre sont chargés dans un système
qui exécute Microsoft SQL Server composants :
Utilisation élevée du processeur pour le processus SQL Server, en particulier le temps processeur privilégié
Réponse lente de la SQL Server même lorsque la charge/l’activité simultanée n’est pas anormalement
importante
Rapports de diverses conditions et messages d’erreur liés à un blocage (SQL Server messages de
planification tels que 17883, les messages de délai d’arrêt de l’application et le blocage grave dans SQL
Server)
Cause
Les pilotes de filtre peuvent être installés sur un système dans le cadre du programme d’installation d’une
application pour fournir un certain type de fonctionnalité. Par exemple, la protection antivirus, les sauvegardes
en ligne, les services de chiffrement et les installations de compression ou de défragmentation des données. Ces
pilotes de filtre s’insèrent eux-mêmes dans la pile de pilotes Windows pour améliorer ou modifier le
comportement des demandes qui passent par la pile de pilotes et qui sont destinées à un appareil.
Dans certaines conditions, ces demandes peuvent prendre beaucoup de temps ou consommer des ressources
excessives. Lorsque cela se produit, divers problèmes se produisent et sont abordés dans la section Symptômes.
En outre, il peut y avoir une forme d’incompatibilité entre les différents pilotes de filtre présents dans la même
pile de pilotes, ce qui peut également entraîner certains des problèmes abordés dans la section Symptômes.
Résolution
L’approche générale pour résoudre ces situations est la suivante.
NOTE
Pour plus d’informations sur chacune des étapes suivantes, voir la section Plus d’informations :
1. Identifiez le pilote de filtre à l’origine du problème.

2. Effectuez les actions suivantes pour le pilote de filtre en question :
a. Configurez le pilote de filtre ou ses logiciels associés de telle sorte qu’il n’interfère pas avec la charge
SQL Server charge de travail ou les opérations.
b. Désactivez le chargement du pilote de filtre dans le système.
c. Contactez le fournisseur du pilote de filtre ou du logiciel d’application, recherchez les mises à jour et
appliquez-les.
d. Dans de rares cas, vous pouvez être dans l’devoir de supprimer le pilote de filtre et le logiciel associé
pour vous assurer que le système et SQL Server peuvent fonctionner sans les problèmes abordés
dans la section Symptômes.
WARNING
utilisateurs malveillants ou par des logiciels malveillants tels que des virus. Nous ne recommandons pas cette
solution de contournement, mais fournissons ces informations afin que vous pouvez implémenter cette solution
de contournement à votre propre discrétion. Son utilisation relève de votre responsabilité.
Dans certains cas, vous pouvez être dans l’devoir d’effectuer toutes ces actions. Reportez-vous à la section Plus
d’informations pour obtenir des instructions spécifiques à certains pilotes de filtre.
L’équipe du support technique et des services client (CSS) de Microsoft a identifié les pilotes de filtre suivants
qui peuvent provoquer les symptômes mentionnés dans cet article. Cette liste est mise à jour lorsque de
nouveaux problèmes sont trouvés. Cette liste est fournie pour faciliter le processus d’identification décrit dans la
section Résolution. La recherche du pilote de filtre problématique implique généralement la collecte d’un
ensemble itératif de données de diagnostic et de suivi lorsque le problème se produit.
Les pilotes de filtre suivants peuvent entraîner des problèmes de performances et de stabilité pour SQL Server :
MFEBOPK.SYS
Ce pilote de filtre est utilisé pour la fonctionnalité de protection de dépassement de mémoire tampon
dans Mc AntivirusScan Enterprise. Si cette fonctionnalité est activée, vous remarquerez que sqlservr.exe
figure dans la liste des processus protégés par la protection de dépassement de mémoire tampon. Si
vous avez ce pilote de filtre sur un système qui exécute SQL Server, vous devez effectuer les actions
spécifiées dans la section Résolution. Vous pouvez également consulter le lien suivant pour plus
d’informations :
Problème à fort impact : les serveurs peuvent ne plus être répondeurs en raison de plusieurs
problèmes
NLEMSQL64.SYS et NLEMSQL.SYS
Ce pilote de filtre est installé par le logiciel de chiffrement NetLib. Lorsque ce pilote de filtre est installé
sur un ordinateur exécutant SQL Server et que vous effectuez une sauvegarde sur un partage réseau,
vous pouvez rencontrer des échecs qui retournent l’erreur du système d’exploitation 1 : Fonction
incorrecte. Pour résoudre ce problème, contactez le fournisseur de logiciels pour obtenir les mises à jour
du pilote de filtre.
MFETDIK.SYS
Ce pilote de filtre est utilisé pour la fonctionnalité de Mini-Firewall antivirus Mc Antivirus dans les
produits Mc AntivirusScan Enterprise et Mc Antivirus McShield. Si cette fonctionnalité est activée, vous
remarquerez que sqlservr.exe figure dans la liste des processus surveillés par la fonctionnalité antivirus.
Si vous avez ce pilote de filtre sur un système qui exécute SQL Server, vous devez effectuer les actions
spécifiées dans la section Résolution. Vous pouvez également envisager d’ajouter SQL Server processus à
la liste des processus à faible risque dans la configuration antivirus.
Pour plus d’informations générales sur les pilotes de filtre, reportez-vous aux liens suivants :
Types de pilotes WDM
Comment désactiver temporairement le pilote de filtre en mode noyau dans Windows
produits.
Microsoft fournit des informations de contact de sociétés tierces afin de vous aider à obtenir un support
technique. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas
l'exactitude des informations concernant les sociétés tierces.
Les informations et la solution de ce document représentent l’affichage actuel de Microsoft Corporation sur ces
problèmes à la date de publication. Cette solution est disponible par le biais de Microsoft ou d’un fournisseur
tiers. Microsoft ne recommande pas spécifiquement un fournisseur tiers ou une solution tierce que cet article
pourrait décrire. Il peut également y avoir d’autres fournisseurs tiers ou solutions tierces que cet article ne décrit
pas. Étant donné que Microsoft doit répondre à l’évolution des conditions du marché, ces informations ne
doivent pas être interprétées comme un engagement de Microsoft. Microsoft ne peut pas garantir ou approuver
la précision des informations ou des solutions présentées par Microsoft ou par un fournisseur tiers mentionné.
Microsoft n’offre aucune garantie et exclut toutes les représentations, garanties et conditions, qu’elles soient
express, implicites ou statutaires. Celles-ci incluent, sans s’y limiter, les représentations, les garanties ou les
conditions de titre, de non-contrefaçon, de condition satisfaisante, de qualité et d’aptitude à un usage particulier,
en ce qui concerne tout service, solution, produit ou tout autre matériel ou information. En aucun cas Microsoft
ne sera responsable de toute solution tierce mentionné dans cet article.
Une utilisation élevée du processeur se produit
lorsque vous exécutez des requêtes dans SQL
Server
Cet article vous aide à résoudre le problème où l’utilisation élevée du processeur se produit lorsque vous
exécutez des requêtes dans SQL Server.
Symptômes
Lorsque vous exploitez un serveur qui exécute Microsoft SQL Server et qui a une charge de travail hautement
simultanée, vous remarquez certains problèmes de performances dans lesquels les requêtes contribuent
considérablement à une utilisation élevée du processeur ou à des demandes d’octroi de mémoire extrêmes.
Vous pouvez également faire face à d’autres effets secondaires, tels que les conditions OOM, la pression de la
mémoire pour planifier l’urgence du cache ou des RESOURCE_SEMAPHORE attentes inattendues.
En outre, vous remarquerez peut-être que les plans de requête pour les requêtes qui consomment beaucoup de
processeurs ou de mémoires ont l’attribut OPTIMIZED pour un opérateur de jointrie de boucles imbrique
définie sur True .
Cause
Ce problème se produit dans certains cas, car SQL Server processeur de requêtes introduit une opération de tri
pour l’optimisation, bien qu’elle ne soit pas requise. Cette opération est appelée « boucles imbrmbrées
optimisées » ou « tri par lots ».
Dans ce cas, le plan ne touche qu’un plus petit nombre de lignes et le coût d’installation de l’opération de tri peut
l’emporte sur ses avantages. Par conséquent, cela entraîne des performances médiocres.
Résolution
Pour résoudre le problème, utilisez l’indicateur de suivi 2340 pour désactiver l’optimisation. Sinon, pour
désactiver l’optimisation au niveau de la requête, appliquez l’indication de requête suivante :
USE HINT (DISABLE_OPTIMIZED_NESTED_LOOP)
Avant d’utiliser cet indicateur de suivi, vous pouvez tester minutieusement vos applications pour vous assurer
que vous bénéficiez des avantages attendus en terme de performances lorsque vous désactivez cette
optimisation. Cela est dû au fait que l’optimisation du tri peut être utile en cas d’augmentation importante du
nombre de lignes touchés par le plan.
Moteur de base de données Options de démarrage du service
S’applique à
SQL Server 2019
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2010
SQL Server 2008
SQL Server Web 2008
SQL Server 2008 Developer- SQL Server 2005
Le Moniteur de ressources entre une condition non
rapportant sur un serveur exécutant SQL Server
Cet article fournit plus d’informations sur le moniteur de ressources qui ne produit pas de résultats.
Symptômes
Sur un serveur exécutant Microsoft SQL Server 2008 ou une version ultérieure, la tâche De l’Observateur de
ressources enregistre le message suivant toutes les 5 secondes :
Date_And_Time Server Using 'dbghelp.dll' version '4.0.5'

Date_And_TimeServer **Dump thread - spid = 0, PSS = 0x0000000000000
000, EC = 0x0000000000000000
Date_And_TimeLogon Login succeeded for user 'OPENTEXT\sqlcrmusr'. Connection: trusted. [CLIENT:
IP_Address]
Date_And_Timespid78 Error: 4014, Severity: 20, State: 2.
Date_And_Timespid78 A fatal error occurred while reading the input stream from the network. The session will
be terminated.
Date_And_TimeServer ***Stack Dump being sent to Drive:\MSSQL2005\LOG\SQLDump####.txt
Date_And_TimeServer * *******************************************************************************
Date_And_TimeServer *
Date_And_TimeServer * BEGIN STACK DUMP:
Date_And_Timespid 0
Date_And_TimeServer * Non-yielding Resource Monitor
Date_And_TimeServer * *******************************************************************************
Date_And_TimeServer * -------------------------------------------------------------------------------
Date_And_TimeServer * Short Stack Dump
Date_And_TimeServer Stack Signature for the dump is 0x000000000000005C
Date_And_Time,Server,Unknown,Resource Monitor (0x9b0) Worker 0x0000000003A2C1C0 appears to be non-yielding
on
Node_#. Memory freed: 0 KB. Approx CPU Used: kernel 0 msnull user 0 msnull Interval:
Interval_value.
Cause
La tâche Moniteur de ressources s’est régulièrement chargée d’écouter les événements de mémoire classés
comme faibles, élevés ou réguliers. Le moniteur avertit les abonnés aux événements lorsque ces événements se
produisent.
Ces événements de mémoire peuvent être externes aux SQL Server. Les événements externes incluent des
notifications du système d’exploitation et sont à l’échelle du système. D’autres événements sont internes SQL
Server. Les événements internes incluent les notifications du pool de mémoires tampons et sont à l’échelle du
processus. Lorsque de telles notifications sont reçues, différents consommateurs de mémoire ont une utilisation
plus courte de la mémoire.
NOTE
Les consommateurs peuvent être des employés de mémoire qui sont des magasins de cache, des magasins d’utilisateurs
ou des magasins d’objets.
Si certains consommateurs de mémoire utilisent une grande quantité de mémoire, la préparation du tri que les
consommateurs effectuent peut prendre beaucoup de temps.
La tâche Scheduler Monitor s’exécute toutes les 5 secondes. Le moniteur de planification vérifie si le moniteur de
ressources est passé d’un consommateur à un autre au cours des 60 dernières secondes. Lorsque le Moniteur
de planification détecte que le Moniteur de ressources n’a pas été déplacé au-delà d’un consommateur pendant
60 secondes, le moniteur de planification interprète ce scénario comme le moniteur de ressources entrant dans
un état non-rendement. Cette interprétation amène le moniteur de planification à enregistrer le message
d’erreur mentionné dans la section Symptômes.
NOTE
À compter SQL Server 2019, l’intervalle de 60 secondes est augmenté jusqu’à 120 secondes. Cette augmentation réduit
la fréquence de ces notifications de diagnostic. Elle réduit également la génération des fichiers de vidage mémoire.
Ces messages sont également élevés si la vitesse à laquelle le Moniteur de ressources libère de la mémoire est
inférieure à 2 Mo toutes les 5 secondes.
Ces messages ne sont qu’une indication que le moniteur de ressources est occupé à nettoyer les grands
consommateurs. Ces messages n’indiquent pas nécessairement un problème avec le Moniteur de ressources
lui-même.
Résolution
À partir des Service Packs suivants, le message du Moniteur de ressources sans rendement s’étend pour isoler
facilement l’employé de la mémoire qui conduit à la condition non-rendement :
Service Pack 2 de Microsoft SQL Server 2008
Service Pack 1 de Microsoft SQL Server 2008 R2
Le nouveau message ressemblera à l’exemple suivant :
Resource Monitor (0x9b0) Worker 0x0000000003A2C1C0 appears to be non-yielding on Node Node_#. Memory
freed: 0 KB. Last wait: > lastwaittype. Last clerk: type clerk_type, name clerk_name. Approx CPU Used:
kernel 0 ms, user 0 ms, Interval: Interval_value.
Les descriptions des différents champs utilisés dans ce message sont les suivantes :
Mémoire libérée : Ce champ indique la quantité de mémoire libérée par le Moniteur de ressources
pour l’intervalle spécifié. Elle est mesurée en kilo-octets. Si la vitesse à laquelle la mémoire est libérée ne
dépasse pas 2 Mo toutes les 5 secondes, le moniteur du programme de planification détecte cette
condition comme une condition qui n’a pas de rendement.
Dernière attente : Ce champ est le dernier type d’attente pour le thread Moniteur de ressources. Vous
pouvez utiliser ce champ en combinaison avec le Approx CPU Used champ. Cette combinaison de champs
permet d’identifier si le thread Moniteur de ressources est en cours d’exécution ou en attente d’une partie
significative de l’intervalle.
Dernier employé : Ce champ est le type et le nom de l’employé de la mémoire qui a émissé sa mémoire
lorsque la condition de non-rendement s’est produite.
Utilisation approximative du processeur : Ce champ est le noyau et le temps utilisateur utilisés par
l’Observateur de ressources, tel que mesuré en millisecondes. Vous pouvez utiliser ce champ avec
d’autres champs pour vérifier que le moniteur de ressources progresse pendant l’intervalle spécifié.
Inter valle : Ce champ est le temps écoulé depuis que le dernier employé a été averti comme mesuré en
millisecondes.
Vous pouvez utiliser ce message pour identifier la source de la notification de mémoire faible. Vous pouvez
également utiliser les entrées RING_BUFFER_RESOURCE_MONITOR à partir de l’heure du message.
Ressources
Pour plus d’informations sur l’interprétation RING_BUFFER_RESOURCE MONITOR, consultez le billet de blog
techcommunity suivant :
Fonctionnement : quelles sont les RING_BUFFER_RESOURCE_MONITOR me le dire ?
La tâche Moniteur de ressources peut résoudre les problèmes de performances liés à la mémoire SQL Server.
SQL Server écoute et répond aux notifications de mémoire. Pour plus d’informations sur ces éléments, consultez
les articles de blog MSDN suivants :
Message SQL Server ensemble de travail
Résolution des problèmes de performances dans SQL Server 2008
L’hypothèse d’un contenu joint dans le New
Cardinality Estimateor dégrade les performances
des requêtes
Cet article vous aide à résoudre les problèmes de performances qui peuvent se produire dans SQL Server 2014
et versions ultérieures lorsque vous compilez vos requêtes à l’aide du nouvel estimateur de cardinalité.
Symptômes
Vous utilisez SQL Server 2014 ou une version ultérieure.
Vous exécutez une requête qui contient des prédicats de filtres joints et non joints.
Vous compilez la requête à l’aide de la nouvelle Estimation de la cardinalité (SQL Server) (Nouveau CE).
Dans ce scénario, vous faites face à une dégradation des performances des requêtes.
Ce problème ne se produit pas si vous compilez la requête à l’aide du ce hérité.
Résolution
Dans SQL Server 2014 et versions ultérieures, vous pouvez utiliser l’indicateur de suivi 9476 pour forcer le
Nouveau CE à utiliser l’hypothèse De contenu simple au lieu de l’hypothèse de contenu de base par défaut. (Voir
la section Plus d’informations.)
L’activation de cet indicateur de suivi peut améliorer le choix du plan de requête sans avoir à revenir
complètement au modèle CE hérité si les conditions suivantes sont vraies :
Vous pouvez faire l’expérience d’un choix de plan de requête sous-timal qui entraîne une dégradation globale
des performances pour les requêtes qui contiennent des jointeurs et des prédicats de filtre non joints.
Vous pouvez vérifier une imprécision significative dans une estimation de « cardinalité de jointure »
(autrement dit, le nombre réel ou estimé de lignes qui diffèrent considérablement).
Cette imprécision n’existe pas lorsque vous compilez des requêtes à l’aide du ce hérité.
Vous pouvez activer cet indicateur de suivi globalement, au niveau de la session ou au niveau de la requête.
NOTE
L’utilisation incorrecte des indicateurs de suivi peut dégrader les performances de votre charge de travail. Pour plus
d’informations, voir Hints (Transact-SQL) - Query.
Depuis SQL Server 2014, le New Cardinality Estimateor a été introduit pour le niveau de compatibilité de base
de données 120 et supérieur. Le nouveau ce modifie plusieurs hypothèses à partir du ce hérité dans le modèle
utilisé par l’optimiseur de requête lorsqu’il estime la cardinalité pour différents opérateurs et prédicats.
L’une de ces modifications est liée à l’hypothèse d’un contenu joint.
Le modèle CE hérité suppose que les utilisateurs interrogent toujours les données qui existent. Cela signifie que,
pour un prédicat de jointage qui implique une opération équijoin pour deux tables, les colonnes jointes existent
sur les deux côtés de la jointre. En présence de prédicats de filtres non joints supplémentaires par rapport à la
table de jointeurs, le ce hérité suppose un certain niveau de corrélation pour les prédicats de jointeurs et les
prédicats de filtre non joints. Cette corrélation implicite est appelée Contenu simple.
Sinon, le nouveau ce utilise le contenu de base comme corrélation. Le nouveau modèle CE suppose que les
utilisateurs peuvent interroger des données qui n’existent pas. Cela signifie que les prédicats de filtre sur des
tables distinctes peuvent ne pas être corrélés les uns avec les autres. Par conséquent, nous utilisons une
approche probabiliste.
Pour de nombreux scénarios pratiques, l’utilisation de l’hypothèse De base de contenu crée de meilleures
estimations. Cela permet, à son tour, de créer des choix de plan de requête plus efficaces. Toutefois, dans certains
cas, l’utilisation de l’hypothèse de l’utilisation de l’ment simple peut fournir de meilleurs résultats. Si cela se
produit, vous pouvez faire face à un choix de plan de requête moins efficace lorsque vous utilisez le Nouveau CE
au lieu du ce hérité.
Recommandations pour réduire la contention
d’allocation dans SQL Server base de données
tempdb
Cet article vous aide à résoudre le problème où vous remarquez un blocage grave lorsque le serveur rencontre
une charge importante.
Symptômes
Sur un serveur en cours d’Microsoft SQL Server, vous remarquez un blocage grave lorsque le serveur rencontre
une charge importante. Dynamic Management Views [ ou ] indique que ces demandes ou tâches sont en attente
sys.dm_exec_request sys.dm_os_waiting_tasks de ressources tempdb. En outre, le type d’attente PAGELATCH_UP
est , et la ressource d’attente pointe vers des pages dans tempdb . Ces pages peuvent être au format 2:1:1, 2:1:3,
et ainsi de suite (pages PFS et SGAM dans tempdb).
NOTE
Si une page est divisible par 8088, il s’agit d’une page PFS. Par exemple, la page 2:3:905856 est un pfs dans file_id=3 dans
tempdb .
Les opérations suivantes utilisent tempdb de manière intensive :

Opération répétitive de création et de dépose de tables temporaires (locales ou globales).
Tableau des variables qui utilisent tempdb pour le stockage.
Tables de travail associées aux CURSEurs.
Tables de travail associées à une clause ORDER BY.
Tables de travail associées à une clause GROUP BY.
Fichiers de travail associés à DES PLANS DE HACHAGE.
Ces activités peuvent entraîner des problèmes de contention.
Cause
Lorsque la base de données tempdb est très utilisée, SQL Server peut être en conflit lorsqu’elle tente
d’allouer des pages. Selon le degré de contention, les requêtes et les requêtes qui impliquent tempdb risquent
de ne pas répondre brièvement.
Lors de la création de l’objet, deux (2) pages doivent être allouées à partir d’une étendue mixte et affectées au
nouvel objet. Une page est pour la carte d’allocation d’index (IAM) et la seconde pour la première page de l’objet.
SQL Server suit les étendues mixtes à l’aide de la page SGAM (Shared Global Allocation Map). Chaque page
SGAM suit environ 4 gigaoctets de données.
Pour allouer une page à partir de l’étendue mixte, SQL Server doit analyser la page d’espace libre de page (PFS)
pour déterminer quelle page mixte est libre à allouer. La page PFS assure le suivi de l’espace disponible sur
chaque page, et chaque page PFS suit environ 8 000 pages. La synchronisation appropriée est conservée pour
apporter des modifications aux pages PFS et SGAM ; et qui peut bloquée d’autres modificateurs pendant de
courtes périodes.
Lorsque SQL Server recherche une page mixte à allouer, il démarre toujours l’analyse sur le même fichier et la
même page SGAM. Cela provoque un conflit intense sur la page SGAM lorsque plusieurs allocations de pages
mixtes sont en cours. Cela peut entraîner les problèmes documentés dans la section Symptômes.
NOTE
Les activités de dé allocation doivent également modifier les pages. Cela peut contribuer à augmenter la contention.
Pour en savoir plus sur les différents mécanismes d’allocation utilisés par SQL Server (SGAM, GAM, PFS, IAM),
consultez la section Références.
Résolution
SQL Server 2016 et versions ultérieures :
Révision
Optimisation des performances de base de données tempdb dans SQL Server.
TEMPDB : fichiers et indicateurs de suivi et mises à jour, Oh My!
Appliquez la mise à jour à jour SQL Server 2016 et 2017 pour tirer parti de la mise à jour suivante.
Une amélioration a été apportée afin de réduire davantage la contention dans SQL Server 2016 et
SQL Server 2017. En plus de l’allocation round robin sur tous les fichiers de données tempdb, le
correctif améliore l’allocation de page PFS en faisant des allocations round robin sur plusieurs
pages PFS dans le même fichier de données. Pour plus d’informations, voir KB4099472 -
Amélioration de l’algorithme de tour robin de page PFS dans SQL Server 2014, 2016 et 2017.
Pour plus d’informations sur ces recommandations et d’autres modifications introduites dans SQL 2016
SQL Server 2016 : il s’exécute simplement plus rapidement : modifications -T1117 et -T1118 pour
TEMPDB et les bases de données utilisateur
SQL Server 2016 - Il s’exécute simplement plus rapidement : configuration TEMPDB automatique
SQL Server 2014 et versions antérieures :
Pour améliorer la concurrence de tempdb, essayez les méthodes suivantes :
Augmentez le nombre de fichiers de données dans tempdb pour optimiser la bande passante du
disque et réduire la contention dans les structures d’allocation. En règle générale, si le nombre de
processeurs logiques est inférieur ou égal à huit (8), utilisez le même nombre de fichiers de
données que les processeurs logiques. Si le nombre de processeurs logiques est supérieur à huit
(8), utilisez huit fichiers de données. Si la contention persiste, augmentez le nombre de fichiers de
données par multiples de quatre (4) jusqu’au nombre de processeurs logiques jusqu’à ce que la
contention soit réduite à des niveaux acceptables. Vous pouvez également apporter des
modifications à la charge de travail ou au code.
Envisagez d’implémenter les recommandations des meilleures pratiques dans Working with
tempdb dans SQL Server 2005.
Si les étapes précédentes ne réduisent pas considérablement la contention d’allocation et que la
contention se trouve sur les pages SGAM, implémentez l’indicateur de suivi -T1118 . Sous cet
indicateur de suivi, SQL Server alloue des étendues complètes à chaque objet de base de données,
éliminant ainsi la contention sur les pages SGAM.
NOTE
Cet indicateur de suivi affecte chaque base de données sur l’instance de SQL Server. Pour plus
d’informations sur la façon de déterminer si la contention d’allocation se trouve sur les pages
SGAM, voir la contention de surveillance causée par les opérations DML.
Pour SQL Server environnements 2014, veillez à appliquer le Service Pack 3 pour tirer parti du
correctif documenté dans l’article de la Ko suivant. Cette amélioration réduit davantage la
contention dans SQL Server environnements 2014. En plus de l’allocation round robin sur tous les
fichiers de données tempdb, le correctif améliore l’allocation de page PFS en faisant des allocations
round robin sur plusieurs pages PFS dans le même fichier de données.
KB4099472 - Amélioration de l’algorithme de tour robin de page PFS SQL Server 2014, 2016 et
2017
Blog de l’équipe MSSQLQl : Fichiers et indicateurs de suivi et mises à jour dans SQL Server tempdb
Augmenter le nombre de fichiers de données tempdb dont le taille

est égal
Par exemple, si la taille du fichier de données unique tempdb est de 8 Go et que la taille du fichier journal est
de 2 Go, il est recommandé d’augmenter le nombre de fichiers de données à huit (8) (chacun d’entre eux de 1
Go pour maintenir un dimensionnement égal) et de laisser le fichier journal tel quelle. Le fait d’avoir les
différents fichiers de données sur des disques distincts serait plus avantageux en terme de performances.
Toutefois, cela n’est pas obligatoire. Les fichiers peuvent coexister sur le même volume de disque.
Le nombre optimal de fichiers de données tempdb dépend du degré de contention observé dans tempdb.
Comme point de départ, vous pouvez configurer tempdb pour qu’il soit au moins égal au nombre de
processeurs logiques affectés à SQL Server. Pour les systèmes de niveau supérieur, le nombre de départ peut
être huit (8). Si la contention n’est pas réduite, vous de devez peut-être augmenter le nombre de fichiers de
données.
Nous vous recommandons d’utiliser le même resserrage des fichiers de données. SQL Server 2000 Service Pack
4 (SP4) a introduit un correctif qui utilise un algorithme round robin pour les allocations de pages mixtes. En
raison de cette amélioration, le fichier de départ est différent pour chaque allocation de page mixte consécutive
(s’il existe plusieurs fichiers). Le nouvel algorithme d’allocation pour SGAM est un tourn round robin pur et
n’honore pas le remplissage proportionnel pour maintenir la vitesse. Nous vous recommandons de créer tous
les fichiers de données tempdb de la même taille.
Comment l’augmentation du nombre de fichiers de données tempdb

réduit la contention
La liste suivante explique comment l’augmentation du nombre de fichiers de données tempdb dont le taille est
égal réduit la contention :
Si vous avez un fichier de données pour tempdb, vous n’avez qu’une seule page GAM et une page
SGAM pour chaque espace de 4 Go.
L’augmentation du nombre de fichiers de données qui ont les mêmes tailles pour tempdb crée
effectivement une ou plusieurs pages GAM et SGAM pour chaque fichier de données.
L’algorithme d’allocation pour GAM alloue une étendue à la fois (huit pages contiguës) à partir du
nombre de fichiers en mode round robin tout en respectant le remplissage proportionnel. Par
conséquent, si vous avez 10 fichiers de même taille, la première allocation est de File1, la seconde de
File2, la troisième de File3, etc.
La contention de ressources de la page PFS est réduite, car huit pages à la fois sont marquées comme
COMPLÈTEs, car GAM alloue les pages.
Comment l’implémentation de l’indicateur de suivi -T1118 réduit la

contention
NOTE
Cette section s’applique uniquement SQL Server 2014 et versions antérieures.
La liste suivante explique comment l’utilisation de l’indicateur de suivi -T1118 réduit la contention :
-T1118 est un paramètre à l’échelle du serveur.
Incluez l’indicateur de suivi -T1118 dans les paramètres de démarrage de SQL Server afin que l’indicateur
de suivi reste en vigueur même après SQL Server recyclé.
-T1118 supprime presque toutes les allocations de page unique sur le serveur.
En désactivant la plupart des allocations de page unique, vous réduisez la contention sur la page SGAM.
Si -T1118 est allumé, presque toutes les nouvelles allocations sont réalisées à partir d’une page GAM (par
exemple, 2:1:2) qui alloue huit (8) pages (une étendue) à la fois à un objet plutôt qu’à une seule page à partir
d’une étendue pour les huit (8) premières pages d’un objet, sans l’indicateur de suivi.
Les pages IAM utilisent toujours les allocations de page unique de la page SGAM, même si -T1118 est
allumé. Toutefois, lorsqu’il est combiné avec le correctif 8.00.0702 et l’augmentation des fichiers de données
tempdb, l’effet net est une réduction de la contention sur la page SGAM. Pour les problèmes d’espace,
consultez la section suivante.
Inconvénients
L’inconvénient de l’utilisation de -T1118 est que vous pouvez constater une augmentation de la taille de la base
de données si les conditions suivantes sont vraies :
De nouveaux objets sont créés dans une base de données utilisateur.
Chacun des nouveaux objets occupe moins de 64 Ko de stockage.
Si ces conditions sont vraies, vous pouvez allouer 64 Ko (huit pages * 8 Ko = 64 Ko) pour un objet qui ne
nécessite que 8 Ko d’espace, ce qui vous permet de perdre 56 Ko de stockage. Toutefois, si le nouvel objet utilise
plus de 64 Ko (huit pages) au cours de sa durée de vie, l’indicateur de suivi n’a aucun inconvénient. Par
conséquent, dans le pire des cas, SQL Server peut allouer sept (7) pages supplémentaires lors de la première
allocation uniquement pour les nouveaux objets qui ne dépassent jamais une (1) page.
Références
Surveillance et dépannage tempDB : goulot d’étranglement d’allocation
Gestion de TempDB dans SQL Server : Configuration tempDB
SQL Server TempDB - Nombre de fichiers - La brute
SQL Server (2005 et 2008) Trace Flag 1118 (-T1118) Utilisation
Résoudre les problèmes de blocage causés par
l’escalade de verrouillage dans SQL Server
Résumé
L’escalade de verrouillage est le processus de conversion de nombreux verrous finaux (tels que les verrous de
ligne ou de page) en verrous de table. Microsoft SQL Server détermine dynamiquement quand faire une
escalade de verrouillage. Lorsqu’il prend cette décision, SQL Server tient compte du nombre de verrous qui sont
placés dans une analyse particulière, du nombre de verrous détenus par l’ensemble de la transaction et de la
mémoire utilisée pour les verrous dans le système dans son ensemble. En règle générale, SQL Server
comportement par défaut de l’utilisateur entraîne une escalade de verrouillage uniquement à ces moments où
cela améliorerait les performances ou lorsque vous devez réduire la mémoire de verrouillage système excessive
à un niveau plus raisonnable. Toutefois, certaines conceptions d’applications ou de requêtes peuvent déclencher
une escalade de verrouillage à un moment où cette action n’est pas souhaitable, et le verrouillage de table
remontée peut bloquer d’autres utilisateurs. Cet article explique comment déterminer si l’escalade de
verrouillage est à l’origine du blocage et comment gérer l’escalade de verrou indésirable.
Déterminer si l’escalade de verrouillage est à l’origine du blocage

L’escalade de verrouillage ne provoque pas la plupart des problèmes de blocage. Pour déterminer si une
escalade de verrouillage se produit au moment ou à proximité du moment où vous rencontrez des problèmes
de blocage, démarrez une session Événements étendus qui inclut lock_escalation l’événement. Si vous ne
voyez aucun événement, l’escalade de verrouillage n’a pas lieu sur votre serveur et les informations de cet
article ne s’appliquent lock_escalation pas à votre situation.
Si une escalade de verrouillage se produit, vérifiez que le verrouillage de table escalade bloque d’autres
utilisateurs.
Pour plus d’informations sur l’identification du bloqueur d’en-tête et de la ressource de verrouillage qui est
détenue par le bloqueur d’en-tête et qui bloque d’autres ID de processus serveur (SPID), voir INF :Comprendre et
résoudre les problèmes de blocage de SQL Server.
Si le verrou qui bloque d’autres utilisateurs est autre chose qu’un verrou TAB (niveau table) dont le mode de
verrouillage est S (partagé) ou X (exclusif), l’escalade de verrouillage n’est pas le problème. En particulier, si le
verrou TAB est un verrou intention (tel qu’un mode de verrouillage IS, IU ou IX), cela n’est pas dû à l’escalade de
verrouillage. Si vos problèmes de blocage ne sont pas causés par l’escalade de verrouillage, consultez l’INF :
Comprendre et résoudre SQL Server les étapes de résolution des problèmes de blocage.
Empêcher l’escalade de verrouillage

La méthode la plus simple et la plus sûre pour empêcher l’escalade des verrous consiste à réduire
l’encombrement des transactions et à réduire l’encombrement des requêtes coûteuses afin que les seuils
d’escalade de verrouillage ne soient pas dépassés. Il existe plusieurs méthodes pour atteindre cet objectif,
notamment les stratégies suivantes :
Décomposez les opérations par lots de grande taille en plusieurs opérations plus petites. Par exemple,
vous exécutez la requête suivante pour supprimer plus de 100 000 anciens enregistrements d’une table
d’audit, puis vous déterminez que la requête a provoqué une escalade de verrouillage qui a bloqué
d’autres utilisateurs :
DELETE FROM LogMessages WHERE LogDate < '20020102';
En supprimant ces enregistrements quelques centaines à la fois, vous pouvez réduire considérablement
le nombre de verrous qui s’accumulent par transaction. Cela permet d’éviter l’escalade de verrouillage.
Par exemple, vous exécutez la requête suivante :
DECLARE @done bit = 0;

WHILE (@done = 0)
BEGIN
DELETE TOP(1000) FROM LogMessages WHERE LogDate < '20020102';
IF @@rowcount < 1000 SET @done = 1;
END;
Réduisez l’encombrement de verrouillage de la requête en rendant la requête aussi efficace que possible.
Des analyses de grande taille ou de nombreuses recherche de signet peuvent augmenter le risque
d’escalade de verrouillage. En outre, elles augmentent le risque d’blocages et affectent négativement la
concurrence et les performances. Une fois que vous avez identifié que la requête à l’origine de l’escalade
de verrouillage, recherchez les opportunités de créer de nouveaux index ou d’ajouter des colonnes à un
index existant pour supprimer les analyses d’index ou de tableau et optimiser l’efficacité des recherches
d’index. Examinez le plan d’exécution et créez potentiellement de nouveaux index non exclusifs pour
améliorer les performances des requêtes. Pour plus d’informations, voir SQL Server Index Architecture
and Design Guide.
L’un des objectifs de cette optimisation est de faire en sorte que les requêtes d’index retournent le moins
de lignes possible pour réduire le coût des recherche de signets (optimisez la sélectivité de l’index pour la
requête). Si SQL Server qu’un opérateur logique de recherche de signet retournera de nombreuses
lignes, il peut utiliser une clause pour rechercher le PREFETCH signet. Si SQL Server est utilisé pour une
recherche de signet, il doit augmenter le niveau d’isolation de transaction d’une partie de la requête en «
lecture répétable » pour une partie de la PREFETCH requête. Cela signifie que ce qui peut ressembler à
une instruction à un niveau d’isolation « en lecture seule » peut acquérir plusieurs milliers de verrous de
clé (à la fois sur l’index en cluster et sur un SELECT index non verrouillé). Cela peut entraîner le
dépassement des seuils d’escalade de verrouillage par une telle requête. Ceci est particulièrement
important si vous constatez que le verrou réamorcer est un verrou de table partagé, bien qu’ils ne soient
pas fréquemment visibles au niveau d’isolation « en lecture seule » par défaut. Si une clause Bookmark
Lookup WITH est à l’origine de l’escalade, envisagez d’ajouter des colonnes à l’index non réservé qui
apparaît dans la recherche d’index, ou l’opérateur logique d’analyse d’index sous l’opérateur logique
Bookmark Lookup dans le plan de PREFETCH requête. Il peut être possible de créer un index de
couverture (un index qui inclut toutes les colonnes d’une table qui ont été utilisées dans la requête), ou au
moins un index qui couvre les colonnes qui ont été utilisées pour les critères de jointeur ou dans la clause
WHERE s’il n’est pas pratique d’inclure tout le texte dans la liste « sélectionner une colonne ».
Une jointation de boucle imbriée peut également utiliser, ce qui PREFETCH entraîne le même
comportement de verrouillage.
L’escalade de verrouillage ne peut pas se produire si un autre SPID détient actuellement un verrou de
table incompatible. L’escalade de verrouillage est toujours resserré jusqu’à un verrou de table et jamais à
un verrou de page. En outre, si une tentative d’escalade de verrouillage échoue parce qu’un autre SPID
contient un verrou TAB incompatible, la requête qui a tenté l’escalade ne bloque pas en attendant un
verrou TAB. Au lieu de cela, il continue d’acquérir des verrous à son niveau d’origine, plus granulaire
(ligne, clé ou page), en faisant régulièrement des tentatives d’escalade supplémentaires. Par conséquent,
une méthode pour empêcher l’escalade de verrouillage sur une table particulière consiste à acquérir et à
maintenir un verrou sur une autre connexion qui n’est pas compatible avec le type de verrouillage
escamorcer. Un verrou IX (intention exclusive) au niveau de la table ne verrouille pas les lignes ou les
pages, mais il n’est toujours pas compatible avec un verrou de tabulation S (partagé) ou X (exclusif). Par
exemple, supposons que vous devez exécuter un travail par lot qui modifie de nombreuses lignes dans la
table mytable et qui a provoqué le blocage en raison de l’escalade de verrouillage. Si ce travail se termine
toujours en moins d’une heure, vous pouvez créer un travail Transact-SQL qui contient le code suivant et
planifier le démarrage du nouveau travail quelques minutes avant l’heure de début du travail par lot :
BEGIN TRAN;
SELECT * FROM mytable (UPDLOCK, HOLDLOCK) WHERE 1 = 0;
WAITFOR DELAY '1:00:00';
COMMIT TRAN;
Cette requête acquiert et maintient un verrou IX sur montable pendant une heure. Cela empêche
l’escalade de verrouillage sur la table pendant cette période. Ce lot ne modifie aucune donnée ou ne
bloque pas les autres requêtes (sauf si l’autre requête force un verrouillage de table à l’aide de l’indicateur
TABLOCK ou si un administrateur a désactivé les verrous de page ou de ligne à l’aide de ALTER INDEX).
Éliminer l’escalade de verrouillage causée par un manque de capacité de recherche de ressources, un
terme de base de données relationnel utilisé pour décrire si une requête peut utiliser des index pour les
prédicats et les colonnes de jointage. Pour plus d’informations sur la sargabilité, voir Considérations sur
les requêtes du Guide de conception. Par exemple, une requête relativement simple qui ne semble pas
demander beaucoup de lignes( ou peut-être une seule ligne) peut encore finir par analyser une table/un
index entier. Cela peut se produire s’il existe une fonction ou un calcul dans le côté gauche d’une clause
WHERE. Les exemples de type sargabilité incluent les conversions de type de données implicites ou
explicites, la fonction système ISNULL(), une fonction définie par l’utilisateur avec la colonne transmise en
tant que paramètre ou un calcul sur la colonne, tel que ou WHERE CONVERT(INT, column1) = @a
WHERE Column1*Column2 = 5 . Dans ce cas, la requête ne peut pas rechercher l’index existant, même si elle
contient les colonnes appropriées, car toutes les valeurs de colonne doivent être récupérées en premier et
transmises à la fonction. Cela entraîne une analyse de l’intégralité de la table ou de l’index et entraîne
l’acquisition d’un grand nombre de verrous. Dans de telles circonstances, SQL Server atteindre le seuil
d’escalade du nombre de verrous. La solution consiste à éviter d’utiliser des fonctions par rapport aux
colonnes de la clause WHERE, garantissant ainsi des conditions sargables.
Désactiver l’escalade de verrouillage

Bien qu’il soit possible de désactiver l’escalade de verrouillage dans SQL Server, nous ne l’avons pas
recommandé. Utilisez plutôt les stratégies de prévention décrites dans la section Empêcher l’escalade de
verrouillage.
Niveau du tableau : Vous pouvez désactiver l’escalade de verrouillage au niveau de la table. Voir
ALTER TABLE ... SET (LOCK_ESCALATION = DISABLE) (en anglais). Pour déterminer la table à cibler, examinez le
tableau T-SQL requêtes. Si ce n’est pas possible, utilisez les événements étendus, activez l’événement
lock_escalation et examinez la object_id colonne. Vous pouvez également utiliser l’événement Lock:Escalation
et examiner la colonne à l’aide SQL ObjectID2 Profiler.
Niveau d’instance : Vous pouvez désactiver l’escalade de verrouillage en activant l’indicateur de suivi 1211
pour l’instance. Toutefois, cet indicateur de suivi désactive toute escalade de verrouillage globalement dans
l’instance de SQL Server. L’escalade de verrouillage a un rôle utile dans SQL Server en optimisant l’efficacité
des requêtes qui sont ralenties par la surcharge d’acquisition et de libération de plusieurs milliers de verrous.
L’escalade de verrouillage permet également de réduire la mémoire requise pour assurer le suivi des verrous.
La mémoire que vous SQL Server allouer dynamiquement aux structures de verrouillage est limitée. Par
conséquent, si vous désactivez l’escalade de verrouillage et que la mémoire de verrouillage devient
suffisamment grande, toute tentative d’allocation de verrous supplémentaires pour n’importe quelle requête
peut échouer et générer l’entrée d’erreur suivante :

Le SQL Server ne peut pas obtenir de ressource LOCK pour le moment. Réexécutez votre instruction lorsqu’il
y a moins d’utilisateurs actifs ou demandez à l’administrateur système de vérifier SQL Server configuration
du verrouillage et de la mémoire.
NOTE
Lorsqu’une erreur 1204 se produit, elle interrompt le traitement de l’instruction active et entraîne la récupération de la
transaction active. La restauration proprement dite peut bloquer les utilisateurs ou entraîner un temps de récupération de
base de données long si vous redémarrez SQL Server service.
Vous pouvez ajouter cet indicateur de suivi (-T1211) à l’aide Gestionnaire de configuration SQL Server. Vous
devez redémarrer le service SQL Server pour qu’un nouveau paramètre de démarrage prenne effet. Si vous
exécutez DBCC TRACEON (1211, -1) la requête, l’indicateur de suivi prend effet immédiatement.
Toutefois, si vous n’ajoutez pas le paramètre de démarrage -T1211, l’effet d’une commande est perdu lors du
redémarrage DBCC TRACEON SQL Server service. L’activement de l’indicateur de suivi empêche toute escalade de
verrouillage ultérieure, mais elle n’inverse pas les escalades de verrouillage qui se sont déjà produites dans une
transaction active.
Si vous utilisez un conseil de verrouillage, tel que ROWLOCK, cela modifie uniquement le plan de verrouillage
initial. Les conseils de verrouillage n’empêchent pas l’escalade de verrouillage.
Seuils d’escalade de verrouillage

L’escalade de verrouillage peut se produire dans l’une des conditions suivantes :
Le seuil de mémoire est atteint : un seuil de mémoire de 40 % de la mémoire de verrouillage est
atteint. Lorsque la mémoire de verrouillage dépasse 24 % du pool de mémoires tampons, une escalade
de verrouillage peut être déclenchée. La mémoire de verrouillage est limitée à 60 % du pool de mémoires
tampons visibles. Le seuil d’escalade de verrouillage est fixé à 40 % de la mémoire de verrouillage. Il s’agit
de 40 % de 60 % du pool de mémoires tampons ou de 24 %. Si la mémoire de verrouillage dépasse la
limite de 60 % (c’est beaucoup plus probable si l’escalade de verrouillage est désactivée), toutes les
tentatives d’allocation de verrous supplémentaires échouent et des erreurs sont 1204 générées.
Un seuil de verrouillage est atteint : une fois le seuil de mémoire vérifié, le nombre de verrous
acquis sur la table ou l’index actuel est évalué. Si ce nombre dépasse 5 000, une escalade de verrouillage
est déclenchée.
Pour comprendre quel seuil a été atteint, utilisez les événements étendus, activez l’événement lock_escalation et
examinez les colonnes escalated_lock_count et escalation_cause étendues. Vous pouvez également utiliser
l’événement Lock:Escalationet examiner la valeur, où « 0 - LOCK_THRESHOLD » indique que l’instruction a
dépassé le seuil de verrouillage et « 1 - MEMORY_THRESHOLD » indique que l’instruction a dépassé le seuil de
EventSubClass mémoire. Examinez également les IntegerData colonnes et IntegerData2 les colonnes.
Recommandations
Les méthodes abordées dans la section Empêcher l’escalade de verrouillage sont de meilleures options que la
désactivation de l’escalade au niveau de la table ou de l’instance. En outre, les méthodes préventives produisent
généralement de meilleures performances pour la requête que la désactivation de l’escalade de verrouillage.
Microsoft recommande d’activer cet indicateur de suivi uniquement pour atténuer les blocages graves causés
par l’escalade de verrouillage, tandis que d’autres options, telles que celles abordées dans cet article, sont en
cours d’examen.
Voir aussi
Comprendre et résoudre les problèmes SQL Server blocage
Résoudre les problèmes de requêtes lentes sur SQL Server
Résoudre la contention d’insertion de
PAGELATCH_EX page dans SQL Server
Cet article explique comment résoudre la contention d’insertion de PAGELATCH_EX page dans SQL Server.
Symptômes
Plusieurs scénarios sont envisageables :
Vous avez une colonne qui inclut des valeurs séquentielles, telles qu’une colonne Identity ou une colonne
DateTime, qui est insérée par le biais de la fonction Getdate().
Vous disposez d’un index en cluster dont la colonne séquentielle est une colonne de début.
NOTE
Le scénario le plus courant est une clé primaire en cluster sur une colonne Identity. Moins fréquemment, ce
problème peut être observé pour les index nonclustered.
Votre application fait fréquemment des opérations INSERT ou UPDATE sur la table.
Vous avez de nombreuses processeurs sur le système. En règle générale, le serveur dispose de 16
processeurs ou plus. Cela permet à plusieurs sessions d’exécuter simultanément les opérations INSERT
sur la même table.
Dans ce cas, vous pouvez voir une diminution des performances de votre application. Lorsque vous examinez
les types d’attente dans sys.dm_exec_requests, vous observez des attentes sur le type d’PAGELATCH_EX et de
nombreuses sessions en attente de ce type d’attente.
Un autre problème se produit si vous exécutez la requête de diagnostic suivante sur votre système :
select session_id, wait_type, wait_time, wait_resource from sys.dm_exec_requests where
session_id > 50 and wait_type = 'pagelatch_ex'
Dans ce cas, vous pouvez obtenir des résultats semblables à ce qui suit.
SESSIO N _ID WA IT _T Y P E WA IT _T IM E WA IT _RESO URC E
60 PAGELATCH_EX 100 5:1:4144
75 PAGELATCH_EX 123 5:1:4144
79 PAGELATCH_EX 401 5:1:4144
80 PAGELATCH_EX 253 5:1:4144
81 PAGELATCH_EX 312 5:1:4144

SESSIO N _ID WA IT _T Y P E WA IT _T IM E WA IT _RESO URC E
82 PAGELATCH_EX 355 5:1:4144
84 PAGELATCH_EX 312 5:1:4144
85 PAGELATCH_EX 338 5:1:4144
87 PAGELATCH_EX 405 5:1:4144
88 PAGELATCH_EX 111 5:1:4144
90 PAGELATCH_EX 38 5:1:4144
92 PAGELATCH_EX 115 5:1:4144
94 PAGELATCH_EX 49 5:1:4144
101 PAGELATCH_EX 301 5:1:4144
102 PAGELATCH_EX 45 5:1:4144
103 PAGELATCH_EX 515 5:1:4144
105 PAGELATCH_EX 39 5:1:4144
Vous remarquerez que plusieurs sessions attendent toutes la même ressource qui ressemble à ce qui suit :
database_id = 5, file_id = 1, base de données page_id = 4144
NOTE
Le database_id doit être une base de données utilisateur (le numéro d’ID est supérieur ou égal à 5 ). Si la database_id est
2, vous pouvez, à la place, être confronté au problème qui est abordé dans fichiers, indicateurs de suivi et mises à jour sur
TEMPDB.
Cause
PAGEL ATCH (verrou sur une page de données ou d’index) est un mécanisme de synchronisation de thread. Il
est utilisé pour synchroniser l’accès physique à court terme aux pages de base de données qui se trouvent dans
le cache de mémoire tampon.
PAGEL ATCH diffère d’un PAGETCHTCH . Cette dernière est utilisée pour synchroniser l’accès physique aux
pages lorsqu’elles sont lues ou écrites sur le disque.
Les latches de page sont courantes dans chaque système, car elles garantissent une protection physique des
pages. Un index en cluster ordonne les données par colonne de clé de début. Pour cette raison, lorsque vous
créez l’index sur une colonne séquentielle, toutes les nouvelles insertions de données se produisent sur la même
page à la fin de l’index jusqu’à ce que cette page soit remplie. Toutefois, en cas de charge élevée, les opérations
INSERT simultanées peuvent provoquer un conflit sur la dernière page de l’arborescence B. Cette contention
peut se produire sur des index en cluster et nonclustered. Cela est dû au fait que l’index nonclusté commande
les pages au niveau feuille par la clé de début. This issue is also known as last-page insert contention.
Pour plus d’informations, voir Diagnosing and Resolving Latch Contention on SQL Server.
Résolution
Pour résoudre ce conflit, la stratégie globale consiste à empêcher toutes les opérations INSERT simultanées
d’accéder à la même page de base de données. À la place, faites en sorte que chaque opération INSERT accède à
une page différente et augmente la concurrence. Par conséquent, l’une des méthodes suivantes qui organisent
les données par une colonne autre que la colonne séquentielle atteint cet objectif.
In SQL Server 2019, a new index option (OPTIMIZE_FOR_SEQUENTIAL_KEY) was added that can help resolve
this issue without using any of the following methods. Pour plus d’informations,
OPTIMIZE_FOR_SEQUENTIAL_KEY en arrière-plan.
Méthode 1
Faites de la colonne qui contient des valeurs séquentielles un index non exclusif, puis déplacez l’index en cluster
vers une autre colonne. Par exemple, pour une clé primaire sur une colonne d’identité, supprimez la clé primaire
en cluster, puis re-créez-la en tant que clé primaire non exclusive. Il s’agit de la méthode la plus simple à faire et
elle atteint directement l’objectif.
Par exemple, supposons que vous avez le tableau suivant qui a été défini à l’aide d’une clé primaire en cluster
sur une colonne Identity.
CREATE TABLE Customers

( CustomerID bigint identity(1,1) not null Primary Key CLUSTERED,
CustomerLastName varchar (32) not null,
CustomerFirstName varchar(32) not null )
Pour le modifier, vous pouvez supprimer l’index de clé primaire et le redéfinir.
ALTER TABLE Customers

DROP CONSTRAINT PK__Customer__A4AE64B98819CFF6
add constraint pk_Cust1
primary key NONCLUSTERED (CustomerID)
Méthode 2
Réordez la définition d’index en cluster de telle sorte que la colonne de début ne soit pas la colonne séquentielle.
Cela nécessite que l’index en cluster soit un index composite. Par exemple, dans une table client, vous pouvez
faire d’une colonne CustomerLastName la colonne de début, suivie de CustomerID . Nous vous
recommandons de tester minutieusement cette méthode pour vous assurer qu’elle répond aux exigences de
performances.

add constraint pk_Cust1
primary key clustered (CustomerLastName, CustomerID)
Méthode 3
Ajoutez une valeur de hachage non importante en tant que clé d’index de début. Cela répartira également les
insertions. Une valeur de hachage est générée en tant que module qui correspond au nombre de processeurs
sur le système. Par exemple, sur un système à 16 processeurs, vous pouvez utiliser un modo de 16. Cette
méthode répartit uniformément les opérations INSERT sur plusieurs pages de base de données.
( CustomerID bigint identity(1,1) not null,
go
ADD [HashValue] AS (CONVERT([tinyint], abs([CustomerID])%16)) PERSISTED NOT NULL
go
ADD CONSTRAINT pk_table1
PRIMARY KEY CLUSTERED (HashValue, CustomerID)
Méthode 4
Utilisez un GUID comme colonne de clé de début d’un index pour garantir la distribution uniforme des
insertions.
NOTE
Bien qu’elle atteigne cet objectif, nous ne recommandons pas cette méthode, car elle présente plusieurs défis, notamment
une clé d’index importante, des fractionnements fréquents de page, une densité de page faible, etc.
Méthode 5
Utilisez le partitionnement de table et une colonne calculée avec une valeur de hachage pour répartir les
opérations INSERT. Étant donné que cette méthode utilise le partitionnement de table, elle n’est utilisable que sur
Enterprise éditions de SQL Server.
NOTE
Vous pouvez utiliser des tables partitionées dans SQL Server 2016 SP1 Édition Standard. Pour plus d’informations, voir la
description de « Partitionnement de tableau et d’index » dans l’article Éditions et fonctionnalités SQL Server 2016.
Voici un exemple dans un système qui possède 16 processeurs.

( CustomerID bigint identity(1,1) not null,
go
ADD [HashID] AS CONVERT(tinyint, ABS(CustomerID % 16)) PERSISTED NOT NULL)
go
CREATE PARTITION FUNCTION pf_hash (tinyint) AS RANGE LEFT FOR VALUES (0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15)
GO
CREATE PARTITION SCHEME ps_hash AS PARTITION pf_hash ALL TO ([PRIMARY])
GO
DROP CONSTRAINT PK__Customer__A4AE64B98819CFF6
CREATE UNIQUE CLUSTERED INDEX CIX_Hash
ON Customers (CustomerID, HashID) ON ps_hash(HashID)
GO
Méthode 6
Vous pouvez également utiliser In-Memory OLTP en particulier si la contention de verrou est élevée. Cette
technologie élimine globalement la contention de verrou. Toutefois, vous devez reconçer et migrer les tableaux
spécifiques, où un conflit de verrous de page est observé, vers un tableau optimisé pour la mémoire. Vous
pouvez utiliser le conseiller d’optimisation de la mémoire et le rapport d’analyse des performances des
transactions pour déterminer si la migration est possible et l’effort impliqué pour la migration. Pour plus
d’informations sur la façon dont In-Memory OLTP élimine la contention d’verrous, téléchargez et examinez le
document dans OLTP en mémoire - Considérations courantessur les modèles de charge de travail et la
migration.
Références
PAGELATCH_EX d’attente et insertions importantes
De nombreux CMEMTHREAD attendent que de
nombreuses entrées du magasin SchemaMgr
existent dans SQL Server
Cet article vous aide à résoudre le problème de dégradation des performances dans SQL Server.
Version du produit d’origine : Microsoft SQL Server 2017 Windows, SQL Server 2014, SQL Server 2016, SQL
Server 2012
Symptômes
Vous pouvez faire face à une dégradation des performances SQL Server. Lorsque ce problème se produit, vous
observez la situation suivante :
Il existe des millions d’entrées du magasin SchemaMgr dans le cache mémoire. Vous pouvez voir les
informations en exécutant le script T-SQL suivant :
SELECT entries_count
FROM sys.dm_os_memory_cache_counters
where name = 'SchemaMgr Store'
Ce problème peut être accompagné d’une augmentation des attentes et du blocage des verrous, dans
lequel les verrous font référence CMEMTHREAD à un type de wait_resource COMPILE verrou. Vous pouvez
voir les informations en exécutant le script T-SQL suivant :
select * from sys.dm_exec_requests where wait_type = 'CMEMTHREAD'

select * from sys.dm_exec_requests where wait_resource like '%compile%'
Cause
Ce problème se produit lorsque le nombre de statistiques HOBT mises en cache atteint une limite interne.
Lorsque la limite est atteinte, le système tente de supprimer de manière agressive les entrées, ce qui provoque
une contention sur l’objet mémoire qui stocke les données.
Résolution
Pour résoudre ce problème, activez l’indicateur de suivi (TF) 8032.
Résoudre les problèmes de blocage causés par les
verrous de compilation
Cet article explique comment résoudre les problèmes de blocage causés par les verrous de compilation.
Résumé
Dans Microsoft SQL Server, une seule copie d’un plan de procédure stockée est généralement mise en cache à la
fois. L’application de cette opération nécessite la sérialisation de certaines parties du processus de compilation,
et cette synchronisation s’accomplit en partie à l’aide de verrous de compilation. Si de nombreuses connexions
exécutent simultanément la même procédure stockée et qu’un verrou de compilation doit être obtenu pour
cette procédure stockée chaque fois qu’elle s’exécute, les ID de session (SPID) peuvent commencer à se bloquer
mutuellement lorsqu’ils tentent d’obtenir un verrou de compilation exclusif sur l’objet.
Voici quelques caractéristiques classiques du blocage de compilation qui peuvent être observées dans la sortie
bloquante :
waittype pour les SPID de session bloqués et (généralement) bloquants est (exclusif) et a la forme , où
est l’ID d’objet de LCK_M_X waitresource la procédure OBJECT: dbid: object_id [[COMPILE]] object_id
stockée.
Les bloqueurs ont waittype la valeur NULL et l’état peut être exécuté. Les bloqueurs ont waittype
LCK_M_X un état de blocage (verrouillage exclusif).
Bien que la durée de l’incident de blocage puisse être longue, il n’existe aucun SPID unique qui bloque les
autres SPID pendant une longue période. Il existe un blocage de déploiement. Une fois la compilation
terminée, un autre SPID prend le rôle de bloqueur de têtes pendant plusieurs secondes ou moins, et ainsi
de suite.
Les informations suivantes sont extraites d’une capture instantanée sys.dm_exec_requests de ce type de blocage
:
session_id blocking_session_id wait_type wait_time waitresource ---------- ------------------- -----

---- --------- ----------------------------
221 29 LCK_M_X 2141 OBJECT: 6:834102
[[COMPILE]]
228 29 LCK_M_X 2235 OBJECT: 6:834102
[[COMPILE]]
29 214 LCK_M_X 3937 OBJECT: 6:834102
[[COMPILE]]
13 214 LCK_M_X 1094 OBJECT: 6:834102
[[COMPILE]]
68 214 LCK_M_X 1968 OBJECT: 6:834102
[[COMPILE]]
214 0 LCK_M_X 0 OBJECT: 6:834102
[[COMPILE]]
Dans la waitresource colonne (6:834102), 6 est l’ID de base de données et 834102 est l’ID d’objet. Cet ID d’objet
appartient à une procédure stockée, et non à une table.
La recompilation des procédures stockées est une explication des verrous de compilation sur une procédure ou
un déclencheur stocké. Dans ce cas, la solution consiste à réduire ou à éliminer les recompilateurs.
Scénarios supplémentaires qui entraînent la compilation des verrous

1. La procédure stockée est exécutée sans nom complet
L’utilisateur qui exécute la procédure stockée n’est pas le propriétaire de la procédure.
Le nom de la procédure stockée n’est pas complet avec le nom du propriétaire de l’objet.
Par exemple, si l’utilisateur dbo possède un objet et un autre utilisateur, exécute cette procédure stockée à
l’aide de la commande , la recherche de cache initiale par nom d’objet échoue, car l’objet n’est pas qualifié
par le dbo.mystoredproc Harry exec mystoredproc propriétaire. (Il n’est pas encore connu si une autre
procédure stockée nommée Harry.mystoredproc existe. Par conséquent, SQL Server ne peut pas être sûr
que le plan mis en cache soit le bon plan à exécuter.) SQL Server obtient ensuite un verrou de compilation
exclusif sur la procédure et effectue les préparations pour compiler la dbo.mystoredproc procédure. Cela
inclut la résolution du nom de l’objet en ID d’objet. Avant SQL Server compiler le plan, SQL Server utilise
cet ID d’objet pour effectuer une recherche plus précise du cache des procédures et peut localiser un plan
compilé précédemment, même sans qualification du propriétaire.
Si un plan existant est trouvé, SQL Server réutilise le plan mis en cache et ne compile pas réellement la
procédure stockée. Toutefois, l’absence de qualification du propriétaire force SQL Server à effectuer une
deuxième recherche de cache et à obtenir un verrou de compilation exclusif avant que le programme
détermine que le plan d’exécution mis en cache existant peut être réutilisé. L’obtention du verrou et
l’opération de recherche et d’autres opérations nécessaires pour atteindre ce point peuvent introduire un
délai pour les verrous de compilation qui entraîne le blocage. Cela est particulièrement vrai si de
nombreux utilisateurs qui ne sont pas le propriétaire de la procédure stockée en même temps exécutent
la procédure sans fournir son nom. Même si les SPID n’attendent pas les verrous de compilation, le
manque de qualification du propriétaire peut entraîner des retards dans l’exécution des procédures
stockées et entraîner une utilisation élevée du processeur.
La séquence d’événements suivante est enregistrée dans une session SQL Server événement étendu
lorsque ce problème se produit.
N O M DE L 'ÉVÉN EM EN T T EXT E
rpc_starting mystoredproc
sp_cache_miss mystoredproc
sql_batch_starting mystoredproc
sp_cache_hit mystoredproc
... ...
sp_cache_miss se produit lorsque la recherche dans le cache par nom échoue, mais qu’un plan mis en
cache correspondant a été trouvé dans le cache une fois que le nom d’objet ambigu a été résolu en ID
d’objet et qu’un événement s’est sp_cache_hit produit.
La solution à ce problème de verrouillage de compilation consiste à s’assurer que les références aux
procédures stockées sont qualifiées par le propriétaire. (Au lieu d’exec, mystoredproc utilisez exec
dbo.mystoredproc.) Bien que la qualification du propriétaire soit importante pour des raisons de
performances, vous n’avez pas besoin de qualifier le processus stocké avec le nom de la base de données
pour empêcher la recherche de cache supplémentaire.
Le blocage provoqué par des verrous de compilation peut être détecté à l’aide de méthodes de résolution
des problèmes de blocage standard.
2. La procédure stockée est précédée du préfixe sp_
Si le nom de votre procédure stockée commence par le préfixe et qu’il ne se trouve pas dans la base de
données maître, vous voyez sp_cache_miss avant que le cache ne soit atteint pour chaque exécution,
même si vous qualifiez la procédure stockée par le sp_ propriétaire. Cela est dû au fait que le préfixe
SQL Server que la procédure stockée est une procédure stockée dans le système et que les procédures
stockées dans le système ont des règles de résolution sp_ de noms différentes. (L’emplacement préféré
se trouve dans la base de données maître.) Les noms des procédures stockées créées par l’utilisateur ne
doivent pas commencer par sp_ .
3. La procédure stockée est invoquée à l’aide d’un cas différent (supérieur/inférieur)
Si une procédure qualifiée par le propriétaire est exécutée à l’aide d’un cas différent (supérieur ou
inférieur) du cas utilisé pour la créer, la procédure peut déclencher un événement CacheMiss ou
demander un verrou COMPILE. Finalement, la procédure utilise le plan mis en cache et n’est pas
recompilée. Toutefois, la demande de verrouillage COMPILE peut parfois provoquer une situation de
chaîne bloquante si de nombreux SPID tentent d’exécuter la même procédure en utilisant un cas différent
de celui utilisé pour la créer. Cela est vrai quel que soit l’ordre de tri ou le classement utilisé sur le serveur
ou sur la base de données. La raison de ce comportement est que l’algorithme utilisé pour rechercher la
procédure dans le cache est basé sur des valeurs de hachage (pour des raisons de performances) et que
les valeurs de hachage peuvent changer si le cas est différent.
La solution consiste à abandonner et à créer la procédure en utilisant le même cas que celui utilisé
lorsque l’application exécute la procédure. Vous pouvez également vous assurer que la procédure est
exécutée à partir de toutes les applications à l’aide de la bonne case (supérieure ou inférieure).
4. La procédure stockée est invoquée en tant qu’événement Language
Si vous essayez d’exécuter une procédure stockée en tant qu’événement de langue plutôt qu’en tant que
RPC, SQL Server doit l’interroger et la compiler, déterminer que la requête tente d’exécuter la procédure
particulière, puis essayer de trouver un plan dans le cache de cette procédure. Pour éviter cette situation
dans laquelle SQL Server doit effectuer une recherche et compiler l’événement de langue, assurez-vous
que la requête est envoyée à SQL en tant que RPC.
Pour plus d’informations, voir la section Procédures stockées système dans l’article Books Online
Creating a Stored Procedure .
Références
La commande OPEN SYMMETRIC KEY empêche la mise en cache du plan de requête
Résoudre les problèmes de requêtes lentes sur SQL
Server
Introduction
Cet article explique comment gérer un problème de performances que les applications peuvent faire face avec
des SQL Server : performances lentes d’une requête ou d’un groupe de requêtes spécifique. Si vous dépannagez
un problème de performances, mais que vous n’avez pas isolé le problème à une requête spécifique ou à un
petit groupe de requêtes dont les performances sont plus lentes que prévu, voir Surveiller et régler les
performances avant de continuer.
Cet article part du principe que vous avez utilisé l'298475 de l’article pour affiner l’étendue du problème et que
vous avez capturé un suivi du profileur SQL avec les événements et colonnes de données spécifiques qui sont
détaillés dans l’article 224587.
Le réglage des requêtes de base de données peut être une tâche multi-facettes. Les sections suivantes abordent
les éléments courants à examiner lorsque vous examinez les performances des requêtes.
Vérifier l’existence des index corrects

L’une des premières vérifications à effectuer lorsque vous rencontrez des temps d’exécution de requête lents est
une analyse d’index. Si vous examinez une seule requête, vous pouvez utiliser l’option Analyser la requête dans
Assistant Paramétrage du moteur de base de données dans SQL Analyseur de requêtes ; Si vous avez une trace
SQL profileur d’une charge de travail importante, vous pouvez utiliser la Assistant Paramétrage du moteur de
base de données. Les deux méthodes utilisent l’optimiseur SQL Server requête pour déterminer les index qui
seraient utiles pour les requêtes spécifiées. Il s’agit d’une méthode efficace pour déterminer si les index corrects
existent dans votre base de données.
Pour plus d’informations sur l’utilisation Assistant Paramétrage du moteur de base de données, consultez la
rubrique « Démarrer et utiliser Assistant Paramétrage du moteur de base de données » dans SQL Server Books
Online.
Si vous avez mis à niveau votre application à partir d’une version antérieure de SQL Server, différents index
peuvent être plus efficaces dans la nouvelle build SQL Server en raison des modifications apportées à
l’optimiseur et au moteur de stockage. Le Assistant Paramétrage du moteur de base de données vous permet de
déterminer si une modification de la stratégie d’indexation améliorerait les performances.
Supprimer tous les conseils de requête, de table et de jointrie

Les conseils remplacent l’optimisation des requêtes et peuvent empêcher l’optimiseur de requête de choisir le
plan d’exécution le plus rapide. En raison des modifications apportées à l’optimiseur, les indications qui ont
amélioré les performances dans les versions antérieures de SQL Server peuvent n’avoir aucun effet ou affecter
négativement les performances dans les builds SQL Server ultérieures. En outre, les conseils de jointation
peuvent entraîner une dégradation des performances pour les raisons suivantes :
Les conseils de jointrie empêchent une requête ad hoc d’être éligible pour la paramétisation automatique
et la mise en cache du plan de requête.
Lorsque vous utilisez un conseil de jointage, cela implique que vous souhaitez forcer l’ordre de jointage
pour toutes les tables de la requête, même si ces jointeurs n’utilisent pas explicitement un conseil.
Si la requête que vous analysez inclut des conseils, supprimez-les, puis réévaluez les performances.
Examiner le plan d’exécution

Une fois que vous avez confirmé que les index corrects existent et qu’aucun conseil ne limite la capacité de
l’optimiseur à générer un plan efficace, vous pouvez examiner le plan d’exécution des requêtes. Vous pouvez
utiliser l’une des méthodes suivantes pour afficher le plan d’exécution d’une requête :
SQL Profiler
Si vous avez capturé l’événement MISC: Execution Plan dans SQL Profiler, il se produira immédiatement
avant l’événement StmtCompleted pour la requête pour l’ID de processus système (SPID).
SQL Analyseur de requêtes : plan d’exposition graphique
Une fois la requête sélectionnée dans la fenêtre de requête, cliquez sur le menu Requête, puis sur Afficher
le plan d’exécution estimé.
NOTE
Si la procédure stockée ou le lot crée et référence des tables temporaires, vous devez utiliser une instruction SET
STATISTICS PROFILE ON ou créer explicitement les tables temporaires avant d’afficher le plan d’exécution.
SHOWPLAN_ALL et SHOWPLAN_TEXT
Pour recevoir une version texte du plan d’exécution estimé, vous pouvez utiliser les options SET
SHOWPLAN_ALL et SHOWPLAN_TEXT SET. Pour plus d’informations, consultez les rubriques SET
SHOWPL AN_ALL (T-SQL) et SET SHOWPL AN_TEXT (T-SQL) dans SQL Server Books Online.
NOTE
Si la procédure stockée ou le lot crée et référence des tables temporaires, vous devez utiliser l’option DÉFINIR LE
PROFIL STATISTIQUES SUR ou créer explicitement les tables temporaires avant d’afficher le plan d’exécution.
PROFIL STATISTIQUES
Lorsque vous affichez le plan d’exécution estimé, graphiquement ou à l’aide de SHOWPLAN, la requête
n’est pas exécutée. Par conséquent, si vous créez des tables temporaires dans un lot ou une procédure
stockée, vous ne pouvez pas afficher les plans d’exécution estimés, car les tables temporaires n’existeront
pas. LE PROFIL STATISTIQUES exécute d’abord la requête, puis affiche le plan d’exécution réel. Pour plus
d’informations, consultez la rubrique SET STATISTICS PROFILE (T-SQL) SQL Server Books Online.
Lorsqu’il s’exécute SQL Query Analyzer, il apparaît sous forme graphique sous l’onglet Plan d’exécution
dans le volet résultats.
Pour plus d’informations sur l’affichage du plan d’exécution estimé, voir la rubrique Afficher le plan d’exécution
estimé dans SQL Server Books Online.
Examiner la sortie Showplan

Showplan output provides much information about the execution plan that SQL Server is using for a particular
query. Voici quelques aspects de base du plan d’exécution que vous pouvez consulter pour déterminer si vous
utilisez le meilleur plan :
Utilisation correcte de l’index
La sortie showplan affiche chaque table impliquée dans la requête et le chemin d’accès utilisé pour
obtenir des données à partir de celle-ci. Avec showplan graphique, déplacez le pointeur sur un tableau
pour afficher les détails de chaque tableau. Si un index est en cours d’utilisation, vous voyez Index Seek ;
Si un index n’est pas utilisé, vous pouvez voir l’analyse de tableau pour un tas ou l’analyse d’index en
cluster pour une table qui possède un index en cluster. L’analyse de l’index en cluster indique que la table
est en cours d’analyse via l’index en cluster, et non que l’index en cluster est utilisé pour accéder
directement à des lignes individuelles.
Si vous déterminez qu’un index utile existe et qu’il n’est pas utilisé pour la requête, vous pouvez essayer
de forcer l’index à l’aide d’une indication d’index. Consultez la rubrique FROM (T-SQL) dans SQL
Server Books Online pour plus d’informations sur les conseils d’index.
Ordre de joints correct
La sortie showplan indique dans quel ordre les tables impliquées dans une requête sont jointes. Pour les
jointeurs de boucle imbrmbrées, le tableau supérieur qui est répertorié est le tableau externe et il doit
être le plus petit des deux tableaux. Pour les jointeurs de hachage, la table supérieure devient l’entrée de
build et doit également être la plus petite des deux tables. Toutefois, notez que l’ordre est moins critique,
car le processeur de requêtes peut inverser les entrées de build et de sonde au moment de l’utilisation s’il
trouve que l’optimiseur a pris une décision erronée. Vous pouvez déterminer quel tableau renvoie moins
de lignes en vérifiant les estimations du nombre de lignes dans la sortie showplan.
Si vous déterminez que la requête peut bénéficier d’un ordre de jointrie différent, vous pouvez essayer de
forcer l’ordre de jointrie avec un conseil de jointrie. Consultez la rubrique FROM (T-SQL) dans SQL
Server Books Online pour plus d’informations sur les conseils de joints.
NOTE
L’utilisation d’un conseil de jointage dans une requête de grande taille force implicitement l’ordre de jointage pour
les autres tables de la requête comme si FORCEPLAN elle avait été définie.
Correct Join Type

SQL Server utilise une boucle imbriée, un hachage et des jointeurs de fusion. Si une requête lente utilise
une technique de jointage par rapport à une autre, vous pouvez essayer de forcer un autre type de
jointage. Par exemple, si une requête utilise une jointrie de hachage, vous pouvez forcer une jointrie de
boucles imbrique à l’aide de l’indication de jointage LOOP. Consultez la rubrique « FROM (T-SQL) » dans
SQL Server Books Online pour plus d’informations sur les conseils de adhésion.
L’utilisation d’un conseil de jointage dans une requête de grande taille force implicitement le type de
jointage pour les autres tables de la requête comme si elle FORCEPLAN avait été définie.
Exécution parallèle
Si vous utilisez un ordinateur multiprocesseur, vous pouvez également déterminer si un plan parallèle est
en cours d’utilisation. Si le parallélisme est utilisé, vous voyez un événement PARALLELISM (Gather Flux).
Si une requête particulière est lente lorsqu’elle utilise un plan parallèle, vous pouvez essayer de forcer un
plan non parallèle à l’aide de l’indication OPTION (MAXDOP 1). Consultez la rubrique « SELECT (T-SQL) »
dans SQL Server Books Online pour plus d’informations.
Pour plus d’informations sur l’utilisation de la sortie du plan d’exécution Showplan, consultez les rubriques
suivantes dans SQL Server Books Online :
Enregistrer un plan d’exécution au format XML
Comparer et analyser les plans d’exécution
Référence des opérateurs logiques et physiques Showplan
Cau t i on
Étant donné que l’optimiseur de requête sélectionne généralement le meilleur plan d’exécution pour une
requête, Microsoft vous recommande d’utiliser des conseils de jointeur, des conseils de requête et des conseils
de table uniquement en dernier recours, et uniquement si vous êtes un administrateur de base de données
expérimenté.
Comprendre et résoudre les problèmes SQL Server
blocage
S’applique à : SQL Server (toutes les versions pris en charge), Azure SQL Managed Instance
Objectif
L’article décrit le blocage dans SQL Server et montre comment résoudre les problèmes de blocage.
Dans cet article, le terme connexion fait référence à une seule session connectée de la base de données. Chaque
connexion apparaît en tant qu’ID de session (SPID) ou session_id dans de nombreux DMV. Chacun de ces SPID
est souvent appelé processus, bien qu’il ne s’agit pas d’un contexte de processus distinct au sens habituel. Au
lieu de cela, chaque SPID se compose des ressources serveur et des structures de données nécessaires pour
répondre aux demandes d’une connexion unique à partir d’un client donné. Une seule application cliente peut
avoir une ou plusieurs connexions. Du point de vue de SQL Server, il n’existe aucune différence entre plusieurs
connexions à partir d’une seule application cliente sur un seul ordinateur client et plusieurs connexions à partir
de plusieurs applications clientes ou de plusieurs ordinateurs clients ; elles sont atomiques. Une connexion peut
en bloquer une autre, quel que soit le client source.
NOTE
Cet ar ticle est axé sur les instances SQL Ser ver, notamment Azure SQL managed instances. Pour plus
d’informations sur la résolution des problèmes de blocage dans Azure SQL Database, voir Comprendre et résoudre Azure
SQL Database problèmes de blocage.
Qu’est-ce qui bloque ?

Le blocage est une caractéristique inévitable et de par sa conception de tout système de gestion de base de
données relationnelle (SGBD) avec accès concurrency basé sur le verrouillage. Comme mentionné
précédemment, dans SQL Server, le blocage se produit lorsqu’une session maintient un verrou sur une
ressource spécifique et qu’une seconde spid tente d’acquérir un type de verrou en conflit sur la même ressource.
En règle générale, la période pendant laquelle le premier SPID verrouille la ressource est petite. Lorsque la
session propriétaire relâche le verrou, la deuxième connexion est alors libre d’acquérir son propre verrou sur la
ressource et de continuer le traitement. Le blocage comme décrit ici est un comportement normal et peut se
produire de nombreuses fois tout au long d’une journée sans effet perceptible sur les performances du système.
La durée et le contexte de transaction d’une requête déterminent la durée de la mise en place de ses verrous et,
par conséquent, leur impact sur les autres requêtes. Si la requête n’est pas exécutée dans une transaction (et
qu’aucun conseil de verrouillage n’est utilisé), les verrous des instructions SELECT sont uniquement placés sur
une ressource au moment de sa lecture, et non pendant la requête. Pour les instructions INSERT, UPDATE et
DELETE, les verrous sont maintenus pendant la requête, à la fois pour des raisons de cohérence des données et
pour permettre la suppression de la requête si nécessaire.
Pour les requêtes exécutées au sein d’une transaction, la durée pendant laquelle les verrous sont maintenus est
déterminée par le type de requête, le niveau d’isolation des transactions et l’utilisation ou non d’indications de
verrouillage dans la requête. Pour obtenir une description du verrouillage, des conseils de verrouillage et des
niveaux d’isolation des transactions, consultez les articles suivants :
Verrouillage dans le Moteur de base de données
Personnalisation du verrouillage et du système de version de ligne
Modes de verrouillage
Compatibilité des verrous
Niveaux d’isolation basés sur le système de version de ligne dans le Moteur de base de données
Transactions
Lorsque le verrouillage et le blocage persistent au point d’avoir un impact négatif sur les performances du
système, cela est dû à l’une des raisons suivantes :
Un SPID maintient les verrous sur un ensemble de ressources pendant une période prolongée avant de
les libérer. Ce type de blocage se résout lui-même au fil du temps, mais peut entraîner une dégradation
des performances.
Un SPID maintient les verrous sur un ensemble de ressources et ne les libère jamais. Ce type de blocage
ne se résout pas lui-même et empêche l’accès aux ressources affectées indéfiniment.
Dans le premier scénario, la situation peut être très fluide, car différents SPID bloquent différentes ressources au
fil du temps, créant ainsi une cible mobile. Ces situations sont difficiles à résoudre à l’aide SQL Server
Management Studio pour affiner le problème à des requêtes individuelles. En revanche, la deuxième situation
entraîne un état cohérent qui peut être plus facile à diagnostiquer.
Applications et blocage
Il peut y avoir une tendance à se concentrer sur le réglage côté serveur et les problèmes de plateforme en cas de
problème de blocage. Toutefois, l’attention portée uniquement à la base de données peut ne pas aboutir à une
résolution et peut entraîner une amélioration du temps et de l’énergie à l’examen de l’application cliente et des
requêtes qu’elle soumet. Quel que soit le niveau de visibilité que l’application expose concernant les appels de
base de données effectués, un problème de blocage nécessite néanmoins fréquemment l’inspection des
instructions SQL exactes envoyées par l’application et le comportement exact de l’application concernant
l’annulation des requêtes, la gestion des connexions, l’extraction de toutes les lignes de résultats, etc. Si l’outil de
développement n’autorise pas le contrôle explicite sur la gestion des connexions, l’annulation des requêtes, le
délai d’arrêt des requêtes, l’extraction des résultats, etc., les problèmes de blocage risquent de ne pas pouvoir
être résolus. Ce potentiel doit être examiné attentivement avant de sélectionner un outil de développement
d’applications pour SQL Server, en particulier pour les environnements OLTP sensibles aux performances.
Faites attention aux performances de la base de données pendant la phase de conception et de construction de
la base de données et de l’application. En particulier, la consommation des ressources, le niveau d’isolation et la
longueur du chemin de transaction doivent être évalués pour chaque requête. Chaque requête et transaction
doit être aussi légère que possible. Une bonne gestion des connexions doit être mise en place, sans cela,
l’application peut sembler acceptable avec un petit nombre d’utilisateurs, mais les performances peuvent se
dégrader sensiblement à mesure que le nombre d’utilisateurs augmente.
Avec une conception d’application et de requête appropriée, SQL Server est capable de prendre en charge des
milliers d’utilisateurs simultanés sur un seul serveur, avec peu de blocage.
Résoudre les problèmes de blocage

Quelle que soit la situation de blocage dans laquelle nous sommes, la méthodologie de résolution des
problèmes de verrouillage est la même. Ces séparations logiques déterminent le reste de la composition de cet
article. Le concept consiste à rechercher le bloqueur d’en-têtes et à identifier ce que fait cette requête et
pourquoi elle est bloquante. Une fois que la requête problématique est identifiée (autrement dit, ce qui
maintient les verrous pendant une période prolongée), l’étape suivante consiste à analyser et déterminer
pourquoi le blocage se produit. Une fois que nous avons compris pourquoi, nous pouvons apporter des
modifications en reconçant la requête et la transaction.
Étapes de résolution des problèmes :
1. Identifier la session de blocage principale (bloqueur d’en-tête)
2. Recherchez la requête et la transaction à l’origine du blocage (ce qui maintient les verrous pendant une
période prolongée)
3. Analyser/comprendre pourquoi le blocage prolongé se produit
4. Résoudre le problème de blocage en reconçant la requête et la transaction
Examinons maintenant comment identifier la session principale bloquante avec une capture de données
appropriée.
Collecter des informations bloquantes

Pour éviter de résoudre les problèmes de blocage, un administrateur de base de données peut utiliser des
scripts SQL qui surveillent en permanence l’état du verrouillage et du blocage sur SQL Server. Pour collecter ces
données, il existe deux méthodes complémentaires.
La première consiste à interroger des objets de gestion dynamique (DME) et à stocker les résultats à des fins de
comparaison au fil du temps. Certains objets référencés dans cet article sont des affichages de gestion
dynamique (DMV) et d’autres sont des fonctions de gestion dynamiques (DMF).
La seconde consiste à utiliser les événementsétendus (XEvents) ou SQL suivis de profileur pour capturer ce qui
est en cours d’exécution. Étant donné SQL suivi et SQL Server Profiler sont supprimés, ce guide de dépannage se
concentre sur XEvents.
Collecter des informations à partir de DMV

Le référencement des DMV pour résoudre les problèmes de blocage a pour objectif d’identifier le SPID (ID de
session) à la tête de la chaîne de blocage et de l’instruction SQL. Recherchez les SPID de victime qui sont
bloqués. Si un SPID est bloqué par un autre SPID, examinez le SPID propriétaire de la ressource (spid de
blocage). Ce spid de propriétaire est-il également bloqué ? Vous pouvez parcourir la chaîne pour trouver le
bloqueur d’en-têtes, puis examiner la raison pour laquelle il maintient son verrou.
Pour ce faire, utilisez l'une des méthodes suivantes :
Dans SQL Server Management Studio (SSMS) Explorateur d’objets, cliquez avec le bouton droit sur l’objet
serveur de niveau supérieur, développez Rapports, développez Rapports standard, puis sélectionnez
Activité – Toutes les transactions bloquantes. Ce rapport présente les transactions actuelles au début
d’une chaîne de blocage. Si vous développez la transaction, le rapport affiche les transactions bloquées
par la transaction d’en-tête. Ce rapport affiche également l’instruction Blocking SQL statement et la
Blocked SQL Statement .
Ouvrez l’Observateur d SSMS et reportez-vous à la colonne Blocage par. Pour plus d’informations sur
l’Observateur d’activités, voir ici.
Des méthodes basées sur des requêtes plus détaillées sont également disponibles à l’aide de DMV :
Les sp_who commandes et les commandes sont des commandes plus anciennes pour afficher toutes les
sp_who2 sessions en cours. La DMV sys.dm_exec_sessions renvoie plus de données dans un jeu de
résultats qui est plus facile à interroger et à filtrer. Vous trouverez au sys.dm_exec_sessions cœur d’autres
requêtes.
Si vous avez déjà identifié une session particulière, vous pouvez l’utiliser pour rechercher la dernière
instruction envoyée DBCC INPUTBUFFER(<session_id>) par une session. Des résultats similaires peuvent
être renvoyés avec la fonction de gestion dynamique (DMF), dans un jeu de résultats plus facile à
interroger et à filtrer, fournissant les session_id et les sys.dm_exec_input_buffer request_id. Par exemple,
pour renvoyer la requête la plus récente envoyée par session_id 66 et request_id 0 :
SELECT * FROM sys.dm_exec_input_buffer (66,0);
Reportez-vous sys.dm_exec_requests à la colonne et blocking_session_id référencez-la. Lorsque

blocking_session_id = 0, une session n’est pas bloquée. Alors que les listes ne répertorient que les
demandes en cours d’exécution, toute connexion (active ou sys.dm_exec_requests non) est répertoriée
dans sys.dm_exec_sessions . Créez cette jointrie commune entre sys.dm_exec_requests et dans la requête
sys.dm_exec_sessions suivante. Gardez à l’esprit qu’elle doit être renvoyée par , la requête doit être
exécutée activement avec sys.dm_exec_requests SQL Server.
Exécutez cet exemple de requête pour rechercher les requêtes en cours d’exécution et leur SQL actuelle de
texte par lot ou de texte de tampon d’entrée, à l’aide des DMV sys.dm_exec_sql_text ou
sys.dm_exec_input_buffer. Si les données renvoyées par la colonne sont NULL, la requête text
sys.dm_exec_sql_text n’est pas en cours d’exécution. Dans ce cas, la colonne de contient la dernière
chaîne de commande event_info transmise au moteur SQL sys.dm_exec_input_buffer commande. Cette
requête peut également être utilisée pour identifier les sessions qui bloquent d’autres sessions, y compris
une liste des sessions session_ids bloquées par session_id.
WITH cteBL (session_id, blocking_these) AS

(SELECT s.session_id, blocking_these = x.blocking_these FROM sys.dm_exec_sessions s
CROSS APPLY (SELECT isnull(convert(varchar(6), er.session_id),'') + ', '
FROM sys.dm_exec_requests as er
WHERE er.blocking_session_id = isnull(s.session_id ,0)
AND er.blocking_session_id <> 0
FOR XML PATH('') ) AS x (blocking_these)
)
SELECT s.session_id, blocked_by = r.blocking_session_id, bl.blocking_these
, batch_text = t.text, input_buffer = ib.event_info, *
FROM sys.dm_exec_sessions s
LEFT OUTER JOIN sys.dm_exec_requests r on r.session_id = s.session_id
INNER JOIN cteBL as bl on s.session_id = bl.session_id
OUTER APPLY sys.dm_exec_sql_text (r.sql_handle) t
OUTER APPLY sys.dm_exec_input_buffer(s.session_id, NULL) AS ib
WHERE blocking_these is not null or r.blocking_session_id > 0
ORDER BY len(bl.blocking_these) desc, r.blocking_session_id desc, r.session_id;
Exécutez cet exemple de requête plus élaboré, fourni par le Support Microsoft, pour identifier le responsable
d’une chaîne de blocage de sessions multiples, y compris le texte de requête des sessions impliquées dans
une chaîne de blocage.
WITH cteHead ( session_id,request_id,wait_type,wait_resource,last_wait_type,is_user_process,request_cpu_time
,request_logical_reads,request_reads,request_writes,wait_time,blocking_session_id,memory_usage
,session_cpu_time,session_reads,session_writes,session_logical_reads
,percent_complete,est_completion_time,request_start_time,request_status,command
,plan_handle,sql_handle,statement_start_offset,statement_end_offset,most_recent_sql_handle
,session_status,group_id,query_hash,query_plan_hash)
AS ( SELECT sess.session_id, req.request_id, LEFT (ISNULL (req.wait_type, ''), 50) AS 'wait_type'
, LEFT (ISNULL (req.wait_resource, ''), 40) AS 'wait_resource', LEFT (req.last_wait_type, 50) AS
'last_wait_type'
, sess.is_user_process, req.cpu_time AS 'request_cpu_time', req.logical_reads AS 'request_logical_reads'
, req.reads AS 'request_reads', req.writes AS 'request_writes', req.wait_time,
req.blocking_session_id,sess.memory_usage
, sess.cpu_time AS 'session_cpu_time', sess.reads AS 'session_reads', sess.writes AS 'session_writes',
sess.logical_reads AS 'session_logical_reads'
, CONVERT (decimal(5,2), req.percent_complete) AS 'percent_complete', req.estimated_completion_time AS
'est_completion_time'
, req.start_time AS 'request_start_time', LEFT (req.status, 15) AS 'request_status', req.command
, req.plan_handle, req.[sql_handle], req.statement_start_offset, req.statement_end_offset,
conn.most_recent_sql_handle
, LEFT (sess.status, 15) AS 'session_status', sess.group_id, req.query_hash, req.query_plan_hash
FROM sys.dm_exec_sessions AS sess
LEFT OUTER JOIN sys.dm_exec_requests AS req ON sess.session_id = req.session_id
LEFT OUTER JOIN sys.dm_exec_connections AS conn on conn.session_id = sess.session_id
)
, cteBlockingHierarchy (head_blocker_session_id, session_id, blocking_session_id, wait_type,
wait_duration_ms,
wait_resource, statement_start_offset, statement_end_offset, plan_handle, sql_handle,
most_recent_sql_handle, [Level])
AS ( SELECT head.session_id AS head_blocker_session_id, head.session_id AS session_id,
head.blocking_session_id
, head.wait_type, head.wait_time, head.wait_resource, head.statement_start_offset,
head.statement_end_offset
, head.plan_handle, head.sql_handle, head.most_recent_sql_handle, 0 AS [Level]
FROM cteHead AS head
WHERE (head.blocking_session_id IS NULL OR head.blocking_session_id = 0)
AND head.session_id IN (SELECT DISTINCT blocking_session_id FROM cteHead WHERE blocking_session_id != 0)
UNION ALL
SELECT h.head_blocker_session_id, blocked.session_id, blocked.blocking_session_id, blocked.wait_type,
blocked.wait_time, blocked.wait_resource, h.statement_start_offset, h.statement_end_offset,
h.plan_handle, h.sql_handle, h.most_recent_sql_handle, [Level] + 1
FROM cteHead AS blocked
INNER JOIN cteBlockingHierarchy AS h ON h.session_id = blocked.blocking_session_id and
h.session_id!=blocked.session_id --avoid infinite recursion for latch type of blocking
WHERE h.wait_type COLLATE Latin1_General_BIN NOT IN ('EXCHANGE', 'CXPACKET') or h.wait_type is null
)
SELECT bh.*, txt.text AS blocker_query_or_most_recent_query
FROM cteBlockingHierarchy AS bh
OUTER APPLY sys.dm_exec_sql_text (ISNULL ([sql_handle], most_recent_sql_handle)) AS txt;
Pour capturer les transactions de longue durée ou non prises en compte, utilisez un autre ensemble de dvd
pour afficher les transactions ouvertes en cours, notamment sys.dm_tran_database_transactions,
sys.dm_tran_session_transactions, sys.dm_exec_connectionset sys.dm_exec_sql_text . Plusieurs DMV sont
associés au suivi des transactions. Consultez d’autres DMV sur les transactions ici.
SELECT [s_tst].[session_id],
[database_name] = DB_NAME (s_tdt.database_id),
[s_tdt].[database_transaction_begin_time],
[sql_text] = [s_est].[text]
FROM sys.dm_tran_database_transactions [s_tdt]
INNER JOIN sys.dm_tran_session_transactions [s_tst] ON [s_tst].[transaction_id] = [s_tdt].[transaction_id]
INNER JOIN sys.dm_exec_connections [s_ec] ON [s_ec].[session_id] = [s_tst].[session_id]
CROSS APPLY sys.dm_exec_sql_text ([s_ec].[most_recent_sql_handle]) AS [s_est];
Référence sys.dm_os_waiting_tasks qui se trouve au niveau de la couche thread/task de SQL Server. Cela
renvoie des informations sur les SQL wait_type que la demande rencontre actuellement. Comme
sys.dm_exec_requests , seules les demandes actives sont renvoyées par sys.dm_os_waiting_tasks .
NOTE
Pour plus d’informations sur les types d’attente, y compris les statistiques d’attente agrégées au fil dutemps, consultez la
sys.dm_db_wait_stats .
Utilisez la sys.dm_tran_locks DMV pour obtenir des informations plus granulaires sur les verrous qui ont été
placés par les requêtes. Cette DMV peut renvoyer de grandes quantités de données sur une instance de SQL
Server production et est utile pour diagnostiquer les verrous actuellement détenus.
En raison de inner JOIN on , la requête suivante limite la sortie des demandes actuellement bloquées
uniquement, de leur statut d’attente et de sys.dm_os_waiting_tasks sys.dm_tran_locks leurs verrous :
SELECT table_name = schema_name(o.schema_id) + '.' + o.name

, wt.wait_duration_ms, wt.wait_type, wt.blocking_session_id, wt.resource_description
, tm.resource_type, tm.request_status, tm.request_mode, tm.request_session_id
FROM sys.dm_tran_locks AS tm
INNER JOIN sys.dm_os_waiting_tasks as wt ON tm.lock_owner_address = wt.resource_address
LEFT OUTER JOIN sys.partitions AS p on p.hobt_id = tm.resource_associated_entity_id
LEFT OUTER JOIN sys.objects o on o.object_id = p.object_id or tm.resource_associated_entity_id = o.object_id
WHERE resource_database_id = DB_ID()
AND object_name(p.object_id) = '<table_name>';
Avec les fichiers DMV, le stockage des résultats de la requête dans le temps fournira des points de données qui
vous permettront de passer en revue le blocage sur un intervalle de temps spécifié pour identifier les tendances
ou les blocages persistants. L’outil de recherche pour les CSS pour résoudre ces problèmes consiste à utiliser le
collecteur de données PSSDiag. Cet outil utilise les « statistiques SQL Server perf » pour collecter au fil du temps
des jeux de résultats à partir de DMV référencés ci-dessus. Comme cet outil évolue constamment, examinez la
dernière version publique de DiagManager sur GitHub.
Collecter des informations à partir d’événements étendus

Outre les informations ci-dessus, il est souvent nécessaire de capturer un suivi des activités sur le serveur pour
examiner minutieusement un problème de blocage dans SQL Server. Par exemple, si une session exécute
plusieurs instructions au sein d’une transaction, seule la dernière instruction envoyée sera représentée.
Toutefois, l’une des instructions précédentes peut être la raison pour laquelle les verrous sont toujours en cours
de blocage. Un suivi vous permet d’voir toutes les commandes exécutées par une session au sein de la
transaction en cours.
Il existe deux façons de capturer des suivis dans SQL Server ; Événements étendus (XEvents) et suivis du
profileur. Toutefois, SQL suivis à l’aide SQL Server Profiler sont supprimés. XEvents est la nouvelle plateforme de
suivi supérieure qui offre plus de souplesse et moins d’impact sur le système observé, et son interface est
intégrée dans SSMS.
Il existe des sessions d’événement étendu pré-réalisées prêtes à démarrer dans SSMS, répertoriées dans
l’Explorateur d’objets sous le menu pour XEvent Profiler. Pour plus d’informations, voir XEvent Profiler. Vous
pouvez également créer vos propres sessions d’événement étendu personnalisées dans SSMS, voir l’Assistant
Nouvelle session événements étendus. Pour résoudre les problèmes de blocage, nous allons généralement
capturer :
Erreurs de catégorie :
Attention :
Blocked_process_report**
Error_reported (administrateur de canal)
Exchange_spill
Execution_warning
**Pour configurer le seuil et la fréquence de création des rapports de processus bloqués, utilisez la commande
sp_configure pour configurer l’optionde seuil de processus bloqué, qui peut être définie en secondes. Par défaut,
aucun rapport de processus bloqué n’est produit.
Avertissements de catégorie :
Hash_warning
Missing_column_statistics
Missing_join_predicate
Sort_warning
Exécution de catégorie :
Rpc_completed
Rpc_starting
Sql_batch_completed
Sql_batch_starting
Verrouillage de catégorie
Lock_deadlock
Session de catégorie
Existing_connection
Connexion
Déconnecter
Identifier et résoudre les scénarios de blocage courants

En examinant les informations ci-dessus, vous pouvez déterminer la cause de la plupart des problèmes
bloquants. Le reste de cet article explique comment utiliser ces informations pour identifier et résoudre certains
scénarios de blocage courants. Cette discussion suppose que vous avez utilisé les scripts de blocage (référencés
précédemment) pour capturer des informations sur les SPID de blocage et que vous avez capturé l’activité de
l’application à l’aide d’une session XEvent.
Analyser les données bloquantes

Examinez la sortie des DMV et pour déterminer les têtes des sys.dm_exec_requests sys.dm_exec_sessions
chaînes de blocage, à blocking_these l’aide et session_id . Cela permet d’identifier clairement les
demandes bloquées et les demandes bloquantes. Recherchez plus en détail les sessions bloquées et
bloquantes. Existe-t-il une racine ou une racine commune à la chaîne de blocage ? Ils partagent
probablement une table commune et une ou plusieurs des sessions impliquées dans une chaîne de
blocage effectuent une opération d’écriture.
Examinez la sortie des DMV et recherchez des informations sur les SPID au début sys.dm_exec_requests
de la chaîne de sys.dm_exec_sessions blocage. Recherchez les colonnes suivantes :
sys.dm_exec_requests.status
Cette colonne indique l’état d’une demande particulière. En règle générale, un état de mise en attente
indique que le SPID a terminé l’exécution et attend que l’application envoie une autre requête ou un
autre lot. Un état d’exécution ou d’exécution indique que le SPID traite actuellement une requête. Le
tableau suivant fournit de brèves explications sur les différentes valeurs d’état.
ÉTAT SIGN IF IC AT IO N
Contexte Le SPID exécute une tâche en arrière-plan, telle que la

détection des blocages, l’enregistreur de journaux ou le
point de contrôle.
En train de s' Le SPID n’est pas en cours d’exécution. Cela indique

généralement que le SPID attend une commande de
l’application.
En cours d’exécution Le SPID est en cours d’exécution sur un programmeur.
Runnable Le SPID se trouve dans la file d’attente runnable d’un

programmeur et attend d’obtenir l’heure du
programmeur.
Suspendu Le SPID attend une ressource, telle qu’un verrou ou un

verrou.
sys.dm_exec_sessions.open_transaction_count
Cette colonne indique le nombre de transactions ouvertes dans cette session. Si cette valeur est
supérieure à 0, le SPID se trouve dans une transaction ouverte et peut détenir des verrous acquis
par n’importe quelle instruction au sein de la transaction.
sys.dm_exec_requests.open_transaction_count
De même, cette colonne indique le nombre de transactions ouvertes dans cette demande. Si cette
valeur est supérieure à 0, le SPID se trouve dans une transaction ouverte et peut détenir des
verrous acquis par n’importe quelle instruction au sein de la transaction.
sys.dm_exec_requests.wait_type , wait_time et last_wait_type
Si la valeur est NULL, la demande n’attend actuellement rien et la valeur indique le dernier
sys.dm_exec_requests.wait_type que la demande a last_wait_type wait_type rencontré. Pour
plus d’informations et une description des types d’attente les sys.dm_os_wait_stats plus courants,
voir sys.dm_os_wait_stats. La wait_time valeur peut être utilisée pour déterminer si la demande
progresse. Lorsqu’une requête sur la table renvoie une valeur dans la colonne inférieure à la
valeur d’une requête précédente de , cela indique que le verrou précédent a été acquis et libéré et
attend maintenant un nouveau verrou (en supposant qu’il n’a pas la valeur sys.dm_exec_requests
wait_time wait_time sys.dm_exec_requests wait_time zéro). Cela peut être vérifié en comparant
la sortie, qui affiche la ressource pour laquelle la demande wait_resource sys.dm_exec_requests
est en attente.
sys.dm_exec_requests.wait_resource Cette colonne indique la ressource qu’une demande bloquée
attend. Le tableau suivant répertorie wait_resource les formats courants et leur signification :
RESSO URC E F O RM AT EXEM P L E EXP L IC AT IO N
Tableau DatabaseID:ObjectID:Inde TAB: 5:261575970:1 Dans ce cas, l’ID de base

xID de données 5 est
l’exemple de base de
données pubs et
261575970 est la table de
titres et object_id 1
l’index en cluster.
RESSO URC E F O RM AT EXEM P L E EXP L IC AT IO N
Page DatabaseID:FileID:PageID PAGE : 5:1:104 Dans ce cas, l’ID de base

de données 5 est pubs,
l’ID de fichier 1 est le
fichier de données
principal et la page 104
est une page appartenant
à la table titles. Pour
identifier l’object_id à la
page, utilisez la fonction
de gestion dynamique
sys.dm_db_page_info, en
passant le DatabaseID,
FileId, PageId à partir du
wait_resource .
Clé DatabaseID:Hobt_id KEY: Dans ce cas, l’ID de base

(valeur de hachage pour 5:72057594044284928 de données 5 est Pubs,
la clé d’index) (3300a4f361aa) Hobt_ID
72057594044284928
correspond à index_id 2
pour object_id
261575970 (tableau
titres). Utilisez
sys.partitions
l’affichage catalogue pour
associer hobt_id
l’affichage à un
index_id particulier et
object_id . Il n’existe
aucun moyen d’annuler le
hachage de la clé d’index
sur une valeur de clé
spécifique.
Ligne DatabaseID:FileID:PageID: RID : 5:1:104:3 Dans ce cas, l’ID de base

Slot(row) de données 5 est pubs,
fichier de données
principal, la page 104 est
une page appartenant à
la table titres et
l’emplacement 3 indique
la position de la ligne sur
la page.
Compiler DatabaseID:FileID:PageID: RID : 5:1:104:3 Dans ce cas, l’ID de base

Slot(row) de données 5 est pubs,
fichier de données
principal, la page 104 est
une page appartenant à
la table titres et
l’emplacement 3 indique
la position de la ligne sur
la page.
sys.dm_tran_active_transactions Le sys.dm_tran_active_transactions DMV contient des données sur

les transactions ouvertes qui peuvent être jointes à d’autres DMV pour obtenir une image complète
des transactions en attente de validation ou de récupération. Utilisez la requête suivante pour
renvoyer des informations sur les transactions ouvertes, jointes à d’autres DMV, y compris
sys.dm_tran_session_transactions. Prenez en compte l’état actuel d’une transaction et d’autres
données de situation pour déterminer s’il peut s’agit d’une transaction_begin_time source de blocage.
SELECT tst.session_id, [database_name] = db_name(s.database_id)

, tat.transaction_begin_time
, transaction_duration_s = datediff(s, tat.transaction_begin_time, sysdatetime())
, transaction_type = CASE tat.transaction_type WHEN 1 THEN 'Read/write transaction'
WHEN 2 THEN 'Read-only transaction'
WHEN 3 THEN 'System transaction'
WHEN 4 THEN 'Distributed transaction' END
, input_buffer = ib.event_info, tat.transaction_uow
, transaction_state = CASE tat.transaction_state
WHEN 0 THEN 'The transaction has not been completely initialized yet.'
WHEN 1 THEN 'The transaction has been initialized but has not started.'
WHEN 2 THEN 'The transaction is active - has not been committed or rolled back.'
WHEN 3 THEN 'The transaction has ended. This is used for read-only transactions.'
WHEN 4 THEN 'The commit process has been initiated on the distributed transaction.'
WHEN 5 THEN 'The transaction is in a prepared state and waiting resolution.'
WHEN 6 THEN 'The transaction has been committed.'
WHEN 7 THEN 'The transaction is being rolled back.'
WHEN 8 THEN 'The transaction has been rolled back.' END
, transaction_name = tat.name, request_status = r.status
, tst.is_user_transaction, tst.is_local
, session_open_transaction_count = tst.open_transaction_count
, s.host_name, s.program_name, s.client_interface_name, s.login_name, s.is_user_process
FROM sys.dm_tran_active_transactions tat
INNER JOIN sys.dm_tran_session_transactions tst on tat.transaction_id = tst.transaction_id
INNER JOIN Sys.dm_exec_sessions s on s.session_id = tst.session_id
LEFT OUTER JOIN sys.dm_exec_requests r on r.session_id = s.session_id
CROSS APPLY sys.dm_exec_input_buffer(s.session_id, null) AS ib;
Autres colonnes
Les colonnes restantes sys.dm_exec_sessions et sys.dm_exec_request peuvent également fournir
des informations sur la racine d’un problème. Leur utilité varie en fonction des circonstances du
problème. Par exemple, vous pouvez déterminer si le problème se produit uniquement à partir de
certains clients ( ), sur certaines bibliothèques réseau ( ), lorsque le dernier lot envoyé par un SPID
était en hostname client_interface_name cours last_request_start_time sys.dm_exec_sessions
d’exécution, start_time pendant combien de temps une demande a été en cours d’exécution dans
sys.dm_exec_requests , etc.
Scénarios de blocage courants

Le tableau ci-dessous m’indique les symptômes courants à leurs causes probables.
Les colonnes , et les colonnes font référence aux informations renvoyées par sys.dm_exec_request , d’autres
colonnes peuvent wait_type open_transaction_count être status renvoyées par sys.dm_exec_sessions. Le «
Résout ? » indique si le blocage est résolu par lui-même ou si la session doit être mise à l’arrêt via la KILL
commande. Pour plus d’informations, voir KILL (Transact-SQL).
EST - C E Q UE
VO US RÉSO LVEZ A UT RES
SC ÉN A RIO WA IT _T Y P E O P EN _T RA N ÉTAT ? SY M P TÔ M ES
EST - C E Q UE
1 NON NULL >= 0 runnable Oui, à la fin de la Dans

requête. sys.dm_exec_sessions
, reads
cpu_time et/ou
les
memory_usage
colonnes
augmenteront
au fil du temps.
La durée de la
requête est
élevée une fois
terminée.
2 NULL >0 somn Non, mais SPID Un signal

peut être libéré. d’attention peut
s’être produit
dans la session
d’événement
étendu pour ce
SPID, indiquant
qu’un délai
d’délai ou une
annulation de
requête s’est
produit.
3 NULL >= 0 runnable Non. Ne sera pas Si

résolu tant que open_transaction
le client n’aura _count = 0 et
pas récupéré que le SPID
toutes les lignes maintient les
ou fermé la verrous alors que
connexion. SpiD le niveau
peut être libéré, d’isolation de
mais cela peut transaction est
prendre jusqu’à par défaut (READ
30 secondes. COMMITTED),
cela est une
cause probable.
4 Variables >= 0 runnable Non. Ne sera pas La colonne dans

résolu tant que le SPID à la tête
le client n’aura d’une chaîne de
pas annulé les blocage sera
requêtes ou identique à celle
fermé les de l’un des
connexions. Les hostname
SPID peuvent sys.dm_exec_sessions
être libérés, mais SPID qu’elle
peuvent prendre bloque.
jusqu’à 30
secondes.
EST - C E Q UE
5 NULL >0 rollback Oui. Un signal

d’attention peut
s’être produit
dans la session
Événements
étendus pour ce
SPID, indiquant
qu’un délai
d’issue de
requête ou
d’annulation s’est
produit, ou
simplement
qu’une
instruction de
annulation a été
émise.
6 NULL >0 somn Finalement. La

Lorsque last_request_start_time
Windows NT valeur en est
détermine que la beaucoup plus
session n’est plus élevée que
active, la sys.dm_exec_sessions
connexion est l’heure actuelle.
interrompue.
Scénarios de blocage détaillés

1. Blocage provoqué par une requête en cours d’exécution normale avec une durée d’exécution longue
Solution : la solution à ce type de problème de blocage consiste à rechercher des moyens d’optimiser la
requête. En fait, cette classe de problème de blocage peut simplement être un problème de performances
et vous obliger à le poursuivre en tant que tel. Pour plus d’informations sur le dépannage d’une requête à
exécution lente spécifique, voir Comment résoudre les requêtes lentes sur SQL Server. Pour plus
d’informations, voir Surveiller et régler les performances.
Les rapports intégrés à SSMS à partir du magasin de requêtes (introduits dans SQL Server 2016) sont
également un outil très recommandé et utile pour identifier les requêtes les plus coûteuses, les plans
d’exécution sous-estimés.
Si vous avez une requête de longue durée qui bloque d’autres utilisateurs et ne peut pas être optimisée,
envisagez de la déplacer d’un environnement OLTP vers un système de rapports dédié, ou utilisez des
groupes de disponibilité AlwaysOn pour synchroniser un réplica en lecture seule de la base de données.
NOTE
Le blocage pendant l’exécution de la requête peut être dû à une escalade de requête, un scénario dans le cas où
les verrous de ligne ou de page sont recalés en verrous de table. Microsoft SQL Server détermine dynamiquement
quand effectuer une escalade de verrouillage. Le moyen le plus simple et le plus sûr d’empêcher l’escalade de
verrouillage consiste à réduire l’encombrement des transactions et à réduire l’encombrement des requêtes
coûteuses afin que les seuils d’escalade de verrouillage ne soient pas dépassés. Pour plus d’informations sur la
détection et la prévention d’une escalade excessive des verrous, voir Résoudre le problème de blocage provoqué
par l’escalade de verrouillage.
2. Blocage provoqué par un SPID en cours d’arrêt avec une transaction noncommande
Ce type de blocage peut souvent être identifié par un SPID qui est en attente ou en attente d’une
commande, mais dont le niveau d’imbrmbrage de transaction ( , de ) est supérieur @@TRANCOUNT
open_transaction_count à sys.dm_exec_requests zéro. Cela peut se produire si l’application subit un délai
d’application ou émet une annulation sans également émettre le nombre requis d’instructions ROLLBACK
et/ou COMMIT. Lorsqu’un SPID reçoit un délai d’délai de requête ou une annulation, il met fin à la requête
et au lot actuels, mais ne annule pas ou ne validera pas automatiquement la transaction. L’application est
responsable de cette opération, SQL Server ne peut pas supposer qu’une transaction entière doit être
annulée en raison de l’annulation d’une seule requête. Le délai ou l’annulation de la requête apparaîtra en
tant qu’événement de signal ATTENTION pour le SPID dans la session d’événement étendu.
Pour démontrer une transaction explicite noncommande, émettre la requête suivante :
CREATE TABLE #test (col1 INT);

INSERT INTO #test SELECT 1;
BEGIN TRAN
UPDATE #test SET col1 = 2 where col1 = 1;
Ensuite, exécutez cette requête dans la même fenêtre :
SELECT @@TRANCOUNT;
ROLLBACK TRAN
DROP TABLE #test;
La sortie de la deuxième requête indique que le niveau d’imbriquement de transaction est un. Tous les
verrous acquis dans la transaction sont toujours détenus jusqu’à la fin de la transaction. Si des
applications ouvrent et valider explicitement des transactions, une communication ou une autre erreur
peut laisser la session et sa transaction dans un état ouvert.
Utilisez le script plus tôt dans cet article pour identifier les transactions actuellement
sys.dm_tran_active_transactions noncommandes dans l’instance.
Résolutions :
En outre, cette classe de problème de blocage peut également être un problème de performances
et vous oblige à la poursuivre en tant que telle. Si le temps d’exécution de la requête peut être
réduit, le délai d’exécution ou l’annulation de la requête ne se produit pas. Il est important que
l’application soit en mesure de gérer les scénarios de délai d’délai ou d’annulation s’ils surviennent,
mais vous pouvez également tirer parti de l’examen des performances de la requête.
Les applications doivent gérer correctement les niveaux d’imbriquement des transactions, sinon
elles peuvent provoquer un problème de blocage suite à l’annulation de la requête de cette
manière. Vous devez tenir compte des éléments suivants :
Dans le programme de traitement des erreurs de l’application cliente, exécutez la suite d’une
erreur, même si l’application cliente ne pense pas qu’une IF @@TRANCOUNT > 0 ROLLBACK TRAN
transaction est ouverte. La vérification des transactions ouvertes est requise, car une procédure
stockée appelée pendant le lot aurait pu démarrer une transaction à l’insu de l’application
cliente. Certaines conditions, telles que l’annulation de la requête, empêchent l’exécution de la
procédure au-delà de l’instruction en cours. Ainsi, même si la procédure possède une logique
pour vérifier et abandonner la transaction, ce code de annulation ne sera pas exécuté dans de
tels IF @@ERROR <> 0 cas.
Si le regroupement de connexions est utilisé dans une application qui ouvre la connexion et
exécute quelques requêtes avant de libérer la connexion au pool, telle qu’une application Web,
la désactivation temporaire de la mise en pool de connexions peut aider à résoudre le
problème jusqu’à ce que l’application cliente soit modifiée pour gérer les erreurs de manière
appropriée. En désactivant la mise en pool de connexions, le fait de libérer la connexion
entraîne une déconnexion physique de la connexion SQL Server, ce qui entraîne la désactivation
par le serveur de toutes les transactions ouvertes.
À utiliser pour la connexion ou dans les procédures stockées qui commencent des transactions
et ne sont pas nettoyées SET XACT_ABORT ON suite à une erreur. En cas d’erreur d’utilisation, ce
paramètre abandonne toutes les transactions ouvertes et retourne le contrôle au client. Pour
plus d’informations, voir SET XACT_ABORT (Transact-SQL).
NOTE
La connexion n’est pas réinitialisée tant qu’elle n’a pas été réutilisée à partir du pool de connexions, il est donc
possible qu’un utilisateur puisse ouvrir une transaction, puis libérer la connexion au pool de connexions, mais elle
risque de ne pas être réutilisée pendant plusieurs secondes, pendant laquelle la transaction reste ouverte. Si la
connexion n’est pas réutilisée, la transaction est abandonnée à l’arrêt de la connexion et supprimée du pool de
connexions. Par conséquent, il est optimal pour l’application cliente d’abandonner les transactions dans son
système de gestion des erreurs ou de l’utiliser pour éviter SET XACT_ABORT ON ce délai potentiel.
Cau t i on
Following SET XACT_ABORT ON , T-SQL statement following a statement that causes an error will not be
executed. Cela peut affecter le flux prévu du code existant.
3. Blocage provoqué par un SPID dont l’application cliente correspondante n’a pas récupéré toutes les lignes
de résultats jusqu’à la fin
Après l’envoi d’une requête au serveur, toutes les applications doivent immédiatement extraire toutes les
lignes de résultats jusqu’à la fin. Si une application n’récupère pas toutes les lignes de résultats, des
verrous peuvent être laissés sur les tables, bloquant ainsi d’autres utilisateurs. Si vous utilisez une
application qui envoie des instructions SQL de manière transparente au serveur, l’application doit extraire
toutes les lignes de résultats. Si ce n’est pas le cas (et si elle ne peut pas être configurée pour le faire),
vous risquez de ne pas pouvoir résoudre le problème de blocage. Pour éviter ce problème, vous pouvez
restreindre les applications à faible comportement à une base de données de rapports ou de prise de
décision, distincte de la base de données OLTP principale.
Résolution :
L’application doit être réécrite pour extraire toutes les lignes du résultat jusqu’à son achèvement. Cela
n’exclut pas l’utilisation de OFFSET et FETCH dans la clause ORDER BY d’une requête pour effectuer la
pagination côté serveur.
4. Blocage provoqué par un blocage de client/serveur distribué
Contrairement à un blocage classique, un blocage distribué n’est pas détectable à l’aide du gestionnaire
de verrouillage SGBD. Cela est dû au fait qu’une seule des ressources impliquées dans le blocage est SQL
Server verrou. L’autre côté du blocage se trouve au niveau de l’application cliente, sur lequel SQL Server
n’a aucun contrôle. Voici deux exemples de la façon dont cela peut se produire et des moyens possibles
par l’application de l’éviter.
R : Blocage distribué client/serveur avec un thread client unique
Si le client dispose de plusieurs connexions ouvertes et d’un thread d’exécution unique, le blocage
distribué suivant peut se produire. Pour des raisons de concision, le dbproc terme utilisé ici fait référence
à la structure de connexion client.
SPID1------blocked on lock------->SPID2
/\ (waiting to write results
| back to client)
| |
| | Server side
| ================================|==================================
| <-- single thread --> | Client side
| \/
dbproc1 <------------------- dbproc2
(waiting to fetch (effectively blocked on dbproc1, awaiting
next row) single thread of execution to run)
Dans le cas ci-dessus, un thread d’application client unique a deux connexions ouvertes. Il envoie de
manière asynchrone une opération SQL sur dbproc1. Cela signifie qu’il n’attend pas le retour de l’appel
avant de poursuivre. L’application envoie ensuite une autre SQL sur dbproc2 et attend les résultats pour
commencer à traiter les données renvoyées. Lorsque les données commencent à revenir (selon le dbproc
qui répond d’abord , supposons qu’il s’agit de dbproc1), elle traite pour terminer toutes les données
renvoyées sur ce dbproc. Il récupère les résultats de dbproc1 jusqu’à ce que SPID1 soit bloqué sur un
verrou détenu par SPID2 (car les deux requêtes s’exécutent de manière asynchrone sur le serveur). À ce
stade, dbproc1 attend indéfiniment plus de données. SPID2 n’est pas bloqué sur un verrou, mais tente
d’envoyer des données à son client, dbproc2. Toutefois, dbproc2 est effectivement bloqué sur dbproc1 au
niveau de la couche d’application, car le thread unique d’exécution de l’application est utilisé par dbproc1.
Cela entraîne un blocage qui ne peut SQL Server détecter ou résoudre, car une seule des ressources
impliquées est SQL Server ressource.
B. Blocage distribué client/serveur avec un thread par connexion
Même s’il existe un thread distinct pour chaque connexion sur le client, une variante de ce blocage
distribué peut toujours se produire comme indiqué ci-après.
SPID1------blocked on lock-------->SPID2
/\ (waiting on net write) Server side
| |
| |
| INSERT |SELECT
| ================================|==================================
| <-- thread per dbproc --> | Client side
| \/
dbproc1 <-----data row------- dbproc2
(waiting on (blocked on dbproc1, waiting for it
insert) to read the row from its buffer)
Ce cas est similaire à l’exemple A, sauf que dbproc2 et SPID2 exécutent une instruction avec l’intention
d’effectuer un traitement de ligne à la fois et de remettre chaque ligne à travers une mémoire tampon à
dbproc1 pour un , ou instruction sur le même SELECT INSERT UPDATE DELETE tableau. Finalement,
SPID1 (en cours d’effectuer le , ou ) devient bloqué sur un verrou détenu par INSERT UPDATE DELETE
SPID2 (en cours d’effectuer SELECT le ). SPID2 écrit une ligne de résultat dans le client dbproc2. Dbproc2
tente ensuite de transmettre la ligne dans une mémoire tampon à dbproc1, mais trouve que dbproc1 est
occupé (il est bloqué en attente sur SPID1 pour terminer le courant , qui est bloqué sur INSERT SPID2). À
ce stade, dbproc2 est bloqué au niveau de la couche d’application par dbproc1 dont spid (SPID1) est
bloqué au niveau de la base de données par SPID2. Là encore, cela entraîne un blocage qui ne peut SQL
Server détecter ou résoudre, car une seule des ressources impliquées est SQL Server ressource.
Les exemples A et B sont des problèmes fondamentaux que les développeurs d’applications doivent
connaître. Ils doivent coder les applications pour gérer ces cas de manière appropriée.
Résolutions :
Lorsqu’un délai d’délai d’une requête est fourni, si le blocage distribué se produit, il est rompu lorsqu’il
arrive. Pour plus d’informations sur l’utilisation d’un délai d’accès à une requête, référencez la
documentation de votre fournisseur de connexions.
5. Blocage provoqué par une session dans un état de récupération
Une requête de modification de données qui est ENLISÉ, ou annulée en dehors d’une transaction définie
par l’utilisateur, sera annulée. Cela peut également se produire en tant que conséquence secondaire de la
déconnexion de la session réseau client, ou lorsqu’une demande est sélectionnée en tant que victime du
blocage. Cela peut souvent être identifié en observant la sortie de , qui peut indiquer la ROLLBACK , et la
colonne sys.dm_exec_requests command peut afficher la percent_complete progression.
Une requête de modification de données qui est ENLISÉ, ou annulée en dehors d’une transaction définie
par l’utilisateur, sera annulée. Cela peut également se produire en tant que conséquence secondaire du
redémarrage de l’ordinateur client et de la déconnexion de sa session réseau. De même, une requête
sélectionnée en tant que victime du blocage sera revenir en arrière. Une requête de modification de
données ne peut souvent pas être revenir en arrière plus rapidement que les modifications initialement
appliquées. Par exemple, si une instruction ou une instruction a été en cours d’exécution pendant une
heure, la mise à jour peut prendre au moins DELETE INSERT une UPDATE heure. Il s’agit d’un
comportement attendu, car les modifications apportées doivent être recalées, sinon l’intégrité
transactionnelle et physique de la base de données serait compromise. Dans la mesure où cela doit se
produire, SQL Server le SPID est dans un état de récupération ou d’or (ce qui signifie qu’il ne peut pas
être sélectionné en tant que victime d’un blocage). Cela peut souvent être identifié en observant la sortie
sp_who de , qui peut indiquer la commande ROLLBACK. La status colonne de sys.dm_exec_sessions
indiquera un état ROLLBACK.
NOTE
Les restaurations longues sont rares lorsque la fonctionnalité récupération accélérée de base de données est
activée. Cette fonctionnalité a été introduite dans SQL Server 2019.
Résolution :
Vous devez attendre la fin de la session pour récupérer les modifications qui ont été apportées.
Si l’instance est fermée au milieu de cette opération, la base de données sera en mode de récupération au
redémarrage et inaccessible tant que toutes les transactions ouvertes n’auront pas été traitées. La
récupération de démarrage prend essentiellement la même durée par transaction que la récupération au
moment de l’utilisation, et la base de données est inaccessible pendant cette période. Par conséquent, le
fait de forcer le serveur à réparer un SPID dans un état de récupération est souvent contre-productif.
Dans SQL Server 2019 avec la récupération de base de données accélérée activée, cela ne doit pas se
produire.
Pour éviter cette situation, n’effectuez pas d’opérations d’écriture par lot importantes, ni d’opérations de
création d’index ou de maintenance pendant les heures de pointe sur les systèmes OLTP. Si possible,
effectuez ces opérations pendant les périodes de faible activité.
6. Blocage provoqué par une connexion orpheline
Il s’agit d’un scénario de problème courant. Si l’application cliente s’arrête ou si la station de travail cliente
est redémarré ou si une erreur d’abandon par lots se trouve, la session réseau sur le serveur risque de ne
pas être immédiatement annulée dans certaines conditions. Cela peut se produire si l’application ne
retent pas la transaction dans les blocs CATCH ou FINALLY de l’application.
Dans ce scénario, alors que l’exécution d’un lot SQL a été annulée, la connexion SQL et la transaction
restent ouvertes par l’application. Du point SQL Server du point de vue de l’instance, le client semble
toujours être présent et les verrous acquis peuvent toujours être conservés.
Résolution :
La meilleure façon d’éviter cette condition consiste à améliorer la gestion des erreurs d’application, en
particulier pour les arrêts inattendus. Envisagez également l’utilisation de la connexion, ou dans toutes les
procédures stockées qui commencent des transactions et ne sont pas nettoyées suite SET XACT_ABORT ON
à une erreur. En cas d’erreur d’utilisation, ce paramètre abandonne toutes les transactions ouvertes et
retourne le contrôle au client. Pour plus d’informations, voir SET XACT_ABORT (Transact-SQL).
Pour résoudre une connexion orpheline d’une application cliente qui s’est déconnectée sans nettoyer
correctement ses ressources, vous pouvez mettre fin au SPID à l’aide de la KILL commande. Pour
référence, voir KILL (Transact-SQL).
La KILL commande prend la valeur SPID comme entrée. Par exemple, pour mettre fin à SPID 9, vous
pouvez émettre la commande suivante :
KILL 99
NOTE
La KILL commande peut prendre jusqu’à 30 secondes, en raison de l’intervalle entre les vérifications de la KILL
commande.
Voir aussi
Surveillance des performances à l’aide du magasin de requêtes
Résoudre les problèmes de blocage causés par l’escalade de verrouillage dans SQL Server
Guide du verrouillage des transactions et du système de version des lignes
DÉFINIR LE NIVEAU D’ISOLATION DES TRANSACTIONS
Démarrage rapide : événements étendus dans SQL Server
Mises à jour recommandées et options de
configuration pour SQL Server avec des charges de
travail hautes performances
Cet article inclut une liste des améliorations des performances et des options de configuration disponibles pour
SQL Server 2012 et versions ultérieures.
Appliquer les mises à jour recommandées et améliorer les

performances de SQL Server 2014 et SQL Server 2012
Cet article décrit les améliorations et modifications de performances disponibles pour les versions SQL Server
2014 et SQL Server 2012 par le biais de différentes mises à jour de produits et options de configuration. Vous
pouvez envisager d’appliquer ces mises à jour afin d’améliorer les performances de l’instance de SQL Server. Le
degré d’amélioration que vous voyez dépend de différents facteurs, notamment le modèle de charge de travail,
les points de contention, la disposition du processeur (nombre de groupes de processeurs, sockets, nœuds
NUMA, cœurs dans un nœud NUMA) et la quantité de mémoire présente dans le système. SQL Server équipe
de support technique a utilisé ces mises à jour et modifications de configuration pour obtenir des gains de
performances raisonnables pour les charges de travail des clients qui utilisaient des systèmes matériels qui
avaient plusieurs nodes NUMA et beaucoup de processeurs. L’équipe de support technique continuera à mettre
à jour cet article avec d’autres mises à jour à l’avenir.
Systèmes haut de gamme Un système haut de gamme possède généralement plusieurs sockets, huit cœurs ou
plus par socket, et un demi-octet ou plus de mémoire.
NOTE
Dans SQL Server 2016 et versions ultérieures, la plupart des indicateurs de suivi mentionnés dans cet article sont le
comportement par défaut et vous n’avez pas besoin de les activer dans ces versions.
Les recommandations sont regroupées dans trois tableaux comme suit :

Le tableau 1 contient les mises à jour et indicateurs de suivi les plus fréquemment recommandés pour
l’évolutivité sur les systèmes haut de gamme.
Le tableau 2 contient des recommandations et des conseils pour un réglage des performances
supplémentaire.
Le tableau 3 contient des correctifs d’évolutivité supplémentaires qui ont été inclus avec une mise à jour
cumulative.
Tableau 1. Mises à jour importantes et indicateurs de suivi pour les

systèmes haut de gamme
Examinez le tableau suivant et activez les indicateurs de suivi dans la colonne d’indicateur de suivi une fois que
vous vous êtes assuré que votre instance de SQL Server répond aux exigences de la colonne Version applicable
et plages de build.
NOTE
La version et la build applicables indiquent la mise à jour spécifique dans laquelle l’indicateur de modification ou de
suivi a été introduit. Si aucune cu cu n’est spécifiée, toutes les cu sont incluses dans le SP.
La version et la build non applicables indiquent la mise à jour spécifique dans laquelle l’indicateur de modification
ou de suivi est devenu le comportement par défaut. Par conséquent, le simple fait d’appliquer cette mise à jour
sera suffisant pour en bénéficier.
IMPORTANT
Lorsque vous activez des correctifs avec des indicateurs de suivi dans les environnements Always On, sachez que vous
devez activer les indicateurs de correction et de suivi sur tous les réplicas qui font partie du groupe de disponibilité.
L IEN
D’A RT IC L E/ B LO G DE
SC ÉN A RIO ET L A B A SE DE
SY M P TÔ M E À P L A GES DE VERSIO N S VERSIO N S ET P L A GES C O N N A ISSA N C ES
P REN DRE EN ET DE B UIL D DE B UIL D N O N Q UI F O URN IT P L US
C OMPT E IN DIC AT EUR DE SUIVI A P P L IC A B L ES A P P L IC A B L ES DE DÉTA IL S
Vous T8048 SQL Server SQL Server

rencontrez 2012 RTM 2014 SP2
des attentes vers service vers le SP/CU
CMEMTHREA pack actuel actuel
D élevées. (SP)/CU SQL Server
SQL Server SQL Server 2016 RTM
est installé sur 2014 RTM vers le SP/CU
des systèmes vers SP1 actuel
avec au moins SQL Server
8 cœurs par 2017 RTM
socket. vers le SP/CU
actuel
Vous T8079 SQL Server 2014 SP2 SQL Server Soft-NUMA

rencontrez vers le SP/CU actuel 2016 RTM (SQL Server)
des attentes vers le SP/CU SQL Server
CMEMTHREA actuel 2014 Service
D élevées. SQL Server Pack 2 est
SQL Server 2017 RTM désormais
est installé sur vers le SP/CU disponible !!!
des systèmes actuel
avec au moins
8 cœurs par
socket.
L IEN
Vous utilisez T9024 Package de mise à SQL Server CORRECTIF : Valeur

des jour cumulative 3 2012 SP3 élevée du compteur «
fonctionnalité SQL Server 2012 vers attentes d’écriture de
s qui reposent Service Pack 1 vers SP/CUSQL journal » sur une
sur le cache SP2 SQL Server 2014 actuel instance SQL Server
du pool de RTM Serveur 2014 2012 SQL Server
journaux. (par SP1 vers 2014
exemple, SP/CU actuel
Always On) SQL Server
SQL Server 2016 RTM
est installé sur vers le SP/CU
des systèmes actuel
avec plusieurs SQL Server
sockets. 2017 RTM
vers le SP/CU
actuel
Votre instance de T1236 Package de mise à SQL Server

SQL Server gère des jour cumulative 9 2012 SP3
milliers de pour SQL Server vers
réinitialisations de 2012 Service Pack 1 SP/CUSQL
connexion en raison vers SP2 Mise à jour actuel
de la mise en pool de cumulative 1 pour Serveur 2014
connexions. SQL Server 2014 SP1 vers
SP/CUSQL
actuel
Serveur 2016
RTM vers
SP/CU actuel
SQL Server
2017 RTM
vers le SP/CU
actuel
L IEN
La charge de T1118 SQL Server SQL Server Améliorations de

travail de 2012 RTM 2016 RTM lacurité pour la base
votre vers le SP/CU vers le SP/CU de données tempdb
application actuel actuel
implique une SQL Server SQL Server REMARQUE Activez
utilisation 2014 RTM 2017 RTM l’indicateur de suivi et
fréquente de vers le SP/CU vers le SP/CU ajoutez plusieurs
tempdb actuel actuel fichiers de données
(création et pour la base de
déplacement données tempdb.
de tables
temporaires
ou de
variables de
tableau).
Vous
remarquez
que les
demandes
des
utilisateurs
attendent des
ressources de
page tempdb
en raison
d’une
contention
d’allocation.
L IEN
Vous avez T1117 SQL Server SQL Server Recommandations

plusieurs 2012 RTM 2016 RTM pour réduire la
fichiers de vers le SP/CU vers le SP/CU contention
données actuel actuel d’allocation dans SQL
tempdb. SQL Server SQL Server Server base de
Les fichiers de 2014 RTM 2017 RTM données tempdb
données sont vers le SP/CU vers le SP/CU
d’abord de la actuel actuel
même taille.
En raison
d’une activité
importante,
les fichiers
tempdb
rencontrent
une
croissance et
tous les
fichiers ne
croissent pas
en même
temps et
provoquent
une
contention
d’allocation.
Des T174 SQL Server Aucun Documentatio

SOS_CACHESTORE 2012 SP1 n de DBCC
conflits de CU14 vers TRACEON -
verrouillage lourds SP/CU actuel Trace Flags
ou vos plans sont SQL Server (Transact-SQL)
fréquemment 2014 RTM Voir la section
délogés sur des CU6 vers Gestion de la
charges de travail de sp/CU actuel taille du cache
requête ad hoc. de Plan Cache
Internals
L IEN
Les entrées T8032 SQL Server Aucun Documentatio

dans le cache 2012 RTM n de DBCC
du plan sont vers le SP/CU TRACEON -
délogées en actuel Trace Flags
raison de la SQL Server (Transact-SQL)
croissance 2014 RTM Voir la section
d’autres vers le SP/CU Gestion de la
caches ou actuel taille du cache
d’employés de de Plan Cache
mémoire Internals
Consommatio
n élevée du
processeur en
raison de
recompilation
s fréquentes
de requêtes
Les statistiques T2371 SQL Server Aucun

existantes ne sont 2012 RTM
pas fréquemment vers le SP/CU
mises à jour en actuel
raison du grand SQL Server
nombre de lignes 2014 RTM
dans le tableau. vers le SP/CU
actuel
Les travaux T7471 SQL Server 2014 SP1 Aucun Amélioration des
statistiques CU6 vers SP/CU performances des
prennent actuel statistiques de mise à
beaucoup de jour SQL 2014 &
temps. SQL 2016
Impossible
d’exécuter
plusieurs
travaux de
mise à jour
statistiques
en parallèle.
La commande T2562 SQL Server Aucun

CHECKDB prend T2549 2012 RTM
beaucoup de temps vers le SP/CU
pour les bases de actuel
données de grande SQL Server
taille. 2014 RTM
vers le SP/CU
actuel
L IEN
La commande T2566 SQL Server Aucun Voir les détails

CHECKDB prend 2012 RTM T2566 dans
beaucoup de temps vers le SP/CU DBCC
pour les bases de actuel TRACEON -
données de grande SQL Server Trace Flags
taille. 2014 RTM (Transact-
vers le SP/CU SQL).
actuel Une base de
données
CHECKDB
plus rapide
SQL Server
(partie IV)
Exécution de T6498 Package de mise à SQL Server

requêtes d’entrepôt jour cumulative 6 2014 SP2
de données pour SQL Server vers
simultanées qui 2014 vers SP1 SP/CUSQL
prennent de longs actuel
résultats de Serveur 2016
compilation dans RTM vers
RESOURCE_SEMAPHORE_QUERY_COMPILE SP/CU actuel
des attentes. SQL Server
2017 RTM
vers le SP/CU
actuel
Vous dépannagez T4199 SQL Server Aucun

des problèmes de 2012 RTM
performances de vers SP4
requête spécifiques SQL Server
que les correctifs de 2014 RTM
l’optimiseur sont vers la version
désactivés par défaut. la plus
récente
Vous pouvez voir des T6532 SQL Server SQL Server

performances lentes T6533 2012 SP3 2016 RTM
à l’aide d’opérations T6534 vers SP/CU vers le SP/CU
de requête avec des actuel actuel
types de données SQL Server SQL Server
spatiales. 2014 SP2 2017 RTM
vers le SP/CU vers le SP/CU
actuel actuel
L IEN
Les requêtes T8075 SQL Server SQL Server CORRECTIF : Erreur

se 2012 SP2 2016 RTM de mémoire en
SOS_MEMORY_TOPLEVELBLOCKALLOCATOR CU8 vers vers le SP/CU mémoire lorsque
rencontrent SP/CU actuel actuel l’espace d’adressa
et SQL Server SQL Server SQL Server virtuel du
CMEMTHREA 2014 RTM 2017 RTM processus est faible
D attend. CU10 vers vers le SP/CU en SQL Server
Il y a peu sp/CU actuel actuel
d’espace
d’adressa
visite virtuel
disponible
pour SQL
Server
processus.
SQL Server T3449 SQL Server SQL Server CORRECTIF : la SQL

est installé sur 2012 SP3 2016 RTM Server de base de
un ordinateur CU3 vers vers le SP/CU données sur un
avec de SP/CU actuel actuel système avec un
grandes SQL Server SQL Server volume important de
quantités de 2014 RTM 2017 RTM mémoire prend plus
mémoire. CU14 vers la vers le SP/CU de temps que prévu
La création de cu RTM actuel
bases de actuelle
données SQL Server
prend 2014 SP1
beaucoup de CU7 vers
temps. SP/CU actuel
Tableau 2. Considérations générales et meilleures pratiques pour

améliorer les performances de votre instance de SQL Server
Examinez le contenu de la colonne Ressources en ligne de la Base de connaissances/Livres en ligne et envisagez
d’implémenter les instructions dans la colonne Actions recommandées.
RESSO URC E EN L IGN E A RT IC L E/ L IVRES DE L A B A SE DE

C O N N A ISSA N C ES A C T IO N S REC O M M A N DÉES
Configurer l’option de configuration du serveur degré max Utilisez la sp_configure stockée pour modifier la
de parallélisme configuration afin de configurer l’option de configuration du
serveur degré maximum de parallélisme pour votre instance
de SQL Server, comme indiqué dans l’article de la Base de
connaissances.
Calculer les limites de capacité par édition de SQL Server Êdition Entreprise licence serveur + licence d’accès client est
limitée à 20 cœurs par instance SQL Server client. Il n’existe
aucune limite dans le modèle de gestion des licences serveur
basée sur le cœur. Envisagez de mettre à niveau votre
édition de SQL Server vers la référence SKU appropriée pour
tirer parti de toutes les ressources matérielles.
Performances lentes sur Windows server lors de l’utilisation Examinez l’article et travaillez avec votre administrateur
du plan d’alimentation « équilibré » Windows pour implémenter l’une des solutions qui sont
notées dans la section « Résolution » de l’article.
Affectez manuellement des nodes NUMA à des groupes K.
Optimiser pour la PARAMÉTISATION FORCÉE des charges de Les entrées dans le cache du plan sont délogées en raison de
travail ad hoc la croissance d’autres caches ou d’employés de mémoire.
Vous pouvez également rencontrer des problèmes de cache
de plan lorsque le cache atteint son nombre maximal
d’entrées. Outre l’indicateur de suivi 8032 mentionné ci-
dessus, envisagez l’option d’optimisation des charges de
travail ad hoc et l’option de base de données PARAMÈTRES
FORCÉS.
Comment réduire la pagination de la mémoire du pool de Attribuez le droit d’utilisateur Activer les pages de
mémoires tampons dans SQL Server configuration de la verrouillage en mémoire (Windows) au compte de
mémoire et les considérations de taille dans SQL Server démarrage SQL service de verrouillage. Découvrez comment
2012 et versions ultérieures activer la fonctionnalité « pages verrouillées » dans SQL
Server 2012. Définissez la mémoire maximale du serveur à
environ 90 % de la mémoire physique totale. Assurez-vous
que les options de configuration de la mémoire du serveur
qui configurent la mémoire ne comptent que pour les nodes
configurés pour utiliser les paramètres de masque d’affinité.
SQL Server pages et grandes pages expliquées... Envisagez d’activer TF 834 si vous avez un serveur avec une
Optimisation des options de SQL Server lors de l’exécution grande quantité de mémoire, en particulier avec une charge
dans des charges de travail hautes performances de travail analytique ou d’entrepôt de données. N’oubliez pas
que le TF 834n’est pas recommandé si vous utilisez des index
columnstore .
Description du nombre de compartiments de la vérification Utilisez les options de configuration du serveur de

d’accès et du quota de cache de vérification d’accès vérification d’accès pour configurer ces valeurs en suivant les
disponibles dans la procédure stockée sp_configure’accès recommandations de l’article de la Base de connaissances.
Les valeurs recommandées pour les systèmes haut de
gamme sont les suivantes :
« nombre de compartiments de cache de vérification d’accès
» : 256
« quota de cache de vérification d’accès » : 1024
ALTER WORKLOAD GROUP : conseils de requête d’octroi de Si de nombreuses requêtes épuisent de grandes quantités
mémoire de mémoire, réduisez la valeur par défaut du groupe de
charges de travail dans la configuration du gouverneur de
ressources de 25 % par défaut à une valeur
request_max_memory_grant_percent inférieure. De
nouvelles options d’octroi de mémoire de requête sont
disponibles min_grant_percent max_grant_percent (et)
dans SQL Server
Initialisation de fichier instantané Travaillez avec votre administrateur Windows pour accorder
au compte de service SQL Server le droit d’utilisateur «
Effectuer les tâches de maintenance en volume » en fonction
des informations de la rubrique Books Online.
Considérations sur les paramètres « autogrow » et « Vérifiez les paramètres actuels de votre base de données et
autoshrink » dans SQL Server assurez-vous qu’ils sont configurés en suivant les
recommandations de l’article de la Base de connaissances.
Points de contrôle de base de données (SQL Server) Envisagez d’activer les points de contrôle indirects sur les
bases de données utilisateur pour optimiser le
comportement des opérations d’SQL Server 2012 et 2014.
CORRECTIF : Synchronisation lente lorsque les disques ont Si vous avez un groupe de disponibilité dans lequel le journal
des tailles de secteur différentes pour les fichiers journaux de des transactions sur le réplica principal se trouve sur un
réplica principal et secondaire dans les environnements SQL disque de taille de secteur de 512 byte et que le journal des
Server AG et Logshipping transactions du réplica secondaire se trouve sur un lecteur
avec une taille de secteur de 4K, il se peut que la
synchronisation soit lente. Dans ce cas, l’activation de TF
1800 doit corriger le problème.
Choix des développeurs : progression des requêtes - Si votre SQL Server n’est pas déjà liée au processeur et
à tout moment, n’importe où qu’une surcharge de 1,5 à 2 % est négligeable pour vos
Mise à jour pour exposer les statistiques d’exécution charges de travail, nous vous recommandons d’activer TF
de requête par opérateur dans showplan XML et 7412 comme indicateur de suivi de démarrage. Cet
l’événement étendu SQL Server 2014 SP2 indicateur active le profilage léger dans SQL Server 2014 SP2
ou version ultérieure, ce qui vous permet d’apporter des
dépannages de requête en direct dans les environnements
de production.
Tableau 3. Correctifs de performances inclus dans une mise à jour

cumulative
Examinez la description dans la colonne Symptômes et appliquez les mises à jour requises dans la colonne Mise
à jour requise dans les environnements applicables. Vous pouvez consulter l’article de la Base de connaissances
pour plus d’informations sur les problèmes respectifs. Ces recommandations ne vous obligent pas à activer des
indicateurs de suivi supplémentaires en tant que paramètres de démarrage. Il suffit d’appliquer la dernière mise
à jour cumulative ou service pack qui inclut ces correctifs pour en tirer parti.
NOTE
Le nom de la mise à jour cumulative dans la colonne Mise à jour requise fournit la première mise à jour cumulative SQL
Server résoudre ce problème. Une mise à jour cumulative contient tous les correctifs logiciels et toutes les mises à jour
incluses dans la version précédente SQL Server mise à jour. Par conséquent, nous vous recommandons d’installer la
dernière mise à jour cumulative afin de résoudre les problèmes.
A RT IC L E DE L A B A SE DE
SY M P TÔ M ES M ISE À JO UR REQ UISE C O N N A ISSA N C ES
Les écritures enthousiastes lors de l' SQL Server 2012 SP2 CU1 CORRECTIF : performances médiocres
select-into pour les tables temporaires SQL Server 2012 SP1 CU10 sur les opérations d’entrée/de-la
provoquent des problèmes de lorsque vous exécutez une sélection
performances. dans une opération de table
temporaire SQL Server 2012
Vous rencontrez SQL Server 2014 RTM CU1 CORRECTIF : les performances
PWAIT_MD_RELATION_CACHE ou SQL Server 2012 SP1 CU9 diminuent après un ALTER INDEX...
MD_LAZYCACHE_RWLOCK patientez L’opération ONLINE est abandonnée
après l’abandon SQL Server 2012 ou SQL Server 2014
ALTER INDEX ... ONLINE d’une
opération de requête.
Les requêtes ont soudainement des SQL Server 2014 RTM CU1 CORRECTIF : les threads ne sont pas
résultats médiocres sur l’édition SQL Server 2012 SP1 CU7 programmés de manière SQL Server
standard du produit. 2012 ou SQL Server 2014 Édition
Standard
Performances ralenties en raison d’une SQL Server 2012 SP1 CU4 CORRECTIF : vous pouvez faire face à
baisse soudaine de la durée de vie de des problèmes de performances SQL
la page. Server 2012
Utilisation élevée du processeur par le SQL Server 2012 SP1 CU3 CORRECTIF : Pointe du processeur
moniteur de ressources sur les lorsqu’il n’y a aucune charge sur un
systèmes avec une configuration serveur après l’installation SQL Server
NUMA, une mémoire élevée et une « 2012 sur le serveur
mémoire serveur maximale » définie
sur une faible valeur.
Le programme de planification qui SQL Server 2012 SP1 CU2 CORRECTIF : Erreur 17883 lorsque
n’offre pas de rendement pendant que vous exécutez une requête sur un
l’allocation de mémoire pour le tri serveur qui dispose de nombreuses
s’exécute est associé à de grandes processeurs et d’une grande quantité
quantités de mémoire accordées sur de mémoire dans SQL Server 2012 ou
les systèmes où une grande quantité SQL Server 2008 R2
de mémoire est installée.
Programmeur sans rapport de SQL Server 2012 SP1 CU1 CORRECTIF : « Le processus semble ne
rendement lorsque l’opérateur de tri pas produire sur le scheduler »
parcourt de nombreux compartiments message d’erreur lorsque vous
dans le pool de mémoires tampons sur exécutez une requête dans SQL Server
des systèmes avec une mémoire 2012
importante.
Utilisation élevée du processeur SQL Server 2012 SP2 CU1 CORRECTIF : la charge de travail de
lorsque vous exécutez des requêtes SQL Server 2014 RTM CU2 compilation de requête intense n’est
simultanées qui prennent beaucoup de pas mise à l’échelle avec un nombre
temps à compiler sur des systèmes croissant de cœurs sur le matériel
avec plusieurs nodes NUMA et de NUMA et entraîne une saturation du
nombreux cœurs. processeur SQL Server
Les allocations de mémoire pour les SQL Server 2012 SP1 CU3 CORRECTIF : résoudre SQL Server
opérateurs de tri prennent beaucoup problèmes de performances dans les
de temps sur les systèmes NUMA avec environnements NUMA
une mémoire importante en raison
des allocations de nœuds distants.
A RT IC L E DE L A B A SE DE
SY M P TÔ M ES M ISE À JO UR REQ UISE C O N N A ISSA N C ES
Erreurs de mémoire en mémoire SQL SQL Server 2012 RTM CU1 CORRECTIF : Erreur de mémoire
Server est installé sur un ordinateur insatisfait lorsque vous exécutez une
NUMA avec une grande quantité de instance de SQL Server 2012 sur un
RAM et SQL Server a beaucoup de ordinateur qui utilise NUMA
pages étrangères.
Contention spinlock sur SQL Server 2014 RTM CU1 CORRECTIF : performances ralenties
SOS_CACHESTORE et SQL Server 2012 SP1 CU7 dans SQL Server 2012 ou SQL Server
SOS_SELIST_SIZED_SLOCK lorsque 2014 lorsque vous créez un index sur
vous créez un index sur le type de un type de données spatiales d’une
données spatiales dans une grande grande table
table.
Type d’attente CMEMTHREAD élevé SQL Server 2014 RTM CU1 CORRECTIF : performances ralenties
lorsque vous créez un index sur un SQL Server 2012 SP1 CU7 dans SQL Server lorsque vous créez un
type de données spatiales dans des index sur un type de données spatiales
tables de grande taille. d’une table de grande taille dans une
instance SQL Server 2012 ou SQL
Server 2014
Problèmes de performances dus aux SQL Server 2014 RTM CU1 CORRECTIF : des problèmes de
attentes CMEMTHREAD pendant SQL Server 2012 SP1 CU9 performances se produisent dans les
l’allocation de mémoire sur environnements NUMA lors du
SOS_PHYS_PAGE_CACHE des traitement de pages étrangères SQL
ordinateurs de grande taille. Server 2012 ou SQL Server 2014
La commande CHECKDB prend Package de mise à jour cumulative 6 CORRECTIF : la commande DBCC
beaucoup de temps pour les bases de pour SQL Server 2014 CHECKDB/CHECKTABLE peut prendre
données de grande taille. plus de temps SQL Server 2012 ou
SQL Server 2014
Remarques importantes
Si toutes les conditions du tableau 1 s’appliquent à vous :
Recommandations pour SQL Server 2014 : appliquer au moins la mise à jour cumulative 1 pour SQL
Server 2014 pour la version finale et ajouter « -T8048 -T9024 -T1236 -T1117 -T1118 » à la liste des
paramètres de démarrage SQL Server.
Recommandations pour SQL Server 2012 : appliquer SP2 et ajouter « -T8048 -T9024 -T1236 -T1117 -
T1118 » à SQL Server liste des paramètres de démarrage.
Pour obtenir des informations générales sur l’utilisation des indicateurs de suivi, consultez la rubrique
DBCC TRACEON - Trace Flags (Transact-SQL) dans SQL Server Books Online.
Vous trouverez plus d’informations sur le nombre de processeurs, la configuration NUMA, etc., dans
votre journal d’erreurs SQL Server dans SQL Server Management Studio (SSMS).
Pour trouver la version de SQL Server, vérifiez ce qui suit :
Comment déterminer la version et l’édition de SQL Server et de ses composants
Références
DBCC (Transact-SQL)
DBCC TRACEON - Trace Flags (Transact-SQL)
Comment obtenir le dernier Service Pack pour SQL Server 2012
Où trouver des informations sur les dernières SQL Server builds
SQL Server de la communauté sur les mises à jour importantes SQL Server
Correctifs liés aux performances et à la stabilité dans les builds post-SQL Server 2012 SP1
Dernières builds de SQL Server 2012
Dernières builds de SQL Server 2012 SP1
Dernières builds de SQL Server 2012 SP2
Dernières builds de SQL Server 2014
S’applique à
SQL Server Web 2014
SQL Server Web 2012
Mises à jour recommandées et options de
configuration pour SQL Server 2017 et 2016 avec
des charges de travail hautes performances
Cet article décrit une liste des améliorations des performances et des options de configuration disponibles pour
SQL Server 2016 et versions ultérieures.
Version du produit d’origine : SQL Server 2017 Windows, SQL Server 2016
Introduction
Cet article décrit les améliorations et modifications de performances disponibles pour Microsoft SQL Server
2017 et SQL Server 2016 par le biais de différentes mises à jour de produits et options de configuration.
Nous vous recommandons d’envisager d’appliquer ces mises à jour pour améliorer les performances de SQL
Server instances. Le degré d’amélioration dépend de différents facteurs, notamment le modèle de charge de
travail, les points de contention, la disposition du processeur (nombre de groupes de processeurs, de sockets, de
nœuds NUMA et de cœurs dans un nœud NUMA) et la quantité de mémoire disponible dans le système.
L’équipe de support SQL Server a utilisé ces mises à jour et modifications de configuration pour obtenir des
gains de performances raisonnables pour les charges de travail des clients qui utilisent des systèmes matériels
qui comprenaient plusieurs nodes NUMA et de nombreux processeurs. L’équipe de support technique
continuera à mettre à jour cet article avec d’autres mises à jour à l’avenir.
Définition : systèmes haut de gamme

Un « système haut de gamme » possède généralement plusieurs sockets, huit cœurs ou plus par socket, et
un demi-octet ou plus de mémoire.
Appliquer les mises à jour recommandées et améliorer SQL Server

performances
Ces recommandations pour améliorer les performances de SQL Server 2017 et SQL Server 2016 sont
regroupées en cinq tableaux, comme suit :
Le tableau 1 contient les mises à jour et indicateurs de suivi les plus fréquemment recommandés pour
l’évolutivité sur les systèmes haut de gamme.
Le tableau 2 contient des recommandations et des conseils pour un réglage des performances
supplémentaire.
Le tableau 3 contient des informations sur les modifications apportées au comportement et aux paramètres
par défaut SQL 2017 et 2016.
Le tableau 4 contient des correctifs d’évolutivité supplémentaires qui ont été inclus avec une mise à jour
cumulative.
Le tableau 5 contient des correctifs recommandés et des instructions de configuration pour SQL Server
instances déployées dans un environnement Linux.
NOTE
Pour obtenir un contexte supplémentaire, consultez Les réglages fréquemment utilisés pour régler une SQL Server.
IMPORTANT
Si vous avez activé les indicateurs de suivi, veillez à consulter les informations de cet article après avoir exécuté la
migration vers SQL Server 2017 ou SQL Server 2016. De nombreux indicateurs de suivi et options de configuration
répertoriés dans cet article sont devenus des options par défaut dans SQL Server 2017 et SQL Server 2016.
Tableau 1. Mises à jour importantes et indicateurs de suivi pour les

systèmes haut de gamme
Examinez le tableau suivant et activez les indicateurs de suivi dans la colonne d’indicateur de suivi une fois que
vous vous êtes assuré que votre instance de SQL Server répond aux exigences de la colonne Des plages de
versions et de builds applicables.
NOTE
La version et la build applicables indiquent la mise à jour spécifique dans laquelle l’indicateur de modification ou
de suivi a été introduit. Si aucune cu n’est spécifiée, toutes les CUS du SP sont incluses.
La version et la build non applicables indiquent la mise à jour spécifique dans laquelle l’indicateur de modification
ou de suivi est devenu le comportement par défaut. Par conséquent, le simple fait d’appliquer cette mise à jour sera
suffisant pour en bénéficier.
IMPORTANT
Lorsque vous activez des correctifs qui ont des indicateurs de suivi dans les environnements Always On, sachez que vous
devez activer les indicateurs de correction et de suivi sur tous les réplicas qui font partie du groupe de disponibilité.
A RT IC L E DE L A B A SE
SC ÉN A RIO ET DE C O N N A ISSA N C ES
SY M P TÔ M E À P L A GES DE VERSIO N S VERSIO N S ET P L A GES O U L IEN DE B LO G
P REN DRE EN ET DE B UIL DS DE B UIL D N O N P O UR P L US
C OMPT E IN DIC AT EUR DE SUIVI A P P L IC A B L ES A P P L IC A B L ES D’IN F O RM AT IO N S
Les T174 SQL Server 2016 Aucun KB3026083 -

SOS_CACHESTORE RTM vers le SP/CU CORRECTIF : une
conflit de verrouillage actuel SQL Server contention
ou vos plans sont 2017 RTM vers le SOS_CACHESTORE
fréquemment SP/CU actuel spinlock sur un cache
délogés sur des de plan SQL Server
charges de travail de ad hoc entraîne une
requête ad hoc. utilisation élevée du
processeur dans SQL
Server
Les entrées dans le T8032 SQL Server 2016 Aucun Documentation de

cache du plan sont RTM vers le SP/CU DBCC TRACEON -
éjectées en raison de actuel SQL Server Trace Flags (Transact-
la croissance dans 2017 RTM vers le SQL) Voir la section
d’autres caches ou de SP/CU actuel Gestion de la taille du
la consommation cache de Plan Cache
élevée du processeur Internals
par les employés de
mémoire en raison
de recompilations
fréquentes de
requêtes
tempdb est T3468 SQL Server 2016 SP1 Aucun Point de contrôle
largement utilisé et a CU5 vers le SP/CU indirect et tempdb -
de nombreuses actuel SQL Server le bon, le mauvais et
modifications 2017 CU1 vers le le programmeur non
apportées aux SP/CU actuel réparateur
données dans KB4040276 -
tempdb Vous CORRECTIF : Les
rencontrez des points de contrôle
messages de indirects sur la base
planification qui n’ont de données tempdb
pas de rapport lors provoquent une
de l’utilisation d’un erreur «
point de contrôle Programmeur non
indirect pour la base réparateur de
de données tempdb rendement » dans
SQL Server 2016 et
2017
Des transactions T3427 SQL Server 2016 SP1 SQL Server 2017 KB3216543 -
courtes fréquentes se CU2 vers SQL Server RTM CORRECTIF : les
produisent dans 2016 SP2 CU2 charges de travail qui
tempdbYou utilisent de
remarquez une nombreuses
augmentation de transactions courtes
l’utilisation du et fréquentes dans
processeur pour ces SQL Server 2016 et
transactions La 2017 peuvent
conformité aux consommer plus de
critères courants processeur qu’SQL
n’est pas activée Server 2014
Vous dépannagez T4199 SQL Server 2016 Aucun KB974006 - Modèle

des problèmes de RTM vers le SP/CU SQL Server de suivi
performances de actuel SQL Server des correctifs de
requête spécifiques 2017 RTM vers le l’optimiseur de
que les correctifs de SP/CU actuel requêtes 4199
l’optimiseur sont Remarque Au lieu
désactivés par défaut. de l’indicateur de
suivi au niveau du
serveur 4199,
envisagez d’utiliser
l’option d’étendue de
base de données
QUERY_OPTIMIZER_
HOTFIXES ou
l’indicateur de
ENABLE_QUERY_OPT
IMIZER_HOTFIXES.
Les travaux de T7471 SQL Server 2016 Aucun KB3156157 :

statistiques prennent RTM CU1 vers sp/CU l’exécution
beaucoup de temps. actuel SQL Server simultanée de
Impossible d’exécuter 2017 RTM vers plusieurs
plusieurs travaux de SP/CU actuel STATISTIQUES DE
mise à jour MISE À JOUR pour
statistiques en différentes
parallèle statistiques sur un
même tableau est
disponible
Amélioration des
performances des
statistiques de mise à
jour SQL 2014 &
SQL 2016
Tableau 2. Considérations générales et meilleures pratiques pour

améliorer les performances de SQL Server instance
Examinez le contenu de l’ar ticle de la Base de connaissances ou de la colonne Ressources en ligne books et
envisagez d’implémenter les instructions dans la colonne Actions recommandées.
A RT IC L E DE L A B A SE DE C O N N A ISSA N C ES O U RESSO URC E

B O O K S O N L IN E A C T IO N S REC O M M A N DÉES
Configurer l’option de configuration du serveur degré max Utilisez la procédure stockée pour modifier la configuration
de parallélisme afin de configurer l’option de configuration du serveur degré
maximum de parallélisme pour votre instance de SQL Server
selon l’article de la sp_configure Base de connaissances.
Calculer les limites de capacité par édition Limitation de Êdition Entreprise licence de licence d’accès client et serveur
licence principale pour SQL Server 2012 est limitée à 20 cœurs par instance SQL Server client.
Il n’existe aucune limite dans le modèle de gestion des
licences serveur basée sur le cœur.
Envisagez de mettre à niveau votre édition de SQL Server
vers la référence SKU appropriée pour utiliser toutes les
ressources matérielles.
Performances lentes sur Windows server lors de l’utilisation Examinez l’article et travaillez en collaboration avec votre
du plan d’alimentation équilibrée administrateur Windows pour implémenter l’une des
solutions répertoriées dans la section Résolution de l’article.
optimiser pour les charges de travail ad hoc Configuration Les entrées dans le cache du plan sont délogées en raison de
du serveur Option DE CONFIGURATION FORCÉE la croissance d’autres caches ou d’employés de mémoire.
PARAMÉTISATION FORCÉE Vous pouvez également rencontrer des problèmes de cache
de plan lorsque le cache atteint son nombre maximal
d’entrées. Outre l’indicateur de suivi 8032 mentionné ci-
dessus, envisagez l’option d’optimisation des charges de
travail ad hoc et l’option de base de données PARAMÈTRES
FORCÉS.
Comment réduire la pagination de la mémoire du pool de Attribuez le droit d’utilisateur Activer les pages de
mémoires tampons dans SQL Server verrouillage en mémoire (Windows) au compte de
Considérations sur la configuration de la mémoire et le SQL démarrage SQL service de verrouillage. Découvrez comment
Server 2012 et versions ultérieures activer la fonctionnalité « pages verrouillées » dans SQL
Server 2012. Définissez la mémoire maximale du serveur à
environ 90 % de la mémoire physique totale. Assurez-vous
que les options de configuration de la mémoire du serveur
qui configurent la mémoire ne comptent que pour les nodes
configurés pour utiliser les paramètres de masque d’affinité.
SQL Server pages et grandes pages expliquées... Envisagez d’activer le TF 834 si vous disposez d’un serveur
Optimisation des options de SQL Server lors de l’exécution qui dispose de beaucoup de mémoire, en particulier pour
dans des charges de travail hautes performances une charge de travail analytique ou d’entrepôt de données.
Gardez à l’esprit que l’interopérabilité des index
Columnstoreavec le modèle de mémoire de grande page
SQL Server .
Problèmes de performances des requêtes associés à un Si le cache de sécurité atteint une taille importante et que
cache de sécurité de grande taille Comment personnaliser le vous rencontrez des problèmes de performances et une
quota pour le magasin de cache TokenAndPermUserStore contention de spinlock, envisagez d’activer les indicateurs de
dans SQL Server 2005 Service Pack 3 DBCC TRACEON - suivi T4610 et T4618 pour réduire la taille maximale de
Trace Flags (Transact-SQL) TokenAndPermuserStore.
ALTER WORKLOAD GROUP KB3107401 - De nouvelles Si de nombreuses requêtes épuisent de grandes quantités
options d’octroi de mémoire de requête sont disponibles de mémoire, réduisez la valeur par défaut du groupe de
(min_grant_percent et max_grant_percent) dans SQL Server charges de travail dans la configuration du gouverneur de
2012 ressources de 25 % par défaut à une valeur
request_max_memory_grant_percent inférieure. De
nouvelles options d’octroi de mémoire de requête sont
disponibles min_grant_percent max_grant_percent (et )
dans SQL Server.
SQL 2016 - Il s’exécute simplement plus rapidement : Ajoutez plusieurs fichiers de données de taille égale pour la
configuration TEMPDB automatique base de données tempdb s’il s’agit d’un serveur mis à
niveau. Pour les nouvelles installations, le programme
d’installation le fait automatiquement.
TEMPDB - Fichiers et indicateurs de suivi et mises à jour Utiliser les optimisations tempdb et améliorer l’évolutivité en
évitant ou en réduisant DDL sur les objets temp
Initialisation de fichier instantané Travaillez en collaboration avec votre administrateur

Windows pour accorder au compte de service SQL Server les
droits d’utilisateur Effectuer des tâches de maintenance en
volume selon les informations de la rubrique Books Online.
Considérations sur les paramètres « autogrow » et « Vérifiez les paramètres actuels de votre base de données et
autoshrink » dans SQL Server assurez-vous qu’ils sont configurés selon les
recommandations de l’article de la Base de connaissances.
Points de contrôle indirects Envisagez d’activer les points de contrôle indirects sur les
comportement des opérations d’SQL Server 2014 et 2012.
SQL Server : ram de grande taille et point de contrôle DB Envisagez d’activer les points de contrôle indirects sur les
comportement des opérations d’opérations d’entreprise
dans SQL Server 2014 et 2012. Examinez les ajustements
requis pour tempdb dans le point de contrôle indirect de
référence et tempdb : le bon, le mauvais et le programme de
planification sans rendement
KB3009974 - CORRECTIF : synchronisation lente lorsque les Si vous disposez d’un groupe de disponibilité dans lequel le
disques ont des tailles de secteur différentes pour les fichiers journal des transactions sur le réplica principal se trouve sur
journaux de réplica principal et secondaire dans les un disque dont la taille de secteur est de 512 byte et que le
environnements SQL Server AG et Logshipping journal des transactions du réplica secondaire se trouve sur
un lecteur dont la taille de secteur est de 4 Ko, la
synchronisation peut être lente. Dans ce cas, l’activation de
TF 1800 doit corriger le problème.
Infrastructure de profilage de requête KB3170113 - Si votre SQL Server n’est pas déjà liée au processeur et
3170113 - Mise à jour pour exposer les statistiques qu’une surcharge de 1,5 à 2 % est négligeable pour vos
d’exécution de requête par opérateur dans showplan XML et charges de travail, nous vous recommandons d’activer TF
événement étendu dans SQL Server 2014 SP2 7412 comme indicateur de suivi de démarrage. Cet
indicateur active le profilage léger dans SQL Server 2014 SP2
ou version ultérieure. Cela vous permet de résoudre les
problèmes de requête en direct dans les environnements de
production.
Identifier les régressions de choix de plan à l’aide du magasin Utilisez la fonctionnalité magasin de requêtes pour identifier
de requêtes Activer le meilleur plan de requête les requêtes qui ont régressé ou dont les performances sont
médiocres Si les problèmes de performances de requête se
produisent en raison de l’estimation de la cardinalité,
sélectionnez la version CE appropriée : option d’étendue
base de données, conseil de requête, niveau de compatibilité
de base de données ou indicateur de suivi
LEGACY_CARDINALITY_ESTIMATION
LEGACY_CARDINALITY_ESTIMATION 9481
L’hypothèse d’un contenu joint dans le New Cardinality Évaluez les requêtes qui utilisent des jointeurs et des filtres
Estimateor dégrade les performances des requêtes pour comprendre l’effet d’un contenu simple et de base.
Utilisez l’indicateur de suivi 9476 pour le contenu simple au
lieu du contenu de base lorsque vous utilisez l’estimateur de
cardinalité par défaut.
Améliorations apportées au niveau de compatibilité 130 Utilisez le niveau de compatibilité de base de données 130
Améliorations du niveau de compatibilité 140 ou ultérieur pour bénéficier des améliorations suivantes :
Seuil adaptatif et agressif pour la mise à jour des statistiques
existantes pour les tableaux plus volumineux
Amélioration du mécanisme d’échantillonnage et de
verrouillage pour la mise à jour des statistiques
Statistiques échantillonn es par un processus multi-thread
Possibilité d’exécuter insert-select à l’aide du niveau de
compatibilité de base de données parallelismUse 140 ou
ultérieur pour bénéficier des améliorations suivantes :
Amélioration de l’estimation de la cardinalité et de la qualité
de la planifier à l’aide de nouvelles fonctionnalités telles que
l’exécution entrecoupées pour les fonctions à valeurs de
table à plusieurs instructions et la jointation adaptative
Amélioration de l’utilisation de la mémoire par le biais du
retour d’octroi de mémoire
Meilleures pratiques avec le magasin de requêtes

Définir le mode de capture sur Auto
Activer les indicateurs de suivi 7745 et 7752 pour améliorer
les performances du magasin de requêtes lors des scénarios
de haute disponibilité et de récupération d’urgence
Appliquer le correctif dans KB4340759 - CORRECTIF :
performances lentes de SQL Server 2016 lorsque le magasin
de requêtes est activé si vous faites face à une contention
spinlock de magasin de requêtes sous des charges de travail
élevées
SQL Server 2016/2017 : modèle de réplica secondaire du Si vous faites l’objet d’un trop grand nombre d’attentes ( ou
groupe de disponibilité et performances ), examinez ce blog pour prendre des mesures correctives
(appliquer le correctif applicable, évaluer l’utilisation
appropriée du PARALLEL_REDO_TRAN_TURN
DPT_ENTRY_LOCK modèle de DIRTY_PAGE_TABLE_LOCK
réaxyment)
KB2634571 : les améliorations apportées à la commande Si vous exécutez des commandes DBCC CHECK sur des
DBCC CHECKDB peuvent accélérer les performances lorsque bases de données de grande taille (plusieurs To), envisagez
vous utilisez l’option PHYSICAL_ONLY Les améliorations d’utiliser les indicateurs de suivi T2562, T2549 et T2566.
apportées à la commande CHECKDB DBCC peuvent Plusieurs vérifications sont maintenant situées sous l’option
améliorer les performances lorsque vous utilisez les détails EXTENDED_LOGICAL_CHECK dans SQL Server 2016.
de l’option PHYSICAL_ONLY optionT2566 dans DBCC
TRACEON - Indicateurs de suivi A plus rapide CHECKDB -
Partie IV (UDT CLR SQL)
Protéger les SQL Server contre les attaques contre les Évaluez attentivement les performances de l’ombrage
vulnérabilités de canal latéral de Spectre et Derdown d’adresse virtuelle (KVAS) du noyau, de l’indirection de la
table des pages du noyau (KPTI) et de l’atténuation de la
prédiction de branche indirecte (IBP) sur différentes charges
de travail SQL Server dans votre environnement.
Tableau 3. Modifications importantes introduites dans SQL Server

2017 et SQL Server 2016
SQL Server 2017 et SQL Server 2016 contient plusieurs améliorations en matière d’évolutivité et de
performances. Diverses modifications de configuration et indicateurs de suivi requis dans SQL Server 2014 et
SQL Server 2012 sont devenus le comportement par défaut dans SQL Server 2017 et 2016. Ce tableau fournit
une vue d’ensemble de toutes les modifications implémentées dans SQL Server 2017 et SQL Server 2016.
IN F O RM AT IO N S ET RÉF ÉREN C ES
C AT ÉGO RIE RÉSUM É DE L A M O DIF IC AT IO N SUP P L ÉM EN TA IRES
SQL Moteur Indicateurs de suivi fréquemment SQL Server Indicateurs de suivi

utilisés qui sont retirés ou qui ne sont
plus nécessaires dans SQL Server 2016
et les versions ultérieures de SQL
Server : 8048, 8079, 9024, 1236,
1118, 1117, 6498, 8075, 3449, 6532,
6533, 6534.
Moteur de base de données Nouveautés de Moteur de base de

données - SQL Server 2017
Moteur de base de données Modifications importantes apportées

fonctionnalités de SQL Server 2016
Moteur de base de données Modifications importantes apportées

fonctionnalités de SQL Server 2017
Conversions de type de données de SQL Server 2016 (13.x) inclut des Pour plus d’informations, voir SQL
traitement des requêtes améliorations dans certaines Server 2016dans la gestion de certains
conversions de types de données et types de données et des opérations
certaines opérations (principalement peu courantes.
rares).
Groupe de disponibilité Pour la base de données secondaire, SQLS titre16 !, Épisode 2 : Amorçage
l’amorçage automatique d’initialisation automatique des groupes de
utilise les points de terminaison de disponibilité
mise en miroir de base de données
pour diffuser le contenu de la base de
données au second niveau et les
appliquer.
Groupe de disponibilité SQL Server 2016 utilise moins de SQL 2016 - Il s’exécute simplement
commutateurs de contexte lorsqu’il plus rapidement : commutateurs de
transporte des blocs de journaux du contexte avec transport de journal
principal au secondaire. AlwaysOn SQL Server 2016 - Il
s’exécute simplement plus rapidement :
groupes de disponibilité AlwaysOn
surchargés
Groupe de disponibilité SQL Server 2016 utilise des SQL 2016 - Il s’exécute simplement
algorithmes de compression améliorés plus rapidement : Compression
et la compression parallèle des parallèle AlwaysOn / Algorithmes
données de bloc de journaux. améliorés
Groupe de disponibilité SQL Server 2016 tire parti du matériel SQL 2016 - Il s’exécute simplement
basé sur les fonctionnalités de plus rapidement - Chiffrement
chiffrement AES-NI pour améliorer AlwaysOn AES-NI
l’évolutivité et les performances de la
livraison des journaux Always On par
un facteur significatif.
Performances SQL Server 2016 détecte les SQL 2016 - Il s’exécute simplement
fonctionnalités de processeur pour plus rapidement : le magasin de
AVX ou SSE et utilise les fonctionnalités colonnes utilise des instructions
vectorielles basées sur le matériel pour vectorielles (SSE/AVX)
améliorer l’évolutivité et les
performances lors de la compression,
de la création de dictionnaires et du
traitement des données du magasin de
colonnes.
Performances SQL Server 2016 tire parti des SQL 2016 - Il s’exécute simplement
instructions du vecteur UC pour plus rapidement - BULK INSERT utilise
améliorer les performances d’insertion des instructions vectorielles (SSE/AVX)
en bloc.
Performances SQL Server 2016 active un insert ... SQLS titre16!, Épisode 3 : Insertion
Instruction SELECT à utiliser à l’aide du parallèle... SELECT
parallélisme réduisant
considérablement le temps de
chargement des données.
Performances SQL Server 2016 active l’opération SQLSutert16!, Épisode 5 : TRUNCATE

TRUNCATE sur des partitions Des partitions sélectionnées
individuelles d’une table pour
l’archivage des partitions plus
anciennes.
Performances SQL Server 2016 ajuste SQL 2016 - Il s’exécute simplement

dynamiquement la taille du pool de plus rapidement : In-Memory pool de
travail In-Memory base de données travail de base de données optimisé
optimisée selon vos besoins.
Tempdb Les allocations sont tempdb et les SQL 2016 - Il s’exécute simplement
bases de données utilisateur utilisent plus rapidement : modifications -
des étendues complètes uniformes. La T1117 et -T1118 pour TEMPDB et les
croissance des fichiers dans tempdb se bases de données utilisateur
produit pour tous les fichiers en même
temps.
Tempdb Moteur de base de SQL 2016 - Il s’exécute simplement

données’installation calcule plus rapidement : configuration
automatiquement le nombre de TEMPDB automatique
fichiers de données tempdb.
Stockage Le moteur de base de données utilise SQL 2016 - Il s’exécute simplement

0xC0 tampon au lieu de 0x00 pour plus rapidement : LDF marqué
l’initialisation du fichier journal des
transactions.
Stockage Pour les serveurs de mémoire de SQL 2016 - Il s’exécute simplement

grande taille et les environnements plus rapidement : point de contrôle
d’écriture importants, les points de indirect par défaut
contrôle indirects sont plus
performants.
Stockage Des taux élevés de transactions SQL 2016 - Il s’exécute simplement

peuvent bénéficier de plusieurs plus rapidement : plusieurs travailleurs
enregistreurs qui vident le cache des de l’enregistreur de journaux
journaux dans le journal des
transactions.
Sauvegarde et restauration Les sauvegardes peuvent être SQLStunest16!, Épisode 1 :

compressées pour la base de données Compression de sauvegarde pour les
chiffrée à l’aide du chiffrement TDE si bases de données activées pour TDE
vous spécifiez MAXTRANSFERSIZE
supérieur à 65536.
SQL SYSTÈME D’EXPLOITATION Partitionner dynamiquement les objets SQL 2016 - Il s’exécute simplement
mémoire pour réduire la contention plus rapidement : partitionnement
d’objets mémoire. d’objet mémoire dynamique
(CMemThread)
SQL SYSTÈME D’EXPLOITATION SQL Server 2016 surveille les modèles SQL 2016 - Il s’exécute simplement
d’utilisation quantum des travailleurs plus rapidement : algorithmes de
permettant à tous les employés planification mis à jour
d’obtenir un traitement équitable et
d’améliorer l’évolutivité.
SQL SYSTÈME D’EXPLOITATION SQL Server 2016 interroge la SQL 2016 - Il s’exécute simplement
disposition matérielle et configure plus rapidement : automatique soft
automatiquement la fonction NUMA NUMA
(Soft NUMA) sur les systèmes qui
rapportent au moins 8 processeurs par
nœud NUMA. Le partitionnement
déclenche différents ajustements dans
le moteur de base de données pour
améliorer l’évolutivité et les
performances.
VÉRIFICATION DBCC Spécifiez MAXDOP pour gérer les SQLS rendez-vous16!, Épisode 6 :
ressources qui sont consommées par DBCC CHECKDB avec MAXDOP
la commande CHECK DBCC.
VÉRIFICATION DBCC DBCC CHECK utilise un algorithme SQL 2016 - Il s’exécute simplement
d’analyse des pages amélioré qui offre plus rapidement : DBCC s’étend 7x
moins de contention et des mieux
fonctionnalités avancées de lecture
avant.
VÉRIFICATION DBCC Les commandes CHECK DBCC SQL 2016 - Il s’exécute simplement
prennent beaucoup de temps SQL plus rapidement : vérifications
Server évaluent des types de données étendues DBCC
et des index spéciaux. Ces vérifications
ont été déplacées sous
EXTENDED_LOGICAL_CHECKS option.
Page de codes Les utilitaires INSERT en BLOC ou bcp SQLSriert16!, Épisode 10 : « Je peux
ont été améliorés pour charger les faire un verre ... », mais puis-je le
données UTF-8 dans une table SQL charger dans une base de données ?
Server.
Spatial SQL Server 2016 supprime les activités SQL 2016 - Il s’exécute simplement
PInvoke et PUnInvoke pendant plus rapidement : Implémentation
l’exécution SQL T pour de nombreuses spatiale native
méthodes spatiales.
Spatial SQL Server 2016 améliore l’évolutivité SQL 2016 - Il s’exécute simplement
du TVP qui utilise des données plus rapidement : TVP avec des
spatiales à l’aide de validations colonnes spatiales
spatiales natives.
Spatial Les améliorations spatiales natives et SQL 2016 - Il s’exécute simplement

TVP permettent SQL Server optimiser plus rapidement : les builds d’index
la création d’index et le tessellation des spatial sont plus rapides
données spatiales.
MSDTC SQL Server 2016 démarre SQL 2016 - Utilise le démarrage

dynamiquement MSDTC selon les MSDTC à la demande
besoins, ce qui permet d’utiliser des
ressources pour d’autres activités
jusqu’à ce que cela soit nécessaire.
XEvent Diverses modifications sont apportées SQL 2016 - Il s’exécute simplement

à la logique du fournisseur Linq XEvent plus rapidement : XEvent Linq Reader
pour réduire le basculement de
contexte, les allocations de mémoire et
d’autres aspects pour accélérer le
rendu des événements.
Tableau 4. Correctifs importants inclus dans une cu

Examinez la description dans la colonne Symptômes et appliquez les mises à jour requises (de préférence la
dernière mise à jour contenant le correctif spécifique) dans la colonne Mise à jour requise dans les
environnements applicables. Vous pouvez consulter l’article de la Base de connaissances pour plus
d’informations sur les problèmes respectifs. Ces recommandations ne vous obligent pas à activer des
indicateurs de suivi supplémentaires en tant que paramètres de démarrage, sauf si elles sont explicitement
appelées dans l’article ou dans ce tableau. Il suffit d’appliquer la dernière mise à jour cu ou Service Pack qui
inclut ces correctifs pour en tirer parti.
Remarque Le nom de la mise à jour à jour requise dans la colonne Mise à jour requise fournit la première mise
à jour SQL Server qui résout ce problème. Une mise à jour cumulative contient tous les correctifs logiciels et
toutes les mises à jour incluses avec la version SQL Server mise à jour précédente. Comme indiqué dans les
mises à jour du modèle de maintenance incrémentielle SQL Server,nous vous recommandons d’installer la
dernière mise à jour cumulative dans une cadence proactive continue pour résoudre ou empêcher les
problèmes décrits. Notez également que depuis SQL Server 2017, le modèle de maintenance moderne pour
SQL Server a été introduit afin que les Service Packs ne soient plus disponibles.
DESC RIP T IO N DU M ISE À JO UR

VERSIO N A P P L IC A B L E Z O N E O U C O M P O SA N T P RO B L ÈM E RÉSO L U REC O M M A N DÉE
SQL Server 2016SQL Server Restauration & La sauvegarde du journal CORRECTIF : Erreurs 33111
2017 sauvegarde d’une base de données TDE et 3013 lors de la backing
échoue et renvoie l’erreur up TDE-encrypted database
33111 par intermittence in SQL Server
lorsque vous recherchez Mise à jour cumulative 2
une copie plus ancienne du pour SQL Server 2017
certificat qui a été utilisée Mise à jour cumulative 6
pour chiffrer le deK dans le pour SQL Server 2016 SP1
passé si maxTRANSFERSIZE Mise à jour cumulative 9
n’est pas utilisé par défaut. pour SQL Server 2016
SQL Server 2016SQL Server Restauration & Instruction RESTORE CORRECTIF : RESTORE
2017 sauvegarde HEADERONLY pour une HEADERONLY, instruction
sauvegarde compressée pour une sauvegarde
TDE lente à se terminer compressée TDE lente à se
dans SQL Server terminer dans SQL Server
Mise à jour cumulative 8
pour SQL Server 2017
pour SQL Server 2016 SP2
SQL Server 2016 Restauration & Échec de la compression du CORRECTIF : Échec de la

sauvegarde fichier de sauvegarde compression du fichier de
lorsque l’option INIT et sauvegarde lorsque l’option
COMPRESSION est utilisée INIT et COMPRESSION est
dans une base de données utilisée dans une base de
TDE données TDE dans SQL
Server 2016
pour SQL Server 2016 RTM
CU 4 pour SQL Server 2016
SP1
SQL Server 2016 Restauration & Échec de l’assertion lors de

sauvegarde la backing up large TDE Mise à jour cumulative 4
encrypted database in SQL pour SQL Server 2016 SP1
Server
SQL Server 2016 Restauration & La restauration échoue CORRECTIF : La

sauvegarde lorsque vous sauvegardez à restauration échoue lorsque
l’aide de la compression et vous sauvegardez à l’aide
de la reprise de contrôle sur de la compression et de la
une base de données TDE reprise de contrôle sur une
base de données TDE dans
SQL Server 2016
SQL Server 2016 Restauration & Erreur 9004 lorsque vous CORRECTIF : Erreur 9004
sauvegarde essayez de restaurer une lorsque vous essayez de
sauvegarde compressée à restaurer une sauvegarde
partir de plusieurs fichiers compressée à partir de
pour une base de données plusieurs fichiers pour un
TDE de grande taille dans grand chiffrement TDE
SQL Server Mise à jour cumulative 7
SQL Server 2016SQL Server Restauration & Performances de KB4088193 - CORRECTIF :

2017 sauvegarde restauration lentes lorsque performances de
vous restituer une restauration lentes lors de
sauvegarde à l’aide de la la restauration d’une
compression sur un secteur sauvegarde compressée sur
4 K dans SQL Server un disque avec une taille de
secteur de 4 Ko SQL Server
SQL Server 2016SQL Server Restauration & La restauration d’une Mise à jour cumulative 7
2017 sauvegarde [VDI] sauvegarde compressée pour SQL Server 2017
TDE échoue lors de Mise à jour cumulative 1
l’utilisation du client VDI pour SQL Server 2016 SP2
SQL Server 2016SQL Server Restauration & La restauration d’une base

2017 sauvegarde [VDI] de données compressée par Mise à jour cumulative 8
sauvegarde et TDE via SQL Server 2017 [bogue
l’interface VDI échoue et VSTS # 10936552]
renvoie l’erreur du système SQL Server 2016 SP2 RTM
d’exploitation 38 [bogue VSTS # 10698847]
SQL Server 2016SQL Server Restauration & La sauvegarde de la base de CORRECTIF : la sauvegarde
2017 sauvegarde [VSS] données de disponibilité par de la base de données de
le biais d’une application disponibilité via une
basée sur VSS peut échouer application basée sur VSS
SQL Server peut échouer SQL Server
SQL Server 2016SQL Server Restauration & La sauvegarde et la La sauvegarde et la

2017 sauvegarde restauration TDE sont restauration activées pour
lentes si la clé de TDE sont lentes si la clé de
chiffrement est stockée chiffrement est stockée
dans un fournisseur EKM dans EKM
dans SQL Server Mise à jour cumulative 8
Service Pack 2
Service Pack 1
SQL Server 2016SQL Server Always On AG Les requêtes qui récupèrent CORRECTIF : les requêtes
2017 Columnstore des données à l’aide de la de récupération de données
recherche d’index non utilisant la recherche d’index
cluster prennent plus de non en cluster prennent
temps beaucoup plus de temps
dans SQL Server
Service Pack 1
SQL Server 2016SQL Server Always On AG La réplication parallèle dans CORRECTIF : Le

2017 un réplica secondaire d’un redéployage parallèle dans
groupe de disponibilité qui un réplica secondaire d’un
contient des tables de tas groupe de disponibilité qui
génère un vidage contient des tables de tas
d’affirmation d’exécution ou génère un vidage
le serveur qui exécute SQL d’affirmation d’runtime ou
Server se crashe et renvoie le SQL Server se crashe
une erreur de violation avec une erreur de violation
d’accès d’accès
SQL Server 2016 Always On AG L’assertion se produit CORRECTIF : l’assertion se

lorsque vous utilisez le produit lorsque vous utilisez
redoe parallèle dans un le redoe parallèle dans un
réplica secondaire d’SQL réplica secondaire d’SQL
Server groupe de Server groupe de
disponibilité AlwaysOn disponibilité AlwaysOn
SQL Server 2016SQL Server Always On AG Les performances sont CORRECTIF : Ag Toujours en
2017 lentes pour une ag always cours lent lors du
on lorsque vous traiterez traitement d’une requête de
une requête de lecture lecture dans SQL Server
SQL Server 2017 Always On AG Amélioration de la Amélioration de la

réduction de la durée du réduction de la durée du
failover pour un groupe de failover pour un groupe de
disponibilité dans SQL disponibilité dans SQL
Server sur Linux Server sur Linux
SQL Server 2017 Always On AG Améliorations apportées Améliorations apportées

aux groupes de disponibilité aux groupes de disponibilité
Always On sur un cluster Always On sur un cluster
pacemaker dans SQL Server pacemaker dans SQL Server
SQL Server 2016 Mémoire Le redéoyyment parallèle CORRECTIF : Le

entraîne une utilisation redéparateur parallèle
élevée de la mémoire entraîne une utilisation
élevée de la mémoire dans
SQL Server 2016 par
rapport à SQL Server 2014
ou versions antérieures
SQL Server 2016SQL Server Mémoire sp_execute_external_script CORRECTIF : les procédures

2017 et DMV provoquent stockées
sys.dm_exec_cached_plans sp_execute_external_script
fuites de mémoire système et les
sys.dm_exec_cached_plans
DMV provoquent des fuites
de mémoire SQL Server
2017 et 2016
SQL Server 2016SQL Server Mémoire Erreur de mémoire hors Erreur de mémoire en
2017 mémoire lorsque l’espace mémoire lorsque l’espace
d’adressa visite virtuel du d’adressa SQL Server virtuel
processus SQL Server est du processus est faible en
faible SQL Server
SQL Server 2016 Mémoire Une fuite de mémoire se Une fuite de mémoire se
produit lorsque vous utilisez produit lorsque vous utilisez
stockage Azure dans SQL stockage Azure dans SQL
Server Server 2014 ou 2016
SQL Server 2016SQL Server OLTP en mémoire Utilisation de points de CORRECTIF : une utilisation
2017 contrôle disque importants importante du point de
pour un groupe de fichiers contrôle de disque se
optimisé en mémoire produit pour In-Memory
groupe de fichiers optimisé
lors de charges de travail
importantes non en
mémoire
SQL Server 2016 OLTP en mémoire Les fichiers de point de CORRECTIF : les fichiers de
contrôle se développent de point de contrôle se
manière excessive lorsque développent de manière
vous insérez des données excessive lorsque vous
dans des tables optimisées insérez des données dans
pour la mémoire des tables optimisées pour
la mémoire SQL Server
2016
SQL Server 2016SQL Server OLTP en mémoire La récupération de la base La récupération d’une base
2017 de données prend de données avec des tables
beaucoup de temps optimisées pour la mémoire
lorsqu’elle contient des prend beaucoup de temps
tables optimisées pour la SQL Server 2017 et 2016
mémoire Mise à jour cumulative 4
SQL Server 2016SQL Server tempdb Amélioration de l’algorithme Amélioration de l’algorithme

2017 de tour robin de page PFS de tour robin de page PFS
SQL Server 2016
SQL Server 2016SQL Server tempdb Les problèmes de Des problèmes de

2017 performances se produisent performances se produisent
sous la forme sous la forme de
PAGELATCH_EX et PAGELATCH_EX et
PAGELATCH_SH attentes PAGELATCH_SH d’attente
dans Mise à jour cumulative 1
TempDB(sys.sysobjvalues et pour SQL Server 2016
sys.sysseobjvalues) Service Pack 2
Service Pack 1
SQL Server 2016SQL Server tempdb Modification de table Une contention tempdb
2017 tempdb contentionTemp importante se produit SQL
lourde qui a des contraintes Server 2016 ou 2017
nommées nécessite une Mise à jour cumulative 5
drop synchrone de la table SQL Server 2017
temp Mise à jour cumulative 8
SQL Server 2017 tempdb PAGELATCH_EX contentions CORRECTIF :

lorsque vous supprimez des PAGELATCH_EX contentions
objets temporaires lors de la suppression
(sys.sysobjvalues) d’objets temporaires dans
SQL Server
SQL Server 2017
SQL Server 2016 tempdb Augmentation CORRECTIF : augmentation

PAGELATCH_EX contentions PAGELATCH_EX contentions
dans les sys.sysobjvalues dans sys.sys'objvalues SQL
Server 2016
Service Pack 1
SQL Server 2016SQL Server tempdb Les points de contrôle CORRECTIF : Les points de
2017 indirects sur la base de contrôle indirects sur la
données tempdb base de données tempdb
provoquent l’erreur « provoquent l’erreur «
Programmeur non rapport Programmeur non
de rendement » réparateur de rendement »
dans SQL Server 2017 et
2016
Service Pack 1
SQL Server 2016SQL Server tempdb Les charges de travail qui Les charges de travail qui
2017 utilisent de nombreuses utilisent de nombreuses
transactions fréquentes et transactions fréquentes et
courtes peuvent courtes dans SQL Server
consommer plus d’UC 2017 et 2016 peuvent
consommer plus d’UC
qu’SQL Server 2014
SQL Server 2016SQL Server Journal des transactions Erreur 9002 en l’absence KB4087406 - CORRECTIF :
2017 d’espace disque suffisant Erreur 9002 en l’absence
pour la croissance critique d’espace disque suffisant
des journaux pour la croissance critique
des journaux dans SQL
Server 2014, 2016 et 2017
SQL Server 2017
SQL Server 2016 Cache de sécurité Une utilisation élevée du KB3195888 - CORRECTIF :
processeur entraîne des une utilisation élevée du
problèmes de performances processeur entraîne des
dans SQL Server 2016 High problèmes de performances
spinlock contention for SQL Server 2016 et 2017
SECURITY_CACHE and Mise à jour cumulative 2
CMED_HASH_SET SQLS pour SQL Server 2016
cumulative 16!, Épisode 8 :
Comment la mise à jour
cumulative 2 de SQL Server
2016 (CU2) peut améliorer
les performances des
charges de travail
hautement simultanées
SQL Server 2017 Magasin de requêtes Une violation d’accès se Violation d’accès lorsque le
produit lorsque le magasin Magasin de requêtes
de requêtes collecte des collecte des statistiques
statistiques d’runtime d’SQL Server 2017
SQL Server 2017
SQL Server 2016 Magasin de requêtes Échec du nettoyage Échec du nettoyage

automatique des données automatique des données
du Magasin de requêtes sur du magasin de requêtes sur
les éditions autres que les éditions autres que
Enterprise et Developer Enterprise et Developer de
SQL Server 2016
SQL Server 2016 Magasin de requêtes Performances ralenties du KB4340759 - CORRECTIF :

SQL Server lorsque le performances lentes SQL
magasin de requêtes est Server 2016 lorsque le
activé magasin de requêtes est
activé
Tableau 5 : Améliorations recommandées, correctifs et instructions de

configuration pour SQL Server dans un environnement Linux
Ce tableau est une compilation de toutes les principales améliorations, recommandations et modifications de
code qui ont été publiées dans les mises à jour cumulatives après la publication SQL Server 2017. Examinez la
description dans la colonne Symptômes et appliquez les mises à jour requises (de préférence la dernière mise à
jour contenant le correctif spécifique) dans la colonne Mise à jour requise dans les environnements applicables.
Vous pouvez consulter l’article de la Base de connaissances répertorié pour plus d’informations sur les
problèmes respectifs.
Ces recommandations ne vous obligent pas à activer des indicateurs de suivi supplémentaires en tant que
paramètres de démarrage, sauf si elles sont explicitement appelées dans l’article ou dans ce tableau. Il suffit
d’appliquer la dernière mise à jour cumulative ou service pack qui inclut ces correctifs pour en tirer parti. Si vous
utilisez le groupe de disponibilité AlwaysOn dans SQL Server sur Linux, mettez à niveau SQL Server 2017 vers
la mise à jour cumulative 8 ou une version supérieure, car plusieurs améliorations ont été apportées à cette
mise à jour. Remarque Le nom de la mise à jour cumulative dans la colonne Mise à jour requise fournit la
première mise à jour cumulative SQL Server résoudre ce problème. Une mise à jour cumulative contient tous
les correctifs logiciels et toutes les mises à jour incluses dans la version précédente SQL Server mise à jour.
Comme indiqué dans les mises à jour du modèle de maintenance incrémentielle SQL Server,nous vous
recommandons maintenant d’installer la dernière mise à jour cumulative dans une cadence proactive continue
pour résoudre ou empêcher les problèmes décrits. Notez également que depuis SQL Server 2017, le modèle de
maintenance moderne pour SQL Server a été introduit afin que les Service Packs ne soient plus disponibles.
RÉSUM É DES C H A N GEM EN T S O U A M ÉL IO RAT IO N S IN F O RM AT IO N S ET RÉF ÉREN C ES SUP P L ÉM EN TA IRES
SQL système d’exploitation : passer en revue les Recommandations en matière de performances et

différentes recommandations de meilleures pratiques pour le recommandations en matière de configuration SQL Server
système d’exploitation et les SQL Server lors du déploiement sur Linux
SQL Server sur Linux
SQL Agent Amélioration : les travaux SQL Server’agent SQL Server Les travaux de l’agent peuvent démarrer sans
peuvent démarrer sans attendre la récupération de toutes attendre la récupération de toutes les bases de données SQL
les bases de données Server 2017 sur Linux
Mise à jour cumulative 9 pour SQL Server 2017
Stockage Amélioration : activer le mécanisme de « purge Activer le mécanisme de purge forcée dans SQL Server 2017
forcée » SQL Server 2017 sur Linux
Stockage Amélioration : déplacer la base de données KB4053439 - Amélioration : déplacer la base de données
principale et le fichier journal des erreurs vers un autre principale et le fichier journal des erreurs vers un autre
emplacement emplacement dans SQL Server 2017 sur Linux
AG Amélioration : améliorations pour les groupes de KB4339875 : améliorations pour les groupes de disponibilité
disponibilité Always On sur un cluster pacemaker dans SQL Always On sur un cluster pacemaker dans SQL Server
Server Mise à jour cumulative 8 pour SQL Server 2017
Mémoire Amélioration : limite de mémoire minimale définie KB4052969 - CORRECTIF : limite de mémoire minimale
sur 2 Go pour l’installation ou le démarrage SQL Server définie sur 2 Go pour installer ou démarrer SQL Server 2017
Mémoire CORRECTIF : la phase de montée en puissance de KB4075203 - CORRECTIF : la phase de montée en puissance
mémoire est trop longue après l’activé TF 834 de la mémoire est trop longue une fois le TF 834 activé dans
SQL Server 2017 sur Linux
Planification CORRECTIF : La portabilité et les KB4043455 - CORRECTIF : portabilité et performances

performances diffèrent entre Windows et les mappages de diffèrent entre les mappages de Windows et de planification
planification Linux dans SQL Server 2017 Linux dans SQL Server 2017
Th AD CORRECTIF : Can’t create a login based on a user KB4073670 - CORRECTIF : Can’t create a login based on a
that belongs to the parent domain user that belongs to the parent domain in SQL Server 2017
on Linux
Th AD Mise à jour : améliore les SQL serveur en limitant le KB4463314 - La mise à jour améliore SQL performances du
KDC qui peut être contacté sur des réseaux serveur en limitant le KDC qui peut être contacté sur des
géographiquement importants réseaux géographiquement importants
Th AD CORRECTIF : SQL Server se crashe lorsque vous KB4466962 - CORRECTIF : SQL Server 2017 lorsque vous
utilisez des fournisseurs Active Directory tiers utilisez des fournisseurs Active Directory tiers
TSQL CORRECTIF : la fonction NEWSEQUENTIALID génère KB4078097 - CORRECTIF : la fonction NEWSEQUENTIALID

un GUID en double après SQL Server redémarrage génère un GUID en double après le redémarrage SQL Server
2017 sur Linux
Connexions CORRECTIF : Consommation de mémoire KB4073045 - CORRECTIF : consommation de mémoire

inattendue lors de l’utilisation de connexions de protocole inattendue lorsque des connexions au protocole TCP sont
TCP utilisées pour SQL Server 2017 sur Linux
Connexions CORRECTIF : Une erreur de résolution de nom KB4053392 - CORRECTIF : une erreur de résolution de nom
se produit lorsque IPv6 est désactivé au démarrage se produit lorsque IPv6 est désactivé au démarrage dans
SQL Server 2017 sur Linux
Connexions CORRECTIF : SQL Server n’écoute pas l’adresse KB4053393 - CORRECTIF : SQL Server 2017 sur Linux
IP non parefault spécifiée par le script mssql-conf n’écoute pas l’adresse IP non parefault spécifiée par le script
mssql-conf
Installation CORRECTIF : échecs de mise à niveau de script Erreurs lors de la mise SQL Server cu4 2017 ou ultérieure et
lors de l’application de la mise à jour un jour l’activation de SQL Agent sur Linux
Messagerie de base de données CORRECTIF : Le KB4100873 - CORRECTIF : Le courrier de base de données

courrier de base de données ne peut pas se connecter SQL ne peut pas se connecter à SQL Server 2017 sur Linux
Server lorsque le port TCP non par défaut est utilisé lorsque le port TCP non par défaut est utilisé
Conteneur CORRECTIF : Can’t stop the SQL Server Linux KB4093805 - CORRECTIF : can’t stop the SQL Server Linux
Docker container by using the « docker stop » command Docker container by using the « docker stop » command
Mise à jour cumulative 5 SQL Server 2017
Conteneur CORRECTIF : Erreur de mémoire en mémoire KB4347055 - CORRECTIF : Erreur de mémoire lorsque vous
lorsque vous exécutez une SQL Server dans un conteneur exécutez SQL Server 2017 dans un conteneur Docker Linux
Docker Linux Mise à jour cumulative 10 pour SQL Server 2017
AG : si vous utilisez le package Pacemaker 1.1.18-11.el7 ou KB4229789 - Mise à jour cumulative 7 SQL Server 2017
une valeur supérieure, ajustez la propriété start-failure-is- Voir la section Notice du pacemaker
fatal
AG CORRECTIF : le pacemaker peut éliminer les processus KB4460203 - CORRECTIF : pacemaker peut éliminer les
de l’agent de ressources lorsque l’opération est à l’attente processus d’agent de ressources lorsque l’opération est SQL
Server groupe de disponibilité AlwaysOn 2017
AG CORRECTIF : deux SQL Server instances sont le réplica KB4316791 - CORRECTIF : deux instances SQL Server sont
principal d’un groupe de disponibilité le réplica principal d’un groupe de disponibilité dans SQL
Server
AG CORRECTIF : Unover inutile lorsque vous utilisez le KB4056922 - CORRECTIF : échec inutile lorsque vous utilisez
groupe de disponibilité AlwaysOn le groupe de disponibilité AlwaysOn dans SQL Server 2017
sur Linux
AG CORRECTIF : le pacemaker rétrograde le réplica principal KB4076982 - CORRECTIF : Pacemaker rétrograde le réplica
existant d’une ag AlwaysOn et n’en promeut jamais un principal existant d’une ag AlwaysOn dans SQL Server 2017
nouveau sur Linux et n’en promeut jamais un nouveau
AG CORRECTIF : pacemaker promeut un réplica KB4091722 - FIX : Pacemaker promeut un réplica

nonynchronisé au principal lorsque vous utilisez AlwaysOn nonynchronisé au principal lorsque vous utilisez AlwaysOn
AG AG dans SQL Server 2017 sur Linux
AG CORRECTIF : La promotion du réplica local en réplica KB4230542 - CORRECTIF : la promotion du réplica local par
principal échoue lors de l’utilisation de AlwaysOn AG le réplica principal échoue lors de l’utilisation de AlwaysOn
AG dans SQL Server 2017
AG CORRECTIF : le démarrage d’une base de données KB4316790 - CORRECTIF : le démarrage d’une base de
appartenant à un groupe de disponibilité a un temps données appartenant à un groupe de disponibilité est SQL
d’attente Server sur Linux
AG CORRECTIF : Des changements inutiles se produisent KB4316793 - CORRECTIF : des changements inutiles se
lorsqu’une instance de cluster de SQL Server ou always on produisent lorsqu’une instance de cluster de SQL Server
AG est gérée par pacemaker 2017 ou always on ag est gérée par Pacemaker
Dégradation des performances lors de la mise à
niveau du niveau de compatibilité des bases de
données de 120 à 130
Cet article vous aide à résoudre le problème qui se produit lors de la mise à niveau du niveau de compatibilité
de base de données de 120 à 130.
Version du produit d’origine : SQL Server 2016, SQL Server 2017 sur Windows (toutes les éditions)
Résumé
Vous exécutez une requête spatiale à l’aide d’un filtre avec une fonction telle que STIntersects SQL Server
2016 ou SQL Server 2017 sur Windows.
Le niveau de compatibilité des bases de données est de 120.
La requête utilise un plan d’exécution parallèle.
Vous devez mettre à niveau le niveau de compatibilité de base de données vers 130 et le plan d’exécution est
devenu parallèle à série.
Dans ce scénario, vous risquez de dégrader les performances si la requête renvoie un jeu de résultats important.
Résolution
Pour résoudre ce problème, essayez l’une des méthodes suivantes :
Revenir à votre niveau de compatibilité de base de données à 120. Lorsque vous faites cela, vous ne
pourrez pas bénéficier de certaines des fonctionnalités disponibles dans SQL Server 2016 ou SQL Server
2017 sur Windows sous le niveau de compatibilité de base de données 130. Toutefois, vous serez
toujours en mesure de réaliser de nombreuses améliorations qui ne sont pas liées au niveau de
compatibilité des bases de données, par exemple, une amélioration globale des performances des
opérations de requête avec des types de données spatiales.
Pour obtenir la liste des améliorations SQL Server 2016 qui nécessitent le niveau de compatibilité de
base de données 130, voir ALTER DATABASE (Transact-SQL) Compatibility Level.
Forcez le plan généré avec le niveau de compatibilité de base de données 120 s’il offre de meilleures
performances. Vous pouvez forcer ce plan lors de l’exécution avec le niveau de compatibilité de base de
données 130 à l’aide de USE PLAN l’indication de requête. Pour plus d’informations sur l’utilisation des
conseils, voir Hints (Transact-SQL) - Query.
Vous pouvez également utiliser le magasin de requêtes pour identifier et corriger des choix de plan
spécifiques. Pour plus d’informations sur l’utilisation du magasin de requêtes à cet effet, voir Scénarios
d’utilisation du magasin de requêtes.
SQL Server niveaux de compatibilité de base de données 120 et 130 utilisent différentes approches pour
estimer la cardinalité des prédicats, où une fonction définie par l’utilisateur scalante ou une fonction T-SQL
particulière (telle que STIntersects) est comparée à une constante.
Bien que le modèle de coût utilisé par le niveau de compatibilité des bases de données 130 génère des gains de
performances pour de nombreuses charges de travail par rapport au niveau 120, pour certaines requêtes (en
fonction des données et des fonctions utilisées), les performances des plans de requête peuvent diminuer au
niveau 130.
S’applique à
SQL Server 2016 Service Pack 1
SQL Server Web 2016
Utilisez la commande DBCC MEMORYSTATUS pour
surveiller l’utilisation de la mémoire SQL Server
Cet article explique comment utiliser la commande DBCC MEMORYSTATUS pour surveiller l’utilisation de la
mémoire.
Résumé
Cet article traite de la sortie de la DBCC MEMORYSTATUS commande. Cette commande est fréquemment utilisée
pour résoudre Microsoft SQL Server problèmes de consommation de mémoire.
Cet article décrit les éléments de la sortie pour le Gestionnaire de mémoire, pour le résumé de l’utilisation de la
mémoire, pour les informations sur la mémoire agrégée, pour les informations de distribution de mémoire
tampon, pour les informations sur le pool de mémoire tampon et pour les informations de cache de procédure.
Il décrit également la sortie sur les objets mémoire globaux, sur les objets mémoire de requête, sur
l’optimisation et sur les courtiers de mémoire.
Introduction
La DBCC MEMORYSTATUS commande fournit un instantané de l’état actuel de la SQL Server. Vous pouvez utiliser la
sortie de cette commande pour résoudre les problèmes de consommation de mémoire dans SQL Server ou
pour résoudre des erreurs spécifiques de mémoire. (De nombreuses erreurs de mémoire inserrable impriment
automatiquement cette sortie dans le journal des erreurs.) Les services de support technique Microsoft peuvent
également vous demander d’exécuter cette commande au cours d’un incident de support spécifique si vous
rencontrez une erreur qui peut être associée à une condition de mémoire faible.
NOTE
L’Moniteur de performances (PerfMon) et le Gestionnaire des tâches ne sont pas correctement responsables de la
mémoire si la prise en charge des extensions de fenêtre d’adresse (AWE) est activée.
Cet article décrit certaines des données que vous pouvez obtenir à partir de la sortie de la DBCC MEMORYSTATUS
commande. Plusieurs sections de cet article incluent des détails d’implémentation propriétaires qui ne sont pas
expliqués ici. Les services de support technique Microsoft ne répondent à aucune question ou ne fournissent
pas plus d’informations sur la signification de compteurs spécifiques au-delà des informations fournies dans cet
article.
IMPORTANT
La commande est destinée à être un outil de diagnostic pour les services de support DBCC MEMORYSTATUS technique
Microsoft. Le format de la sortie et le niveau de détail fourni sont sujets à des changements entre les Service Packs et les
lancements de produits. La fonctionnalité que fournit la commande peut être remplacée par un DBCC MEMORYSTATUS
mécanisme différent dans les versions ultérieures du produit. Par conséquent, dans les versions ultérieures du produit,
cette commande peut ne plus fonctionner. Aucun avertissement supplémentaire n’est effectué avant que cette commande
ne soit modifiée ou supprimée. Par conséquent, les applications qui utilisent cette commande peuvent se rompre sans
avertissement.
La sortie de la DBCC MEMORYSTATUS commande a changé par rapport aux précédentes SQL Server. La sortie
contient maintenant plusieurs sections qui n’étaient pas disponibles dans les versions antérieures du produit.
Gestionnaire de mémoire
La première section de la sortie est le Gestionnaire de mémoire. Cette section indique la consommation globale
de mémoire par SQL Server.
Memory Manager KB
------------------------------ --------------------
VM Reserved 1761400
VM Committed 1663556
AWE Allocated 0
Reserved Memory 1024
Reserved Memory In Use 0
(5 row(s) affected)
Les éléments de cette section sont les suivants :

VM Reserved : cette valeur indique la quantité globale d’espace d’adressas virtuel (VAS) SQL Server réservé.
VM Committed: This value shows the overall amount of VAS that SQL Server has committed. La mémoire
d’intégrité de la mémoire (VAS) qui est engagé a été associée à la mémoire physique.
AWE alloué : cette valeur indique la quantité globale de mémoire allouée via le mécanisme AWE sur la
version 32 bits de SQL Server. Sinon, cette valeur indique la quantité globale de mémoire consommée par les
pages verrouillées sur la version 64 bits du produit.
Mémoire réservée : cette valeur indique la mémoire réservée à la connexion d’administrateur dédiée.
Mémoire réservée en cours d’utilisation : cette valeur indique la mémoire réservée utilisée.
Résumé de l’utilisation de la mémoire

La section Gestionnaire de mémoire est suivie d’un résumé de l’utilisation de la mémoire pour chaque nœud
mémoire. Dans un système NUMA (Non-uniform Memory Access) activé, il y aura une entrée de nœud
Mémoire correspondante pour chaque nœud NUMA matériel. Dans un système SMP, il y aura une seule entrée
de nœud Mémoire.
NOTE
L’ID du nœud mémoire peut ne pas correspondre à l’ID du nœud matériel.
Memory node Id = 0 KB
------------------------------ --------------------
VM Reserved 1757304
VM Committed 1659612
AWE Allocated 0
MultiPage Allocator 10760
SinglePage Allocator 73832
(5 row(s) affected)
NOTE
Ces valeurs indiquent la mémoire allouée par les threads qui s’exécutent sur ce nœud NUMA. Ces valeurs ne sont pas la
mémoire locale du nœud NUMA.

VM Reserved : cette valeur affiche le VAS qui est réservé par les threads qui s’exécutent sur ce nœud.
VM Committed : cette valeur indique le VAS qui est engagé par des threads qui s’exécutent sur ce nœud.
AWE alloué : cette valeur indique la mémoire allouée via le mécanisme AWE sur la version 32 bits du
produit. Sinon, cette valeur indique la quantité globale de mémoire consommée par les pages
verrouillées sur la version 64 bits du produit.
Dans un système NUMA, cette valeur peut être incorrecte ou négative. Toutefois, la valeur globale allouée
AWE dans la section Gestionnaire de mémoire est une valeur correcte. Pour suivre la mémoire allouée par
des nœuds NUMA individuels, utilisez SQL Server : objets de performances de nœud de mémoire
tampon. (Pour plus d’informations, voir SQL Server Books Online.)
Alloueur MultiPage : cette valeur affiche la mémoire allouée via l’allocation multipage par les threads qui
s’exécutent sur ce nœud. Cette mémoire provient de l’extérieur du pool de mémoires tampons.
Alloueur SinglePage : cette valeur affiche la mémoire allouée via l’allocation de page unique par les
threads qui s’exécutent sur ce nœud. Cette mémoire est volée du pool de mémoires tampons.
NOTE
Les sommes des valeurs réservées de l’VM et des valeurs de mémoire réservées de l’VM sur tous les nodes mémoire
seront légèrement inférieures aux valeurs correspondantes qui sont signalées dans la section Gestionnaire de mémoire.
Mémoire agrégée
La section suivante contient les informations de mémoire agrégées pour chaque type d’employé et pour chaque
nœud NUMA. Pour un système NUMA, vous pouvez voir une sortie similaire à celle-ci.
NOTE
Le tableau suivant ne contient qu’une partie de la sortie.
MEMORYCLERK_SQLGENERAL (node 0) KB
---------------------------------------------------------------- --------------------
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
(7 row(s) affected)
MEMORYCLERK_SQLGENERAL (node 1) KB
---------------------------------------------------------------- --------------------
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
(7 row(s) affected)
MEMORYCLERK_SQLGENERAL (Total) KB
---------------------------------------------------------------- --------------------
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
(7 row(s) affected)
NOTE
Ces ID de nœud correspondent à la configuration du nœud NUMA de l’ordinateur qui exécute SQL Server. Les ID de
nœud incluent les nœuds NUMA logiciels possibles qui sont définis sur les nœuds NUMA matériels ou sur un système
SMP. Pour rechercher le mappage entre les ID de nœud et les processeurs pour chaque nœud, affichez l’ID d’événement
Information 17152. Cet événement est consigné dans le journal des applications dans l’Observateur d’événements
lorsque vous démarrez SQL Server.
Pour un système SMP, vous ne verrez qu’une seule section pour chaque type d’employé. Cette section est
similaire à la suivante.
MEMORYCLERK_SQLGENERAL (Total) KB
---------------------------------------------------------------- --------------------
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
(7 row(s) affected)
Les autres informations de ces sections sont sur la mémoire partagée :

SM réservé : cette valeur affiche le VAS qui est réservé par tous les employés de ce type qui utilisent l’API
de fichiers mappés en mémoire. Cette API est également appelée mémoire partagée.
SM Committed : cette valeur indique le VAS qui est engagé par tous les employés de ce type qui utilisent
l’API de fichiers mappés en mémoire.
Vous pouvez obtenir des informations récapitulatifs pour chaque type d’employé pour tous les nodes mémoire à
l’aide des sys. dm_os_memory_clerks affichage de gestion dynamique (DMV). Pour ce faire, exécutez la requête
suivante :
select
type,
sum(virtual_memory_reserved_kb) as [VM Reserved],
sum(virtual_memory_committed_kb) as [VM Committed],
sum(awe_allocated_kb) as [AWE Allocated],
sum(shared_memory_reserved_kb) as [SM Reserved],
sum(shared_memory_committed_kb) as [SM Committed],
sum(multi_pages_kb) as [MultiPage Allocator],
sum(single_pages_kb) as [SinlgePage Allocator]
from
sys.dm_os_memory_clerks
group by type
Distribution des mémoires tampons

La section suivante montre la distribution de mémoires tampons de 8 kilo-octets (Ko) dans le pool de mémoires
tampons.
Buffer Distribution Buffers

------------------------------ -----------
Stolen 553
Free 103
Cached 161
Database (clean) 1353
Database (dirty) 38
I/O 0
Latched 0
(7 row(s) affected)

Volé : la mémoire volée décrit les mémoires tampons de 8 Ko que le serveur utilise à divers fins. Ces
mémoires tampons servent d’allocations de magasin de mémoire génériques. Différents composants du
serveur utilisent ces mémoires tampons pour stocker les structures de données internes. Le processus
lazywriter n’est pas autorisé à vider les mémoires tampons volées du pool de mémoires tampons.
Gratuit : cette valeur affiche les mémoires tampons en cours d’utilisation qui ne sont pas utilisées. Ces
mémoires tampons sont disponibles pour la gestion des données. D’autres composants peuvent
également demander ces mémoires tampons, puis marquer ces mémoires tampons comme volées.
Mis en cache : cette valeur affiche les mémoires tampons utilisées pour différents caches.
Base de données (propre) : cette valeur affiche les mémoires tampons qui ont du contenu de base de
données et qui n’ont pas été modifiées.
Base de données (dirty) : cette valeur affiche les mémoires tampons qui ont du contenu de base de
données et qui ont été modifiées. Ces mémoires tampons contiennent des modifications qui doivent être
vidées sur le disque.
O/S : cette valeur affiche les mémoires tampons en attente d’une opération d’opérations d’exploitation en
attente.
Verrous verrouillés : cette valeur affiche les mémoires tampons verrouillées. Une mémoire tampon est
verrouillée lorsqu’un thread lit ou modifie le contenu d’une page. Une mémoire tampon est également
verrouillée lorsque la page est lue à partir du disque ou écrite sur le disque. Un verrou est utilisé pour
maintenir la cohérence physique des données dans la page pendant qu’elle est en cours de lecture ou de
modification. Un verrou est utilisé pour maintenir la cohérence logique et transactionnelle.
Détails du pool de mémoires tampons

Vous pouvez obtenir des informations détaillées sur les mémoires tampons de pool de mémoires tampons pour
les pages de base de données à l’aide du sys.dm_os_buffer_descriptors DMV. Vous pouvez également obtenir
des informations détaillées sur les pages de pool de mémoires tampons utilisées à diverses fins de serveur à
l’aide de sys.dm_os_memory_clerks la DMV.
La section suivante répertorie les détails sur le pool de mémoires tampons, ainsi que des informations
supplémentaires.
Buffer Counts Buffers

------------------------------ --------------------
Committed 1064
Target 17551
Hashed 345
Stolen Potential 121857
External Reservation 645
Min Free 64
Visible 17551
Available Paging File 451997
(8 row(s) affected)

Committed: This value shows the total buffers that are committed. La mémoire physique associée aux
tampons qui sont engagés est associée. La valeur committed est la taille actuelle du pool de mémoires
tampons. Cette valeur inclut la mémoire physique allouée si la prise en charge AWE est activée.
Cible : cette valeur indique la taille cible du pool de mémoires tampons. Si la valeur cible est supérieure à la
valeur committed, le pool de mémoires tampons augmente. Si la valeur cible est inférieure à la valeur
committed, le pool de mémoires tampons est réduit.
Hachage : cette valeur affiche les pages de données et les pages d’index stockées dans le pool de mémoires
tampons.
Potentiel volé : cette valeur indique le nombre maximal de pages qui peuvent être volées du pool de
mémoires tampons.
ExternalReservation : cette valeur affiche les pages qui ont été réservées pour les requêtes qui effectueront
une opération de tri ou une opération de hachage. Ces pages n’ont pas encore été volées.
Min Free : cette valeur affiche les pages que le pool de mémoires tampons tente d’avoir dans la liste gratuite.
Visible : cette valeur affiche les mémoires tampons qui sont visibles simultanément. Ces mémoires tampons
sont accessibles directement en même temps. Cette valeur est égale au nombre total de mémoires tampons.
Toutefois, lorsque la prise en charge AWE est activée, cette valeur peut être inférieure au nombre total de
mémoires tampons.
Fichier d’pagination disponible : cette valeur indique la mémoire disponible pour la engagement. Cette valeur
est exprimée en tant que nombre de mémoires tampons de 8 Ko. Pour plus d’informations, voir la rubrique
relative à la fonction GlobalMemor yStatusEx dans la documentation Windows API.
Cache des procédures
La section suivante décrit la composition du cache de procédures.
Procedure Cache Value

------------------------------ -----------
TotalProcs 4
TotalPages 25
InUsePages 0
(3 row(s) affected)

TotalProcs : cette valeur indique le nombre total d’objets mis en cache actuellement dans le cache des
procédures. Cette valeur correspondra aux entrées de sys.dm_exec_cached_plans la DMV.
NOTE
En raison de la nature dynamique de ces informations, la correspondance peut ne pas être exacte. Vous pouvez
utiliser PerfMon pour surveiller l’objet SQL Server: Plan Cache et le DMV pour obtenir des informations détaillées
sur le type d’objets mis en cache, tels que les déclencheurs, les procédures et les objets
sys.dm_exec_cached_plans ad hoc.
TotalPages : cette valeur affiche les pages cumulatives dont vous devez avoir besoin pour stocker tous les
objets mis en cache dans le cache des procédures.
InUsePages : cette valeur affiche les pages du cache de procédures qui appartiennent aux procédures en
cours d’exécution. Ces pages ne peuvent pas être ignorées.
Objets mémoire globaux

La section suivante contient des informations sur différents objets mémoire globaux. Cette section contient
également des informations sur la quantité de mémoire que les objets mémoire globaux utilisent.
Global Memory Objects Buffers

------------------------------ --------------------
Resource 126
Locks 85
XDES 10
SETLS 2
SE Dataset Allocators 4
SubpDesc Allocators 2
SE SchemaManager 44
SQLCache 41
Replication 2
ServerGlobal 25
XP Global 2
SortTables 2
(12 row(s) affected)

Ressource : cette valeur indique la mémoire que l’objet Resource utilise. L’objet Resource est utilisé par le
moteur de stockage et pour diverses structures à l’échelle du serveur.
Verrous : cette valeur indique la mémoire que le Gestionnaire de verrouillage utilise.
XDES : cette valeur indique la mémoire que le Gestionnaire de transactions utilise.
SETLS : cette valeur indique la mémoire utilisée pour allouer la structure par thread spécifique Stockage
moteur qui utilise le stockage local de thread.
SE Alloueurs de jeux de données : cette valeur indique la mémoire utilisée pour allouer des structures pour
l’accès aux tables via le paramètre Méthodes Access.
Allocateurs de sous-projets : cette valeur indique la mémoire utilisée pour la gestion des sous-processus
pour les requêtes parallèles, les opérations de sauvegarde, les opérations de restauration, les opérations de
base de données, les opérations de fichier, la mise en miroir et les curseurs asynchrones. Ces sous-processus
sont également appelés processus parallèles.
SE SchemaManager : cette valeur indique la mémoire que le Gestionnaire de schéma utilise pour stocker
Stockage métadonnées spécifiques au moteur.
SQLCache : cette valeur indique la mémoire utilisée pour stocker le texte des instructions ad hoc et des
instructions préparées.
Réplication : cette valeur indique la mémoire que le serveur utilise pour les sous-systèmes de réplication
interne.
ServerGlobal : cette valeur indique l’objet mémoire serveur global utilisé de manière générique par plusieurs
sous-systèmes.
XP Global : cette valeur indique la mémoire que les procédures stockées étendues utilisent.
Tables de tri : cette valeur indique la mémoire que les tables de tri utilisent.
Interroger des objets mémoire

La section suivante décrit les informations d’octroi de mémoire de requête. Cette section inclut un instantané de
l’utilisation de la mémoire de requête. La mémoire de requête est également appelée mémoire d’espace de
travail.
Query Memory Objects Value

------------------------------ -----------
Grants 0
Waiting 0
Available (Buffers) 14820
Maximum (Buffers) 14820
Limit 10880
Next Request 0
Waiting For 0
Cost 0
Timeout 0
Wait Time 0
Last Target 11520
(11 row(s) affected)
Small Query Memory Objects Value

------------------------------ -----------
Grants 0
Waiting 0
Available (Buffers) 640
Maximum (Buffers) 640
Limit 640
(5 row(s) affected)
Si la taille et le coût d’une requête répondent à des seuils de mémoire de requête « petits », la requête est mise
dans une file d’attente de requêtes de petite taille. Ce comportement empêche les requêtes plus petites d’être
retardées derrière les requêtes plus volumineuses qui sont déjà dans la file d’attente.
Octrois : cette valeur affiche les requêtes en cours d’exécution qui ont des octrois de mémoire.
En attente : cette valeur affiche les requêtes en attente d’octroi de mémoire.
Disponible : cette valeur affiche les mémoires tampons disponibles pour les requêtes à utiliser en tant
qu’espace de travail de hachage et espace de travail de tri. La valeur Disponible est régulièrement mise à jour.
Maximum : cette valeur indique le nombre total de mémoires tampons qui peuvent être données à toutes les
requêtes à utiliser comme espace de travail.
Limite : cette valeur indique la cible d’exécution de requête pour la file d’attente de requête de grande taille.
Cette valeur diffère de la valeur maximale (mémoires tampons), car la valeur maximale (mémoires tampons)
n’est pas mise à jour tant que la file d’attente n’a pas changé.
Requête suivante : cette valeur indique la taille de la demande de mémoire, dans les mémoires tampons,
pour la requête en attente suivante.
En attente : cette valeur indique la quantité de mémoire qui doit être disponible pour exécuter la requête à
laquelle la valeur Requête suivante fait référence. La valeur En attente est la valeur requête suivante
multipliée par un facteur d’espace d’en-tête. Cette valeur garantit effectivement qu’une quantité spécifique de
mémoire sera disponible lors de l’utilisation de la requête en attente suivante.
Coût : cette valeur indique le coût de la requête en attente suivante.
Délai d’attente : cette valeur indique le délai d’attente, en secondes, de la requête en attente suivante.
Temps d’attente : cette valeur indique le temps écoulé, en millisecondes, depuis que la requête en attente
suivante a été mise en file d’attente.
Dernière cible : cette valeur indique la limite de mémoire globale pour l’exécution des requêtes. Cette valeur
est la limite combinée pour la file d’attente de requêtes de grande taille et la file d’attente de requêtes de
petite taille.
Optimisation
La section suivante récapitule les utilisateurs qui tentent d’optimiser les requêtes en même temps.
Optimization Queue Value
------------------------------ --------------------
Overall Memory 156672000
Last Notification 1
Timeout 6
Early Termination Factor 5
(4 row(s) affected)
Small Gateway Value

------------------------------ --------------------
Configured Units 8
Available Units 8
Acquires 0
Waiters 0
Threshold Factor 250000
Threshold 250000
(6 row(s) affected)
Medium Gateway Value

------------------------------ --------------------
Configured Units 2
Available Units 2
Acquires 0
Waiters 0
Threshold Factor 12
(5 row(s) affected)
Big Gateway Value

------------------------------ --------------------
Configured Units 1
Available Units 1
Acquires 0
Waiters 0
Threshold Factor 8
(5 row(s) affected)
Les requêtes sont envoyées au serveur pour compilation. Le processus de compilation inclut l’évaluation,
l’algèbre et l’optimisation. Les requêtes sont classées en fonction de la quantité de mémoire consommée par
chaque requête au cours du processus de compilation.
NOTE
Cette quantité n’inclut pas la mémoire requise pour exécuter la requête.
Lorsqu’une requête démarre, le nombre de requêtes qui peuvent être compilées n’est pas limité. À mesure que
la consommation de mémoire augmente et atteint un seuil, la requête doit transmettre une passerelle pour
continuer. Il existe une limite progressivement décroissante des requêtes compilées simultanément après
chaque passerelle. La taille de chaque passerelle dépend de la plateforme et de la charge. Les tailles de
passerelle sont choisies pour optimiser l’évolutivité et le débit.
Si la requête ne peut pas transmettre de passerelle, elle attend que la mémoire soit disponible. Sinon, la requête
retourne une erreur de délai d’délai (Erreur 8628). En outre, la requête peut ne pas acquérir de passerelle si
l’utilisateur annule la requête ou si un blocage est détecté. Si une requête passe plusieurs passerelles, la requête
ne libère pas les passerelles plus petites tant que le processus de compilation n’est pas terminé.
Ce comportement ne permet que quelques compilations intensives en mémoire en même temps. En outre, ce
comportement optimise le débit pour les requêtes plus petites.
Courtiers de mémoire
Les trois sections suivantes montrent des informations sur les courtiers de mémoire qui contrôlent la mémoire
mise en cache, la mémoire volée et la mémoire réservée. Les informations fournies par ces sections ne peuvent
être utilisées que pour les diagnostics internes. Par conséquent, ces informations ne sont pas détaillées ici.
MEMORYBROKER_FOR_CACHE Value
-------------------------------- --------------------
Allocations 1843
Rate 0
Target Allocations 1843
Future Allocations 0
Last Notification 1
(4 row(s) affected)
MEMORYBROKER_FOR_STEAL Value
-------------------------------- --------------------
Allocations 380
Rate 0
Last Notification 1
(4 row(s) affected)
MEMORYBROKER_FOR_RESERVE Value
-------------------------------- --------------------
Allocations 0
Rate 0
Last Notification 1
(4 row(s) affected)
S’applique à
Les fournisseurs de services en couches Winsock
peuvent entraîner des problèmes de stabilité du
réseau ou du serveur pour SQL Server
Cet article vous aide à résoudre le problème qui se produit lorsque les fournisseurs de services en couches
(LSP) Winsock sont chargés dans SQL Server’espace d’adressame.
Version du produit d’origine : Microsoft SQL Server 2005, SQL Server 2008
Symptômes
Vous remarquez un arrêt ou un arrêt brusque de toutes les communications réseau entre SQL Server et les
applications clientes. Cela peut entraîner SQL Server de réponse et des défaillances de service. Vous pouvez
recevoir des exceptions dont les piles d’appels impliquent la manipulation des structures de données qui sont
conservées ou utilisées par les modules chargés dans l’espace d’adressage SQL Server de données. Ces
problèmes sont généralement suivis de messages d’erreur générés par SQL Server Scheduler, tels que les
erreurs 17883 et 17882.
Cause
Une DLL Winsock LSP peut être chargée dans les processus SQL Server et intercepter et surveiller les
communications réseau (y compris les paquets TDS) au niveau Winsock entre les applications clientes et les SQL
Server. Cela se produit lorsque les agents de surveillance du réseau sont installés sur un ordinateur exécutant
SQL Server et que cet ordinateur est choisi pour surveiller l’utilisation du réseau pour surveiller les compteurs
de performance par un fournisseur de services gérés.
Résolution
Exécutez la commande suivante à partir d’une invite de commandes pour connaître la liste de tous les LSP
Winsock installés sur l’ordinateur qui exécute SQL Server :
Netsh winsock show catalog
Exécutez la requête suivante pour savoir lequel de ces LSP installés est chargé dans SQL Server processus :
SELECT [name],[company],[file_version],[product_version]
FROM sys.dm_os_loaded_modules
WHERE company NOT LIKE 'Microsoft%' OR company is NULL
Si vous avez une exigence professionnelle d’utiliser ces fournisseurs, assurez-vous que les dernières mises à
jour sont installées pour ces fournisseurs. Si possible, évitez de surveiller SQL Server trafic lié et évitez de
charger ces modules dans SQL Server processus. Vous pouvez également exclure ce serveur du processus de
surveillance.
Architecture Winsock
Fournisseurs de services de transport
102 et syntaxe incorrecte sp_MS des erreurs lorsque
vous créez une réplication d’égal à égal dans SQL
Server
Cet article vous aide à résoudre le problème qui se produit lorsque vous créez une composition d’égal à égal à
partir de SQL scripts dans Microsoft SQL Server.
Symptômes
Lorsque vous créez une composition d’égal à égal à partir de scripts SQL dans Microsoft SQL Server, l’agent de
distribution dans une réplication échoue et génère une syntaxe incorrecte proche des messages d’erreur.
Ces messages d’erreur apparaissent dans l’historique des opérations de l’agent SQL Server, dans un suivi du
profileur SQL ou dans un fichier de journalisation de l’agent généré à l’aide du paramètre -Output. Par exemple,
les messages d’erreur suivants sont générés en exécutant une procédure stockée pour la table de l’exemple de
base de données INSERT Production.product AdventureWorks2017 :
SQL Server Message d’erreur de l’agent
Messages d’erreur :
Syntaxe incorrecte près de « sp_MSins_ProductionProduct ». (Source : MSSQLServer, Numéro d’erreur : 102)
Obtenir de l’aide : http://help/102
SQL Suivi du profileur
Instruction d’échec du suivi du profileur avec « . » entre le schéma et le nom de la procédure

if object_id(N'[dbo][sp_MSins_ProductionProduct]', 'P') > 0
drop proc [dbo][sp_MSins_ProductionProduct]
Message d’erreur du journal de l’agent
Horoda de connexion à l’abonné

Initialisation de l’horodat
Code de message de l’agent d’horodaté 102. Syntaxe incorrecte près de « sp_MSins_ProductionProduct ».
Time stamp Category:COMMAND
Source : Échec de la commande
Nombre :
Message : si @trancount @> 0 rollback trans
Time stamp Category:NULL
Source : Microsoft SQL Server Native Client 11.0
Nombre : 102
Message : syntaxe incorrecte près de ' 'sp_MSins_ProductionProduct''.
NOTE
Vous pouvez voir des messages d’erreur pour d’autres réplications qui sont générées pour une procédure stockée telle
que sp_MSdel_{article} et sp_MDupd_{article} .
Cause
Ce problème se produit lorsque vous ajoutez des articles à une composition pair à pair existante à l’aide de
Microsoft SQL Server Management Studio 17.x.x. Lorsque vous faites cela, la réplication génère un nom de
procédure stockée qui est préfixé à l’aide [dbo] du schéma. Pour ce faire, vous pouvez écrire un script pour la
composition dans la sp_addarticle commande, comme illustré dans l’exemple suivant.
exec sp_addarticle @publication = N'Products', @article = N'Product',

@source_owner = N'Production', @source_object = N'Product',
...
@ins_cmd = N'CALL [dbo].[sp_MSins_ProductionProduct]',
@del_cmd = N'CALL [dbo].[sp_MSdel_ProductionProduct]',
@upd_cmd = N'SCALL [dbo].[sp_MSupd_ProductionProduct]'
GO
En exécutant un script de réplication pour reconstruire l’environnement d’égal à égal, la logique pare un point («
. ») qui provoque une syntaxe CALL non valide, telle sp_addarticle que CALL [dbo][sp_MSins_ProductionProduct]
.
Résolution
Pour résoudre ce problème, procédez comme suit :
1. Scriptez toutes les publications d’égal à égal, comme indiqué dans la section Cause.
2. Pour supprimer le préfixe de schéma des appels de procédure stockée, recherchez dbo globalement le
ALL [dbo].[ texte. Ensuite, remplacez-le par ALL [ .
NOTE
Si vous créez un nouvel environnement d’égal à égal, la solution la plus rapide à ce problème peut consister à
abandonner la composition, à modifier le script, puis à créer à nouveau l’environnement d’égal à égal.
Si un ou deux tableaux seulement échouent, envisagez d’abandonner ces articles de la composition, de modifier le
script, puis de restaurer les articles dans la composition.
Les tables et les données déterminent l’option que vous devez choisir. Si les tables rompues représentent une
grande partie de la base de données et que les données incluent des modifications, nous vous recommandons
d’essayer de recréer l’environnement d’égal à égal via un nouveau processus de sauvegarde-restauration et
d’utiliser l’Assistant D’égal à égal pour recréer la topologie.
Syntaxe corrigée
@ins_cmd = N'CALL [sp_MSins_ProductionProduct]',

@del_cmd = N'CALL [sp_MSdel_ProductionProduct]',
@upd_cmd = N'SCALL [sp_MSupd_ProductionProduct]'
Prévention
Lorsque vous ajoutez de nouveaux articles à une composition pair à pair existante, ouvrez la fenêtre Propriétés
de l’ar ticle et supprimez le préfixe de schéma avant d’enregistrer [dbo]. les modifications.
État
Microsoft a confirmé qu’il s’agit d’un problème dans les produits Microsoft répertoriés dans la version
d’origine du produit au début de cet article.
Erreur 1205 lors de la configuration de la réplication
transactionnelle
Cet article vous aide à résoudre un problème qui se produit lorsque vous configurez la réplication
transactionnelle dans SQL Server.
Symptômes
Vous configurez la réplication transactionnelle dans SQL Server.
La topologie de réplication transactionnelle se compose de plusieurs éditeurs.
Les éditeurs répliquent les données dans la même base de données abonnée.
Les agents de distribution s’exécutent en continu ou selon un calendrier fréquent. Par exemple, les agents de
distribution s’exécutent toutes les minutes.
Dans ce scénario, les agents de distribution peuvent être impliqués dans un scénario de blocage et peuvent être
sélectionnés en tant que victime du blocage. Lorsque ce problème se produit, vous pouvez recevoir un message
d’erreur semblable à ce qui suit :
Erreur 1205
La transaction (ID de processus %d) a été dans un blocage sur les ressources %*ls avec un autre processus
et a été choisie comme victime du blocage. Réexécutez la transaction.
Si vous activez l’indicateur de suivi 1222 pour rediriger les informations de blocage dans le journal d’erreurs
SQL Server, vous recevez un message d’erreur semblable à l’un des éléments suivants :
update MSreplication_subscriptions set transaction_timestamp = cast( @P1 as binary(15)) +

cast(case datalength(transaction_timestamp) when 16 then isnull(substring(transaction_timestamp,
16, 1), 0) else 0 end as binary(1)), « time » = @P2 where UPPER(publisher) = UPPER( @P3 ) and
publisher_db = and publication = and subscription_type = @P4 @P5 0
update MSreplication_subscriptions set transaction_timestamp = cast( @P1 as binary(15)) +

cast(substring(transaction_timestamp, 16, 1) en tant que binaire(1)), « time » = @P2 where
UPPER(publisher) = UPPER( ) and publisher_db = and @P3 publication = and subscription_type =
@P4 @P5 0 and (substring(transaction_timestamp, 16, 1) = 0 or datalength(transaction_timestamp)
< 16)
Cause
Ce problème se produit si l’estimation du nombre de lignes pour la MSreplication_subscriptions table système
de nombres est incorrecte. Si l’estimation du nombre de lignes est incorrecte, le moteur SQL Server base de
données peut utiliser une méthode incorrecte pour mettre à jour la base de données.
NOTE
En règle générale, l’estimation correcte du nombre de lignes est égale au nombre d’abonnements dans la base de
données. Si vous utilisez la fonctionnalité Subscription Flux, l’estimation du nombre de lignes est égale au nombre
d’abonnements multiplié par le nombre de flux configurés pour chaque abonnement.
Résolution
Méthode 1 : utiliser la DBCC UPDATEUSAGE commande
Pour résoudre ce problème, mettez à jour la valeur de nombre de lignes incorrecte. Pour ce faire, exécutez
la commande suivante :
DBCC UPDATEUSAGE (**subscriber_database_name** **,**'MSreplication_subscriptions') WITH COUNT_ROWS
NOTE
La commande détermine les valeurs correctes pour les lignes, les pages utilisées, les pages réservées, les pages
feuilles et les nombres de pages de données pour chaque DBCC UPDATEUSAGE partition d’un tableau. Si ces
valeurs sont correctes, la DBCC UPDATEUSAGE commande ne renvoie aucune donnée. Si des valeurs inexactes sont
trouvées et corrigées, renvoie les lignes et les DBCC UPDATEUSAGE colonnes qui sont mises à jour.
Méthode 2 : Utiliser ALTER INDEX l’instruction

Pour résoudre ce problème, resserez les index associés à la MSreplication_subscriptions table. Pour ce
faire, utilisez l’instruction suivante :
ALTER INDEX ALL ON [dbo].[MSreplication_subscriptions] REBUILD
Lorsque le problème mentionné dans la section Symptômes se produit, l’estimation du nombre de lignes pour la
table système MSreplication_subscriptions peut être aussi élevée que 4 294 967 296 . Pour vérifier la valeur
rowcount, utilisez l’une des méthodes suivantes.
Méthode 1 : utiliser SQL Server Management Studio
Pour utiliser SQL Server Management Studio pour vérifier la valeur de nombre de lignes pour la
MSreplication_subscriptions table système, suivez les étapes suivantes :
1. Démarrez SQL Server Management Studio, puis connectez-vous à l’instance du serveur abonné.
2. Développez bases de données, puis développez la base de données abonnée.
3. Développez Tables, puis développez Tables système.
4. Cliquez avec le bouton droit sur dbo. MSreplication_subscriptions, puis sélectionnez
Propriétés.
5. Sélectionnez Stockage, puis vérifiez la valeur de nombre de lignes dans le champ Nombre de
lignes.
Méthode 2 : utiliser une instruction de requête
Pour vérifier la valeur rowcount de la table MSreplication_subscriptions système, exécutez la requête
suivante :
SELECT rows, * FROM sys.partitions WHERE object_id = object_id('MSreplication_subscriptions')
Références
Pour plus d’informations sur la détection et la fin des blocages, voir : Detecting and Ending Deadlocks
Pour plus d’informations sur l’instruction ALTER, voir : Transact-SQL statements
Pour plus d’informations sur la commande DBCC UPDATEUSAGE, voir : DBCC UPDATEUSAGE (Transact-SQL)
Messages d’erreur 20011 SQL Server l’échec de
l’Agent de lecture du journal de réplication
Cet article décrit les étapes de résolution des problèmes qui peuvent aider à résoudre les problèmes qui se
produisent après l’échec de l’agent de lecture des journaux de réplication SQL Server.
Symptômes
Lorsque l’agent de lecture du journal de réplication échoue Microsoft SQL Server, vous recevez un message
d’erreur semblable à celui-ci dans le journal SQL Server de réplication :
<Time stamp> spid98 Replication-Replication Transaction-Log Sous-système lecteur : échec de

logreadername de l’agent. Le processus n’a pas pu exécuter « sp_replcmds » sur ' <Server name> '. <Time
stamp> Erreur spid258 : 14151, Gravité : 18, État : 1. <Time stamp> spid258 Replication-Replication
Transaction-Log sous-système lecteur : échec de logreadername de l’agent. Le processus n’a pas pu exécuter
« sp_replcmds » sur ' <Server name> '.
En outre, vous pouvez recevoir un ou plusieurs messages d’erreur semblables à ce qui suit :
18805/18836 LogReader n’a pas pu construire l’état de la commande répliquée : <Time stamp> 0,
code : 20011, texte : « Le processus n’a pas pu exécuter « sp_replcmds » sur ' <Server name> '.'.
<Time stamp> Le processus n’a pas pu exécuter « sp_replcmds » sur ' <Server name> '. <Time
stamp> Status: 0, code: 18836, text: 'Invalid Text Info Block for UpdateText: m_pHead->GetType() : 1,
m_TextDataType : 0, m_TextOpType : 3, ti:{RowsetId 7746362867712, {TextTimeStamp 480235880448,
{RowId {PageId 2680944, FileId 1}, SlotId 21 }} , coloffset -1, textInfoFlags 0x4, textSize 177, offset 177,
oldSize 0, newSize 0}.' <Time stamp> Status: 0, code: 18805, text: 'Logreader failed to construct
replicated command from LSN {00150725:00014316:009d}.'. <Time stamp> Status: 0, code: 22037,
text: 'The process could not execute 'sp_replcmds' on <Server name> '.'.
18805/18836 LogReader n’a pas pu construire l’état de la commande répliquée : <Time stamp> 0,
code : 20011, texte : « Le processus n’a pas pu exécuter « sp_replcmds » sur ' <Server name> '.'.
<Time stamp> Le processus n’a pas pu exécuter « sp_replcmds » sur ' <Server name> '. <Time
stamp> Repl Agent Status: 6 <Time stamp> Status: 0, code: 18805, text: 'The Log Reader Agent failed
to construct a replicated command from log sequence number (LSN) {00033a89:0000969c:000a}.
Back up the publication database and contact Customer Support Services.'. <Time stamp> Status: 0,
code: 22037, text: 'The process could not execute 'sp_replcmds' on <Server name> '.'.
Délai d’exécution de LogReader L’agent est en cours d’exécution. Utilisez le moniteur de réplication
pour afficher les détails de cette session d’agent. État de l’agent deplage : 3 Publisher : {call
sp_repldone ( 0x0000172a0002ac900001, 0x0000172a0002ac900001, 0, 0)} Publisher : {call
sp_replcmds (500, 0)} Status: 2, code: 0, text: 'The process could not execute 'sp_replcmds' on
<Publisher name> ''.'. Le processus n’a pas pu exécuter « sp_replcmds » sur ' <Publisher name> '.
État de l’agent deplage : 5 État : 2, code : 0, texte : « Expiration du délai d’expiration ». Déconnexion de
Publisher <Publisher name> ' L’agent a échoué avec l’état « Nouvelle tentative ». Essayez d’exécuter
l’agent ultérieurement.
<Time stamp>Assertion Status: 0, code: 20011, text: 'The process could not execute 'sp_replcmds' on
<Server name> '.'. <Time stamp> Le processus n’a pas pu exécuter « sp_replcmds » sur ' <Server
name> '. <Time stamp> Status: 0, code: 18773, text: 'Could not locate text information records for the
column « ClientPreferences », ID 30 during command construction.'. <Time stamp> Status: 0, code:
3624, text: 'A system assertion check has failed. Pour plus d SQL Server, consultez le journal des
erreurs. En règle générale, un échec d’assertion est dû à un bogue logiciel ou à une altération des
données. Pour vérifier l’altération de la base de données, envisagez d’exécutez DBCC CHECKDB. Si
vous avez accepté d’envoyer des vidages à Microsoft lors de l’installation, un mini-vidage sera envoyé
à Microsoft. Une mise à jour peut être disponible auprès de Microsoft dans le Dernier Service Pack ou
dans un QFE du support technique. '. <Time stamp> Status: 0, code: 22037, text: 'The process could
not execute 'sp_replcmds' on <Server name> '.'.

Message d’erreur 1 : 18805/18836 LogReader n’a pas réussi à construire la commande répliquée
À partir de ce message, vous pouvez déterminer l’objet et la modification qui a créé la transaction dans le
journal. Pour ce faire, utilisez les informations suivantes :
Le code 18836 vous donne l’ID de la page sur laquelle vous pouvez trouver l’objet.
NOTE
Vous pouvez utiliser la page Comment utiliser DBCC pour afficher le contenu des pages de base de
données.
Le code 18805 vous donne un numéro de séquence de journal (LSN) qui peut fournir l’objet :
dbcc Log(master, 3, 'lsn', '0x00000208:000000a0:0004', 'numrecs', 1)
Message d’erreur 2 : 18805/18836 LogReader Failed to Construct Replicated Command The

main difference between error message 1 and error message 2 is that error 2 does not contain the status
message and does not point to the « textinfo » column. This known issue is fixed in Cumulative update
package 11 for Microsoft SQL Server 2008 Service Pack 3 (SP3).
Le problème se produit uniquement sur les tables qui ont des colonnes de type BLOB (Binary Large Object) et
pour lesquelles l’article n’utilise pas les commandes paramétisées pour répliquer. Pour résoudre ce problème,
suivez les étapes suivantes :
1. Déterminez si l’article utilise des commandes paramétisées. Pour ce faire, exécutez la requête suivante :
select status, name from sysarticles where name =''
2. Convertissez les valeurs d’état au format binaire. Par exemple, pour une valeur d’état de 41, la valeur
binaire est 101001 et le cinquième bit à partir du côté droit, également appelé bit d’état, est sur. Si le bit
d’état est 1, il est déjà définie. Si le bit d’état est 0, il n’est pas définie. Par conséquent, vous devez exécuter
sp_changearticle pour configurer les commandes paramétrables. Pour modifier le bit d’état, exécutez la
commande suivante :
sp_changearticle 'ConstituentRequest_ETL_Trans', 'CRProfile', 'status', 'parameters'
Message d’erreur 3 : délai d’out logReader

Pour résoudre ce problème, appliquez l’une des méthodes suivantes :
Augmentez la valeur du paramètre QueryTimeout de l’agent de lecture de journaux.
NOTE
Par défaut, la valeur de ce paramètre est 1 800 secondes (30 minutes).
Définissez la valeur du paramètre QueryTimeout sur zéro (0) afin de désactiver le délai d’absence.
Réduisez la valeur du paramètre ReadBatchSize de l’agent de lecture de journaux.
Si l’assertion dans le journal des erreurs correspond aux problèmes de ces articles de la Base de connaissances,
installez le correctif approprié.
Résoudre l’erreur 20598 dans la réplication
transactionnelle
Cet article explique comment résoudre l’erreur 20598 dans la réplication transactionnelle et fournit des
solutions de contournement pour le problème.
Résoudre des problèmes

Pour résoudre ce problème, procédez comme suit :
1. Dans le moniteur de réplication de l’agent de distribution de l’abonné, extrayez le numéro de séquence de
transaction et l’ID de commande qui ont rencontré l’erreur :
NOTE
Vous pouvez obtenir le même numéro de séquence de transactions à partir du serveur distributeur à l’aide de la
requête suivante :
2. Extrayons les commandes qui m’indiquent le numéro de séquence de transactions sur le serveur
distributeur. Utilisez le numéro de séquence de transaction de l’étape 1 comme paramètre pour cette
commande :
3. À partir de la sortie de l’étape 2, identifiez la commande qui échoue à l’aide de l’ID de commande de
l’étape 1. Reportez-vous à command_id colonne dans le jeu de résultats.
4. Valider les informations de l’article sur l’éditeur. Utilisez l’ID d’article que vous obtenez à l’étape 2 et
vérifiez les détails de l’article que vous essayez de mettre à jour :
5. Validez la clé primaire sur l’éditeur.

Vous avez deux informations : la table sur laquelle vous essayez d’effectuer la mise à jour et la valeur de la
clé primaire. Vous pouvez interroger la table à l’aide de la valeur de clé primaire et localiser la ligne dans
la base de données publisher. Par exemple :
SELECT * FROM tbl_sample WHERE column_name = <primary_key_value>
6. Vérifiez le problème chez l’abonné.

Exécutez la même requête sur la base de données d’abonnés et comparez-la au résultat que vous recevez
de la base de données publisher.
Pour contourner ce problème, utilisez les deux méthodes suivantes :
Insérez manuellement la ligne manquante à l’abonné. Cela peut permettre à l’agent de distribution de
réessayer la commande ayant échoué et de passer à la réplication.
NOTE
D’autres lignes sont manquantes et doivent être insérées manuellement au niveau de l’abonné en cas d’autres
échecs.
Indiquez à l’agent de distribution d’ignorer cette erreur et de continuer à répliquer le reste des
modifications. L’agent de distribution accepte le skiperrors paramètre. Vous pouvez utiliser ce
paramètre pour transmettre le code d’erreur 20598. Cela peut conserver la configuration de la réplication
intacte pendant que vous attendez une opportunité de synchroniser manuellement les lignes
manquantes.
NOTE
Vous devez évaluer attentivement les effets en aval de l’intégrité référence et les déclencheurs présents sur le
tableau affecté avant de continuer.
Collecte de données pour examiner la cause de ce problème

Si ce problème se produit à plusieurs reprises, vous devez collecter les données suivantes pour analyse par
l’équipe de support technique Microsoft SQL Server afin qu’elle puisse tenter d’identifier la cause du problème :
Sauvegarde de la base de données de distribution lorsque ce problème se produit. (Cela doit se faire
après le rapport d’erreur et avant la réinitialisation de l’abonnement.)
Sauvegardes du journal des transactions de l’éditeur et de l’abonné. (Celles-ci doivent être pendant au
moins les 24 heures qui ont conduit à l’heure du problème.)
Suivis du profileur qui montrent l’activité des agents de réplication sur l’éditeur, l’abonné et le distributeur.
(Assurez-vous que le profileur est en cours d’exécution même avant le début du problème. Dans l’idéal,
vous souhaitez démarrer le profileur en même temps que l’heure de début du travail de réindexation.)
Sorties des cinq étapes précédentes pour identifier la table concernée et la valeur de clé primaire
manquante.
Sortie des vues de catalogue à partir des bases de données de l’éditeur et de l’abonné :
sys.partitions
sys.allocation_units
sys.objects
Sorties détaillées des journaux de l’agent de réplication
Problèmes connus résolus

Les problèmes suivants se produisent dans les versions antérieures SQL Server :
KB 982857 fix: Distribution Agent fails with error code 20598 when a publication database is configured
with the Read Committed Snapshot option
KB 2484392 FIX : la colonne « xact_seqno » dans la table « MSrepl_errors » n’enregistre pas une ligne
ignorée dans SQL Server 2008 ou SQL Server 2008 R2 si vous utilisez le paramètre « -SkipErrors » dans
l’agent de distribution
Résolution des problèmes : rechercher des erreurs avec la réplication SQL Server transactionnelle
Erreur lors de l’attachement d’une base de données
activée par LAX À une instance de SQL Server 2016
ou SQL Server 2017 sur Windows
Cet article vous aide à résoudre le problème qui vous permet de ne pas attacher une base de données à base de
données à base de données ACTIVÉE à une instance de SQL Server 2016 ou SQL Server 2017 sur Windows.
Version du produit d’origine : SQL Server 2008 et les versions ultérieures
Symptômes
Vous détachez une base de données avec activée sur SQL Server 2014 ou une version antérieure et vous
l’attachez à Change Data Capture une instance SQL Server 2016 ou SQL Server 2017 sur Windows instance.
Dans ce cas, vous rencontrez l’erreur suivante lorsque vous exécutez la sp_cdc_enable_table procédure système
:
Commande
EXEC sys.sp_cdc_enable_table @source_schema='<schema name>',

@source_name='<source name>', @role_name='<role name>',
@supports_net_changes=1, @allow_partition_switch=0;
Message d’erreur
Msg 22832, Niveau 16, État 1, Procédure

sp_cdc_enable_table_internal, ligne 639 [ligne de démarrage par lot 0]
Could not update the metadata that indicates table [ <schema name> ]. [ <object name> ] est activé pour la
capture des données de modification. L’échec s’est produit lors de l’exécution de la commande « insert in
[contrôle]. [captured_columns]'. L’erreur renvoyée était 213 : « Le nom de colonne ou le nombre de valeurs
fournies ne correspond pas à la définition de table. » Utilisez l’action et l’erreur pour déterminer la cause de
l’échec et resoumettre la demande.
Résolution
Pour résoudre ce problème, exécutez une fois que vous avez attaché une base de données à une instance de
sp_cdc_vupgrade SQL Server 2016 ou SQL Server 2017 sur Windows qui a Change Data Capture été activée.
Pour plus d’informations, voir Attacher une base de données.

Message d’erreur SQL Server de réplication 2008 :
une erreur s’est produite lors de la récupération des
données de composition
Cet article vous aide à contourner le problème qui se produit lorsque vous essayez d’afficher une composition
dans le Moniteur de réplication.
Symptômes
Vous commencez Microsoft SQL Server 2008 Management Studio.
Vous démarrez le moniteur de réplication.
Vous développez un éditeur, puis sélectionnez une composition.
Dans ce scénario, vous pouvez recevoir un message d’erreur semblable à ce qui suit :
Une erreur s’est produite lors de la récupération des données de composition. Impossible de caser l’objet de
type « System.DBNull » pour taper « Microsoft.sqlserver.Replication.PublisherMonitor ».
Cause
Ce problème se produit si vous sélectionnez la composition avant que la liste des éditeurs soit remplie.
Pour contourner ce problème, attendez que la liste des éditeurs soit entièrement remplie avant de cliquer sur
une composition.
En règle générale, le problème mentionné dans la section Symptômes se produit lorsque de nombreux serveurs
sont répertoriés en tant qu’éditeurs. La liste des éditeurs peut également s’remplir lentement si les serveurs
sont occupés ou sur des connexions réseau lentes.
Références
Pour plus d’informations sur le moniteur de réplication, voir : Vue d’ensemble de l’interface du moniteur de
réplication
S’applique à
SQL Server Web 2008
Appliquer un correctif pour les SQL Server dans
une topologie de réplication
Cet article explique comment appliquer un correctif pour les Microsoft SQL Server dans une topologie de
réplication.
Serveurs pour l’application d’un correctif

Vous appliquez un correctif à un ou plusieurs des serveurs suivants dans une topologie de réplication :
Distributeur
Le Publisher
Abonné
Le serveur Web
NOTE
L’objectif du correctif détermine les serveurs sur lesquels vous appliquez le correctif.
Après avoir appliqué le correctif, vous de devez suivre des étapes supplémentaires pour résoudre complètement
le problème pour lequel vous appliquez le correctif. L’article de la Base de connaissances Microsoft qui décrit le
correctif logiciel décrit ces étapes supplémentaires.
Conditions requises
Dans une topologie de réplication, vous pouvez appliquer n’importe quel correctif SQL Server au distributeur
ou au Publisher. Toutefois, si plusieurs versions de SQL Server sont installées, vous devez également respecter
les conditions suivantes :
Après avoir appliqué le correctif, la version de SQL Server sur le distributeur doit être ultérieure ou
identique à la version de SQL Server sur le Publisher.
NOTE
Le distributeur est le même serveur que le Publisher.
Après avoir appliqué le correctif, la version de SQL Server sur le Publisher doit être antérieure ou
identique à la version de SQL Server sur le distributeur.
La SQL Server de version requise pour l’abonné après l’application d’un correctif dépend du type de
composition. Si vous avez un abonné en lecture seule à une composition transactionnelle, vous pouvez
appliquer n’importe quel correctif à l’abonné. Si vous avez un abonné à une composition de fusion, la version de
SQL Server sur l’abonné doit être antérieure ou identique à la version de SQL Server sur le Publisher une fois
que vous avez appliqué le correctif.
Lorsque vous utilisez la synchronisation Web pour répliquer vers l’une des destinations suivantes, vous devez
appliquer un correctif sur un serveur Web qui héberge les composants de réplication :
A SQL Server Subscriber
Une base SQL Server CE
Une base SQL Server Mobile Edition
Une base de données SQL Server Compact Edition
L’utilisation de rowguidcol dans la définition de filtre
n’est pas prise en charge dans la réplication de
fusion
Cet article explique que l’utilisation dans la définition de filtre rowguidcol n’est pas prise en charge dans la
réplication de fusion.
Version du produit d’origine : SQL Server 2008 Enterprise, SQL Server 2008 R2 Enterprise, SQL Server 2005
Êdition Entreprise
Résumé
Lors de la conception d’une topologie de réplication, un filtre ne doit pas inclure et utilisé par la réplication
rowguidcol uniqueidentitifier pour identifier les lignes. Par défaut, SQL Server ajoute cette colonne lors de la
configuration de la réplication de fusion sur une table.
Pour suivre les modifications, la réplication de fusion (et la réplication transactionnelle avec les abonnements de
mise à jour en file d’attente) doivent être en mesure d’identifier de manière unique chaque ligne de chaque table
publiée.
Pour effectuer cette réplication de fusion, ajoute la colonne rowguid à chaque table, sauf si la table possède déjà
une colonne de type de données avec le jeu de propriétés (auquel cas cette colonne uniqueidentifier
ROWGUIDCOL est utilisée).
Si le tableau est supprimé de la composition, la colonne rowguid est supprimée ; si une colonne existante a été
utilisée pour le suivi, la colonne n’est pas supprimée. Un filtre ne doit pas inclure le rowguidcol filtre utilisé par
la réplication pour identifier les lignes. Lorsque la réplication est configurée, la fonction est fournie par défaut
pour la colonne rowguid ou la colonne utilisateur newsequentialid() avec rowguidcol .
Les clients peuvent fournir un guid pour chaque ligne si nécessaire, même si la valeur 00000000-0000-0000-
0000-00000000000000 ne doit pas être utilisée.
Échec du travail de capture DE LAS lors du
traitement des modifications d’une table avec un
type de données CLR système (géométrie,
géographie ou hierarchyid)
Cet article vous aide à contourner le problème d’échec d’un travail de capture DE TYPE PRINCIPAL lorsque vous
traitez les modifications d’une table qui possède un type de données CLR système (géométrie, géographie ou
hierarchyid).
Symptômes
Vous activez la fonctionnalité CAPTURE (Change Data Capture) sur une table qui possède un type de données
CLR système, tel que la géométrie, la géographie ou hierarchyid .
Le travail de capture (analyse) SCANNE traite les modifications liées à d’autres tables. Le processus n’a pas
encore atteint la table qui possède le type de données CLR système.
Vous modifiez le langage de manipulation de données (DML) sur la table qui possède le type de données
CLR système. Ensuite, vous modifiez le langage de définition de données (DDL) dans le même tableau (par
exemple, vous ajoutez une colonne).
Dans ce scénario, lorsque le travail de capture PRINCIPAL commence à traiter la table qui possède le type de
données CLR système, il échoue et renvoie le message d’erreur suivant :
Msg 18805, Level 16, State 1, Procedure sp_replcmds, LineLineNumber[Batch Start LineNumber ]
Le Log-Scan n’a pas réussi à créer une commande répliquée à partir du numéro de séquence de journal
(LSN) {nnnnnnnn: nnnnnnnn: nnnn}. Back up the publication database and contact Customer Support
Services.
Msg 22859, Level 16, State 2, Procedure sp_replcmds, LineNumber [Batch Start LineNumber ]
Échec du processus d’analyse des journaux dans le traitement des enregistrements du journal. Reportez-
vous aux erreurs précédentes dans la session en cours pour identifier la cause et corriger les problèmes
associés.
Msg 3621, Level 16, State 6, Procedure sp_replcmds, LineNumber [Batch Start LineNumber ]
L’instruction a été terminée.
Msg 22864, Level 16, State 1, Procedure sp_MScdc_capture_job, Line LineNumber[Batch Start LineNumber ]
L’appel à sp_MScdc_capture_job par le travail de capture pour la base de données « DatabaseName » a
échoué. Recherchez les erreurs précédentes pour la cause de l’échec.
En outre, l’entrée suivante peut être consignée dans le journal des erreurs :
Erreur : 913, Gravité : 16, État : 16. IDID de base de données in trouvable. Il est possible que la base de
données ne soit pas encore activée ou qu’elle soit en transition. Reissue la requête une fois que la base de
données est disponible. Si vous ne pensez pas que cette erreur est due à une base de données en cours de
transition et que cette erreur continue de se produire.
Ce problème ne se produit pas si le travail de capture DE LASC traite initialement uniquement le DML, puis traite
la modification DDL lors de l’étape suivante.
Pour contourner ce problème, essayez l’une des méthodes suivantes :
Évitez d’utiliser les types de données problématiques (géométrie, géographie, hierarchyid) avec LASO.
Assurez-vous que vous n’avez aucune modification DML en cours lorsque vous a apporté des
modifications DDL sur les tables qui ont des types de données g eometry, geography ou hierarchyid .
Pour éviter ce problème, suivez les étapes suivantes :
1. Quiesce all DML to the table.
2. Exécutez un travail de capture pour traiter les modifications.
3. Exécutez DDL pour la table.
4. Exécutez un travail de capture pour traiter les modifications DDL.
5. Ré-activez le traitement DML.
NOTE
Si vous continuez à faire l’expérience de ce problème, désactivez puis réactivez LA FONCTIONSO sur la table.
SQL Le journal des transactions augmente lorsque
vous utilisez la capture de données de modification
pour Oracle par Attunity
Cet article vous aide à résoudre le problème dans lequel vous remarquez une croissance continue des journaux
de transactions pour une base de données ACTIVÉE.
Symptômes
Vous utilisez Microsoft SQL Server 2017 sur Windows, SQL Server 2016, 2014 ou 2012 Modifier la capture
de données pour Oracle par Attunity.
Vous créez une instance CAS pour capturer les modifications des tables de base de données Oracle.
Les valeurs de capture des changements sont stockées dans SQL Server de capture des changements.
Le journal des transactions de la base SQL Server de données s’agrandit et les transactions ne sont pas
marquées pour troncation lorsque les modifications de données sont capturées.
Dans ce scénario, la croissance SQL Server fichier journal des transactions de la base de données s’accumulent
et consomment trop d’espace disque au fil du temps.
Cause
Lorsque la capture des données de modification pour les instances Oracle est configurée, la base de données
SQL qui reçoit les données de modification aura des tables en miroir, avec des transactions marquées pour la
réplication. Ce comportement est dû au fait que LA FONCTION DNS pour Oracle s’appuie sur des procédures
stockées système sous-jacentes qui ressemblent à celles utilisées dans LA fonction SQL SERVER. Toutefois, étant
donné qu’aucune réplication SQL NE peut être impliquée lorsque la réplication DUPLICATION pour Oracle est
utilisée seule, il n’existe aucun lecteur de journal pour effacer les transactions qui sont marquées pour la
réplication. Étant donné que la transaction n’a pas besoin d’être répliquée dans SQL Server, il est possible de
marquer manuellement la transaction comme distribuée à l’aide de la solution de contournement décrite plus
loin dans cet article.
Pour vérifier cette cause exacte, exécutez la commande lorsque vous êtes connecté à la DBCC OPENTRAN base de
données SQL SERVER LA BASE de données PRINCIPALE. Vous verrez un numéro de téléphone LSN non
distribué, comme illustré dans l’exemple suivant :
Replicated Transaction Information:

Oldest distributed LSN : (0:0:0)
Oldest non-distributed LSN : (38:272:1)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Vous avez peut-être un LSN non distribué, car LASO pour Oracle utilise LA méthode SQL pour les procédures
stockées et qui, à son tour, utilise le lecteur du journal de réplication. Ce LSN non distribué correspond aux
entrées du journal pour ajouter la table mise en miroir dans la base de données ATTUNity MIRROR.
Si vous exécutez cette requête, log_reuse_wait_desc l’option renvoie une valeur de , indiquant la REPLICATION
cause. Sélectionnez log_reuse_wait_desc le nom dans , où le nom est <your_cdc_database> sys.databases :
REPLICATION <your_cdc_database>
Résolution
1. Exécutez la commande suivante dans une fenêtre de requête qui est connectée à la base de données
activée pour LA CONNEXION dans SQL Server :
exec sp_repltrans
Vous devez recevoir une sortie semblable à ce qui suit :
xdesid xact_seqno xact_seqno

0x000000260000012C0001 0x0000002A000001B50001
Copiez les numéros de séquence de transaction LSN pour la commande suivante.

2. À l’aide des numéros de l’étape 1, exécutez la commande comme suit pour signaler que sp_repldone les
paires LSN BeginTran et CommitTran sont déjà répliquées :
sp_repldone @xactid = 0x000000260000012C0001, @xact_segno = 0x0000002A000001B50001
3. Exécutez la commande suivante pour vérifier que la transaction est marquée comme répliquée dans la
base de données PRINCIPALE :
DBCC OPENTRAN
Cela renvoie une sortie semblable à ce qui suit :
No active open transactions.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
4. Pour vous assurer que le journal des transactions peut être réutilisé, confirmez qu’aucune autre raison de
réutilisation n’est indiquée sur la base de données :
select log_reuse_wait_desc, name from sys.databases where name = 'your_cdc_database'
Cela renvoie une sortie semblable à ce qui suit :
log_reuse_wait_desc name
NOTHING your_cdc_database
5. Vous devez maintenant être en mesure de tronqué le journal des transactions à l’aide de sauvegardes de
journaux. Vous devez également être en mesure de réduire le fichier journal des transactions pour
réduire l’espace disque qui est consommé. Par exemple, exécutez la commande suivante :
BACKUP LOG your_cdc_database TO DISK='c:\folder\logbackup.trn'
DBCC SHRINKFILE (yourcdcdatabase_log, 1024)
Pour plus d’informations, voir Gérer la taille du fichier journal des transactions.
Pour plus d’informations, voir Résoudre les erreurs d’instanceSUPdans la capture des données de modification
Microsoft pour Oracle par Attunity.
produits.
Lignes de touches dupliquées à partir sys.systableau
de validation dans SQL Server
Cet article fournit des informations sur la résolution d SQL Server problème de suivi des changements qui peut
entraîner des doublons de lignes dans le sys.syscommittab fichier.
Symptômes
Lorsque vous comparez le fichier en mémoire et le fichier sur disque dans Microsoft SQL Server, vous pouvez
voir des lignes de clé SYSCOMMITTABLE sys.syscommittab en double. Ces valeurs en double peuvent entraîner
l’échec des opérations de sauvegarde et de point de contrôle.
« Impossible d’insérer une ligne de clé en double dans l’objet « sys.sysvalidation » avec un index unique «
si_xdes_id ». La valeur de clé en double est (KeyValue).
Échec du purgement de la table de validation sur le disque dans dbidDatabaseID en raison de l’erreur 2601.
Pour plus d’informations, consultez lelog des erreurs. »
Cause
Ce problème se produit en raison d’un problème connu dans SQL Server suivi des changements.
Facteurs de résolution à l’origine des clés en double

Pour résoudre les facteurs à l’origine des clés en double, appliquez l’un des correctifs suivants, selon votre
situation :
CORRECTIF : Une opération de sauvegarde sur une base de données SQL Server 2008 ou SQL Server
2008 R2 échoue si vous activez le suivi des changements sur cette base de données
CORRECTIF : la sauvegarde échoue dans SQL Server 2008, SQL Server 2008 R2 ou SQL Server 2012 si
vous activez le suivi des changements sur la base de données
CORRECTIF : l’opération de sauvegarde échoue dans une base de données SQL Server 2008, SQL Server
2008 R2 ou SQL Server 2012 après avoir activé le suivi des changements
Bien que ces correctifs empêchent l’apparition de lignes de touches en double, ils ne suppriment pas
automatiquement les lignes en double. Sans supprimer les lignes en double, la base de données concernée ne
peut pas remplir les points de contrôle de base de données et les sauvegardes risquent d’échouer.
Désactiver et activer le suivi des changements pour supprimer les

lignes en double
1. Désactivez le suivi des changements sur les tables et bases de données concernées.
2. Émettre un point de contrôle de base de données manuel.
3. Activer le suivi des changements sur la base de données et les tables concernées.
Pour plus d’informations sur le suivi des changements, voir Activer et désactiver le suivi des changements. Pour
émettre un point de contrôle manuel, voir CHECKPOINT (Transact-SQL).
Supprimer manuellement les lignes en double

1. Copiez le script Transact-SQL à la fin de la section Transact-SQL script dans un éditeur de texte.
2. Recherchez <AFFECTED_DB> l’espace réservé dans le script et remplacez-le par le nom de la base de données
concernée.
3. Enregistrez le script modifié sur votre disque dur en tant que fichier .sql. Par exemple,
C:\temp\remove_duplicates.sql .
Si vous exécutez SQL Server 2014, vous devez accorder au SID par service un contrôle total sur les
mssqlsystemresource.ldf fichiers et les mssqlsystemresource.mdf fichiers. Pour cela, procédez comme suit :
1. Accédez au répertoire Bin qui correspond à votre ID d’instance. Par exemple :

C:\Program Files\Microsoft SQL Server\<Instance ID>\MSSQL\Binn
2. Ouvrez les propriétés mssqlsystemresource.ldf pour mssqlsystemresource.mdf et, puis cliquez sur
l’onglet Sécurité.
3. Recherchez le SID SQL Server service par service et notez les autorisations par défaut :
*Read & execute
*Read
4. Accordez au SQL Server un contrôle total du SID par service, puis fermez les boîtes de dialogue
d’autorisations.
5. Démarrez SQL Server en mode Single-User'écran de démarrage. Pour plus d’informations, voir Démarrer
SQL Server en mode Single-User.
6. Utilisez une sqlcmd ligne de commande pour vous connecter à SQL Server sous le DAC (Dedicated
Administrator Connection). Par exemple :
sqlcmd -S PRODSERV1\MSSQLSERVER -A -E -i c:\temp\remove_duplicates.sql
Ensuite, exécutez le script Transact-SQL modifié.

7. Démarrez SQL Server en mode multi-utilisateur, puis vérifiez que les opérations de sauvegarde et de
point de contrôle sur la base de données concernée se terminent correctement. Si l’étape 4 a été utilisée,
revenir aux valeurs par défaut des autorisations.
Script transact-SQL
/*
Create a temporary database to store the necessary rows
required to remove the duplicate data
*/
if exists(select 1 from sys.databases where name = 'dbChangeTrackingMetadata')
begin
drop database dbChangeTrackingMetadata
end
go
create database dbChangeTrackingMetadata
go
--Table to store the contents of the SYSCOMMITTABLE

use dbChangeTrackingMetadata
go
go
create table dbo.t_SYSCOMMITTABLE (
commit_ts bigint
,xdes_id bigint
,commit_lbn bigint
,commit_csn bigint
,commit_time datetime
)
go
/*Table to store the duplicate rows to be removed from the

sys.syscommittab table
*/
create table dbo.t_syscommittab (
commit_ts bigint
,xdes_id bigint
,commit_lbn bigint
,commit_csn bigint
,commit_time datetime
,dbfragid int
)
go
--Enable the usage of OPENROWSET

exec sys.sp_setbuildresource 1
go
--Change <AFFECTED_DB> to the database that contains the duplicate values

USE <AFFECTED DB>
go
declare @rowcount bigint
SET @rowcount = 0
--Copy all rows from the SYSCOMMITTABLE into the temporary database
insert into dbChangeTrackingMetadata.dbo.t_SYSCOMMITTABLE
SELECT commit_ts, xdes_id, commit_lbn, commit_csn, commit_time
FROM OpenRowset (table SYSCOMMITTABLE, db_id (), 0, 0)
--Save the duplicate values into the temporary database

insert into dbChangeTrackingMetadata.dbo.t_syscommittab
select ondisk_ct.* from sys.syscommittab as ondisk_ct
join dbChangeTrackingMetadata.dbo.t_SYSCOMMITTABLE as inmem_ct
on ondisk_ct.xdes_id = inmem_ct.xdes_id
--Delete the duplicate values

delete from sys.syscommittab
where xdes_id in ( select xdes_id from dbChangeTrackingMetadata.dbo.t_syscommittab )
set @rowcount = @@rowcount
if (@rowcount > 0)
begin
print ''
print 'DELETED '+CAST(@rowcount as NVARCHAR(10))+
' rows from sys.syscommittab that were also stored in SYSCOMMITTABLE'
print ''
end
else
begin
print ''
print 'Failed to DELETE DUP rows from sys.syscommittab'
print ''
end
exec sys.sp_setbuildresource 0
go
Message d’erreur « L’agent de distribution n’a pas
réussi à créer des fichiers temporaires » lorsque vous
exécutez l’agent de distribution dans SQL Server
Cet article vous aide à contourner le problème lorsque vous exécutez l’agent de distribution dans SQL Server.
Symptômes
Sur une instance de Microsoft SQL Server installée sur un ordinateur Windows Server, vous configurez une
composition transactionnelle. Vous utilisez le Distribution Profile for OLEDB streaming profil de l’agent de
distribution. Lorsque vous exécutez l’agent de distribution, vous recevez un message d’erreur comme suit :
L’agent de distribution n’a pas réussi à créer des fichiers temporaires dans le répertoire C:\Program
Files\Microsoft SQL Server \ <nnn> \COM. Code d’erreur 5 renvoyé par le système.
NOTE
<nnn>identifie la version de SQL Server. Pour plus d’informations, voir File Locations for Default and Named Instances of
SQL Server.
Cause
Lorsque vous utilisez le profil pour l’agent de distribution ou que vous utilisez la diffusion en continu OLEDB
dans un profil personnalisé, l’agent de distribution crée des fichiers temporaires dans le
Distribution Profile for OLEDB streaming répertoire suivant :
C:\Program Files\Microsoft SQL Server\<nnn>\COM
Si le compte qui exécute SQL Server Agent n’a pas d’accès en écriture au dossier COM, l’agent de distribution
échoue lorsqu’il est en cours d’exécution en tant que travail. Si vous exécutez l’agent de distribution à partir
d’une ligne de commande à l’aide d’un compte qui n’a pas accès en écriture au dossier COM, le même échec se
produit.
Pour contourner ce problème, accordez des autorisations d’écriture au dossier COM pour le compte qui exécute
le service SQL Server Agent. Si vous exécutez l’agent de distribution à partir d’une ligne de commande, accordez
des autorisations d’écriture au dossier COM pour le compte que vous utilisez pour exécuter l’agent de
distribution.
NOTE
Si vous modifiez le compte affecté au travail de réplication, le compte doit avoir des autorisations d’écriture sur le dossier
COM.
Si vous rencontrez toujours ce problème par intermittence après avoir suivi ces étapes, vous devez vous assurer
que le dossier COM est exclu de toute analyse antivirus qui se produit sur le système.
Le code d’erreur 5 indique que l’erreur est « l’accès est refusé ».
Erreur lors de l’éumation des propriétés
d’abonnement SQL Server 2016 ou 2017
Cet article vous aide à contourner le problème qui se produit lorsque vous essayez d’éumer les propriétés de
l’abonnement sur une instance d’abonné dans SQL Server Management Studio.
Symptômes
Vous avez configuré une instance de Microsoft SQL Server 2016 ou 2017 en tant qu’éditeur et
distributeur.
Vous avez configuré un abonnement Push ou Pull à un abonné distant qui n’est pas configuré en tant
qu’éditeur ou distributeur.
Dans ce cas, si vous essayez d’éumer les propriétés de l’abonnement sur une instance d’abonné dans SQL
Server Management Studio, vous recevez un message d’erreur semblable à ce qui suit :
Impossible d’appliquer la valeur « null » à la propriété ServerInstance : la valeur ne peut pas être null.
Pour contourner ce problème, utilisez le moniteur de réplication pour l’état et la progression de l’abonnement.
S’applique à
SQL Server Web 2016
Appliquer un correctif pour les SQL Server dans
une topologie de mise en miroir de bases de
données et de réplication transactionnelle
Introduction
Cet article contient les étapes à suivre pour installer des Service Packs et des correctifs logiciels sur une instance
de Microsoft SQL Server avec les caractéristiques suivantes :
L’instance de SQL Server possède une ou plusieurs bases de données qui participent à la fois à une mise en
miroir de bases de données et à une topologie de réplication transactionnelle.
La base de données participe en tant qu’éditeur, distributeur ou abonné.
NOTE
La base de données de distribution ne peut pas être mise en miroir. Toutefois, il peut co-exister avec la base de données
principale/d’éditeur ou avec le témoin de mise en miroir de base de données.

Les étapes à suivre pour appliquer des correctifs à une SQL Server qui participe à une mise en miroir de base de
données ou à une réplication transactionnelle sont documentées dans les rubriques suivantes dans SQL Server
documents :
Mise à niveau ou correction des bases de données répliquées
Mise à niveau des instances mises en miroir
Dans un environnement où une SQL Server est configurée pour participer à la mise en miroir de bases de
données et à la topologie de réplication transactionnelle, si le témoin et le distributeur se trouve sur la même
instance de serveur, les étapes d’installation sont les suivantes :
1. Miroir
2. Témoin/distributeur
3. Principal/éditeur
4. Le(s) abonné(s)
Si le témoin et le distributeur ne sont pas sur le même serveur, les étapes d’installation sont les suivantes :
1. Miroir
2. Témoin
3. Distributeur
4. Principal/éditeur
5. Le(s) abonné(s)
Procedure
1. Si un serveur témoin se trouve dans la session de mise en miroir de bases de données, vous devez
désactiver la fonctionnalité deover automatique pendant le processus de mise à jour. Pour ce faire,
supprimez le serveur témoin de la session de mise en miroir de base de données. Si le serveur n’est pas
un serveur partenaire de certaines autres sessions de mise en miroir de bases de données, suivez ces
étapes pour désactiver le changement automatique sur le serveur témoin :
Utilisez l’instruction Transact-SQL pour désactiver le point de terminaison de mise en miroir
ALTER ENDPOINT de base de données.
Pour plus d’informations, voir Remove the Witness from a Database Mirroring Session (SQL
Server).
Effectuez une sauvegarde complète de la base de données principale/publisher, puis exécutez
DBCC CHECKDB la commande sur la base de données principale.
NOTE
Cette étape est facultative, mais elle est recommandée. Cette étape va entraver l’activité de production. Par
conséquent, vous devez planifier une fenêtre de maintenance pour cette étape.
2. Installez le Service Pack ou le correctif logiciel sur le serveur miroir. N’oubliez pas que vous de devez
mettre à jour plusieurs serveurs à ce stade.
3. Installez le Service Pack ou le correctif logiciel sur le serveur témoin.
4. Installez le Service Pack ou le correctif logiciel sur le distributeur. Si le distributeur se trouve sur la même
instance de serveur que le témoin, ces rôles serveur seront mis à jour en même temps.
NOTE
La réplication est temporairement suspendue pendant l’application de la mise à jour. Les transactions restent dans
le journal des transactions de l’éditeur pendant la mise à jour, puis sont répliquées dès que le service SQL est
redémarré sur le distributeur.
5. Reprendre les sessions de mise en miroir de bases de données.

Pour plus d’informations sur la reprise d’une session de mise en miroir de bases de données, voir Pause
ou Resume a Database Mirroring Session (SQL Server).
6. Effectuez un failover manuel sur le serveur miroir afin que le serveur miroir reprenne le rôle principal et
le rôle d’éditeur.
Pour plus d’informations sur la façon d’effectuer manuellement le failover sur le serveur miroir, voir la
rubrique Manually Failing Over to a Secondar y Database topic in SQL Server 2005 or SQL Server
2008 Books Online.
7. Exécutez DBCC CHECKDB la commande sur le serveur principal.
NOTE
Cette étape est facultative, mais recommandée.
8. Suspendre les sessions de mise en miroir de bases de données.

9. Installez le Service Pack ou le correctif logiciel sur le nouveau serveur miroir.
NOTE
Le nouveau serveur miroir est identique au serveur principal/éditeur d’origine. N’oubliez pas que vous de devez
mettre à jour plusieurs serveurs à ce stade.
10. Reprendre les sessions de mise en miroir de bases de données.

Si la session de mise en miroir de bases de données possède un serveur témoin, annuler les
modifications que vous avez apportées à l’étape 1.
Pour plus d’informations sur la façon de faire, voir Ajouter ou remplacer un témoin de mise en miroir de
base de données (SQL Server Management Studio).
NOTE
Lorsque vous annulerez les modifications que vous avez apportées à l’étape 1, le serveur témoin est de nouveau
ajouté à la session de mise en miroir de base de données.
11. Installez le Service Pack ou le correctif logiciel sur les abonnés. Au cours de ce processus, la réplication du
distributeur vers les abonnés sera temporairement suspendue et les transactions seront mise en file
d’attente dans la base de données de distribution. Si l’abonné est mis en miroir et qu’un autre serveur
témoin est utilisé, suivez les étapes 1 à 3 pour mettre à jour d’abord le serveur miroir, suivi du témoin.
Un SQL Server logique métier personnalisé
remplace une chaîne vide par un caractère de fin de
chaîne
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez un handler de logique métier
personnalisé dans SQL Server.
Version du produit d’origine : SQL Server 2008 Standard, SQL Server 2008 Enterprise, SQL Server 2008 R2
Standard, SQL Server 2008 R2 Enterprise, SQL Server 2008 R2 Datacenter, SQL Server 2012 Standard, SQL
Server 2012 Enterprise, SQL Server 2012 Developer
Symptômes
Vous configurez la réplication de fusion dans Microsoft SQL Server 2012, Microsoft SQL Server 2008 R2 ou
Microsoft SQL Server 2008.
La composition contient un article de tableau.
L’article du tableau contient une colonne de type de varchar données.
La varchar colonne contient une chaîne vide ('').
NOTE
Ce problème ne se produit pas avec une valeur NULL ou une valeur d’espace unique (' ').
Vous configurez l’article du tableau pour utiliser un handler de logique métier personnalisé.
Le handler de logique métier personnalisé gère les événements qui se produisent lors de la synchronisation
de la réplication de fusion.
Le handler de logique métier personnalisé utilise un jeu de données personnalisé pour renvoyer la ligne.
Dans ce scénario, bien qu’aucune erreur ne soit renvoyée, le handler de logique métier personnalisé remplace la
chaîne vide par un seul end-of-string caractère. Par exemple, le responsable de la logique métier personnalisée
remplace la chaîne vide par l’une des chaînes suivantes :
'ASC0'
'0x00'
« \0 » Aucune autre donnée n’est affectée.
Cause
Ce problème se produit en raison de la façon dont les composants de l’agent de fusion et le handler de logique
métier passent des données dans et hors des variables intermédiaires.
Vous pourrez peut-être contourner ce problème en utilisant le type de données au lieu nvarchar du varchar
type de données.
Le problème décrit dans la section Symptômes peut se produire si le handler de logique métier personnalisé
gère les instructions conflictuelles au niveau de l’éditeur et UPDATE de l’abonné. La chaîne vide est remplacée
par le caractère unique après la copie du jeu de données de l’éditeur ou de l’abonné dans le jeu de données
personnalisé, puis le jeu de données personnalisé est ensuite transmis au rapprochementur de réplication de
end-of-string fusion.
En outre, ce problème se produit si les données ne sont pas modifiées dans du code personnalisé semblable à ce
qui suit :
public override ActionOnUpdateConflict UpdateConflictsHandler(..., ref customDataSet, ...)

{
customDataSet = publisherDataSet.Copy();
conflictLogType = ConflictLogType.ConflictLogPublisher;
return ActionOnUpdateConflict.AcceptCustomConflictData;
}
Supprimer manuellement la réplication dans SQL
Server
Cet article explique comment supprimer manuellement la réplication dans SQL Server.
Résumé
Cet article explique comment supprimer une réplication d’un ordinateur qui exécute Microsoft SQL Server. Pour
supprimer une réplication, vous devez supprimer les abonnements, les publications et le distributeur configuré
pour la réplication. Vous pouvez supprimer la réplication en exécutant le script Transact-SQL généré par le
gestionnaire SQL Server Entreprise ou SQL Server Management Studio. Toutefois, si vous ne pouvez pas
générer le script Transact-SQL pour supprimer la réplication, vous pouvez supprimer manuellement la
réplication à l’aide de procédures stockées système et d’autres instructions Transact-SQL. Cet article contient des
informations sur les procédures stockées système qui peuvent être utilisées dans ce processus.
NOTE
Pour plus d’informations sur les procédures stockées système mentionnées dans cet article, voir SQL Server Books Online.
Supprimer manuellement une réplication

Vous pouvez supprimer manuellement une réplication à l’aide de procédures stockées système et d’autres
instructions SQL transact. Pour supprimer complètement une réplication, suivez les étapes suivantes :
1. Abandonnez tous les abonnements configurés pour la réplication.
2. Déposez toutes les publications configurées pour la réplication.
3. Déposez le distributeur configuré pour la réplication.
NOTE
Les procédures stockées système pour chaque type de réplication sont répertoriées plus loin dans cet article. Utilisez les
procédures stockées appropriées, selon le type de réplication que vous souhaitez supprimer.
Abandonner les abonnements

Pour abandonner les abonnements d’une instance de SQL Server, vous pouvez utiliser les procédures stockées
suivantes et les paramètres appropriés :
sp_dropsubscription : vous pouvez utiliser la procédure stockée système pour abandonner les
abonnements à un article, une composition ou un ensemble d’abonnements sp_dropsubscription
particuliers Publisher. Vous devez exécuter la procédure stockée sur le serveur Publisher sur la base de
données de composition.
: Vous pouvez utiliser la procédure stockée système pour abandonner un
sp_droppullsubscription
abonnement dans la base de données sp_droppullsubscription actuelle de l’abonné. Vous devez exécuter
la procédure stockée au niveau de l’abonné sur la base de données d’abonnement pull.
sp_dropmergesubscription : Vous pouvez utiliser la procédure stockée système pour abandonner un
abonnement à une composition de fusion et à l’agent de fusion associé sp_dropmergesubscription à la
composition de fusion. Vous devez exécuter la procédure stockée sur le serveur Publisher sur la base de
données de composition.
sp_dropmergepullsubscription : vous pouvez utiliser la procédure stockée système pour abandonner un
sp_dropmergepullsubscription abonnement de fusion et de fusion. Vous devez exécuter la procédure
stockée au niveau de l’abonné sur la base de données d’abonnement pull.
Drop snapshot subscriptions

Pour abandonner un abonnement Push à tous les articles d’une composition de capture instantanée, exécutez le
script suivant Publisher :
USE < **Publication database name** >

GO
EXEC sp_dropsubscription @publication = N'<Publication name>', @article = N'all', @subscriber = N'all',
@destination_db = N'all'
Pour déposer un abonnement de capture instantanée à tous les articles d’une composition de capture
instantanée, suivez les étapes suivantes :
1. Exécutez le script SQL suivant dans l’abonné :
USE < **Subscription database name** >

GO
EXEC sp_droppullsubscription @publisher = N'<Publisher server name>', @publisher_db = N'<Publication
database name>', @publication = N'<Publication name>'
2. Exécutez le script suivant à l’Publisher :

GO
EXEC sp_dropsubscription @publication=N'<Publication name>', @subscriber = N'<Subscriber server
name>', @article = N'all', @destination_db = N'all'
Abandonner un abonnement transactionnel

Pour abandonner un abonnement Push à tous les articles d’une composition transactionnelle, exécutez le script
suivant à l’Publisher :

GO
EXEC sp_dropsubscription @publication = N'<Publication name>', @article = N'all', @subscriber = N'all',
@destination_db = N'all'
Pour abandonner un abonnement pull à tous les articles d’une composition transactionnelle, suivez les étapes
suivantes :
1. Exécutez le script suivant sur l’abonné :
GO
EXEC sp_droppullsubscription @publisher = N'<Publisher server name>', @publisher_db = N'<Publisher
database name>', @publication = N'<Publication name>'

GO
EXEC sp_dropsubscription @publication =N'<Publication name>', @subscriber = N'<Subscriber server
name>', @article = N'all', @destination_db = N'<Destination database name>'
Abandonner un abonnement de fusion

Pour abandonner un abonnement Push, exécutez le script suivant Publisher :

GO
EXEC sp_dropmergesubscription @publication = N'<Publication name>', @subscriber = N'<Publisher server
name>', @subscriber_db = N'<Subscription database name>', @subscription_type = N'push'
Pour abandonner un abonnement pull, suivez les étapes suivantes :

1. Exécutez le script suivant sur l’abonné :

GO
EXEC sp_dropmergepullsubscription @publication = N'<Publication name>', @publisher = N'<Publisher
server name>', @publisher_db = N'<Publisher database name>'

GO
EXEC sp_dropmergesubscription @subscription_type = N'pull', @publication = N'<Publication name>',
@subscriber = N'<Subscriber server name>', @subscriber_db = N'<Subscription database name>'
Déposer les publications

Après avoir supprimé tous les abonnements qui s’abonnez à une composition, vous pouvez supprimer la
composition. Après avoir supprimé les publications de la base de données de composition, vous devez définir
l’option de base de données de réplication de la base de données de composition sur false. Pour supprimer une
composition, vous pouvez utiliser les procédures système stockées suivantes :
sp_droppublication : Vous pouvez utiliser la procédure stockée système pour abandonner une composition
et les articles associés sp_droppublication à la composition. Vous devez exécuter la procédure stockée à
l’Publisher sur la base de données de composition.
sp_dropmergepublication : Vous pouvez utiliser la procédure stockée système pour abandonner une
composition de fusion et l’agent de capture instantanée associé sp_dropmergepublication à la composition de
fusion. Les articles associés à la composition sont également supprimés. Vous devez exécuter la procédure
stockée à l’Publisher sur la base de données de composition.
sp_replicationdboption : vous pouvez utiliser la procédure stockée système pour définir une option de base
de données sp_replicationdboption de réplication pour la base de données active. Vous devez exécuter la
procédure stockée sur le Publisher serveur.
Pour déposer une composition de capture instantanée, exécutez le script suivant Publisher :

GO
EXEC sp_droppublication @publication = N'<Publication name>'
USE master
GO
exec sp_replicationdboption @dbname = N'<Publication database name>', @optname = N'publish', @value =
N'false'
Pour abandonner une composition transactionnelle, exécutez le script suivant Publisher :

GO
EXEC sp_droppublication @publication = N'<Publication name>'
USE master
GO
EXEC sp_replicationdboption @dbname = N'<Publication database name>', @optname = N'publish', @value =
N'false'
Pour abandonner une composition de fusion, exécutez le script suivant Publisher :

GO
EXEC sp_dropmergepublication @publication = N'<Publication name>'
USE master
GO
EXEC sp_replicationdboption @dbname = N'<Publication database name>', @optname = N'merge publish', @value =
N'false'
Déposer le distributeur
Une fois que vous avez publié tous les abonnements et toutes les publications, vous pouvez abandonner le
distributeur approprié. Toutefois, avant de déposer le distributeur, vous devez abandonner la désignation
d’abonné Publisher. Pour ce faire, utilisez les procédures stockées suivantes :
sp_dropsubscriber : vous pouvez utiliser la procédure stockée système pour abandonner la désignation
d’abonné sp_dropsubscriber à partir d’un serveur enregistré. La procédure stockée supprime l’entrée de
Registre de l’abonné. La procédure stockée est Publisher sur la base de données de composition.
sp_dropdistributor : vous pouvez utiliser la sp_dropdistributor procédure stockée système pour
supprimer le distributeur. La procédure stockée est exécuté au distributeur. Pour abandonner la
désignation d’abonné Publisher, exécutez le script suivant à l’Publisher :
USE master
GO
EXEC sp_dropsubscriber @subscriber = N'<Subscriber server name>', @reserved = N'drop_subscriptions'
Pour supprimer le distributeur, exécutez le script suivant chez le distributeur :

USE master
GO
EXEC sp_dropdistributor @no_checks = 1
Utiliser des procédures stockées

Vous pouvez également utiliser les procédures stockées suivantes lorsque vous supprimez la réplication :
sp_removedbreplication : Vous pouvez utiliser la procédure stockée système pour supprimer tous les
objets de réplication d’une base de données sans mettre à jour les données sp_removedbreplication chez
le distributeur. Vous devez exécuter la procédure stockée à l’Publisher de la base de données de
composition ou de l’abonné sur la base de données d’abonnement. Voici la syntaxe de cette procédure
stockée :
sp_removedbreplication '<Database name>'
sp_droparticle : vous pouvez utiliser la procédure stockée système pour déposer un article d’une
composition instantanée ou sp_droparticle de la composition transactionnelle. Vous ne pouvez pas
supprimer un article si un ou plusieurs abonnements à l’article publié existent toujours. Vous devez
exécuter la procédure stockée à l’Publisher sur la base de données de composition. Voici la syntaxe de
cette procédure stockée :
sp_droparticle @publication = N'<Publication name>', @article = N'<Article name>',

@force_invalidate_snapshot = 1
Références
Pour plus d’informations, voir les rubriques suivantes dans SQL Server Books Online :
Désactiver la publication et la distribution
Supprimer une composition
Supprimer un abonnement Push
Supprimer un abonnement Pull
La réplication de fusion ne prend pas en charge les
topologies d’abonné centralisées
Cet article vous aide à contourner le problème que la réplication de fusion ne prend pas en charge les
topologies d’abonné centralisées.
Version du produit d’origine : SQL Server 2012, SQL Server 2008, SQL Server 2005
Résumé
La réplication de fusion ne prend pas en charge les topologies d’abonné centralisées. Une base de données
d’abonné à fusion unique ne peut s’abonner qu’à une seule composition de fusion. Par conséquent, tout type de
topologie d’abonné centralisée n’est pas pris en charge dans la réplication de fusion.
NOTE
Cette limitation s’applique à toutes les versions actuellement SQL serveur, mais ne s’applique pas Microsoft SQL Server
Compact abonnés.
Pour contourner ce problème, envisagez les alternatives suivantes à l’utilisation d’une topologie d’abonné
centrale et de la réplication de fusion :
Implémenter une composition de fusion centrale unique avec des filtres de ligne paramétisés dans lesquels
les partitions de données fournissent les données pour les bases de données d’abonné individuelles.
Utiliser la réplication transactionnelle au lieu de la réplication de fusion pour implémenter la topologie
d’abonné centrale
NOTE
Pour plus d’informations sur la façon d’implémenter des topologies d’abonné centralisées et d’intégrer des données à
partir de plusieurs sites, voir la section Références.
Dans un modèle d’abonné central, la base de données d’abonnés se synchronise avec au moins deux sources de
publication. Dans ce scénario, les sources de publication se composent de l’une des combinaisons suivantes :
Au moins deux publications dans la même base de données d’éditeurs sur la même instance de serveur de
publication.
Au moins deux publications dans deux bases de données d’éditeurs ou plus sur la même instance de serveur
de publication.
Au moins deux publications dans deux bases de données d’éditeurs ou plus sur différentes instances de
serveur de publication.
La réplication de fusion ne prend pas en charge le modèle d’abonné central. Les agents de fusion n’ont pas été
conçus ou testés pour fonctionner dans ce scénario. La seule topologie prise en charge est la topologie dans
laquelle chaque base de données d’abonnés se synchronise avec une seule composition de fusion. Vous devez
tenir compte des éléments suivants :
NOTE
Cela s’applique à toutes les versions de Microsoft SQL Server.
Les métadonnées de réplication de fusion d’une base de données d’abonné sont stockées dans un ensemble
unique de tables de métadonnées. Si plusieurs abonnements sont créés dans la même base de données, les
métadonnées de tous les abonnements sont stockées dans le même ensemble de tables système.
Les métadonnées de réplication sont partagées par plusieurs agents de fusion.
Les agents de fusion synchronisent les informations de publication et d’abonnement entre leurs partenaires
de synchronisation configurés. Par conséquent, chaque synchronisation télécharge également des
métadonnées non liées de la base de données d’abonné vers la base de données de l’éditeur. Des
synchronisations supplémentaires distribuent ensuite ces métadonnées à d’autres nodes non liés dans la
topologie.
Lorsque les agents de fusion synchronisent leurs abonnements en même temps en parallèle. l’interaction
entre les agents de fusion peut affecter la façon dont les modifications sont gérées. Par exemple, le
regroupement des générations par lots pendant la phase de chargement individuelle de chaque
synchronisation peut être affecté.
Vous pouvez avoir des problèmes si vous implémentez un modèle d’abonné de fusion centrale. Voici quelques
exemples des problèmes que vous pouvez avoir à résoudre lorsque vous implémentez un modèle d’abonné de
fusion centrale :
La cohérence des métadonnées de réplication de fusion est compromise après l’abandon d’une
composition, puis sa re-création sur le même serveur d’éditeur et la même base de données qui ont le
même nom. Dans ce scénario, il se peut que les agents de fusion ne se synchronisent pas ultérieurement.
Par exemple, vous pouvez recevoir un ou plusieurs des messages d’erreur suivants :
Impossible d’insérer une ligne de clé en double dans un dbo.sysmergepartitioninfo objet avec
un index uc1sysmergepartitioninfo unique.
Cette composition diffère de la composition dans laquelle l’abonnement a été initialement

créé. La composition d’origine a peut-être été supprimée et remplacée par une nouvelle
composition du même nom. Chez l’abonné, supprimez l’abonnement et recréez-le pour la
nouvelle composition.
Le processus de fusion a détecté une insévaluation lors de l’évaluation de l’expression de

validation de la partition d’abonné. Le problème peut être résolu en réinitialisant
l’abonnement.
Impossible de récupérer les informations d’abonnement pour l’abonné à partir du Publisher'

L’abonnement à la publication « publication » n’est pas valide ou n’a pas été configuré
correctement.
La cohérence des métadonnées de réplication de fusion peut être compromise après l’abandon d’un
abonnement, puis sa re-création dans la base de données d’abonné centrale.
La cohérence des métadonnées de réplication de fusion peut être compromise si les abonnements dans
la base de données d’abonnés centrale sont configurés pour utiliser des valeurs différentes pour leurs
filtres de ligne paramétrables. Cela inclut l’utilisation de valeurs différentes pour le paramètre host_name
dans différents abonnements. En outre, nous pensons que le mélange de filtres host_name et
suser_sname contribue à ce problème.
Des conflits inattendus pendant la résolution des conflits peuvent entraîner une perte potentielle de
données. Ce problème peut se produire lorsque les agents de fusion s’exécutent en parallèle sur l’abonné
central.
Un blocage étendu se produit si les agents de fusion s’exécutent en parallèle. Ce problème peut se
produire au début de la phase de téléchargement ou de la synchronisation. Ce problème peut également
se produire lors de la lecture ou de l’écriture des données de modification. Ce problème de performances
peut se répercuter en cascade dans la topologie, en fonction des objets impliqués dans le blocage.
NOTE
Ces problèmes peuvent ne pas se produire immédiatement après la configuration ou la changement de la topologie. Ces
problèmes peuvent se produire de manière inattendue et intermittente ultérieurement. L’étendue des problèmes peut
dépendre du minutage des événements. Par exemple, lorsque des agents de fusion individuels se synchronisent les uns
par rapport aux autres, la gravité du problème peut être affectée par l’événement à l’origine du problème et par la
quantité de données téléchargées ou téléchargées.
Références
Pour plus d’informations sur l’intégration des données de plusieurs sites dans Microsoft SQL Server
2008 R2, voir : Integrating Data from Multiple Sites (Client)
Pour plus d’informations sur l’intégration de données à partir de plusieurs sites dans Microsoft SQL
Server 2008, voir : Integrating Data from Multiple Sites (Client)
Pour plus d’informations sur l’intégration de données à partir de plusieurs sites dans Microsoft SQL
Server 2005, voir : Integrating Data from Multiple Sites (Client)
Pour plus d’informations sur la publication des données et des objets de base de données dans SQL
Server 2012, voir le site web MSDN suivant.
NOTE
Reportez-vous à la rubrique Tableaux de publication de plusieurs publications de cet article. Publier des
données et des objets de base de données
Server 2008 R2, voir le site web MSDN suivant :
NOTE
Reportez-vous à la rubrique Tableaux de publication de plusieurs publications de cet article. Publication de
données et d’objets de base de données
Server 2008, voir le site web MSDN suivant :
NOTE
Server 2005, voir le site web MSDN suivant :
NOTE
Non-convergence lorsque SQL Server générations
enfants et parents dans des lots de génération
distincts
Cet article vous aide à résoudre le problème de non-convergence qui se produit lorsque SQL Server
générations enfants et parents dans des lots de génération distincts.
Symptômes
La perte de commandes INSERT dans les tables enfants d’un abonné peut se produire dans les conditions
suivantes :
La topologie de réplication de fusion est hiérarchique, avec un éditeur, un ou plusieurs republiers et un ou
plusieurs abonnés.
Un ou plusieurs articles parents et enfants existent dans une composition de réplication de fusion, avec un
filtre de jointage défini entre eux.
Il existe une contrainte de clé étrangère au niveau du republier et de l’abonné pour NOT FOR REPLICATION la
relation entre ces deux articles.
Les entrées INSERT dans un article enfant se produisent dans une génération distincte de la génération
parent associée par une valeur plus élevée que celle spécifiée dans le paramètre de
-DownloadGenerationsPerBatch l’agent de fusion. Ainsi, l’agent de fusion traite la génération enfant dans un lot
de générations distinctes de la génération parent associée.
Il existe une interruption du traitement de fusion entre l’éditeur et le republier et entre le traitement des lots
de génération enfant et parent.
L’architecture de réplication de fusion ne fournit pas de mécanisme permettant de maintenir les modifications
parent et enfant entre elles au-delà des limites de lot de génération. Pour contourner ce problème, vous pouvez :
Augmentez les paramètres de l’agent de fusion et de fusion à leur valeur maximale de
-UploadGenerationsPerBatch 2 000, ce qui élimine pratiquement la possibilité de traiter la génération d’un
article enfant dans un lot distinct de la génération de -DownloadGenerationsPerBatch l’article parent.
OU -
Supprimez la propriété sur les contraintes de clé NOT FOR REPLICATION étrangère au niveau de la
republier. Dans ce cas, l’agent de fusion n’est pas en mesure d’insérer des lignes dans l’article enfant, car il
n’existe aucune ligne d’article parent associée. N’oubliez pas, toutefois, qu’une dégradation des
performances peut être associée à cette modification. Si l’agent de fusion ne parvient pas à insérer ces
lignes enfants, ces modifications doivent être retentées. Le processus de nouvelle tentative de l’agent de
fusion est beaucoup moins efficace que son mode normal de traitement par lots.
Voici une séquence d’événements plus détaillée dans laquelle ce problème peut se produire. Les valeurs par
défaut des paramètres de l’agent de fusion et de fusion (qui sont fortement liées à ce problème) sont
-UploadGenerationsPerBatch -DownloadGenerationsPerBatch 100. Dans l’exemple suivant, supposons que les
paramètres et les -UploadGenerationsPerBatch -DownloadGenerationsPerBatch paramètres n’ont pas été modifiés.
INSERTs se produisent au niveau de l’éditeur de niveau supérieur dans un enfant et un article parent. Un
article enfant est tout article d’une composition qui a une contrainte de clé étrangère à une autre table,
appelée article parent. Ces deux articles sont liés par un filtre de jointeur de réplication de fusion et les
contraintes de clé étrangère côté serveur réelles au niveau de la republier et de l’abonné sont marquées avec
la propriété NOT FOR REPLICATION. Vous pouvez exécuter la sp_help stockée sur les tables pour déterminer
si les contraintes ne sont pas pour la réplication, si vous n’êtes pas sûr.
Les entrées INSERT dans la table enfant se produisent (par exemple) dans la génération 110. Les entrées
INSERT dans la table parente se produisent (par exemple) dans la génération 250. La séparation entre ces
générations est supérieure au -DownloadGenerationsPerBatch paramètre.
L’agent de fusion de republier d’éditeur traite le lot de générations qui contiennent les générations 101 à
200. Une fois le traitement de ce lot réussi et le téléchargement des modifications associées dans ces
générations vers le repudier, l’agent de fusion de republier d’éditeur est interrompu. L’interruption se produit
avant que l’agent de fusion puisse traiter les générations 201 à 300 (contenant les modifications apportées à
l’article parent). L’interruption peut être due à une perte de connectivité réseau, à un délai d’interruption de
requête, etc. L’agent de fusion peut valider les lignes de l’article enfant sans les lignes parentes, car la
contrainte de clé étrangère côté serveur est marquée comme NOT FOR REPLICATION, ce qui « suspend » la
vérification de la contrainte.
Avant que l’agent de fusion republier-éditeur recommence le traitement, l’agent de fusion de republisher-
abonné commence une session de fusion. Il commence le processus de téléchargement des modifications à
partir du republisher.
Lorsque l’agent de fusion de l’abonné à la republier traite la génération 110 (l’article enfant INSERTs), il
évalue le filtre de jointeur présent entre l’article enfant et l’article parent. Étant donné que les modifications
apportées à l’article parent n’ont pas encore été apportées au republier, l’agent de fusion détermine que ces
INSERT enfants ne « qualifient » pas le filtre de jointeur. L’agent de fusion télécharge la
MSmerge_genhistor y qui représente la génération 110, mais aucune des modifications apportées à cette
génération. Cet agent de fusion termine correctement sa session.
Une suite d’une série de l’agent de fusion entre l’éditeur et le republier traite avec succès le lot de
générations qui contiennent l’article parent INSERTs (générations 201 à 300) et valider ces modifications au
niveau de la publication.
Enfin, une session d’agent de fusion ultérieure entre le repudier et l’abonné considère la génération 250 et
télécharge l’article parent INSERTs à l’abonné. Toutefois, étant donné que l’abonné connaît également la
génération 110 (génération de l’article enfant), l’agent de fusion ne réévalue pas la partition de l’article
enfant.
Ainsi, les lignes parent-article correctes sont présentes à l’abonné avec des lignes orphaned enfants au niveau
de la republier.
Message d’erreur lorsque vous utilisez le service de
capture de données microsoft change pour Oracle
par Attunity
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez le service de capture de
données de modification pour Oracle par Attunity.
Version du produit d’origine : SQL Server 2012 Enterprise, SQL Server 2012 Developer
Symptômes
Le service de capture de données microsoft change pour Oracle par Attunity arrête la capture des données
pendant les périodes d’inactivité. Lorsque ce problème se produit, vous recevez le message suivant sous l’onglet
État dans la console de gestion Oracle Change Data Capture Designer :
Tentative de récupération de l’enregistrement de modification suivant à partir de la base de données source
En outre, vous recevez le message suivant lorsque vous essayez d’utiliser le lien Collecter les diagnostics pour
lire la table Xdbcdc_trace dans la base de données SQL SERVER LASO :
OrACDC517E:Oracle Call Interface (OCI) method failed: ORA-00600: internal error code, arguments:
[krvxgintocol11
Cause
Ce problème se produit si la base de données Oracle est la version 11.1.0.7 ou une version antérieure.
Résolution
Téléchargez et installez une mise à jour pour la version existante de la base de données Oracle.
Mettez à jour la base de données Oracle vers la version 11.2.0.1 ou une version ultérieure.
Vous pouvez activer la collecte de données pour détecter le problème décrit dans la section « Symptômes ».
Pour cela, procédez comme suit :
1. Reproduisez le problème.
2. Cliquez sur Collecter les diagnostics sous l’onglet État de la console de gestion Oracle Change Data
Capture Designer.
3. Examinez les fichiers de sortie et les fichiers journaux pour le message d’erreur mentionné dans la section
Symptômes. Par exemple, le message d’erreur mentionné dans la section Symptômes peut apparaître
dans un ou plusieurs des fichiers de sortie suivants :
\app\administrator\diag\rdbms\orclcdc\orclcdc\alert\log.xml
\app\administrator\diag\rdbms\orclcdc\orclcdc\trace\orclcdc_ora_1932.trc
Pour plus d’informations sur le problème, activez le suivi dans la console de gestion Oracle Change Data
Capture Designer. Pour ce faire, ajoutez une nouvelle propriété dans la grille Advanced Paramètres sous
l’onglet Avancé, définissez le nom de la propriété à suivre, puis définissez la valeur sur Source . Une fois que le
problème s’est produit, exécutez la requête suivante pour afficher les données de suivi :
SELECT * FROM xdbcdc_trace
NOTE
Après avoir vu les informations de suivi, supprimez la propriété dans la grille Advanced Paramètres pour éviter les
problèmes de performances.
Références
Pour plus d’informations sur les mises à jour décrites dans la section Résolution, voir My Oracle Support.
produits.
Les déclencheurs de composition Oracle envoient
des données pour les colonnes non publiées lors de
la réplication avec Microsoft SQL Server
Cet article vous aide à résoudre le problème qui se produit lors de l’utilisation de la réplication transactionnelle
avec un Publisher Oracle et le filtrage des colonnes.
Symptômes
Lorsque vous utilisez la réplication transactionnelle avec un Publisher Oracle et le filtrage des colonnes, vous
remarquez que le déclencheur généré par l’Assistant publication (déclencheur de niveau ligne) est le suivi de
toutes les colonnes du tableau, même si seules quelques-unes sont publiées.
Cause
Lorsqu’un filtre vertical est appliqué à une composition créée à l’aide d’un éditeur Oracle configuré avec l’option
Passerelle, SQL Server limite la table de suivi pour n’inclure que les colonnes d’intérêt, mais ne limite pas les
événements déclencheurs. Par conséquent, lorsqu’il existe de nombreuses mises à jour de colonnes de tableau
qui ne sont pas incluses dans la table de suivi, de nombreuses lignes inutiles sont enregistrées dans la table de
suivi.
Vous pouvez contourner le problème en modifiant manuellement le déclencheur de base de données généré sur
la base de données Oracle lors de l’installation de la réplication, afin d’inclure une liste de colonnes explicite
pour limiter les colonnes qui, lors de la mise à jour, déclencheront le déclencheur.
Utilisez la procédure suivante pour implémenter la solution de contournement :
1. Vérifier que l’éditeur Oracle est configuré en tant qu’éditeur de passerelle
2. Marquez la table publiée ou son espace de table associé comme étant en lecture seule.
3. Déterminez le nom du déclencheur de ligne et de la table de journaux associés à la table publiée.
4. Modifiez la clause du déclencheur de ligne qui identifie les conditions de déclenchement afin d’inclure une
liste de colonnes explicite contenant uniquement les colonnes publiées.
5. Restituer la table publiée ou son espace de table associé en lecture-écriture.
Pour plus d’informations sur chaque étape, voir les paragraphes suivants :
Comment marquer la table publiée ou son espace de table associé comme étant en lecture seule :
Avant de modifier le déclencheur, vous devez définir le tableau en lecture seule afin qu’aucune modification ne
soit perdue. Si votre version Oracle est antérieure à 11 g, vous devrez marquer l’espace de table associé au
tableau comme étant en lecture seule. La lecture seule d’un espace de table empêche les opérations d’écriture
sur les filtres de données de l’espace de table. Pour déterminer l’espace de table associé à votre table publiée,
exécutez la requête suivante :
select table_name, tablespace_name from all_tables
where table_name = 'my_table' and owner = 'my_name';
Pour rendre un fichier de données en lecture seule, utilisez une commande semblable à la suivante :
ALTER TABLESPACE my_tablespace READ ONLY;
Dans Oracle 11 g, vous pouvez marquer un tableau en lecture seule directement.
ALTER TABLE my_table READ ONLY;
Comment marquer la table publiée ou son espace de table associé comme étant en lecture seule :
Avant de modifier le déclencheur, vous devez définir le tableau en lecture seule afin qu’aucune modification ne
soit perdue. Si votre version Oracle est antérieure à 11 g, vous devrez marquer l’espace de table associé au
tableau comme étant en lecture seule. La lecture seule d’un espace de table empêche les opérations d’écriture
sur les filtres de données de l’espace de table. Pour déterminer l’espace de table associé à votre table publiée,
exécutez la requête suivante :
select table_name, tablespace_name from all_tables
where table_name = 'my_table' and owner = 'my_name';
Pour rendre un fichier de données en lecture seule, utilisez une commande semblable à la suivante :
ALTER TABLESPACE my_tablespace READ ONLY;
Dans Oracle 11 g, vous pouvez marquer un tableau en lecture seule directement.
ALTER TABLE my_table READ ONLY;
Comment déterminer le nom du déclencheur de ligne et de la table de journaux associés à la table publiée :
Tous les déclencheurs et tables de journal ont des noms créés à partir des modèles suivants :
HREPL_ARTICLE N LOG_ V
HREPL_ARTICLE N_TRIGGER_ROW
où N et V sont déterminés de la manière suivante :
N est le article_id associé à la table publiée, qui peut être obtenu à l’aide de la requête SQL suivante auprès du
distributeur :
select name, table_id from distribution.dbo.IHarticles
V est un moteur de conception de version. Si les tables à deux journaux ont la même valeur associée pour N, le
journal actif a la valeur V la plus élevée.
Modification de la clause du déclencheur de ligne qui identifie les conditions de déclenchement afin d’inclure
une liste de colonnes explicite contenant uniquement les colonnes publiées :
Oracle fournit un outil d’interface graphique graphique gratuit SQL développeur qui est bien adapté pour
apporter les modifications nécessaires au déclencheur généré. Vous pouvez utiliser les étapes suivantes dans
l’outil SQL développeur pour apporter les modifications nécessaires :
1. Ouvrez une connexion à votre instance Oracle.
2. Sous les schémas Oracle définis, développez le schéma correspondant à votre utilisateur d’administrateur
de réplication.
3. Recherchez les déclencheurs dans la liste des objets et développez-le pour voir la liste des déclencheurs
dont est propriétaire l’utilisateur de l’administrateur de réplication.
4. Recherchez le déclencheur à modifier et mettez-le en surbrillez. Le texte du déclencheur s’affiche dans le
volet droit.
5. Cliquez avec le bouton droit sur le nom du déclencheur dans la liste et sélectionnez Modifier
6. La modification de la définition du déclencheur est réalisée près du début du déclencheur, qui
ressemblera à ce qui suit :
.. créer ou remplacer LE DÉCLENCHEUR APRÈS LA SUPPRESSION OU L’INSERTION OU LA MISE À
JOUR DE
my_name.my_table
POUR CHAQUE LIGNE...
7. Pour modifier le déclencheur, incluez après le mot clé UPDATE la liste des colonnes du tableau publié qui
ont été incluses dans l’article. Si vous développez tables sous le schéma d’administrateur de repl, puis
développez la table des journaux d’articles associée à la table publiée, les colonnes à inclure sont celles
qui apparaissent dans le journal après les cinq colonnes de métadonnation initiales précédées de HREPL_.
Le mot ON doit apparaître au début de la liste des colonnes. Les modifications nécessaires pour le
tableau my_name.my_table avec les colonnes publiées PK, c1 et c2 sont indiquées ci-dessous.
create or replace TRIGGER AFTER DELETE OR INSERT OR UPDATE ON "PK", "c1", "c2" OF my_name.my_table
FOR EACH ROW...
8. Lorsque vous avez terminé la modification, cliquez avec le bouton droit sur le nom du déclencheur et
sélectionnez Compiler pour compiler votre déclencheur révisé. Assurez-vous que le déclencheur résultant
est identifié comme étant valide après la compilation.
Comment restaurer la table publiée ou son espace de table associé pour lire l’écriture :
Après avoir effectué la modification du déclencheur, veillez à restaurer l’espace de table ou la table en LECTURE
ÉCRITURE, en fonction de ce qui a été marqué EN LECTURE SEULE. L’instruction suivante rend l’espace
my_tablespace de table accessible en my_tablespace :
ALTER TABLESPACE *my_tablespace* READ WRITE;
Dans Oracle 11 g, utilisez la commande modifier la table pour restaurer la table afin d’autoriser les
modifications :
ALTER TABLE *my_table* READ WRITE;
Utilisez la requête suivante dans Oracle 11 g pour vérifier que la table publiée n’est plus en lecture seule :
select table_name, read_only
from dba_tables
where table_name = 'my_table' and owner = 'my_owner'
Clause d’exclusion de responsabilité tierce

produits.
Présentation des outils de statistiques de
performances pour le lecteur de journaux de
réplication et les agents de distribution de
réplication
Cet article présente les outils de statistiques de performances pour le lecteur de journaux de réplication et
l’agent de distribution SQL Server.
Introduction
Des statistiques de performances ont été ajoutées à la table et à la table sur la base de données de
mslogreader_history msdistribution_history distribution dans Microsoft SQL Server. Vous pouvez utiliser ces
statistiques pour consulter l’historique des performances récent des agents de lecture de journaux de réplication
et de distribution de réplication.
NOTE
Ces modifications ont été apportées pour la première fois dans les builds SQL Server suivantes :
9.00.4220
9.00.3315
10.00.1806
10.00.2714
Toutes les cinq minutes, les statistiques de performances pour le lecteur de journaux et les agents de distribution
sont enregistrées dans les tableaux d’historique. Par défaut, seules les données des dernières 48 heures sont
conservées. Un processus de nettoyage supprime les données de plus de 48 heures. La valeur par défaut peut
être modifiée en exécutant la procédure stockée et en spécifiant une sp_changedistributiondb nouvelle valeur
pour le history_retention paramètre.
Voici un exemple de sortie de performances du tableau d’historique pour l’agent de lecture de journaux :
<stats state="1" work="9" idle="295"> <reader fetch="8" wait="0"/> <writer write="9" wait="0"/>
<sincelaststats elapsedtime="304" work="9" cmds="52596" cmdspersec="5753.000000"> <reader fetch="8"
wait="0"/> <writer write="9" wait="0"/> </sincelaststats> </stats>
Trois événements d’état peuvent être enregistrés :
ÉTAT DESC RIP T IO N
1 Événements normaux qui décrivent les performances des

threads lecteur et rédacteur.
ÉTAT DESC RIP T IO N
2 Événements qui se produisent lorsque le thread de lecteur

d’un agent attend plus longtemps que le temps de
-messageinterval l’agent. (Par défaut, la durée est de 60
secondes.) Si vous remarquez des événements d’état 2
enregistrés pour un agent, cela indique que l’agent prend
beaucoup de temps pour écrire les modifications apportées
à la destination.
3 Événements générés uniquement par l’agent de lecture de

journaux lorsque le thread rédacteur attend plus longtemps
-messageinterval que le temps. Si vous remarquez des
événements d’état 3 enregistrés pour l’agent de lecture de
journaux, cela indique que l’analyse des modifications
répliquées à partir du journal des transactions prend
beaucoup de temps.
Thread de lecteur de l’agent de distribution

Les statistiques de performances suivantes montrent une situation dans laquelle il existe une latence dans la
topologie de réplication et dans laquelle le goulot d’étranglement est le thread de lecteur de l’agent de
distribution. Ce thread interroge la base de données de distribution (< Serveur de distribution
>..MSdistribution_history.Comments table) pour obtenir les commandes à appliquer à l’abonné.
<stats state="1" work="14798" idle="2035">

<reader fetch="14798" wait="193"/>
<writer write="12373" wait="9888"/>
<sincelaststats elapsedtime="424" work="415" cmds="296900" cmdspersec="713.000000">
</sincelaststats>
</stats>
Le sincelaststats délai d’attente du rédacteur (212 secondes) apparaît élevé. Il s’agit du moment où le thread
rédacteur attend que le thread de lecteur fournisse des mémoires tampons que le thread rédacteur peut
appliquer dans la base de données d’abonnés. Le thread de lecteur de l’agent de distribution exécute la
sp_MSget_repl_commands procédure stockée.
Si vous remarquez des temps d’attente élevés pour les rédacteurs dans les statistiques de performances de
l’agent de distribution, vous devez examiner les performances de l’exécution de l’agent de distribution par
rapport au serveur de distribution et à la base de données. En particulier, vous devez examiner l’heure
d’exécution de sp_MSget_repl_commands la procédure stockée.
Fil de discussion rédacteur de l’agent de distribution

topologie de réplication et dans laquelle le goulot d’étranglement est le thread de lecteur de l’agent de
distribution. Ce thread interroge la base de données de distribution (< Serveur de distribution
>..MSdistribution_history.Comments table) pour obtenir les commandes à appliquer à l’abonné.
NOTE
L’état est 2 et le résultat est légèrement différent des statistiques d’état 1. Les données d’état de l’état 2 indiquent que le
thread de lecteur a dû attendre plus longtemps que la valeur configurée de l’agent de -messageinterval distribution.
Par défaut, la -messageinterval valeur est de 60 secondes.
<stats state="2" fetch="48" wait="384" cmds="1028" callstogetreplcmds="321">

<sincelaststats elapsedtime="312" fetch="47" wait="284" cmds="1028" cmdspersec="3.000000"/>
</stats>
Si la valeur est augmentée, vous pouvez recevoir de nouveau des statistiques -messageinterval d’état 1
<stats state="1" work="1941" idle="0">

</sincelaststats>
</stats>
NOTE
Le délai d’attente d’extraction sincelaststats de 505 secondes est très élevé.
Si vous remarquez des temps d’attente de lecture élevés dans les statistiques de performances de l’agent de
distribution, vous devez examiner les performances de l’exécution de l’agent de distribution par rapport au
serveur abonné et à la base de données. Utilisez l’outil de suivi du profileur pour examiner les performances de
l’exécution des procédures stockées de réplication. En règle générale, les procédures stockées sont nommées
comme suit :
sp_MSupd_<owner tablename >
sp_MSins_<owner tablename >
sp_MSdel_<owner tablename >
En outre, pour déterminer si le goulot d’étranglement est basé sur le matériel ou sur le système, utilisez l’écran
de performances pour surveiller les performances du système. Par exemple, utilisez l’écran de performances
pour surveiller les compteurs de disque physique.
Thread de lecteur de l’Agent de lecture de journaux

topologie de réplication et dans laquelle le goulot d’étranglement est le thread de lecteur de l’agent de lecture
de journaux. Le thread lecteur de l’Agent de lecture de journaux analyse le journal des transactions de la base de
données publiée pour trouver les commandes à remettre à la base de données de distribution.
<Distribution server>..MSlogreader_history.Comments
<stats state="1" work="301" idle="0" >

</sincelaststats>
</stats>
La statistique d’attente de l’auteur sincelaststats de 288 secondes apparaît élevée. Il s’agit du moment où le
thread rédacteur attend que le thread lecteur fournisse des mémoires tampons à appliquer. Le thread lecteur de
l’Agent de lecture de journaux exécute la sp_replcmds procédure stockée. Si vous remarquez des threads
d’attente de rédacteur élevés dans les statistiques de performances de l’Agent de lecture de journaux, vous devez
examiner les performances de l’exécution de l’agent de lecture de journaux sur le serveur de publication et la
base de données, puis examiner la durée d’exécution de la procédure sp_replcmds stockée.
Voici la description de chaque statistique de performances :
STAT IST IQ UE ÉTAT DESC RIP T IO N
État État 1 : cet état indique que le rapport

de performances est normal après une
validation par lot.
État 2 : le thread lecteur indique

qu’une lecture par lot attend plus
longtemps que la valeur de la
messageinterval propriété.
État 3 : le thread Writer indique qu’une

écriture par lot attend plus longtemps
que la -messageinterval valeur.
cmds 2 uniquement Cet état indique le nombre de

commandes lues par l’agent de
distribution.
callstogetreplcmds 2 uniquement Cet état indique le nombre d’appels à

la procédure stockée par
sp_MSget_repl_commands l’agent de
distribution.
travail La valeur représente le temps cumulé

passé par l’agent au travail depuis le
dernier démarrage de l’agent. Le temps
d’inactivité est exclu.
idle La valeur représente le temps cumulé

que l’agent attend pour appeler la
procédure stockée lorsque l’appel
précédent ne renvoie aucune
transaction ou lorsque le nombre de
transactions est inférieur à la valeur de
la propriété depuis le dernier
démarrage de sp_replcmds
MaxTrans l’agent.
fetch de lecteur La valeur représente le temps cumulé

passé par le lecteur depuis le dernier
démarrage de l’agent. Le temps
d’inactivité est exclu et le temps
d’attente du rédacteur.
attente du lecteur La valeur représente le temps d’attente

cumulé du rédacteur depuis le dernier
démarrage de l’agent. La valeur
indique le temps passé à attendre la fin
de l’utilisation du thread rédacteur à
l’aide de la mémoire tampon de
données avant que le lecteur puisse
remplir à nouveau la mémoire tampon
de données.
écriture de rédacteur La valeur représente le temps cumulé

passé par le rédacteur depuis le dernier
démarrage de l’agent. Cette durée
exclut le temps d’inactivité et le temps
d’attente du lecteur.
Pour l’attente du rédacteur, cette

valeur représente le temps d’attente
du lecteur depuis le dernier démarrage
de l’agent. La valeur indique le temps
passé à attendre que le thread de
lecteur termine le remplissage de la
mémoire tampon de données avant
que le rédacteur puisse appliquer la
mémoire tampon de données.
sincelaststats_elapsed_time Le nœud sincelaststats affiche des

statistiques similaires pour la période
commençant au dernier événement
stats enregistré. Par défaut, la période
est de cinq minutes. Le temps
d’inactivité est exclu. La valeur
représente le temps écoulé depuis le
dernier événement stats enregistré.
travail sincelaststats La valeur représente le temps passé

par l’agent depuis le dernier
événement stats.
cmds sincelaststats La valeur représente le nombre de

commandes depuis le dernier
événement stats.
sincelaststats cmdspersec La valeur représente le nombre de

commandes exécutées par seconde
depuis le dernier événement stats.
sincelaststats\reader fetch La valeur représente le temps cumulé

passé par le lecteur depuis le dernier
événement stats. Le temps d’inactivité
est exclu et le temps d’attente du
rédacteur.
sincelaststats\reader wait La valeur représente le temps d’attente

cumulé du rédacteur depuis le dernier
événement stats. La valeur indique le
temps passé à attendre que le thread
rédacteur se termine à l’aide de la
mémoire tampon de données pour
que le lecteur puisse remplir à nouveau
la mémoire tampon de données.
sincelaststats\writer La valeur représente le temps cumulé

passé par l’auteur depuis le dernier
événement stats. Cette durée exclut le
temps d’inactivité et le temps d’attente
du lecteur.
sincelaststats\writer wait La valeur représente le temps d’attente

du lecteur depuis le dernier événement
stats. La valeur indique le temps passé
à attendre que le thread de lecteur
termine le remplissage de la mémoire
tampon de données avant que le
rédacteur puisse appliquer la mémoire
tampon de données.
Script pour charger les MSlogreader_history et MSdistribution_history

exécuter des statistiques à partir de données XML dans une table qui
peut être interrogé facilement
Il existe quatre exemples de script qui vous aident à extraire les statistiques de performances dans un tableau
permanent qui peut être facilement interrogé. Il existe également une procédure stockée qui met
approximativement en corrélation les statistiques de performances de l’Agent de lecture de journaux avec les
statistiques de performances de l’agent de distribution (c’est-à-dire, le perf_stats_tab tableau).
Pour obtenir les exemples de script, consultez cet exemple et cliquez sur KB2892631.zip, puis décompressez les
fichiers KB2892631.zip, vous verrez les quatre fichiers de script suivants :
Version d’origine du fichier Perf_stats_script.sql : perf_stats_script.sql
Fichier Usp_move_stats_to_table.sql révisé : usp_move_stats_to_table.sql
Fichier Sp_endtoend_stats.sql révisé : sp_endtoend_stats.sql
Un autre script pour lire les données en temps réel ou à partir d’une sauvegarde de base de données de
distribution : Additional_Script.sql
NOTE
Le tableau contient des statistiques de performances pour l’agent de lecture de journaux perf_stats_tab et l’agent
de distribution. Les statistiques peuvent être interrogés indépendamment à l’aide de la WHERE TYPE='Distrib' clause
ou de la WHERE TYPE='LogRead' clause.
La procédure stockée ouvre un curseur sur la table et la table, puis appelle la procédure stockée pour chaque ligne afin
d’extraire les données statistiques de performances XML dans le move_stats_to_tab mslogreader_history
msdistribution_history move_stats_to_tab perf_stats_tab tableau.
Les abonnements pull ne s’affichent pas dans
Windows Synchronization Manager
S’applique à : SQL Server 2019, SQL Server 2017, SQL Server 2016, SQL Server 2014
Symptômes
Supposons que vous créez un abonnement pull à une composition de fusion. Après l’activation de la
synchronisation avec Windows Synchronization Manager,aucun abonnement n’est répertorié dans le Centre de
synchronisation (mobsync.exe) de l’abonné.
NOTE
Cette solution de contournement s’applique uniquement SQL serveurs avec une seule instance.
IMPORTANT
Suivez attentivement les étapes de cette section. Des problèmes graves peuvent se produire si vous modifiez le Registre
de façon incorrecte. Avant de le modifier, vous devez le restaurer.
Voici comment contourner ce problème :

1. Dans la zone de recherche de la barre des tâches, tapez regedit, puis sélectionnez Éditeur du Registre
(application de bureau) dans les résultats pour ouvrir l’Éditeur du Registre dans Windows 10.
2. Recherchez et sélectionnez la sous-clé de Registre :
HKLM\Software\Microsoft\Windows\CurrentVersion\SyncMgr\Handlers\{FFAADE58-9A14-45F3-A497-E969A64F09C7}
.
3. Renommez le nom de la sous-clé en fonction de la version SQL Server suivante :
SQ L SERVER VERSIO N VA L EUR DU H A N DL ER DU REGIST RE
SQL Server 2014 D6133761-E626-4DF7-90F6-7DDD8FCCB926
SQL Server 2016 E828F4BF-6E5C-4549-A3BA-CF53F6A60819
SQL Server 2017 C96C286D-DFC0-4CF0-9CF8-7D582094D263
SQL Server 2019 B1544C19-71BD-417C-8DE2-430A0CDCEA06

Certains agents SQL Server réplication de serveur
ne peuvent pas s’exécuter lorsque vous configurez
de nombreux agents de réplication pour qu’ils
s’exécutent sur un serveur
Cet article vous aide à contourner le problème où certains agents de réplication ne peuvent pas s’exécuter
lorsque vous configurez de nombreux agents de réplication SQL Server pour qu’ils s’exécutent sur un serveur.
Symptômes
Vous configurez de nombreux Microsoft SQL Server agents de réplication 2014 SQL Server 2012 pour qu’ils
s’exécutent sur un serveur. Par exemple, vous configurez plus de 200 agents de réplication pour qu’ils
s’exécutent sur un serveur.
Dans ce scénario, certains agents de réplication ne peuvent pas s’exécuter. En outre, le message d’erreur suivant
est consigné dans le journal système :
Erreur de l’application : l’application n’a pas réussi à s’initialiser correctement (0xc0000142).

Cliquez sur OK pour terminer l’application.
Cause
Ce problème se produit parce que le tas de bureau est utilisé.
Utiliser des comptes distincts pour les agents de réplication créés pour différentes bases de données
Vous pouvez le spécifier lors de la création d’agents de réplication. Vous devez vous assurer que tous les points
tactiles des autorisations sont pris en charge. La procédure de modification des paramètres de sécurité pour les
agents de réplication déjà créés se trouve dans l’affichage et la modification des paramètres de sécurité de
réplication.
Utiliser les paramètres du Registre pour augmenter la taille du tas de bureau
Vous pouvez modifier les entrées de Registre suivantes :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SessionViewSize
(par exemple, augmentez la valeur de 48 à 64).
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows (par exemple,
augmentez la troisième valeur SharedSection de 256 kilo-octets)
Vous devez appliquer les modifications sur les deux nodes. Vous devez enregistrer les clés de Registre avant la
modification et redémarrer le serveur après avoir appliqué la modification.
Modifier les agents de réplication de l’exécution continue à l’exécution sur une base programmée
Cela permet de s’assurer que les agents de réplication s’exécutent uniquement lorsqu’il est nécessaire et de ne
pas rester inactifs en permanence (car cela fait perdre des ressources).
Des instructions sur la modification de la planification de l’agent de réplication sont disponibles dans Spécifier
les planifications de synchronisation.
Modifier l’emplacement du serveur sur lequel les agents de réplication sont en cours d’exécution
Vous pouvez évaluer les paires éditeur-abonné et voir si vous pouvez modifier certains abonnés pour effectuer
un pull qui exécutera l’agent de distribution/fusion sur l’abonné plutôt que sur l’éditeur. Cela permet de réduire
le nombre d’agents simultanés qui doivent s’exécuter sur le serveur.
Statut
Comment examiner l’utilisation du tas de bureau

Chaque compte qui démarre le service SQL Server Agent de bureau correspond à un tas de bureau
noninteractive. En outre, tous les agents de réplication gérés par le service agent SQL Server partagent le tas de
bureau du compte.
Vous pouvez utiliser l’outil Moniteur de tas de bureau pour examiner l’utilisation du tas de bureau. Ensuite, vous
pouvez décider si vous devez augmenter ou réduire la taille du tas de bureau non actif. En règle générale, vous
devez augmenter la taille.
IMPORTANT
L’outil Moniteur de tas de bureau ne fonctionne pas dans Windows Server 2008 ou une version ultérieure de Windows. Si
vous utilisez l’une de ces versions de Windows, vous pouvez utiliser LiveKD pour obtenir des valeurs de tas de bureau.
Pour plus d’informations sur la façon de le faire, allez à la section suivante.
Pour utiliser l’outil Moniteur de tas de bureau pour examiner l’utilisation du tas de bureau, suivez les étapes
suivantes :
1. Téléchargez l’outil Moniteur de tas de bureau.
2. Installez l’outil Moniteur de tas de bureau. Pour cela, procédez comme suit :
a. Double-cliquez sur le package pour extraire les fichiers.
b. Cliquez sur Démarrer, cliquez sur Exécuter, tapez cmd, puis cliquez sur OK.
c. Depuis l'invite de commandes, exécutez la commande suivante :
CD ExtractFolder\kktools\dheapmon8.1\Platform
NOTE
ExtractFolder est un espace réservé pour le dossier dans lequel vous extrayez les fichiers. La plateforme
est un espace réservé pour le nom du dossier qui correspond à la plateforme spécifique.
d. Exécutez la commande suivante :
dheapinst.exe -y srv*http://msdl.microsoft.com/download/symbols
3. Chargez le pilote. Pour ce faire, exécutez la commande suivante :
dheapmon.exe -l
4. Exécutez l’outil Moniteur de tas de bureau. Pour ce faire, exécutez la commande suivante :
dheapmon.exe -s
La sortie ressemble à ce qui suit :
Desktop Heap Information Monitor Tool (Version 8.1.2925.0)

Copyright (c) Microsoft Corporation. All rights reserved.
-------------------------------------------------------------
Session ID: 0
Total Desktop: ( 7872 KB - 12 desktops)
WinStation\Desktop Heap Size(KB) Used Rate(%)
-------------------------------------------------------------
WinSta0\Default 3072 24.2
WinSta0\Disconnect 64 4.5
WinSta0\Winlogon 128 10.0
Service-0x0-3e7$\Default 512 40.9
SAWinSta\SADesktop 512 0.5
__X78B95_89_IW\__A8D9S1_42_ID 512 0.5
Service-0x0-1d419$\Default 512 2.4
Service-0x0-1da0b$\Default 512 2.4
Service-0x0-25c2e$\Default 512 13.5
Service-0x0-2461f$\Default 512 98.6
-------------------------------------------------------------
Dans cette sortie, l’élément représente le compte qui démarre le Service-0x0-2461f$\Default service SQL
Server Agent. Tous les agents de réplication s’exécutent dans le contexte de sécurité de ce compte. Si vous
exécutez davantage d’agents de réplication, l’utilisation du tas de bureau augmente. Si l’utilisation du tas de
bureau est de plus de 98 ou 99 %, aucune ressource de tas de bureau ne peut être allouée. Par conséquent, vous
ne pouvez pas démarrer de nouveaux agents de réplication.
Dans ce résultat, l’utilisation du tas de bureau du compte est de 98,6 %. Dans ce cas, augmentez la taille du tas
de bureau non actif en augmentant la troisième valeur du SharedSection paramètre. Après avoir augmenté la
troisième valeur, le problème est résolu après le redémarrage du serveur. Ensuite, vous pouvez utiliser l’outil
Moniteur de tas de bureau pour vérifier si la nouvelle valeur s’adaptera à tous les agents de réplication.
Nous recommandons que l’utilisation du tas de bureau reste entre 80 et 90 %. Si vous augmentez la troisième
valeur du paramètre, nous vous recommandons d’augmenter la valeur SharedSection de 512 à chaque fois.
Étapes à suivre pour utiliser LiveKD afin d’éumer les valeurs de tas de
bureau
1. Téléchargez les outils de débogage Windows dans le cadre du SDK.
2. Sdksetup.exe Exécutez, puis installez Outils de débogage pour Windows.
3. Téléchargez LiveKD.
4. Créez un C:\debugger dossier.
5. Copiez tous les fichiers de l’emplacement où vous avez installé les outils de débogage dans C:\debugger .
Le chemin d’accès par défaut C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64 est .
6. Extrayez LiveKD dans C:\debugger .
7. Ouvrez une invite de commandes avec des autorisations élevées.
8. Exécutez la commande suivante à partir de l’invite de commandes :
livekd -y srv*http://msdl.microsoft.com/download/symbols
9. Vous devez recevoir une sortie semblable à ce qui suit :
LiveKd v5.3 - Execute kd/windbg on a live system

Sysinternals -[www.sysinternals.com](http://www.sysinternals.com/)
Copyright (C) 2000-2012 Mark Russinovich and Ken Johnson
Launching C:\Debugger\kd.exe:
Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\livekd.dmp]
Kernel Complete Dump File: Full address space is available
Comment: 'LiveKD live system view'
Symbol search path is: srv*http://msdl.microsoft.com/download/symbols
Executable search path is:
Product: Server, suite:
Built by:
Machine Name:
Kernel base =
Debug session time:
System Uptime:
Loading Kernel Symbols
...............................................................
Loading User Symbols
...................................................
Loading unloaded module list
......Unable to enumerate user-mode unloaded modules, NTSTATUS 0xC0000147
10. Exécutez !dskheap pour recevoir la sortie suivante :
kd> !dskheap
*** ERROR: Module load completed but symbols could not be loaded for LiveKdD.SYS
Winstation\Desktop Heap Size(KB) Used Rate(%)
------------------------------------------------------------
WinSta0\Default 20480 0%
WinSta0\Disconnect 96 4%
WinSta0\Winlogon 192 2%
Service-0x0-3e7$\Default 768 1%
Service-0x0-3e4$\Default 768 0%
Service-0x0-3e5 $\Default 768 0%
Service-0x0-10a75$\Default 768 0%
------------------------------------------------------
Total Desktop: (23840 KB - 7 desktops)
Session ID: 0
============================================================
11. Décodez la connexion chiffrée en faisant ce qui suit :

a. "3e5$Service-0x0- 3e5 $\Default" -> 0x3e5 == 997 .
b. Ouvrez wbemtest à partir de la commande Exécuter dans Windows.
c. Connecter à root\cimv2 l’espace de noms.
d. Cliquez sur Requête, puis tapez select * from win32_logonsession .
e. Double-cliquez sur l’entrée qui contient 997.
f. Sélectionnez UUID dans l’éditeur d’objets, puis cliquez sur Associators pour afficher le nom réel
de la logon. Reportez-vous à la capture d’écran suivante :
Éléments à prendre en compte si vous utilisez le protocole Bureau à

distance
Si vous vous connectez au serveur à l’aide du protocole RDP (Remote Desktop Protocol), veillez à créer la
session console à l’aide du /console commutateur. Si vous n’utilisez pas le /console commutateur, vous ne
pouvez pas voir le Bureau. Cela est dû au fait que le compte qui démarre le service SQL Server agent est associé
à la session 0.
Le pilote Win32k.sys alloue 48 Mo d’espace d’adressare tampon pour le tas de bureau. Assurez-vous que vous
n’avez pas beaucoup de bureaux qui utilisent l’intégralité de 48 Mo d’espace d’adressare de mémoire tampon.
Si le serveur n’est pas configuré en tant que serveur Terminal Server, tous les tas de bureau partagent l’espace
d’adressare de mémoire tampon de 48 Mo. Cela limite le nombre de processus de service qui peuvent s’exécuter
sur le serveur.
Si le serveur est configuré en tant que serveur Terminal Server, le pilote Win32k.sys alloue 20 Mo d’espace
d’adressare mémoire tampon pour le tas de bureau. Le Win32k.sys de session alloue également 16 Mo d’espace
de session à son propre pool paginé.
Différences entre un serveur Terminal Server et les services Terminal

Server en ce qui concerne le tas de bureau
Un serveur Terminal Server et des services Terminal Server sont différents. Vous installez le composant Terminal
Server dans Ajouter ou supprimer des programmes. Après avoir installé le composant Terminal Server, le
serveur devient un serveur Terminal Server. Les services Terminal Services sont un service qui existe dans le
logiciel en snap-in MMC (Microsoft Management Console) services. Si vous supprimez le composant Terminal
Server du serveur, les ordinateurs clients peuvent toujours se connecter au serveur à l’aide de RDP. Par
conséquent, envisagez de supprimer le composant Terminal Server pour obtenir les 48 Mo d’espace
d’adressager de mémoire tampon pour le tas de bureau.
Impact des travaux dans SQL Server 2005 sur le tas de bureau
Dans SQL Server 2005, vous pouvez avoir différents travaux qui s’exécutent sous différents comptes proxy. Pour
chaque compte proxy, le tas de bureau non actif pour ce compte proxy sera alloué. Par exemple, la troisième
valeur du paramètre SharedSection est 512. Si vous utilisez un compte proxy pour démarrer un travail, le tas de
bureau de 512 Ko sera alloué, même si le travail lui-même n’utilise que 10 Ko du tas de bureau.
NOTE
Les autres travaux qui utilisent le même compte proxy utiliseront toujours ce tas de bureau.
Cela peut entraîner de nombreux bureaux lorsque le service SQL Server agent est démarré. Par conséquent,
l’espace d’adressare de mémoire tampon de 48 Mo peut être utilisé. Si vous utilisez l’outil Moniteur de tas de
bureau pour examiner l’utilisation du tas de bureau, vous remarquerez qu’un bureau correspond à un compte
proxy utilisé par un travail en cours d’exécution. Nous vous recommandons d’utiliser moins de comptes proxy
pour éviter d’atteindre la limite de 48 Mo.
Références
Pour plus d’informations sur les valeurs du paramètre, voir SharedSection User32.dll ou
Kernel32.dll'initialisation échoue.
Échec de la fusion de la capture instantanée de
composition avec erreur d’échec de script SQL
Server
Cet article vous aide à contourner l’erreur d’échec du script qui se produit lors de la création d’un instantané de
composition de fusion.
Symptômes
Dans SQL Server 2014 ou 2012, vous créez une composition de fusion qui contient un tableau avec un type de
données de géométrie ou de géographie. Pour copier votre index spatial, vous avez donné la valeur True à
l’option Copier les index spatials de l’article afin que la fusion réplique les index spatials. Toutefois, lorsque la
capture instantanée s’exécute, elle échoue. Si vous démarrez le Moniteur de réplication et que vous analysez
l’éditeur et la composition, recherchez l’agent de capture instantanée et affichez les détails de l’exécution de la
capture instantanée, le message d’erreur suivant s’affiche :
Source: Microsoft.SqlServer.Smo
Target Site: System.Collections.Generic.IEnumerable`1[System.String]
ScriptWithList(Microsoft.SqlServer.Management.Smo.DependencyCollection,
Microsoft.SqlServer.Management.Smo.SqlSmoObject[], Boolean)
>Message: Script failed for Server 'CMSQL'.
Stack: at Microsoft.SqlServer.Management.Smo.Scripter.ScriptWithList(DependencyCollection depList,
SqlSmoObject[] objects, Boolean discoveryRequired)
at Microsoft.SqlServer.Management.Smo.Scripter.EnumScriptWithList(SqlSmoObject[] objects)
at Microsoft.SqlServer.Replication.Snapshot.SmoScriptingManager.ScriptIndexList(Scripter scripter,
SqlSmoObject[] smoObjectList)
at
Microsoft.SqlServer.Replication.Snapshot.MergeSmoScriptingManager.GenerateTableArticleDriScriptWithSingleBat
chConstraints(Scripter scripter, BaseArticleWrapper articleWrapper, Table smoTable)
at
Microsoft.SqlServer.Replication.Snapshot.MergeSmoScriptingManager.GenerateTableArticleScripts(ArticleScripti
ngBundle articleScriptingBundle)
at
Microsoft.SqlServer.Replication.Snapshot.MergeSmoScriptingManager.GenerateArticleScripts(ArticleScriptingBun
dle articleScriptingBundle)
at Microsoft.SqlServer.Replication.Snapshot.SmoScriptingManager.GenerateObjectScripts(ArticleScriptingBundle
articleScriptingBundle)
at Microsoft.SqlServer.Replication.Snapshot.SmoScriptingManager.DoScripting()
at Microsoft.SqlServer.Replication.Snapshot.SqlServerSnapshotProvider.DoScripting()
at Microsoft.SqlServer.Replication.Snapshot.MergeSnapshotProvider.DoScripting()
at Microsoft.SqlServer.Replication.Snapshot.SqlServerSnapshotProvider.GenerateSnapshot()
at Microsoft.SqlServer.Replication.SnapshotGenerationAgent.InternalRun()
at Microsoft.SqlServer.Replication.AgentCore.Run() (Source: Microsoft.SqlServer.Smo, Error number: 0)
Get help: `http://help/0`
Source: Microsoft.SqlServer.Smo
Target Site: Void CheckTargetVersion(Microsoft.SqlServer.Management.Smo.SqlServerVersionInternal,
Microsoft.SqlServer.Management.Smo.SqlServerVersionInternal, System.String)
Message: Error with spatial index [IX_GeographicEntity_Outline]. GEOMETRY_AUTO_GRID and GEOGRAPHY_AUTO_GRID
are not supported in SQL Server 2008.
Stack: at Microsoft.SqlServer.Management.Smo.SqlSmoObject.CheckTargetVersion(SqlServerVersionInternal
targetVersion, SqlServerVersionInternal upperLimit, String exceptionText)
at Microsoft.SqlServer.Management.Smo.Index.SpatialIndexScripter.ScriptIndexDetails(StringBuilder sb)
at Microsoft.SqlServer.Management.Smo.Index.IndexScripter.GetCreateScript()
at Microsoft.SqlServer.Management.Smo.Index.ScriptDdl(StringCollection queries, ScriptingPreferences sp,
Boolean notEmbedded, Boolean createStatement)
at Microsoft.SqlServer.Management.Smo.Index.ScriptCreate(StringCollection queries, ScriptingPreferences sp)
at Microsoft.SqlServer.Management.Smo.SqlSmoObject.ScriptCreateInternal(StringCollection query,
ScriptingPreferences sp, Boolean skipPropagateScript)
at Microsoft.SqlServer.Management.Smo.ScriptMaker.ScriptCreateObject(Urn urn, ScriptingPreferences sp,
ObjectScriptingType& scriptType)
at Microsoft.SqlServer.Management.Smo.ScriptMaker.ScriptCreate(Urn urn, ScriptingPreferences sp,
ObjectScriptingType& scriptType)
at Microsoft.SqlServer.Management.Smo.ScriptMaker.ScriptCreateObjects(IEnumerable`1 urns)
at Microsoft.SqlServer.Management.Smo.ScriptMaker.DiscoverOrderScript(IEnumerable`1 urns)
at Microsoft.SqlServer.Management.Smo.ScriptMaker.ScriptWorker(List`1 urns, ISmoScriptWriter writer)
at Microsoft.SqlServer.Management.Smo.ScriptMaker.Script(DependencyCollection depList, SqlSmoObject[]
objects, ISmoScriptWriter writer)
at Microsoft.SqlServer.Management.Smo.Scripter.ScriptWithListWorker(DependencyCollection depList,
SqlSmoObject[] objects, Boolean discoveryRequired)
at Microsoft.SqlServer.Management.Smo.Scripter.ScriptWithList(DependencyCollection depList, SqlSmoObject[]
objects, Boolean discoveryRequired) (Source: Microsoft.SqlServer.Smo, Error number: 0)
Get help: `http://help/0`
Cause
SQL Server ne prend pas en charge les index spatials définis avec le GEOMETRY_AUTO_GRID ou les
GEOGRAPHY_AUTO_GRID mots clés.
Lorsque vous créez une composition dans SQL Server 2012 ou SQL Server 2014, le paramètre de niveau de
compatibilité ascendante () de la composition autorise les @publication_compatibility_level paramètres de
90RTM et 100RTM. Par conséquent, la compatibilité avec SQL Server 2008 est forcée lorsque vous créez une
composition de fusion. Toutefois, en raison de la compatibilité ascendante avec SQL Server 2008, les index
spatials ne peuvent pas être copiés.
Pour continuer à utiliser ce type de données dans une composition de fusion, utilisez l’une des solutions de
contournement suivantes :
Définissez l’index spatial à l’aide du ou des mots GEOMETRY_GRID clés à la place de ou GEOGRPAHY_GRID
GEOMETRY_AUTO_GRID GEOGRAPHY_AUTO_GRID .
Lorsque vous définissez la composition, configurez l’article qui est défini avec un index spatial, en configurant
l’option Copier les index spatials sur False . Ensuite, une fois les abonnements créés et initialisés, créez
manuellement l’index spatial dans la table des abonnés.
S’applique à
Utiliser le paramètre -SkipErrors dans l’agent de
distribution
Cet article présente l’utilisation des -SkipErrors paramètres dans l’agent de distribution.
Résumé
Microsoft SQL Server inclut le nouveau paramètre dans l’agent de distribution qui permet à l’agent de
distribution d’ignorer l’erreur indiquée dans la réplication transactionnelle et de poursuivre -SkipErrors le
processus de distribution.
L’extrait suivant est extrait de la rubrique Handling Agent Errors dans SQL Server Books Online :
Dans le cadre d’un traitement de réplication classique, vous ne devez pas faire l’objet d’erreurs qui doivent être
ignorées. La possibilité d’ignorer les erreurs lors de la réplication transactionnelle est disponible dans les
circonstances uniques où vous attendez des erreurs et ne souhaitez pas qu’elles affectent la réplication (par
exemple, lors du recalcalage vers une Publisher secondaire lors de la livraison des journaux de transaction).
Microsoft recommande d’utiliser ce paramètre avec précaution et uniquement lorsque vous avez une bonne
connaissance des sujets suivants :
Ce que l’erreur indique.
Raison pour laquelle l’erreur se produit.
Pourquoi est-il préférable d’ignorer l’erreur au lieu de la résoudre ?
Si vous ne connaissez pas les réponses à ces éléments, une utilisation inappropriée du paramètre peut
provoquer une incohérence de données entre le Publisher -SkipErrors et l’abonné. Cet article décrit certains
problèmes qui peuvent se produire lorsque vous utilisez le paramètre de manière -SkipErrors incorrecte.
Dans la réplication transactionnelle, les modifications de données au niveau Publisher sont propagées à
l’abonné dans l’unité de transaction.
Dans une transaction, il peut y avoir plusieurs commandes. Par défaut, en cas d’échec d’une commande,
l’intégralité de la transaction de réplication est revenir à l’abonné. Si vous ajoutez le paramètre pour permettre à
l’agent de distribution d’ignorer certaines erreurs, la commande qui provoque cette erreur n’est pas appliquée à
l’abonné, mais toutes les autres commandes des mêmes transactions sont -SkipErrors appliquées. Dans ce cas,
la transaction de réplication n’est appliquée que partiellement à l’abonné, ce qui peut par conséquent provoquer
l’incohérence des données entre le Publisher et l’abonné.
Par exemple :
Vous avez une transaction en attente de réplication vers la table Abonné nommée T1. Cette transaction inclut
100 instructions insert. Lorsqu’elle s’applique à l’abonné, les 90 premiers insèrent le processus correctement ;
toutefois, l’instruction insert 91 échoue et l’erreur de violation de clé primaire 2627 se produit.
Lorsque vous n’utilisez pas le -SkipErrors paramètre (comportement par défaut) :
Par défaut, la transaction entière est retransférante et aucun des 100 nouveaux enregistrements n’est inséré
dans la table d’abonnement. Dans ce cas, vous devez corriger l’erreur de réplication afin que la transaction
puisse être réapplante à l’abonné.
Lorsque vous utilisez le -SkipErrors paramètre :
L’agent de distribution enregistre l’erreur dans l’historique de l’agent de distribution, ignore cette erreur, puis
poursuit le processus de distribution. Par conséquent, à l’exception du nouvel enregistrement quatre-vingt-un
qui a provoqué l’erreur, les 99 autres nouveaux enregistrements sont insérés dans la table d’abonnement. Cette
transaction n’est pas réapplée par l’agent de distribution, même après avoir corrigé manuellement l’erreur au
niveau de l’abonné. Par conséquent, dans cette situation, l’abonné manque le nouvel enregistrement quatre-
vingt-un et un problème d’incohérence de données se produit.
Vous devez également savoir qu’en SQL Server 2000, l’agent de distribution est généralement partagé par
plusieurs publications (par défaut, il existe un agent de distribution par base de données de composition et par
paire de base de données d’abonnement). Ainsi, si vous ajoutez le paramètre à la tâche Agent de distribution, il
affecte toutes les publications que cet -SkipErrors agent dessert. Dans SQL versions 2005 et SQL 2008, la
réplication transactionnelle utilise des agents indépendants par défaut pour les publications créées dans
l’Assistant Nouvelle composition. Pour les publications créées sp_addpublication à l’aide d’une procédure
stockée, le comportement par défaut consiste à utiliser un agent partagé.
Pour utiliser le paramètre pour une composition spécifique, utilisez un agent indépendant, qui -SkipErrors
n’offre qu’un abonnement. Pour utiliser un agent indépendant, suivez les étapes pour votre version :
SQL Server 2000

1. Dans SQL Server Entreprise Manager, cliquez avec le bouton droit sur la composition, cliquez sur, puis
sous l’onglet Options d’abonnement, cliquez sur utiliser un agent de distribution indépendant de l’autre
composition à partir de cette option de base de Properties données.
NOTE
Vous ne pouvez pas activer cette option après avoir ajouté des abonnements à cette composition.
2. Ajoutez -SkipErrors le paramètre à l’agent de distribution d’un abonnement spécifique.
SQL Server 2005 et SQL Server 2008

1. Dans SQL Server management studio, accédez à Réplication, puis, dans la section Publications locales,
cliquez avec le bouton droit sur la composition, cliquez sur Propriétés, puis dans la page Options
d’abonnement, modifiez la valeur de l’agent de distribution indépendant de False à True .
NOTE
Vous ne pouvez pas activer cette option après avoir ajouté des abonnements à cette composition.
2. Ajoutez -SkipErrors le paramètre à l’agent de distribution d’un abonnement spécifique.
Pour plus d'informations, consultez les articles suivants :

Administration de l’agent de réplication
Ignorer les erreurs dans la réplication transactionnelle
sp_addpublication (Transact-SQL)
Les agents Instantané ou Logreader échouent
lorsque la table de destination est vide SQL Server
Cet article vous aide à contourner le problème d’échec des agents Snapshot ou Logreader lorsqu’une table de
destination est vide.
Symptômes
Dans une réplication transactionnelle en Microsoft SQL Server, un article d’une requête SQL a une chaîne vide
dans une table de destination ( = N ») dans une instruction @destination_table Transact-SQL. Dans ce cas, vous
pouvez recevoir les messages d’erreur suivants aux emplacements spécifiés :
Dans l’agent de capture instantanée :
La valeur ne peut pas être null. Nom du paramètre : strObjectName
Dans l’agent Logreader :
Le processus n’a pas pu exécuter « sp_replcmds » sur « SERVER »
Dans le fichier journal des erreurs :
SQL Server Assertion : File: <replrowset.cpp>, line=2853 Failed Assertion = 'dwColLen'.
NOTE
La troisième erreur peut être liée au minutage. Si l’erreur persiste après la réexécution de l’instruction, utilisez cette
vérification pour vérifier l’intégrité DBCC CHECKDB structurelle de la base de données. Sinon, redémarrez le serveur pour
vous assurer que les structures de données en mémoire ne sont pas endommagées. Un fichier de vidage est créé dans le
\Log dossier qui contient les détails de l’assertion.
Les deuxième et troisième erreurs sont déclenchées uniquement si l’option de synchronisation immédiate est activée
pour la publication.
Cause
Ce problème se produit car une chaîne vide n’est pas un nom de table de destination valide.
Pour contourner ce problème, définissez un nom de table de destination valide ou supprimez le nom de la table
de destination non valide.
S’applique à
SQL Server Web 2014
SQL Server Web 2012
La synchronisation pour la SQL Server de fusion
échoue lorsqu’un article utilise un résolveur de
conflit personnalisé de procédure stockée
Cet article vous aide à contourner le problème d’échec de la synchronisation de la SQL Server fusion lorsqu’un
article de tableau utilise un résolveur de conflit personnalisé de procédure stockée.
Version du produit d’origine : SQL Server 2008 R2, SQL Server 2008, SQL Server 2005
Symptômes
Vous configurez la réplication de fusion dans Microsoft SQL Server 2008 R2, Microsoft SQL Server 2008
ou Microsoft SQL Server 2005.
La composition contient un article de tableau.
L’article du tableau contient des colonnes de type varchar de données ou nvarchar .
NOTE
L’article du tableau peut contenir des colonnes des deux types de données.
L’article du tableau contient également une colonne de type de decimal données.
NOTE
Le tableau peut également contenir une colonne de type numeric de données ou money .
Une colonne de type uniqueidentifier de données qui possède la propriété Rowguidcol n’est pas la
dernière colonne du tableau. Par exemple, une colonne de type de données , ou est decimal numeric
money triée après la uniqueidentifier colonne.
Vous configurez l’article du tableau pour utiliser un résolveur de conflit personnalisé de procédure
stockée.
Un conflit est détecté pour l’article du tableau.
Dans ce scénario, la synchronisation peut échouer pendant la résolution du conflit. Lorsque ce problème se
produit, vous pouvez recevoir un message d’erreur semblable à l’un des suivants :
L’agent de fusion a échoué car le schéma de l’article au Publisher ne correspond pas au schéma de l’article
de l’abonné. Cela peut se produire lorsqu’il existe des modifications DDL en attente d’application au niveau
de l’abonné.
Redémarrez l’agent de fusion pour appliquer les modifications DDL et synchroniser l’abonnement.
Le processus de fusion n’a pas pu stocker les informations de conflit pour l’article « article_name ». Vérifiez
les propriétés de la composition pour déterminer où les enregistrements en conflit sont stockés.
Valeur de caractère non valide pour la spécification de cast.
Ces erreurs sont signalées par l’agent de fusion en cas d’échec du travail de l’agent de fusion.
Cause
Ce problème se produit car les données renvoyées par le résolveur de conflits personnalisé de procédure
stockée sont converties de manière incorrecte en types de données SQL Server dans les tables de base.
NOTE
La procédure stockée renvoie les données correctes.
État
Microsoft a confirmé qu’il s’agit d’un bogue dans les produits Microsoft répertoriés dans la version d’origine du
produit au début de cet article.
Solution de contournement 1 : caster les colonnes de type de

données varchar en caractères
NOTE
Le message d’erreur que vous recevez dépend de la définition de la table. Vous de devez peut-être essayer des variantes
de ces méthodes pour contourner le problème.
Pour contourner ce problème, castez les colonnes de type de données en type de données dans le code de
résolution de conflit personnalisé de procédure varchar char stockée.
Solution de contournement 2 : modifier l’ordre des colonnes dans la

table sous-jacente
Pour contourner ce problème, modifiez l’ordre des colonnes dans la table sous-jacente. Par exemple, modifiez
l’ordre des colonnes afin que la colonne qui possède la propriété soit triée après les colonnes de type de
données uniqueidentifier Rowguidcol , et decimal numeric money varchar .
NOTE
Vous de devez peut-être déposer, puis rajouter des colonnes pour modifier l’ordre de tri. En outre, le problème peut se
reproduire si vous ajoutez des colonnes ultérieurement.
L’abonnement n’existe pas lorsqu’un réplica principal
de distributeur échoue vers un réplica qui n’utilise
pas le même profil d’agent.
Cet article vous aide à contourner l’erreur « L’abonnement n’existe pas » qui se produit lorsqu’un réplica
principal de distributeur passe à un réplica qui n’utilise pas le même profil d’agent.
Enterprise Core
Symptômes
Dans SQL Server 2017, vous avez un agent de distribution qui n’utilise pas de profil d’agent par défaut.
La base de données de distribution est ajoutée au groupe de disponibilité.
Le réplica principal de la base de données de distribution échoue vers un réplica qui n’utilise pas exactement
le même profil d’agent.
Dans ce scénario, l’agent de distribution échoue et vous recevez le message d’erreur suivant :
L’abonnement n’existe pas.
Cause
Les profils d’agent sont gérés et persistants dans la base msdb de données. Les modifications apportées à un
profil d’agent sont persistantes et ne peuvent pas être envoyées à d’autres distributeurs dans la ag de la base
msdb de données de distribution.
Les agents de réplication sont associés au profil via profile_id . Après un failover, l’agent risque de ne pas
pouvoir trouver le profil correct. Sinon, il peut trouver le profil erroné. Étant donné qu’un profil non parefault
dans un distributeur peut différer d’un autre distributeur, ou qu’il n’a peut-être jamais été existant ou qu’il peut
avoir un autre profile_id .
Le travail de l’agent de distribution lance la procédure stockée pour obtenir l’ID de
sp_MShelp_distribution_agentid l’agent au démarrage. Si le profil n’existe pas ou si les ID de profil sont
différents, le travail de l’agent de distribution n’a pas l’ID d’agent et il renvoie l’abonnement n’existe pas de
message d’erreur.
Spécifiez les paramètres directement dans la commande de l’agent de distribution, au lieu d’utiliser le
profil d’agent. Appliquez également les modifications au travail de l’agent de distribution dans tous les
réplicas de distributeur.
Assurez-vous que le profil de l’agent est créé dans tous les distributeurs qui participent à la base de
données de distribution dans l’AG et assurez-vous que les ID de profil sont les mêmes.
L’agent de distribution exécute la sp_MShelp_distribution_agentid procédure stockée pour obtenir le profil de
l’agent. Si le profil de l’agent n’existe pas ou si l’ID de profil est différent, le profil d’agent correct est in trouvé et
le message d’erreur « L’abonnement n’existe pas » est renvoyé.
Pour éviter ce problème, spécifiez le profil d’agent (ID de profil) correct dans la sp_MShelp_distribution_agentid
procédure stockée.
Voici un segment de code de la sp_MShelp_distribution_agentid procédure stockée :
SELECT distribAgent.id,
distribAgent.name,
distribAgent.publisher_database_id,
distribAgent.publisher_db,
distribAgent.subscriber_db,
profileName.profile_id,
profileName.profile_name
FROM MSdistribution_agents AS distribAgent
INNER JOIN msdb..MSagent_profiles AS profileName
ON distribAgent.profile_id = profileName.profile_id
Comprendre l’ordre de traitement de l’article de la
réplication de fusion
Cet article explique comment comprendre l’ordre de traitement de l’article De réplication de fusion.
Résumé
L’agent de fusion suit un ensemble spécifique de règles qui régissent l’ordre dans lequel le processus de fusion
applique les modifications aux articles pendant le processus de synchronisation.
Cet article explique pourquoi l’ordre de traitement des articles est important.
L’ordre de traitement des articles est important pour deux raisons principales :
Dans de nombreux cas, l’agent de fusion doit traiter les modifications apportées aux articles qui
participent aux contraintes d’intégrité référentielle déclarative (DRI) dans un ordre spécifique pour
obtenir des performances optimales. Si ce n’est pas le cas, il se peut que l’agent de fusion doit réessayer
les opérations DML qu’il a essayées dans un ordre incorrect (autrement dit, essayez d’insérer une ligne
enfant avant celle de son parent).
Les applications qui utilisent des déclencheurs pour maintenir l’intégrité référentielle nécessitent que
l’agent de fusion envoie les modifications dans un ordre spécifique. Si l’agent de fusion envoie les
modifications dans un ordre incorrect, le déclencheur la resserra probablement et la modification ne se
propagera pas dans toute la topologie de réplication.
NOTE
L’agent de fusion peut contourner l’évaluation de contrainte FOREIGN KEY et l’exécution du déclencheur utilisateur
lorsqu’il applique SQL de modification DML à un réplica partenaire. Pour que cela se produise, la contrainte FOREIGN KEY
et le déclencheur utilisateur, ou les deux, doivent avoir été créés avec l’option NOT FOR REPLICATION. Dans les deux
cas, le processus de fusion suppose que SQL Server a correctement évalué la logique métier lors de l’exécution de la
modification initiale initiée par l’utilisateur sur l’objet et qu’il n’a pas besoin de réévaluer ces conditions lorsqu’il réplique les
données dans le réplica partenaire. Le principal avantage de l’utilisation de L A RÉPLICATION NOT FOR de cette
manière est l’augmentation des performances. Pour plus d’informations sur l’option NE PAS FOR REPLICATION et pour
savoir comment l’utiliser correctement, voir la rubrique sur l’option NOT FOR REPLICATION dans SQL Server 2000
Books Online.
Pour les deux raisons répertoriées précédemment, l’ordre dans lequel l’agent de fusion fournit les modifications
à un réplica partenaire est important.
Avant de commencer une discussion sur l’ordre de traitement des articles, il est important de comprendre deux
concepts clés. Les deux concepts clés sont les suivants :
Surnom d’article.
Génération.
Voici une description des deux concepts.
Surnoms d’article
Un surnom est une valeur d’entier que l’agent de fusion utilise pour identifier un article (une table SQL
Server) pour fusionner la réplication. Le processus de configuration de fusion attribue un surnom
d’article lorsqu’il ajoute l’article à une composition de fusion. Si un article participe à des contraintes DRI,
le processus de configuration de fusion tente de générer un surnom d’article qui reflète les contraintes
DRI définies. Le processus de fusion affecte aux tables référencés par une contrainte FOREIGN KEY (un
parent) un surnom d’article plus petit que celui de la table de référence (la table enfant ou la table sur
laquelle la contrainte FOREIGN KEY est définie).
Si une table ne participe pas aux contraintes DRI, le processus de configuration de fusion affecte le
surnom de l’article en fonction de l’ordre dans lequel il ajoute l’article à la composition (dans l’ordre
croissant).
Generation
Une génération est une valeur entière que l’agent de fusion utilise pour suivre un groupe logique de
modifications apportées à un article particulier. Toutes les modifications apportées à un article particulier dans
un réplica particulier entre les synchronisations de fusion sont associées à la même génération. Chaque fois que
l’agent de fusion s’exécute, il ferme la génération ouverte existante, puis ouvre une nouvelle génération à
laquelle associer l’ensemble de modifications suivant.
Traitement des ENTRÉES INSERT, DESATE et SUPPRESSIONS

L’agent de fusion partitionnera les articles d’une composition particulière en deux groupes distincts :
L’agent de fusion place les articles qui ne sont impliqués dans aucune relation de filtrage de jointeur et
qui ne sont pas liés par le biais d’une DRI aux articles impliqués dans les filtres de jointeur dans un
groupe.
L’agent de fusion place les articles qui sont explicitement impliqués dans les relations de filtrage de
jointeur et les articles liés à joindre des articles de filtre via DRI dans un deuxième groupe distinct.
L’agent de fusion ajoute chaque article défini à la composition à un seul des groupes précédents.
L’agent de fusion utilise les groupes pour déterminer l’ordre de traitement global de , et pour tous les UPDATEs
articles définis dans la INSERTs DELETEs composition.
Dans chacun des deux groupes respectifs, l’agent de fusion traite et, dans l’ordre croissant des surnoms d’article,
les processus dans l’ordre décroit des surnoms INSERTs UPDATEs DELETEs d’article. Tout d’abord, l’agent de
fusion traite tout son ensemble dans un groupe particulier, suivi par et DELETEs UPDATEs INSERTs (également
dans un groupe particulier). D’un point de vue conceptuel, l’agent de fusion s’ad commune aux deux groupes
susmentionnés (non fusionnés) dans l’ordre indiqué précédemment. L’agent de fusion commence par traiter le
premier groupe, puis étend le traitement au deuxième groupe et le reste des modifications pour les deux
groupes est traitée DELETEs DELETE en parallèle. Bien que l’agent de fusion conserve l’ordre de traitement des
articles dans chaque groupe respectif, l’agent de fusion ne conserve pas un ordre strict de traitement des articles
dans les deux groupes respectifs. En tant que tel, dans le cas d’un ou de , il est possible que les modifications
apportées au premier groupe avec un surnom d’article supérieur arrivent en avance sur celles du deuxième
groupe avec un surnom INSERT UPDATE inférieur. La situation inverse peut également se produire pour un
DELETE . Ces deux comportements sont dus à la conception.
Effets possibles du traitement par lots de génération sur l’ordre de

traitement des articles
Comme indiqué précédemment, avec une génération, vous pouvez grouper logiquement les modifications ( et )
qui se produisent pour un article particulier à un réplica particulier entre INSERTs UPDATEs les DELETEs
sessions de synchronisation. En fin de compte, l’agent de fusion fonctionne avec les générations lorsqu’il
détermine les modifications qu’il doit échanger entre deux réplicas. L’agent de fusion négocie une génération
commune aux points suivants dans le processus de synchronisation :
Avant de télécharger les modifications de l’abonné vers l’éditeur.
Avant de télécharger les modifications de l’éditeur vers l’abonné.
L’agent de fusion utilise cette génération commune comme point de départ lors de l’éumation des générations à
envoyer à un réplica partenaire pendant les phases de téléchargement et de téléchargement de la
synchronisation de fusion.
L’agent de fusion traite les générations par lots, également appelés lots de génération. Par défaut, 100
générations sont incluses dans chaque lot de génération que l’agent de fusion télécharge vers l’éditeur à partir
de l’abonné ou vers l’abonné à partir de l’éditeur. La taille du lot de génération est configurable par le biais des
paramètres Merge Agent et Merge Agent, ou par le biais du -UploadGenerationsPerBatch
-DownloadGenerationsPerBatch profil de l’agent de fusion. Dans le cas par défaut, s’il y a plus de 100 générations
que vous devez échanger (c’est-à-dire, télécharger et télécharger, ou les deux) entre un éditeur (ou un ré-éditeur)
et un abonné, l’agent de fusion traite plusieurs lots de génération. Le nombre de lots dépend du nombre de
générations que l’agent de fusion doit échanger et des générations par paramètres par lot en vigueur pour une
session de fusion particulière.
Dans le cas où plusieurs lots de génération sont échangés, l’agent de fusion peut fractionner les modifications
parent et enfant associées entre deux lots de génération distincts. Si c’est le cas, l’agent de fusion peut fournir
une modification enfant dans un lot de génération avant le lot de génération qui contient la modification parent
associée. Dans les topologies de fusion hiérarchique qui utilisent des éditeurs de nouveau, il existe une situation
rare dans laquelle le fractionnement des modifications parent et enfant entre lots de génération peut entraîner
une non-convergence. Pour plus d’informations sur la non-convergence, consultez l’article suivant :
Non-convergence lorsque SQL Server générations enfants et parentsdans des lots de génération distincts.
Vous pouvez augmenter les paramètres mentionnés précédemment pour éviter de fractionner les modifications
parent et enfant entre -UploadGenerationsPerBatch -DownloadGenerationsPerBatch les lots de génération.
L’ordre de traitement des articles est maintenu dans un lot de génération particulier conformément aux règles
abordées précédemment. Toutefois, l’agent de fusion ne peut pas maintenir l’ordre de traitement des articles
entre les lots de génération.
Les instructions UPDATE peuvent être répliquées en
tant que paires DELETE/INSERT
Cet article décrit que les instructions Update peuvent être répliquées en tant que paires DELETE/INSERT.
Résumé
Si une colonne faisant partie d’une contrainte unique est mise à jour, SQL Server implémente la mise à jour en
tant que « mise à jour différée », ce qui signifie une paire DELETE / INSERT d’opérations. Cette « mise à jour
différée » entraîne l’envoi par la réplication d’une paire d’instructions DELETE / INSERT aux abonnés. Il existe
également d’autres situations qui peuvent entraîner une mise à jour différée. Par conséquent, toute logique
métier que vous implémentez dans vos déclencheurs ou procédures stockées personnalisées au niveau de
l’abonné doit également être incluse dans les déclencheurs ou les UPDATE DELETE / INSERT procédures
stockées personnalisées.
Le comportement par défaut dans la réplication transactionnelle consiste à utiliser et des procédures stockées
personnalisées pour appliquer les INSERT UPDATE modifications aux DELETE abonnés.
INSERT les instructions réalisées au Publisher sont appliquées aux abonnés par le biais INSERT d’un appel de
procédure stockée. De même, une DELETE instruction est appliquée via un appel de procédure DELETE stockée.
Toutefois, lorsqu’une instruction est exécutée en tant que « mise à jour différée », l’agent logreader place deux
appels de procédure stockée dans la base de données de distribution à appliquer aux abonnés plutôt qu’à un
appel de procédure stockée de mise à UPDATE DELETE / INSERT jour. Par exemple, supposons que vous avez un
tableau de publication, TABLE1 nommé, avec ces trois colonnes :
col1 int
col2 int
col3 varchar(30)
La seule contrainte unique est TABLE1 définie par le biais col1 d’une contrainte de clé primaire. Supposons
que vous avez un enregistrement (1,1, « Dallas »).
Lorsque vous exécutez ce code :
UPDATE TABLE1 set col1 = 3 where col2 = 'Dallas'
L’instruction est implémentée par SQL Server sous la forme d’une paire d’instructions depuis la mise à jour ,
dont un UPDATE DELETE / INSERT index unique col1 est défini. Par conséquent, le logreader place une paire
DELETE / INSERT d’appels dans la base de données de distribution. Cela peut avoir un impact sur toute logique
métier présente dans les déclencheurs ou les procédures stockées personnalisées au niveau de l’abonné. Vous
devez incorporer la logique métier supplémentaire dans et déclencher ou stocker des DELETE INSERT
procédures pour gérer cette situation.
Si vous préférez utiliser une logique unique et que vous souhaitez que toutes vos commandes sont répliquées
en tant que paires, vous pouvez activer un UPDATE DELETE / INSERT indicateur de suivi.
En outre, si vous utilisez un filtre horizontal dans votre composition et si la ligne mise à jour ne répond pas à
une condition de filtre, seul un appel de procédure est envoyé aux DELETE abonnés. Si la ligne mise à jour
précédemment ne répondait pas à la condition de filtre mais répond à la condition après la mise à jour, seul
l’appel de procédure est envoyé via le INSERT processus de réplication.
Dans l’exemple précédent, supposons que vous avez également un filtre horizontal défini sur TABLE1 :
where col2 = 'Dallas' . Si vous exécutez ce code :
UPDATE table1 set col2 = 'New York' where col1 = 3
L’agent logreader place uniquement un appel de procédure stockée à appliquer aux abonnés, car la ligne mise à
jour ne répond pas aux critères de DELETE filtre horizontal.
Maintenant, si vous exécutez ce code :
UPDATE table1 set col2 = 'Dallas' where col1 = 3
Le logreader génère uniquement l’appel de procédure stockée, car la ligne ne répondait pas INSERT à la
condition de filtre.
Bien qu’une opération a été effectuée au niveau Publisher, seules les commandes appropriées sont appliquées
au niveau UPDATE de l’abonné.
Bloquer l’utilisation à distance des comptes locaux
dans Windows
Cet article explique comment bloquer l’utilisation à distance de comptes locaux dans Windows.
Enterprise Core
Résumé
Lorsque vous utilisez des comptes locaux pour l’accès à distance dans les environnements Active Directory, vous
pouvez être face à plusieurs problèmes différents. Le problème le plus important se produit si un compte local
d’administration a le même nom d’utilisateur et le même mot de passe sur plusieurs appareils. Un attaquant qui
dispose de droits d’administration sur un appareil de ce groupe peut utiliser le hachage de mot de passe des
comptes de la base de données SAM (Security Accounts Manager) locale pour obtenir des droits
d’administration sur les autres appareils du groupe qui utilisent les techniques de « hachage ».
Nos dernières instructions de sécurité répondent à ces problèmes en profitant des nouvelles fonctionnalités
Windows pour bloquer les connexions à distance par les comptes locaux. Windows 8.1 et Windows Server 2012
R2 ont introduit les identificateurs de sécurité (SID) suivants :
S-1-5-113 : AUTORITÉ NT\Compte local
S-1-5-114 : AUTORITÉ NT\Compte local et membre du groupe Administrateurs
Ces SID sont également définis sur Windows 7, Windows 8, Windows Server 2008 R2 et Windows Server 2012
après l’installation de l’avis de sécurité Microsoft mise à jour : mise à jour pour améliorer la protection et la
gestion des informations d’identification : 13 mai 2014.
Le premier SID est ajouté au jeton d’accès des utilisateurs au moment de l’authentification si le compte
d’utilisateur authentifié est un compte local. Le deuxième SID est également ajouté au jeton si le compte local est
membre du groupe Administrateurs intégré.
Ces SID peuvent accorder ou refuser l’accès à tous les comptes locaux ou tous les comptes locaux
d’administration. Par exemple, vous pouvez utiliser ces SID dans Attributions des droits d’utilisateur dans la
stratégie de groupe pour « Refuser l’accès à cet ordinateur à partir du réseau » et « Refuser l’accès à l’ordinateur
via les services Bureau à distance ». Il s’agit de la pratique recommandée dans nos derniers conseils de sécurité.
Pour obtenir le même effet avant la définition de ces nouveaux SID, vous deviez nommer explicitement chaque
compte local que vous vouliez restreindre.
Dans la version initiale des instructions Windows 8.1 et Windows Server 2012 R2, nous avons refusé l’accès
réseau et bureau à distance au compte local (S-1-5-113) pour toutes les configurations client et serveur
Windows. Cela bloque tout accès à distance pour tous les comptes locaux.
Nous avons de nouveau découvert que le clustering deover repose sur un compte local nonadministratif
(CLIUSR) pour la gestion des nœuds de cluster, et que le blocage de son accès à la déconnexions réseau entraîne
l’échec des services de cluster. Étant donné que le compte CLIUSR n’est pas membre du groupe Administrateurs,
le remplacement de S-1-5-113 par S-1-5-114 dans le paramètre « Refuser l’accès à cet ordinateur à partir du
réseau » permet aux services de cluster de fonctionner correctement. Il le fait tout en fournissant une protection
contre les types d’attaques « pass the hash » en refusant l’accès réseau aux comptes locaux d’administration.
Bien que nous pourrions conserver les instructions inchangées et ajouter une note de bas de page « cas spécial
» pour les scénarios de cluster de failover, nous avons choisi de simplifier les déploiements et de modifier la
ligne de base du serveur membre Windows Server 2012 R2, comme indiqué dans le tableau suivant.
COMPUTER CONFIGURATION\WINDOWS SETTINGS\LOCAL POLICIES\USER RIGHTS

C H EM IN D’A C C ÈS DE L A ST RAT ÉGIE ASSIGNMENT
Nom de la stratégie Refuser l’accès à cet ordinateur à partir du réseau
Valeur d’origine Invités, compte local*
Nouvelle valeur Invités, compte local et membres du groupe

Administrateurs*
Ces instructions vous recommandent également d’ajouter des administrateurs de domaine (DA) et des
administrateurs Enterprise (EA) à ces restrictions. L’exception concerne les contrôleurs de domaine et les
stations de travail d’administration dédiées. Da et EA sont spécifiques au domaine et ne peuvent pas être
spécifiés dans les lignes de base des objets de stratégie de groupe génériques.
NOTE
Cette modification s’applique uniquement à la ligne de base du serveur membre. La restriction sur l’accès au
Bureau à distance n’est pas modifiée. Les organisations peuvent toujours décider de refuser l’accès réseau au
compte local pour les serveurs non privés.
Les restrictions sur les comptes locaux sont destinées aux systèmes joints au domaine Active Directory. Les
appareils de groupe de travail Windows non joints ne peuvent pas authentifier les comptes de domaine. Par
conséquent, si vous appliquez des restrictions à l’utilisation à distance de comptes locaux sur ces appareils, vous
pourrez vous connecter uniquement à la console.
En savoir plus sur le compte CLIUSR

Le compte CLIUSR est un compte d’utilisateur local créé par la fonctionnalité de clustering de failover si la
fonctionnalité est installée sur Windows Server 2012 ou versions ultérieures.
Dans la Windows Server 2003 et les versions antérieures du service de cluster, un compte d’utilisateur de
domaine a été utilisé pour démarrer le service. Ce compte de service de cluster (CSA) a été utilisé pour former le
cluster, joindre un nœud, faire la réplication du Registre, etc. En fait, tout type d’authentification effectué entre les
différents nods utilisait ce compte d’utilisateur comme identité commune.
Plusieurs problèmes de prise en charge ont été rencontrés car les administrateurs de domaine ont été en train
de définir des stratégies de stratégie de groupe qui ont retiré les autorisations des comptes d’utilisateur de
domaine. Les administrateurs ne considéraient pas que certains de ces comptes d’utilisateurs étaient utilisés
pour exécuter des services.
Par exemple, ce problème s’est rencontré lors de l’utilisation de l' logon en tant que droit de service. Si le compte
de service de cluster ne vait pas cette autorisation, il ne pouvait pas démarrer le service de cluster. Si vous
utilisiez le même compte pour plusieurs clusters, vous pourriez être en panne de production sur plusieurs
systèmes importants. Vous deviez également gérer les modifications de mot de passe dans Active Directory. Si
vous avez modifié le mot de passe des comptes d’utilisateurs dans Active Directory, vous deviez également
modifier les mots de passe sur tous les clusters et tous les nodes qui utilisent le compte.
Dans Windows Server 2008, nous avons repensé tout ce qui était sur la façon de démarrer le service pour
rendre le service plus résilient, moins sujet aux erreurs et plus facile à gérer. Nous avons commencé à utiliser le
service réseau intégré pour démarrer le service de cluster. N’oubliez pas qu’il ne s’agit pas du compte complet,
mais seulement d’un ensemble de privilèges réduit. En réduit l’étendue de ce compte, nous avons trouvé une
solution pour les problèmes de stratégie de groupe.
Pour l’authentification, le compte a été basculé pour utiliser l’objet ordinateur associé au nom de cluster appelé
objet CNO (Cluster Name Object) pour une identité commune. Étant donné que cet objet réseau de stratégie de
groupe est un compte d’ordinateur dans le domaine, il fait pivoter automatiquement le mot de passe, tel que
défini par la stratégie de domaine pour vous. (Par défaut, il s’agit de tous les 30 jours.)
À compter de Windows Server 2008 R2, les administrateurs ont commencé à virtualiser tout le reste de leurs
centres de données. Cela inclut les contrôleurs de domaine. La fonctionnalité de volumes partagés de cluster
(CSV) a également été introduite et est devenue la norme pour le stockage cloud privé. Certains administrateurs
ont adopté la virtualisation et virtualisé chaque serveur dans leur centre de données. Cela inclut l’ajout de
contrôleurs de domaine en tant que machine virtuelle à un cluster et l’utilisation du lecteur CSV pour contenir le
vhd/VHDX de l’ordinateur virtuel.
Cela a créé un scénario « Catch 22 » pour de nombreuses sociétés. Pour monter le lecteur CSV afin d’accéder
aux VM, vous deviez contacter un contrôleur de domaine pour récupérer l’no CNO. Toutefois, vous n’avez pas pu
démarrer le contrôleur de domaine car il était en cours d’exécution sur le CSV.
Une connexion lente ou peu fiable aux contrôleurs de domaine a également une incidence sur les lecteurs DSV.
CSV permet une communication intra-cluster via SMB, similaire à la connexion à des partages de fichiers. Pour
se connecter à SMB, la connexion doit s’authentifier. Dans Windows Server 2008 R2, cela impliquait
l’authentification de l’no CNO à l’aide d’un contrôleur de domaine distant.
Par Windows Server 2012, nous avons dû réfléchir à la façon dont nous pourrions profiter au mieux des deux
mondes et éviter certains problèmes que nous voyons. Nous utilisons toujours le droit d’utilisateur du service
réseau réduit pour démarrer le service de cluster. Toutefois, pour supprimer toutes les dépendances externes,
nous utilisons désormais un compte d’utilisateur local (non-domaine) pour l’authentification entre les nodes.
Ce compte « utilisateur » local n’est pas un compte d’administration ou un compte de domaine. Ce compte est
automatiquement créé pour vous sur chaque nœud lorsque vous créez un cluster, ou sur un nouveau nœud
ajouté au cluster existant. Ce compte est auto-géré par le service de cluster. Il fait pivoter automatiquement le
mot de passe du compte et synchronise tous les nodes pour vous. Le mot de passe CLIUSR est pivoté à la même
fréquence que l’objet réseau de réseau de recherche, tel que défini par votre stratégie de domaine. (Par défaut, il
s’agit de tous les 30 jours.) Étant donné que le compte est local, il peut authentifier et monter CSV afin que les
contrôleurs de domaine virtualisés démarrent correctement. Vous pouvez désormais virtualiser tous les
contrôleurs de domaine sans craindre. Par conséquent, nous augmentant la résilience et la disponibilité du
cluster en réduisant les dépendances externes.
Ce compte est le compte CLIUSR. Il est identifié par sa description dans le logiciel en snap-in Gestion de
l’ordinateur.
Une question fréquente est de savoir si le compte CLIUSR peut être supprimé. Du point de vue de la sécurité,
des comptes locaux supplémentaires (pas par défaut) peuvent être signalés pendant les audits. Si
l’administrateur réseau n’est pas sûr de l’objectif de ce compte (c’est-à-dire qu’il ne lit pas la description de «
Identité locale du cluster de failover »), il peut le supprimer sans en comprendre les implications. Pour que le
clustering deover fonctionne correctement, ce compte est nécessaire pour l’authentification.
1. Le nœud joint démarre le service de cluster et transmet les informations d’identification CLIUSR.
2. Pour obtenir le même effet, toutes les informations d’identification sont transmises afin que le nœud
puisse se joindre.
Nous avons fourni une protection de plus pour garantir un succès continu. Si vous supprimez accidentellement
le compte CLIUSR, il est re-créé automatiquement lorsqu’un nœud tente de rejoindre le cluster.
Résumé : Le compte CLIUSR est un composant interne du service de cluster. Il s’agit d’une gestion autonome
afin que vous n’êtes pas obligé de le configurer ou de le gérer.
Dans Windows Server 2016, nous avons fait une étape plus loin en profitant des certificats pour permettre aux
clusters de fonctionner sans aucun type de dépendance externe. Cela vous permet de créer des clusters à l’aide
de serveurs situés dans différents domaines ou en dehors de tous les domaines.
Le .NET Framework client 4.6.2 pour Always
Encrypted échoue par intermittence pendant le
déchiffrement de ligne
Cet article fournit une solution au problème qui provoque l’échec de l’application cliente .NET Framework 4.6.2
lors de l’accès aux données à partir d’une base de données toujours chiffrée.
Symptômes
Vous avez une application cliente qui utilise le .NET Framework Fournisseur de données pour Microsoft SQL
Server (Sqlclient) inclus dans Microsoft .NET Framework 4.6.2. Vous utilisez cette application pour vous
connecter à une base de données toujours chiffrée qui s’exécute sur Microsoft SQL Server 2016, SQL Server
2017 sur Windows ou Microsoft Azure SQL Database.
Lorsque vous essayez de déchiffrer les enregistrements de la base de données toujours chiffrée, vous recevez
des messages d’erreur intermittents semblables à l’erreur suivante :
Échec du déchiffrement. Les 10 derniers octets de la clé de chiffrement de colonne chiffrée sont : 7E-0B-E6-
D3-39-CE-35-86-2F-AA. Les 10 premiers octets de texte chiffré sont : 01-C3-D7-39-33-2F-E6-44-C3-B1. Le
texte chiffré spécifié comporte une balise d’authentification non valide.
Lorsque ce problème se produit, les requêtes sur des colonnes protégées par le paramètre Toujours chiffré
peuvent afficher des résultats incorrects, par exemple, trop peu d’enregistrements sont renvoyés. Cela peut à son
tour déclencher un comportement incorrect. Par exemple, l’application cliente tente d’insérer des valeurs
manquantes ou d’exécuter d’autres processus de mise à jour qui créent des erreurs supplémentaires ou
provoquent des données incohérentes dans la base de données.
Résolution
Pour résoudre ce problème, installez la mise à jour de sécurité à partir du Bulletin de sécurité Microsoft MS16-
155.
IMPORTANT
Si votre application cliente est hébergée via Web Apps sur Microsoft Azure App Service, le client utilise automatiquement
la .NET Framework 4.6.2. Par conséquent, vous pouvez rencontrer le problème mentionné dans la section Symptômes.
Dans ce scénario, vous pouvez utiliser uniquement la solution de contournement de la méthode 2 (« Désactiver le
chiffrement de colonne ») dans cette section jusqu’à ce qu’un correctif soit publié pour ce problème.
Pour contourner ce problème, suivez les instructions suivantes, le cas échéant :

Le client .NET n’est pas encore mis à niveau vers la version 4.6.2
Dans les environnements mentionnés dans la section Symptômes, nous vous recommandons de ne pas
mettre à niveau vers le .NET Framework 4.6.2 tant que ce problème n’est pas résolu. Ce problème
n’affecte pas les versions antérieures du pilote.
Le client .NET est déjà mis à niveau vers la version 4.6.2
Utilisez l’une des méthodes suivantes :
Méthode 1 : revenir à la version .NET Framework version
Désinstallez le .NET Framework 4.6.2 des applications clientes d’hébergement du système. Cela
force les applications à utiliser une version antérieure de NET Framework Fournisseur de données
pour les SQL Server qui ne sont pas en présence de ce problème. Pour cela, procédez comme suit :
1. Dans le Panneau de contrôle, ouvrez l’élément Programmes, puis sélectionnez
Programmes et fonctionnalités.
2. Sélectionnez Afficher les mises à jour installées, puis désinstallez Mise à jour pour
Microsoft Windows KB3120737 .
NOTE
Après avoir désinstallé une version du .NET Framework, nous vous recommandons de tester .NET
Framework applications dépendantes. Ces applications peuvent ne pas fonctionner correctement si vous
désinstallez la version du .NET Framework dont elles dépendent.
Méthode 2 : désactiver la mise en cache des clés de chiffrement de colonnes

Si vous ne pouvez pas revenir en arrière .NET Framework’installation, dés désactiver la mise en
cache de clé de chiffrement de colonne (CEK). Pour ce faire, définissez la propriété
SqlConnection.ColumnEncryptionKeyCacheTtl dans l’application cliente sur 0. Par exemple,
exécutez le code suivant pour désactiver le chiffrement de colonne dans C# applications :
System.Data.SqlClient.SqlConnection.ColumnEncryptionKeyCacheTtl = TimeSpan.Zero
Après avoir utilisé l’une ou l’autre des méthodes, vérifiez que l’erreur ne réapparaît pas lors d’une analyse de
tableau (telle que SELECT * FROM < table avec > Toujours chiffré) qui s’exécute à partir d’une fenêtre de
requête en SSMS sur une connexion de base de données dont le paramètre de chiffrement de colonne est
activé dans la chaîne de connexion. L’exécution de ce type d’analyse valide le chiffrement correct.
IMPORTANT
Les utilisateurs qui présentent le problème décrit dans la section Symptômes pendant l’analyse de validation doivent
contacter sqlalwaysencrypted@microsoft.com . L’équipe de support peut aider à récupérer toutes les lignes
précédemment chiffrées affectées par ce bogue. Ce bogue ne provoque pas de perte de données permanente.
Références
.NET Framework pilote client 4.6.2 pour Always Encrypted, ce qui entraîne des échecs intermittents de
déchiffrement des lignes individuelles
Vous ne devez pas désactiver l’utilisateur invité dans
la base de données msdb dans SQL Server
Cet article décrit différents problèmes qui peuvent se produire lorsque vous désactivez l’utilisateur invité dans la
base de données msdb dans SQL Server.
Symptômes lorsque l’utilisateur invité est désactivé dans la base de

données msdb
Pour que certaines fonctionnalités Microsoft SQL Server fonctionnent, l’utilisateur invité doit être activé dans la
base de données msdb. Cet article décrit certains problèmes que vous pouvez connaître si vous désactivez
l’utilisateur invité dans la base de données msdb. L’article fournit également des informations sur la résolution
de ces problèmes.
Lorsque l’utilisateur invité est désactivé dans la base de données msdb, vous pouvez recevoir des
MSSQLSERVER_916 d’erreur lorsque l’utilisateur développe le nœud Bases de données dans Management
Studio se développe ou lorsqu’une application serveur tente de se connecter à SQL Server. Vous pouvez être
face à un ou plusieurs des symptômes suivants dans votre environnement lorsque ce problème se produit.
NOTE
Le texte de l’erreur peut légèrement varier en fonction du scénario. Toutefois, la cause sous-jacente est essentiellement la
même. Cette cause est un nombre insuffisant de privilèges dans la base de données msdb. Ces symptômes se produisent
lorsque l’Explorateur d’objets tente d’afficher l’état de gestion basée sur la stratégie de chaque base de données.
L’Explorateur d’objets utilise les autorisations de l’utilisateur connecté actuel pour interroger la base de données msdb
pour obtenir ces informations, ce qui provoque l’erreur.
Symptôme 1
Dans les environnements SQL Server 2012 et ultérieurs, lorsqu’un utilisateur qui n’est pas membre du rôle
serveur fixe Sysadmin dans SQL Server et qui autrement n’a pas reçu les autorisations appropriées dans msdb
tente d’étendre le nœud Bases de données ou l’un des dossiers sous ce nœud, il reçoit un message d’erreur qui
ressemble à ce qui suit :
Impossible d’afficher la boîte de dialogue demandée. INFORMATIONS SUPPLÉMENTAIRES : Impossible

d’afficher la boîte de dialogue demandée. (SqlMgmt) Une exception s’est produite lors de l’exécution d’une
instruction SQL transact ou d’un lot. (Microsoft.SqlServer.ConnectionInfo)
Le principal du <username> serveur n’est pas en mesure d’accéder à la base de données msdb dans le contexte
de sécurité actuel. (Microsoft SQL Server, Erreur : 916)
Symptôme 2
Dans les environnements SQL Server 2008 et SQL Server 2008 R2, lorsqu’un utilisateur qui n’est pas membre
du rôle serveur fixe Sysadmin dans SQL Server et qui n’a pas reçu les autorisations appropriées dans msdb
tente de développer le nœud Bases de données ou l’un des dossiers sous ce nœud, il reçoit un message d’erreur
qui ressemble à ce qui suit :
Échec de la récupération des données pour cette demande. (Microsoft.SqlServer.Manager.Sdk.Sfc)

Informations supplémentaires :
Une exception s’est produite lors de l’exécution d’une instruction SQL transact ou d’un lot.
(Microsoft.SqlServer.ConnectionInfo)
Le principal du serveur n’est pas en mesure d’accéder à la base de données <Servername> « msdb » dans le
contexte de sécurité actuel. (Microsoft SQL Server, Erreur : 916)
NOTE
Le développement du nœud Base de données n’est qu’une des activités qui nécessitent l’autorisation de connexion du
compte invité à la base de données msdb. Une erreur similaire peut se produire avec toute activité nécessitant au moins
un accès minimal à la base de données msdb.
Comment déterminer le problème

Pour déterminer si l’utilisateur invité est configuré correctement dans la base de données msdb, exécutez la
requête suivante en tant que membre du rôle serveur fixe sysadmin :
USE msdb;
SELECT prins.name AS grantee_name, perms.*
FROM sys.database_permissions AS perms
JOIN sys.database_principals AS prins
ON perms.grantee_principal_id = prins.principal_id
WHERE prins.name = 'guest' AND perms.permission_name = 'CONNECT';
GO
Si vous recevez un jeu de résultats semblable à ce qui suit, l’utilisateur invité dispose des autorisations
nécessaires.
GRA N T GRA N T
GRA N T EE_P RI O R_P RI P ERM I
EE_N A C L A SS M A JO R M IN O R N C IPA N C IPA SSIO N _ STAT E_
ME C L A SS _DESC _ID _ID L _ID L _ID TYPE NAME STAT E DESC
invité 0 DATAB 0 0 2 1 CO CONN G GRANT

ASE ECT
Si vous recevez un jeu de résultats vide ou si l’affiche DENY dans le jeu de résultats mentionné ici, l’utilisateur
invité est désactivé dans la base de données state_desc msdb. Vous pouvez recevoir l’erreur 916 lorsque vous
vous connectez à une base de données.
Comment résoudre le problème

Pour résoudre le problème, exécutez la requête suivante dans SQL Server Management Studio en tant que
membre du rôle serveur fixe sysadmin :
USE msdb;
GRANT connect TO guest;
GO
Références
Autorisations des invités sur les bases de données utilisateur
Sécurisation de SQL Server
Résoudre les problèmes d’autorisation lors du
déplacement de la base de données MSDB entre
différentes instances
Cet article vous aide à résoudre les problèmes d’autorisation qui se produisent lorsque vous déplacez la base de
données MSDB entre différentes instances.
Symptômes
Vous déplacez la base de données msdb d’une instance vers une autre à l’aide du processus de sauvegarde et de
restauration ou en copiant les fichiers de base de données (mdf et ldf). Ensuite, sur le serveur de destination, un
utilisateur qui ne fait pas partie du rôle fixe Sysadmin dans SQL Server tente d’y faire l’une des opérations
suivantes :
Affichez un travail dans SQL Server Management Studio.
Appeler SQL procédures stockées associées à un agent (par exemple, xp_sqlagent_enum_jobs ou
sp_get_composite_job_info) directement à l’aide de T-SQL.
Dans ce scénario, l’utilisateur reçoit un message d’erreur semblable au suivant :
L’autorisation EXECUTE a été refusée sur l’objet « xp_sqlagent_enum_jobs » base de données «
mssqlsystemresource » et schéma « sys ». (Microsoft SQL Server, Erreur : 229)
Cause
Ce problème se produit car le certificat SQL agent de sécurité est différent sur différentes instances.
Résolution
Pour résoudre le problème, vous devez remplacer le certificat dans la base de données principale par le certificat
de la base de données msdb restaurée à l’aide du script suivant sur le serveur de destination :
use msdb
go
-- Backup the Agent certificate from the remote server to a file
BACKUP CERTIFICATE [##MS_AgentSigningCertificate##] TO FILE = 'MS_AgentSigningCertificate.remote_server.cer'
go
use master
go
-- re-create the agent certificate on master
-- Note: Because we are making these changes using a regular user and not as part of setup, the name
-- cannot include the ## token.
-- Creating a regular certificate in this case should be the equivalent as we only need it to derive a SID
CREATE CERTIFICATE [MS_AgentSigningCertificate.remote_server] FROM FILE =
'MS_AgentSigningCertificate.remote_server.cer'
go
-- Recreate the user mapped to the cert and grant the same permissions that the regular certificate needs.
CREATE USER [MS_AgentSigningCertificate.remote_server] FROM CERTIFICATE
[MS_AgentSigningCertificate.remote_server]
go
GRANT EXECUTE TO [MS_AgentSigningCertificate.remote_server]
go
NOTE
Dans un scénario où les certificats dans la base et le modèle sont les mêmes avant d’exécuter le script décrit dans l’article,
l’exécution du script entraîne le message d’erreur suivant :

Un certificat nommé « MS_AgentSigningCertificate.remote_server20009 » existe déjà ou ce certificat a déjà
été ajouté à la base de données.
Si vous présentez les symptômes décrits dans l’article même lorsque les certificats sont identiques, contactez les
services de support technique Microsoft (CSS) pour obtenir de l’aide.
SQL Server ne parvient pas à démarrer lorsque le
serveur est configuré pour utiliser SSL
Cet article fournit une résolution de l’erreur 17182 (échec de l’initialisation de TDSSNIClient avec 0xd d’erreur,
0x38 de code d’état) qui se produit lorsque le serveur est configuré pour utiliser SSL.
Symptômes
Vous avez une instance de SQL Server 2005 ou une version ultérieure qui est hébergée sur un système
exécutant Windows Server 2008 ou une version ultérieure du système d’exploitation.
Vous avez configuré le chiffrement SSL pour votre SQL Server en entrant manuellement l’empreinte
numérique d’un certificat dans la valeur Certificat sous la clé de Registre suivante :
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\<instance>\MSSQLServer\SuperSocketNetLib
Dans ce scénario, votre SQL Server peut ne pas démarrer et les messages suivants sont enregistrés dans le SQL
Server Errorlog :
<Datetime> Erreur du serveur : 17182, Gravité : 16, État : 1.

<Datetime> Échec de l’initialisation du serveur TDSSNIClient avec erreur 0xd, code d’état 0x38.
<Datetime> Erreur du serveur : 17182, Gravité : 16, État : 1. <Datetime> Échec de l’initialisation du serveur
TDSSNIClient avec erreur 0xd, code d’état 0x1.
<Datetime> Le serveur n’a pas pu démarrer la bibliothèque réseau en raison d’une erreur interne dans la
bibliothèque réseau. Pour en déterminer la cause, examinez les erreurs qui précèdent immédiatement celle-
ci dans le journal des erreurs.
<Datetime>Le serveur SQL Server n’a pas pu générer de thread FRunCM. Consultez le SQL Server d’erreurs
et les journaux Windows’événements pour plus d’informations sur les problèmes associés possibles.
Cause
L’une des causes premières courantes de ces symptômes est un caractère invisible qui a peut-être été ajouté par
inadvertance à la valeur Thumbprint du certificat, lorsqu’il est copié à partir du contrôle d’édition enrichi du
logiciel en ligne Certificats dans la MMC.
Résolution
Vous pouvez utiliser l’une des résolutions suivantes :
Évitez de copier des caractères de début à partir du logiciel en snap-in Certificats dans MMC, lorsque
vous copiez la valeur Thumbprint d’un certificat.
Utilisez l’outil Certutil au lieu du logiciel en snap-in de certificats dans MMC pour exporter le certificat
dans un fichier texte, puis copiez la valeur Thumbprint du certificat requis à partir du fichier texte.
L’utilisation est indiquée ci-dessous :
Pour afficher le contenu du magasin de certificats utilisateur actuel de l’ordinateur, tapez ce qui suit à
l’invite de commandes :
certutil -store -user my
Pour afficher le contenu du magasin de certificats de l’ordinateur local, tapez ce qui suit à l’invite de
commandes :
certutil -store my
Vous pouvez diriger la sortie de la commande ci-dessus vers un fichier texte en utilisant ce qui suit à l’invite de
commandes d’administration sur les systèmes d’exploitation Vista :
certutil -store my > cert.txt
L’empreinte numérique peut se trouver dans la ligne qui commence par Cert Hash(sha1)
Par exemple : Cert Hash(sha1) : e7 02 4b 42 c4 04 fd 44 8c ec 21 f1 91 76 5c b7 c3 ad 1d 55
Vous pouvez ensuite copier cette valeur (sans espaces ; pour l’exemple ci-dessus, il s’adressera à
e7024b42c404fd448cec21f191765cb7c3ad1d55) vers la valeur certificat sous la clé de Registre suivante :
Un code d'0x38 dans le message d’erreur 17182 signifie que SQL Server une erreur s’est produite lors de
l’initialisation de SSL. Pour plus d SQL, voir SQL protocols.
L'0xd de code de retour indique l’erreur du système d’exploitation 0xd (13) qui se traduit par « Les données ne
sont pas valides ». L’erreur 17182 ci-dessus « Échec de l’initialisation de TDSSNIClient avec 0xd d’erreur, le
code d’état 0x38 » se produit spécifiquement en raison du fait que la chaîne sous valeur Certificat ne peut pas
être correctement convertie en une empreinte valide du certificat.
Ce problème d’interface graphique graphique avec le composant logiciel en ligne Certificats ne se produit pas
sur les versions antérieures de Windows (par exemple, Windows XP, Windows Server 2003), car ils n’utilisent
pas de contrôle d’édition enrichi dans le composant logiciel en ligne Certificats
Pour vérifier si vous êtes en cours d’exécution dans le problème documenté dans cet article, vous pouvez utiliser
la procédure suivante :
1. Ouvrez regedit, accédez à la clé de Registre suivante et exportez la clé dans le fichier SSLKey.reg :
2. Ouvrez le fichier SSLKey.reg de l’étape 1 à l’aide de Bloc-notes et à l’aide de la boîte de dialogue

Enregistrer sous dans le menu Fichier, cliquez sur ANSI dans la liste de codage, puis cliquez sur
Enregistrer .
3. Si vous recevez l’avertissement ci-dessous, allez à l’étape 3 en cliquant sur OK.
WARNING
Ce fichier contient des caractères au format Unicode qui seront perdus si vous enregistrez ce fichier en tant que
fichier texte ansI. Pour conserver les informations Unicode, cliquez sur Annuler ci-dessous, puis sélectionnez l’une
des options Unicode dans la liste bas de codage. Continuer
4. Fermez le fichier SSLKey.reg et rouvrez-le à l’aide Bloc-notes.
5. Si vous voyez maintenant une marque de questions ou tout autre caractère non valide dans l’empreinte
numérique de votre certificat, cela indique que vous êtes probablement en cours d’exécution dans le
problème documenté dans cet article :
Un exemple d’entrée peut ressembler à ce qui suit :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\MSSQL.1\MSSQLServer\SuperSocketNetLib]
« Certificate"= »?b009d02038431da332f095b4ea6a126f4f5c7d18 »
SQL Server service ne peut pas démarrer après
avoir configuré une instance pour utiliser un
certificat Secure Sockets Layer
Cet article fournit une solution au problème qui se produit après la configuration d’un certificat SSL qui utilise
Microsoft Enhanced Cryptographic Provider 1.0.
Symptômes
Prenons le cas de figure suivant. Vous configurez une instance de SQL Server pour utiliser un certificat SSL. Le
certificat SSL utilise le fournisseur de chiffrement amélioré 1.0. Dans ce scénario, le service SQL Server ne peut
pas démarrer. En outre, lorsque vous essayez de démarrer le service SQL Server, les messages d’erreur suivants
sont écrits dans SQL Server fichier Errorlog :
Ser veur d’heure de date impossible de charger le certificat spécifié par l’utilisateur. Le serveur
n’accepte pas de connexion. Vous devez vérifier que le certificat est correctement installé. Voir «
Configuring Certificate for Use by SSL » dans Books Online.
Erreur du serveur d’heure de date : 17182, Gravité : 16, État : 1.
Échec de l’initialisation de Date Time Server TDSSNIClient avec erreur 0x80092004, code d’état
0x80.
Échec de l’initialisation de Date Time Server TDSSNIClient avec erreur 0x80092004, code d’état 0x1.
Cause
Ce problème se produit car vous ne pouvez pas utiliser un certificat dont la version 1.0 du fournisseur de
services de chiffrement est Enhanced Cryptographic Provider comme certificat de serveur.
Résolution
Ne spécifiez aucun certificat. Par conséquent, SQL Server génère un certificat auto-signé. Pour ce faire,
laissez la zone Cer tificat vide dans Gestionnaire de configuration SQL Server.
Pour plus d’informations, visitez les sites Web MSDN (Developer Network) suivants :
Configuration des protocoles réseau de serveur et des bibliothèques réseau
Chiffrement des connexions aux SQL Server
Utilisez un certificat qui utilise le fournisseur de services de chiffrement du fournisseur de chiffrement de
canal RSA pour SQL Server certificat.
Les certificats SSL qui utilisent le fournisseur de chiffrement amélioré 1.0 peuvent être utilisés pour les
certificats clients. Toutefois, les certificats ne conviennent pas en tant que certificats de serveur. Pour déterminer
le fournisseur d’un certificat, exécutez la commande à l’invite de commandes : certutil -v -store my .
Le message d’erreur suivant est mentionné dans la section Symptômes :
Échec de l’initialisation de Date Time Server TDSSNIClient avec erreur 0x80092004, code d’état 0x80.
Dans ce message d’erreur, l’état 0x80'erreur indique qu’un problème se trouve dans le certificat SSL. En outre,
0x80092004 est un code d’erreur SSPI (Security Support Provider Interface) qui se traduit par
CRYPT_E_NOT_FOUND .
Transférer des connexions et des mots de passe
entre des instances de SQL Server
Cet article explique comment transférer les connexions et les mots de passe entre différentes instances de SQL
Server en cours d’exécution Windows.
Introduction
Cet article explique comment transférer les connexions et les mots de passe entre différentes instances de
Microsoft SQL Server.
NOTE
Les instances peuvent se faire sur le même serveur ou sur des serveurs différents, et leurs versions peuvent différer.
Dans cet article, les serveurs A et B sont des serveurs différents.
Après avoir fait passer une base de données de l’instance de SQL Server sur le serveur A vers l’instance de SQL
Server sur le serveur B, les utilisateurs risquent de ne pas pouvoir se connecter à la base de données sur le
serveur B. En outre, les utilisateurs peuvent recevoir le message d’erreur suivant :
Échec de connexion pour l’utilisateur «MyUser ». (Microsoft SQL Server, Erreur : 18456)
Ce problème se produit car vous n’avez pas transféré les connexions et les mots de passe de l’instance de SQL
Server sur le serveur A vers l’instance de SQL Server sur le serveur B.
NOTE
Le message d’erreur 18456 se produit également pour d’autres raisons. Pour plus d’informations sur ces causes et
résolutions potentielles, MSSQLSERVER_18456.
Pour transférer les connexions, utilisez l’une des méthodes suivantes, selon votre situation.
Méthode 1 : réinitialiser le mot de passe sur l’ordinateur SQL Server destination (serveur B)
Pour résoudre ce problème, réinitialisez le mot de passe SQL Server ordinateur, puis scriptez la
connexion.
NOTE
L’algorithme de hachage de mot de passe est utilisé lorsque vous réinitialisez le mot de passe.
Méthode 2 : Transférer les connexions et les mots de passe vers le serveur de destination (serveur B) à
l’aide de scripts générés sur le serveur source (serveur A)
1. Créez des procédures stockées qui vous aideront à générer les scripts nécessaires pour transférer
les connexions et leurs mots de passe. Pour ce faire, connectez-vous au serveur A en utilisant SQL
Server Management Studio (SSMS) ou tout autre outil client et exécutez le script suivant :
USE [master]
GO
IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL
DROP PROCEDURE sp_hexadecimal
GO
CREATE PROCEDURE [dbo].[sp_hexadecimal]
(
@binvalue varbinary(256),
@hexvalue varchar (514) OUTPUT
)
AS
BEGIN
DECLARE @charvalue varchar (514)
DECLARE @i int
DECLARE @length int
DECLARE @hexstring char(16)
SELECT @charvalue = '0x'
SELECT @i = 1
SELECT @length = DATALENGTH (@binvalue)
SELECT @hexstring = '0123456789ABCDEF'
WHILE (@i <= @length)

BEGIN
DECLARE @tempint int
DECLARE @firstint int
DECLARE @secondint int
SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))

SELECT @firstint = FLOOR(@tempint/16)
SELECT @secondint = @tempint - (@firstint*16)
SELECT @charvalue = @charvalue + SUBSTRING(@hexstring, @firstint+1, 1) +
SUBSTRING(@hexstring, @secondint+1, 1)
SELECT @i = @i + 1
END
SELECT @hexvalue = @charvalue
END
go
IF OBJECT_ID ('sp_help_revlogin') IS NOT NULL
DROP PROCEDURE sp_help_revlogin
GO
CREATE PROCEDURE [dbo].[sp_help_revlogin]
(
@login_name sysname = NULL
)
AS
BEGIN
DECLARE @name SYSNAME
DECLARE @type VARCHAR (1)
DECLARE @hasaccess INT
DECLARE @denylogin INT
DECLARE @is_disabled INT
DECLARE @PWD_varbinary VARBINARY (256)
DECLARE @PWD_string VARCHAR (514)
DECLARE @SID_varbinary VARBINARY (85)
DECLARE @SID_string VARCHAR (514)
DECLARE @tmpstr VARCHAR (1024)
DECLARE @is_policy_checked VARCHAR (3)
DECLARE @is_expiration_checked VARCHAR (3)
Declare @Prefix VARCHAR(255)
DECLARE @defaultdb SYSNAME
DECLARE @tmpstrRole VARCHAR (1024)
DECLARE @tmpstrRole VARCHAR (1024)
IF (@login_name IS NULL)
BEGIN
DECLARE login_curs CURSOR
FOR
SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess,
l.denylogin
FROM sys.server_principals p
LEFT JOIN sys.syslogins l ON ( l.name = p.name )
WHERE p.type IN ( 'S', 'G', 'U' )
AND p.name <> 'sa'
ORDER BY p.name
END
ELSE
DECLARE login_curs CURSOR
FOR
SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name,
l.hasaccess, l.denylogin
FROM sys.server_principals p
LEFT JOIN sys.syslogins l ON ( l.name = p.name )
WHERE p.type IN ( 'S', 'G', 'U' )
AND p.name = @login_name
ORDER BY p.name
OPEN login_curs
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled,
@defaultdb, @hasaccess, @denylogin
IF (@@fetch_status = -1)
BEGIN
PRINT 'No login(s) found.'
CLOSE login_curs
DEALLOCATE login_curs
RETURN -1
END
SET @tmpstr = '/* sp_help_revlogin script '

PRINT @tmpstr
SET @tmpstr = '** Generated ' + CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME
+ ' */'
PRINT @tmpstr
PRINT ''
WHILE (@@fetch_status <> -1)

BEGIN
IF (@@fetch_status <> -2)
BEGIN
PRINT ''
SET @tmpstr = '-- Login: ' + @name
PRINT @tmpstr
SET @tmpstr='IF NOT EXISTS (SELECT * FROM sys.server_principals WHERE name =

N'''+@name+''')
BEGIN'
Print @tmpstr
IF (@type IN ( 'G', 'U'))

BEGIN -- NT authenticated account/group
SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' FROM WINDOWS WITH
DEFAULT_DATABASE = [' + @defaultdb + ']'
END
ELSE
BEGIN -- SQL Server authentication
-- obtain password and sid
SET @PWD_varbinary = CAST( LOGINPROPERTY( @name, 'PasswordHash' ) AS
varbinary (256) )
EXEC sp_hexadecimal @PWD_varbinary, @PWD_string OUT

EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT
-- obtain password policy state

SELECT @is_policy_checked = CASE is_policy_checked WHEN 1 THEN
'ON' WHEN 0 THEN 'OFF' ELSE NULL END
FROM sys.sql_logins
WHERE name = @name
SELECT @is_expiration_checked = CASE is_expiration_checked WHEN 1

THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END
FROM sys.sql_logins
WHERE name = @name
SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' WITH PASSWORD
= ' + @PWD_string + ' HASHED, SID = '
+ @SID_string + ', DEFAULT_DATABASE = [' +
@defaultdb + ']'
IF ( @is_policy_checked IS NOT NULL )

BEGIN
SET @tmpstr = @tmpstr + ', CHECK_POLICY = ' + @is_policy_checked
END
IF ( @is_expiration_checked IS NOT NULL )

BEGIN
SET @tmpstr = @tmpstr + ', CHECK_EXPIRATION = ' +
@is_expiration_checked
END
END
IF (@denylogin = 1)
BEGIN -- login is denied access
SET @tmpstr = @tmpstr + '; DENY CONNECT SQL TO ' + QUOTENAME( @name )
END
ELSE IF (@hasaccess = 0)
BEGIN -- login exists but does not have access
SET @tmpstr = @tmpstr + '; REVOKE CONNECT SQL TO ' + QUOTENAME( @name )
END
IF (@is_disabled = 1)
BEGIN -- login is disabled
SET @tmpstr = @tmpstr + '; ALTER LOGIN ' + QUOTENAME( @name ) + ' DISABLE'
END
Set @Prefix = '

exec master.dbo.sp_addsrvrolemember @loginame='''
Set @tmpstrRole=''
Select @tmpstrRole = @tmpstrRole

+ Case When sysadmin = 1 Then @Prefix + [LoginName] + ''',
@rolename=''sysadmin''' Else '' End
+ Case When securityadmin = 1 Then @Prefix + [LoginName] + ''',
@rolename=''securityadmin''' Else '' End
+ Case When serveradmin = 1 Then @Prefix + [LoginName] + ''',
@rolename=''serveradmin''' Else '' End
+ Case When setupadmin = 1 Then @Prefix + [LoginName] + ''',
@rolename=''setupadmin''' Else '' End
+ Case When processadmin = 1 Then @Prefix + [LoginName] + ''',
@rolename=''processadmin''' Else '' End
+ Case When diskadmin = 1 Then @Prefix + [LoginName] + ''',
@rolename=''diskadmin''' Else '' End
+ Case When dbcreator = 1 Then @Prefix + [LoginName] + ''',
@rolename=''dbcreator''' Else '' End
+ Case When bulkadmin = 1 Then @Prefix + [LoginName] + ''',
@rolename=''bulkadmin''' Else '' End
From (
From (
select convert(varchar(100),suser_sname(sid)) as [LoginName],
sysadmin,
securityadmin,
serveradmin,
setupadmin,
processadmin,
diskadmin,
dbcreator,
bulkadmin
from sys.syslogins
where ( sysadmin<>0
or securityadmin<>0
or serveradmin<>0
or setupadmin <>0
or processadmin <>0
or diskadmin<>0
or dbcreator<>0
or bulkadmin<>0
)
and name=@name
) L
PRINT @tmpstr
Print @tmpstrRole
Print 'END'
END
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled,
@defaultdb, @hasaccess, @denylogin
END
CLOSE login_curs
DEALLOCATE login_curs
RETURN 0
END
NOTE
Ce script crée deux procédures stockées dans la base de données maître. Les procédures sont nommées
sp_hexadecimal et sp_help_revlogin .
2. Dans l SSMS de requête, sélectionnez l’option Résultats vers texte.

3. Exécutez l’instruction suivante dans la même fenêtre de requête ou dans une nouvelle fenêtre de
requête :
EXEC sp_help_revlogin
4. Le script de sortie généré sp_help_revlogin par la procédure stockée est le script de connexion. Ce
script de connexion crée les connexions qui ont l’identificateur de sécurité (SID) d’origine et le mot
de passe d’origine.
IMPORTANT
Examinez les informations de la section Remarques ci-dessous avant de poursuivre l’exécution des étapes d’exécution sur
le serveur de destination.
Étapes sur le serveur de destination (serveur B)

Connecter serveur B à l’aide d’un outil client (tel que SSMS), puis exécutez le script généré à l’étape 4 (sortie de )
à partir du sp_helprevlogin serveur A.
Remarques
Examinez les informations suivantes avant d’exécuter le script de sortie sur l’instance sur le serveur B :
Un mot de passe peut être haché des manières suivantes :
VERSION_SHA1 : ce hachage est généré à l’aide de l’algorithme SHA1 et est utilisé dans SQL Server 2000
à SQL Server 2008 R2.
VERSION_SHA2 : ce hachage est généré à l’aide de l’algorithme SHA2 512 et est utilisé dans SQL Server
2012 et versions ultérieures.
Examinez attentivement le script de sortie. Si le serveur A et le serveur B sont dans des domaines
différents, vous devez modifier le script de sortie. Ensuite, vous devez remplacer le nom de domaine
d’origine en utilisant le nouveau nom de domaine dans les instructions CREATE LOGIN. Les connexions
intégrées qui ont accès au nouveau domaine n’ont pas le même SID que les connexions dans le domaine
d’origine. Par conséquent, les utilisateurs sont orphelins de ces connexions. Pour plus d’informations sur
la résolution de ces utilisateurs orphelins,voir Comment résoudre les problèmes d’autorisation lorsque
vous déplacez une base de données entre des serveurs en cours d’exécution SQL Server .
Si le serveur A et le serveur B se trouve dans le même domaine, le même SID est utilisé. Par conséquent,
il est peu probable que les utilisateurs soient orphelins.
Dans le script de sortie, les connexions sont créées à l’aide du mot de passe chiffré. Cela est dû à
l’argument HASHED dans CREATE LOGIN l’instruction. Cet argument spécifie que le mot de passe entré
après le hachage de l’argument PASSWORD est déjà.
Par défaut, seul un membre du rôle serveur fixe sysadmin peut exécuter une instruction à SELECT partir
de sys.server_principals l’affichage. À moins qu’un membre du rôle serveur fixe sysadmin n’accorde les
autorisations nécessaires aux utilisateurs, ils ne peuvent pas créer ni exécuter le script de sortie.
Les étapes de cet article ne transfèrent pas les informations de base de données par défaut pour une
connexion particulière. Cela est dû au fait que la base de données par défaut n’existe pas toujours sur le
serveur B. Pour définir la base de données par défaut pour une connexion, utilisez l’instruction en passant
le nom de connexion et la base de données par ALTER LOGIN défaut en tant qu’arguments.
Tri des commandes sur les serveurs source et de destination :
Serveur A et serveur sensible à la cas B : l’ordre de tri du serveur A peut ne pas prendre en compte
la cas et l’ordre de tri du serveur B peut être sensible à la cas. Dans ce cas, les utilisateurs doivent
taper les mots de passe en lettres majuscules après avoir transféré les connexions et les mots de
passe vers l’instance sur le serveur B.
Ser veur A et ser veur sensible à la cas B : L’ordre de tri du serveur A peut être sensible à la cas et
l’ordre de tri du serveur B peut ne pas prendre en compte la cas. Dans ce cas, les utilisateurs ne
peuvent pas se connecter à l’aide des connexions et des mots de passe que vous transférez à
l’instance sur le serveur B, sauf si l’une des conditions suivantes est vraie :
Les mots de passe d’origine ne contiennent aucune lettre.
Toutes les lettres des mots de passe d’origine sont en majuscules.
Sensible à la cas ou sensible à la cas sur les deux serveurs : l’ordre de tri du serveur A et du
serveur B peut être sensible à la cas, ou l’ordre de tri du serveur A et du serveur B peut ne pas
prendre en compte la cas. Dans ce cas, les utilisateurs ne sont pas en situation de problème.
Une connexion qui se trouve déjà dans l’instance sur le serveur B peut avoir un nom identique à celui du
script de sortie. Dans ce cas, vous recevez le message d’erreur suivant lorsque vous exécutez le script de
sortie sur l’instance sur le serveur B :
Le principal de serveur «MyLogin » existe déjà.
De même, une connexion qui se trouve déjà dans l’instance sur le serveur B peut avoir un SID identique à
un SID dans le script de sortie. Dans ce cas, vous recevez le message d’erreur suivant lorsque vous
exécutez le script de sortie sur l’instance sur le serveur B :
Msg 15433, Level 16, State 1, Line 1 Supplied parameter sid is in use.
Par conséquent, vous devez :

1. Examinez attentivement le script de sortie.
2. Examinez le contenu de la vue sys.server_principals dans l’instance sur le serveur B.
3. Traiter ces messages d’erreur selon le cas.
Dans SQL Server 2005, le SID d’une connexion est utilisé pour implémenter l’accès au niveau de la
base de données. Une connexion peut avoir différents SID dans différentes bases de données sur
un serveur. Dans ce cas, la connexion peut uniquement accéder à la base de données dont le SID
correspond au SID dans sys.server_principals l’affichage. Ce problème peut se produire si les
deux bases de données sont combinées à partir de serveurs différents. Pour résoudre ce problème,
supprimez manuellement la connexion de la base de données qui présente une inaltérable SID à
l’aide de l’instruction DROP USER. Ensuite, ajoutez de nouveau la connexion à l’aide de
CREATE USER l’instruction.
Références
Résoudre les problèmes des utilisateurs orphelins
CREATE LOGIN (Transact-SQL)
ALTER LOGIN (Transact-SQL)
Utiliser des certificats au format PFX dans SQL
Server
Cet article présente Microsoft PVKConverter pour SQL Server’outil. Cet outil prend en charge la conversion d’un
certificat qui utilise le format PFX au format PVK/DER.
Résumé
Pour utiliser des certificats au format PFX au Microsoft SQL Server, utilisez Microsoft PVKConverter pour SQL
Server pour convertir les fichiers de certificat PFX au format PVK/DER. Pour cela, procédez comme suit :
1. Téléchargez et installez l’outil suivant :
Microsoft PVKConverter pour SQL Server
2. Exécutez la commande suivante à une invite de commandes :
PVKConverter.exe -i <PFX format file> -o <PVK/DER format file> -d <Decryption password> -e

<Encryption password>
Cette étape traite un fichier de certificat PFX afin de générer les paires de certificats PVK/DER suivantes :
<Fichier au format PVK/DER >_1.cer
<Fichier au format PVK/DER >_2.cer et <au format PVK/DER >_2.pvk
NOTE
Le nombre de fichiers PVK/DER générés dépend du nombre de paires de clés publiques/privées contenues dans le
fichier PFX. Une paire de fichiers PVK/DER est générée pour chaque paire de clés publique/privée.
3. Utilisez SQL Query Analyzer pour exécuter le script Transact-SQL suivant :
CREATE CERTIFICATE >Certificate name>

FROM FILE = '<PVK/DER format file>.cer'
WITH PRIVATE KEY (FILE = '<PVK/DER format file>.pvk',
DECRYPTION BY PASSWORD = '<Encryption password>');
NOTE
L’espace réservé représente le mot de passe fourni par le biais de Encryption password l’option -e de
PVKConverter.exe.
SQL Server prend en charge l’importation de certificats de sécurité existants spécifiés sous la forme d’une paire
de fichiers codés au format PVK/DER. Le fichier PVK contient des informations sur la clé privée du certificat, et le
fichier DER contient les informations restantes.
Windows Le Gestionnaire de certificats prend en charge l’exportation au format PFX uniquement des certificats
existants qui contiennent des informations de clé privée Windows 2008. Windows 2008 n’a plus pris en charge
l’exportation au format PVK/DER. En revanche, SQL Server ne prend pas en charge l’importation de certificats
codés PFX. Par conséquent, il existe actuellement un problème d’interopérabilité entre Windows certificate
manager et SQL Server.
NOTE
Si le numéro de série de votre certificat est supérieur à 16 octets, consultez l’article suivant pour obtenir votre version de
SQL Server.
For Microsoft SQL Server 2014 Service Pack 1, see 3082513 FIX: TDE certificate creation fails in SQL
Server 2014 SP1 if the serial number is greater than 16 bytes.
Pour les autres versions de SQL Server, voir Not able to use PFX format certificate in SQL Server?.
S’applique à
SQL Server Web 2014
SQL Server Web 2014
SQL Server Web 2012
SQL Server Web 2008
Microsoft SQL Server 2005 Êdition Entreprise
Microsoft SQL Server 2005 Workgroup Edition
Microsoft SQL Server 2005 Édition Standard
Microsoft SQL Server 2005 Express Edition
Instructions d’utilisation SQL Server 2014 en mode
conforme FIPS 140-2
Cet article décrit les instructions pour la publication fiPS 140-2 (FIPS 140-2) et l’utilisation de Microsoft SQL
Server 2014 en mode conforme à la norme FIPS 140-2.
NOTE
Les termes « Conformité FIPS 140-2 », « Conformité FIPS 140-2 » et « Mode conforme FIPS 140-2 » sont définis
ici pour une utilisation et une clarté. Ces termes ne sont pas reconnus ou définis par le gouvernement. Les
gouvernements des États-Unis et du Canada reconnaissent la validation des modules de chiffrement par rapport
aux normes telles que fiPS 140-2, mais pas l’utilisation de modules de chiffrement d’une manière spécifiée ou
conforme. Dans cet article, nous utilisons « conformité FIPS 140-2 », « Conformité FIPS 140-2 » et « Mode
conforme FIPS 140-2 » au sens où SQL Server 2014 utilise uniquement les instances fiPS 140-2 validées
d’algorithmes et de fonctions de hachage dans toutes les instances dans lesquelles les données chiffrées ou
hachées sont importées ou exportées à partir de SQL Server 2014. En outre, cela signifie que SQL Server 2014
gère les clés de manière sécurisée, selon les besoins des modules de chiffrement validés fiPS 140-2. Le processus
de gestion des clés inclut également la génération de clés et le stockage de clés.
Nous utilisons « certifié » ici pour signifier que l’instance de l’algorithme est validée par LA FIPS 140-2 ou que le
système d’exploitation contient des instances d’algorithmes validées par FIPS 140-2.
Qu’est-ce que FIPS ?

La norme FIPS (Federal Information Processing Standard) est une norme développée par les deux organismes
publics suivants :
National Institute of Standards and Technology (NIST) aux États-Unis
Établissement de sécurité des communications (CSE) au Canada
Les normes FIPS sont recommandées ou obligatoires pour une utilisation dans les systèmes informatiques
gérés par le gouvernement fédéral aux États-Unis et au Canada.
Qu’est-ce que FIPS 140-2 ?

FIPS 140-2 est une instruction intitulée « Security Requirements for Cryptographic Modules ». Il spécifie les
algorithmes de chiffrement et les algorithmes de hachage qui peuvent être utilisés et la façon dont les clés de
chiffrement doivent être générées et gérées. Certains matériels, logiciels et processus contenant les algorithmes
peuvent être considérés comme certifiés FIPS 140-2. Les autres matériels, logiciels et processus qui appellent les
algorithmes corrects peuvent être conformes à la norme FIPS 140-2.
Quelle est la différence entre la conformité FIPS 140-2 et la

certification FIPS 140-2 ?
SQL Server 2014 peut être configuré et exécuté d’une manière conforme à la norme FIPS 140-2. Pour
configurer SQL Server 2014 de cette manière, SQL Server 2014 doit s’exécuter sur un système d’exploitation
certifié FIPS 140-2 ou sur un système d’exploitation qui fournit des modules de chiffrement certifiés.
La différence entre la conformité et la certification n’est pas subtile. Les algorithmes peuvent être certifiés. Il est
insuffisant d’utiliser un algorithme simplement parce qu’il est répertorié dans les listes approuvées dans FIPS
140-2. Au lieu de cela, vous devez utiliser une instance d’un tel algorithme certifié. Cela signifie que l’instance
est validée par le gouvernement. La certification nécessite des tests et une vérification par un laboratoire
d’évaluation approuvé par le gouvernement des États-Unis ou du Canada. Windows Server 2012 versions
ultérieures, ainsi que Windows 8 et versions ultérieures contiennent l’instance certifiée de chaque algorithme
autorisé. Plus important encore, un appel à chacun de ces algorithmes fournit uniquement l’instance certifiée.
Quels produits d’application peuvent être conformes à la norme FIPS

140-2 ?
Toutes les applications qui effectuent le chiffrement ou le hachage et qui s’exécutent sur une version certifiée de
Windows peuvent être conformes en utilisant uniquement les instances certifiées des algorithmes approuvés et
en respectant les exigences de génération de clés et de gestion des clés. Pour ce faire, vous pouvez utiliser l’une
des méthodes suivantes :
En utilisant la fonction Windows pour la génération de clés et la gestion des clés
En se conformant aux exigences de génération de clés et de gestion des clés au sein de l’application
N’ignorez pas qu’une application conforme FIPS peut contenir des domaines dans lesquels des algorithmes ou
des processus non conformes sont activés. Par exemple, certains processus internes qui restent dans le système
et certaines données externes qui doivent être chiffrées en plus par une instance d’algorithme certifiée sont
autorisés.
La SQL Server 2014 est-elle toujours conforme à la norme FIPS 140-2

?
Non. SQL Server 2014 peut être conforme à la norme FIPS 140-2, car il peut être configuré et exécuté de telle
sorte qu’il utilise uniquement les instances d’algorithme certifiées FIPS 140-2 qui sont appelées à l’aide de
CryptoAPI pour le chiffrement ou par hachage dans chaque instance dans laquelle la conformité FIPS 140-2 est
requise.
Comment configurer SQL Server 2014 pour être conforme à la norme

FIPS 140-2 ?
Conditions requises pour le système d’exploitation
Installez SQL Server 2014 sur un serveur basé sur l’un des systèmes d’exploitation suivants :
Windows Server 2012
Windows 8
Windows 8.1
Windows 10
Windows’administration système requise
Le mode FIPS doit être définie avant SQL Server 2014 est démarré. SQL Server lit le paramètre au démarrage.
Pour définir le mode FIPS, suivez les étapes suivantes :
1. Log on to Windows as a Windows system administrator.
2. Cliquez sur Démarrer .
3. Cliquez sur Panneau de contrôle.
4. Cliquez sur Outils d’administration. (Vous de devez peut-être basculer vers Icônes Darge pour l’étape
suivante.)
5. Cliquez sur Stratégie de sécurité locale. La fenêtre Sécurité Paramètres s’affiche.
6. Dans le volet de navigation, cliquez sur Stratégies locales, puis sur Options de sécurité.
7. Dans le volet droit, double-cliquez sur Chiffrement système : utilisez des algorithmes conformes FIPS
pour le chiffrement, le hachage et la signature.
8. Dans la boîte de dialogue qui s’affiche, cliquez sur Activé, puis cliquez sur Appliquer.
9. Cliquez sur OK .
10. Fermez la fenêtre Sécurité Paramètres locale.
SQL Server requise de l’administrateur
Lorsque le service SQL Server (lorsqu’un point de terminaison est configuré pour service Broker ou mise en
miroir de bases de données) détecte que le mode FIPS est activé au démarrage, SQL Server enregistre le
message suivant dans le journal des erreurs SQL Server :
Le transport Service Broker est en cours d’exécution en mode de conformité FIPS.
En outre, le message suivant peut être consigné dans le journal Windows événements suivants :
Le transport de mise en miroir de bases de données est en cours d’exécution en mode de conformité FIPS.
Vous pouvez vérifier que le serveur est en cours d’exécution en mode FIPS en cherchant ces messages.
Pour la sécurité des boîtes de dialogue (entre les services), le chiffrement utilise l’instance certifiée FIPS
d’Advanced Encryption Standard (AES) si le mode FIPS est activé. Si le mode FIPS est désactivé, le
chiffrement utilise RC4.
Lorsque vous configurez un point de terminaison du service Broker en mode FIPS, l’administrateur doit
spécifier « AES » pour le service Broker. Si le point de terminaison est configuré sur RC4, SQL Server
génère une erreur. Par conséquent, la couche de transport ne démarre pas.
Comment fonctionne SQL Server 2014 en mode conforme FIPS 140-2

?
Avec le mode FIPS en Windows est désactivé, dans tous les domaines dans lesquels l’utilisateur n’a pas le
choix entre chiffrer ou hachage et sur la façon dont il sera effectué, SQL Server 2014 s’exécutera
conformément à LA FIPS 140-2. (SQL Server 2014 utilisera CryptoAPI dans Windows et utilisera
uniquement les instances certifiées des algorithmes.)
Avec le mode FIPS en Windows activé, dans toutes les zones dans lesquelles l’utilisateur a le choix
d’utiliser le chiffrement, SQL Server 2014 n’activera que le chiffrement conforme à la norme FIPS 140-2
ou n’activera aucun chiffrement.
Informations importantes pour les développeurs de logiciels : dans tous les domaines dans lesquels le
développeur ou l’utilisateur écrit son propre code pour le chiffrement ou le hachage, il doit être invité à
utiliser uniquement CryptoAPI (et par conséquent uniquement les instances certifiées) et à spécifier
uniquement les algorithmes autorisés par FIPS 140-2. For the official National Institute of Standards and
Technology (NIST) list of FIPS 140-2 approved cryptographic algorithms, go to Annexes A, C, and D in
Cryptographic Module Validation Program.
Quel est l’effet de l’exécution SQL Server 2014 en mode conforme

FIPS 140-2 ?
L’utilisation d’un chiffrement plus fort peut avoir un faible impact sur les performances pour les
processus pour lesquels un chiffrement moins fort est autorisé lorsque le processus n’est pas conforme à
la norme FIPS 140-2.
La sélection du chiffrement pour SSIS (UseEncryption=True) génère un message d’erreur qui indique que
le chiffrement disponible est incompatible avec la conformité FIPS et n’est pas autorisé. En d’autres
termes, aucun chiffrement du processus de message n’est effectué.
L’utilisation du chiffrement avec le système DTS hérité n’est pas conforme à la norme FIPS 140-2. Pour
DTS, le mode FIPS dans Windows n’est pas vérifié. Par conséquent, il incombe à l’utilisateur de ne
sélectionner aucun chiffrement pour rester conforme.
Étant donné que la plupart des processus de chiffrement et de hachage SQL Server 2014 sont déjà
conformes à la norme FIPS 140-2, l’exécution en conformité totale (autrement dit, avec le mode FIPS en
Windows est désactivé) aura peu ou pas d’effet sur l’utilisation ou les performances du produit.
Où puis-je en savoir plus sur FIPS 140-2 ?

Pour plus d’informations sur la norme FIPS 140-2, voir la composition NIST suivante :
Exigences de sécurité pour les modules de chiffrement
produits.
Utiliser SQL Server 2016 en mode conforme FIPS
140-2
Cet article présente les instructions FIPS 140-2 et explique comment utiliser SQL Server2016 en mode
conforme FIPS 140-2.
NOTE
Les termes « Conformité FIPS 140-2 », « Conformité FIPS 140-2 » et « Mode conforme FIPS 140-2 » sont définis
ici pour une utilisation et une clarté. Ces termes ne sont pas reconnus ou définis par le gouvernement. Les
gouvernements des États-Unis et du Canada reconnaissent la validation des modules de chiffrement par rapport
aux normes telles que FIPS 140-2 au lieu d’utiliser des modules de chiffrement d’une manière spécifiée ou
conforme.
Dans cet article, Nous utilisons le mode conforme FIPS 140-2, la conformité FIPS 140-2 et le mode conforme FIPS
140-2 pour que SQL Server 2016 utilise uniquement les instances fiPS 140-2 validées d’algorithmes et de
fonctions de hachage dans toutes les instances dans lesquelles les données chiffrées ou hachées sont importées
ou exportées à partir de SQL Server 2016. En outre, cela signifie que SQL Server 2016 gérera les clés de manière
sécurisée, comme requis pour les modules de chiffrement validés par FIPS 140-2. Le processus de gestion des clés
inclut également la génération de clés et le stockage de clés.
Nous utilisons « certifié » ici pour signifier que l’instance de l’algorithme est validée PAR LA FIPS 140-2 ou que le
système d’exploitation contient des instances d’algorithmes validées par FIPS140-2.
Qu’est-ce que FIPS ?

La norme FIPS (Federal Information Processing Standard) est une norme développée par les deux organismes
publics suivants :
National Institute of Standards and Technology (NIST) aux États-Unis
Établissement de sécurité des communications (CSE) au Canada
Les normes FIPS sont recommandées ou obligatoires pour une utilisation dans les systèmes informatiques
gérés par le gouvernement fédéral aux États-Unis et au Canada.

FIPS 140-2 est une instruction intitulée « Security Requirements for Cryptographic Modules ». Il spécifie les
chiffrement doivent être générées et gérées. Certains matériels, logiciels et processus qui contiennent les
algorithmes peuvent être considérés comme certifiés FIPS 140-2, et d’autres matériels, logiciels et processus qui
appellent les algorithmes corrects peuvent être considérés comme conformes à la norme FIPS 140-2.
Quelle est la différence entre la conformité FIPS 140-2 et la

certification FIPS 140-2 ?
SQL Server 2016 peut être configuré et exécuté d’une manière conforme à la norme FIPS 140-2. Pour
configurer SQL Server 2016 de cette manière, il doit s’exécuter sur un système d’exploitation certifié FIPS 140-2
ou qui fournit des modules de chiffrement certifiés. La différence entre la conformité et la certification n’est pas
subtile. Les algorithmes peuvent être certifiés. Il est insuffisant d’utiliser un algorithme simplement parce qu’il
est répertorié dans les listes approuvées dans FIPS 140-2. Au lieu de cela, vous devez utiliser une instance d’un
tel algorithme certifié. Cela signifie que l’instance est validée par le gouvernement. La certification nécessite des
tests et une vérification par les États-Unis. ou laboratoire d’évaluation approuvé par le gouvernement canadien.
Windows Server 2012 et versions ultérieures, et Windows 8 versions ultérieures contiennent l’instance certifiée
de chaque algorithme autorisé. Plus important encore, un appel à chacun de ces algorithmes fournit
uniquement l’instance certifiée.
Quelles applications peuvent être conformes à la norme FIPS 140-2 ?

Toutes les applications qui effectuent le chiffrement ou le hachage et qui s’exécutent sur une version certifiée de
Windows peuvent être conformes en utilisant uniquement les instances certifiées des algorithmes approuvés et
en respectant les exigences de génération de clés et de gestion des clés. Cela nécessite l’utilisation de la
Windows pour la génération de clés et la gestion des clés, ou la conformité avec les exigences de génération de
clés et de gestion des clés au sein de l’application. Certaines zones d’une application conforme FIPS peuvent
exister lorsque des algorithmes ou des processus non conformes sont activés. Par exemple, certains processus
internes qui restent dans le système et certaines données externes qui sont prévues pour être chiffrées en plus
par une instance d’algorithme certifiée sont autorisés.
La SQL Server 2016 est-elle toujours conforme à la norme FIPS 140-2

?
Non. SQL Server 2016 peut être conforme à la norme FIPS 140-2, car il peut être configuré et exécuté de sorte
qu’il utilise uniquement les instances d’algorithme certifiées FIPS 140-2. En outre, ces instances sont appelées à
l’aide de CryptoAPI ou CGN pour le chiffrement ou par hachage dans chaque instance où la conformité FIPS
140-2 est requise.
Comment configurer SQL Server 2016 pour être conforme à la norme

FIPS 140-2 ?
Système d’exploitation requis
Vous devez installer SQL Server 2016 sur un hôte exécutant l’un des systèmes d’exploitation suivants :
Windows Server 2012
Windows Server 2016
Windows 8
Windows 8.1
Windows 10
Le mode FIPS doit être définie avant SQL Server 2016 est démarré. SQL Server lit le paramètre au démarrage.
Pour définir le mode FIPS, suivez les étapes suivantes :
1. Log on to Windows as a Windows system administrator.
2. Cliquez sur Démarrer .
3. Cliquez sur Panneau de contrôle.
4. Cliquez sur Outils d’administration. (Vous de devez peut-être basculer vers des icônes de grande taille
pour l’étape suivante.)
5. Cliquez sur Stratégie de sécurité locale. La fenêtre Sécurité Paramètres locale s’affiche.
6. Dans le volet de navigation, cliquez sur Stratégies locales, puis sur Options de sécurité.
7. Dans le volet droit, double-cliquez sur Chiffrement système : utilisez des algorithmes conformes FIPS
pour le chiffrement, le hachage et la signature.
8. Dans la boîte de dialogue qui s’affiche, cliquez sur Activé, puis cliquez sur Appliquer.
9. Cliquez sur OK .
10. Fermez la fenêtre Sécurité Paramètres locale.
SQL Server requise de l’administrateur
Lorsque le service SQL Server (lorsqu’un point de terminaison est configuré pour service Broker ou mise en
miroir de bases de données) détecte que le mode FIPS est activé au démarrage, SQL Server enregistre le
message suivant dans le journal des erreurs SQL Server :
Le transport Service Broker est en cours d’exécution en mode de conformité FIPS.
En outre, le message suivant peut être consigné dans le journal Windows événements suivants :
Le transport de mise en miroir de bases de données est en cours d’exécution en mode de conformité FIPS.
Vous pouvez vérifier que le serveur est en cours d’exécution en mode FIPS en cherchant ces messages.
NOTE
Pour la sécurité des boîtes de dialogue (entre les services), le processus de chiffrement utilise l’instance certifiée FIPS
d’AES si le mode FIPS est activé. Si le mode FIPS est désactivé, le processus de chiffrement utilise toujours AES.
Lorsque vous configurez un point de terminaison du service Broker en mode FIPS, l’administrateur doit spécifier « AES
» pour le service Broker. Si le point de terminaison est configuré sur RC4, SQL Server génère une erreur. Par
conséquent, la couche de transport ne démarre pas.
Comment fonctionne SQL Server 2016 en mode conforme FIPS 140-2

?
Lorsque le mode FIPS en Windows est allumé, dans tous les domaines où l’utilisateur n’a pas le choix
entre chiffrement ou hachage et mode de traitement, SQL Server 2016 s’exécutera conformément à LA
FIPS 140-2. (SQL Server 2016 utilisera CryptoAPI dans Windows et utilisera uniquement les instances
certifiées des algorithmes.)
Avec le mode FIPS en Windows activé, dans toutes les zones où l’utilisateur a le choix d’utiliser le
chiffrement, SQL Server 2016 n’activera que le chiffrement conforme à la norme FIPS 140-2 ou n’activera
aucun chiffrement.
Informations impor tantes pour les développeurs de logiciels : Dans tous les domaines où le
développeur ou l’utilisateur écrit son propre code pour le chiffrement ou le hachage, il doit être invité à
utiliser uniquement CryptoAPI (et par conséquent uniquement les instances certifiées) et à spécifier
uniquement les algorithmes autorisés par fiPS 140-2.Pour obtenir la liste NIST officielle des algorithmes
de chiffrement approuvés par la FIPS 140-2, voir Annexes A, C et D dans le programme de validation de
modulede chiffrement.

FIPS 140-2 ?
Lorsque vous utilisez un chiffrement plus fort, cela peut avoir un faible impact sur les performances pour
les processus pour lesquels un chiffrement moins robuste est autorisé lorsque le processus n’est pas
conforme à la norme FIPS 140-2.
La sélection du chiffrement pour SSIS (UseEncryption=True) génère une erreur qui indique que le
chiffrement disponible est incompatible avec la conformité FIPS et n’est pas autorisé. En d’autres termes,
aucun chiffrement du processus de message n’est effectué.
Lorsque vous utilisez le chiffrement avec DTS hérité, le chiffrement n’est pas conforme à la norme FIPS
140-2. Pour DTS, le mode FIPS Windows n’est pas vérifié. Par conséquent, il incombe à l’utilisateur de ne
sélectionner aucun chiffrement pour rester conforme.
Étant donné que la plupart des processus de chiffrement et de hachage SQL Server 2016 sont déjà
conformes à la norme FIPS 140-2, l’exécution en conformité totale (autrement dit, avec le mode FIPS en
Windows est désactivé) aura peu ou pas d’effet sur l’utilisation ou les performances de l’application.
Où puis-je en savoir plus sur FIPS 140-2 ?

Pour plus d’informations sur la norme FIPS 140-2, voir Normes et documents CMVP FIPS 140-2.
Microsoft fournit des informations de contact de sociétés tierces afin de vous aider à obtenir un support
technique. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas la
précision de ces informations de contact tierces.
Instructions d’utilisation SQL Server 2008 en mode
conforme FIPS 140-2
Cet article décrit la norme FIPS 140-2 et explique comment utiliser SQL Server 2008 en mode conforme à la
norme FIPS 140-2.
Introduction
Cet article décrit les instructions FIPS (Federal Information Processing Standard) 140-2 et explique comment
utiliser Microsoft SQL Server 2008 en mode conforme FIPS 140-2.
NOTE
Les termes « FiPS 140-2-compliant », « FIPS 140-2 compliance » et « FIPS 140-2-compliant mode » sont définis ici pour
une utilisation et une clarté. Ces termes ne sont pas reconnus ou définis par le gouvernement. Les gouvernements des
États-Unis et du Canada reconnaissent la validation des modules de chiffrement par rapport aux normes telles que FIPS
140-2 et non leur utilisation d’une manière spécifiée ou conforme. Dans cet article, nous définissons « conformité FIPS
140-2 », « Conformité FIPS 140-2 » et « Mode de conformité FIPS 140-2 » pour SQL Server 2008 utilise uniquement les
instances fiPS 140-2 validées d’algorithmes et de fonctions de hachage dans toutes les instances dans lesquelles les
données chiffrées ou hachées sont importées ou exportées vers SQL Server 2008. En outre, ces termes signifient que SQL
Server 2008 gère les clés de manière sécurisée selon les besoins des modules de chiffrement validés fiPS 140-2. Le
processus de gestion des clés inclut également les fonctionnalités de génération de clés et de stockage de clés.
Qu’est-ce que FIPS

FIPS signifie normes de traitement des informations fédérales. Les NORMES FIPS sont des normes développées
par deux organismes publics. La première est le National Institute of Standards and Technology aux États-Unis.
L’autre est le Centre de sécurité des communications au Canada. Les normes FIPS sont des normes
recommandées ou obligatoires pour une utilisation dans les systèmes informatiques gérés par le gouvernement
fédéral (États-Unis ou Canadien).

FIPS 140-2 est une déclaration des « Exigences de sécurité pour les modules de chiffrement ». Il spécifie les
chiffrement doivent être générées et gérées. Certains matériels, logiciels et processus peuvent être validés par
un laboratoire de validation approuvé au niveau FIPS 140-2. Certaines d’entre elles peuvent également être
décrites comme conformes à la norme FIPS 140-2, comme le terme est défini dans cet article.
Quelle est la différence entre une application « conforme à la norme

FIPS 140-2 » et une application « fiPS 140-2 validée »
Vous pouvez configurer SQL Server 2008 pour qu’il s’exécute en tant qu’application conforme FIPS 140-2. Pour
ce faire, vous devez exécuter SQL Server 2008 sur un système d’exploitation qui utilise un fournisseur de
services de chiffrement fiPS 140-2 validé ou qui fournit un module de chiffrement qui a été validé. La différence
entre la conformité et la validation n’est pas subtile. Les algorithmes peuvent être validés. Réalisez qu’il n’est pas
suffisant d’utiliser les algorithmes des listes approuvées dans FIPS 140-2. Vous devez utiliser des instances
d’algorithmes qui ont été validées par la fiPS 140-2. La validation nécessite des tests et une vérification par un
laboratoire d’évaluation approuvé par le gouvernement. Windows Server 2008, Windows Server 2003 et
Windows XP contiennent les modules de chiffrement approuvés, et les modules, y compris les instances
spécifiques des algorithmes, ont été testés en laboratoire et validés par le gouvernement.
Quelles applications peuvent être conformes à la norme FIPS 140-2 ?

Toutes les applications qui effectuent le chiffrement ou le hachage et qui s’exécutent sur une version validée d’un
fournisseur de services de chiffrement Windows peuvent être conformes si elles utilisent uniquement les
instances validées des algorithmes approuvés. Ces applications doivent également respecter les exigences de
génération et de gestion des clés en utilisant une fonction clé Windows ou en respectant les exigences de
génération et de gestion des clés dans l’application. En outre, dans certains cas, les algorithmes ou processus
non conformes sont autorisés dans une application conforme FIPS 140-2. Par exemple, les données peuvent être
chiffrées à l’aide d’un algorithme non conforme si, sous cette forme chiffrée, les données restent dans
l’application, autrement dit, si les données ne sont pas exportées sous cette forme, ou si les données sont
chiffrées (enveloppées) à l’aide d’un algorithme conforme FIPS.
Cela signifie-t-SQL Server 2008 est toujours conforme à la norme FIPS

140-2
Non. Cela signifie que SQL Server 2008 peut être configuré pour s’exécuter en mode conforme FIPS 140-2.
Comment configurer SQL Server 2008 pour utiliser un module de

chiffrement fiPS 140-2 validé
Système d’exploitation requis
Vous devez installer SQL Server 2008 sur un ordinateur Windows Server 2008, un ordinateur Windows
Vista, un ordinateur Windows Server 2003 ou un ordinateur Windows XP.
Vous devez activer le mode FIPS avant de commencer SQL Server 2008. Cela est dû au SQL Server 2008
lit le paramètre FIPS au démarrage. Pour activer FIPS, suivez ces étapes.
Pour Windows Server 2008 et Windows Vista
1. Utilisez les informations d’identification d’administration pour vous connecter à l’ordinateur.
2. Si vous utilisez Windows Server 2008, cliquez sur Démarrer, sur Exécuter, tapez gpedit.msc,
puis appuyez sur Entrée. L’Éditeur de stratégie de groupe local s’ouvre. Si vous utilisez un
ordinateur Windows Vista, cliquez sur Démarrer, tapez gpedit.msc dans la zone Démarrer la
recherche, puis appuyez sur Entrée.
3. Dans l’Éditeur de stratégie de groupe local, double-cliquez Windows Paramètres sous le nœud
Configuration ordinateur, puis double-cliquez sur Sécurité Paramètres .
4. Sous le nœud Sécurité Paramètres, double-cliquez sur Stratégies locales, puis cliquez sur
Options de sécurité.
5. Dans le volet d’informations, double-cliquez sur Chiffrement système : utilisez des
algorithmes conformes FIPS pour le chiffrement, le hachage et la signature.
6. Dans la boîte de dialogue Chiffrement système : utiliser des algorithmes conformes FIPS
pour le chiffrement, le hachage et la signature, cliquez sur Activé, puis cliquez sur OK pour
fermer la boîte de dialogue.
7. Fermez l’Éditeur de stratégie de groupe local.
Pour Windows Server 2003 et Windows XP
1. Utilisez les informations d’identification d’administration pour vous connecter à l’ordinateur.
2. Cliquez sur Démarrer, cliquez sur Exécuter, tapez gpedit.msc, puis appuyez sur Entrée.
3. Dans la fenêtre Stratégie de groupe, double-cliquez Windows Paramètres sous le nœud
Configuration ordinateur, puis double-cliquez sur Sécurité Paramètres .
4. Sous le nœud Sécurité Paramètres, double-cliquez sur Stratégies locales, puis cliquez sur
Options de sécurité.
5. Dans le volet d’informations, double-cliquez sur Chiffrement système : utilisez des
algorithmes conformes FIPS pour le chiffrement, le hachage et la signature.
6. Dans la boîte de dialogue Chiffrement système : utiliser des algorithmes conformes FIPS
pour le chiffrement, le hachage et la signature, cliquez sur Activé, puis cliquez sur OK pour
fermer la boîte de dialogue.
7. Fermez la fenêtre stratégie de groupe.
SQL Server’administrateur 2008

Lorsque le service SQL Server 2008 détecte que le mode FIPS est activé au démarrage, SQL Server 2008
enregistre le message suivant dans le journal d’erreurs SQL Server:
Le transport Service Broker est en cours d’exécution en mode de conformité FIPS
En outre, le message suivant peut être enregistré dans le journal des applications :
Le transport de mise en miroir de bases de données est en cours d’exécution en mode de conformité
FIPS
Pour vérifier que le serveur est en cours d’exécution en mode FIPS, recherchez ces messages.
Pour obtenir la sécurité des boîtes de dialogue entre les services, le processus de chiffrement utilise
l’instance certifiée FIPS de la norme AES (Advanced Encryption Standard) si le mode FIPS est activé. Si le
mode FIPS est désactivé, le processus de chiffrement utilise RC4.
Lorsque vous configurez un point de terminaison Service Broker en mode FIPS, vous devez spécifier AES
pour le service Broker. Si le point de terminaison est configuré sur RC4, SQL Server génère une erreur.
Par conséquent, la couche de transport ne démarre pas.
Fonctionnement SQL Server 2008 en mode conforme FIPS 140-2

Si le mode FIPS dans Windows est allumé et si l’utilisateur n’a pas le choix de chiffrer ou de hachage des
données et de savoir comment les chiffrer, SQL Server 2008 fonctionne en mode conforme à la norme
FIPS 140-2. SQL Server 2008 utilisera CryptoAPI et utilisera uniquement les instances validées des
algorithmes.
Si le mode FIPS est allumé et si l’utilisateur a le choix d’utiliser ou non le chiffrement, SQL Server 2008
autorise uniquement le chiffrement conforme à la norme FIPS 140-2 ou n’autorise aucun chiffrement.
Informations importantes pour les développeurs
Si vous écrivez votre propre code pour le chiffrement ou le hachage, vous devez utiliser uniquement
CryptoAPI. Vous devez spécifier uniquement les algorithmes autorisés par FIPS 140-2. Plus précisément,
utilisez uniquement la triple norme de chiffrement de données (3DES) ou AES pour le chiffrement et
uniquement SHA-1 pour le hachage. Vous pouvez utiliser les mots clés suivants dans SQL Server 2008
pour les algorithmes FIPS 140-2 validés respectifs :
DESX(Three-key triple DES)
Triple-DES(Two-key triple DES)
TRIPLE_DES_3KEY(Three-key triple DES)
TRIPLE_DES_2KEY(Two-key triple DES)
NOTE
La sélection de DESX ne fournit pas d’algorithme DESX dans SQL Server 2005 ou SQL Server 2008. Dans les deux
cas, la sélection de DESX fournit une instance validée du triple DES à trois touches.
Informations importantes pour les développeurs

SQL Server 2008 prend en charge une fonctionnalité de gestion des clés Enterprise (EKM) qui permet la
gestion des clés de chiffrement sur un module de stockage matériel (HSM) tiers distinct. Pour fonctionner
en mode conforme FIPS 140-2 et utiliser EKM, l’une des deux conditions suivantes doit être vraie :
Le module de chiffrement externe doit être validé PAR LA FIPS 140-2.
Certains algorithmes utilisés par le module de chiffrement doivent être validés fiPS 140-2. Utilisez
uniquement les instances d’algorithmes validés lorsque le chiffrement ou le déchiffrement fiPS 140-2
est requis pour importer ou exporter des données vers ou depuis SQL Server.
En outre, les données qui seront chiffrées ou déchiffrées par le module de chiffrement externe doivent
être transmises sous forme chiffrée à l’aide d’une instance validée PAR LA FIPS 140-2.

FIPS 140-2
L’utilisation d’un chiffrement plus fort peut avoir un faible effet sur les performances pour les processus
pour lequel un chiffrement moins fort est autorisé lorsque le processus n’est pas conforme à la norme
FIPS 140-2.
La sélection du chiffrement pour SSIS (UseEncryption=True) génère un message d’erreur that the
available encryption is incompatible with FIPS compliance and is not allowed. En d’autres termes, aucun
chiffrement du processus de message n’est effectué.
L’utilisation du chiffrement avec les services de transformation de données (DTS) hérités n’est pas
conforme à la norme FIPS 140-2. Pour DTS, le mode FIPS dans Windows n’est pas vérifié. Pour rester
conforme, vous ne devez pas sélectionner le chiffrement.
La SQL Server processus de chiffrement et de hachage 2008 utilisent déjà un module de chiffrement fiPS
140-2 validé. Par conséquent, si vous exécutez une application en mode conforme FIPS 140-2 lorsque le
mode FIPS est allumé en Windows, l’utilisation ou les performances de l’application n’ont que très peu ou
pas d’effet.
Clause d’exclusion de responsabilité tierce

produits.
Questions fréquemment posées sur l’outil de
diagnostic du support Microsoft
Cet article fournit les réponses et les questions sur l’outil de diagnostic du support Microsoft (MSDT).
Version du produit d’origine : Windows
Introduire
Cet article répond aux questions fréquemment posées sur l’utilisation de l’outil de diagnostic du support
Microsoft sur les systèmes d’exploitation suivants :
Windows XP
Windows Server 2003
Windows Vista
Windows Server 2008
L’outil de diagnostic du support Microsoft (MSDT) collecte des informations à envoyer au Support Microsoft. Le
Support Microsoft analyse ensuite ces informations et les utilise pour déterminer la résolution des problèmes
que vous pouvez être confrontés sur votre ordinateur.
Pour Windows XP et Windows Server 2003, MSDT s’exécute sur une session Internet Explorer Windows via
l’installation d’un ActiveX. Pour Windows Vista et Windows Server 2008, MSDT s’exécute à l’aide d’un outil
inbuilt nommé msdt.exe.
Il existe 9 questions et réponses comme suit :
Q1 : Comment exécuter MSDT sur un ordinateur exécutant Windows Server 2003 ou Windows XP ?
Vous pouvez exécuter MSDT sur un ordinateur exécutant Windows Server 2003 ou Windows XP de deux
manières. Si votre ordinateur dispose d’une connexion Internet, suivez les étapes suivantes :
1. Dans Internet Explorer, accédez à l’URL qui vous a été envoyée par Microsoft.
2. Dans le menu Outils , cliquez sur Options Internet .
3. Sous l’onglet Sécurité, sélectionnez l’icône Sites de confiance, puis cliquez sur Sites.
4. Ajoutez la liste d’URL suivante des sites de confiance :
https://support.microsoft.com
5. Sélectionnez Cet ordinateur rencontre le problème, puis cliquez sur Continuer.
6. Assurez-vous que le contrôle de ActiveX de diagnostic du support Microsoft est installé. Pour cela,
a. Vérifiez la présence d’une barre jaune qui vous demande d’installer le module.
b. Cliquez sur la barre jaune, puis suivez les instructions pour installer le contrôle.
c. Assurez-vous que l’option Collecter automatiquement les données est sélectionnée, puis cliquez sur
Démarrer la collecte.
NOTE
Selon la vitesse de votre connexion Internet, vous pouvez vous attendre à un délai de 1 à 5 minutes après avoir
cliqué sur Démarrer la collecte.
7. Attendez que l’exécution du diagnostic soit terminée. (Selon le package de diagnostic en cours
d’exécution, l’exécution peut prendre plusieurs minutes.)
8. Sélectionnez l’option de téléchargement des données vers le Support Microsoft.
Si votre ordinateur n’a pas de connexion Internet, accédez à l’URL qui vous a été envoyée par Microsoft sur un
ordinateur sur lequel une connexion Internet est disponible, puis générez un package autonome que vous
pouvez exécuter sur l’ordinateur sans connexion Internet. Pour plus d’informations, voir « Q3 : Comment
exécuter MSDT sur un ordinateur sans connexion Internet ? »
Q2 : Comment exécuter MSDT sur un ordinateur exécutant Windows Vista ou Windows Server 2008 ?
Vous pouvez exécuter MSDT sur un ordinateur qui exécute Windows Vista ou Windows Server 2008 de deux
manières. Si votre ordinateur dispose d’une connexion Internet, vous pouvez exécuter MSDT directement via
Internet Explorer ou à l’aide msdt.exe'outil. Dans ce cas, accédez à l’URL qui vous a été envoyée par Microsoft,
puis suivez les instructions décrites sur la page web, soit en cliquant sur collecte de données, soit en exécutant
l’outil MSDT et en tapant la touche de passage fournie. Ensuite, suivez les instructions pour exécuter le package
de diagnostic.
Si votre ordinateur n’a pas de connexion Internet, accédez à l’URL qui vous a été envoyée par Microsoft sur un
ordinateur sur lequel une connexion Internet est disponible, puis générez un package autonome que vous
pouvez exécuter sur l’ordinateur sans connexion Internet. Pour plus d’informations, voir « Q3 : Comment
exécuter MSDT sur un ordinateur sans connexion Internet ? »
Q3 : Comment exécuter MSDT sur un ordinateur sans connexion Internet ?
Vous pouvez exécuter l’outil MSDT sur un ordinateur sans connexion Internet à l’aide d’un package exécutable
généré sur un ordinateur sur lequel une connexion Internet est disponible. Ce fichier exécutable (appelé «
package hors connexion ») peut être utilisé pour obtenir des informations de diagnostic sur tout ordinateur
exécutant Windows XP, Windows Server 2003, Windows Vista ou Windows Server 2008 et génère un fichier
CAB qui contient des données de diagnostic qui peuvent être transférées au Support Microsoft.
Pour exécuter MSDT sur un ordinateur sans connexion Internet, suivez les instructions de « Q1 : Comment
exécuter MSDT sur un ordinateur exécutant Windows Server 2003 ou Windows XP ? » ou « Q2 : Comment
exécuter MSDT sur un ordinateur exécutant Windows Vista ou Windows Server 2008 ? » en fonction du système
d’exploitation. Suivez ces instructions sur un ordinateur sur lequel une connexion Internet est disponible pour
commencer à exécuter le package de diagnostic. Une fois l’exécution du package de diagnostic démarrée, un
écran intitulé « Sélectionnez l’ordinateur qui rencontre le problème » ou « Quel ordinateur a un problème ? »
Suivez ces étapes sur l’ordinateur qui exécute le package de diagnostic.
1. Copiez le package hors connexion. Pour ce faire, suivez ces étapes, en fonction du système d’exploitation
de l’ordinateur qui exécute le package de diagnostic.
Pour Windows XP ou Windows Server 2003
a. Sélectionnez le problème sur une autre option d’ordinateur, puis cliquez sur Continuer.
b. Cliquez sur Créer un fichier.
NOTE
Vous pouvez être retardé de 1 à 5 minutes, en fonction de la vitesse de votre connexion Internet.
c. Suivez les instructions décrites sur la page web pour copier le package hors connexion (MSDT-
Portable.exe) sur l’ordinateur en cours de diagnostic.
Pour Windows Vista ou Windows Server 2008
a. Sélectionnez l’option Un autre ordinateur.
b. Dans l’écran Enregistrer les outils de diagnostic sur un média amovible, cliquez sur
Télécharger et enregistrer.
c. Indiquez où le package hors connexion (MSDT-Portable.exe) doit être enregistré.
2. Exécutez le fichier de package hors connexion (MSDT-Portable.exe) sur l’ordinateur de destination et
exécutez-le sur l’ordinateur de destination.
3. Attendez que l’exécution du package soit terminée. (Cette étape peut prendre plusieurs minutes.)
4. Une fois l’exécution du package de diagnostic terminé, cliquez sur Enregistrer les résultats, puis indiquez
un dossier dans lequel vous souhaitez enregistrer les résultats.
5. Notez que deux fichiers sont enregistrés. Un fichier est un fichier CAB qui contient les résultats de
diagnostic. L’autre fichier est un raccourci (.lnk). Déplacez les deux fichiers vers un ordinateur sur lequel
une connexion Internet est disponible.
6. Sur un ordinateur qui dispose d’une connexion Internet, double-cliquez sur le fichier de raccourci, puis
suivez les instructions pour renvoyer le fichier résultant au Support Microsoft.
Q4 : MSDT modifie -t-il ma configuration système ?
MSDT peut modifier la configuration de l’ordinateur. Par exemple, MSDT peut activer la journalisation liée au
débogage, puis vous obliger à reproduire le problème que vous rencontrez. Une partie de cette journalisation
peut être activée jusqu’à ce que le package de diagnostic télécharge les informations de dépannage au Support
Microsoft. MSDT peut également activer les diagnostics qui collectent des informations supplémentaires sur le
problème. En outre, MSDT peut installer des packages d’exécution qui peuvent exécuter certains packages de
diagnostic tels que Windows PowerShell ou microsoft .NET Framework. Toutes les configurations modifiées par
MSDT ne sont pas reconnexées à la fin de l’exécution du package. En particulier, pour les scénarios dans lesquels
un package d’Windows PowerShell est installé, il peut être conservé sur l’ordinateur.
Q5 : Quels composants et fichiers restent sur l’ordinateur une fois que MSDT a chargé des fichiers vers
Microsoft ?
Si vous exécutez Windows XP ou Windows Server 2003, une Msdcode.dll DLL reste sur l’ordinateur. Ce fichier
est un contrôle ActiveX qui est utilisé pour transférer en toute sécurité des fichiers et des utilitaires de diagnostic
de Microsoft et pour télécharger des informations vers Microsoft. Ce fichier est stocké dans le dossier
%windir%\Downloaded Program Files.
Tous les fichiers créés par MSDT lors de l’exécution du diagnostic lorsque MSDT s’exécute dans Windows XP ou
Windows Server 2003 sont stockés dans un dossier nommé %temp% odc pendant le processus de collecte de
données, mais qui est supprimé après l’envoi des résultats à ~ Microsoft. Ces fichiers sont également supprimés
si vous arrêtez la collecte de données ou sélectionnez l’option Non, n’envoyez pas les fichiers à l’option
Microsoft sur l’écran Envoyer des fichiers à Microsoft.
Si vous exécutez Windows Vista ou Windows Server 2008, tous les fichiers créés par MSDT lors de l’exécution
du package de diagnostic sont stockés dans un dossier nommé %temp%\MSDT_< GUID > (où l'> GUID
d’espace réservé < représente un dossier qui représente un GUID pour l’exécution) et supprimé après l’envoi des
résultats à Microsoft. Ces fichiers sont également supprimés si vous arrêtez la collecte de données ou
sélectionnez l’option Non, n’envoyez pas les fichiers à l’option Microsoft sur l’écran Envoyer des fichiers à
Microsoft.
En outre, comme décrit dans « Q4 : MSDT modifie-t-il ma configuration système ? » certains composants au
moment de l’Windows PowerShell et d’autres packages peuvent rester sur l’ordinateur. Certains packages de
diagnostic peuvent également activer le suivi ou des journaux spécifiques qui peuvent rester activés sur
l’ordinateur jusqu’à ce que les informations de dépannage soient téléchargées vers le Support Microsoft.
Q6 : MSDT modifiera-t-il la stratégie Windows PowerShell’exécution ?
Certains packages de diagnostic peuvent modifier temporairement Windows PowerShell stratégie d’exécution
de script sur RemoteSigned », puis revenir à la configuration d’origine après avoir collecté des informations. La
stratégie peut rester « RemoteSigned » si vous annulez l’exécution des diagnostics avant la fin de l’exécution du
package.
Q7 : MSDT s’exécute -t-il correctement sur une version localisée du Windows d’exploitation ?
MSDT s’exécute correctement sur les versions localisées de Windows. Toutefois, seules certaines descriptions de
contenu sont localisées. Par conséquent, certaines parties de l’interface utilisateur apparaissent en anglais.
Q8 : Comment démarrez-vous MSDT sur une installation server core de Windows Server 2008 ?
Une installation server core de Windows Server 2008 n’a pas de fonctionnalité de navigateur. Par conséquent,
vous devez démarrer MSDT manuellement. Tant que l’ordinateur Windows Server 2008 Server Core a accès à
Internet, vous pouvez suivre ces étapes pour exécuter MSDT et collecter des informations de diagnostic à partir
de l’ordinateur :
1. À l’invite de commandes, tapez Msdt.exe, puis appuyez sur Entrée.
2. Tapez votre touche de passe, puis cliquez sur OK.
NOTE
Pour obtenir la valeur de la clé de passage, ouvrez le lien URL dans un message électronique sur un système Windows
Vista ou Windows Server 2008 qui dispose d’un accès Internet, puis notez la valeur de la clé de passe à 10 chiffres.
Q9 : Quelles URL doivent être configurées sur un pare -feu ou un proxy pour qu’un package de diagnostic
s’exécute dans Windows XP, Windows Server 2003, Windows Vista ou Windows Server 2008 ?
Les URL suivantes sont accessibles lorsque vous exécutez un package de diagnostic :
Hello de DCUpload sur CO1 02
Hello à partir de DCodeWS sur CO1 02

Cette section décrit les problèmes les plus courants qui se produisent lorsque vous exécutez MSDT sur un
ordinateur exécutant Windows Server 2008, Windows Vista, Windows Server 2003 ou Windows XP.
Problème 1 : après avoir ouver t l’URL qui vous a été envoyée par un ingénieur pour
exécuter MSDT sur un ordinateur exécutant Windows 7 ou Windows Ser ver 2008 R2, le
package de diagnostic ne peut pas être exécuté. Votre seule option consiste à créer un
package hors connexion à l’aide du bouton « Créer un fichier ».
Ce problème se produit car l’URL qui vous a été envoyée exécute un package de diagnostic qui s’exécute
sur un ordinateur exécutant Windows XP, Windows Server 2003, Windows Vista ou Windows Server
2008. Si vous devez diagnostiquer un ordinateur Windows 7, demandez à l’ingénieur de vous envoyer
une clé d’accès pour exécuter MSDT sur un ordinateur Windows 7. Si vous souhaitez générer un package
hors connexion que vous pouvez exécuter sur Windows XP, Windows Server 2003, Windows Vista ou
Windows Server 2008, cliquez sur Créer un fichier pour générer le package hors connexion (MSDT-
Portable.exe), puis suivez les étapes 2 à 6 décrites dans « Q3 : Comment exécuter MSDT sur un ordinateur
sans connexion Internet ? »
Problème 2 : lorsque vous exécutez le package hors connexion (MSDT-Por table.exe) sur un
ordinateur exécutant Windows 7 ou Windows Ser ver 2008, vous recevez le message d’erreur
« Cette application n’est pas prise en charge sur ce système d’exploitation » et l’application
se quitte.
Ce problème se produit car le exécutable du package hors connexion (MSDT-Portable.exe) est
incompatible avec un ordinateur exécutant Windows 7 ou Windows Server 2008 R2. Si vous souhaitez
obtenir des données à partir d’un ordinateur Windows 7, vous devez demander à l’ingénieur de vous
envoyer une clé que vous pouvez utiliser sur un ordinateur Windows 7. Ensuite, vous pouvez générer un
package hors connexion compatible avec Windows 7.
Problème 3 : lorsque vous générez un package hors connexion dans Windows XP ou
Windows Ser ver 2003, un message vous demande de localiser le fichier MSDT-Por table.exe
dans un dossier nommé « [WinTempFolder]. » Toutefois, vous ne pouvez pas trouver le
fichier.
Ce problème se produit lorsque le contrôle ActiveX MSDT n’a pas été installé sur l’ordinateur. Pour
résoudre ce problème, assurez-vous qu’il est ajouté à la liste Sites de confiance et que vous laissez le
contrôle ActiveX être installé lorsque vous y êtes https://support.microsoft.com invité. Pour plus
d’informations, voir « Q3 : Comment exécuter MSDT sur un ordinateur sans connexion Internet ? »
Problème 4 : lorsque vous générez un package hors connexion dans Windows XP ou
Windows Ser ver 2003, Internet Explorer semble cesser de répondre.
Ce problème peut se produire lorsque la connexion Internet support.microsoft.com à est lente. Patientez
quelques minutes pour que le ActiveX termine le téléchargement du package et la génération de
l’exécutable. Si le problème persiste après plusieurs minutes, contactez votre ingénieur du support
technique.
Les informations sont collectées par le collecteur
SQL Server diagnostics de connectivité
Cet article décrit les informations collectées par le SQL Server Connectivity Diagnostics Collector.
Version du produit d’origine : SQL Server 2012, SQL Server 2008, SQL Server 2008 R2, SQL Server 2005
Résumé
Le collecteur de diagnostics de connectivité Microsoft SQL Server pour Windows Server 2003 R2, Windows
Vista, Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows 8, Windows 8.1, Windows Server
2012 et Windows Server 2012 R2 collecte des informations de diagnostic utiles pour résoudre une grande
classe de problèmes de connectivité avec SQL Server. Le SQL Server Connectivity Diagnostics Collector collecte
également des informations de diagnostic limitées pour SQL Server Analysis Services.
Le SQL Server Connectivity Diagnostics Collector prend en charge les versions suivantes de SQL Server :
SQL Server 2005
SQL Server 2008
SQL Server 2008 R2
SQL Server 2012
Logiciels prérequis
Il existe différentes conditions préalables pour exécuter des packages de diagnostic, en fonction du système
d’exploitation de l’ordinateur de destination. Le diagnostic vérifie automatiquement si ces conditions préalables
sont requises sur votre ordinateur et commence à s’exécuter s’ils sont déjà installés. Sinon, vous êtes invité à
installer les conditions préalables si elles ne sont pas déjà disponibles sur l’ordinateur. Le service de dépannage
automatisé de Microsoft (MATS) peut également installer les logiciels requis pour vous. Par exemple, si Windows
PowerShell n’est pas présent sur l’ordinateur de destination, MATS l’installe automatiquement. Pour plus
d’informations, consultez les informations sur les services de dépannage automatisés de Microsoft et la
plateforme de diagnostic du support technique.
Droits Windows requis

Le SQL Server connectivity Diagnostics Collector doit être exécuté par un utilisateur ayant des droits
d’administration sur l’ordinateur sur lequel le collecteur de diagnostics de connectivité SQL Server est exécuté.
SQL Server sécurité requise

Le SQL Server connectivity Diagnostics Collector découvre toutes les instances de SQL Server installées sur
l’ordinateur sur lequel l’outil de diagnostic est exécuté. Dans le cadre du processus de collecte de données, le
collecteur de diagnostics de connectivité SQL Server tente de se connecter à chaque instance de SQL Server que
l’outil de diagnostic découvre pour collecter des informations sur la configuration de SQL Server actuelle et l'«
état » du serveur. Les connexions de base de données sont réalisées à l’aide Windows’authentification unique.
Pour que les tâches de collecte de diagnostics suivantes réussissent, l’utilisateur qui exécute le collecteur de
diagnostics de connectivité SQL Server doit avoir une connexion Windows membre du rôle serveur fixe
sysadmin :
SQL Server Collection de configurations AlwaysOn
Scripts de collecte de données SQLDIAG
Prise en charge Windows clusters de failover

Pour diagnostiquer SQL Server connectivité de groupe de disponibilité AlwaysOn ou connectivité SQL Server en
cluster, vous de devez peut-être exécuter le collecteur de diagnostics de connectivité SQL Server sur plusieurs
nœuds de cluster pour collecter toutes les informations de dépannage nécessaires comme suit :
Exécutez le collecteur de diagnostics de connectivité SQL Server sur le nœud de cluster qui détient
actuellement le groupe de disponibilité AlwaysOn SQL Server ou la ressource de cluster SQL Server qui
rencontre le problème de connectivité.
Exécutez le SQL Server de diagnostic de connectivité sur le nœud où une défaillance de connectivité s’est
produite précédemment. Cela permet de collectionr différents journaux à partir du nœud de cluster où
l’échec s’est produit précédemment.
Informations collectées
Informations générales
DESC RIP T IO N N O M DE F IC H IER
Informations système de base. Cela inclut le nom de <COMPUTER_NAME>_ System_Information.txt

l’ordinateur, le numéro du Service Pack, le modèle
ordinateur, ainsi que le nom et la vitesse du processeur.
Informations de virtualisation, etc. <COMPUTER_NAME>_ DiscoveryReport.xml
Liste des rôles et des fonctionnalités installés sur le <COMPUTER_NAME>_ ResultReport.xml

support serveur. (Windows Server 2008 R2 et versions
ultérieures)
Journal système
NOTE
Le SQL Server connectivity Diagnostics Collector collecte les événements des 15 derniers jours.
Journal système aux formats TXT, CSV et EVT ou EVTX <COMPUTER_NAME>_ evt_System.csv
<COMPUTER_NAME>_ evt_System.txt
<COMPUTER_NAME>_ evt_System.evt ou
<COMPUTER_NAME>_ evt_System.evtx
Journal des applications

NOTE
Le SQL Server connectivity Diagnostics Collector collecte les événements des 15 derniers jours.
Journal des applications au format TXT, CSV et EVT ou <COMPUTER_NAME>_ evt_Application.csv

EVTX <COMPUTER_NAME>_ evt_Application.txt
<COMPUTER_NAME>_ evt_Application.evt ou
<COMPUTER_NAME>_ evt_Application.evtx
Informations sur les variables d’environnement utilisateur et système sur l’ordinateur de

destination
Informations sur les variables d’environnement <COMPUTER_NAME>_ EnvironmentVariables.xml

utilisateur et système dans le contexte de l’utilisateur <COMPUTER_NAME>_ EnvironmentVariables.txt
actuel sur l’ordinateur de destination au format XML et
TXT
Informations sur tous les ser vices installés sur l’ordinateur de destination
Informations sur les services installés sur l’ordinateur de <COMPUTER_NAME>_SC_Services_Output.xml

destination
Informations sur les pilotes de filtre installés sur l’ordinateur de destination
Éumer les pilotes de filtre supérieur et inférieur à l’aide de <COMPUTER_NAME>_FltrFind.txt

Fltrfind.exe
Rappor t des pilotes de mini-filtre
Éumer les pilotes de mini-filtre à l’aide de Fltmc.exe <COMPUTER_NAME>_Fltmc.txt
Informations sur tous les processus et détails du pilote en cours d’exécution, ainsi que leurs
versions de fichiers
Exécution de pilotes <COMPUTER_NAME>_sym_RunningDrivers.csv

Exécution de pilotes <COMPUTER_NAME>_sym_RunningDrivers.txt
%windir%\system32\drivers\*.* <COMPUTER_NAME>_sym_Drivers.csv
%windir%\system32\drivers\*.* <COMPUTER_NAME>_sym_Drivers.txt
Processus en cours d’exécution <COMPUTER_NAME>_sym_Process.csv
Processus en cours d’exécution <COMPUTER_NAME>_sym_Process.txt
Informations sur la configuration réseau de l’ordinateur de destination
Informations de configuration SMB de base, telles que la <COMPUTER_NAME>_SMB-Info.txt

sortie de sous-net.exe, telles que le partage net, les
sessions nettes, l’utilisation nette, les comptes net et la
configuration net.
Informations de configuration TCP/IP et réseau de base <COMPUTER_NAME>_TcpIp-Info.txt

telles que la clé de Registre TCP/IP et les sorties des
commandes ipconfig, netstat, nbtstat et netsh.
Fichier d’hôtes du client DNS <COMPUTER_NAME>_DnsClient_HostsFile.txt
Sortie de commande IPCONFIG/DISPLAYDNS <COMPUTER_NAME>_DnsClient_ipconfig-displaydns.txt
Sortie de commande NETSH DBNLIENT SHOW STATE <COMPUTER_NAME>_DnsClient_netsh_dnsclient-show-

REMARQUE Cette commande n’est pas valide Windows state.TXT
Server 2003
Entrées de Registre du client DNS <COMPUTER_NAME>DnsClient_reg.txt
Clé de Registre des paramètres TCP/IP <COMPUTER_NAME>_TcpIp_Parameters_Registry.xml

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Propriétés de la carte réseau <COMPUTER_NAME>_NetworkAdapterConfigurations.x

ml
Fichiers de sauvegarde du Registre et de vidage de texte de CurrentControlSet SQL Ser ver

ruches du Registre
HKLM\System\CurrentControlSet\SessionManagers <COMPUTER_NAME>_CurrentControlSet_Reg.txt
HKLM\SYSTEM\CurrentControlSet\Control\Lsa <COMPUTER_NAME>_CurrentControlSet_Reg.txt
HKLM\SYSTEM\CurrentControlSet <COMPUTER_NAME>_CurrentControlSet_Reg.hiv
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server <COMPUTER_NAME>_REG_SQL.txt
HKLM\SOFTWARE\Microsoft\MSSQLServer <COMPUTER_NAME>_REG_SQL.txt

2005 Redist
HKLM\Software\Microsoft\MSFTESQLInstMap <COMPUTER_NAME>_REG_SQL.txt
HKLM\SOFTWARE\Microsoft\Microsoft SQL Native <COMPUTER_NAME>_REG_SQL.txt

Client
HKLM\SOFTWARE\Microsoft\OLAP Server <COMPUTER_NAME>_REG_SQL.txt
HKLM\SOFTWARE\Microsoft\SNAC <COMPUTER_NAME>_REG_SQL.txt
HKLM\SOFTWARE\Microsoft\SQLXML4 <COMPUTER_NAME>_REG_SQL.txt
HKLM\Software\Microsoft\Vsa <COMPUTER_NAME>_REG_SQL.txt
HKLM\SOFTWARE\ODBC <COMPUTER_NAME>_REG_SQL.txt
HKLM\SOFTWARE\Microsoft\MSDTS <COMPUTER_NAME>_REG_SQL.txt
HKLM\SOFTWARE\Microsoft\MSXML 6.0 Parser and SDK <COMPUTER_NAME>_REG_SQL.txt
HKLM\SOFTWARE\Microsoft\MSXML60 <COMPUTER_NAME>_REG_SQL.txt
HKCU\Software\Microsoft\Microsoft SQL Server <COMPUTER_NAME>_REG_SQL.txt
HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft <COMPUTER_NAME>_Wow6432Node_REG_SQL.txt
SQL Server
HKLM\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer <COMPUTER_NAME>_Wow6432Node_REG_SQL.txt
SQL Server 2005 Redist
SQL Native Client
SQL Native Client 10.0
HKLM\SOFTWARE\Wow6432Node\Microsoft\SNAC <COMPUTER_NAME>_Wow6432Node_REG_SQL.txt
HKLM\SOFTWARE\Wow6432Node\Microsoft\SQLXML4 <COMPUTER_NAME>_Wow6432Node_REG_SQL.txt
HKLM\Software\Wow6432Node\Microsoft\Vsa <COMPUTER_NAME>_Wow6432Node_REG_SQL.txt
HKLM\SOFTWARE\Wow6432Node\ODBC <COMPUTER_NAME>_Wow6432Node_REG_SQL.txt
HKLM\SOFTWARE\Wow6432Node\Microsoft\MSDTS <COMPUTER_NAME>_Wow6432Node_REG_SQL.txt
Backup of HKLM\SOFTWARE\Microsoft\Microsoft SQL <COMPUTER_NAME>_Microsoft_SQL_Server.hiv

Server key in HIV format
Sor tie de l’utilitaire PSTAT
Sortie de PSTAT.EXE <COMPUTER_NAME>_PStat.txt
Windows de pare-feu
Sortie du netsh advfirewall afficher la commande avec <COMPUTER_NAME>_Firewall_netsh_advfirewall.txt

différentes options
Sortie de netsh advfirewall consec show rule name=all <COMPUTER_NAME>_Firewall_netsh_advfirewall-

consec-rules.txt
Sortie de l’exportation netsh advfirewall <COMPUTER_NAME>_Firewall_netsh_advfirewall-

export.wfw
Sortie du pare-feu netsh advfirewall afficher le nom de la <COMPUTER_NAME>_Firewall_netsh_advfirewall-

règle =all firewall-rules.txt
Sortie de netsh wfp show netevents <COMPUTER_NAME>_Firewall_netsh_wfp-show-

netevents.txt
HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall <COMPUTER_NAME>Firewall_reg.txt
HKLM\SYSTEM\CurrentControlSet\Services\BFE <COMPUTER_NAME>Firewall_reg.txt
HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT <COMPUTER_NAME>Firewall_reg.txt
HKLM\SYSTEM\CurrentControlSet\Services\MpsSvc <COMPUTER_NAME>Firewall_reg.txt
HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess <COMPUTER_NAME>Firewall_reg.txt
Informations sur les attributions de droits d’utilisateur sur l’ordinateur de destination
Attributions de droits d’utilisateur local <COMPUTER_NAME>_UserRights.txt

Informations sur le domaine auquel l’ordinateur de destination est joint
Informations sur le domaine auquel l’ordinateur de <COMPUTER_NAME>_DSMisc.txt

destination est joint.
Tickets Kerberos et TGT
Tickets Kerberos et TGT <COMPUTER_NAME>_ Kerberos_klist.txt
Clés de Registre Kerberos, LSA et SChannel sur l’ordinateur de destination
HKLM:\System\CurrentControlSet\Control\Lsa <COMPUTER_NAME>_ Authentication_Registry.xml

HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0
HKLM:\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
HKLM:\System\CurrentControlSet\Services\LanmanServer\Parameters
HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Configuration réseau de ser veur de toutes les instances de SQL Ser ver sur l’ordinateur de
destination
SQL Server configurations réseau (TCP/IP, NP, Mémoire <COMPUTER_NAME>_

partagée, etc.) pour toutes les instances de SQL Server. SqlServer_Network_Configurations.xml
En outre, (Moteur de base de données) instances sur
l’ordinateur de destination. Cela inclut les instances 64
bits et 32 bits sur un ordinateur 64 bits.
Propriétés Active Director y et SSN des comptes SQL Ser ver ser vice sur l’ordinateur de
destination
Propriétés Active Directory et SSN des comptes SQL <COMPUTER_NAME>_

Server service sur l’ordinateur de destination SqlServiceAccounts_SPN_ADProperties.xml
<COMPUTER_NAME>_ SQLInstances_Spn_Summary.xml
SQL Ser ver ’erreurs

Le SQL Server de diagnostics de connectivité collecte jusqu’à 20 journaux d’erreurs SQL Server pour
chaque instance découverte qui répond aux critères suivants :
La taille de chaque fichier journal d’erreurs doit être inférieure ou inférieure à 200 Mo.
La taille totale non compressée maximale de tous les fichiers journaux d’erreurs collectés ne peut pas
dépasser 250 Mo. Lorsque la limite de 250 Mo est atteinte, aucun journal d’erreur supplémentaire
n’est collecté pour l’instance de SQL Server.
Collecte les SQL Server des erreurs pour toutes les Instance nommée :
instances installées sur l’ordinateur sur lequel l’outil de <COMPUTER_NAME>_<INSTANCE_NAME>_1033_ERRO
diagnostic est exécuté. RLOG[.n]
Instance par défaut :

<COMPUTER_NAME>_MSSQLSERVER_ERRORLOG[.n]
NOTE
Lorsque le collecteur de diagnostics de connectivité SQL Server est exécuté sur un cluster de percevoir le cluster
de Windows, les journaux d’erreurs SQL Server sont collectés uniquement s’ils sont stockés sur un lecteur «
propriétaire » et « en ligne » vers le nœud du cluster de destination.
SQL Ser ver Journaux de l’agent

Le SQL Server connectivity Diagnostics Collector collecte jusqu’à 20 journaux de l’agent SQL Server pour
chaque instance découverte qui répond aux critères suivants :
La taille de chaque SQL Server journal de l’agent doit être inférieure ou inférieure à 200 Mo.
La taille totale non compressée maximale de tous les fichiers journaux de l’agent SQL Server collectés
ne peut pas dépasser 250 Mo. Lorsque la limite de 250 Mo est atteinte, aucun fichier journal SQL
Server agent supplémentaire n’est collecté pour l’instance de SQL Server.
Collecte les SQL Server de l’agent de diagnostic pour Instance nommée :

toutes les instances installées sur l’ordinateur sur lequel <COMPUTER_NAME>_<INSTANCE_NAME
l’outil de diagnostic est exécuté. >_1033_SQLAGENT. [OUT | n]

<COMPUTER_NAME>_MSSQLSERVER__1033_SQLAGEN
T. [OUT | n]
NOTE
Lorsque le collecteur de diagnostics de connectivité SQL Server est exécuté sur un cluster de percepteur de
percepteur de données de Windows, les journaux de l’agent SQL Server sont collectés uniquement s’ils sont
stockés sur un lecteur « propriétaire » et « en ligne » vers le nœud du cluster de destination.
SQL Ser ver fichiers minidump

Le SQL Server connectivity Diagnostics Collector collecte jusqu’à 10 SQL Server fichiers minidump pour
chaque instance de SQL Server. Les fichiers sont collectés dans l’ordre décroit, en fonction de la date de
création du fichier minidump. Cela signifie que les derniers fichiers générés sont collectés en premier. Les
fichiers collectés doivent répondre aux critères suivants :
La taille de chaque fichier minidump doit être inférieure ou inférieure à 100 mégaoctets (Mo).
Chaque fichier minidump doit avoir 30 jours ou moins.
La taille totale non compressée maximale de tous les fichiers minidump collectés pour une
instance donnée de SQL Server ne peut pas dépasser 200 Mo. Lorsque la limite de 200 Mo est
atteinte, aucun fichier minidump supplémentaire n’est collecté pour l’instance de SQL Server.
NOTE
Tous les fichiers d’une instance donnée sont compressés dans une archive zip avant d’être collectés.
SQL Server fichiers minidump Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_1033_SqlMi
niDumps.zip

<COMPUTER_NAME>_MSSQLSERVER_1033_SqlMiniDu
mps .zip
Un rapport d’inventaire de vidage est généré et collecté Instance nommée :

pour chaque instance de SQL Server. <COMPUTER_NAME>_<INSTANCE_NAME>_DumpInven
tory.log

<COMPUTER_NAME>_MSSQLSERVER_DumpInventory.l
og
NOTE
Lorsque le collecteur de diagnostics de connectivité SQL Server est exécuté sur un cluster de failover Windows, les
fichiers minidump SQL Server sont collectés uniquement s’ils sont stockés sur un lecteur « propriétaire » et « en
ligne » sur le nœud de cluster de destination.
Script de collecte de données SQLDIAG

Le script de collecte de données SQLDIAG est exécuté sur chaque instance de SQL Server dont l’état de
service est « RUNNING ». La sortie du script est redirigée vers un fichier et collectée par le diagnostic.
Sortie de script SQLDIAG Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_1033_sp_sq
ldiag_Shutdown.out

<COMPUTER_NAME>_MSSQLSERVER_1033_sp_sqldiag_
Shutdown.out
SQL Ser ver Informations de configuration AlwaysOn

NOTE
Les SQL Server de configuration AlwaysOn sont collectées uniquement à partir d’instances de SQL Server 2012.
SQL Server Informations de configuration AlwaysOn Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_1033_Alwa
ysOn.out

<COMPUTER_NAME>_MSSQLSERVER_1033_AlwaysOn.
out
SQL Ser ver Journaux d’état AlwaysOn

SQL Server Les journaux de session d’état AlwaysOn sont collectés à partir de chaque instance de SQL
Server 2012 installée sur l’ordinateur de destination. Les fichiers sont collectés et compressés dans des
archives compressées « spécifiques à l’instance ».
Le nombre maximal d SQL Server journaux d’état AlwaysOn qui seront collectés pour chaque instance
découverte est de 20. Les fichiers sont collectés dans l’ordre décroit, en fonction de la date de création du
fichier.
SQL Server Journaux d’état AlwaysOn Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_AlwaysOn_
health_XeLogs.zip

<COMPUTER_NAME>_MSSQLSERVER_AlwaysOn_health
_XeLogs.zip
NOTE
diagnostics de connectivité Windows, les journaux d’état AlwaysOn SQL Server sont collectés uniquement s’ils
sont stockés sur un lecteur « propriétaire » et « en ligne » vers le nœud du cluster de destination.
SQL Ser ver journaux d’état du cluster de failover

SQL Server journaux d’état du cluster de failover sont collectés à partir de chaque instance « en cluster »
de SQL Server 2012 installée sur l’ordinateur de destination. Les fichiers sont collectés et compressés
dans des archives compressées « spécifiques à l’instance ».
Le nombre maximal de journaux d’état du cluster de percevoir pour chaque instance est de 20. Les
fichiers sont collectés dans l’ordre décroit, en fonction de la date de création du fichier.

SQL Server journaux d’état du cluster de failover Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_FailoverClus
ter_health_XeLogs.zip

<COMPUTER_NAME>_MSSQLSERVER_FailoverCluster_h
ealth_XeLogs.zip
NOTE
Les SQL Server d’état du cluster de percevoir sont collectés uniquement s’ils sont stockés sur un lecteur «
propriétaire » et « en ligne » sur le nœud du cluster de destination.
SQL Ser ver d’état du système par défaut

SQL Server journaux d’état du système par défaut sont collectés à partir de chaque instance de SQL
archives compressées « spécifiques à l’instance ».
SQL Server d’état du système par défaut Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_system_hea
lth_XeLogs.zip

<COMPUTER_NAME>_MSSQLSERVER_system_health_Xe
Logs.zip
NOTE
percepteur de Windows, les journaux d’état du système par défaut SQL Server sont collectés uniquement s’ils sont
stockés sur un lecteur « propriétaire » et « en ligne » sur le nœud du cluster de destination.
S’applique à
SQL Server 2012 Parallel Data Warehouse
SQL Server Web 2012
SQL Server Web 2008
Déterminer le niveau de version, d’édition et de
mise à jour SQL Server et ses composants
Cet article répertorie les différentes builds ou mises à jour disponibles pour différentes versions de SQL Server
et décrit les procédures pour déterminer la version de SQL Server qui s’exécute sur un système donné.
Résumé
Une version téléchargeable d’un Excel qui contient toutes les versions de build ainsi que leur phase de
cycle de vie de support actuelle pour la version actuelle de 2005 à 2005 est disponible. Cliquez pour
télécharger ce fichier Excel maintenant. (Nom de fichier : SQL Server builds V3.xlsx)
Pour savoir à quoi un numéro de version spécifique de SQL Server est mapré ou pour trouver les
informations de l’article de la Base de données de la base de données pour un package de mise à jour
cumulative spécifique ou un Service Pack, recherchez le numéro de version dans les tableaux de la liste
version complète SQL Server.
Pour trouver l’édition de votre instance SQL Server, vous pouvez utiliser l’une des procédures de la
méthode 2 à la méthode 5 de la section Déterminer la version et l’édition de SQL Server Moteur de base
de données en cours d’exécution.
NOTE
Les informations de version et d’édition sont dans la même chaîne de sortie.
NOTE
Pour plus d’informations SQL Server le cycle de vie du support technique, consultez la page Microsoft SQL Server
le cycle de vie du support technique.
Dernières mises à jour disponibles pour les versions actuellement SQL

Server
Chacun des liens suivants fournit des informations sur tous les produits et technologies applicables.
DERN IÈRE M ISE IN F O RM AT IO N S

DERN IER À JO UR C O M P L ÈT ES SUR IN ST RUC T IO N S
VERSIO N SERVIC E PA C K DERN IÈRE GDR C UM UL AT IVE L A VERSIO N GÉN ÉRA L ES
SQL Server 2019 Néant GDR CU12 pour 2019 SQL Server SQL Server 2019
(15.0.2080.9 - (15.0.4153.1 - builds 2019
Janvier 2021) Août 2021)
CU8 + GDR
(15.0.4083.2 -
Janvier 2021)
SQL Server 2017 Néant GDR CU25 SQL Server SQL Server 2017
(14.0.2037.2 - (14.0.3401.7 - builds 2017
Janvier 2021) Juillet 2021)
CU22 + GDR
(14.0.3370.1 -
Janvier 2021)
SQL Server 2016 SP2 (13.0.5026.0 GDR pour SP2 CU17 pour 2016 SQL Server 2016 SQL Server 2016
- Avril 2018) (13.0.5103.6 - SP2
SP1 (13.0.4001.0 Janvier 2021) (13.0.5888.11 -
- Novembre GDR pour SP1 Mars 2021)
2016) (13.0.4259.0 - CU15 + GDR
Juillet 2019) pour SP2
GDR pour rtm (13.0.5865.1 -
(13.0.1745.2 - Janvier 2021)
Janvier 2018) CU15 + GDR
pour SP1
(13.0.4604.0 -
Juillet 2019)
CU15 pour SP1
(13.0.4574.0 -
mai 2019)
CU14 pour SP2
(13.0.5830.85-
Août 2020)
CU9 pour RTM
(13.0.2216.0 -
Novembre 2017)
SQL Server 2014 SP3 (12.0.6024.0 GDR pour SP3 CU4 + GDR SQL Server 2014 SQL Server 2014
- Octobre 2018) (12.0.6164.21 - pour SP3
SP2 (12.0.5000.0 Janvier 2021) (12.0.6433.1 -
- Juillet 2016) GDR pour SP2 Janvier 2021)
SP1 (12.0.4100.1 (12.0.5223.6 - CU4 pour SP3
- Mai 2015) Janvier 2019) (12.0.6329.1 -
GDR pour SP1 Juillet 2019)
(août 2017) CU18 pour SP2
MS 15-058 (12.0.5687.1 -
(juillet 2015) Juillet 2019)
CU13 pour SP1
(12.0.4522.0 -
Août 2017)
SQL Server 2012 SP4 (11.0.7001.0 GDR pour SP4 CU10 pour SP3 SQL Server 2012 SQL Server 2012
- Septembre (11.0.7507.2 - (11.0.6607.3 -
2017) Janvier 2021) Août 2017)
SP3 (11.0.6020.0 GDR pour SP3 CU16 pour SP2
- Novembre (janvier 2018) (11.0.5678.0 -
2015) MS 16-136 Janvier 2017)
SP2 (11.0.5058.0 (novembre CU16 pour SP1
- Juin 2014) 2016) (11.0.3487.0 -
SP1 MS 15-058 mai 2015)
(11.0.3000.00 - (décembre 2015)
Novembre 2012
SQL Server 2008 SP3 GDR pour SP3 Néant SQL Server SQL Server 2008
R2 (10.50.6000.34 - (janvier 2018) builds 2008 R2 R2 SP3
Septembre MS 15-058 Installation
2014) (juillet 2015)
SP2
(10.50.4000.0 -
Juillet 2012)
SQL Server 2008 SP4 GDR pour SP4 Néant SQL Server SQL Server
(10.0.6000.29 - (janvier 2018) builds 2008 maintenance
Septembre MS 15-058 2008
2014) (juillet 2015)
SP3
(10.00.5500.00 -
Octobre 2011)
NOTE
« Latest » = During the past 12 months
Déterminer la version et l’édition de SQL Server Moteur de base de

données en cours d’exécution
Pour déterminer la version de SQL Server, vous pouvez utiliser l’une des méthodes suivantes.
Méthode 1 : Connecter sur le serveur à l’aide de l’Explorateur d’objets SQL Server Management Studio.
Une fois connecté, l’Explorateur d’objets affiche les informations de version entre parenthèses, ainsi que
le nom d’utilisateur utilisé pour se connecter à l’instance spécifique de SQL Server.
Méthode 2 : Regardez les premières lignes du fichier Errorlog pour cette instance. Par défaut, le journal
des erreurs se trouve à l’emplacement des fichiers
Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\ERRORLOG ERRORLOG.n. Les entrées peuvent
ressembler à ce qui suit :
2011-03-27 22:31:33.50 Server Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64)
March 29 2009 10:11:52
Copyright (c) 1988-2008 Microsoft Corporation
Express Edition (64-bit)
on Windows NT 6.1 <X64> (Build 7600: )
Cette entrée fournit toutes les informations nécessaires sur le produit, telles que la version, le niveau de
produit, la version 64 bits ou 32 bits, l’édition de SQL Server et la version du système d’exploitation sur
laquelle SQL Server est en cours d’exécution.
NOTE
La sortie de cette requête a été améliorée pour afficher des informations supplémentaires, comme décrit dans
l’article de billet de blog, quelle version de SQL Server utilisez-vous ?, pour les versions suivantes :
SQL Server 2014 RTM CU10 et versions ultérieures
SQL Server 2014 Service Pack 1 CU3 et versions ultérieures
Méthode 3 : Connecter à l’instance de SQL Server, puis exécutez la requête suivante :
Select @@version
Voici un exemple de sortie de cette requête :
Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64)

March 29 2009 10:11:52
Copyright (c) 1988-2008 Microsoft Corporation Express Edition (64-bit)
on Windows NT 6.1 <X64> (Build 7600: )
NOTE
La sortie de cette requête a été améliorée pour afficher des informations supplémentaires. Cela est documenté
dans l’article de billet de blog, quelle version de SQL Server utilisez-vous ?, pour les versions suivantes :
SQL Server 2014 RTM CU10 et versions ultérieures
Méthode 4 : Connecter à l’instance de SQL Server, puis exécutez la requête suivante dans SQL Server
Management Studio (SSMS) :
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
NOTE
Cette requête fonctionne pour toute instance de SQL Server 2000 ou une version ultérieure.
Les résultats suivants sont renvoyés :

Version du produit (par exemple, 10.0.1600.22)
Le niveau de produit (par exemple, RTM)
L’édition (par exemple, Enterprise)
Par exemple, les résultats ressemblent à ce qui suit.
14. 0. 2027. 2 RT M DEVELO P ER EDIT IO N ( 64 B IT S)
NOTE
La fonction SERVERPROPERTY renvoie des propriétés individuelles liées aux informations de version, bien
que la fonction @ combine la sortie @VERSION en une seule chaîne. Si votre application nécessite des
chaînes de propriétés individuelles, vous pouvez utiliser la fonction SERVERPROPERTY pour les renvoyer au
lieu d’avoir à les utiliser comme résultats @ @VERSION .
Cette méthode fonctionne également pour les instances SQL Azure base de données. Pour plus
d’informations, voir la rubrique suivante dans SQL Server Books Online SERVERPROPERTY (Transact-SQL).
Depuis SQL Server 2014 RTM Cumulative Update 10 et SQL Server 2014 Service Pack 1 Cumulative
Update 3, des propriétés supplémentaires ont été ajoutées à l’instruction ServerProperty. Pour une liste
complète de révision SERVERPROPERTY (Transact-SQL).
Méthode 5 : À compter SQL Server 2008, vous pouvez également utiliser le rapport de découverte des
fonctionnalités SQL Server installées. Vous pouvez trouver ce rapport en localisant la page Outils du
centre d SQL Server d’installation. Cet outil fournit des informations sur toutes les instances de SQL
Server qui sont installées sur le système. Il s’agit notamment des outils clients tels que SQL Server
Management Studio. La seule chose à savoir est que cet outil peut être exécuté localement uniquement
sur le système sur lequel SQL serveur est installé. Elle ne peut pas être utilisée pour obtenir des
informations sur les serveurs distants. Pour plus d’informations, voir Valider SQL Server installation.
Voici un instantané d’un exemple de rapport :
Déterminer la version des outils SQL Server client

SQL Ser ver Management Studio (SSMS)
Pour déterminer les versions des outils clients installées sur votre système, démarrez Management
Studio, puis cliquez sur À propos du menu d’aide. (Voir la capture d’écran suivante.)
À partir SQL Server 2016, SQL Server Management Studio est proposé en téléchargement séparé. Pour
plus d’informations sur les différentes versions de l’outil, examinez les notes de publication SQL Server
Management Studio (SSMS).
SQL Server Data Tools
Pour plus d’informations SQL Server Data Tools, voir Télécharger SQL Server Data Tools (SSDT) pour
Visual Studio.
SQL Server Reporting Services

La version de SQL Server Reporting Services (SSRS) s’affiche sur l’URL du service Web Reporting Services, par
exemple http://servername/reportserver : La version est également affichée dans l’outil de configuration de
Reporting Services.
SQL Server Integration Services

La version de SQL Server Integration Services s’aligne sur la version du serveur SQL que vous avez installé.
SQL Server Analysis Services

Pour déterminer la version de SQL Server Analysis Services, utilisez l’une des méthodes suivantes :
Méthode 1 : Connecter sur le serveur à l’aide de l’Explorateur d’objets SQL Server Management Studio.
Une fois connecté, l’Explorateur d’objets affiche les informations de version entre parenthèses, ainsi que
le nom d’utilisateur utilisé pour se connecter à l’instance spécifique d’Analysis Services.
Méthode 2 : Vérifiez la version du fichier Msmdsrv.exe dans le dossier Bin Analysis Services. Les
emplacements par défaut sont indiqués dans le tableau suivant.
VERSIO N D’A N A LY SIS SERVIC ES LO C AT IO N


Server\MSAS15.InstanceName\OLAP\Bin\MSMDSrv.exe




Méthode 3 : Utilisez les sous-clés de Registre répertoriées dans le tableau suivant.
2019 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL

Server\MSAS15.InstanceName\MSSQLServer\CurrentVersion
Key: CurrentVersion
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SQL Server\MSAS15.InstanceName \Setup Keys:
PatchLevel , Version, Key Edition

Key: CurrentVersion

Key: CurrentVersion

Key: CurrentVersion
SQL Server\MSAS12.InstanceName
\MSSQLServer\CurrentVersion Key: CurrentVersion

Key: CurrentVersion
Pour plus d’informations sur la vérification des versions de build Analysis Services, vérifiez la version de
build de mise à jour cumulative Analysis Services.
SQL Server réplication
Étant donné que les agents de réplication peuvent être installés sur plusieurs ordinateurs différents, il est
important de vérifier les versions installées sur tous les ordinateurs concernés.
Par exemple, l’agent de distribution dans la réplication transactionnelle ou pair à pair peut exister sur des
ordinateurs qui diffèrent de l’instance d’éditeur de SQL Server et qui peuvent exister sur les différentes
instances d’abonné de SQL Server dans un abonnement pull.
Si vous utilisez la synchronisation Web pour la réplication de fusion, il se peut que le serveur web IIS ne soit pas
le même ordinateur que l’ordinateur qui exécute SQL Server. Par conséquent, vous avez des fichiers d’agent de
réplication qui sont installés sur le serveur web IIS. De plus, vous de devez vérifier la version de ces fichiers .dll
dans le répertoire virtuel IIS et les mettre à jour de manière explicite pour obtenir les derniers Service Packs,
mises à jour cumulatives et correctifs logiciels pour vos agents web.
Pour plus d’informations, voir Mise à niveau ou correction des bases de données répliquées.
Recherche de texte intégral

Les composants de recherche en texte intégral sont les suivants :
Sqlserver.exe
Sql_fulltext_keyfile.dll
Iftsph.dll
Fd.dll
Fdhost.exe
Fdlauncher.exe
À l'Sqlservr.exe, ces composants peuvent ne pas être mis à jour avec chaque mise à jour cumulative ou Service
Pack pour le produit SQL Server respectif. Les versions de ces fichiers ne changent que s’il existe un correctif
pour le composant respectif. En règle générale, vous pouvez vérifier la version de chacun de ces fichiers .dll
fichiers. La version la plus élevée de la liste est la version du composant de recherche en texte intégral installé
sur le système.
Vous pouvez utiliser l’une des méthodes suivantes pour déterminer la version du composant de recherche en
texte intégral installé sur votre système.
NOTE
Chacune de ces méthodes peut indiquer que la version du composant de recherche en texte intégral est rtm ou une
version antérieure à la version actuelle du composant de base de données. Nous reconnaissez qu’il s’agit d’un problème et
nous travaillons à sa résolution dans une prochaine mise à jour.
Méthode 1 : Vérifiez la version de SQL Server Full-Text (Sql_fulltext_keyfile.dll) dans le dossier

d’installation SQL Server 2008 R2 ou SQL Server 2008. En règle générale, SQL Server 2008 R2, ce fichier
se trouve dans le dossier suivant :
%ProgramFiles%\Microsoft SQL Server\MSQL10_50.\<Instance Name>\MSSQL
Pour SQL Server 2008, ce fichier se trouve généralement dans le dossier suivant :
%ProgramFiles%\Microsoft SQL Server\MSQL10.\<Instance Name>\MSSQL
Méthode 2 : Vérifiez la sous-clé de Registre suivante :

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft sql server\Mssql10_50.instname\Setup\SQL_FULLTEXT_ADV
Voici un exemple d’entrée dans cette sous-clé de Registre :
featurelist: SQL_FullText_Adv=3 SQL_FullText_CNI=3

ProductCode: {9DFA5914-C275-42E0-810E-C88E46A7F9EA}
Patchlevel: 10.50.1765.0
Version: 10.50.1600.1
Dans cet exemple d’entrée, la troisième ligne (Patchlevel) indique la version actuelle du composant de
recherche en texte intégral qui est installé, et la quatrième ligne (Version) affiche généralement la version
d’origine de la recherche en texte intégral qui est installée. Dans ce cas, il s’agit SQL Server 2008 R2.
Méthode 3 : Utilisez le fichierSummary.txt créé lors de l’installation. Pour SQL Server 2008 R2 et
versions ultérieures, ce fichier se trouve dans le dossier suivant :
%ProgramFiles%\Microsoft SQL Server\<nnn>\Setup Bootstrap\LOG\Summary.txt
Pour les valeurs qui correspondent à votre version examiner les emplacements de fichiers pour les
instances par défaut et <nnn> nommées de SQL Server.
Pour SQL Server 2008, ce fichier se trouve dans le dossier suivant :
%ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\LOG\Summary.txt
SQL Server Master Data Services (MDS)

Le MDS Configuration Manager n’affiche pas directement le numéro de version actuellement installé.
Sachez que MDS a un scénario de gestion des versions unique dans lequel l’installation du moteur de base de
données SQL Server ne correspond pas nécessairement à la version MDS version. La version peut varier lorsque
vous comparez l’installation SQL Server aux binaires déployés sur le site web MDS et à la version de schéma
MDS catalogue. Les étapes manuelles qui utilisent l MDS Configuration Manager sont nécessaires pour mettre à
jour et mettre à niveau les MDS web et les schémas de base de données. Vous pouvez consulter le billet de blog
suivant sur les correctifs logiciels et la méthodologie de mise à jour du Service Pack pour MDS : Téléchargement
et installation des mises à jour cumulatives de SQL Server 2008 R2 Master Data Services (MDS)
La sous-clé de Registre suivante indique les versions binaires installées sur le SQL Server. Toutefois, cette version
ne correspond pas nécessairement à la version du site web et du schéma de base de données tant que le
processus MDS de mise à niveau est terminé.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Master Data Services 10.5\CurrentVersion
Vous pouvez vérifier la version du produit et la version de schéma installées à l’aide de la requête suivante dans
MDS catalogue :
select * from mds.mdm.tblSystem
SQL Server Native Client

NOTE
La version SQL Server de la dernière version SQL Server Native Client est SQL Server 2012. Il est compatible avec SQL
Server 2014 et SQL Server 2016. Pour plus d’informations, examinez l’installation SQL Server Native Client.
Pour déterminer la version de SQL Server Native Client, utilisez l’une des méthodes suivantes :
Méthode 1 : Sur le système où vous souhaitez trouver la version de Client natif, démarrez
l’administrateur ODBC (odbcad32.exe), puis vérifiez la colonne Version sous l’onglet Pilotes.
Méthode 2 : Vérifiez les clés PatchLevel ou Version suivantes aux emplacements de Registre suivants.
SQ L VERSIO N /
SQ L SERVER N AT IVE C L IEN T VERSIO N SO US- C L ÉS DE REGIST RE
SQL Server 2012, SQL Server 2014 et SQL Server 2016/ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SQL Server Native Client 11.0 SQL Server\SQLNCLI11\CurrentVersion
SQL Server 2008 & SQL Server 2008 R2/ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft

SQL Server Native Client 10 SQL Server\SQLNCLI10\CurrentVersion
SQL Server 2005/ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft

SQL Server Native Client 9 SQL Native Client\CurrentVersion
SQL Server Navigateur

La version du navigateur doit correspondre à la version la plus élevée du SQL Server Moteur de base de
données et des instances d’Analysis Services installées sur l’ordinateur.
SQL Server Rédacteur

Pour déterminer la version de SQL Server Writer, vérifiez la valeur de sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\SqlWriter\CurrentVersion Keys: PatchLevel or
Version
Microsoft .NET Framework

Pour déterminer la version de .NET Framework sur votre système, voir Déterminer les versions et les niveaux de
Service Pack de .NET Framework sont installés.
Pour plus d’informations, voir Understanding the .NET Framework requirements for various versions of SQL
Server.
SQL Azure
Pour trouver la version de votre instance de SQL Azure et les informations connexes, consultez la rubrique
suivante dans Books Online : SERVERPROPERTY (Transact-SQL).
SQL Server CE
Pour trouver la version de votre instance de SQL Server CE et les informations connexes, voir SQL Server
documentation sur les versions précédentesde CE.
PolyBase
PolyBase pour SQL Server sur Windows
Pour trouver la version de PolyBase et ses fonctionnalités associées dans Windows, essayez les méthodes
suivantes :
Si le service PolyBase est en cours d’exécution, exécutez le script PowerShell suivant :
Get-Process mpdwsvc -FileVersionInfo | Format-Table -AutoSize
Si le service PolyBase n’est pas en cours d’exécution ou ne peut pas être démarré, exécutez le script
PowerShell suivant :
cd 'C:\Program Files\Microsoft SQL Server'

ls mpdwsvc.exe -r -ea silentlycontinue | % versioninfo | Format-Table -AutoSize
PolyBase pour SQL Server sur Linux

Pour trouver la version de PolyBase installée et ses fonctionnalités connexes dans Ubuntu, essayez les méthodes
suivantes :
apt list mssql-server-polybase

apt list mssql-server-polybase-hadoop
Pour trouver la version de PolyBase installée et ses fonctionnalités connexes dans RHEL, essayez les méthodes
suivantes :
yum info mssql-server-polybase

yum info mssql-server-polybase-hadoop
yum list installed *polybase*
Windows ou Linux
Vous pouvez également essayer les étapes SQL Server du programme d’installation dans cette section suivante.
Pour trouver la version de PolyBase et ses fonctionnalités connexes, reportez-vous à un nouveau rapport de
découverte qui s’exécute dans SQL Server outils d’installation.
Dans Windows ou Linux, recherchez le dossier d’installation \Setup Bootstrap\Log. Le Summary.txt affiche un
rapport de découverte de toutes les fonctionnalités et versions. Toutefois, si l’action de configuration la plus
récente a été d’ajouter PolyBase à une instance SQL Server existante, le fichier Summary.txt ne contient pas la
fonctionnalité PolyBase. Cela est dû au fait que le rapport de découverte s’est exécuté avant l’ajout de la
fonctionnalité PolyBase.
Nous vous recommandons d’actualiser le rapport Summary.txt en exécutant le rapport de découverte des
fonctionnalités à partir SQL Server le programme d’installation. Pour plus d’informations, voir Valider SQL
Server installation.
Machine Learning services

Pour Windows serveurs, reportez-vous aux versions du fichier CAB qui changent avec SQL Server mises à jour
cumulatives. Reportez-vous aux Rlauncher.config ou PythonLauncher.config dans le répertoire pour rechercher
les emplacements des dossiers RHOME ou PYTHONHOME des fichiers
Program Files\Microsoft SQL Server\MSSQL.nn\MSSQL\Binn CAB. Pour les versions CAB incluses dans SQL Server
versions cu, voir téléchargements CAB pour l’installation hors connexion des mises à jour cumulatives pour SQL
Server Machine Learning Services.
Pour les serveurs Linux, la commande suivante renvoie la liste de tous les packages installés spécifiques à mssql,
ainsi que leurs numéros de version :
apt-get list --installed | --grep mssql
Le numéro de version de la version du package d’extensibilité mssql-server est la version SQL Server de la
fonctionnalité Machine Learning Services.
Le numéro de version du fichier mssql-mlservices-packages-r ou mssql-mlservices-packages-py fait référence à
chaque fichier de package de langue. Pour plus d’informations, voir Install SQL Server Machine Learning
Services on Linux (Offline installation).
Foire aux questions

Q1 : Comment déterminez-vous la version de SQL Ser ver lorsque SQL Ser ver ’est pas en cours
d’exécution ?
A1 : Vous pouvez déterminer la version de SQL Server à l’aide de la méthode 2 ou de la méthode 5 (pour SQL
Server 2008 et versions ultérieures) dans la section Déterminer la version et l’édition de SQL Server Moteur de
base de donnéesen cours d’exécution] de cet article.
Q2 : Comment ma map montre-t-il les versions des produits sur les noms des produits ?
A2 : Vous pouvez utiliser le tableau suivant comme référence.
M O DÈL E DE VERSIO N SQ L P RO DUIT
15.0.x.x SQL Server 2019
10.50.x.x SQL Server 2008 R2
Termes et acronymes fréquemment utilisés

Mise à jour cumulative (CU) : Mise à jour de correctifs qui contient tous les correctifs logiciels à la demande
critiques précédents à ce jour. En outre, elle contient des correctifs pour les problèmes qui répondent aux critères
d'acceptation des correctifs logiciels. Ces critères peuvent inclure la disponibilité d’une solution de
contournement, l’impact sur le client, la reproductibilité du problème, la complexité du code qui doit être
modifié et d’autres rubriques.
Correctif : Package unique et cumulatif qui inclut un ou plusieurs fichiers utilisés pour résoudre un problème
dans un produit et qui sont cumulatifs au niveau binaire et fichier. Un correctif répond à une situation client
spécifique et peut ne pas être distribué en dehors de l’organisation du client.
RTM : En règle générale, cela signifie « release to manufacturing ». Dans le contexte d’un produit tel que SQL
Server, il indique qu’aucun Service Pack ou correctif n’a été appliqué au produit.
RTW : En règle générale, cela signifie « release to web ». Il indique un package qui a été publié sur le web et mis
à la disposition des clients pour téléchargement.
Ser vice Pack : Ensemble cumulatif testé de tous les correctifs logiciels, mises à jour de sécurité, mises à jour
critiques et mises à jour. Les Service Packs peuvent également contenir des correctifs supplémentaires pour les
problèmes qui se trouvent en interne depuis la publication du produit et un nombre limité de modifications ou
de fonctionnalités de conception demandées par le client.
Pour plus d’informations, voir les sites web suivants :
Annonce du modèle de maintenance moderne pour SQL Server
Description du schéma d’attribution de noms et de la zone de correction pour SQL Server packages de
mise à jour logicielle
Description de la terminologie standard utilisée pour décrire les mises à jour logicielles Microsoft
Description de la terminologie standard utilisée pour décrire les mises à jour logicielles Microsoft
Un modèle de maintenance incrémentielle est disponible auprès de l’équipe SQL Server pour fournir des
correctifs pour les problèmes signalés
Cycle de vie des logiciels publiés
SQL Server documentation
SQL Server’informations sur le produit
SQL Server blogs de publication
SQL Server de liste de versions complètes

NOTE
Ces tableaux utilisent le format suivant et sont ordonnés par numéro de build.
SQL Server 2019

N UM ÉRO DE B UIL D
O U VERSIO N SERVIC E PA C K UP DAT E A RT IC L E DE L A K B DAT E DE SO RT IE
15.0.4153.1 Néant CU12 5004524 Août 04 2021
15.0.4138.2 Néant CU11 5003249 10 juin 2021
15.0.4123.1 Néant CU10 5001090 06 avril 2021
15.0.4102.2 Néant CU9 5000642 11 février 2021
15.0.4083.2 Néant CU8 + GDR 4583459 12 Janvier 2021
15.0.4073.23 Néant CU8 4577194 30 septembre 2020

15.0.4053.23 Néant CU6 4563110 04 août 2020
15.0.4043.16 Néant CU5 4552255 22 juin 2020
15.0.4033.1 Néant CU4 4548597 31 mars 2020
15.0.4023.6 Néant CU3 4538853 12 mars 2020
15.0.4013.40 Néant CU2 4536075 13 février 2020
15.0.4003.23 Néant CU1 4527376 07 janvier 2020
15.0.2070.41 Néant GDR1 4517790 4 novembre 2019
15.0.2000.5 Néant RTM N/A 04 novembre 2019
SQL Server 2017

14.0.3401.7 Néant CU25 5003830 12 juillet 2021
14.0.3391.2 Néant CU24 5001228 10 mai 2021
14.0.3381.3 Néant CU23 5000685 24 février 2021
14.0.3370.1 Néant CU22 + GDR 4583457 12 janvier 2021
14.0.3335.7 Néant CU21 4557397 01 juillet 2020
14.0.3294.2 Néant CU20 4541283 07 avril 2020
14.0.3281.6 Néant CU19 4535007 05 février 2020
14.0.3257.3 Néant CU18 4527377 09 décembre 2019
14.0.3238.1 Néant CU17 4515579 08 octobre 2019
14.0.3223.3 Néant CU16 4508218 01 août 2019
14.0.3192.2 Néant CU15 + GDR 4505225 9 juillet 2019
14.0.3162.1 Néant CU15 4498951 23 mai 2019
14.0.3103.1 Néant CU14 + GDR 4494352 14 mai 2019

14.0.3076.1 Néant CU14 4484710 25 mars 2019
14.0.3048.4 Néant CU13 4466404 18 décembre 2018
14.0.3045.24 Néant CU12 4464082 24 octobre 2018
14.0.3037.1 Néant CU10 4342123 27 août 2018
14.0.3035.2 Néant CU9 + GDR 4293805 14 août 2018
14.0.3030.27 Néant CU9 4341265 18 juillet 2018
14.0.3029.16 Néant CU8 4338363 21 juin 2018
14.0.3026.27 Néant CU7 4229789 23 mai 2018
14.0.3025.34 Néant CU6 4101464 17 avril 2018
14.0.3023.8 Néant CU5 4092643 20 mars 2018
14.0.3022.28 Néant CU4 4056498 20 février 2018
14.0.3015.40 Néant CU3 4052987 04 janvier 2018
14.0.3008.27 Néant CU2 4052574 28 novembre 2017
14.0.3006.16 Néant CU1 4038634 24 octobre 2017
SQL Server 2016

13.0.5888.11 SP2 CU17 5001092 29 mars 2021
13.0.5882.1 SP2 CU16 5000645 11 février 2021
13.0.5865.1 SP2 CU15 + GDR 4583461 12 Janvier 2021
13.0.5850.14 SP2 CU15 4577775 28 septembre 2020
13.0.5830.85 SP2 CU14 4564903 06 août 2020
13.0.5820.21 SP2 CU13 4549825 28 mai 2020
13.0.5698.0 SP2 CU12 4536648 24 février 2020

13.0.5598.27 SP2 CU11 4527378 09 décembre 2019
13.0.5492.2 SP2 CU10 4524334 08 octobre 2019
13.0.5426.0 SP2 CU8 4505830 31 juillet 2019
13.0.5366.0 SP2 CU7 + GDR 4505222 9 juillet 2019
13.0.5337.0 SP2 CU7 4495256 22 mai 2019
13.0.5292.0 SP2 CU6 4488536 19 mars 2019
13.0.5264.1 SP2 CU5 4475776 23 janvier 2019
13.0.5233.0 SP2 CU4 4464106 13 novembre 2018
13.0.5216.0 SP2 CU3 4458871 20 septembre 2018
13.0.5201.2 SP2 CU2 + Mise à jour de 4458621 21 août 2018

sécurité
13.0.5153.0 SP2 CU2 4340355 16 juillet 2018
13.0.5149.0 SP2 CU1 4135048 30 mai 2018
13.0.5026.0 SP2 RTW/PCU2 4052908 24 avril 2018
13.0.4604.0 SP1 CU15 + GDR 4505221 9 juillet 2019
13.0.4574.0 SP1 CU15 4495257 16 mai 2019
13.0.4560.0 SP1 CU14 4488535 19 mars 2019
13.0.4550.1 SP1 CU13 4475775 23 janvier 2019
13.0.4541.0 SP1 CU12 4464343 13 novembre 2018
13.0.4528.0 SP1 CU11 4459676 17 septembre 2018
13.0.4224.16 SP1 CU10 + Mise à jour 4458842 22 août 2018

de sécurité
13.0.4514.0 SP1 CU10 4341569 16 juillet 2018
13.0.4502.0 SP1 CU9 4100997 30 mai 2018
13.0.4474.0 SP1 CU8 4077064 19 mars 2018
13.0.4466.4 SP1 CU7 4057119 04 janvier 2018

13.0.4457.0 SP1 CU6 4037354 20 novembre 2017
13.0.4451.0 SP1 CU5 4040714 18 septembre 2017
13.0.4446.0 SP1 CU4 4024305 8 août 2017
13.0.4435.0 SP1 CU3 4019916 15 mai 2017
13.0.4422.0 SP1 CU2 4013106 20 mars 2017
13.0.4411.0 SP1 CU1 3208177 17 janvier 2017
13.0.4001.0 SP1 RTW/PCU1 3182545 16 novembre 2016
13.0.2216.0 RTM CU9 4037357 20 novembre 2017
13.0.2213.0 RTM CU8 4040713 18 septembre 2017
13.0.2210.0 RTM CU7 4024304 8 août 2017
13.0.2204.0 RTM CU6 4019914 15 mai 2017
13.0.2197.0 RTM CU5 4013105 20 mars 2017
13.0.2193.0 RTM CU4 3205052 17 janvier 2017
13.0.2186.6 RTM CU3 3205413 16 novembre 2016
13.0.2164.0 RTM CU2 3182270 22 septembre 2016
13.0.2149.0 RTM CU1 3164674 25 juillet 2016
SQL Server 2014

12.0.6329.1 SP3 CU4 4500181 29 juillet 2019
12.0.6293.0 SP3 CU3 + GDR 4505422 9 juillet 2019
12.0.6259.0 SP3 CU3 4491539 16 avril 2019
12.0.6214.1 SP3 CU2 4482960 19 février 2019
12.0.6205.1 SP3 CU1 4470220 12 décembre 2018
12.0.6024.0 SP3 RTW/PCU3 4022619 30 octobre 2018

12.0.5687.1 SP2 CU18 4500180 29 juillet 2019
12.0.5659.1 SP2 CU17 + GDR 4505419 9 juillet 2019
12.0.5632.1 SP2 CU17 4491540 16 avril 2019
12.0.5626.1 SP2 CU16 4482967 19 février 2019
12.0.5605.1 SP2 CU15 4469137 12 décembre 2018
12.0.5600.1 SP2 CU14 4459860 15 octobre 2018
12.0.5590.1 SP2 CU13 4456287 27 août 2018
12.0.5589.7 SP2 CU12 4130489 18 juin 2018
12.0.5579.0 SP2 CU11 4077063 19 mars 2018
12.0.5571.0 SP2 CU10 4052725 16 janvier 2018
12.0.5563.0 SP2 CU9 4055557 18 décembre 2017
12.0.5557.0 SP2 CU8 4037356 16 octobre 2017
12.0.5556.0 SP2 CU7 4032541 28 août 2017
12.0.5553.0 SP2 CU6 4019094 8 août 2017
12.0.5546.0 SP2 CU5 4013098 17 avril 2017
12.0.5540.0 SP2 CU4 4010394 21 février 2017
12.0.5538.0 SP2 CU3 3204388 19 décembre 2016
12.0.5522.0 SP2 CU2 3188778 17 octobre 2016
12.0.5511.0 SP2 CU1 3178925 25 août 2016
12.0.5000.0 SP2 RTW/PCU2 3171021 11 juillet 2016
12.0.4522.0 SP1 CU13 4019099 8 août 2017
12.0.4511.0 SP1 CU12 4017793 17 avril 2017
12.0.4502.0 SP1 CU11 4010392 21 février 2017
12.0.4491.0 SP1 CU10 3204399 19 décembre 2016
12.0.4474.0 SP1 CU9 3186964 17 octobre 2016

12.0.4468.0 SP1 CU8 3174038 15 août 2016
12.0.4459.0 SP1 CU7 3162659 20 juin 2016
12.0.4457.0 SP1 CU6 3167392 30 mai 2016
12.0.4449.0 SP1 CU6 3144524 18 avril 2016
12.0.4438.0 SP1 CU5 3130926 22 février 2016
12.0.4436.0 SP1 CU4 3106660 21 décembre 2015
12.0.4427.24 SP1 CU3 3094221 19 octobre 2015
12.0.4422.0 SP1 CU2 3075950 17 août 2015
12.0.4416.0 SP1 CU1 3067839 19 juin 2015
12.0.4213.0 SP1 MS15-058 : Mise à 3070446 14 juillet 2015

jour de sécurité GDR
12.0.4100.1 SP1 RTW/PCU1 3058865 04 mai 2015
12.0.2569.0 RTM CU14 3158271 20 juin 2016
12.0.2568.0 RTM CU13 3144517 18 avril 2016
12.0.2564.0 RTM CU12 3130923 22 février 2016
12.0.2560.0 RTM CU11 3106659 21 décembre 2015
12.0.2556.4 RTM CU10 3094220 19 octobre 2015
12.0.2553.0 RTM CU9 3075949 17 août 2015
12.0.2548.0 RTM MS15-058 : Mise à 3045323 14 juillet 2015

jour de sécurité QFE
12.0.2546.0 RTM CU8 3067836 19 juin 2015
12.0.2495.0 RTM CU7 3046038 20 avril 2015
12.0.2480.0 RTM CU6 3031047 16 février 2015
12.0.2456.0 RTM CU5 3011055 17 décembre 2014
12.0.2430.0 RTM CU4 2999197 mardi 21 octobre 20

14
12.0.2402.0 RTM CU3 2984923 18 août 2014

12.0.2381.0 RTM MS14-044 : Mise à 2977316 mardi 12 août 2014

12.0.2370.0 RTM CU2 2967546 vendredi 27 juin

2014
12.0.2342.0 RTM CU1 2931693 21 avril 2014
12.0.2269.0 RTM MS15-058 : Mise à 3045324 14 juillet 2015

12.0.2254.0 RTM MS14-044 : Mise à 2977315 mardi 12 août 2014

12.0.2000.8 RTM 01 avril 2014
SQL Server 2012

11.0.7001.0 SP4 RTW/PCU4 4018073 2 octobre 2017
11.0.6607.3 SP3 CU10 4025925 8 août 2017
11.0.6598.0 SP3 CU9 4016762 15 mai 2017
11.0.6594.0 SP3 CU8 4013104 20 mars 2017
11.0.6579.0 SP3 CU7 3205051 17 janvier 2017
11.0.6567.0 SP3 CU6 3194992 17 novembre 2016
11.0.6248.0 SP3 Mise à jour de 3194721 8 novembre 2016

sécurité GDR MS16-
136
11.0.6544.0 SP3 CU5 3180915 19 septembre 2016
11.0.6540.0 SP3 CU4 3165264 18 juillet 2016
11.0.6537.0 SP3 CU3 3152635 16 mai 2016
11.0.6523.0 SP3 CU2 3137746 21 mars 2016
11.0.6518.0 SP3 CU1 3123299 19 janvier 2016
11.0.5678.0 SP2 CU16 3205054 17 novembre 2016

11.0.5676.0 SP2 CU15 3205416 17 novembre 2016
11.0.5657.0 SP2 CU14 3180914 19 septembre 2016
11.0.5655.0 SP2 CU13 3165266 18 juillet 2016
11.0.5649.0 SP2 CU12 3152637 16 mai 2016
11.0.5646.0 SP2 CU11 3137745 21 mars 2016
11.0.5644.2 SP2 CU10 3120313 19 janvier 2016
11.0.5641.0 SP2 CU9 3098512 16 novembre 2015
11.0.5634.1 SP2 CU8 3082561 21 septembre 2015
11.0.5623.0 SP2 CU7 3072100 20 juillet 2015

11.0.5592.0 SP2 CU6 3052468 18 mai 2015
11.0.5582.0 SP2 CU5 3037255 16 mars 2015
11.0.5569.0 SP2 CU4 3007556 19 janvier 2015
11.0.5556.0 SP2 CU3 3002049 17 novembre 2014
11.0.5548.0 SP2 CU2 2983175 15 septembre 2014
11.0.5532.0 SP2 CU1 2976982 23 juillet 2014

11.0.5058.0 SP2 RTW/PCU2 2958429 10 juin 2014

11.0.3482.00 SP1 CU13 3002044 17 novembre 2014
11.0.3470.00 SP1 CU12 2991533 15 septembre 2014
11.0.3460.0 SP1 MS14-044 : Mise à 2977325 mardi 12 août 2014

11.0.3449.00 SP1 CU11 2975396 21 juillet 2014

11.0.3431.00 SP1 CU10 2954099 19 mai 2014
11.0.3412.00 SP1 CU9 2931078 17 mars 2014
11.0.3401.00 SP1 CU8 2917531 20 janvier 2014
11.0.3393.00 SP1 CU7 2894115 lundi 18 novembre

2013
11.0.3381.00 SP1 CU6 2874879 16 septembre 2013
11.0.3373.00 SP1 CU5 2861107 15 juillet 2013
11.0.3368.00 SP1 CU4 2833645 30 mai 2013
11.0.3349.00 SP1 CU3 2812412 18 mars 2013
11.0.3339.00 SP1 CU2 2790947 21 janvier 2013
11.0.3321.00 SP1 CU1 2765331 20 novembre 2012


11.0.2424.00 RTM CU11 2908007 16 décembre 2013
11.0.2420.00 RTM CU10 2891666 21 octobre 2013
11.0.2401.00 RTM CU6 2728897 18 février 2013
11.0.2395.00 RTM CU5 2777772 17 décembre 2012
11.0.2383.00 RTM CU4 2758687 15 octobre 2012
11.0.2376.00 RTM MS12-070 : Mise à 2716441 9 octobre 2012

11.0.2332.00 RTM CU3 2723749 31 août 2012
11.0.2325.00 RTM CU2 2703275 18 juin 2012
11.0.2316.00 RTM CU1 2679368 12 avril 2012
11.0.2218.00 RTM MS12-070 : Mise à 2716442 9 octobre 2012

11.0.2100.60 RTM 6 mars 2012
SQL Server 2008 R2



10.50.6000.34 SP3 RTW/PCU3 2979597 26 septembre 2014

10.50.4321.00 SP2 MS14-044 : Mise à 2977319 14 août 2014

10.50.4319.00 SP2 CU13 2967540 30 juin 2014
10.50.4305.00 SP2 CU12 2938478 21 avril 2014
10.50.4302.00 SP2 CU11 2926028 18 février 2014
10.50.4297.00 SP2 CU10 2908087 17 décembre 2013
10.50.4295.00 SP2 CU9 2887606 28 octobre 2013
10.50.4285.00 SP2 CU7 2844090 17 juin 2013
10.50.4279.00 SP2 CU6 2830140 15 avril 2013
10.50.4276.00 SP2 CU5 2797460 18 février 2013
10.50.4270.00 SP2 CU4 2777358 17 décembre 2012
10.50.4266.00 SP2 CU3 2754552 15 octobre 2012
10.50.4263.00 SP2 CU2 2740411 31 août 2012
10.50.4260.00 SP2 CU1 2720425 24 juillet 2012


10.50.2881.00 SP1 CU14 2868244 jeudi 8 août 2013
10.50.2876.00 SP1 CU13 2855792 17 juin 2013
10.50.2874.00 SP1 CU12 2828727 15 avril 2013
10.50.2869.00 SP1 CU11 2812683 18 février 2013
10.50.2866.00 SP1 CU9 2756574 15 octobre 2012
10.50.2861.00 SP1 MS12-070 : Mise à 2716439 9 octobre 2012

10.50.2822.00 SP1 CU8 2723743 31 août 2012
10.50.2817.00 SP1 CU7 2703282 18 juin 2012
10.50.2811.00 SP1 CU6 2679367 lundi 16 avril 2012
10.50.2806.00 SP1 CU5 2659694 22 février 2012
10.50.2796.00 SP1 CU4 2633146 19 décembre 2011
10.50.2789.00 SP1 CU3 2591748 17 octobre 2011
10.50.2772.00 SP1 CU2 2567714 15 août 2011
10.50.2769.00 SP1 CU1 2544793 18 juillet 2011

10.50.1815.00 RTM CU13 2679366 lundi 16 avril 2012
10.50.1810.00 RTM CU12 2659692 21 février 2012
10.50.1807.00 RTM CU10 2591746 17 octobre 2011
10.50.1804.00 RTM CU9 2567713 15 août 2011
10.50.1790.00 RTM MS11-049 : Mise à 2494086 14 juin 2011

10.50.1777.00 RTM CU7 2507770 18 avril 2011
10.50.1765.00 RTM CU6 2489376 21 février 2011

10.50.1753.00 RTM CU5 2438347 20 décembre 2010
10.50.1746.00 RTM CU4 2345451 18 octobre 2010
10.50.1734.00 RTM CU3 2261464 16 août 2010
10.50.1720.00 RTM CU2 2072493 21 juin 2010
10.50.1702.00 RTM CU1 981355 18 mai 2010
10.50.1617.00 RTM MS11-049 : Mise à 2494088 14 juin 2011

10.50.1600.1 RTM 10 mai 2010
SQL Server 2008




10.00.5869.00 SP3 MS14-044 : Mise à 2984340, 2977322 mardi 12 août 2014

10.00.5867.00 (package de mise à 2877204

jour à la demande)
10.00.5861.00 SP3 CU17 2958696 19 mai 2014
10.00.5852.00 SP3 CU16 2936421 17 mars 2014
10.00.5850.00 SP3 CU15 2923520 20 janvier 2014
10.00.5848.00 SP3 CU14 2893410 lundi 18 novembre

2013
10.00.5846.00 SP3 CU13 2880350 16 septembre 2013
10.00.5844.00 SP3 CU12 2863205 15 juillet 2013
10.00.5840.00 SP3 CU11 2834048 20 mai 2013

10.00.5835.00 SP3 CU10 2814783 18 mars 2013
10.00.5829.00 SP3 CU9 2799883 21 janvier 2013
10.00.5828.00 SP3 CU8 2771833 19 novembre 2012

10.00.5794.00 SP3 CU7 2738350 17 septembre 2012
10.00.5788.00 SP3 CU6 2715953 16 juillet 2012
10.00.5785.00 SP3 CU5 2696626 21 mai 2012
10.00.5768.00 SP3 CU2 2633143 21 novembre 2011
10.00.5766.00 SP3 CU1 2617146 17 octobre 2011



10.00.5500.00 SP3 RTW /PCU 3 2546951 6 octobre 2011

10.00.4332.00 SP2 CU10 2696625 21 mai 2012
10.00.4330.00 SP2 CU9 2673382 19 mars 2012
10.00.4326.00 SP2 CU8 2648096 16 janvier 2012
10.00.4323.00 SP2 CU7 2617148 21 novembre 2011
10.00.4321.00 SP2 CU6 2582285 19 septembre 2011
10.00.4316.00 SP2 CU5 2555408 18 juillet 2011
10.00.4311.00 SP2 MS11-049 : Mise à 2494094 14 juin 2011

10.00.4285.00 SP2 CU4 2527180 16 mai 2011
10.00.4279.00 SP2 CU3 2498535 17 mars 2011

10.00.4266.00 SP2 CU1 2289254 15 novembre 2010

10.00.4064.00 SP2 MS11-049 : Mise à 2494089 14 juin 2011

10.00.4000.00 SP2 RTW /PCU 2 2285068 29 septembre 2010
10.00.2850.0 SP1 CU16 2582282 19 septembre 2011
10.00.2847.0 SP1 CU15 2555406 18 juillet 2011
10.00.2841.0 SP1 MS11-049 : Mise à 2494100 14 juin 2011

10.00.2821.00 SP1 CU14 2527187 16 mai 2011
10.00.2816.00 SP1 CU13 2497673 17 mars 2011
10.00.2804.00 SP1 CU11 2413738 15 novembre 2010
10.00.2775.00 SP1 CU8 981702 17 mai 2010
10.00.2746.00 SP1 CU5 975977 16 novembre 2009
10.00.2734.00 SP1 CU4 973602 21 septembre 2009
10.00.2723.00 SP1 CU3 971491 20 juillet 2009
10.00.2714.00 SP1 CU2 970315 18 mai 2009
10.00.2710.00 SP1 CU1 969099 16 avril 2009
10.00.2573.00 SP1 MS11-049 : Mise à 2494096 14 juin 2011

10.00.2531.00 SP1 RTW /PCU 1 Avril 2009
10.00.1835.00 RTM CU10 979064 15 mars 2010
10.00.1823.00 RTM CU8 975976 16 novembre 2009
10.00.1787.00 RTM CU3 960484 19 janvier 2009
10.00.1779.00 RTM CU2 958186 19 novembre 2008
10.00.1763.00 RTM CU1 956717 22 septembre 2008

10.00.1600.22 RTM 6 août 2008
SQL Server 2005

9.00.5324 SP4 MS12-070 : Mise à 2716427 9 octobre 2012

9.00.5292 SP4 MS11-049 : Mise à 2494123 14 juin 2011

9.00.5069 SP4 MS12-070 : Mise à 2716429 9 octobre 2012

9.00.5057 SP4 MS11-049 : Mise à 2494120 14 juin 2011

9.00.5000 SP4 RTW /PCU4 16 décembre 2010
9.00.4309 SP3 CU11 2258854 16 août 2010
9.00.4305 SP3 CU10 983329 21 juin 2010
9.00.4285 SP3 CU8 978915 16 février 2010
9.00.4230 SP3 CU5 972511 17 août 2009
9.00.4226 SP3 CU4 970279 15 juin 2009
9.00.4211 SP3 CU2 961930 16 février 2009
9.00.4060 SP3 MS11-049 : Mise à 2494113 14 juin 2011

9.00.4035 SP3 RTW 955706 15 décembre 2008
9.00.3325 SP2 CU13 967908 20 avril 2009
9.00.3282 SP2 CU9 953752 18 août 2008
9.00.3257 SP2 CU8 951217 16 juin 2008
9.00.3239 SP2 CU7 949095 14 avril 2008
9.00.3077 SP4 MS09-004 : Mise à 960089 10 février 2009

9.00.3042 SP2 937137

9.00.2047 SP1
9.00.1399 RTM
SQL Server 2000

DESC RIP T IO N DE L A VERSIO N ( N UM ÉRO DE L A B A SE DE
N UM ÉRO DE B UIL D O U VERSIO N DO N N ÉES DE C ET T E M ISE À JO UR) , DAT E DE P UB L IC AT IO N
8.00.2283 Correctif post-SP4 pour MS09-004 (971524)
8.00.2282 MS09-004 : KB959420 29 octobre 2008
8.00.2273 MS08-040 - KB 948111 8 juillet 2008
8.00.2040 Correctif AWE post-SP4 (899761)
8.00.2039 SQL Server 2000 SP4
8.00.1007 Update.exe du programme d’installation de correctifs 2

(891640)
8.00.977 Update.exe Du programme d’installation de correctifs - Ligne

de base 1 (884856)
8.00.818 (821277)
8.00.765 Correctifs post-SP3
8.00.760 SQL Server 2000 SP3 ou SP3a (8.00.766 ssnetlib.dll)
8.00.701 Publication du programme d’installation de correctifs v.1
8.00.534 SQL Server 2000 SP2
8.00.384 SQL Server 2000 SP1
8.00.194 SQL Server 2000 RTM ou MSDE 2.0
Versions antérieures de SQL Server

SQL Server 7.0
Utilisez le numéro de version dans le tableau suivant pour identifier le niveau de produit ou de Service Pack.
N UM ÉRO DE VERSIO N SERVIC E PA C K
7.00.1063 SQL Server 7.0 Service Pack 4

7.00.623 SQL Server 7.0 RTM
SQL Server 6.5

Utilisez le numéro de version dans le tableau suivant pour identifier le niveau de produit ou de Service Pack.
6.50.479 SQL Server 6.5 Service Pack 5a Update
6.50.416 SQL Server 6.5 Service Pack 5a
6.50.201 SQL Server 6,5 RTM

Des déviations ou des techniques similaires peuvent
entraîner des comportements inattendus avec SQL
Server
Cet article décrit la stratégie de support Microsoft lorsque vous utilisez des déviations tierces avec des SQL
Server et des problèmes qui peuvent se produire lorsque vous les utilisez.
Résumé
Le support Microsoft a rencontré de nombreux produits tiers qui utilisent des déviations pour fournir des
fonctionnalités supplémentaires aux SQL Server. Il s’agit généralement de fonctionnalités d’audit. Il n’existe
aucun processus de certification pour les déviations tierces pour les applications Microsoft. Par conséquent, en
règle générale, Microsoft déconseille fortement d’utiliser les déviations.
Les fonctionnalités qui utilisent des déviations ou des techniques similaires pour modifier le comportement des
SQL Server peuvent entraîner les problèmes suivants :
Problèmes de performances.
Résultats incorrects.
Altération du disque et de la mémoire.
Perte de SQL Server réponse.
Arrêt inattendu du processus.
Impossibilité d’utiliser des diagnostics standard, tels que fn_get_sql fonction et la DBCC INPUTBUFFER
commande.
Utilisation du processeur à 100 % et temps de récupération de base de données longs lorsque vous utilisez
des tables OLTP en mémoire dans SQL Server.
Vous pouvez rencontrer ces mêmes problèmes lorsque vous utilisez des logiciels non Microsoft tels que des
serveurs liés, des procédures étendues ou des objets COM au sein SQL Server processus. Les déviations sont
masquées en affichage DBA. Pour découvrir une déviation, vous devez utiliser les techniques décrites dans la
section Plus d’informations qui suit. Les serveurs liés, les objets COM et les procédures étendues ont une
inscription explicite et des interfaces définies.
NOTE
En raison de la nature masquée des déviations et de l’absence d’interfaces publiées, Microsoft ne fournit pas de services
de support pour les fonctionnalités tierces qui utilisent des déviations ou des techniques similaires. Le tiers est
responsable de la prise en charge de son propre code, tout comme il serait responsable de son propre serveur lié ou d’un
autre déploiement.
Il est courant, dans le cadre de la résolution des problèmes, que les services de support Microsoft vous
demandent de désactiver les travaux non essentiels et de désactiver ou de supprimer des composants tiers et
d’autres techniques similaires. Microsoft tente toujours de réduire l’encombrement du problème pendant qu’il
identifie le problème. Une fois que le problème est identifié comme non lié aux travaux ou produits tiers, ces
travaux ou produits tiers peuvent être de nouveau introduits en production.
Nous n’avons pas l’intention de découvrir une déviation, puis de considérer l’instance de SQL Server comme
non pris en compte. Microsoft reconnaît que certaines implémentations sont nécessaires. Toutefois, Microsoft
vous oblige à valider la prise en charge des déviations. Un détour d’une société fiable et fiable est sans aucun
doute différent d’une déviation inattendue utilisée par un virus. Microsoft ne justifie ni ne certifie ces produits
tiers, ni la façon dont les produits tiers interagissent avec les produits et services Microsoft. Au lieu de cela, les
fournisseurs tiers sont responsables de l’identification et de la fiabilité de leurs produits et services. Si vous avez
des questions sur les produits et services tiers, contactez le tiers applicable. Microsoft n’est pas responsable des
problèmes causés par votre utilisation de produits ou services tiers en relation avec SQL Server.
Les déviations offrent des fonctionnalités améliorées et un compromis risque/récompense. En règle générale,
lorsqu’une déviation est implémentée dans SQL Server, du code tiers est injecté dans l’espace de processus.
Cette activité peut modifier le comportement des SQL Server.
Voici quelques exemples de situations et d’effets secondaires possibles :
Les paquets de trafic réseau entrant (TDS) sont analysés et modifiés. La déviation est ajoutée à un
emplacement critique au niveau net_readdata thread de processus réseau. Même 100 cycles de
processeur à cet emplacement peuvent réduire considérablement le débit du débit par lots.
Une modification des données TDS réelles peut entraîner des problèmes de mémoire. Ce problème a
déclenché divers problèmes de stabilité SQL Server et d’altération des données. Des problèmes peuvent
entraîner une partie de la changement d’un paquet TDS et la relecture de la SQL Server. Les installations
de journalisation à ce niveau peuvent exposer des mots de passe et d’autres données sensibles SQL
Server suivi est conçu pour supprimer et sécuriser.
SQL Server routines d’SQL Server sont déviées pour modifier le comportement. Les effets secondaires
possibles sont les suivants :
Les plans d’exécution ne correspondent pas au texte de requête réel.
Une commande est envoyée une seule fois à partir du client. Toutefois, la commande est exécutée
plusieurs fois.
La sortie de suivi affiche la commande d’origine au lieu de la requête modifiée.
La DBCC INPUTBUFFER commande affiche la commande d’origine au lieu de la requête modifiée.
La fn_get_sql fonction affiche des données incorrectes. En outre, la fn_get_sql fonction est
susceptible d’être exposée à des exceptions et à des résultats incorrects. La fn_get_sql fonction est
utilisée par de nombreuses solutions d’analyse et peut entraîner des problèmes sur les solutions
d’analyse.
La planification globale du planning du mode utilisateur (UMS) et SQL Server système d’exploitation
(SQLOS) peut être interrompue. Cela entraîne la perte de SQL Server réponse, des changements de
performances et des pannes.
Les API Win32 qui fournissent des fonctionnalités de sécurité améliorées sont déviées. Selon
l’implémentation, les installations de journalisation à ce niveau peuvent exposer des mots de passe et
d’autres données sensibles. La planification globale de la SQLOS et de la ums est interrompue. Cela
entraîne la perte de SQL Server réponse et des pannes.
La modification des tables de fonctions et la redirection des fonctions SQL Server ou des API Windows ne
sont pas pris en charge dans SQL Server processus. Cela peut entraîner une instabilité et un
comportement inattendu dans la SQL Server de l’utilisateur.
L’exemple suivant montre que kernel32!GetQueuedCompletionStatus la fonction a été déviée.
MyDLL!MyGetQueuedCompletionStatus
ssnetlib!ConnectionReadAsyncWait
Dans l’assembly de la fonction, la première instruction a été remplacée GetQueuedCompletionStatus par une
instruction de saut.
0:038> u kernel32!GetQueuedCompletionStatus
kernel32!GetQueuedCompletionStatus
77e660f1 e90a9f00aa jmp 21e70000 ß This points to an address that does not appear in the loaded module list
(lm). It is injected code.
77e660f6 83ec10 sub esp,10h
L’assembly du code injecté affiche l’activité qui a été déviée et un appel au fichier MyDLL.
0:038> u 21e70000
21e70000 55 push ebp
21e70001 8bec mov ebp,esp
21e70003 51 push ecx
21e70004 8b4518 mov eax,dword ptr [ebp+18h]
21e70007 50 push eax
21e70008 8b4d14 mov ecx,dword ptr [ebp+14h]
21e7000b 51 push ecx
21e7000c 8b5510 mov edx,dword ptr [ebp+10h]
21e7000f 52 push edx
21e70010 8b450c mov eax,dword ptr [ebp+0Ch]
21e70013 50 push eax
21e70014 8b4d08 mov ecx,dword ptr [ebp+8]
21e70017 51 push ecx
21e70018 e8234d19ee call MyDLL+0x4d40 (10004d40) <- Call to the MyDLL file.
21e7001d 8945fc mov dword ptr [ebp-4],eax
21e70020 8b55fc mov edx,dword ptr [ebp-4]
Vous pouvez utiliser les outils de débogage Windows pour déterminer si des déviations sont utilisées. Pour cela,
procédez comme suit.
NOTE
Testez toujours cette méthode avant de l’essayer en production. Lorsque vous utilisez les outils de débogage pour
Windows, le processus peut se figer lorsque vous exécutez les commandes. Ce comportement peut nuire à un serveur de
production.
1. Attachez les outils de débogage Windows à SQL Server ou chargez un fichier de vidage utilisateur
complet.
2. Émettre la commande de débogger suivante. Cette commande inspecte chaque image par rapport à
l’image sur disque pour déterminer si des déviations ont été injectées.
!for_each_module "!chkimg -v @#Base -d"
3. Détachez le débogger.
Si l’image en mémoire a été modifiée, la sortie peut ressembler à ce qui suit :
Comparison image path: c:\program files\microsoft sql server\mssql\binn\ssnetlib.dll\ssnetlib.dll
Scanning section: .text
Size: 56488
Range to scan: 0c261000-0c26eca8
0c263710-0c26371a 11 bytes - ssnetlib!ConnectionClose
[ 8b ff 55 8b ec 83 ec 10:68 00 00 00 00 e9 27 8a ]
0c2641e0-0c2641ea 11 bytes - ssnetlib!ConnectionReadAsync (+0xad0)
[ 8b ff 55 8b ec 83 ec 38:68 00 00 00 00 e9 00 7e ]
0c265160-0c26516a 11 bytes - ssnetlib!ConnectionWriteAsync (+0xf80)
[ 8b ff 55 8b ec 83 ec 28:68 00 00 00 00 e9 ba 70 ]
Total bytes compared: 56488(100%)
Number of errors: 33
33 errors : 0c260000 (0c263710-0c26516a)
Vous pouvez examiner l’assembly pour examiner plus attentivement le problème comme suit :
0:038> u ssnetlib!ConnectionClose
ssnetlib!ConnectionClose]:
0c263710 6800000000 push 0
0c263715 e9278ada03 jmp MyDLL!MyGetQueuedCompletionStatus <- A detour has been installed.
Les programmes antivirus qui s’SQL attaques par injection peuvent faire l’SQL Server code. Dans ce scénario, la
sortie de l’extension peut montrer que le SQL Server !for_each_module "!chkimg -v @#Base -d" fonctionne et est
modifié yyparse ex_raise2 :
Comparison image path: <symbol file path>\sqlservr.exeRange to scan: c81000-3de7d48 ed71a8-ed71ad 6 bytes -
sqlservr!yyparse [ ff f5 41 54 41 55:e9 c7 95 5c 76 90 ]1202820-1202824 5 bytes - sqlservr!ex_raise2
(+0x32b678) [ ff f3 57 41 54:e9 20 e0 29 76 ] Total bytes compared: 51801416(17%)Number of errors: 11
Nous vous recommandons de contacter le fournisseur des déviations ou des techniques similaires pour obtenir
des informations détaillées sur la façon dont il utilise les déviations dans SQL Server. Pour plus d’informations
sur les déviations et les techniques similaires, voir Detours.
Fin de la prise en charge SQL Server 2008 et SQL
Server 2008 R2
Cet article décrit la fin de la prise en charge SQL Server 2008.

Résumé
Microsoft SQL Server 2008 et SQL Server 2008 R2 ont approche de la fin de la prise en charge étendue. À des
dates du tableau ci-dessous, il n’y aura pas d’autres dates :
Mises à jour de sécurité gratuites en local
Mises à jour non relatives à la sécurité
Options de support gratuites
Mises à jour de contenu technique en ligne
Les clients qui utilisent ces versions de SQL Server et services doivent suivre l’une des étapes suivantes :
Mettre à niveau vers la dernière version de SQL Server local.
Ré-héberger sur Azure SQL Database instance gérée, ce qui élimine la nécessité de futures mises à niveau.
Migrez vers Microsoft Azure machines virtuelles.
Cette option de machine virtuelle tire parti de trois années supplémentaires de mises à jour de
sécurité critiques sans frais supplémentaires. Les clients peuvent également se moderniser dès qu’ils
sont prêts.
Le tableau suivant concerne les produits SQL Server 2008 et SQL Server 2008 R2. Le tableau indique les dates à
laquelle chaque produit atteint ou a atteint la fin de sa prise en charge par Microsoft :
DAT ES DE F IN DE
P RO DUIT P RISE EN C H A RGE ÉT EN DUE
Microsoft SQL Server Développeur 2008 7/9/2019
Microsoft SQL Server 2008 Enterprise 7/9/2019
Microsoft SQL Server 2008 Express 7/9/2019
Microsoft SQL Server 2008 Express services avancés 7/9/2019
Microsoft SQL Server 2008 R2 Datacenter 7/9/2019
Microsoft SQL Server 2008 R2 Developer 7/9/2019
Microsoft SQL Server 2008 R2 Enterprise 7/9/2019

DAT ES DE F IN DE
P RO DUIT P RISE EN C H A RGE ÉT EN DUE
Microsoft SQL Server 2008 R2 Express 7/9/2019
Microsoft SQL Server 2008 R2 Express avec services avancés 7/9/2019
Microsoft SQL Server 2008 R2 pour les systèmes incorporés 7/9/2019
Microsoft SQL Server 2008 R2 Parallel Data Warehouse 7/9/2019
Microsoft SQL Server 2008 R2 Standard 7/9/2019
Microsoft SQL Server 2008 R2 Édition Standard for Small 7/9/2019

Business
Microsoft SQL Server 2008 R2 Web 7/9/2019
Microsoft SQL Server 2008 R2 Workgroup 7/9/2019
Microsoft SQL Server 2008 Standard 7/9/2019
Microsoft SQL Server Web 2008 7/9/2019
Microsoft SQL Server 2008 Workgroup 7/9/2019
Nous vous recommandons de migrer vers Azure SQL DB ou de mettre à niveau vers les versions actuelles du
produit. Vous devez prendre des mesures avant les dates de fin du support. La mise à niveau vous permet de
tirer parti des dernières innovations de produit et garantit une prise en charge ininterrompue de Microsoft.
Ressources
Options de fin de support de SQL Server
Étendre la prise en charge SQL Server 2008 et SQL Server 2008 R2 avec Azure
Fin du support classique pour SQL Server 2008 et SQL Server 2008 R2, juillet 2014
SQL Server 2008 R2
documentation SQL Server 2008
Assistance à la migration avec le Centre de migration et de modernisation Azure
Le Centre de migration et de modernisation Azure dispose d’un large éventail d’outils disponibles pour vous
aider :
Évaluez votre environnement local actuel.
Migrez vos charges de travail vers Azure.
Optimisez votre utilisation d’Azure en fonction de vos besoins.
Microsoft travaille également avec de nombreux partenaires qui sont disponibles pour vous aider à chaque
étape du parcours.
Informations sur microsoft Automated
Troubleshooting Services and Support Diagnostic
Platform
Cet article présente les questions fréquemment posées (FAQ) sur les services de dépannage automatisé
microsoft (MATS) et la plateforme de diagnostic du support technique (SDP).
Version du produit d’origine : Windows
Résumé
Le support Microsoft utilise MATS pour collecter des informations de diagnostic à partir d’un ordinateur
Windows, pour analyser les données collectées pour les causes racines connues et pour déterminer la résolution
correcte des problèmes trouvés. Les informations collectées peuvent également être utilisées pour effectuer
automatiquement des tâches courantes de dépannage ou résoudre automatiquement les problèmes connus sur
votre ordinateur. Les résultats des données que vous collectez peuvent être téléchargés vers le support
Microsoft.
Pour résoudre les problèmes, voir la section dépannage de ce document.
Q1 : Comment exécuter les packages de diagnostic ?

Sur les ordinateurs qui ont une connexion Internet :
1. Cliquez sur l’URL que Microsoft vous a fournie ou copiez-la et collez-la dans la barre d’adresses de
votre navigateur web.
2. Lorsque la page se charge, cliquez sur le grand bouton « Exécuter » qui s’affiche dans la page, puis
veillez à sélectionner l’invite de dialogue « Exécuter » (ou « Ouvrir ») lorsque vous êtes invité à
exécuter ou à enregistrer le fichier.
3. Vous pouvez être invité à utiliser une boîte de dialogue contrôle de compte d’utilisateur (UAC) qui
vous demande si vous souhaitez que MATS modifie votre ordinateur. Cliquez sur le bouton « Oui ».
4. Suivez les instructions d’exécuter, puis téléchargez les données générées par le diagnostic.
Sur les ordinateurs qui n’ont pas de connexion Internet : voir Q2 dans cet article.
Q2 : Comment exécuter des diagnostics SDP sur un ordinateur sans

connexion Internet ?
1. Sur un ordinateur qui dispose d’une connexion Internet :
a. Cliquez sur l’URL que Microsoft vous a fournie ou collez-la dans la barre d’adresses de votre
navigateur web.
b. Lorsque la page se charge, cliquez sur le bouton « Exécuter » et assurez-vous de sélectionner l’invite
de dialogue « Exécuter » (ou « Ouvrir ») lorsque vous êtes invité à exécuter ou à enregistrer le fichier.
c. Vous pouvez être invité à utiliser une boîte de dialogue UAC qui vous demande si vous souhaitez que
MATS modifie votre ordinateur. Cliquez sur le bouton « Oui ».
d. Après le démarrage de MATS, cliquez sur le bouton « Accepter ».
e. Sélectionnez « Un autre ordinateur », puis cliquez sur le bouton « Suivant ». Remarque : si PowerShell
est déjà installé sur l’ordinateur de destination ou s’il s’agit d’un ordinateur qui Windows 7 ou Server
2008 R2, vous pouvez sélectionner l’option « L’ordinateur Windows PowerShell déjà installé » en
cliquant sur la case à cocher.
f. Cliquez sur le bouton « Commencer ».
g. Enregistrez le diagnostic sur un lecteur USB ou un partage réseau. Un fichier nommé «
Portable_Diagnostic.exe » est généré.
2. Sur l’ordinateur à diagnostiquer :
a. Exécutez le fichier « Portable_Diagnostic.exe » (il s’agit du fichier généré sur l’ordinateur qui dispose
d’une connexion Internet). Le diagnostic démarre.
b. Cliquez sur le bouton « Accepter » et suivez les instructions pour exécuter le diagnostic.
c. Une fois le diagnostic terminé, vous êtes invité à passer en revue et à enregistrer les résultats du
téléchargement. Enregistrez les résultats de diagnostic sur un lecteur USB ou un partage réseau. Un
sous-ensemble commençant par les mots « Télécharger Résultats » est créé à l’emplacement que vous
avez sélectionné pour enregistrer les résultats.
3. Sur un ordinateur qui dispose d’une connexion Internet :
a. Recherchez les résultats enregistrés dans le dossier Télécharger Résultats (à l’étape « 2c » plus tôt dans
cet article) et exécutez le fichier « Upload_results.exe ».
b. Cliquez sur le bouton « Envoyer » pour renvoyer les résultats au Support Microsoft.
Q3 : Les diagnostics MATS/SDP peuvent-ils modifier ma configuration

système ?
Certains packages de diagnostic qui s’exécutent sur MATS peuvent modifier la configuration de l’ordinateur, et
d’autres non. Nous vous recommandons de consulter l’article de la Base de connaissances pour le package de
diagnostic spécifique que vous avez l’intention d’exécuter pour obtenir des informations plus précises sur ce que
le package peut modifier et sur les informations qu’il peut collecter. Par exemple, les diagnostics peuvent activer
la journalisation liée au débogage, puis vous obliger à reproduire le problème que vous rencontrez. Une partie
de cette journalisation peut être activée et conservée jusqu’à ce que le package de diagnostic télécharge les
informations de dépannage vers le Support Microsoft.
MATS peut également installer des packages d’Windows PowerShell pour exécuter des packages de diagnostic.
Toutes les modifications de configuration apportées par MATS ne seront pas rendues une fois le package de
diagnostic terminé. Plus précisément, si PowerShell est installé, PowerShell ne sera pas automatiquement
supprimé de l’ordinateur.
En outre, certains diagnostics peuvent également détecter des problèmes spécifiques. Si les diagnostics peuvent
rechercher et résoudre automatiquement des problèmes, vous avez la possibilité d’appliquer des correctifs. Si
vous décidez d’appliquer les correctifs, les modifications apportées par ce correctif resteront une fois le
diagnostic terminé.
Q4 : Quels systèmes d’exploitation peuvent exécuter les packages de

diagnostic du Support Microsoft ?
Windows XP (x86 et x64)
Windows Server 2003 (x86 et x64)
Windows Vista (x86 et x64)
Windows Server 2008 (x86 et x64)
Windows 7 (x86 et x64)
Windows Server 2008 R2 (x64)
Windows 8 (x86 et x64)
Windows Server 2012
Q5 : Existe-t-il des environnements d’installation qui ne sont pas pris

en charge et par conséquent ne peuvent pas exécuter de packages
de diagnostic ?
Les packages de diagnostic les plus nouveaux ne peuvent pas s’exécuter sur :
Itanium (IA-64)
Windows Option d’installation server core de Server 2008 (non R2)
Si l’ordinateur de destination exécute l’un de ces environnements, vous pourrez peut-être exécuter un package
de diagnostic de fonctionnalités réduites plus ancien si disponible. Pour plus d’informations, voir Q7.
Si un package de fonctionnalités réduites n’est pas disponible sur la page web de diagnostic, vous pouvez
demander à votre ingénieur du support technique de vous envoyer un package de diagnostic avec
fonctionnalités réduites compatible avec l’option d’installation Itanium (IA-64) ou Windows Server 2008 Server
Core.
Q6 : Existe-t-il des conditions préalables pour l’exécution du package

de diagnostic ?
Il existe différentes conditions préalables pour l’exécution des packages de diagnostic, selon le système
d’exploitation de l’ordinateur de destination. Le diagnostic vérifie automatiquement si ces conditions préalables
sont requises sur votre ordinateur et commence à s’exécuter s’ils sont déjà installés ou vous invite à les installer
s’ils ne sont pas déjà disponibles sur l’ordinateur.
NOTE
Certains packages de diagnostic peuvent également nécessiter PowerShell 2.0 qui n’est pas installé automatiquement par
MATS. Vous pouvez télécharger PowerShell 2.0 à l’aide des liens fournis dans cet article. En outre, un package de
diagnostic peut avoir d’autres conditions préalables spécifiques à la résolution des problèmes. Par exemple, un package de
diagnostic conçu pour résoudre les problèmes Exchange Server composants peuvent nécessiter l’installation Exchange
Server sur l’ordinateur.
Conditions minimales requises pour exécuter un diagnostic sur les systèmes d’exploitation suivants
Windows XP ou Windows Server 2003
Windows XP (32 bits) requiert le Service Pack 3 ou une version ultérieure
Windows XP 64 bits et Windows Server 2003 nécessitent le Service Pack 2 ou une version ultérieure
Microsoft Core XML Services (MSXML) 6.0
Le .NET Framework 2.0, 3.0 ou 3.5 (l’installation de .NET Framework 4.0 ou version ultérieure n’installe
pas la configuration nécessaire pour ces versions de Windows)
Windows PowerShell 1.0 ou 2.0 (Windows PowerShell 2.0 fait partie de Windows Management
Framework)
NOTE
Le diagnostic installe automatiquement PowerShell 1.0 pour vous. Toutefois, si 2.0 est nécessaire, vous devez
l’installer manuellement vous-même.
Windows Vista ou Windows Server 2008
Windows PowerShell 1.0 ou 2.0 (Windows PowerShell 2.0 fait partie de Windows Management Framework)
NOTE
Le diagnostic installe automatiquement PowerShell 1.0 pour vous. Toutefois, si 2.0 est nécessaire, vous devez l’installer
manuellement vous-même.
Windows 7 ou Windows Server 2008 R2

Toutes les conditions minimales sont remplies.
Windows 8 ou Windows Server 2012
Toutes les conditions minimales sont remplies.
NOTE
Certains packages de diagnostic sur Windows 8 peuvent nécessiter l’installation de .NET Framework 3.5.1, sur lequel
l’installation sera démarrée automatiquement la première fois que le package de diagnostic s’exécute.
Emplacements de téléchargement pour la version minimale requise

Le .NET Framework (sélectionnez l’une des méthodes ci-dessous s’il ne se trouve pas déjà sur l’ordinateur sur
qui vous souhaitez exécuter le package de diagnostic) :
2.0 - Microsoft .NET Framework Version 2.0 Redistributable Package (x64) (x64)
3.5 - Microsoft .NET Framework 3.5 Service Pack 1 (package complet)
Microsoft Core XML Services (MSXML) 6.0
Windows PowerShell System Requirements
Conditions requises pour le redémar
En règle générale, il n’existe aucune exigence de redémarrage pour l’installation des conditions préalables
minimales. Toutefois, dans certaines situations, un redémarrage sera nécessaire. Par exemple, PowerShell 1.0 est
installé sur votre ordinateur et vous mettez à niveau vers PowerShell vers 2.0, ou votre ordinateur a installé une
mise à jour récemment et un redémarrage est en attente.
Q7 : Que dois-je faire si PowerShell ne peut pas être installé sur

l’ordinateur pour être diagnostiquer ?
Si l’ordinateur de destination exécute Windows XP, Windows Server 2003, Windows Vista ou Windows Server
2008 et que vous ne pouvez pas installer PowerShell, vous pouvez exécuter une version à fonctionnalités
réduites du package de diagnostic. Toutefois, il est possible qu’aucun package équivalent « Fonctionnalités
réduites » ne soit disponible pour chaque diagnostic. En outre, les packages de fonctionnalités réduites peuvent
ne pas collecter l’ensemble complet des données collectées par un package standard (il peut uniquement être en
mesure de collecter un sous-ensemble).
Pour déterminer si vous pouvez exécuter un package de fonctionnalités réduites qui ne nécessite pas
l’installation des conditions préalables minimales répertoriées au Q6, ouvrez l’URL fournie par Microsoft dans le
message électronique et développez la section « Méthodes supplémentaires pour exécuter ce package de
diagnostic ». Si vous voyez le texte étiqueté « Sur Windows XP, Windows Server 2003, Windows Vista ou
Windows Server 2008 », cela signifie qu’une version à fonctionnalités réduites du package peut être exécuté sur
l’ordinateur. Dans ce cas, vous pouvez développer la section, puis cliquer sur le lien « Exécuter le diagnostic ».
L’article suivant contient plus d’informations sur la façon d’exécuter des packages de fonctionnalités réduites :
Questions fréquemment posées sur l’outil de diagnostic du support Microsoft (MSDT)
Q8 : Quels composants et fichiers restent sur l’ordinateur une fois que
MATS a chargé les fichiers vers Microsoft ?
Comme décrit au troisième trimestre, certains paramètres ou composants d’run-time peuvent rester sur
l’ordinateur. Par exemple, si PowerShell a été installé pendant l’exécution d’un package de diagnostic, PowerShell
reste sur l’ordinateur.
Pendant la collecte de données, les informations de diagnostic MATS sont stockées temporairement dans le
dossier (où GUID est un GUID généré de manière aléatoire qui représente une instance d’exécution
%WINDIR%\TEMP\SDIAG_{GUID} de diagnostic unique).
%TEMP%\msdtadmin and/or %APPDATA%\..\Local\ElevatedDiagnostics\{Folder} Ces dossiers sont supprimés une fois
l’exécution du package de diagnostic terminée.
Q9 : Les packages de diagnostic peuvent-ils modifier la stratégie

d’exécution de PowerShell ?
La plupart des packages de diagnostic ne modifient pas la stratégie d’exécution De PowerShell. Toutefois,
certains packages de diagnostic qui collectent des informations à partir d’ordinateurs distants peuvent modifier
temporairement la stratégie d’exécution de PowerShell sur « RemoteSigned ».
Le package de diagnostic modifie la configuration de nouveau à la stratégie d’origine avant de terminer la
collecte des informations. Sachez que la stratégie peut rester « RemoteSigned » si vous annulez le diagnostic
avant la fin de l’exécution du package.
Q10 : Comment démarrez-vous un package de diagnostic sur une

installation server core de Windows Server 2008 R2 ?
Windows Server 2008 R2 Server Core ne prend pas en charge l’exécution de packages de diagnostic
directement sur l’ordinateur. Pour diagnostiquer un ordinateur Windows Server 2008 R2 Server Core, vous
devez contacter votre ingénieur du support technique et demander une clé d’accès pour exécuter un package de
diagnostic spécifique qui peut être utilisé pour collecter des informations à partir d’un ordinateur Server Core
R2 à l’aide d’un ordinateur distant.
Q11 : Pourquoi l'« Actualisation des System Information... » s’affiche

lorsque vous exécutez certains packages de diagnostic ?
Ce message est généré par l’utilitaire « System Information » (MSInfo32) lorsqu’il collecte des informations sur
l’ordinateur. Un package de diagnostic exécute généralement l’utilitaire msinfo32 en arrière-plan, lors de
l’exécution d’autres tâches de diagnostic au premier plan, pour accélérer le processus de collecte de données. Ce
processus collecte uniquement des informations sur le système et ne met à jour aucun paramètre sur
l’ordinateur.
Q12 : Comment exécuter des diagnostics sur un ordinateur Windows

server sur qui la configuration de sécurité renforcée (IESC) d’Internet
Explorer est activée ?
Vous disposez de deux options :
1. Générez un fichier exécutable portable sur un serveur dont la « configuration de sécurité renforcée d’Internet
Explorer » est désactivée ou sur un ordinateur exécutant un système d’exploitation client, tel que Windows
Vista ou Windows 7. Ensuite, exécutez l’exécutable portable sur l’ordinateur cible. Pour plus d’informations
sur la façon de générer un exécutable portable, voir Q2.
2. Ajouter le site de support Microsoft à la liste des sites de confiance
Q13 : Quelles URL doivent être configurées sur un pare-feu/proxy

pour exécuter un package de diagnostic ?
Les URL suivantes sont accessibles lorsque vous exécutez un package de diagnostic :
http://support.microsoft.com
https://support.microsoft.com
https://dcupload.microsoft.com
https://dcodews.partners.extranet.microsoft.com
http://microsoft.com
https://microsoft.com
Q14 : Mon environnement est complexe. Comment choisir les

ordinateurs sur lesquels exécuter le diagnostic ?
Si vous ne savez pas sur quels ordinateurs exécuter les packages de diagnostic, discutez plus en détail du
problème avec un ingénieur du support technique Microsoft.
Q15 : Comment le support Microsoft utilise-t-il les informations

téléchargées par un package de diagnostic ?
Les données téléchargées par un package de diagnostic sont utilisées pour la résolution des problèmes. Nous ne
divulguerons aucune information incluse dans les résultats en dehors de Microsoft, de ses filiales contrôlées et
de ses affiliés sans votre consentement.
Microsoft s’engage à protéger la sécurité de vos informations personnelles. Nous utilisons de nombreuses
technologies et procédures de sécurité différentes pour protéger vos informations personnelles contre tout
accès, utilisation ou divulgation non autorisé. Par exemple, nous stockons les informations personnelles que
nous collectons sur des systèmes informatiques à accès limité, qui se trouvent dans des installations contrôlées.
Lorsque nous transmettons des informations hautement confidentielles sur Internet, nous les protégeons à
l’aide du chiffrement, comme le protocole SSL (Secure Socket Layer).
Lisez la déclaration de confidentialité Microsoft Online pour obtenir des informations supplémentaires sur
l’engagement de Microsoft à protéger votre confidentialité : Déclaration de confidentialité Microsoft.

Cette section décrit les problèmes les plus courants qui peuvent se produire lorsque vous exécutez des packages
de diagnostic sur un ordinateur.
T1 : lorsque vous exécutez un diagnostic, l’option « Cet ordinateur »

est estommée et le diagnostic ne peut pas être exécuté
Cela peut se produire car le package de diagnostic que vous essayez d’exécuter est incompatible avec le système
d’exploitation de l’ordinateur de destination. Par exemple, vous exécutez peut-être Windows XP, mais le package
de diagnostic que le support Microsoft vous a envoyé n’est compatible qu’avec Windows 7. Dans ce cas,
contactez un professionnel du support Microsoft pour demander un diagnostic compatible avec le système
d’exploitation de l’ordinateur de destination.
T2 : lorsque vous exécutez un package de diagnostic, vous recevez un

« Nous n’avons pas pu télécharger les composants nécessaires à
partir de notre serveur. Message d’erreur « Essayer à nouveau plus
tard » et l’application se ferme
Corrigez-le pour moi
Pour vérifier les connexions aux URL utilisées dans le service SDP, cliquez sur le bouton ou le lien Résoudre.
Cliquez ensuite sur Exécuter dans la boîte de dialogue Téléchargement de fichiers, puis suivez les étapes de
l’Assistant Résoudre le problème.
NOTE
Le package Fix it est uniquement compatible avec Windows 7 et versions ultérieures. Le package sera mis à jour pour
prendre en charge les versions antérieures Windows prochainement.
Il se peut que cet Assistant ne soit disponible qu’en anglais. Toutefois, la résolution automatique fonctionne aussi pour
d'autres versions linguistiques de Windows.
Si vous n’êtes pas sur l’ordinateur qui a le problème, enregistrez la solution Résoudre le problème sur un disque
mémoire flash ou un CD, puis exécutez-la sur l’ordinateur qui a le problème.
Je résous le problème moi-même

Cela se produit généralement lorsque l’ordinateur ne peut pas contacter les serveurs Microsoft pour télécharger
les composants clients ou le package de diagnostic. Vérifiez que votre navigateur peut accéder aux sites
répertoriés au T13 et qui ont été abordés précédemment.
Pour contourner ce problème, vous pouvez utiliser un autre ordinateur connecté à Internet pour générer un
package de diagnostic portable comme décrit au Q2, ou demander à un ingénieur du support technique
Microsoft de générer un exécutable portable et de vous l’envoyer pour qu’il s’exécute sur l’ordinateur cible.
T3 : lors du transfert de fichiers vers le Support Microsoft, vous

recevez un « L’application n’a pas pu contacter le serveur de
diagnostic. Assurez-vous que vous êtes connecté à Internet, puis
recommencez le message d’erreur «
Cette erreur se produit lorsque l’ordinateur utilisé pour transférer les résultats vers le Support Microsoft ne peut
pas atteindre les serveurs Microsoft, ou si la communication avec les serveurs est interrompue ou arrive à son
terme. Si le problème persiste après avoir cliqué sur le bouton « Réessayer », vous pouvez résoudre ce problème
en suivant les étapes suivantes :
1. Exécutez les étapes décrites dans T2 pour résoudre ce problème.
2. Vérifiez que votre navigateur peut accéder aux sites répertoriés au Q13.
3. f Vous ne pouvez toujours pas télécharger les résultats vers le Support Microsoft après avoir suivi les étapes
précédentes, et que vous avez enregistré une copie du fichier CAB des résultats, contactez le Support
Microsoft pour organiser le transfert du fichier CAB.
4. Si vous n’avez pas enregistré une copie des résultats que vous démarrez le transfert de fichiers, vous pourrez
peut-être l’obtenir si le diagnostic est toujours en cours d’exécution. Le fichier est stocké dans le ou les
dossiers (où GUID est un identificateur généré de manière aléatoire représentant une
%TEMP%\msdtadmin\_{GUID}_ instance d’exécution \Windows\Temp\SDIAG_{GUID} de diagnostic).
T4 : lorsque vous exécutez le package de diagnostic portable («

Portable_Diagnostic.exe ») vous recevez un message d’erreur « Cette
application n’est pas prise en charge sur ce système d’exploitation »
ou un message d’erreur « Cet outil de diagnostic ne prend pas en
charge la configuration de votre ordinateur » et l’application se ferme
Cela peut se produire car le package de diagnostic portable que vous essayez d’exécuter est incompatible avec le
système d’exploitation de l’ordinateur de destination. Par exemple, vous exécutez peut-être Windows XP, mais le
package de diagnostic que le support Microsoft vous a envoyé n’est compatible qu’avec Windows 7. Dans ce cas,
T5 : lorsque vous exécutez un diagnostic, vous recevez un message

d’erreur « Cet outil de dépannage ne s’applique pas à cet ordinateur »
(0x80005005 d’erreur) ou un message d’erreur « Cet outil de
dépannage ne s’applique pas à votre système » et l’application se
ferme.
Cela peut se produire car le package de diagnostic que vous essayez d’exécuter est incompatible avec le système
d’exploitation de l’ordinateur de destination. Par exemple, vous exécutez peut-être Windows XP, mais le package
de diagnostic que le support Microsoft vous a envoyé n’est compatible qu’avec Windows 7. Dans ce cas,
T6 : lorsque vous exécutez un diagnostic, vous recevez un message

d’erreur « Nous sommes désolés, mais votre clé de passe pour cet
outil de diagnostic est obsolète ou a expiré » et vous ne pouvez pas
exécuter le diagnostic.
Cette erreur peut se produire parce que l’URL envoyée par Microsoft a expiré ou que vous avez atteint le
nombre maximal de téléchargements autorisé par une exécution de diagnostic. Dans ce cas, vous devez
contacter le Support Microsoft pour demander de prolonger la date d’expiration ou d’obtenir une nouvelle URL.
T7 : lorsque vous exécutez un diagnostic, vous recevez un message «

Nous sommes désolés, mais le programme a rencontré une erreur
lors de la tentative de contact du serveur. Veuillez réessayer plus tard.
Message d’erreur [Code 80072EE7] »
Cela se produit généralement lorsque l’ordinateur ne peut pas contacter les serveurs Microsoft pour télécharger
les composants clients ou le package de diagnostic. Exécutez l’dépannage disponible dans T2 ou vérifiez que
votre navigateur peut accéder aux sites répertoriés au Q13.
Pour contourner ce problème, vous pouvez utiliser un autre ordinateur connecté à Internet pour générer un
package de diagnostic portable, comme décrit au Q2. Vous pouvez également demander à un ingénieur du
support technique Microsoft de générer un exécutable portable et de vous l’envoyer pour qu’il s’exécute sur
l’ordinateur cible.
T8 : lorsque vous exécutez un diagnostic, vous recevez un message «

Les fichiers de résultats sont trop grands pour être envoyés à
Microsoft... » message d’erreur
Cette erreur se produit lorsque les données collectées par le diagnostic produisent un fichier compressé dont la
taille est supérieure à 2 Go. Le fichier CAB des résultats de diagnostic ne peut être généré et téléchargé
automatiquement que s’il est inférieur à 2 Go.
Lorsque cette erreur se produit, vous pouvez obtenir la version étendue des résultats et les envoyer
manuellement à un ingénieur du support technique Microsoft. Pour ce faire, avant de cliquer sur « Fermer » sur
l’écran de diagnostic, ouvrez le dossier (où GUID est un identificateur aléatoire représentant une instance
d’exécution de diagnostic unique), puis copiez et compressez les résultats dans un autre
%windir%\temp\SDIAG_{GUID}\Result dossier. Après avoir copié le contenu du dossier, revenir au diagnostic, puis
cliquez sur « Fermer » pour nettoyer le dossier temporaire. Enfin, contactez votre professionnel du support
technique pour organiser le transfert des fichiers vers Microsoft.
T9 : lorsque vous exécutez un diagnostic sur un ordinateur Windows

XP ou Windows Server 2003, vous recevez un message d’erreur «
Impossible de trouver une version de l’run time pour exécuter cette
application »
Cette erreur peut se produire si le .NET Framework 4.0 est installé sur l’ordinateur, mais que .NET Framework 2.0
ou .NET Framework 3.5 n’est pas installé. Pour résoudre le problème, installez la .NET Framework 2.0 ou la .NET
Framework 3.5 sur l’ordinateur. Vous trouverez les liens d’installation pour le .NET Framework Q6.
T10 : après avoir cliqué sur le bouton « Exécuter » pour exécuter un

diagnostic sur un ordinateur Windows Server, vous recevez un
message d’erreur « Vos paramètres de sécurité actuels n’autorisent
pas le téléchargement de ce fichier » et le diagnostic ne s’exécute pas
Cette erreur peut se produire si la configuration de sécurité renforcée d’Internet Explorer est activée sur
l’ordinateur. Suivez les instructions du T12 pour exécuter le diagnostic sur un ordinateur sur qui la configuration
de sécurité renforcée d’Internet Explorer est activée.
T11 : lorsque vous cliquez sur le bouton « Exécuter » pour exécuter

un diagnostic sur un ordinateur Windows Server, seules les options «
Enregistrer » et « Annuler » sont disponibles.
Ce problème peut se produire si l’option « Ne pas enregistrer les pages chiffrées sur le disque » est définie dans
Options Internet. Lorsque « Configuration de sécurité renforcée d’Internet Explorer » est activée sur un
ordinateur Windows serveur, cette option est automatiquement définie.
Pour exécuter un diagnostic sur un ordinateur avec cette option activée, enregistrez le fichier, puis exécutez le
diagnostic à partir du dossier de téléchargement. Pour désactiver l’option, ouvrez « Internet Paramètres »,
sélectionnez l’onglet « Avancé », puis désactivez la case à cocher « Ne pas enregistrer les pages chiffrées sur le
disque » sous « Sécurité ».
T12 : lorsque vous cliquez sur le bouton « Exécuter » pour exécuter

un diagnostic, vous recevez un message d’erreur « Nous sommes
désolés, mais une erreur s’est produite : les cookies ne sont pas
activés dans votre navigateur ou ont été supprimés »
Ce problème peut se produire si les cookies sont désactivés dans le navigateur. Pour résoudre ce problème,
activez les cookies dans votre navigateur et actualisez la page. Pour activer les cookies dans Internet Explorer,
sélectionnez « Options Internet », sélectionnez l’onglet « Confidentialité », puis sélectionnez « Par défaut » sous «
Paramètres » pour déplacer le curseur vers le paramètre « Moyen ».
Une autre raison possible de cette erreur est que « Configuration de sécurité renforcée » est activée sur un
ordinateur Windows Server, mais que tous les sites répertoriés au T12 n’ont pas été ajoutés à la liste des sites de
sécurité. Pour résoudre ce problème, suivez les instructions du T12. Vous pouvez également exécuter
l’dépannage disponible dans T2 pour identifier rapidement les problèmes de « Configuration de sécurité
renforcée ».
Informations collectées par le collecteur de
diagnostics SQL RS
Cet article décrit les informations qui peuvent être collectées à partir d’un ordinateur lorsque l’outil SQL RS
Diagnostics Collector est en cours d’exécution.
Version du produit d’origine : Microsoft SQL Server 2012, SQL Server 2008, SQL Server 2008 R2, SQL Server
2005
Résumé
Le SQL RS Diagnostics Collector pour Windows Server 2003 R2, Windows Vista, Windows Server 2008,
Windows Server 2008 R2, Windows 7, Windows 8, Windows 8.1, Windows Server 2012 et Windows Server
2012 R2 collectent des informations de diagnostic utiles pour résoudre un grand nombre de problèmes qui
impliquent le SQL Server Reporting Services (SSRS). Ce collecteur est utilisé pour collecter des informations
pour le mode natif et le mode SharePoint SSRS.
Le SQL RS Diagnostics Collector prend en charge les versions suivantes de SQL Server :
SQL Server 2005
SQL Server 2008
SQL Server 2008 R2
SQL Server 2012
d’exploitation de l’ordinateur de destination. Le package de diagnostic vérifie automatiquement si ces conditions
préalables sont requises sur votre ordinateur, puis démarre si les éléments prérequis sont déjà installés. Si les
conditions préalables ne sont pas déjà disponibles sur l’ordinateur, vous êtes invité à les installer. Le service de
dépannage automatisé (MATS) peut également installer les logiciels requis pour vous. Par exemple, si Windows
PowerShell n’est pas présent sur l’ordinateur de destination, MATS l’installe automatiquement. Pour plus
d’informations, consultez les informations sur les services de dépannage automatisés de Microsoft et la
plateforme de diagnostic du support technique.

Vous devez avoir des droits d’administration sur l’ordinateur à partir duquel vous exécutez le SQL RS
Diagnostics Collector.
Étapes impliquées
Le SQL RS Diagnostics Collector doit être exécuté manuellement sur tous les ordinateurs impliqués dans la
configuration SSRS. Par exemple, si le SSRS est un déploiement de mise à l’échelle, le collecteur de diagnostics
RS SQL doit être exécuté manuellement sur tous les ordinateurs impliqués dans la configuration de mise à
l’échelle. De même, sur un mode SharePoint intégré, le SQL RS Diagnostics Collector doit être exécuté sur
SharePoint.
Le SQL RS Diagnostics Collector découvre toutes les instances des services de rapports installés sur l’ordinateur
sur lequel l’outil de diagnostic est exécuté. Dans le cadre du processus de collecte de données, le collecteur de
diagnostics SQL RS tente de se connecter à chaque serveur de base de données de catalogue SSRS auquel les
instances SSRS se connectent, puis collecte des informations à partir de la base de données de catalogue
ReportServer. Les connexions de base de données sont réalisées à l’aide Windows’authentification unique. Pour
démarrer le collecteur de diagnostics SQL RS, vous devez avoir une Windows qui est membre du rôle serveur
fixe sysadmin.
SharePoint sécurité requise

Le SQL RS Diagnostics Collector découvre toutes les instances des services de rapports installés sur l’ordinateur.
Si l’ordinateur héberge uniquement le logiciel SharePoint intégré au SSRS, le collecteur de diagnostics SQL RS
collecte des informations sur la configuration du SharePoint, les sites web installés, etc. Pour exécuter le
collecteur de diagnostics SQL RS, vous devez avoir une Windows qui est membre du groupe d’administrateurs
sur l’ordinateur.
Informations collectées par le collecteur de diagnostics SQL RS

Journal des événements système
NOTE
Le SQL RS Diagnostics Collector collecte les événements des 30 jours précédents.
Journal des événements système aux formats TXT, CSV <COMPUTER_NAME> _ evt_System.csv
et EVT ou EVTX <COMPUTER_NAME> _ evt_System.txt
<COMPUTER_NAME> _ evt_System. (evt ou evtx)
Journal des événements de l’application
NOTE
Le SQL RS Diagnostics Collector collecte les événements des 30 jours précédents.
Journal des événements de l’application aux formats TXT, <COMPUTER_NAME> _evt_Application.csv

CSV et EVT ou EVTX <COMPUTER_NAME> _ evt_Application.txt
<COMPUTER_NAME> _evt_Application. (evt ou evtx)
Informations de Registre liées à la configuration des ser vices de rappor ts

Collectez la clé de Registre et les clés enfants sous <COMPUTER_NAME> _RS_Registry.XML

HKLM:\System\CurrentControlSet\Services\TCPIP\Parameters
.
Collectez la clé de Registre et les clés enfants sous <COMPUTER_NAME> _RS_Registry.XML

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
.
Informations de tous les ser vices installés sur l’ordinateur de destination
Collectez des informations sur les services installés sur <COMPUTER_NAME> _MiscProperties.XML
l’ordinateur de destination.
Informations provenant des journaux ULS de l’instance SharePoint sur l’ordinateur de

destination
Collectez les journaux ULS à partir du SharePoint installé <COMPUTER_NAME>.<INSTANCE_NAME> _Date.log

sur l’ordinateur de destination.
Informations provenant des journaux SSRS de toutes les instances SSRS sur l’ordinateur de
destination
Collectez les journaux SSRS à partir des instances SSRS <COMPUTER_NAME>.<INSTANCE_NAME>

installées sur l’ordinateur de destination. _ReportServerService_GUID.log
Informations provenant du fichier de Repor tSer ver.Config SSRS de toutes les instances
SSRS sur l’ordinateur de destination
Collectez leRSReportServer.Config à partir des instances <COMPUTER_NAME>.<INSTANCE_NAME>

SSRS installées sur l’ordinateur de destination. _RSReportserver.config
Informations du fichier Web.config de toutes les instances SSRS sur l’ordinateur de

destination
Collectez leWeb.config à partir des répertoires <COMPUTER_NAME>.<INSTANCE_NAME> _web.config

ReportServer et ReportManager à partir de toutes les
instances SSRS installées sur l’ordinateur de destination.
Informations de la configuration SSRS pour toutes les instances SSRS sur l’ordinateur de
destination
Collectez les informations de configuration stockées dans <COMPUTER_NAME>.<INSTANCE_NAME>

la base de données du catalogue SSRS pour toutes les ConfigInfo.XML
Informations provenant des informations d’exécution pour toutes les instances SSRS sur
l’ordinateur de destination
Collectez les informations d’exécution stockées dans la <COMPUTER_NAME>.<INSTANCE_NAME>

base de données du catalogue SSRS pour toutes les ExecutionInfo.XML
Informations de la configuration SPN pour toutes les instances SSRS sur l’ordinateur de
destination
Collectez les informations de configuration SPN pour le <COMPUTER_NAME> _RS_SPN.XML

compte de service SSRS qui exécute l’instance SSRS. (si le
serveur est en cours d’SharePoint)
Informations des journaux d’erreur HTTP sur l’ordinateur de destination
Collectez les journaux d’erreur HTTP sur l’ordinateur de <COMPUTER_NAME>.httperrX.log

destination.
Informations des journaux HTTP pour toutes les instances SSRS sur l’ordinateur de
destination
Collectez les journaux HTTP qui sont générés si l’attribut <COMPUTER_NAME>.<INSTANCE_NAME> _Http.log
est mis enReportserver.configSSRS.
S’applique à
SQL Server Web 2012
SQL Server Web 2008
SQL Server Configurer l’outil de diagnostic de
collecte de données
Cet article décrit les informations qui peuvent être collectées à partir d’un ordinateur lorsque l’outil SQL Server
de diagnostic de collecte de données du programme d’installation est en cours d’exécution.
Résumé
Le collecteur de données d’installation SQL Server pour Windows 7, Windows Server 2008 R2, Windows 8,
Windows Server 2012, Windows 8.1 et Windows Server 2012 R2 collecte des informations de diagnostic utiles
pour résoudre les problèmes d’installation pour Microsoft SQL Server 2008, SQL Server 2008 R2 et SQL Server
2012.
SQL Server sont classées en tant que fonctionnalités d’instance ou en tant que fonctionnalités partagées.
Fonctionnalités d’instance
Les fonctionnalités d’instance sont les suivantes :
Moteur de base de données Fonctionnalités (Réplication SQL Server, recherche d’extractions de texte intégral
et sémantique, services de qualité des données)
Analysis Services
Reporting Services - Natif
Fonctionnalités partagées
Les fonctionnalités partagées sont les suivantes :
Reporting Services : SharePoint
Reporting Services Add-in for SharePoint Products
Business Intelligence Development Studio
Connectivité des outils clients
Compatibilité ascendante des outils clients
SDK Outils clients
SQL Server Livres en ligne
Outils de gestion - De base (outils de gestion - Complet)
SQL SDK de connectivité client
Microsoft Sync Framework
Data Quality Client
Master Data Services
Contrôleur de relecture distribuée
Client de relecture distribuée
Le SQL Server collecte de données d’installation est pris en compte dans le cluster et collecte des informations
spécifiques au cluster lorsque le collecteur de données d’installation SQL Server est exécuté sur une instance en
cluster de SQL Server. Lorsque vous dépanner un échec d’installation qui s’est produit sur un cluster Windows,
le collecteur de données d’installation SQL Server doit être exécuté sur le nœud du cluster auquel l’échec de
l’installation s’est produit. Pour résoudre plusieurs échecs d’installation sur plusieurs nœuds qui sont joints au
même cluster, le collecteur de données d’installation SQL Server doit être exécuté sur chaque nœud sur lequel
l’échec s’est produit.
Le SQL Server de données du programme d’installation doit être exécuté dans le contexte de sécurité du compte
qui a été utilisé pour exécuter le programme d’installation. En outre, le SQL Server de données du programme
d’installation doit être exécuté par un utilisateur qui dispose de droits d’administration sur l’ordinateur sur lequel
le collecteur de données sera exécuté.
Tous les journaux des événements
Journal système - Format Evtx ComputerName _System.evtx
Journal des applications - Format Evtx ComputerName _Application.evtx
Journal de sécurité - Format Evtx ComputerName _Security.evtx
FailoverClustering-Operational - Format Evtx ComputerName _FailoverClustering-Operational.evtx
NOTE
Les journaux d’événements de clustering de percevoir le clustering de percevoir sont collectés uniquement sur les
serveurs sur qui le clustering de failover est configuré.
Informations de Registre relatives au Gestionnaire de session et au débogage
Collecter la clé de Registre - ComputerName _ _Recovery_Registry.TXT

HKLM\Software\Microsoft\Windows
NT\CurrentVersion\AEDebug
Collecter la clé de Registre - ComputerName __Recovery_Registry.TXT

HKLM\Software\Microsoft\DrWatson

HKLM\System\CurrentControlSet\Services\i8042prt\Parameters
Collecter la clé de Registre - ComputerName __Recovery_Registry.TXT

HKLM\System\CurrentControlSet\Control

HKLM\System\CurrentControlSet\Control\Session
Manager
Fichiers journaux dr Watson existants, rappor ts de vidage de mémoire et fichiers
Rapport de vidage mémoire ComputerName _DumpReport.htm
Rapport de vidage mémoire ComputerName _ DumpReport.txt
Fichier de vidage mémoire (minidumps) Nom_ordinateur DMP{Date}.zip
Informations sur tous les ser vices installés sur le système d’exploitation
Collecter des informations sur tous les services de ComputerName _SC_Services_Output.txt

système d’exploitation
Informations sur tous les pilotes de filtre actifs sur l’ordinateur
Informations sur les filtres supérieur et inférieur qui ComputerName _ FltrFind.txt

utilisent fltrfind.exe utilitaire
Informations sur tous les processus et détails du pilote en cours d’exécution, ainsi que leurs
versions de fichiers
%programfiles%\*.sys ComputerName _sym_ProgramFiles_SYS.CSV
%programfiles%\*.sys ComputerName _sym_ProgramFiles_SYS.TXT
%windir%\system32\drivers\*.* ComputerName _sym_Drivers.CSV
%windir%\system32\drivers\*.* ComputerName _sym_Drivers.TXT
%windir%\system32\*.exe ComputerName _sym_System32_exe.CSV
%windir%\system32\*.exe ComputerName _sym_System32_exe.TXT
%windir%\system32\*.sys ComputerName _sym_System32_sys.CSV
%windir%\system32\*.sys ComputerName _sym_System32_sys.TXT
Processus en cours d’exécution ComputerName _sym_Process.CSV

Processus en cours d’exécution ComputerName _sym_Process.TXT
Exécution de pilotes ComputerName _sym_RunningDrivers.CSV
Exécution de pilotes ComputerName _sym_RunningDrivers.TXT
Informations relatives aux performances pour le système d’exploitation
Informations de base sur le processeur système ComputerName _ Processor_Details.txt
Informations sur les performances du processeur ComputerName _ OS_Perf_Details.txt

système
Statistiques de performances du système ComputerName _ OS_Perf_Statistics.txt
Informations sur la configuration réseau de l’ordinateur
Informations de base sur TCP/IP ComputerName _TcpIp-Info.txt
Informations de base sur SMB ComputerName _SMB-Info.txt
Sor tie de l’utilitaire NetDiag
Sortie de diagnostic réseau qui utilise l’utilitaire ComputerName _NetDiag.txt

NetDiag.exe réseau
NOTE
NetDiag est un outil de diagnostic qui permet d’isoler les problèmes de réseau et de connectivité en effectuent
une série de tests pour déterminer l’état du client réseau.
Informations sur Windows tâches programmées configurées sur l’ordinateur
Liste des tâches programmées ComputerName _schtasks.csv
Liste des tâches programmées ComputerName _schtasks.txt

Données de configuration de démarrage de l’ordinateur
Sortie de lBcdedit.exe utilitaire ComputerName _BCDEdit.txt
Sortie de lBcdedit.exe utilitaire ComputerName _BCD-Backup.bak
Informations de maintenance de l’ordinateur
Component-Based journaux de maintenance situés à Nom_ordinateur _CBS * .log

l’emplacement %windir%\Logs\CBS
Journal DPX Setup Act situé à l’emplacement ComputerName _setupact.log

%windir%\logs\DPX
Journal Exec de la file d’attente des opérations en attente ComputerName _poqexec.log

qui se trouve à l’emplacement %windir%\winsxs
Windows Journal en attente en attente côte à côte situé ComputerName _pending.xml.bad

à l’emplacement %windir%\ winsxs
Windows Journal en attente côte à côte situé à ComputerName _pending.xml

l’emplacement %windir%\ winsxs
Journaux SetupAPI du système d’exploitation
Journaux SetupAPI situés dans le %windir%\inf dossier ComputerName _SetupApi.app.log
ComputerName _SetupApi.evt.log
ComputerName _SetupApi.offline.log
ComputerName _SetupApi.Dev.log
Informations sur tous les correctifs logiciels appliqués sur l’ordinateur
Mises à jour et correctifs installés ComputerName _Hotfixes.CSV
ComputerName _Hotfixes.Txt
ComputerName _Hotfixes.HTM
Sauvegarde de CurrentControlSet et des ruches SQL Ser ver registre

HKLM\System\CurrentControlSet\SessionManagers ComputerName _CurrentControlSet_Reg.txt
HKLM\SYSTEM\CurrentControlSet\Control\Lsa ComputerName _CurrentControlSet_Reg.txt
HKLM\SYSTEM\CurrentControlSet ComputerName _CurrentControlSet.Hiv
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\MSSQLServer ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server ComputerName _REG_SQL.TXT

2005 Redist
HKLM\Software\Microsoft\MSFTESQLInstMap ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\Microsoft SQL Native ComputerName _REG_SQL.TXT

Client
HKLM\SOFTWARE\Microsoft\OLAP Server ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\SNAC ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\SQLXML4 ComputerName _REG_SQL.TXT
HKLM\Software\Microsoft\Vsa ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\ODBC ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\MSDTS ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\MSXML 6.0 Parser and SDK ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\MSXML60 ComputerName _REG_SQL.TXT
HKCU\Software\Microsoft\Microsoft SQL Server ComputerName _REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server ComputerName _Microsoft_SQL_Server.HIV
Sor tie de MSINFO32
Rapport System Information Microsoft ComputerName _MSINFO32. NFO
ComputerName _MSINFO32.TXT
Sor tie de l’utilitaire PStat

PStat.exe sortie ComputerName _Pstat.txt
NOTE
PStat est un outil basé sur des caractères qui répertorie tous les threads en cours d’exécution et affiche leur état.
Sauvegarde des clés de Registre liées au cluster
C L É DU REGIST RE N O M DE F IC H IER
HKLM\Software\Microsoft\Windows ComputerName _reg_CurrentVersion.TXT

NT\CurrentVersion
HKLM\Software\Microsoft\Windows\CurrentVersion
ComputerName _reg_Uninstall.TXT
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions ComputerName _reg_ProductOptions.TXT
HKLM\System\MountedDevices ComputerName _reg_MountedDevices.*
HKLM\System\CurrentControlSet\Control\CrashControl ComputerName _reg_Recovery.TXT

Manager
Manager\Memory Management
NT\CurrentVersion\AeDebug
HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Image File Execution Options
HKLM\Software\Microsoft\Windows\Windows Error
Reporting
HKLM\Software\Policies\Microsoft\Windows\Windows
Error Reporting
HKCU\Software\Microsoft\Windows\CurrentVersion\Run ComputerName _reg_Startup.TXT

HKCU\Software\Microsoft\Windows\CurrentVersion\Runonce
HKCU\Software\Microsoft\Windows\CurrentVersion\RunonceEx
HKCU\Software\Microsoft\Windows\CurrentVersion\RunServices
HKCU\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\
Software\Microsoft\Windows\CurrentVersion\Run
HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce
HKLM\Software\Microsoft\Windows\CurrentVersion\RunonceEx
HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices
HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad
HKCU\Software\Microsoft\Windows
NT\CurrentVersion\Load
HKCU\Software\Microsoft\Windows
NT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
NT\CurrentVersion\Winlogon\UserInit
C L É DU REGIST RE N O M DE F IC H IER
HKLM\SYSTEM\CurrentControlSet\Control\Print ComputerName _reg_Print.HIV
HKCU\Software\Policies ComputerName _reg_Policies.txt

HKLM\Software\Policies
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
ComputerName _reg_TimeZone.txt
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
NT\CurrentVersion\Time Zones
HKLM\SYSTEM\CurrentControlSet\Control\Terminal ComputerName _reg_TermServices.txt

Server
NT\CurrentVersion\Terminal Server
NT\CurrentVersion\Terminal Server Web Access
HKLM\SYSTEM\CurrentControlSet\Services\TermService
HKLM\SYSTEM\CurrentControlSet\Services\TermDD
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer ComputerName _reg_SMB.txt

HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation
HKLM\SYSTEM\CurrentControlSet\Services\MRxSmb
HKLM\SYSTEM\CurrentControlSet\Services\SMB
HKLM\SYSTEM\CurrentControlSet\Services\MRxSmb10
HKLM\SYSTEM\CurrentControlSet\Services\MRxSmb20
ComputerName _reg_TCPIPParameters
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
HKLM\SYSTEM\CurrentControlSet\Services\VSS ComputerName _reg_VSS.TXT
HKLM\SYSTEM\CurrentControlSet\Services\iScsiPrt ComputerName _reg_iSCSI.TXT

HKLM\SOFTWARE\Microsoft\iSCSI Target
NT\CurrentVersion\iSCSI
HKLM\System\CurrentControlSet\Control\MPDev ComputerName _reg_Storage.TXT

HKLM\System\CurrentControlSet\Control\iSCSIPrt
HKLM\System\CurrentControlSet\Services\MSiSCSI
HKLM\System\CurrentControlSet\Services\MSDsm
HKLM\System\CurrentControlSet\Services\MPIO
HKLM\System\CurrentControlSet\Control\Class\
{4d36e97b-e325-11ce-bfc1-08002be10318}
HKLM\System\CurrentControlSet\Services\Tcpip
HKLM\SYSTEM\CurrentControlSet\Enum ComputerName _reg_Enum.TXT
HKLM\System\CurrentControlSet\services\ClusSvc ComputerName _reg_ClusSvc.TXT

HKLM\System\CurrentControlSet\services\CluDisk
HKLM\Cluster ComputerName _Cluster.hiv

NOTE
Ces informations sont collectées si l SQL Server de diagnostic de collecte de données du programme d’installation
détecte que l’ordinateur sur lequel l’outil est en cours d’exécution est un cluster.
Informations de base sur Windows cluster de failover

Les données collectées sont les suivantes :
Journaux de cluster
Informations de volume partagées
Propriétés des ressources de cluster
Dossier rapports de cluster
Dépendance aux ressources de cluster
Rapport de validation de cluster
Journaux de cluster générés par Get-ClusterLog ComputerName _Cluster.Log

Windows PowerShell cmdlet
Sortie de l’outil MPS de cluster (clusmps.exe) ComputerName _Cluster_MPS_Information.txt
Fichiers de rapports de validation de cluster situés à ComputerName _ * .mht

l’emplacement \Windows\Cluster\Reports\*.mht
Cluster reports XML files that are located at ComputerName _ *.xml

\Windows\Cluster\Reports\*.xml
Fichiers journaux de validation de cluster à partir de Nom_ordinateur _Validade * .log

\Windows\Cluster\Reports\Validate*.log
Propriétés des ressources de cluster qui utilisent la ComputerName _ClusterProperties.txt

cmdlet Windows PowerShell Get-ClusterResource cluster
Rapport de dépendance de cluster généré par la cmdlet ComputerName _DependencyReport.mht

Get-ClusterResourceDependencyReport Windows
PowerShell cluster
Informations sur le volume partagé de cluster - format ComputerName _CSVInfo.htm

HTML
Rapport de validation de base du cluster généré par la ComputerName _ValidationReport.mht

cmdlet Test-Cluster Windows PowerShell cluster
NOTE
Ces informations sont collectées si l SQL Server de diagnostic de collecte de données du programme d’installation
détecte que l’ordinateur sur lequel l’outil est en cours d’exécution est un cluster.
Informations sur SQL Ser ver instances installées sur l’ordinateur

Informations du programme d’installation MSI SQL ComputerName _FindSQLInstalls.txt

Server produits
Informations sur les por ts TCP/IP utilisés sur l’ordinateur
Informations d’utilisation des ports TCP/IP ComputerName _PortUsage.txt
Informations sur les attributions de droits d’utilisateur
Attributions de droit d’utilisateur local ComputerName _userrights.txt
Sauvegarde du dossier Setup Bootstrap pour SQL Ser ver installations
Répertoire compressé ComputerName _SQL90_Bootstrap.Cab

%programfiles%\ Microsoft SQL Server\90\Setup
Bootstrap\Log

Bootstrap\Log

Bootstrap\Log
SQL Ser ver ’erreurs pour toutes les instances de SQL Ser ver installées sur l’ordinateur
instances installées sur l’ordinateur sur lequel l’outil de ComputerName _ instance_name _.errorlog
diagnostic est exécuté. Le nombre de fichiers collectés Instance par défaut :
est déterminé par le nombre de journaux d’erreurs ComputerName MSSQLSERVER.errorlog
existant sur le système de fichiers.
NOTE
L’outil de diagnostic de collecte de données d’installation de SQL Server collecte les journaux d’erreurs pour une
instance en cluster uniquement si le lecteur partagé qui stocke le journal des erreurs appartient actuellement au
serveur sur lequel l’utilitaire est exécuté.
Outre les fichiers collectés et répertoriés ici, cet dépanneur peut détecter une ou plusieurs des situations
suivantes :
L’ordinateur est en cours d’exécution dans un environnement virtuel.
Le service de cluster d’un nœud FailoverCluster n’est pas en cours d’exécution.
L’état d’un des nodes de cluster est hors connexion.
L’un des groupes de clusters est hors connexion.
Il existe un problème lors de l’obtention d’informations de cluster.
S’applique à
SQL Server Web 2008
SQL Collecteur de diagnostics de base pour
Windows Server
Cet article décrit les informations qui peuvent être collectées à partir d’un ordinateur lorsque l’outil SQL Base
Diagnostics Collector est en cours d’exécution.
Résumé
Le collecteur SQL diagnostics de base pour Windows Server collecte des informations de diagnostic utiles pour
résoudre un grand nombre de problèmes qui impliquent le moteur Microsoft SQL Server de diagnostic. Le
collecteur SQL diagnostics de base collecte également des informations de diagnostic limitées pour SQL Server
Analysis Services.
Le SQL de diagnostics de base prend en charge SQL Server et SQL Server Analysis Services.
d’exploitation de l’ordinateur cible. Le diagnostic vérifie automatiquement si ces conditions préalables sont
requises sur votre ordinateur et commence à s’exécuter s’ils sont déjà installés. Sinon, vous êtes invité à installer
les conditions préalables si elles ne sont pas déjà disponibles sur l’ordinateur. Le service de dépannage
automatisé de Microsoft (MATS) peut également installer les logiciels requis pour vous. Par exemple, si Windows
PowerShell n’est pas présent sur l’ordinateur cible, MATS l’installe automatiquement. Pour plus d’informations,
consultez les informations sur les services de dépannage automatisés de Microsoft et la plateforme de
diagnostic du support technique.

Le SQL Server de diagnostics de base doit être exécuté par un utilisateur qui dispose de droits d’administration
sur l’ordinateur sur lequel le collecteur SQL diagnostics de base est exécuté.

Le SQL de diagnostics de base découvre toutes les instances de SQL Server installées sur l’ordinateur sur lequel
l’outil de diagnostic est exécuté. Dans le cadre du processus de collecte de données, le collecteur de diagnostics
de base SQL essaiera de se connecter à chaque instance de SQL Server que l’outil de diagnostic découvrira pour
collecter des informations sur la configuration SQL Server actuelle et l'« état » du serveur. Les connexions de
base de données sont réalisées à l’aide Windows’authentification unique. L’utilisateur qui exécute le collecteur de
diagnostics de base SQL doit avoir une Windows qui est membre du rôle serveur fixe sysadmin pour que les
tâches de collecte de diagnostics suivantes réussissent :
SQL Server Collection de configurations AlwaysOn
Scripts de collecte de données SQLDIAG
Prise en charge Windows clusters de failover

Le SQL de diagnostics de base est pris en compte dans le cluster et collecte des informations spécifiques au
cluster lorsque l’outil de diagnostic est exécuté sur un cluster de Windows Server.
Pour diagnostiquer les SQL Server de groupe de disponibilité AlwaysOn ou les changements de ressources de
cluster SQL Server, vous de devez exécuter le collecteur de diagnostics de base SQL sur plusieurs nœuds de
cluster pour collecter toutes les informations de dépannage nécessaires :
Exécutez le collecteur SQL diagnostic de base sur le nœud de cluster qui possède actuellement le groupe
de disponibilité AlwaysOn SQL Server ou la ressource de cluster SQL Server qui SQL Server connu le
percepteur. Cela est nécessaire car les informations collectées pour SQL Server et SQL Server AlwaysOn
résident sur la ressource de disque de cluster et sont rerouées avec le groupe de disponibilité AlwaysOn
ou la ressource de cluster SQL Server vers le nouveau nœud propriétaire.
Exécutez le SQL de diagnostic de base sur le nœud où l’échec s’est produit. Cela active la collection du
journal du cluster à partir du nœud du cluster où l’échec s’est produit.
Journal des événements système
NOTE
Le SQL de diagnostics de base collecte les événements des 30 derniers jours.
Journal des événements système aux formats TXT, CSV <COMPUTER_NAME>_ evt_System.csv
et EVT ou EVTX <COMPUTER_NAME>_ evt_System.txt
<COMPUTER_NAME>_ evt_System. (evt ou evtx)
Journal des événements de l’application
NOTE
Le SQL de diagnostics de base collecte les événements des 30 derniers jours.
Journal des événements de l’application aux formats TXT, <COMPUTER_NAME>_ evt_Application.csv

CSV et EVT ou EVTX <COMPUTER_NAME>_ evt_Application.txt
<COMPUTER_NAME>_ evt_Application. (evt ou evtx)
Informations du Registre relatives au Gestionnaire de session et au débogage
Collecter la clé de Registre - <COMPUTER_NAME>_Recovery_Registry.txt

NT\CurrentVersion\AEDebug

HKLM\Software\Microsoft\DrWatson

HKLM\System\CurrentControlSet\Services\i8042prt\Para
meters

HKLM\System\CurrentControlSet\Control

Manager
Fichiers journaux Dr Watson existants et Windows d’erreur signalant des vidages mémoire pour SQL
Server processus
Rapport qui contient des informations sur les vidages <COMPUTER_NAME>_DumpReport.htm

mémoire et sur les paramètres de l’ordinateur liés aux <COMPUTER_NAME>_DumpReport.txt
vidages de mémoire aux formats htm et txt
Windows’erreur signalant des fichiers de vidage mémoire <COMPUTER_NAME> DMP(Date).zip

pour SQL Server processus de 30 jours maximum et
inférieur ou égal à 25 Mo
Informations sur tous les services installés sur l’ordinateur de destination
Collecter des informations sur les services installés sur <COMPUTER_NAME>_SC_Services_Output.txt

l’ordinateur cible
Informations sur les pilotes de filtre installés sur l’ordinateur de destination
Pilotes de filtre supérieur et inférieur, éumés par <COMPUTER_NAME> _FltrFind.txt

l’utilitaire fltrfind.exe de recherche
Rapport des pilotes de mini-filtre
Éumer les pilotes de mini-filtre à l’aide de Fltmc.exe <COMPUTER_NAME>_Fltmc.TXT

Informations sur tous les processus et détails du pilote en cours d’exécution, ainsi que leurs versions de
fichiers
%programfiles% *.sys <COMPUTER_NAME>_sym_ProgramFiles_SYS.CSV
%programfiles% *.sys <COMPUTER_NAME>_sym_ProgramFiles_SYS.TXT
Exécution des pilotes <COMPUTER_NAME>_sym_RunningDrivers.CSV
Exécution des pilotes <COMPUTER_NAME>_sym_RunningDrivers.TXT
%windir%\system32\drivers * .* <COMPUTER_NAME>_sym_Drivers.CSV
%windir%\system32\drivers * .* <COMPUTER_NAME>_sym_Drivers.TXT
%SystemRoot%\System32\iscsi . <COMPUTER_NAME>_sym_MS_iSCSI.CSV
%SystemRoot%\System32\iscsi . <COMPUTER_NAME> _sym_MS_iSCSI.TXT*
Processus en cours d’exécution <COMPUTER_NAME>_sym_Process.CSV
Processus en cours d’exécution <COMPUTER_NAME>_sym_Process.TXT
%SystemRoot%\System32 *.DLL <COMPUTER_NAME>_sym_System32_DLL.CSV
%SystemRoot%\System32 *.DLL <COMPUTER_NAME>_sym_System32_DLL.TXT*
%SystemRoot%\System32 *.EXE <COMPUTER_NAME>_sym_System32_EXE.CSV
%SystemRoot%\System32 *.EXE <COMPUTER_NAME>_sym_System32_EXE.TXT
%SystemRoot%\System32 *.SYS <COMPUTER_NAME>_sym_System32_SYS.CSV
%SystemRoot%\System32 *.SYS <COMPUTER_NAME>_sym_System32_SYS.TXT
%SystemRoot%\SysWOW64 *.dll <COMPUTER_NAME>_sym_SysWOW64_DLL.CSV
%SystemRoot%\SysWOW64 *.dll <COMPUTER_NAME>_sym_SysWOW64_DLL.TXT
%SystemRoot%\SysWOW64 *.exe <COMPUTER_NAME>_sym_SysWOW64_EXE.CSV
%SystemRoot%\SysWOW64 *.exe <COMPUTER_NAME>_sym_SysWOW64_EXE.TXT
%SystemRoot%\SysWOW64 *.sys <COMPUTER_NAME>_sym_SysWOW64_SYS.CSV
%SystemRoot%\SysWOW64 *.sys <COMPUTER_NAME>_sym_SysWOW64_SYS.TXT
Informations liées aux performances capturées à partir de l’ordinateur de destination

Capture perfmon de base d’une minute des <COMPUTER_NAME>_Performance Counter.blg

performances système globales d’Windows Server 2008
et versions ultérieures
Capture perfmon de base d’une minute des <COMPUTER_NAME>Perfmon(DateAndTime).blg

performances système globales à partir de Windows
Server 2003
Rapport de performances système généré à partir du <COMPUTER_NAME>_report.html

journal de perfmon collecté
Informations sur la configuration réseau de l’ordinateur de destination
Ce rapport produit le nombre de ports TCP locaux <COMPUTER_NAME>_PortUsage.txt

uniques utilisés (au-dessus du port de départ) pour
chaque adresse IP et processus sur l’ordinateur cible.
Informations de base sur SMB <COMPUTER_NAME>_SMB-Info.txt
Informations de base sur TCP/IP <COMPUTER_NAME>_TcpIp-Info.txt
Fichier DNS Client Hosts <COMPUTER_NAME>_DnsClient_HostsFile.TXT
Sortie de commande IPCONFIG /DISPLAYDNS <COMPUTER_NAME>_DnsClient_ipconfig-

displaydns.TXT
Sortie de commande NETSH DBNLIENT SHOW STATE <COMPUTER_NAME>_DnsClient_netsh_dnsclient-show-

state.TXT
> [!NOTE]
> cette commande non valide sur Windows Server 2003
Entrées de Registre client DNS <COMPUTER_NAME>DnsClient_reg.TXT
Liste des mises à jour installées sur l’ordinateur de destination
Liste des mises à jour installées sur l’ordinateur cible au <COMPUTER_NAME>_Hotfixes.CSV

format CSV, TXT et HTM <COMPUTER_NAME>_Hotfixes.TXT
<COMPUTER_NAME>_Hotfixes.HTM
Informations sur les tâches programmées configurées sur l’ordinateur de destination
Liste de tâches programmées au format CSV et TXT <COMPUTER_NAME>_schtasks.csv

<COMPUTER_NAME>_schtasks.txt
Données de configuration de démarrage pour l’ordinateur de destination
Sortie de Bcdedit.exe <COMPUTER_NAME>_BCDEdit.TXT
> [!NOTE]
> collecté uniquement à partir de Windows 7, Windows
Server 2008 R2, Windows Server 2008 et Windows Vista
Sortie de Bcdedit.exe <COMPUTER_NAME>_BCD-Backup.BKP
> [!NOTE]
> collecté uniquement à partir de Windows 7, Windows
Server 2008 R2, Windows Server 2008 et Windows Vista
Boot.ini <COMPUTER_NAME>_Boot.ini
> [!NOTE]
> collecté uniquement sur Windows Server 2003
Fichiers de sauvegarde du Registre et de vidage de texte de CurrentControlSet SQL Server ruches du

Registre
HKLM\System\CurrentControlSet\SessionManagers <COMPUTER_NAME> _CurrentControlSet_Reg.txt
HKLM\SYSTEM\CurrentControlSet\Control\Lsa <COMPUTER_NAME> _CurrentControlSet_Reg.txt
HKLM\SYSTEM\CurrentControlSet <COMPUTER_NAME> _CurrentControlSet_Reg.hiv
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\MSSQLServer <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server 2005 <COMPUTER_NAME>_REG_SQL.TXT

Redist
HKLM\Software\Microsoft\MSFTESQLInstMap <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\Microsoft SQL Native Client <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\OLAP Server <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\SNAC <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\SQLXML4 <COMPUTER_NAME>_REG_SQL.TXT
HKLM\Software\Microsoft\Vsa <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\ODBC <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\MSDTS <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\MSXML 6.0 Parser et SDK <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\MSXML60 <COMPUTER_NAME>_REG_SQL.TXT
HKCU\Software\Microsoft\Microsoft SQL Server <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server <COMPUTER_NAME>_REG_SQL.TXT
HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft <COMPUTER_NAME>_Wow6432Node_REG_SQL.TXT
SQL Server
HKLM\SOFTWARE\Wow6432Node\Microsoft\MSSQLSer <COMPUTER_NAME>_Wow6432Node_REG_SQL.TXT
ver
SQL Server 2005 Redist
SQL Native Client
SQL Native Client 10.0
HKLM\SOFTWARE\Wow6432Node\Microsoft\SNAC <COMPUTER_NAME>_Wow6432Node_REG_SQL.TXT
HKLM\SOFTWARE\Wow6432Node\Microsoft\SQLXML4 <COMPUTER_NAME>_Wow6432Node_REG_SQL.TXT
HKLM\Software\Wow6432Node\Microsoft\Vsa <COMPUTER_NAME>_Wow6432Node_REG_SQL.TXT
HKLM\SOFTWARE\Wow6432Node\ODBC <COMPUTER_NAME>_Wow6432Node_REG_SQL.TXT
HKLM\SOFTWARE\Wow6432Node\Microsoft\MSDTS <COMPUTER_NAME>_Wow6432Node_REG_SQL.TXT
Sauvegarde de HKLM\SOFTWARE\Microsoft\Microsoft <COMPUTER_NAME>_Microsoft_SQL_Server.HIV

SQL Server au format HIV
Sortie de l’utilitaire PSTAT
Sortie de PSTAT.EXE <COMPUTER_NAME>_PStat.txt
Windows de pare-feu
Windows Journal des événements de sécurité avancée <COMPUTER_NAME>evt_WindowsFirewallWithAdvance

du pare-feu aux formats TXT, CSV et EVTX dSecurity-Firewall_evt.csv
> [!NOTE] <COMPUTER_NAME>evt_WindowsFirewallWithAdvance

> disponible uniquement sur Windows 7 et Windows dSecurity-Firewall_evt.txt
Server 2008 R2
<COMPUTER_NAME>evt_WindowsFirewallWithAdvance
dSecurity-Firewall_evt.evtx
Sortie de la commande NETSH ADVFIREWALL SHOW <COMPUTER_NAME>_Firewall_netsh_advfirewall.TXT

avec différentes options
Sortie de netSH advfirewall consec show rule name=all <COMPUTER_NAME>_Firewall_netsh_advfirewall-

consec-rules.TXT
Sortie de l’exportation netsh advfirewall <COMPUTER_NAME>_Firewall_netsh_advfirewall-

export.wfw
Sortie du pare-feu netsh advfirewall afficher le nom de la <COMPUTER_NAME>_Firewall_netsh_advfw-firewall-

règle =all rules.TXT
HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall <COMPUTER_NAME>Firewall_reg.TXT
HKLM\SYSTEM\CurrentControlSet\Services\BFE <COMPUTER_NAME>Firewall_reg.TXT
HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT <COMPUTER_NAME>Firewall_reg.TXT
HKLM\SYSTEM\CurrentControlSet\Services\MpsSvc <COMPUTER_NAME>Firewall_reg.TXT
HKLM\SYSTEM\CurrentControlSet\Services\SharedAcces <COMPUTER_NAME>Firewall_reg.TXT
s»
Informations de base collectées lorsque le collecteur SQL diagnostics de base est exécuté sur un cluster
de Windows de données
Journaux de cluster générés par Get-ClusterLog <COMPUTER_NAME>_cluster.log

Windows PowerShell cmdlet
Propriétés du cluster <COMPUTER_NAME>_ClusterProperties.txt
Rapport de dépendance de cluster <COMPUTER_NAME>_ag_DependencyReport.mht
Noms et versions des binaires de clustering <COMPUTER_NAME>_sym_Cluster.CSV
Noms et versions des binaires de clustering <COMPUTER_NAME>_sym_Cluster.TXT

Journal des événements d’administration du <COMPUTER_NAME>_evt_FailoverClusteringManager-

Gestionnaire du cluster de failover aux formats TXT, CSV Admin.csv
et EVTX
<COMPUTER_NAME>_evt_FailoverClusteringManager-
Admin.txt
> [!NOTE] <COMPUTER_NAME>_evt_FailoverClusteringManager-

> disponible uniquement sur les Windows cluster de Admin.evtx
failover Server 2008 R2
Événements opérationnels du cluster de failover dans les <COMPUTER_NAME>_evt_FailoverClustering-

formats TXT, CSV et EVTX Operational.csv
> [!NOTE] <COMPUTER_NAME>_evt_FailoverClustering-

> disponible uniquement sur les Windows cluster de Operational.txt
failover Server 2008 R2
<COMPUTER_NAME>_evt_FailoverClustering-
Operational.evtx
Windows clés de Registre de cluster
HKLM\System\CurrentControlSet\services\CluDisk <COMPUTER_NAME>_reg_ClusDisk.txt
HKLM\System\CurrentControlSet\services\ClusSvc <COMPUTER_NAME>_reg_ClusSvc.txt
HKLM\Cluster <COMPUTER_NAME>_reg_Cluster.hiv
Informations sur les attributions de droits d’utilisateur sur l’ordinateur de destination
Attributions locales de droits d’utilisateur <COMPUTER_NAME>_UserRights.txt
Informations sur le domaine joint à l’ordinateur de destination
Informations sur le domaine joint à l’ordinateur cible <COMPUTER_NAME>_DSMisc.txt
Informations sur le système d’exploitation et si l’ordinateur de destination est une VM
Rapports sur l’état de virtualisation de la VM cible <COMPUTER_NAME>_Virtualization.htm
Rapports sur l’état de virtualisation de la VM cible <COMPUTER_NAME>_Virtualization.TXT

Informations sur les stratégies de groupe Active Directory appliquées à l’ordinateur de destination
Informations sur les stratégies de groupe appliquées à <COMPUTER_NAME>_GPResult.txt

Informations sur les stratégies de groupe appliquées à <COMPUTER_NAME>_GPResult.htm

Informations d’auto-mise en place
NOTE
Pour plus d’informations sur l’utilitaire d’auto-mise en service, voir Autoruns for Windows v13.98.
Informations d’auto-.htm format <COMPUTER_NAME>_Autoruns.htm
Informations d’auto-.xml format <COMPUTER_NAME>_Autoruns.XML
Tickets Kerberos et TGT
Tickets Kerberos et TGT <COMPUTER_NAME>_ Kerberos_klist.txt
Informations sur la configuration du service Windows volume shadow copy sur l’ordinateur de
destination
Windows Informations sur le service de copie de l’ombre <COMPUTER_NAME>_VSSAdmin.TXT

du volume
SQL Server’erreurs
Le SQL de diagnostics de base collecte jusqu’à 20 journaux d’erreurs SQL Server pour chaque instance
découverte qui répond aux critères suivants :
La taille de chaque fichier journal d’erreurs doit être inférieure ou inférieure à 200 Mo.
La taille totale non compressée maximale de tous les fichiers journaux d’erreurs collectés ne peut pas
dépasser 250 Mo. Lorsque la limite de 250 Mo est atteinte, aucun journal d’erreur supplémentaire
n’est collecté pour l’instance de SQL Server.
instances installées sur l’ordinateur sur lequel l’outil de <COMPUTER_NAME>_<INSTANCE_NAME>_1033_ERRO
diagnostic est exécuté. RLOG[.n]

<COMPUTER_NAME>_MSSQLSERVER_ERRORLOG[.n]
NOTE
Lorsque le collecteur de diagnostics de base SQL est exécuté sur un cluster de percepteur de Windows, les
journaux d’erreurs SQL Server sont collectés uniquement s’ils sont stockés sur un lecteur « propriétaire » et « en
ligne » sur le nœud de cluster cible.
SQL Server Journaux de l’agent

Le SQL de diagnostics de base collecte jusqu’à 20 journaux de l’agent SQL Server pour chaque instance
découverte qui répond aux critères suivants :
La taille SQL Server fichier journal de l’agent doit être inférieure ou inférieure à 200 Mo.
La taille totale non compressée maximale de tous les fichiers journaux de l’agent SQL Server collectés
ne peut pas dépasser 250 Mo. Lorsque la limite de 250 Mo est atteinte, aucun fichier journal SQL
Server agent supplémentaire n’est collecté pour l’instance de SQL Server.
Collecte les SQL Server de l’agent de diagnostic pour Instance nommée :

toutes les instances installées sur l’ordinateur sur lequel <COMPUTER_NAME>_<INSTANCE_NAME>_1033_SQLAGENT.
l’outil de diagnostic est exécuté. [OUT|n]
<COMPUTER_NAME>_MSSQLSERVER__1033_SQLAGENT.
[OUT|n]
NOTE
journaux de l’agent SQL Server sont collectés uniquement s’ils sont stockés sur un lecteur « propriétaire » et « en
SQL Server fichiers minidump

Le SQL de diagnostics de base collecte jusqu’à 10 SQL Server fichiers minidump pour chaque instance de
SQL Server. Les fichiers sont collectés dans l’ordre décroit, en fonction de la date de création du fichier
minidump. Cela signifie que les derniers fichiers générés sont collectés en premier. Les fichiers collectés
doivent répondre aux critères suivants :
La taille de chaque fichier minidump doit être inférieure ou inférieure à 250 Mo.
La taille totale non compressée maximale de tous les fichiers minidump collectés pour une instance
donnée de SQL Server ne peut pas dépasser 300 Mo. Lorsque la limite de 300 Mo est atteinte, aucun
fichier minidump supplémentaire n’est collecté pour l’instance de SQL Server
NOTE
SQL Server fichiers minidump Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_1033_SqlMi
niDumps.zip

<COMPUTER_NAME>_MSSQLSERVER_1033_SqlMiniDu
mps.zip

pour chaque instance de SQL Server <COMPUTER_NAME>_<INSTANCE_NAME>_DumpInven
tory.log

og
NOTE
Lorsque le collecteur de diagnostics de base SQL est exécuté sur un cluster de percevoir le cluster de Windows, les
fichiers SQL Server minidumps sont collectés uniquement s’ils sont stockés sur un lecteur « propriétaire » et « en
Script de collecte de données SQLDIAG

Le script de collecte de données SQLDIAG est exécuté sur chaque instance de SQL Server dont l’état de
service est « RUNNING ». La sortie du script est redirigée vers un fichier et collectée par le diagnostic.
Sortie de script SQLDIAG Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_1033_sp_sq
ldiag_Shutdown.OUT

<COMPUTER_NAME>_MSSQLSERVER_1033_sp_sqldiag_
Shutdown.OUT
SQL Server Informations de configuration AlwaysOn
NOTE
Les SQL Server de configuration AlwaysOn sont collectées uniquement à partir SQL Server instances 2012.

SQL Server Informations de configuration AlwaysOn Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_1033_Alwa
ysOn.OUT

<COMPUTER_NAME>_MSSQLSERVER_1033_AlwaysOn.
OUT
SQL Server Journaux d’état AlwaysOn

SQL Server Les journaux de session d’état AlwaysOn sont collectés à partir de chaque instance SQL
archives zip « spécifiques à l’instance ».
Le nombre maximal d SQL Server journaux d’état AlwaysOn qui seront collectés pour chaque instance
découverte est de 20. Les fichiers sont collectés dans l’ordre décroit, en fonction de la date de création du
fichier.
SQL Server Journaux d’état AlwaysOn Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_AlwaysOn_
health_XeLogs.zip

<COMPUTER_NAME>_MSSQLSERVER_AlwaysOn_health
_XeLogs.zip
NOTE
journaux d’état SQL Server AlwaysOn sont collectés uniquement s’ils sont stockés sur un lecteur « propriétaire »
et « en ligne » sur le nœud de cluster cible.
SQL Server journaux d’état du cluster de failover

SQL Server journaux d’état du cluster de failover sont collectés à partir de chaque instance de cluster SQL
archives zip « spécifiques à l’instance ».
Le nombre maximal de journaux d’état du cluster de percevoir pour chaque instance est de 20. Les
fichiers sont collectés dans l’ordre décroit, en fonction de la date de création du fichier.
SQL Server journaux d’état du cluster de failover Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_FailoverClus
ter_health_XeLogs.zip

<COMPUTER_NAME>_MSSQLSERVER_FailoverCluster_h
ealth_XeLogs.zip
NOTE
Les SQL Server d’état du cluster de percevoir sont collectés uniquement s’ils sont stockés sur un lecteur «
propriétaire » et « en ligne » sur le nœud de cluster cible.
SQL Server d’état du système par défaut

SQL Server journaux d’état du système par défaut sont collectés à partir de chaque instance SQL Server
2012 installée sur l’ordinateur de destination. Les fichiers sont collectés et compressés dans des archives
ZIP « spécifiques à l’instance »
SQL Server d’état du système par défaut Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_system_hea
lth_XeLogs.zip

<COMPUTER_NAME>_MSSQLSERVER_system_health_Xe
Logs.zip
NOTE
journaux d’état du système par défaut SQL Server sont collectés uniquement s’ils sont stockés sur un lecteur «
propriétaire » et « en ligne » sur le nœud du cluster cible.
SQL Server Fichier de configuration Analysis Services

Le SQL Server de configuration Analysis Services est collecté pour chaque instance Analysis Services
découverte sur l’ordinateur de destination.
SQL Server Fichier de configuration Analysis Services <COMPUTER_NAME>_<INSTANCE_NAME>_1033_msm

dsrv.ini
NOTE
Lorsque le collecteur de diagnostics de base SQL est exécuté sur un cluster de Windows de bas de commande, les
fichiers de configuration SQL Server Analysis Services sont collectés uniquement s’ils sont stockés sur un lecteur «
propriétaire » et « en ligne » sur le nœud de cluster cible.
SQL Server Clés de Registre Analysis Services

HKLM:\SOFTWARE\Microsoft\Microsoft SQL <COMPUTER_NAME>_reg_HKLM_OLAP_IntanceRoot_all

Server<OLAP_INSTANCE_ROOT_KEY> .txt
HKCR:\MSOLAP <COMPUTER_NAME>_reg_HKCR_MSOLAP_all.txt
HKCR:\MSOLAP.2
HKCR:\MSOLAP.3
HKCR:\MSOLAP.4
HKLM:\System\CurrentControlSet\Services<OLAP_Servic <COMPUTER_NAME>_reg_HKLM_CurrentControlSet_Se
e_Name> rvices_OLAP.txt
SQL Server Fichier journal Analysis Services

Le SQL Server journal Analysis Services est collecté pour chaque instance Analysis Services découverte
sur l’ordinateur de destination.
SQL Server Fichier journal Analysis Services <COMPUTER_NAME><INSTANCE_NAME>_msmdsrv.log
SQL Server Suivis de l’enregistreur de vol Analysis Services

Les SQL Server de l’enregistreur de vol Analysis Services seront collectés pour chaque instance Analysis
Services découverte sur l’ordinateur de destination.
Enregistreur de SQL Server Analysis Services actuel <COMPUTER_NAME>-

<INSTANCE_NAME>_FlightRecorderCurrent.trc
Enregistrement de SQL Server de version d’SQL Server <COMPUTER_NAME>-

Analysis Services <INSTANCE_NAME>_FlightRecorderBack.trc
SQL Server Fichiers minidump Analysis Services

Le SQL de diagnostics de base collecte jusqu’à 10 SQL Server fichiers minidump Analysis Services pour
chaque instance de SQL Server Analysis Service. Les fichiers sont collectés dans l’ordre décroit, en
fonction de la date de création du fichier minidump. Cela signifie que les derniers fichiers générés sont
collectés en premier. Les fichiers collectés doivent répondre aux critères suivants :
La taille de chaque fichier minidump doit être inférieure ou inférieure à 250 Mo.
La taille totale non compressée maximale de tous les fichiers minidump collectés pour une instance
donnée de SQL Server ne peut pas dépasser 300 Mo. Lorsque la limite de 300 Mo est atteinte, aucun
fichier minidump supplémentaire n’est collecté pour l’instance de SQL Server Analysis Services.
NOTE
SQL Server Fichiers minidump Analysis Services Instance nommée :

<COMPUTER_NAME>_<INSTANCE_NAME>_1033_ASMi
niDumps
.zip

<COMPUTER_NAME>_MSSQLSERVER_1033_ASMiniDu
mps .zip

pour chaque instance SQL Server Analysis Services <COMPUTER_NAME>_<INSTANCE_NAME>_DumpInven
tory.log

og
Utilisation de SQL Server dans Windows 8 et
versions ultérieures du Windows d’exploitation
Cet article contient des instructions sur l’utilisation de différentes versions de Microsoft SQL Server sur un
ordinateur qui exécute Windows 8 ou une version ultérieure du système d’exploitation.
Résumé
NOTE
Sauf indication contraire, lorsqu’un système d’exploitation est pris en charge pour une version SQL majeure, il reste pris en
charge pour toutes les versions de maintenance ultérieures. Par exemple, si SQL Server 2016 RTM est pris en charge sur
Windows 10, cela implique que toutes les CUS en plus de SQL Server 2016 RTM ou SQL Server 2016 Service Pack 1 (SP1)
sont pris en charge sur Windows 10.
Utilisation de cet article :

1. Découvrez la version minimale requise pour la version SQL Server que vous essayez d’installer pour le
système d’exploitation correspondant.
W IN DO
WS P L US
VERSIO N D’IN F O R
/ SQ L SQ L SQ L SQ L SQ L SQ L SQ L M AT IO N
VERSIO N SERVER SERVER SERVER 2 SQ L SER SERVER 2 SERVER SERVER 2 S/ L IM ITA
--> 2019 2017 016 VER 2014 012 2008 R2 008 T IO N S
Window Oui Oui Oui Oui Oui Non pris Non pris Informati
s 10 (RTM) (RTM) (SP2) (SP3) (SP4) en en ons
charge charge supplém
entaires
pour les
environn
ements
Windows
10 de
données
s Server (RTM) (RTM) (SP2) (SP3) (SP4) en en ons
2019 charge charge supplém
entaires
pour
Windows
environn
ements
Server
2019
W IN DO
WS P L US
--> 2019 2017 016 VER 2014 012 2008 R2 008 T IO N S
s Server (RTM) (RTM) (SP2) (SP3) (SP4) en en ons
2016 charge charge supplém
entaires
pour les
environn
ements
Windows
Server
2016 de
données
Window Non Oui Oui Oui Oui Oui Oui Informati

s 8.1 (RTM) (SP2) (SP3) (SP4) (SP3) (SP4) ons
supplém
entaires
pour les
environn
ements
Windows
8.1 de
données

s (RTM) (SP2) (SP3) (SP4) (SP3) (SP4) ons
Server 2 supplém
012 R2 entaires
pour les
Windows
Server
2012 R2

s8 (RTM) (SP2) (SP3) (SP4) (SP3) (SP4) ons
supplém
entaires
pour les
environn
ements
Windows
8 de
données

s (RTM) (SP2) (SP3) (SP4) (SP3) (SP4) ons
Server 2 supplém
012 entaires
pour les
environn
ements
Windows
Server
2012 de
données
W IN DO
WS P L US
--> 2019 2017 016 VER 2014 012 2008 R2 008 T IO N S
Page SQL SQL SQL SQL SQL Serv SQL SQL

Configur Server 2 Server 2 Server Server 2 er 2012 Server Server
ation 019 017 2016 014 2008 R2 2008
matériell
e et
logicielle
requise
2. Pour trouver des réponses aux questions suivantes, examinez le lien correspondant sous la page
Configuration matérielle et logicielle requise.
Quelles éditions de SQL Server sont compatibles avec quelles versions de Windows ?
Quelles sont les .NET Framework requises pour ma version SQL client ?
3. Utilisez la colonne Informations supplémentaires/Limitations dans le tableau ci-dessus pour trouver des
informations supplémentaires sur l’exécution SQL serveur sur le système d’exploitation spécifique.
Par exemple, si vous souhaitez installer SQL Server 2016 Developer Edition sur Windows 10 Professional
:
a. Vérifiez si SQL Server 2016 est pris en charge sur Windows 10. La valeur correspondante dans le
tableau ci-dessus est Oui (SP2).
Oui indique que la SQL Server 2016 sur Windows 10 est prise en charge.
(SP2) indique que SQL Server 2016 doit être mis à jour vers au moins SP2 pour être pris
en charge sur Windows 10.
b. La page Configuration matérielle et logicielle requise pour SQL 2016 confirme que SQL Server
Édition Développeur 2016 est prise en charge sur Windows 10 Professional.
c. La colonne Plus d’informations/limitations Windows Server 2016 n’appelle aucun problème
connu supplémentaire pour cette configuration.
Exigences SQL Server version minimale pour Windows Server 2019

Cette section décrit la version minimale requise pour l’installation SQL Server sur un ordinateur exécutant
Avant d’installer SQL Server sur un ordinateur exécutant Windows Server 2019, vous devez vous assurer que
vous remplissez les conditions minimales suivantes, en fonction de votre situation.
Pour SQL Ser ver 2019 sur Windows
La publication est prise en charge SQL Server 2019 sur Windows version RTM Release.
Pour SQL Ser ver 2016
Vous devez appliquer SQL Server 2016 Service Pack 2 ou une mise à jour ultérieure. Pour plus
d’informations, voir Comment obtenir ledernier Service Pack pour SQL Server 2016.
d’informations,voir Comment obtenir le dernier Service Pack pour SQL Server 2014.
NOTE
Veillez à vérifier les problèmes d’installation connus lorsque vous installez SQL Server 2012 sur Windows 10 ou
La rubrique Books Online Hardware and Software Requirements for Installing SQL Ser ver 2012 has
not yet been updated to reflect the support for Windows Server 2016.

SQL Server 2008 R2 n’est pas pris en charge sur Windows 10 ou Windows Server 2016.
SQL Server 2008 n’est pas pris en charge sur Windows 10 ou Windows Server 2016.
Exigences SQL Server version minimale pour les Windows 10 et

Windows Server 2016
Cette section décrit la version minimale requise pour installer les SQL Server sur un ordinateur qui exécute
Windows 10 ou Windows Server 2016.
Avant d’installer SQL Server sur un ordinateur exécutant Windows 10 ou Windows Server 2016, vous devez
vous assurer que vous remplissez les conditions minimales suivantes, en fonction de votre situation.
d’informations, voir Comment obtenir le dernier Service Pack pour SQL Server 2016.
NOTE
Veillez à vérifier les problèmes d’installation connus lorsque vous installez SQL Server 2012 sur Windows
10 ou Windows Server 2016.
La rubrique Books Online Hardware and Software Requirements for Installing SQL Ser ver 2012
has not yet been updated to reflect the support for Windows Server 2016.

SQL Server 2008 R2 n’est pas pris en charge sur Windows 10 ou Windows Server 2016.
SQL Server 2008 n’est pas pris en charge sur Windows 10 ou Windows Server 2016.
Exigences SQL Server version minimale pour Windows Server 2012 R2

ou Windows 8.1
Cette section décrit la version minimale requise pour l’installation de SQL Server sur un ordinateur qui exécute
Windows Server 2012 R2 ou Windows 8.1.
Avant d’installer SQL Server sur un ordinateur exécutant Windows Server 2012 R2 ou Windows 8.1, vous devez
vous assurer que vous remplissez les conditions minimales suivantes, en fonction de votre situation :
SQL Server 2019 n’est pas pris en charge sur Windows 8.1 ou Windows Server 2012 R2.
Vous pouvez installer la version release de SQL Server 2017 Windows version ultérieure ou ultérieure.
Pour plus d’informations, voir la page SQL Server 2014.
NOTE
Vérifiez les problèmes d’installation connus lorsque vous installez SQL Server 2012 sur Windows 8 ou Windows
Server 2012.

Vous devez appliquer SQL Server 2008 R2 Service Pack 3 ou une mise à jour ultérieure. Pour plus
d’informations, voir Comment obtenir le dernier Service Pack pour SQL Server 2008 R2.
Vous devez appliquer SQL Server 2008 Service Pack 4 ou une mise à jour ultérieure.
NOTE
L’installation RTM du produit est prise en charge. Toutefois, vous devez installer les Service Packs respectifs une
fois l’installation initiale terminée. Votre installation SQL Server 2008 n’est pas prise en charge, sauf si vous
appliquez le Service Pack 4 après avoir installé l’édition RTM. Pour plus d’informations, voir Comment obtenir le
dernier Service Pack pour SQL Server 2008.
Vérifiez également les problèmes d’installation connus lorsque vous installez SQL Server 2008 R2 et SQL Server
2008 sur un ordinateur exécutant Windows Server 2012 R2, Windows Server 2012, Windows 8.1 ou Windows
8.
Exigences SQL Server version minimale pour les Windows Server 2012
ou Windows 8
NOTE
Windows 8 a atteint la fin de la prise en charge, ce Windows 8 les appareils ne reçoivent plus les mises à jour de sécurité
importantes. Nous vous recommandons d’effectuer la mise à niveau gratuite vers Windows 8.1 pour continuer à recevoir
les mises à jour de sécurité et la prise en charge. Pour plus d’informations, voir Mise à jour Windows 8.1 à partir Windows
8.
Cette section décrit la version minimale requise pour l’installation SQL Server sur un ordinateur qui exécute
Windows Server 2012 ou Windows 8.
Avant d’installer SQL Server sur un ordinateur exécutant Windows Server 2012 ou Windows 8, vous devez vous
assurer que vous remplissez les conditions minimales suivantes, en fonction de votre situation :
SQL Server 2019 n’est pas pris en charge sur Windows 8.1 ou Windows Server 2012 R2.
NOTE
Vérifiez les problèmes d’installation connus lorsque vous installez SQL Server 2012 sur Windows 8 ou Windows
Server 2012.

Vous devez appliquer Microsoft SQL Server 2008 R2 Service Pack 3 ou une mise à jour ultérieure.
NOTE
fois l’installation initiale terminée. Vous verrez le message suivant dans la page Centre de solutions :
Pour plus d’informations, voir Comment obtenir le dernier Service Pack pour SQL Server 2008 R2.
Vous devez appliquer SQL Server 2008 Service Pack 4 ou une mise à jour ultérieure.
NOTE
fois l’installation initiale terminée. Votre installation SQL server 2008 n’est pas prise en charge, sauf si vous
appliquez le Service Pack 4 après avoir installé l’édition RTM. Vous verrez le message suivant sur la page Centre de
solutions.
Pour plus d’informations, voir Comment obtenir le dernier Service Pack pour SQL Server 2008.
IMPORTANT
La boîte de dialogue suivante apparaît SQL Server 2008 R2 et SQL Server 2008 lorsque vous exécutez le
programme d’installation.
Une fois SQL Server programme d’installation, vous devez installer des Service Packs avant d’exécuter
SQL Server sur cette version de Windows.
Pour SQL Server 2008, vous devez installer le Service Pack 4 (SP4) ou une version ultérieure.
Pour SQL Server 2008 R2, vous devez installer le Service Pack 3 (SP3) ou une version ultérieure.
NOTE
Vérifiez également les problèmes d’installation connus lorsque vous installez SQL Server 2008 R2 et SQL
Server 2008 sur un ordinateur exécutant Windows Server 2012 R2, Windows Server 2012, Windows 8.1
ou Windows 8.
Pour SQL Ser ver Compact éditions

Les versions suivantes sont Windows 8.1, Windows 8, Windows Server 2012 et Windows Server 2012
environnements R2 :
SQL Server Compact 3.5 Service Pack 2 et versions ultérieures
SQL Server Compact 4.0 et versions ultérieures
NOTE
Aucune prise en charge n’est prévue Windows RT appareils mobiles.
Prise en charge du changement de mode dans Windows Server 2012

R2 ou Windows Server 2012
Cette section décrit la stratégie de prise en charge lorsque vous basculez Windows Server 2012 R2 ou Windows
Server 2012 modes d’exploitation pendant SQL Server’installation.
Windows Server 2012 R2 et Windows Server 2012 ont les états de fonctionnalité ou modes suivants :
Serveur complet
Interface serveur minimale
Server CoreYou peut basculer entre ces états de fonctionnalité à tout moment.
Vous pouvez passer de Server Core ou Minimal Server Interface à Full Server lorsqu’une ou plusieurs instances
de SQL Server 2014 ou SQL Server 2012 sont installées. Toutefois, sachez que vous ne pouvez pas passer de
l’interface serveur complète à l’interface serveur minimale ou à l’interface minimale minimale lorsqu’une ou
plusieurs instances de SQL Server 2014 ou SQL Server 2012 sont installées.
Pour passer d’une interface serveur complète à une interface serveur minimale ou minimale lorsqu’une ou
plusieurs instances de SQL Server 2014 ou SQL Server 2012 sont installées, vous devez désinstaller SQL Server
2014 ou SQL Server 2012, les modes commutateur, puis réinstaller SQL Server 2014 ou SQL Server 2012.
Toutefois, vous pouvez activer les conditions préalables à l’installation de SQL Server 2014 ou SQL Server 2012
en mode serveur complet, basculer en mode Serveur principal, puis installer SQL Server 2014 ou SQL Server
2012.
NOTE
Minimal Server est une installation minimale qui dispose du Gestionnaire de serveur et d’autres outils serveur. Par
conséquent, le programme d’installation SQL Server effectue les mêmes étapes d’installation en mode d’interface
serveur minimale Windows Server 2012 R2 et Windows Server 2012 mode d’interface serveur minimale et serveur
principal. En outre, vous pouvez basculer entre Server Core et Minimal Server lorsqu’une ou plusieurs instances de
SQL Server 2014 ou SQL Server 2012 sont installées. Il s’agit d’un scénario pris en charge.
SQL Server Reporting Services 2012 n’est pas pris en charge sur Windows Server 2012 R2 Server Core, Windows
Server 2012 Server Core, Windows Server 2012 R2 Minimal Server Interface mode ou Windows 2012 Minimal
Server Interface mode. Vous pouvez installer SQL Server Reporting Services 2012 sur un serveur qui exécute
Windows Server 2012 en mode serveur complet, puis basculer en mode Windows Server 2012 Serveur principal.
Toutefois, cette configuration n’est pas prise en charge.
Nous vous recommandons de désinstaller toutes les fonctionnalités SQL Server 2012 qui ne sont pas pris en
charge sur un serveur exécutant Windows Server 2012 R2 ou Windows Server 2012 en mode Serveur principal.
Pour plus d’informations sur la façon de faire, voir Install SQL Server 2012 on Server Core).
Ce problème ne s’applique SQL Server 2008 ou 2008 SQL Server 2008 R2. SQL Server 2008 et SQL Server 2008
R2 ne sont pas pris en charge en mode Minimale Interface serveur ou Serveur principal.
Pour plus d’informations sur les options d’installation disponibles lorsque vous installez Windows Server 2012,
voir Windows Server Installation Options.
SQL Server 2012 et SQL Server 2008 R2 pour les nouvelles
fonctionnalités de Windows 8.1, Windows 8, Windows Server 2012 R2
et Windows Server 2012
Cette section récapitule le fonctionnement des versions de SQL Server avec certaines nouvelles fonctionnalités
dans Windows 8.1, Windows 8, Windows Server 2012 R2 et Windows Server 2012.
Le tableau suivant récapitule le fonctionnement des versions de SQL Server avec certaines nouvelles
fonctionnalités Windows 8 et Windows Server 2012.
NOTE
Sauf indication du tableau suivant, toutes les fonctionnalités de Windows Server 2012 sont pris en charge dans toutes les
versions de SQL server.
SQ L O U
C O M P O SA N T SQ L EXIGEN C ES
Q UI IN T ERA GIT F O N C T IO N N A L I M IN IM A L ES EN
AVEC C ET T E T É Q UI EST M AT IÈRE DE EXC EP T IO N S O U
N O UVEL L E A F F EC T ÉE O U VERSIO N ET DE L IM ITAT IO N S DE P L US
F O N C T IO N N A L I F O N C T IO N N A L I P RISE EN SERVIC E PA C K P RISE EN D’IN F O RM AT IO N
TÉ TÉ C H A RGE P O UR SQ L C H A RGE S
Espaces de SQL Server 2008 Cette

stockage R2 Service Pack fonctionnalité est
1 ou version prise en charge
ultérieure, SQL avec les Service
Server 2012 Packs spécifiés
(VERSION pour les versions
FINALE et respectives.
versions
ultérieures)
REMARQUE
SQL Server 2008
R2 nécessite le
Service Pack 2
sur Windows 8.1
et Windows
Server 2012 R2.
Système de ReFS n’est pas

fichiers résilient pris en charge
(ReFS, Resilient SQL 2012 et
File System) toutes les autres
versions de bas
niveau. SQL
Server 2014
prend en charge
ReFS.
SQ L O U
Atténuation des LazyWriter Renifleur de page SQL Server 2012 Lorsque SQL
erreurs Checksum Server 2012 est
matérielles de installé sur un
RAM système
d’exploitation
Windows 2012
avec du matériel
qui prend en
charge les
diagnostics de
mémoire non
bon, vous
remarquerez de
nouveaux
messages
d’erreur tels que
854, 855 et 856
au lieu des
erreurs 832
générées par
LazyWriter.
Nombre Disponibilité Clustering SQL Server 2012 25 par cluster de

d’instances par élevée deover per failover
cluster lorsque vous
utilisez des
lettres de lecteur
et jusqu’à 50 si
vous utilisez le
stockage de
partage de
fichiers SMB
SQ L O U
Volumes de Depuis SQL

partage de Server 2014, les
cluster (CSV) instances de
cluster de
failover
AlwaysOn prend
en charge les
volumes
partagés en
cluster (CSV)
dans Windows
Server 2008 R2
et Windows
Server 2012.
Pour plus
d’informations
sur CSV, voir
Understanding
Cluster Shared
Volumes in a
Failover Cluster.
Les CSV ne sont
pas pris en
charge dans les
versions
antérieures SQL
Server 2014.
SQL Server 2005

Cette section fournit des informations de support sur les instances de SQL Server 2005 dans Windows 8.1 ou
Windows 8 environnements. Il décrit également les options disponibles pour les clients qui utilisent SQL Server
2005. Microsoft SQL Server 2005 (version release et Service Packs) et les versions antérieures de SQL Server
ne sont pas pris en charge sur Windows 10, Windows Server 2016, Windows Server 2012 R2, Windows Server
2012, Windows 8.1 ou Windows 8. Vous recevrez un avertissement dans le centre de actions si Windows 10,
Windows 8.1 ou Windows 8 détecte une instance de SQL Server 2005.
Pour résoudre ce problème, mettre à niveau ou supprimer l’instance existante de SQL Server 2005. Pour plus
d’informations sur la mise à niveau SQL Server, voirUpgrade to SQL Server.
NOTE
Ce lien pointe vers SQL Server 2014. Vous pouvez utiliser l’outil de sélection de version en haut du lien MSDN (Autres
versions) pour plus d’informations sur les autres versions.
Pour plus d’informations sur les éditions Express de SQL Server, voir les sites web Microsoft suivants :
SQL Server 2014 Service Pack 2 Express Edition
SQL Server 2012 Service Pack 3 (SP3) Express Edition
SQL Server 2008 R2 Service Pack 3 (SP3) Express Edition
Pour plus d’informations sur la désinstallation d’une instance existante de SQL Server 2005, voirHow to
manually uninstall an instance of SQL Server 2005 or Howto: Uninstall an Existing Instance of SQL Server 2005
(Setup).
S’applique à
SQL Server Web 2008
SQL Server Web 2012
SQL Server Web 2014
SQL Server Web 2016
SQL Server 2019 sur Windows
Stratégie de prise en charge Microsoft SQL Server
produits en cours d’exécution dans un
environnement de virtualisation de matériel
Cet article décrit la stratégie de prise en charge SQL Server produits qui s’exécutent dans un environnement de
virtualisation matérielle.
INTRODUCTION
Cet article décrit la stratégie de prise en charge pour Microsoft SQL Server qui s’exécutent dans un
environnement de virtualisation de matériel.
Microsoft fournit une assistance technique pour SQL Server 2008 et versions ultérieures pour les
environnements de virtualisation de matériel pris en charge suivants :
Windows Server 2008 et versions ultérieures avec Hyper-V
Microsoft Hyper-V Server 2008 et versions ultérieures
Configurations validées par le biais du programme SVVP (Server Virtualization Validation Program).
Pour plus d’informations sur les fournisseurs certifiés et sur les configurations pour svVP, voir
http://windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm .
NOTE
La solution SVVP doit être en cours d’exécution sur du matériel certifié pour Windows Server 2008 R2 ou une
version ultérieure afin d’être considérée comme une configuration SVVP valide.
Microsoft fournit une assistance technique pour SQL Server 2008 et versions ultérieures pour les
environnements de virtualisation de matériel pris en charge suivants :
Services d’infrastructure Azure qui inclut les machines virtuelles Azure et Azure Virtual Network (consultez la
section Questions fréquemment posées pour plus d’informations)
Microsoft peut fournir un support technique limité ou nul pour les environnements suivants :
Toute version de SQL Server antérieure à SQL Server 2008 (par exemple, SQL Server 2005) qui s’exécute sur
un fournisseur ou une configuration de virtualisation.
Tout logiciel de virtualisation non-Microsoft qui n’est pas une configuration validée par le biais du
programme SVVP
Cette stratégie de prise en charge limitée est basée sur l’article suivant de la Base de connaissances Microsoft :
Stratégie de support pour les logiciels Microsoft qui s’exécutent sur des logiciels de virtualisation de matériel
non Microsoft
Restrictions et limitations
Les restrictions et limitations suivantes peuvent affecter la stratégie de prise en charge des configurations prise
en charge ci-dessus :
Le clustering de failover invité est pris en charge pour SQL Server 2008 et versions ultérieures dans une
machine virtuelle pour les environnements de virtualisation de matériel pris en charge répertoriés dans
cet article, à condition que toutes les conditions suivantes soient remplies :
Le système d’exploitation s’exécutant sur la machine virtuelle (le « système d’exploitation invité »)
est Windows Server 2008 ou une version ultérieure.
L’environnement de virtualisation répond aux exigences du clustering de Windows 2008 ou
Windows 2012, comme documenté dans les articles suivants de la Base de connaissances
Microsoft :
Stratégie de support Microsoft pour les clusters de Windows Server 2008 ou Windows
Server 2008 R2
Stratégie de support Microsoft pour les clusters de Windows serveur
Le SQL Server produit doit être une version prise en charge dans le cadre de sa politique de cycle de vie
actuelle du support Microsoft. Pour plus d’informations sur les stratégies de cycle de vie du support
Microsoft, voir Les informations de cycle de vie des produits et services de recherche.
SQL Server prend en charge les solutions de sauvegarde adaptées à la virtualisation qui utilisent VSS
(captures instantanées en volume). Par exemple, SQL Server prend en charge la sauvegarde Hyper-V.
Les captures instantanées de machine virtuelle qui n’utilisent pas de captures instantanées de volume
VSS ne sont pas prises en charge par SQL Server. Toute technologie de capture instantanée qui enregistre
en arrière-plan un état de mémoire, de disque et d’appareil à un point dans le temps des ordinateurs
virtuels sans interagir avec les applications sur l’invité à l’aide de VSS peut laisser SQL Server dans un
état incohérent.
SQL Server réplica Hyper-V est pris en charge à condition que l’indicateur
EnableWriteOrderPreservationAcrossDisks soit définie.
NOTE
Pour définir l’indicateur EnableWriteOrderPreservationAcrossDisks, exécutez l’cmdlet suivante :
Set-VMReplication -VMName \<vm-name> -EnableWriteOrderPreservationAcrossDisks 1
Exceptions
Si plusieurs VM SQL sont étroitement couplées les unes aux autres, les VM individuels peuvent faire
échouer vers le site de récupération d’urgence, mais les fonctionnalités de haute disponibilité (HA) de
SQL à l’intérieur de la VM doivent être supprimées et reconfigurées après le failover de la VM. Pour cette
raison, les fonctionnalités SQL Server suivantes ne sont pas pris en charge sur le réplica hyper-VM :
Groupes de disponibilité
Mise en miroir de bases de données
Instances de cluster de failover
Copie des journaux de transaction
Replication (Réplication)
Pour SQL serveurs en cours d’exécution sur l’environnement Linux, examinez les instructions dans la
section Technologies de virtualisation prise en charge de la stratégie de support technique pour Microsoft
SQL Server.
Il est recommandé d’utiliser SQL Server dans Exécuter Hyper-V dans une machine virtuelle avec
virtualisation imbriée uniquement à des fins de test et de développement.
Foire aux questions

Q1 : Quel niveau de suppor t technique recevrai-je si ma configuration de fournisseur non-
Microsoft est cer tifiée via SVVP ?
R1 : le support technique microsoft (CSS) collaborera avec le client et le fournisseur certifié SVVP pour
examiner le problème avec les SQL Server en cours d’exécution sur la machine virtuelle. Microsoft CSS
ou le fournisseur SVVP suit le processus documenté sur le site web SVVP suivant pour utiliser le
programme TSANet avec l’autorisation des clients pour tenter de résoudre le problème :
Server Virtualization Validation Program
Q2 : Que se passe-t-il si la configuration de vir tualisation du fournisseur non-Microsoft
n’est pas cer tifiée via SVVP ?
R2 : Microsoft CSS suit les stratégies de support qui sont documentées dans l’article de la Base de
connaissances 897615. Pour plus d’informations, cliquez sur le numéro d’article suivant pour afficher
l’article dans la Base de connaissances Microsoft :
Stratégie de support pour les logiciels Microsoft qui s’exécutent sur des logiciels de virtualisation de
matériel non Microsoft
Si Microsoft CSS détermine que le problème est peut-être lié au logiciel de virtualisation du fournisseur,
microsoft CSS peut exiger que le client reproduise le problème en dehors de l’environnement de
virtualisation.
Toutes les configurations de fournisseur ne sont pas considérées comme certifiées par svVP, même si le
fournisseur participe au programme. La liste des configurations validées peut être mise à jour lorsque les
fournisseurs envoient des modifications via ce programme.
Q3 : Le programme SVVP réper torie spécifiquement les configurations valides pour
Windows Ser ver 2008. D’autres versions de Windows sont-elles pris en charge pour être
utilisées en tant que système d’exploitation invité ?
R3 : Oui. Comme indiqué sur le site web SVVP suivant, les produits qui ont satisfait aux exigences SVVP
pour la dernière version finale de Windows Server sont considérés comme pris en charge sur toutes les
versions antérieures de Windows Server qui sont toujours pris en charge par la matrice de cycle de vie.
Virtualisation de serveur
Lors de l’exécution de SQL Server sur un système d’exploitation invité, la version de SQL Server doit être
prise en charge sur la version du système d’exploitation invité, conformément aux exigences répertoriées
dans la documentation produit SQL Server respective.
Pour plus d’informations sur la configuration matérielle et logicielle requise pour SQL Server, consultez
les pages suivantes sur les documents :
SQL Server 2019 : Configuration matérielle et logicielle requise
SQL Server 2016 et 2017 : Configuration matérielle et logicielle requise
SQL Server 2014 : Configuration matérielle et logicielle requise
Configuration matérielle et logicielle requise pour l’installation SQL Server 2012
Configuration matérielle et logicielle requise pour l’installation SQL Server 2008 R2
Configuration matérielle et logicielle requise pour l’installation SQL Server 2008
Q4 : Des fonctionnalités SQL Ser ver telles que la mise en miroir de bases de données sont-
elles pris en charge pour s’exécuter dans un environnement de vir tualisation ?
R4 : les seules restrictions d’installation et d’utilisation des SQL Server dans un environnement de
virtualisation sont documentées dans cet article ou dans la documentation SQL Server produit. Toute
fonctionnalité ou utilisation qui n’est pas précisée dans cet article ou dans la documentation du produit
SQL Server est supposée être prise en charge dans un environnement de virtualisation en utilisant les
mêmes restrictions et prise en charge qu’un environnement matériel complet. Pour plus d’informations
sur les fonctionnalités qui sont pris en charge par différentes éditions de SQL Server, consultez le site web
TechNet suivant :
Fonctionnalités pris en charge par les éditions SQL Server 2008 R2
Ces mêmes exigences s’appliquent SQL Server 2008 et versions ultérieures qui s’exécutent dans un
environnement de virtualisation.
Q5 : La migration rapide et en direct avec Windows Ser ver 2012 ou Windows Ser ver 2008
R2 Hyper-V est-elle prise en charge avec SQL Ser ver ?
R5 : Oui, live migration est pris en charge pour SQL Server 2008 et versions ultérieures lorsqu’il est
utilisé avec Windows Server 2008 R2 ou versions ultérieures avec Hyper-V et hyper-V server 2008 R2 ou
versions ultérieures. La migration rapide, introduite avec Windows Server 2008 avec Hyper-V et Hyper-V
Server 2008, est également prise en charge pour SQL Server (toutes les versions de SQL Server 2008 et
versions ultérieures) dans Windows Server 2008 (ou versions ultérieures) avec Hyper-V et Hyper-V
Server 2008 (ou versions ultérieures).
Q6 : Quelle est la stratégie de prise en charge SQL Ser ver lors de l’utilisation d’une
fonctionnalité de vir tualisation du fournisseur SVVP telle que des captures instantanées ou
une migration ?
R6 : les captures instantanées d’un fournisseur de virtualisation qui n’utilisent pas VSS ne sont pas prises
en charge avec SQL Server. Toute autre fonctionnalité supplémentaire de virtualisation d’un fournisseur
SVVP, telle que la migration, doit être prise en charge par le fournisseur SVVP. Cela inclut les problèmes
qui peuvent se produire SQL Server lors de l’utilisation de ces fonctionnalités. Lisez cette ressource pour
plus d’informations sur la stratégie de prise en charge pour les fonctionnalités supplémentaires d’un
produit de virtualisation :
Server Virtualization Validation Program
Q7 : La mémoire dynamique Hyper-V est-elle prise en charge pour SQL Ser ver ?
R7 : La mémoire dynamique Hyper-V est entièrement prise en charge avec SQL Server. Seules SQL
Server versions et éditions qui prendre en charge l’ajout de mémoire à chaud (Enterprise et Datacenter)
peuvent voir la mémoire ajoutée à l’aide de la mémoire dynamique Hyper-V. SQL Server 2012 et les
versions ultérieures des éditions standard reconnaissent également la mémoire Hot Add lors de
l’exécution dans un environnement virtuel. SQL Server versions qui ne prisent pas en charge l’ajout de
mémoire à chaud sont toujours pris en charge. Toutefois, ces versions détecteront uniquement la
mémoire présente dans le système d’exploitation SQL Server démarrage. Avant de déployer la mémoire
dynamique Hyper-V, lisez les ressources suivantes lorsque vous utilisez la mémoire dynamique Hyper-V
avec SQL Server :
Guide d’évaluation de la mémoire dynamique Hyper-V
SQL Server et mémoire dynamique Hyper-V - Partie 1
SQL Server dynamique Hyper-V - Partie 2
Q8 : Est-ce que vous SQL Ser ver en cours d’exécution Microsoft Azure Vir tual Machine ?
R8 : Oui. Microsoft prend en charge SQL Server 2008 et versions ultérieures dans Microsoft Azure
Infrastructure Services qui inclut Microsoft Azure machines virtuelles et Microsoft Azure virtual network.
Prenons les considérations suivantes lorsque vous déployez SQL Server 2008 et versions ultérieures
dans Microsoft Azure Virtual Machine :
Microsoft Azure Les stockages Geo-Replication ne sont pas pris en charge si les données et les
fichiers journaux d’une base de données sont stockés sur plusieurs disques.
Groupes de disponibilité AlwaysOn (avec plusieurs écouteurs) entièrement pris en charge.
Nous vous recommandons une VM DS3 ou une version supérieure pour SQL Enterprise édition, et
DS2 ou une version supérieure pour SQL Standard et Web.
Les fichiers Azure ne sont actuellement pas pris en charge pour stocker SQL Server données ou
fichiers journaux.
Pour plus d’informations Microsoft Azure la machine virtuelle et les SQL Server, voir What is SQL
Server on Azure Virtual Machines (Windows).
SQL Server instances de cluster de failover (FCI) sont pris en charge dans les scénarios suivants :
SQL Server FCI sur Windows Server 2016 versions ultérieures avec espaces de stockage
Direct. Pour plus d’informations, voir Configure SQL Server Failover Cluster Instance on
Azure Virtual Machines.
SQL Server FCI sur Windows Server 2016 versions ultérieures avec partages de fichiers
premium. Pour plus d’informations, voir Créer un ICI avec un partage de fichiers premium
(SQL Server sur les VM Azure).
SQL Server FCI n Windows Server 2016 versions ultérieures avec des disques partagés
Azure. Pour plus d’informations, voir Créer un ICI avec des disques partagés Azure (SQL
Server sur les ordinateurs virtuels Azure).
Q9 : Les clients peuvent-ils exécuter SQL Ser ver dans le Microsoft Azure de la VM ?
R9 : Microsoft Azure de machine virtuelle est un rôle non persistant et n’est pas identique à celui de
Microsoft Azure Virtual Machine. Il n’est pas pris en charge pour SQL Server production. Les clients qui
souhaitent déployer des fonctionnalités de plateforme de données aujourd’hui sur la plateforme
Microsoft Azure doivent utiliser Microsoft Azure machine virtuelle ou Microsoft Azure SQL Database.
Q10 : Existe-t-il des recommandations de configuration ou de meilleures pratiques à
prendre en compte lors du déploiement de SQL Ser ver dans des environnements vir tualisés
?
R10 : Oui, vous devez consulter les recommandations suivantes de l’hyperviseur respectif :
Meilleures pratiques en matière de virtualisation et de gestion des SQL Server
CONCEPTION DE MICROSOFT SQL SERVER SUR VMWARE VSPHERE
S’applique à
SQL Server Web 2008
SQL Server 2008 R2 PowerPivot pour Excel 2010
SQL Server Web 2012
SQL Server Web 2014
SQL Server Web 2016
Stratégie de support technique pour Microsoft SQL
Server
Cet article décrit la stratégie de prise en charge pour Microsoft SQL Server.
Version du produit d’origine : SQL Server 2017 sur Linux (toutes les éditions), SQL Server 2017 sur Windows
(toutes les éditions)
Résumé
Cet article décrit les stratégies de prise en charge et les limites de dépannage pour SQL Server produits installés
sur les plateformes pris en charge.
Systèmes d’exploitation pris en charge

En fonction de la version et de l’édition SQL Server, vous pouvez installer SQL Server sur un système d
Windows d’exploitation pris en charge. Les détails exacts sont décrits dans les notes de publication SQL Server
2019 Big Data Clusters.
Cette documentation décrit les systèmes d’exploitation spécifiques sur lesquels le produit est testé et validé.
Lorsque vous installez l’ancienne version de SQL Server sur des systèmes d Windows d’exploitation plus
Windows, vous devez être sur un Service Pack pris en charge.
À compter SQL Server 2017, vous pouvez installer SQL Server sur Linux d’exploitation. Les instructions
d’installation SQL Server sur Linux la liste actuelle des systèmes d’exploitation Linux pris en charge sur lesquels
vous pouvez installer et configurer SQL Server pour une utilisation en production.
À partir SQL Server 2019, vous pouvez déployer le SQL Server big data cluster sur Kubernetes. Examinez le
système d’exploitation hôte pris en charge pour Kubernetes dans les notes de publication SQL Server 2019 Big
Data Clusters dans la section Prise en charge.
Matériel pris en charge

SQL Server Les installations sont pris en charge sur les processeurs x64 (AMD et Intel). Ils ne sont plus pris en
charge sur les processeurs x86. Pour plus d’informations, voir la SQL Server 2016 et 2017: Configuration
matérielle et logicielle requise.
Technologies de virtualisation prise en charge

Microsoft prend en charge le déploiement SQL Server technologies de virtualisation qui incluent Microsoft
Hyper-V et d’autres hyperviseurs certifiés par le biais du programme SVVP (Server Virtualization Validation
Program). Pour plus d’informations sur SVVP, voir Windows Server Virtualization Validation Program.
Si vous hébergez une machine virtuelle Linux sur Hyper-V, assurez-vous que vous avez des machines virtuelles
Linux sur Hyper-V. Microsoft prend en charge SQL Server installations sur les services d’infrastructure cloud tels
qu’Azure Virtual Machine, Amazon EC2 et Google Cloud.
Les fournisseurs de système d’exploitation hôte publient des hyperviseurs pris en charge pour leurs systèmes.
La liste suivante inclut quelques exemples :
Quels hyperviseurs sont certifiés pour exécuter Red Hat Enterprise Linux ?
Modifications, erreurs et bogues du guide du serveur Ubuntu
Ordinateurs virtuels SUSE pris en charge sur Hyper-V
Recherchez dans la documentation du système d’exploitation l’hyperviseur actuel et mis à jour pris en charge
sur des versions spécifiques du système d’exploitation.
SQL Server en cours d’exécution dans des conteneurs Linux

Cette section décrit les stratégies de prise en charge et les configurations SQL Server en cours d’exécution dans
des conteneurs Linux.
SQL Server est une application qui s’exécute dans l’espace utilisateur d’un conteneur Linux. SQL Server et ses
dépendances dans le conteneur SQL Server effectuer des appels vers le système d’exploitation hôte sous-jacent
et son noyau. Différents systèmes d’exploitation Linux sont combinés à différents ensembles d’applications
d’espace utilisateur et de noyau Linux qui sont bien testés en combinaison avec SQL Server. Bien qu’il soit
possible d’exécuter SQL Server dans une configuration non testée ou non gérée de combinaisons conteneur et
hôte, Microsoft ne recommande pas cette opération. Nous 5 000 000 configurations qui utilisent les instructions
suivantes. Ces instructions dictent les configurations bien testées et pris en charge pour l’exécution SQL Server
conteneurs Linux.
Les instructions et exemples suivants s’appliquent à la prise en charge des déploiements SQL Server sur Linux
conteneur.
Conseils
1. Le système d SQL Server de conteneur doit correspondre au système d’exploitation hôte du conteneur en
termes de distribution et de version principale.
2. Un déploiement SQL Server sur Linux conteneurs prend en charge le même ensemble de plateformes pris en
charge que pour les SQL Server sur Linux en cours d’exécution dans des charges de travail non
conteneurisées. Pour plus d’informations, voir conseils d’installation SQL Server sur Linux.
Exemples de configurations prise en charge
SQL Server 2019 sur des conteneurs Red Hat 7.x s’exécutant sur un hôte Red Hat 7.x
SQL Server 2017 sur un conteneur Ubuntu 16.04 s’exécutant sur un hôte Ubuntu 16.04
SQL Server 2017 sur un conteneur SLES 12.x s’exécutant sur un hôte SLES 12.x
SQL Server 2017 sur un conteneur Ubuntu 16.04 s’exécutant sur une machine virtuelle Ubuntu 16.04
hébergée sur le système d’exploitation Windows
Exemples de configurations non pris en place
SQL Server 2017 sur des conteneurs Red Hat 7.6 s’exécutant sur un hôte de conteneur Ubuntu
Une distribution du système d’exploitation Linux qui n’est pas en correspondance entre le
conteneur et l’hôte
SQL Server 2017 sur un conteneur Ubuntu 16.04 s’exécutant sur un hôte Ubuntu 18.04
Une version du système d’exploitation Linux qui n’est pas en correspondance entre le conteneur et
l’hôte
SQL Server 2017 sur un conteneur CentOS sur un hôte de conteneur CentOS (CentOS n’est pas
une distribution de système d’exploitation Linux prise en charge pour SQL Server sur Linux.
Microsoft résoudrea uniquement les problèmes reproductibles sur une configuration prise en
charge.)
L’image de conteneur Linux SQL Server 2017 est disponible dans le Registre de conteneur. Vous pouvez utiliser
l’image Linux dans vos scénarios de DevOps de production, de pipeline CI/CD ou de production. Pour plus
d’informations, voir la page de documentation relative au déploiement de conteneur.
Pour plus d’informations sur la prise en charge des composants dans le conteneur et le système d’exploitation
hôte par les fournisseurs de systèmes d’exploitation, consultez les canaux suivants :
Red Hat Enterprise Matrix de compatibilité des conteneurs Linux
Stratégie de prise en charge des conteneurs Red Hat
SQL Server en cours d’exécution dans Windows conteneurs

SQL Server déploiements de Windows ne sont pas couverts par la prise en charge. Pour le développement et le
test, créez vos propres images de conteneur personnalisées à SQL Server dans Windows conteneurs. Les
exemples de fichiers sont disponibles sur GitHub mais sont fournis pour référence uniquement.
SQL Server Conteneurs en cours d’exécution sur des orchestrators de

conteneur
Microsoft prend en charge le déploiement et la gestion SQL Server conteneurs à l’aide d’OpenShift et de
Kubernetes.
À partir SQL Server 2019, vous pouvez déployer le SQL Server big data cluster sur Kubernetes. Examinez les
plateformes Kubernetes prise en charge dans les notes de publication SQL Server 2019 Big Data Clusters
dans la section Prise en charge.
Personnalisation de SQL Server conteneurs

La création de conteneurs SQL Server Linux personnalisés est prise en charge lorsqu’elle est personnalisée par-
dessus les conteneurs de base SQL Server téléchargés à partir de MCR (Registre de conteneur), ainsi que de
vous assurer que vous ne modifiez pas l’emplacement aux emplacements : SQL directories/binaries/licenses
/opt/mssql/, /usr/share/doc/ qui, en cas de modification incorrecte, risque de ne pas démarrer le processus SQL
Server.
Vous pouvez également créer vos propres images de conteneur SQL Server à partir de zéro, étant donné que
l’image de base du conteneur du système d’exploitation Linux utilisée pour générer l’image de conteneur SQL
Server personnalisée correspond aux plateformes prises en charge pour SQL Server sur Linux et que vous
suivez les instructions mentionnées ci-dessus.
Dans le cadre de la résolution des problèmes, si le conteneur personnalisé SQL Server des problèmes de
démarrage ou une autre exception/erreur SQL Server, Microsoft peut vous obliger à désinstaller la
personnalisation ou à ajouter des outils ou des packages spécifiques pour résoudre et répliquer le problème. Si
le problème ne se produit pas après la suppression de la personnalisation, Microsoft ne prend pas en charge la
personnalisation ou le script personnalisé.
SQL personnalisation de conteneur n’est pas prise en charge pour une utilisation dans d’autres produits
Microsoft qui utilisent des conteneurs SQL Linux tels qu’Azure Arc for Data Services, Azure SQL Edge, etc.,
Exemples de configurations prise en charge :
1. Vous téléchargez l’image de conteneur SQL à partir de MCR, puis à l’aide du fichier dockerfile vous
ajoutez des fonctionnalités telles que Polybase, MSDTC, etc., ces modifications ou des modifications
similaires sont pris en charge pour vous aider à créer votre propre image de conteneur SQL
personnalisée.
2. Vous pouvez également créer une image de conteneur SQL Server 2019 personnalisée sur une
plateforme de système d’exploitation Linux prise en charge, comme une image de conteneur UBI
RHEL 8.2 ou des images de base SLES 12.
Exemples de configurations non pris en défaut :
Vous essayez de créer une image personnalisée sur n’importe quelle plateforme Linux qui n’est pas
mentionnée dans la documentation des plateformes prise en charge.
Systèmes de fichiers pris en charge

Si vous installez SQL Server sur Windows, les systèmes de fichiers pris en charge sont NTFS et ReFS. Cela
s’applique aux volumes qui stockent les fichiers de base de données et les fichiers binaires du programme.
Si vous installez SQL Server sur Linux, les systèmes de fichiers pris en charge pour les volumes qui hébergent
les fichiers de base de données sont EXT4 et XFS.
Solutions de haute disponibilité prise en charge

Lorsque vous définissez une solution de haute disponibilité pour SQL Server sur Windows, reportez-vous aux
stratégies et exigences de support dans la stratégie de support de l’Microsoft SQL Server pour le clustering
Microsoft et les conditions préalables,les restrictions et les Recommandations pour les groupes de disponibilité
Always On.
Lorsque vous définissez une solution de haute disponibilité pour SQL Server sur Linux, veuillez passer en revue
les stratégies de support du fournisseur du système d’exploitation spécifiques à la haute disponibilité. Les
environnements de production nécessitent un agent de sécurité, tel que STONITH, pour la haute disponibilité. Un
cluster Linux utilise l’analyse pour retourner le cluster à un état connu. La manière correcte de configurer la
sécurité dépend de la distribution et de l’environnement. Actuellement, l’informatique n’est pas disponible dans
certains environnements cloud. Pour plus d’informations, voir les recommandations et stratégies du fournisseur
de système d’exploitation suivantes :
Stratégies de prise en charge pour les clusters haute disponibilité RHEL - Plateformes de virtualisation
Stratégies de support pour les clusters haute disponibilité RHEL : abonnements, services de support et
accès aux logiciels
Extension haute disponibilité SUSE Linux Enterprise
Pour obtenir la solution de haute disponibilité prise en charge dans SQL Server sur Linux, voir Continuité
d’activité et récupération de base de données - SQL Server sur Linux.
Fonctionnalités non prises en charge

Vous trouverez la liste actuelle des fonctionnalités SQL Server qui ne sont pas pris en charge dans la section des
fonctionnalités et services non pris en charge dans les notes de publication pour SQL Server 2017 sur Linux. Si
vous essayez d’utiliser des composants ou des fonctionnalités répertoriés dans les notes comme non pris en
compte, vous pouvez être face à des symptômes et des erreurs inattendus. Lorsque vous utilisez une
combinaison de fonctionnalités pour votre application ou solution, assurez-vous que l’interopérabilité entre les
fonctionnalités est documentée comme prise en charge. Pour obtenir des conseils, voir Groupes de disponibilité
Always On : interopérabilité (SQL Server).
Stratégie de support
Microsoft fournit un support technique et des correctifs de produit pour les composants SQL Server qui sont
déployés sur le système d’exploitation, les systèmes de fichiers, les hyperviseurs et les architectures matérielles
pris en charge conformément à la documentation du produit. Microsoft peut fournir une assistance technique
limitée ou aucune assistance technique pour les composants logiciels SQL Server qui sont déployés sur des
systèmes d’exploitation, des systèmes de fichiers, des hyperviseurs et des plateformes matérielles non pris en
charge.
Si vous déployez SQL Server sur un système d’exploitation, un système de fichiers ou un hyperviseur non pris
en charge, vous risquez de ne pas être à l’même comportement et de connaître les résultats. Lorsque vous
dépanner de tels problèmes, l’équipe de support Microsoft peut vous demander de reproduire le problème sur
une combinaison prise en charge du système d’exploitation, du système de fichiers, de l’hyperviseur et de
l’architecture matérielle. Dans ces circonstances, Microsoft peut ne pas être en mesure de fournir une prise en
charge ou une résolution du problème si le problème se produit uniquement dans la combinaison non prise en
charge du système d’exploitation, du système de fichiers, de l’hyperviseur ou de l’architecture.
Lorsque vous dépanner les problèmes qui se produisent lorsque vous utilisez une solution ou une application
qui est conçue à l’aide de SQL Server, le support Microsoft tente d’isoler la cause du problème sur la source de
couche matérielle ou logicielle spécifique. Le problème peut se faire soit dans le logiciel SQL Server, soit dans les
composants du système d’exploitation avec SQL Server interaction. Si le problème est en cours SQL Server, le
support Microsoft fournit des solutions de résolution et des solutions de contournement appropriées pour le
problème. Si le problème se trouve dans le comportement du système d’exploitation, le Support Microsoft vous
renvoie au fournisseur du système d’exploitation pour le suivi et la résolution. Pour les systèmes d’exploitation
pris en charge, le Support Microsoft collaborera avec le fournisseur de support du système d’exploitation pour
vous offrir une résolution commercialement utilisable.
Avant de déployer SQL Server sur une version spécifique d’un système d’exploitation, consultez la
documentation du produit pour SQL Server et vérifiez auprès du fournisseur du système d’exploitation les
conditions de prise en charge requises pour l’ensemble de la solution que vous construisez pour vous assurer
que les différents composants impliqués sont compatibles et pris en charge. Contactez le fournisseur du
système d’exploitation à propos des stratégies de support qui s’appliquent aux stratégies de support
supplémentaires pour la virtualisation, le stockage et les couches matérielles.
Microsoft prendra en charge l’utilisation d’images de conteneur officielles publiées par Microsoft dans les
différents référentiels de conteneurs. Si vous utilisez des images SQL Server conteneur d’autres contributeurs, le
Support Microsoft peut vous demander de reproduire le problème sur l’image de conteneur officielle. Cette
étape peut être nécessaire pour exclure la possibilité que des personnalisations ou des modifications apportées
à l’image de conteneur privé contribuent au problème.
Si le problème est isolé du comportement du moteur de conteneur, vous devez travailler avec le fournisseur du
moteur de conteneur pour résoudre le problème.
Microsoft peut ne pas être en mesure de fournir un support technique si vous utilisez une fonctionnalité non
prise en charge ou si vous utilisez une fonctionnalité de manière non prise en charge ou non.
SQL Server dans Azure

Si vous avez déployé SQL Server sur une machine virtuelle dans Azure, les stratégies de support pour Azure
s’appliquent lorsque vous dépanner les problèmes. Voir distributions Linux approuvées sur Azure.
Si vous déployez des SQL Server sur d’autres solutions ou plateformes cloud, consultez le fournisseur de
solutions cloud sur leurs stratégies spécifiques qui régissent la production ou le support commercial.
Cycle de vie du produit

SQL Server suit la politique de cycle de vie fixe pour obtenir la prise en charge et les mises à jour. Voir les
informations de cycle de vie des produits et services de recherche pour le cycle de vie et la phase (ordinaire,
étendu et hors support) pour chaque version du produit.
Les Service Packs sont publiés pour SQL Server version 2016. Le support prend fin 12 mois après les
prochaines publication du Service Pack ou à la fin du cycle de vie du support du produit, selon le cas. Pour plus
d’informations, consultez la politique de cycle de vie fixe.
Aucun Service Pack ne sera publié à partir SQL Server 2017. Pour plus d’informations, voir SQL Server Service
Packs ne sont plus disponibles depuis SQL Server 2017.
Pour les mises à jour qui commencent à SQL Server 2017, nous vous recommandons d’appliquer la dernière
mise à jour cumulative (ou une mise à jour cumulative publiée au cours de l’année précédente) pour la version
correspondante. L’équipe de support peut vous obliger à appliquer une cu spécifique qui résout un problème
spécifique lorsque vous dépanner un problème.
Les systèmes d’exploitation suivent leur propre cycle de vie. Contactez le fournisseur du système à propos de la
période de cycle de vie applicable et des versions pris en charge.
Obtenir l’assistance de Microsoft

Il existe de nombreux canaux par le biais des lesquels vous pouvez obtenir la prise en charge de SQL Server. Si
vous rencontrez un problème qui affecte un déploiement local de SQL Server, vous pouvez examiner les options
de support pour les utilisateurs professionnels afin d’obtenir une assistance de l’équipe de support technique. Si
vous avez déployé SQL Server dans un environnement cloud Azure, vous pouvez envoyer des demandes de
support à partir du support technique du portail de gestion Azure.
Vous pouvez également soumettre votre rapport de problème ou votre suggestion de produit au site Connecter.
En outre, vous pouvez interagir avec l’équipe SQL Server’ingénierie en utilisant les options suivantes :
Stack Exchange (tag sql-server) : questions sur l’administration de la base de données
Stack Overflow (tag sql-server) : questions de développement
Forums MSDN - Questions techniques
Reddit - Discutez SQL Server
Obtenir la prise en charge des fournisseurs de système d’exploitation

Linux
Si le problème technique que vous découvrez n’existe pas dans le produit SQL Server mais qu’il se produit dans
le système d’exploitation, vous pouvez travailler directement avec le fournisseur du système d’exploitation pour
résoudre le problème. Vous pouvez contacter les équipes de support des fournisseurs de systèmes
d’exploitation en utilisant les canaux suivants :
Système d’exploitation Ubuntu
Système d’exploitation Red Hat
Système d’exploitation SUSE

produits.
Le groupe de disponibilité AlwaysOn reste à l’état
de résolution après un SQL Server
Cet article vous aide à résoudre le problème où le groupe de disponibilité AlwaysOn qui contient la base de
données SSISDB reste à l’état de résolution après un SQL Server.
Symptômes
Supposons que la base de données SSISDB est membre d’un groupe de disponibilité AlwaysOn et que ce
groupe de disponibilité échoue pendant qu’un package de SSISDB s’exécute de manière synchrone. Dans ce cas,
le groupe de disponibilité peut rester à l’état de résolution sur le réplica principal (désormais anciennement)
jusqu’à ce que l’exécution du package se termine.
Dans ce scénario, l’opération de failover réussit, mais le groupe de disponibilité sur le (nouveau) réplica
secondaire reste à l’état de résolution jusqu’à la fin de l’exécution du package. Pendant ce temps, le journal SQL
Server’erreurs affiche un message semblable à ce qui suit :
Les transactions non qualifiées sont en cours de mise à jour dans la base de données SSISDB pour un
changement d’état des groupes de disponibilité AlwaysOn. Achèvement de la récupération estimé : 0 %. Il
s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise.
L’interrogation de l’état de la session indique que la session qui a été utilisée pour exécuter le travail est dans
l’état ROLLBACK/ROLLBACK. Si l’exécution est terminée, elle peut déclencher des erreurs telles que les suivantes
:

Cause
Ce problème se produit car les threads utilisés pour exécuter le package SSIS sont hors du contrôle du
mécanisme utilisé pour mettre fin à une session SQL Server session. Lorsqu’un package est exécuté de manière
synchrone, cela entraîne l’exécution d’une boucle qui empêche SQL Server de mettre fin à la session tant que
l’exécution du package n’est pas terminée.
Pour contourner ce problème, configurez le package SSIS pour qu’il s’exécute de manière asynchrone.
L’exécution asynchrone du package est le comportement par défaut.
Créer un objet ou un message dynamique pour la
tâche Envoyer un message dans SQL Server
Cet article montre comment mettre à jour la propriété d’un objet SQL Server Integration Services (SSIS) lors de
l’utilisation en créant une expression de propriété.
Introduction
Vous pouvez créer un package SSIS à l’aide SQL Server Business Intelligence Development Studio. Lorsque vous
créez ce package, vous pouvez créer une expression pour une propriété du package SSIS à mettre à jour ou pour
remplir la propriété lors de l’utilisation. Par exemple, si le package SSIS contient une tâche Envoyer un message,
vous pouvez créer une expression pour la propriété Subject et pour la MessageSource propriété. Vous pouvez
utiliser l’expression de propriété Subject pour mettre à jour dynamiquement l’objet d’un message électronique.
Vous pouvez utiliser l’expression de propriété pour mettre à jour dynamiquement des variables dans le message
électronique, telles que des variables remplies par une transformation de nombre MessageSource de lignes.
Cet article explique comment créer un objet ou un message dynamique pour la tâche Envoyer un message.
Voici un exemple d’expression de propriété pour la propriété Subject dans une tâche Envoyer un message.
"Package>>> " + @[System::PackageName] +" was executed at>>> " + (DT_WSTR, 40) @[System::StartTime] + " by
user>>> "
+ @[System::UserName] + " on Machine>>> " + @[System::MachineName]
Si vous utilisez cet exemple d’expression de propriété, l’objet d’un message électronique est mis à jour
dynamiquement. L’objet inclut les informations suivantes :
Informations textuelles Dans cet exemple, l’objet du message électronique inclut les Package>>> informations
textuelles.
Variables système
Le message électronique inclut les variables système suivantes :
PackageName
Nom du package.
StartTime
Heure d’exécution du package.
UserName
Utilisateur qui a exécuté le package.
MachineName
Nom de l’ordinateur sur lequel le package a été exécuté.
Vous pouvez également inclure plus d’informations dans l’expression, telles qu’une variable définie par
l’utilisateur. Par exemple, une tâche de Flow peut inclure une transformation de nombre de lignes avant la tâche
Envoyer un message. (La transformation Nombre de lignes est utilisée pour compter les lignes.) La
transformation Nombre de lignes remplit une variable définie par l’utilisateur nommée @myrowcount . Cette
variable stocke les informations de nombre dans le flux de données.
Pour spécifier qu’un message électronique ne doit être envoyé que si le nombre de lignes est inférieur à une
certaine valeur, modifiez le flux de contrôle en utilisant des contraintes de priorité. Pour cela, procédez comme
suit :
1. Dans SQL Server Business Intelligence Development Studio, cliquez avec le bouton droit sur Flow tâche,
puis cliquez sur Ajouter une contrainte de priorité.
2. Double-cliquez sur la contrainte de priorité que vous avez créée.
3. Dans la boîte de dialogue Éditeur de contraintes de priorité, cliquez sur Expression et contrainte
dans l’opération d’évaluation.
4. Dans la zone Expression, tapez l’expression : @myrowcount < 2
5. Dans la boîte de dialogue Éditeur de contraintes de priorité, cliquez sur OK.

Si moins de deux lignes sont traitées dans le flux de données, un message électronique est envoyé.
En outre, vous pouvez utiliser la tâche Envoyer un courrier électronique dans le cadre d’un handler d’erreurs. Par
exemple, vous pouvez envoyer un message électronique aux administrateurs lorsqu’un package SSIS ne
s’exécute pas. Pour ce faire, créez un handler d’événement OnError pour le package, puis ajoutez une tâche
d’envoi de courrier au handler d’événements. Créez une expression de propriété d’objet qui capture l’heure
d’exécution du package, l’heure de début du conteneur ou l’heure de début du handler d’événements à partir
des variables système pertinentes. Par exemple, créez une expression semblable à ce qui suit :
"Error in the task: " + @[System::SourceName] + "with the ID: " + @[System::SourceID]
+ " has failed at: " + (DT_WSTR, 20) @[System::ContainerStartTime] + "."
Cet exemple d’expression utilise les variables système suivantes :

StartTime : heure d’exécution du package.
ContainerStartTime : heure de début du conteneur.
EventHandlerStartTime : heure de début du handler d’événements.
Références
Pour plus d’informations, consultez les rubriques suivantes dans SQL Server Books Online:
Utilisation d’expressions de propriétés dans les packages
How to: Create a Property Expression
Expressions des services d’intégration avancée
Contraintes de priorité
Définition des contraintes de priorité sur les tâches et les conteneurs
Integration Services Event Handlers
Une erreur 0xC0202009 se produit lorsque SSIS
lance un cast de paramètre dans SQL Server
Cet article vous aide à résoudre l’erreur 0xC0202009 qui se produit lorsque Microsoft SQL Server Integration
Services (SSIS) fait une cast de paramètres dans SQL Server.
Symptômes
Lorsque vous exécutez un package SSIS, l’exécution échoue en raison d’une erreur de cast de paramètres et vous
recevez le message d’erreur suivant :
Code : 0xC0202009
Source : Tâche de Flow données
Description : Code d’erreur SSIS DTS_E_OLEDBERROR. Une erreur OLE DB s’est produite. Code d’erreur :
0x80040E21.
Un enregistrement OLE DB est disponible. Source : « Microsoft SQL Server Native Client 11.0 »
Hresult : 0x80040E21 Description : « Valeur de caractère non valide pour la spécification de cast ».
Pour un composant source OLE DB, lorsque vous avez une tâche de flux de données qui contient une requête
paramétisée, vous pouvez être face à ce problème. Par exemple, vous avez la requête suivante :
SELECT mydate
FROM dbo.myTable
WHERE mydate >= convert (char, dateadd(year,-1,cast( ? as datetime)))
NOTE
Ce problème se produit uniquement si vous essayez d’utiliser un composant source OLE DB avec des paramètres dans la
chaîne de requête. Un marqueur de paramètre est mappé à un paramètre1 de variable utilisateur SSIS défini ? en tant
que chaîne SSIS 20080122 .
Cause
Le problème se produit en raison du changement de comportement dans la façon dont OLE DB gère les
paramètres. Dans Microsoft SQL Server 2012, la nouvelle procédure stockée de , remplacement de jeu renvoie
un sp_describe_undeclared_parameters résultat différent pour le type de fmtonly paramètre. Cette modification
est de par sa conception.
Dans l’exemple de requête de la section Symptômes, le comportement d’origine doit être ? décrit comme .
char(8) Toutefois, la nouvelle sp_describe_undeclared_parameters indique que ? c’est le datetime cas. Par
conséquent, la distribution interne de la chaîne vers celle qui est gérée par le fournisseur datetime OLE DB
renvoie le message d’erreur.
Résolution
Pour résoudre ce problème, réécrivez la requête pour ajouter un cast explicite supplémentaire au type de
données d’origine. Renvoie ensuite sp_describe_undeclared_parameters le type correct et attendu. Pour résoudre
ce problème dans la requête d’exemple décrite dans la section Symptômes, mettez à jour la requête comme suit
:
SELECT mydate
FROM dbo.myTable
WHERE mydate >= convert(char ,dateadd(year,-1, cast( cast( ? as char(8)) as datetime)))
Vous recevez un message d’erreur « Chargement
d’erreur » lorsque vous essayez d’exécuter un
package SQL Server Integration Services
Cet article vous aide à résoudre les échecs de chargement de package qui se produisent lorsque SSIS ne peut
pas déchiffrer le mot de passe stocké dans le package.
Symptômes
Dans Microsoft SQL Server, lorsque vous essayez d’exécuter un package SSIS (SQL Server Integration Services)
à partir de Business Intelligence de Microsoft SQL Server Studio ou à l’aide de l’outil de ligne de commande SQL
Server Execute Package Utility (Dtexec.exe), vous recevez le message d’erreur suivant :
Erreur lors du chargement de PackageName : échec du déchiffrement du nœud XML protégé «

PackagePassword » avec l’erreur 0x8009000B « Clé non valide pour une utilisation dans l’état spécifié ».
Vous n’êtes peut-être pas autorisé à accéder à ces informations. Cette erreur se produit en cas d’erreur de
chiffrement. Vérifiez que la clé correcte est disponible.
NOTE
L’espace réser vé PackageName est un espace réservé pour le nom du package SSIS que vous essayez d’exécuter.
Ce comportement se produit lorsque vous essayez d’exécuter le package SSIS à l’aide d’un autre ordinateur ou
d’un autre compte d’utilisateur que l’ordinateur et le compte d’utilisateur qui ont été utilisés pour créer le
package SSIS.
Cause
Ce comportement se produit si la valeur de la propriété dans le package SSIS est définie pour fournir la quantité
maximale de protection pour la propriété Password dans le ProtectionLevel package SSIS. Par défaut, la valeur
de la ProtectionLevel propriété est définie sur Encr yptSensitiveWithUserKey . La valeur
Encr yptSensitiveWithUserKey chiffre toutes les propriétés du package SSIS qui sont considérées comme
sensibles, telles que la propriété Password. Lorsque le même compte d’utilisateur et le même ordinateur qui ont
été utilisés pour créer le package SSIS sont utilisés pour exécuter le package SSIS, le package SSIS se déchiffre
automatiquement et aucun message d’erreur n’est généré. Toutefois, lorsqu’un autre compte d’utilisateur ou un
autre ordinateur est utilisé pour exécuter le package SSIS, la valeur Encr yptSensitiveWithUserKey de la
propriété est en jeu et la propriété Password du package SSIS reste ProtectionLevel chiffrée. Lorsque cela se
produit, un message d’erreur est généré.
Résolution
Pour résoudre ce problème, modifiez la valeur de la ProtectionLevel propriété dans le package SSIS.
Pour plus d’informations, voir les rubriques suivantes dans SQL Server Books Online :
Considérations en matière de sécurité pour les services d’intégration
Définition du niveau de protection des packages
Références
Pour plus d’informations sur un problème similaire, voir le package SSIS ne s’exécute pas lorsqu’il est appelé à
partir d’SQL Server’étape du travail de l’agent.
Impossible de préparer l’insertion en bloc SSIS pour
l’insertion de données sur les systèmes activés pour
le contrôle d’utilisateur
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez d’exécuter un package SSIS sur
des systèmes où le contrôle de compte d’utilisateur (UAC) est activé.
Symptômes
Vous créez un package SQL Server Integration Services (SSIS) qui possède un composant de destination
SQL Server dans une tâche de flux de données.
Vous essayez d’exécuter ce package sur les systèmes où le contrôle de compte d’utilisateur (UAC) est
activé (par exemple Vista ou Windows 7) à l’aide de l’une des méthodes suivantes :
Business Intelligence Development Studio (BIDS)
SQL Server Management Studio (SSMS) Object Explorer
DTExec.exe
DTExecUI.exe
Dans ce scénario, vous pouvez obtenir un message d’erreur semblable à ce qui suit :
SQL Server Erreur de destination : impossible de préparer l’insertion en bloc SSIS pour l’insertion de
données. [SSIS. Erreur du pipeline : le composant « SQL Server Destination » a échoué à la phase de pré-
exécution et a renvoyé le code d’erreur 0xC0202071.
NOTE
Vous n’obtenez pas cette erreur si vous exécutez le package sous le compte d’administrateur intégré créé lors de
l’installation du système d’exploitation. Toutefois, vous recevez ce message pour tout autre utilisateur, y compris ceux qui
sont membres du groupe Administrateurs local.
Le problème ne se produit pas lorsque vous exécutez le même package SSIS qu’un travail SQL Server agent.
Une fois SQL 2008 Service Pack 2 installé, le texte de l’erreur DTS_E_BULKINSERTAPIPREPARATIONFAILED
(0xC0202071) a été modifié : Impossible de copier en bloc les données. Vous devrez peut-être exécuter ce
package en tant qu’administrateur.
Cette modification a été réalisée pour faciliter la compréhension de l’action corrective requise, comme décrit dans la
section de résolution de cette ko.
Cause
Sur les systèmes où le contrôle de compte d’utilisateur est activé, lorsqu’une application (telle que SSIS) est
lancée par un compte membre du groupe Administrateurs, elle obtient deux jetons de sécurité, l’un avec des
privilèges faibles et l’autre un jeton élevé. Le jeton élevé est utilisé uniquement lorsque l’application est
explicitement exécuté sous un compte Administrateur en choisissant Exécuter en tant qu’administrateur. Par
défaut, SSIS utilise toujours le jeton à faibles privilèges, ce qui entraîne un échec lors de la connexion à SQL
Destination.
Résolution
Utilisez l’une des méthodes suivantes pour contourner le problème :
Si vous exécutez le package depuis SQL Server Management Studio (SSMS) ou Business Intelligence
Development Studio (BIDS) ou DTExecUI.exe, lancez ces outils sous le compte Administrateur élevé. Pour
ce faire, cliquez sur Démarrer, pointez sur Tous les programmes, pointez sur SQL Ser ver 2005 ou
SQL Ser ver 2008 , cliquez avec le bouton droit sur l’outil que vous utilisez, puis cliquez sur Exécuter en
tant qu’administrateur. Cette opération lance l’application avec des privilèges élevés du compte
Administrateur intégré et le package s’exécute correctement.
De même, si vous exécutez le package à l’aide DTExec.exe lancez-le à partir d’une invite de commandes
avec élévation de élévation de niveaux. Vous pouvez démarrer l’invite de commandes avec élévation de
pouvoir en cliquant sur Démarrer, sur Tous les programmes, sur Accessoires, sur Invite de
commandes avec le bouton droit, puis sur Exécuter en tant qu’administrateur.
NOTE
Si vous ne vous connectez pas à l’ordinateur en tant qu’administrateur, vous êtes invité à fournir le compte
d’administrateur. Lorsque vous êtes invité à fournir le compte d’administrateur, tapez le nom d’utilisateur et le mot
de passe de l’administrateur dans la boîte de dialogue Contrôle de compte d’utilisateur. Cliquez ensuite sur OK .
Remplacez les SQL Server destination dans les tâches de flux de données qui échouent par des
composants OLE DB Destination qui pointent vers le même gestionnaire de connexions SQL Server
données.
Utilisez un compte qui n’est pas membre du groupe Administrateurs local après avoir attribué à ce
compte le droit d’utilisateur Créer des objets globaux. Pour cela, procédez comme suit :
1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Stratégie de sécurité
locale.
2. Développez les stratégies locales, puis cliquez sur Attribution des droits d’utilisateur.
3. Dans le volet droit, double-cliquez sur Créer des objets globaux.
4. Dans la boîte de dialogue Paramètres de stratégie de sécurité locale, cliquez sur Ajouter.
5. Dans la boîte de dialogue Sélectionner des utilisateurs ou un groupe, cliquez sur les comptes
d’utilisateurs que vous souhaitez ajouter, cliquez sur Ajouter, puis sur OK.
6. Cliquez sur OK .
NOTE
Lorsque vous utilisez un compte qui n’est pas membre du groupe Administrateurs local, le UAC n’entre pas en jeu.
Utilisation du contrôle de compte d’utilisateur (UAC) dans Windows Vista
Aide guidée : ajuster les paramètres de contrôle de compte d’utilisateur Windows 7 et Windows 8
Qu’est-il ad arrivé à la commande Exécuter en tant que ?
DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER
lorsque vous utilisez le gestionnaire de connexion Oracle
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez le gestionnaire de connexions
Oracle.
Symptômes
Envisagez le scénario suivant pour l’une SQL Server :
Vous concevez un package SQL Server Integration Services (SSIS) à l’aide de Business Intelligence
Development Studio (BIDS).
Dans votre package, vous vous connectez à un serveur Oracle à l’aide d’un fournisseur OLEDB pour Oracle et
utilisez le client Oracle 10G ou 11G.
Vous utilisez le fichier de configuration du package pour définir toutes les propriétés de connexion de la
connexion Oracle lors de l’utilisation.
Dans ce scénario, si vous exécutez le package à partir de BIDS, vous obtenez le message d’erreur suivant
« Erreur : 0xC0202009 package, gestionnaire de connexions « Fournisseur OLEDB » : code d’erreur SSIS
DTS_E_OLEDBERROR. Une erreur OLE DB s’est produite. Code d’erreur : 0x80040E21.
Un enregistrement OLE DB est disponible. Source : « Composants du service Microsoft OLE DB » Hresult :
0x80040E21 description : « Erreurs générées par l’opération OLE DB en plusieurs étapes. Vérifiez chaque
valeur d’état OLE DB, si disponible. Aucun travail n’a été effectué. »
Error: 0xC020801C at Data Flow Task, Oracle OLEDB Source [1]: SSIS Error Code
DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. L’appel de méthode
AcquireConnection au gestionnaire de connexions « FOURNISSEUR OLEDB » a échoué avec un code d’erreur
0xC0202009. Des messages d’erreur peuvent être publiés avant cela, avec plus d’informations sur la raison
de l’échec de l’appel de la méthode AcquireConnection.
Error: 0xC0047017 at Data Flow Task, DTS. Pipeline : le composant « Oracle OLEDB Source » (1) a échoué à
la validation et a renvoyé le code d’erreur 0xC020801C. »
Cause
Cela est dû au fait que la propriété Catalogue initial dans le fichier de configuration n’est pas reconnue par le
fournisseur Oracle. Ce paramètre est vide pour le gestionnaire de connexions Oracle dans le fichier de
configuration.
Par exemple, le fichier de configuration XML suivant est généré lorsque vous utilisez BIDS pour créer un package
SSIS qui se connecte à un serveur Oracle :
<?xml version="1.0"?>
<DTSConfiguration>
<DTSConfigurationHeading>
<DTSConfigurationFileInfo GeneratedBy="MyUserName" GeneratedFromPackageName="MyPackage"
GeneratedFromPackageID="<guid>" GeneratedDate="2/22/2010 9:00:00 PM"/>
</DTSConfigurationHeading>
<Configuration ConfiguredType="Property"
Path="\Package.Connections[MyConnectionManager].Properties[ConnectionString]" ValueType="String">
<ConfiguredValue>Data Source=MyServerName;User ID=MyAccount;Password=MyPassword; **Initial
Catalog=**; Provider=MSDAORA.1;Persist Security Info=True;</ConfiguredValue>
</Configuration>
</DTSConfiguration>
Résolution
Supprimez la case à cocher du catalogue initial lors de la création ou de la modification du fichier de
configuration via le Concepteur BIDS.
Par exemple, la version fixe de l’exemple de fichier de configuration indiqué dans la section Cause sera la
suivante :
<?xml version="1.0"?>
<DTSConfiguration>
<DTSConfigurationHeading>
<DTSConfigurationFileInfo GeneratedBy="MyUserName" GeneratedFromPackageName="MyPackage"
GeneratedFromPackageID="<guid>" GeneratedDate="2/22/2010 9:00:00 PM"/>
</DTSConfigurationHeading>
<Configuration ConfiguredType="Property"
Path="\Package.Connections[MyConnectionManager].Properties[ConnectionString]" ValueType="String">
<ConfiguredValue>Data Source=MyServerName;User
ID=MyAccount;Password=MyPassword;Provider=MSDAORA.1;Persist Security Info=True;</ConfiguredValue>
</Configuration>
</DTSConfiguration>
INFO : Limitations du pilote ODBC Microsoft Oracle et du fournisseur OLEDB
Séquencement de messages (données de licence
non valides) SQL Server Business Intelligence
Development Studio (BIDS) avec App-V
Cet article explique la stratégie de prise en charge concernant le séquencement SQL Server Business Intelligence
Development Studio (BIDS) ou SQL Server Data Tools (SSDT).
Version du produit d’origine : SQL Server, SQL Server Management Studio
Résumé
Lorsque vous tentez de virtualiser (séquence) Business Intelligence de Microsoft SQL Server Development
Studio (BIDS) ou SQL Server Data Tools (SSDT) avec Microsoft Application Virtualization (App-V), le package
résultant échoue avec l’erreur suivante :
Données de licence non valides
Le séquencement d’une version SQL Server Business Intelligence Development Studio (BIDS) ou SQL Server
Data Tools (SSDT) n’est pas pris en charge. Cela inclut, mais n’est pas limité à toutes les versions de SQL Server, y
compris SQL Server Management Studio.
Les points de contrôle SSIS ne sont pas honorés
pour les éléments de conteneur de boucle For ou
de boucle Foreach
Cet article vous aide à contourner le problème où les points de contrôle SQL Server Integration Services (SSIS)
ne sont pas honorés pour les éléments de conteneur ou pour For Loop Foreach Loop ceux-ci.
Symptômes
Vous installez Microsoft SQL Server Integration Services sur un ordinateur.
Vous créez un package SSIS qui contient un élément de conteneur pour boucle suivi d’un conteneur de
séquence.
Les éléments Conteneur de boucle For et Conteneur de séquence ont l’une des valeurs suivantes :
An Execute SQL Task (OR)
Deux ou plusieurs tâches exécuter SQL qui s’exécutent en parallèle.
Vous activez le paramètre Point de contrôle pour le package SSIS.
Vous exécutez le package SSIS
Le conteneur For Loop se termine et l’exécution du package est exécutée sur le conteneur sequence.
Vous devez prendre l’une des mesures ci-dessous :
Pour les packages ayant une seule tâche Exécuter SQL, vous arrêtez l’exécution du package pendant
que la tâche est en cours d’exécution.
Pour les packages exécutant plusieurs tâches Execute SQL, vous arrêtez l’exécution du package ou
vous faites face à un échec dans l’une de ces tâches alors que d’autres tâches Execute SQL sont
toujours en cours d’exécution.
Le package SSIS s’exécute à nouveau.
Dans ce scénario, le package commence à partir For Loop du conteneur au lieu du Sequence conteneur.
NOTE
Ce problème n’est pas lié à l’exécution SQL tâche. Cela peut également se produire avec d’autres tâches.
Cause
Ce comportement est inhérent au produit. Les données de point de contrôle ne sont pas enregistrées pour
For Loop les éléments conteneur et Foreach Loop conteneur. Si un conteneur enfant de la boucle s’exécute
correctement, il n’est pas enregistré dans le fichier de point de contrôle. Ainsi, lorsque le package est redémarré,
les tâches de chacun de ces éléments de conteneur sont réexécutées.
Pour contourner le problème, encapsulez le conteneur ou le For Loop Foreach Loop conteneur à l’intérieur d’un
Sequence conteneur.
Le package SSIS ne s’exécute pas lorsqu’il est appelé
à partir d’une étape SQL Server travail de l’agent
de sécurité
Cet article vous aide à résoudre le problème qui se produit lorsque vous appelez un package SSIS à partir d’une
étape SQL Server travail de l’agent.
Symptômes
Lorsque vous appelez un package Microsoft SQL Server Integration Services (SSIS) à partir d’une étape de
travail SQL Server Agent, le package SSIS ne s’exécute pas. Toutefois, si vous ne modifiez pas le package SSIS, il
s’exécutera correctement en dehors SQL Server Agent.
Résolution
Pour résoudre ce problème, utilisez l’une des méthodes suivantes. La méthode la plus appropriée dépend de
l’environnement et de la raison de l’échec du package. Les raisons de l’échec du package sont les suivantes :
Le compte d’utilisateur utilisé pour exécuter le package sous SQL Server Agent diffère de l’auteur du package
d’origine.
Le compte d’utilisateur ne dispose pas des autorisations requises pour établir des connexions ou accéder à
des ressources en dehors du package SSIS.
Le package peut ne pas s’exécuter dans les scénarios suivants :
L’utilisateur actuel ne peut pas déchiffrer les secrets du package. Ce scénario peut se produire si le compte
actuel ou le compte d’exécution diffère de l’auteur du package d’origine et que le paramètre de propriété
ProtectionLevel du package ne permet pas à l’utilisateur actuel de déchiffrer les secrets dans le package.
Une connexion SQL Server qui utilise la sécurité intégrée échoue, car l’utilisateur actuel ne peut pas avoir les
autorisations requises.
L’accès aux fichiers échoue car l’utilisateur actuel ne peut pas écrire dans le partage de fichiers accessible par
le gestionnaire de connexions. Par exemple, ce scénario peut se produire avec des fournisseurs de journaux
de texte qui n’utilisent pas de connexion et de mot de passe. Ce scénario peut également se produire avec
n’importe quelle tâche qui dépend du gestionnaire de connexions de fichiers, telle qu’une tâche de système
de fichiers SSIS.
Une configuration de package SSIS basée sur le Registre utilise les HKEY_CURRENT_USER clés de Registre. Les
HKEY_CURRENT_USER clés de Registre sont spécifiques à l’utilisateur.
Une tâche ou un gestionnaire de connexions requiert que le compte d’utilisateur actuel dispose des
autorisations correctes.
Pour résoudre le problème, utilisez les méthodes suivantes :
Méthode 1 : utiliser un compte proxy SQL Server’agent de gestion. Créez un SQL Server proxy agent de
gestion. Ce compte proxy doit utiliser une informations d’identification qui permet à l’agent SQL Server
d’exécuter le travail en tant que compte qui a créé le package ou en tant que compte qui dispose des
autorisations requises.
Cette méthode fonctionne pour déchiffrer les secrets et répond aux exigences clés de l’utilisateur.
Toutefois, cette méthode peut avoir un succès limité, car les clés utilisateur du package SSIS impliquent
l’utilisateur actuel et l’ordinateur actuel. Par conséquent, si vous déplacez le package vers un autre
ordinateur, cette méthode peut toujours échouer, même si l’étape du travail utilise le compte proxy
correct.
Méthode 2 : définissez la propriété du package SSIS ProtectionLevel sur ServerStorage. Modifiez la
propriété SSIS Package ProtectionLevel en ServerStorage. Ce paramètre stocke le package dans une base
de données SQL Server et autorise le contrôle d’accès via SQL Server rôles de base de données.
Méthode 3 : définir la propriété du package SSIS ProtectionLevel sur EncryptSensitiveWithPassword .
Modifiez la propriété du package SSIS ProtectionLevel sur EncryptSensitiveWithPassword . Ce paramètre
utilise un mot de passe pour le chiffrement. Vous pouvez ensuite modifier la ligne de commande SQL
Server l’étape du travail de l’agent pour inclure ce mot de passe.
Méthode 4 : utiliser les fichiers de configuration du package SSIS. Utilisez les fichiers de configuration du
package SSIS pour stocker des informations sensibles, puis stockez ces fichiers de configuration dans un
dossier sécurisé. Vous pouvez ensuite modifier la propriété afin que le package ne soit pas chiffré et
n’essaie pas d’enregistrer les ProtectionLevel DontSaveSensitive secrets dans le package. Lorsque vous
exécutez le package SSIS, les informations requises sont chargées à partir du fichier de configuration.
Assurez-vous que les fichiers de configuration sont correctement protégés s’ils contiennent des
informations sensibles.
Méthode 5 : Créer un modèle de package. Pour une résolution à long terme, créez un modèle de package
qui utilise un niveau de protection différent du paramètre par défaut. Ce problème ne se produira pas
dans les futurs packages.

1. Connectez-vous en tant qu’utilisateur qui ne fait pas partie du groupe SQLServerSQLAgentUser. Par
exemple, vous pouvez créer un utilisateur local.
2. Créez un package SSIS, puis ajoutez une tâche ExecuteSQL. Utilisez un gestionnaire de connexion OLE DB
pour le fichier msdb local à l’aide de la chaîne suivante
'Windows Authentication' -SQLSourceType: "Direct Input" -SQLStatement: "sp_who" :
3. Exécutez le package pour vous assurer qu’il s’exécute correctement.
4. La ProtectionLevel propriété est définie sur EncryptSensitiveWithPassword .
5. Créez un SQL Server agent de sécurité et une étape de travail. Dans la liste Exécuter en tant que, cliquez
SQL Server Service d’agent pour exécuter l’étape du travail. Le texte de l’historique SQL Server travail de
l’agent affiche des informations semblables à ce qui suit :
Déchiffrer les secrets du package

Le paramètre par défaut de la propriété du package SSIS ProtectionLevel est EncryptSensitiveWithUserKey .
Lorsque le package est enregistré, SSIS chiffre uniquement les parties du package qui contiennent des
propriétés marquées, telles que les mots de passe, les noms d’utilisateur et les sensitive chaînes de connexion.
Par conséquent, lorsque le package est rechargé, l’utilisateur actuel doit satisfaire les exigences de chiffrement
pour les propriétés sensitive à déchiffrer. Toutefois, l’utilisateur actuel n’a pas besoin de satisfaire aux
exigences de chiffrement pour charger le package. Lorsque vous exécutez le package via une étape SQL Server
travail de l’agent, le compte par défaut est SQL Server service d’agent. Ce compte par défaut est probablement
un utilisateur différent de l’auteur du package. Par conséquent, l SQL Server de l’agent peut charger et démarrer
l’étape du travail, mais le package échoue car il ne peut pas terminer une connexion. Par exemple, le package ne
peut pas terminer une connexion OLE DB ou une connexion FTP. Le package échoue car il ne peut pas déchiffrer
les informations d’identification dont il doit avoir besoin pour se connecter.
IMPORTANT
Examinez le processus de développement et l’environnement pour déterminer les comptes nécessaires et utilisés sur
chaque ordinateur. Le paramètre EncryptSensitiveWithUserKey de la propriété ProtectionLevel est un paramètre
puissant. Ce paramètre ne doit pas être réduit, car il provoque d’abord des complications de déploiement. Vous pouvez
chiffrer les packages lorsque vous êtes connecté au compte approprié. Vous pouvez également utiliser l’utilitaire d’invite
de commandes SSIS Dtutil.exe pour modifier les niveaux de protection à l’aide d’un fichier .cmd et du sous-système de
commande de l’agent SQL Server. Par exemple, suivez ces étapes. Étant donné que vous pouvez utiliser l’utilitaire
Dtutil.exe dans des boucles et des fichiers de lots, vous pouvez suivre ces étapes pour plusieurs packages en même temps.
1. Modifiez le package à chiffrer à l’aide d’un mot de passe.

2. Utilisez l’utilitaire Dtutil.exe par le biais d’un système d’exploitation (cmd Exec) SQL Server’agent de
gestion pour modifier la ProtectionLevel propriété en EncryptSensitiveWithUserKey . Ce processus
implique le déchiffrement du package à l’aide du mot de passe, puis le nouveau chiffrement du package.
La clé d’utilisateur utilisée pour chiffrer le package est le paramètre de l SQL Server de l’agent de sécurité
dans la liste Exécuter en tant que.
NOTE
Étant donné que la clé inclut le nom d’utilisateur et le nom de l’ordinateur, l’effet du déplacement des packages
vers un autre ordinateur peut être limité.
Assurez-vous que vous avez des informations détaillées sur l’échec du

package SSIS
Au lieu de vous appuyer sur les détails limités de l’historique des opérations de l’agent SQL Server, vous pouvez
utiliser la journalisation SSIS pour vous assurer que vous avez des informations d’erreur sur l’échec du package
SSIS. Vous pouvez également exécuter le package à l’aide de la commande de sous-système exec au lieu de la
commande de sous-système SSIS.
À propos de la journalisation SSIS
Les fournisseurs de journaux et de journalisation SSIS vous permet de capturer des détails sur l’exécution et les
échecs du package. Par défaut, le package ne journale pas les informations. Vous devez configurer le package
pour journaliser les informations. Lorsque vous configurez le package pour journaliser les informations, des
informations détaillées semblables à ce qui suit s’affichent. Dans ce cas, vous savez qu’il s’agit d’un problème
d’autorisations :
OnError,DOMAINNAME,DOMAINNAME\USERNAME,FTP Task,{C73DE41C-D0A6-450A-BB94-DF6D913797A1},{2F0AF5AF-2FFD-4928-
88EE-1B58EB431D74},4/28/2006 1:51:59 PM,4/28/2006 1:51:59 PM,-1073573489,0x,Unable to connect to FTP server
using "FTP Connection Manager".
OnError,DOMAINNAME,DOMAINNAME\USERNAME,Execute SQL Task,{C6C7286D-57D4-4490-B12D-AC9867AE5762},{F5761A49-

F2F9-4575-9E2B-B3D381D6E1F3},4/28/2006 4:07:00 PM,4/28/2006 4:07:00 PM,-1073573396,0x,Failed to acquire
connection "user01.msdb". Connection may not be configured correctly or you may not have the right
permissions on this connection.
À propos de la commande du sous-système exec et des informations de sortie

À l’aide de l’approche de commande du sous-système exec, vous ajoutez des commutateurs de journalisation de
console détaillées à la ligne de commande SSIS pour appeler le fichier exécutable de ligne de commande SSIS
Dtexec.exe. En outre, vous utilisez la fonctionnalité de travail avancé du fichier de sortie. Vous pouvez également
utiliser l’option Inclure la sortie de l’étape dans l’historique pour rediriger les informations de journalisation vers
un fichier ou vers l’historique des SQL Server de l’agent de journalisation.
Voici un exemple de ligne de commande :
dtexec.exe /FILE "C:\_work\SSISPackages\ProtectionLevelTest\ProtectionLevelTest\AgentTesting.dtsx"

/MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING V /CONSOLELOG NCOSGXMT
La journalisation de la console renvoie des détails qui ressemblent à ce qui suit :
Error: 2006-04-27 18:13:34.76 Code: 0xC0202009 Source: AgentTesting Connection manager "(local).msdb"
Description: An OLE DB error has occurred. Error code: 0x80040E4D. An OLE DB record is available. Source:
"Microsoft SQL Native Client" Hresult: 0x80040E4D Description: "Login failed for user
'DOMAINNAME\username'.". End Error
Error: 2006-04-28 13:51:59.19 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node
"DTS:Property" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized
to access this information. This error occurs when there is a cryptographic error. Verify that the correct
key is available. End Error
Log: Name: OnError Computer: COMPUTERNAME Operator: DOMAINNAME\username Source Name: Execute SQL Task Source
GUID: {C6C7286D-57D4-4490-B12D-AC9867AE5762} Execution GUID: {7AFE3D9E-5F73-42F0-86FE-5EFE264119C8} Message:
Failed to acquire connection "(local).msdb". Connection may not be configured correctly or you may not have
the right permissions on this connection. Start Time: 2006-04-27 18:13:34 End Time: 2006-04-27 18:13:34 End
Log
Références
Pour plus d’informations sur un problème similaire, voir « Erreur de chargement » lorsque vous essayez
d’exécuter un package services d’intégration SQL Server 2005 dans SQL Server 2005
Pour plus d’informations sur l’utilisation de l’utilitaire Dtutil.exe dans les opérations par lots, voir
Comment utiliser l’utilitaire dtutil (Dtutil.exe) pour définir le niveau de protection d’un lot de packages
SSIS (SQL Server Integration Services) dans SQL Server 2005
Pour plus d’informations sur la création de modèles de package, voir Comment créer un modèle de
package dans SQL Server Business Intelligence Development Studio
Pour plus d’informations sur la sécurité du package SSIS et la propriété, voir la rubrique Considérations
de sécurité pour les services d’intégration ProtectionLevel dans SQL Server 2005 Books Online.
Malheureusement, les utilisateurs ne savent pas que les paramètres d’étape du travail d’agent par défaut les
placent dans cet état. Pour plus d’informations sur SQL Server proxies de l’agent de SQL Server et le SSIS,
consultez les rubriques suivantes dans SQL Server 2005 Books Online :
Planification de l’exécution du package dans SQL Server Agent
Création de SQL Server agent de sécurité
L’exécution d’un package SSIS cesse de répondre
lorsque vous activez des transactions DTC pour un
package dans Microsoft SQL Server
Cet article vous aide à résoudre le problème dans lequel l’exécution d’un package SSIS (Microsoft SQL Server
Integration Services) cesse de répondre si vous activez les transactions DTC pour le package et activez la
propriété d’un composant dans une tâche de flux de ValidateExternalMetadata données.
Symptômes
Vous créez un package SSIS dans SQL Server.
Le package SSIS contient une tâche de flux de données et d’autres tâches.
La propriété du package SSIS est définie sur TransactionOption Obligatoire pour utiliser les transactions DTC.
Les autres tâches s’exécutent dans une transaction DTC avant l’exécution de la tâche de flux de données.
Vous ajoutez un composant à la tâche de flux de données.
La ValidateExternalMetadata propriété d’un composant de flux de données est définie sur True.
La tâche de flux de données contient un composant OLE DB Destination dont le mode d’accès aux données
est définie sur Table ou Affichage, ou sur nom de table ou variable de nom d’affichage.
Lorsque vous exécutez le package dans ce scénario, l’exécution cesse de répondre. En outre, si vous déboguer le
package SSIS dans Visual Studio, vous recevez des messages qui ressemblent à ce qui suit dans l’affichage
Progression :
Démarrage du package SSIS « Package.dtsx ».

Informations : 0x4004300A sur Data Flow Task, DTS. Pipeline : la phase de validation commence.
Informations : 0x4001100A sur Package : démarrage de la transaction distribuée pour ce conteneur.
Informations : 0x4004300A sur Data Flow Task, DTS. Pipeline : la phase de validation commence.
Cause
Ce problème se produit car la connexion dans le flux de données n’est pas inscrite dans la transaction DTC. Cela
entraîne le blocage de l’exécution sp_cursoropen de la procédure stockée. Il s’agit d’une fonctionnalité de
conception, car une connexion ne peut pas être inscrite dans une transaction DTC pendant le processus de
validation. Dans le scénario décrit dans la section Symptômes, le processus de validation d’un composant de flux
de données est bloqué lorsque vous exécutez le package, car la connexion dans la tâche de flux de données n’a
pas été inscrite dans la transaction DTC.
Résolution
Pour résoudre ce problème, utilisez l’une des méthodes suivantes :
Définissez ValidateExternalMetadata pour tous les composants de la tâche de flux de données sur False .
Définissez le mode d’accès aux données du composant OLE DB Destination sur l’un des modes suivants :
Table ou affichage - chargement rapide
Nom de la table ou variable de nom d’affichage - chargement rapide
SQL commande
Le mode d’accès aux données table ou affichage est bloqué, mais les autres modes d’accès aux données ne le
sont pas car les différentes commandes émises par le fournisseur de données pour chaque mode d’accès aux
données. Pour obtenir plus de détails sur ce problème, utilisez SQL Server Profiler pour voir les différentes
commandes émises par le fournisseur de données.
Pour plus d’informations sur l’utilisation SQL Server Profiler, voir SQL Server Profiler modèles et
autorisations.
Pour plus d’informations sur la résolution des problèmes de packages SSIS, voir Troubleshooting Package
Development.
Message d’erreur lorsque vous déployez un package
SSIS sur un autre serveur dans SQL Server
Cet article vous aide à résoudre le problème qui se produit lorsque le package SSIS utilise le composant
nettoyage Data Quality Client pour nettoyer les données de flux de données dans un environnement SQL Server.
Version du produit d’origine : SQL Server 2012 Business Intelligence, SQL Server 2012 Developer, SQL Server
2012 Enterprise
Symptômes
Vous créez une conception de package SSIS (SQL Server Integration Services) qui utilise le composant
nettoyage des services de qualité des données (DQS) pour nettoyer les données de flux de données dans un
environnement Microsoft SQL Server 2012 ou SQL Server 2014.
Vous déplacez le package SSIS d’un environnement serveur vers un autre. Par exemple, vous déployez le
package SSIS sur un autre serveur.
Vous mettez à jour le gestionnaire de connexion nettoyage DQS pour qu’il pointe vers le nouveau nom de
serveur.
Dans ce scénario, vous recevez le message d’erreur suivant :
Data Flow Task Name:Error: Microsoft.Ssdqs.Infra.Exceptions.EntryPointException: The Knowledge Base does

not exist [Id : 1000999].
at Microsoft.Ssdqs.Proxy.Database.DBAccessClient.Exec()
at Microsoft.Ssdqs.Proxy.EntryPoint.KnowledgebaseManagementEntryPointClient.DQProjectGetById(Int64
id)
at Microsoft.Ssdqs.Component.DataCorrection.Logic.DataCorrectionComponent.PostExecute()
at
Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostPostExecute(IDTSManagedComponentWrapp
er100 wrapper)
Data Flow Task Name:Error: System.NullReferenceException: Object reference not set to an instance of an
object.
at
Microsoft.Ssdqs.Component.DataCorrection.Logic.DataCorrectionComponent.ProcessChunk(ReadOnlyCollec
tion 1 fieldMappings, ReadOnlyCollection 1 records, CorrectedRecordsStatusStatistics&
correctedRecordsTotalStatusStatistics)
at Microsoft.Ssdqs.Component.DataCorrection.Logic.DataCorrectionComponent.ProcessInput(Int32 inputID,
PipelineBuffer buffer)
at
Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostProcessInput(IDTSManagedComponentWrap
per100 wrapper, Int32 inputID, IDTSBuffer100 pDTSBuffer, IntPtr bufferWirePacket)
Cause
Ce problème se produit lorsque le numéro d’ID de la base de connaissances DQS, tel que 1000999, n’existe pas
sur l’instance de destination de SQL Server dans la base de données DQS_MAIN données.
Le nombre varie chaque fois que vous modifiez et publiez la base de connaissances DQS (KB). Le numéro
d’identification est un identificateur unique pour chaque ko DQS publié et ne correspond qu’à une seule Ko.
Lorsque le package SSIS est persistant dans le fichier .dtsx ou dans la base de données SSISDB, l’ID numérique
de la base de données DQS est mémoriser dans les balises de conception, comme dans l’exemple suivant :
<property dataType="System.Int64" name="KnowledgebaseName" typeConverter="NOTBROWSABLE">1000999

</property>
Le nom du serveur DQS et le numéro de la base de données de la base de données restent cohérents même
lorsque vous déplacez les packages SSIS vers différents serveurs.
Pour vérifier qu’il en est la cause, connectez-vous au moteur de base de données SQL Server qui héberge les
bases de données des services de qualité des données, puis exécutez la requête suivante pour déterminer si l’ID
de la base de données mentionné dans le message d’erreur existe :
SELECT * from [DQS_MAIN].[dbo].[A_KNOWLEDGEBASE] where id=1000999
NOTE
Si vous exportez une ko DQS, puis importez la ko dans une instance DQS, le numéro d’ID change lorsque la ko est
importée, puis publiée. Par conséquent, même si les éléments de conception de la base de données sont identiques, il se
peut que le nombre ne soit plus synchronisé entre la conception du package SSIS et la base de données de qualité de la
base de données publiée.
NOTE
La propriété du composant nettoyage DQS n’est pas dynamique et n’est pas configurable avec les KnowledgebaseName
configurations, expressions, variables ou environnements SSIS classiques. Il s’agit d’une limitation de conception SQL
Server 2012 et SQL Server 2014.
1. Modifiez le nom du serveur DQS ou déployez le package SSIS dans un autre environnement serveur.
2. Ouvrez le package des services d’intégration dans le concepteur SQL Server Data Tools.msdn.
3. Recherchez la tâche de flux de données concernée.
4. Double-cliquez sur le composant nettoyage DQS pour afficher l’éditeur personnalisé.
5. Mettez à jour la base de connaissances répertoriée dans la liste de listes de la Base de connaissances sur la
qualité des données.
6. Cliquez sur OK, puis enregistrez le package.
Pour éviter ce problème, veillez à pointer vers la même instance DQS, même lorsque vous déployez des
packages SSIS entre différents serveurs. Par conséquent, pendant le développement de SSIS et avant le
déploiement vers un système de production, vous pouvez ajuster les noms des serveurs dans le gestionnaire de
connexions, puis effectuer cette solution de contournement.
NOTE
Bien que vous pouvez modifier manuellement les balises XML dans une conception de package SSIS, cette procédure n’est
pas prise en charge. Vous pouvez le faire à vos propres risques en visualisant le code du fichier .dtsx dans un éditeur de
texte, en localisant la balise XML appropriée, puis en ajustant la propriété pour corriger le KnowledgeBaseName numéro.
Pour déterminer le nombre possible, exécutez la requête suivante pour vérifier la colonne d’ID de chaque nom de la Ko
correspondante :
SELECT ID from [DQS_MAIN].[dbo].[A_KNOWLEDGEBASE] where Name like '%KBName%'

Erreur pour les packages SSIS sur les serveurs SQL
configurés pour utiliser le chiffrement et la taille des
paquets réseau
Cet article vous aide à résoudre le problème qui se produit lorsque vous configurez votre SQL Server pour
utiliser les connexions chiffrées et l’option de taille des paquets réseau.
Symptômes
Prenons le scénario suivant pour SQL Server environnements de travail :
Vous configurez votre SQL Server pour utiliser activer les connexions chiffrées au Moteur de base de
données connexions.
Vous configurez votre serveur SQL pour utiliser une option de taille de paquet réseau supérieure à la
valeur par défaut (4K).
Dans ce scénario, vous remarquerez les choses suivantes :
Une tentative d’enregistrer des packages SSIS dans le magasin de packages MSDB échoue avec le
La méthode SaveToSQLServer a rencontré un code d’erreur OLE DB 0x80004005 (échec de liaison de

communication). L SQL’instruction qui a été émise a échoué.
NOTE
Vous pouvez également exécuter le message d’erreur ci-dessus lors de l’enregistrement des plans de maintenance
créés dans SQL Server Management Studio en tant que packages SSIS dans des bases de données MSDB, car
cette opération utilise intrinsèquement le chiffrement pour les connexions à SQL Server.
La fonctionnalité de collecteur de données SQL Server qui utilise SSIS, présente différents problèmes,
comme indiqué ci-dessous :
Un travail jeu de collecte de données signale les erreurs suivantes dans l’historique des travail :
dcexec : Erreur : erreur interne chez Main (raison : le système ne peut pas trouver le fichier spécifié).
dcexec: Error: Internal error at Main (Reason: The handle is invalid).
Lorsque vous exécutez un jeu de collecte de données directement à partir des données, vous pouvez
rencontrer le message d’erreur suivant :
Le package « Set_{7B191952-8ECF-4E12-AEB2-EF646EF79FEF}_Master_Package_Collection » a
échoué.
Si vous examinez les journaux du collecteur de données, vous trouverez un message d’erreur semblable au
suivant :
Erreur SSIS. Nom du composant : TaskForCollectionItem_1, Code : -1073602332, Sous-composant : (null),

Description : Erreur 0xC0014062 lors de la préparation du chargement du package. La méthode
LoadFromSQLServer a rencontré un code d’erreur OLE DB 0x80004005 (échec de liaison de
communication). L SQL’instruction qui a été émise a échoué.
Le problème peut se produire avec toute opération qui utilise les méthodes
Application.LoadFromSqlServer(String, String, String, String, IDTSEvents) ou
Application.SaveToSqlServer(Package, IDTSEvents, String, String, String) lorsque les conditions (chiffrement et
taille des paquets de grande taille) abordées dans cette section sont vraies.
Cause
Secure Socket Layer (SSL) et son remplacement, Transport Layer Security(TLS), limitent les fragments de
données à 16 000 (16 384) de taille. Cela est documenté dans la norme RFC 2246 publique (section 6.2.2) et
l’implémentation actuelle des protocoles réseau, et la couche points de terminaison TDS respecte cette
spécification. Ainsi, lorsque vous utilisez une taille de paquet réseau supérieure à 16 000 dans les
environnements où le chiffrement est activé sur SQL Server, vous êtes face à des erreurs abordées dans la
section Symptômes.
Résolution
Pour résoudre ce problème, spécifiez une taille de paquet réseau qui est plus petite ou égale à 16 384 octets.
Vous pouvez utiliser le code suivant pour définir network packet size l’option de configuration de la procédure
stockée système sp_configure :
NOTE
Si MARS est activé, le fournisseur SMUX ajoute un en-tête de 16 octets au paquet avant le chiffrement SSL, réduisant ainsi
la taille maximale des paquets réseau à 16 368 octets.
EXEC sp_configure 'network packet size', 16368

RECONFIGURE WITH OVERRIDE
GO
La taille des paquets réseau peut également être modifiée via la page Propriétés du serveur dans l’Explorateur
d’objets. Sélectionnez l’option Avancé et tapez la nouvelle valeur pour Taille des paquets réseau, puis cliquez
sur OK.
NOTE
Vous n’avez pas besoin de redémarrer SQL Server pour que la modification soit effective. Une fois ce paramètre modifié,
toutes les nouvelles connexions reçoivent la nouvelle valeur.
TLS et SSL
Étapes à reproduire
sp_configure 'network packet size', 16384
RECONFIGURE WITH OVERRIDE
GO
1. Assurez-vous que votre collecteur de données est installé.

2. Définissez la taille des paquets réseau sur une valeur supérieure à 16K.
3. Cliquez avec le bouton droit sur Collecte de données dans l’Explorateur d’objets (OE) et désactivez
la collecte de données.
4. Cliquez avec le bouton droit sur Collecte de données dans OE et sélectionnez Activer la collecte
de données.
5. Cliquez avec le bouton droit sur Activité du serveur dans les ensembles de collections et sélectionnez
Démarrer le jeu de collecte de données.
6. Pour obtenir l’erreur, cliquez avec le bouton droit sur Activité du serveur et sélectionnez Collecter et
Télécharger maintenant . (Les journaux DC indiquent l’erreur en détail).
MDS intermédiaire basé sur une entité peut
échouer lorsqu’une valeur de balise de lot en
double est utilisée SQL Server 2012
Cet article vous aide à résoudre le problème où la mise en transit basée sur une entité Master Data Services
(MDS) peut échouer lorsqu’une valeur de balise de lot en double est utilisée dans SQL Server 2012.
Symptômes
Vous utilisez la Microsoft SQL Server 2012 MDS intermédiaire basé sur une entité pour importer des
données dans MDS.
Vous devez remplir diverses tables MDS de transit (stg.name) avec les données de transit à l’aide de la
colonne pour BatchTag identifier le lot.
Vous utilisez la même valeur pour remplir une table intermédiaire distincte qui appartient à une autre
entité dans un BatchTag modèle MDS différent.
Vous exécutez les procédures stockées nécessaires pour démarrer le traitement par lots. Sinon, vous
démarrez le lot intermédiaire à partir de la zone fonctionnelle Gestion de l’intégration sur le MDS web.
Lorsque vous démarrez le processus intermédiaire, vous utilisez l’une des trois procédures stockées :
stg.udp_name_Leaf
stg.udp_name_Consolidated
stg.udp_name_Relationship
NOTE
L’espace réservé est le nom de la table intermédiaire spécifiée lors de la création de <name> l’entité.
Les exemples suivants montrent comment démarrer le processus intermédiaire à l’aide de la procédure stockée
intermédiaire :
exec mds.stg.udp_entityname1 'versionAdescription',0,'batchtag'
exec mds.stg.udp_entityname2 'versionBdescription',0,'batchtag'
Dans ce scénario, vous recevez le message d’erreur suivant lorsque vous démarrez le processus intermédiaire :
MDSERR310029
État du lot spécifié non valide.
En outre, lorsque vous vérifiez l’état du lot, vous remarquez que le lot qui a la valeur reste bloqué indéfiniment
dans l’état BatchTag En cours d’exécution.
NOTE
Vous pouvez vérifier l’état du lot à partir du site web MDS en cliquant sur Gestion de l’intégration, puis en sélectionnant le
modèle pour afficher l’état ou en interrogeant la [mdm].[tblStgBatch] table.
Cause
Ce problème se produit parce que le MDS intermédiaire basé sur une entité vérifie l’état, quel que BatchTag soit
MDS modèle.
Résolution
Si votre lot est bloqué dans l’état En cours d’exécution, arrêtez le processus de traitement par lots, puis essayez
de traiter à nouveau le lot. Pour arrêter le processus de traitement par lots, exécutez l’instruction SQL : Pour
résoudre ce problème, mettez à jour la valeur BatchTag dans la table intermédiaire pour les enregistrements
avec un Exec [mdm].[udpStagingBatchQueueActivate] nouveau nom. En outre, assurez-vous que le
importstatus_ID champ est définie sur 0 pour les enregistrements.
Pour plus d’informations sur le démarrage du processus intermédiaire, voir le site web suivant :
Staging Stored Procedure (Master Data Services)
SQL Server Archive vidéo
Vue d’ensemble : importation de données à partir de tables (Master Data Services)
Importer des états (Master Data Services)
MDS La commande Valider la version échoue avec
une erreur de serveur SQL Server 2012 et SQL
Server 2014
Cet article vous aide à résoudre le problème où la commande Master Data Services (MDS) Valider la version
échoue avec une erreur de serveur dans SQL Server 2012 et SQL Server 2014.
Symptômes
Un administrateur installe Microsoft SQL Server 2012 ou SQL Server 2014 MDS puis déploie le site web
MDS à l’aide d’un nouveau compte de pool d’applications.
Plus tard, accédez au site MDS web, puis suivez les étapes suivantes :
1. Cliquez sur la page Gérer les versions.
2. Cliquez sur la commande Valider la version dans la barre d’outils supérieure.
3. Vous sélectionnez la case à cocher Valider pour le modèle .
4. Vous confirmez que vous voulez vraiment valider cette version ? Invitez-vous, puis cliquez sur
OK.
Dans ce scénario, vous recevez le message d’erreur suivant dans la fenêtre du navigateur :
Erreur de serveur dans l’application « / ».

Une erreur s’est produite lors du traitement du type de demande de message « ValidationGetRequest ». Pour
plus d’informations, voir les détails des exceptions.
Description : une exception non exécutée s’est produite lors de l’exécution de la demande web en cours.
Consultez la trace de pile pour plus d’informations sur l’erreur et son origine dans le code.
Détails de l’exception : Microsoft.MasterDataServices.WebUI.ServiceAdapterException : une erreur s’est
produite lors du traitement du type de demande de message « ValidationGetRequest ». Pour plus
d’informations, voir les détails des exceptions.
Erreur source :
Une exception non exécutée a été générée lors de l’exécution de la demande web en cours. Les informations
relatives à l’origine et à l’emplacement de l’exception peuvent être identifiées à l’aide de la trace de pile
d’exceptions ci-dessous.
Trace de pile :
[ServiceAdapterException : une erreur s’est produite lors du traitement du type de demande de message «
ValidationGetRequest ». Voir les détails des exceptions pour plus d’informations.]
Microsoft.MasterDataServices.WebUI.ServiceAdapter.InspectResponseForErrors(MessageRequest request,
MessageResponse response) +687
Microsoft.MasterDataServices.WebUI.ServiceAdapter.ExecuteRequest(opération MdmServiceOperation 2,
demande TRequestType) +75
Microsoft.MasterDataServices.WebUI.ServiceAdapter.GetValidationStatus(Int32 versionInternalId, Nullable 1
entityInternalId, Nullable 1 memberType, String notificationUserName, IList 1 memberIds, Boolean
omitSummary, Boolean omitIssuesList, Int32 pageNumber, Int32 pageSize, String sortColumn, SortDirection
sortDirection) +678
Microsoft.MasterDataServices.WebUI.ServiceAdapter.GetValidationStatus(Int32 versionInternalId, Int32
pageNumber, Int32 pageSize, String sortColumn, SortDirection sortDirection) +133
Microsoft.MasterDataServices.WebUI.Common.Validations.LoadGrid() +355
Microsoft.MasterDataServices.WebUI.Audit.Dimensions.LoadGrid() +26
Microsoft.MasterDataServices.WebUI.Audit.Dimensions.EvaluateSelectedVersion() +267
Microsoft.MasterDataServices.WebUI.Audit.Dimensions.OnLoad(EventArgs e) +776
System.Web.UI.Control.LoadRecursive() +71
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean
includeStagesAfterAsyncPoint) +3064
NOTE
Un problème similaire peut se produire lorsqu’une application microsoft .NET Framework personnalisée utilise la classe API
MDS ValidationGetRequest. This problem is documented on: ValidationGetRequest Class.
Cause
Ce problème se produit car les nouveaux comptes ne sont pas VIEW SERVER STATE autorisés.
Lorsque vous utilisez l’utilitaire Gestionnaire de configuration Master Data Services pour créer un site web MDS,
l’outil vous demande les informations d’identification du compte d’utilisateur du pool d’applications pour
l’identité du pool d’applications.
Ensuite, une fois le MDS et la base de données sélectionnés, l’outil accorde des autorisations au compte. Le
compte d’informations d’identification du pool d’applications spécifié se voir accorder plusieurs autorisations
dans la base de données MDS spécifiée et est ajouté au groupe d’utilisateurs local et au rôle de base de données
dans le catalogue de bases de données MDS_ServiceAccounts mds_exec MDS spécifié.
Toutefois, VIEW SERVER STATE l’autorisation n’est pas accordée à la base de données maître. Parfois, Windows
comptes peuvent avoir cette autorisation dans SQL Server. Toutefois, par défaut, les nouveaux comptes ne sont
pas autorisés.
L’autorisation est utile pour interroger le service Broker à l’aide de l’affichage gestion dynamique (DMV) pour
vérifier la progression de l’activité en VIEW SERVER STATE sys.dm_broker_activated_tasks arrière-plan en file
d’attente.
L MDS’application web exécute en interne la procédure stockée exec mdm.udpValidationIsRunning pour vérifier la
progression de la validation. Toutefois, les informations d’identification du pool d’applications qui exécute la
requête n’ont pas d’autorisations sur le DMV et reçoivent le message d’erreur suivant :
L’utilisateur n’est pas autorisé à effectuer cette action.
L’instruction suivante à l’intérieur de la procédure échoue et la page web n’est pas rendue :
IF EXISTS (SELECT 1 FROM sys.dm_broker_activated_tasks

WHERE procedure_name = N'[mdm].[udpValidationQueueActivate]')
Pour contourner ce problème, utilisez un compte membre du rôle serveur fixe administrateur système pour
accorder manuellement des autorisations au compte désigné pour exécuter le pool d’applications MDS système.
Par exemple, pour accorder manuellement les autorisations, exécutez les commandes suivantes :
USE Master;
GO
GRANT VIEW SERVER STATE TO <domain\MdsWebAppAccount>;
NOTE
L’espace réservé <domain\MdsWebAppAccount> représente le compte correct pour votre configuration.
Pour déterminer si ce problème est lié à l’autorisation, exécutez une trace de profileur SQL, puis recherchez le
message d’erreur suivant lorsque vous exécutez les instructions comme décrit dans la VIEW SERVER STATE
section Cause :
L’utilisateur n’est pas autorisé à effectuer cette action.
Ensuite, vérifiez si le compte a des autorisations effectives et ajoutez les autorisations si nécessaire. Pour cela,
1. Ouvrez Management Studio, puis connectez-vous au moteur SQL Server de données qui héberge le
catalogue MDS web.
2. Dans le volet Explorateur d’objets, développez le dossier Sécurité.
3. Recherchez le compte utilisé pour exécuter le pool d’applications MDS IIS.
4. Cliquez avec le bouton droit sur le compte, puis cliquez sur Propriétés.
5. Cliquez sur la page Sécurisables. Dans le volet inférieur, cliquez sur l’onglet Effectif.
Si l’autorisation VIEW SERVER STATE effective est répertoriée, cela n’est probablement pas le
problème.
Si l’autorisation n’est pas répertoriée, revenir à l’onglet Explicite de la boîte de dialogue Propriétés
de connexion, puis cochez la case Afficher les autorisations d’état du serveur pour accorder des
autorisations au compte.
Références
Pour plus d’informations sur l’utilisation de l’application web Master Data Manager pour valider des données,
voir :
Valider une version par rapport aux règles métiers (Master Data Services)
sys.dm_broker_activated_tasks (Transact-SQL)
80020009 d’erreur lorsque vous récupérez des
données à partir SQL
Cet article vous aide à résoudre l’erreur 80020009 lorsque vous récupérez des données à partir SQL Server.
Symptômes
L’erreur suivante se produit lors de l’accès à un jeu d’enregistrements dans un fichier Active Server Pages (ASP)
qui contient ou tape des données Text d’une table SQL suivante Blob :
Erreur « 80020009 » du fournisseur Microsoft OLE DB pour les pilotes ODBC
Cause
La condition suivante peut provoquer l’erreur :
Les champs Texte/Objet Blob sont sélectionnés dans un ordre précédant les autres types de champs.
Résolution
Lorsque vous traitez des champs BLOB Microsoft SQL Server, vous devez les placer à droite des colonnes non
BLOB dans le groupe de résultats. Pour être sûr, vous devez également lire les colonnes dans l’ordre de gauche à
droite. Ainsi, si vous avez deux colonnes BLOB comme les deux dernières colonnes dans votre groupe de
résultats, lisez la première, puis la seconde. Ne les lisez pas dans l’ordre inverse.
Pour démontrer l’ordre correct de sélection de champ, créez une page ASP dans une Project Visual InterDev et
collez le code suivant dans la page ASP vide. Modifiez la chaîne de connexion pour vous connecter à votre SQL
Server :
NOTE
Vous devez modifier Username= <username> et PWD= <strong password> avec les valeurs correctes avant d’exécuter
ce code. Assurez-vous que l’ID utilisateur dispose des autorisations appropriées pour effectuer cette opération sur la base
de données.
<%@ Language=VBScript %>
<HTML>
<BODY bgcolor=white>
<%
Set cn = Server.CreateObject("ADODB.Connection")
Set rs = Server.CreateObject("ADODB.Recordset")'Open the connection.
cn.Open "dsn=yoursystemdsn;Username=<username>;PWD=<strong password>;database=pubs;"
'Open the recordset.
'Notice that the Blob field, pr_info, is last in the field order.
rs.Open "select pub_id, pr_info from pub_info", cn
While Not rs.EOF
Response.Write "<P>PR Info:<P>" & rs("pr_info")

Response.Write "<P>That was the PR Info for PubID " &
rs("pub_id")
rs.MoveNext
Wend
%>
</BODY>
</HTML>
Statut
Ce comportement est inhérent au produit. Toutefois, il ne se produit pas lors de l’utilisation de Mdac 2.1 sp2 ou
une ultérieure avec le pilote 3.7 ou une SQL Server.
SQL Server renvoie les données sur le réseau et le client reçoit essentiellement un flux de bits lus
séquentiellement sur le réseau. Avec des colonnes liées (c’est-à-dire que les valeurs peuvent être copiées dans
des mémoires tampons locales et mises en cache à cet effet), le pilote transfère les données de ces colonnes vers
les mémoires tampons. Une fois que les données sont dans des mémoires tampons locales, vous pouvez les lire
dans n’importe quel ordre. Par conséquent, vous pouvez lire les colonnes de résultats dans n’importe quel ordre
lorsque toutes les colonnes sont liées (et non les colonnes BLOB).
Lorsque vous incluez des colonnes BLOB, la longueur de la colonne peut être d’environ 2 gigaoctets et les
bibliothèques d’accès aux données ne lient généralement pas ces colonnes, car le pilote ne peut souvent pas
déterminer exactement la taille de l’objet BLOB tant qu’il n’a pas été récupéré. En outre, les bibliothèques d’accès
aux données évitent généralement la mise en cache des données BLOB, car cela peut consommer de grandes
quantités de mémoire et les mettre en cache à la fois dans la bibliothèque d’accès aux données et votre
application est inefficace. Si le pilote d’accès aux données est invité à renvoyer le contenu d’une colonne BLOB, il
rejette généralement les colonnes non liées qui précèdent la colonne BLOB demandée, car il doit récupérer le
flux de données séquentiel avant de pouvoir lire la colonne demandée. Par conséquent, il est plus efficace de lire
votre ensemble de résultats de gauche à droite, car cela correspond à la façon dont les données sont récupérées.
NOTE
Cela décrit le comportement des SQL Server. Oracle et d’autres SGBD client/serveur peuvent faire la même chose, mais ce
n’est pas obligatoire.
Une meilleure solution consiste peut-être à éviter d’utiliser une colonne de texte. Étant donné SQL Server de
l’espace en blocs de 2K, l’utilisation de colonnes de texte peut entraîner une utilisation inefficace du stockage si
la longueur du texte est faible. Le temps de sauvegarde est également affecté car le vidage du journal des
transactions prend plus de temps. Il est souvent préférable de créer une autre table qui possède le PK de votre
table existante, une colonne de numéro de bloc et une varchar (255) colonne. Divisez le texte en autant de
blocs de 255 caractères nécessaires et insérez autant de lignes dans le nouveau tableau que de blocs. Il vaut
généralement la peine d’utiliser davantage de temps de codage, car vous utilisez plus efficacement le stockage
et les sauvegardes sont beaucoup plus rapides.
Vous ne pouvez pas traduire correctement les
données de caractères d’un client vers un serveur à
l’aide du pilote ODBC SQL Server si la page de
code client diffère de la page de code serveur
Cet article vous aide à contourner un problème qui provoque une traduction incorrecte des données client lors
de l’utilisation SQL Server pilote ODBC.
Symptômes
Lorsque vous utilisez MDAC 2.1 ou une version ultérieure du pilote ODBC SQL Server (version 3.70.0623 ou
ultérieure) ou du fournisseur OLEDB (version 7.01.0623 ou ultérieure), dans certaines circonstances, vous
pouvez faire l’expérience de la traduction des données de caractères de la page de code client vers la page de
code serveur, même lorsque la connexion est Autotranslation désactivée.
Cause
Autotranslation n’est pas le seul mécanisme qui peut entraîner une conversion de page de code. Le pilote
ODBC SQL Server 7.0 et le fournisseur OLEDB introduisent un nouveau comportement lors de la connexion à
MSDE 1.0, SQL Server 7.0 ou à des versions ultérieures de l’une ou l’autre. Toutes SQL instructions envoyées en
tant qu’événement de langue sont converties en Unicode sur le client avant d’être envoyées au serveur. L’effet
final est similaire à une de toutes les données qui circulent du client vers le serveur via un événement de langue,
quel que soit le paramètre actuel Autotranslation Autotranslation de la connexion. Cela n’introduit aucune
difficulté, sauf lorsque vous essayez de stocker des données de caractères non traduites à partir d’une page de
code autre que SQL Server page de code.
Ne stockez pas de données X de page de code dans une page de code Y SQL Server (par exemple, la page de
code 950 données dans une page de code 1252 serveur). Bien que cela était possible dans certaines
circonstances avec les versions précédentes de SQL Server, elle n’a toujours pas été pris en compte. Pour un
chiffre de 1 252 SQL Server, tout autre qu’un caractère de 1 252 n’est pas une donnée de caractère valide. Les
données de caractères non Unicode d’une autre page de code ne seront pas triées correctement et, dans le cas
des données codées sur deux caractères (DBCS), SQL Server ne reconnaîtra pas correctement les limites des
caractères. Cela peut entraîner des problèmes importants.
Le meilleur choix pour la page SQL Server code est la page de code des clients qui accèderont au serveur.
Le serveur et le client peuvent avoir des pages de code différentes, mais vous devez vous assurer que la
traduction automatique est activée sur le client afin que vous receviez correctement la traduction des données
vers et depuis la page de code du serveur dans tous les cas.
Si votre serveur doit stocker des données à partir de plusieurs pages de code, la solution prise en charge
consiste à stocker les données dans les colonnes Unicode ( NCHAR/NVARCHAR/NTEXT ).
Si votre situation nécessite que vous stockiez des données de page de code X dans une page de code SQL
Server Y, il existe deux façons de le faire de manière fiable :
Stockez les données dans des colonnes binaires ( BINARY/VARBINARY/IMAGE ).
Écrivez votre application pour utiliser les appels de procédure distante (RPCs) pour toutes les SQL qui traitent
des données de caractères. Les données envoyées via un événement RPC ne sont pas soumises à la
conversion. Vous ne pouvez rien faire au niveau du pilote ou de la DSN pour modifier le type d’événements
envoyés. Le fait qu’une commande soit envoyée en tant que langage ou événement RPC dépend entièrement
des API et de la syntaxe choisies par le programmeur lors de l’écriture de l’application.
La traduction automatique (c’est-à-dire, la case à cocher Effectuer la traduction des données de caractères dans
les applications ODBC les plus récentes) convertit les données de caractères de la page de code client en page
de code serveur avant d’envoyer les données au serveur, en utilisant Unicode comme support de traduction.
Toutefois, le pilote ODBC 3.7 SQL Server convertit également toutes les instructions SQL envoyées en tant
qu’événement de langue en Unicode avant de les placer sur le réseau, ce qui a un effet similaire à la traduction
automatique, mais qui n’est pas régi par le paramètre de traduction automatique. En revanche, les données de
caractères qui circulent du serveur vers les clients respectent l’indicateur de traduction automatique . Si la
traduction automatique est désactivée, les données arrivent à l’application cliente avec les mêmes codes de
caractères que les données sur le serveur. De même, la traduction des données pour les événements RPC de
client à serveur peut être désactivée en désactivant la traduction automatique. Script simple qui montre
comment le comportement affecte les événements de langue suit. Cet exemple a été exécuté à partir de
l’Analyseur de requêtes sur un client de la page de code 1252 qui se connecte à un serveur 437 de la page de
code :
-- Turn Autotranslation off here.

USE tempdb
GO
CREATE TABLE t1 (c1 int, c2 char(1))
GO
-- Enter a yen character, using the keystroke ALT-0165.

INSERT INTO t1 VALUES (1, '¥')
SELECT c1, c2, ASCII (c2) FROM t1
c1 c2
----------- ---- -----------
1 157
(1 row(s) affected)
Voici ce qui suit à propos de l’exemple précédent :

Même s’il était hors de ce lot, le code de caractère 165 (dans la page de code 1252) a été converti en
Autotranslation 157 (en page de code 437). En effet, le pilote ODBC a converti la chaîne SQL en Unicode
avant de l’envoyer au serveur, de sorte que le serveur a pu la convertir en caractère approprié pour le
stockage dans la page de code 437.
Lorsque le client a mis en place un select pour récupérer les données qui avaient été stockées, le caractère
157 est arrivé non traduit sur le client (157 apparaît comme une zone « » sur une page de code 1252 client).
En effet, la conversion abordée dans cet article s’applique uniquement aux données envoyées du client au
serveur, et non du serveur au client. Les données n’ont pas été traduites car Autotranslation le paramètre
est éteint.
-- Turn Autotranslation back on before running the following batch.
INSERT INTO t1 VALUES (2, '¥')
SELECT c1, c2, ASCII (c2) FROM t1
c1 c2
----------- ---- -----------
1 ¥ 157
2 ¥ 157
(2 row(s) affected)
Dans ce cas, le fait de revenir en arrière n’a eu aucun effet sur la traduction du client vers le serveur (c’est-à-dire
que la même traduction correcte du code de caractère 165 au code de caractère 157 s’est produite), mais elle a
eu un effet sur les données extraites du Autotranslation serveur. Lorsque l’instruction SELECT est exécuté cette
fois (avec on), les symboles de symboles s’affichent correctement dans la page de code 1252 de l’application, car
ils ont été convertis du code de caractère 157 au code de caractère 165 par le Autotranslation Autotranslation
mécanisme.
Vous verrez ce comportement (conversion d’événements de langue en Unicode sur le client) lorsque vous
utilisez un pilote ODBC SQL Server version 3.70 ou ultérieure et que vous vous connectez à SQL Server 7.0 ou
version ultérieure. Elle ne se produit pas lorsque vous utilisez des pilotes ODBC plus anciens ou lorsque vous
utilisez le pilote 3.7 pour vous connecter à SQL Server 6.5 ou une antérieure. En outre, si vous stockez vos
données dans des colonnes Unicode () la conversion ne NCHAR/NVARCHAR/NTEXT sera pas un problème.
Pour plus d’informations sur la représentation des données de caractères dans SQL Server 2005, voir Character
data is represented incorrectly when the code page of the client computer differs from the code page of the
database in SQL Server 2005.
Vérifier la version de MDAC
Cet article explique comment vérifier la version de MDAC.

Résumé
Cet article décrit deux façons différentes de vérifier la version de Microsoft Data Access Components (MDAC)
installée sur un système :
Utilisez l’outil De vérification des composants.
Vérifiez les informations de version stockées dans le Registre.
Installer et utiliser l’outil De vérification des composants

La méthode la plus fiable pour déterminer la version de MDAC installée consiste à comparer le numéro de
version de chaque fichier DLL MDAC à une liste des fichiers DLL livrés avec chaque version de MDAC. Le
contrôle de composant peut vous aider à le faire. Il vérifie les fichiers sur l’ordinateur, les compare à une liste de
chaque version de MDAC et signale la correspondance la plus proche.
Pour installer le vérification des composants, suivez les étapes suivantes :
1. Accédez au site Web Microsoft : Utilitaire MDAC : outil de vérification des composants.
2. Cliquez sur le lien pour télécharger l’vérification des composants. Lorsque le navigateur vous y invite,
enregistrez cc_<CPU_arc >.msi (fichier exécutable à extraction autonome) sur le Bureau.
3. Sur le Bureau, double-cliquez sur cc_<CPU_arc>.msi ; cela installe les fichiers de vérification des
composants à l’emplacement par défaut, C:\CompChecker\ .
Pour utiliser le contrôle de composant pour vérifier la version MDAC, suivez les étapes suivantes :
1. Dans le menu Démarrer, cliquez sur Exécuter.
2. Dans la zone de texte Ouvrir, c:\CompChecker\CC.exe tapez, puis cliquez sur OK.
3. Dans la boîte de dialogue Vérification des composants - Choisissez Type d’analyse, sélectionnez Effectuer
une analyse de votre ordinateur et déterminer automatiquement la version finale, puis cliquez sur OK .
4. Le programme tente d’identifier la version MDAC sur votre ordinateur en analysant tous les fichiers
MDAC principaux et les paramètres de Registre. Ce processus prend normalement plusieurs minutes.
Lorsque vous avez terminé, vous devez recevoir le message suivant :
La version MDAC la plus proche de la version sur votre ordinateur est « XXXX ».
5. Cliquez sur OK .
6. Un résumé de l’analyse de vérification des composants s’affiche.
NOTE
Les erreurs Dir, FileDescription et FileSize peuvent être ignorées en toute sécurité.
Vérifier les informations de version stockées dans le Registre

Bien qu’il ne s’agit pas de la méthode la plus fiable pour vérifier la version de MDAC, la vérification des
informations de version dans le Registre est un moyen simple de vérifier ces informations (si vous ne rencontrez
aucun problème lié à MDAC).
Les informations de version se trouvent dans la clé suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\DataAccess\FullInstallVer
Pour vérifier le Registre, suivez les étapes suivantes :

1. Dans le menu Démarrer , cliquez sur Exécuter .
2. Dans la zone de texte Ouvrir, tapez, regedit puis cliquez sur OK ; cela démarre l’Éditeur du Registre.
3. Dans le volet de navigation, descendez jusqu’au chemin d’accès suivant :
HKEY_LOCAL_MACHINE\Software\Microsoft\DataAccess
4. Dans le volet Détails, recherchez et dans la colonne FullInstallVer Version Nom. Chacune de ces clés
aura les informations de version correspondantes dans la colonne Données.
5. Lorsque vous avez terminé, cliquez sur Quitter dans le menu Registre pour fermer l’Éditeur du Registre.

NOTE
Les informations de version stockées dans le Registre peuvent être incorrectes pour les versions de MDAC antérieures à la
version 2.1 par rapport aux versions des fichiers réels. Windows 2000 installe la version 2.5. Seules les versions de MDAC
ultérieures à la version 2.5 peuvent être installées Windows 2000.
Les téléchargements des composants d’accès aux données Microsoft sont disponibles SQL développeur de
données.
Erreur lorsque vous utilisez le curseur client pour
ajouter un enregistrement à SQL Server table qui a
une valeur par défaut dans le champ Datetime
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez le curseur client pour ajouter un
enregistrement à une table SQL Server qui a une valeur par défaut dans le champ Datetime.
Symptômes
Si vous utilisez ADO pour insérer un nouvel enregistrement via un jeu d’enregistrements côté client dans une
table SQL Server avec un champ non nullable avec une valeur par défaut, vous recevez le message d’erreur
suivant si vous ne fournissez pas de valeur pour le champ datetime datetime :
Erreur d'2147217887 '-2147217887 (80040e21) : une opération en plusieurs étapes a généré des erreurs.
Vérifiez chaque valeur d’état.
Cette erreur se produit si vous utilisez le fournisseur OLE DB pour SQL Server ou le fournisseur OLE DB pour les
pilotes ODBC. Le message d’erreur peut différer lorsque vous utilisez Microsoft Data Access Components
(MDAC) version 2.5 Service Pack 1 (SP1) ou une version antérieure. Cette erreur ne se produit pas avec un
curseur côté serveur.
Cause
Cette erreur se produit dans le moteur de curseur client lorsqu’il tente de convertir la valeur du type
DBTYPE_DBTIMESTAMP en DBTYPE_VARIANT .
Résolution
Il existe plusieurs façons de contourner ce problème :
Utilisez un curseur côté serveur pour le jeu d’enregistrements.
Supprimez la valeur par défaut spécifiée pour le champ dans la base de données.
Spécifiez toujours une valeur pour le champ lorsque vous ajoutez un nouvel enregistrement.
Étapes pour reproduire le comportement

1. Ajoutez une table à SQL Server qui contient un champ date/heure qui n’accepte pas les valeurs null et qui
a une valeur par défaut. Inclure au moins un champ supplémentaire. Dans le but de cet article, la table
SQL Server 2000 suivante est créée :
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[DateTest]')
and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[DateTest]
GO
CREATE TABLE [dbo].[DateTest] ([DateId] [int] IDENTITY (1, 1) NOT NULL ,

[TestDate] [datetime] NOT NULL ,
[Nonsense] [varchar] (16) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[DateTest] WITH NOCHECK ADD

CONSTRAINT [DF_DateTest_TestDate] DEFAULT ('3/1/2001') FOR [TestDate],
PRIMARY KEY CLUSTERED
([DateId]
) ON [PRIMARY]
GO
2. Pour insérer une ligne dans le tableau, exécutez un code semblable au code suivant.
NOTE
Vous devez modifier l’ID utilisateur = <UID> et le mot de passe = aux <strong password> valeurs correctes avant
d’exécuter ce code. Assurez-vous que <UID> vous disposez des autorisations appropriées pour effectuer cette
opération sur la base de données. Assurez-vous également que vous ne fournissez pas de valeur pour le
datetime champ.
Dim cnn As ADODB.Connection

Dim rst As ADODB.Recordset
Set cnn = New ADODB.Connection

cnn.Open "Provider=SQLOLEDB;Data Source=(local);" & _
"Initial Catalog=test;User Id=<UID>;Password=<strong password>;"
Set rst = New ADODB.Recordset

With rst
.CursorLocation = adUseClient
.Open "SELECT * FROM DateTest", cnn, adOpenStatic, adLockOptimistic
.AddNew
.Fields("Nonsense").Value = "test data"
.Update
End With
Debug.Print rst("TestDate").Value
Vous recevez le message d’erreur mentionné ci-dessus lorsque vous examinez la propriété Value du
datetime champ.
SQL Server ne termine pas l’exécution d’un lot
important d’SQL instructions
Cet article vous aide à résoudre le problème qui se produit lorsque vous exécutez un grand lot d’instructions
SQL qui renvoient de nombreux jeux de résultats.
Symptômes
Lorsque vous exécutez un lot important d’instructions SQL qui renvoie de nombreux jeux de résultats, Microsoft
SQL Server peut arrêter le traitement du lot avant que toutes les instructions du lot ne soient exécutées. Les
effets de ce comportement dépendent des opérations effectuées par les instructions batch. Par exemple, si le lot
démarre une transaction au début et la validation à la fin, il se peut que la validation ne se produise pas. Ce
comportement entraîne le blocage des verrous plus longtemps que prévu. Cela peut également entraîner le
retour de la transaction à la fermeture de la connexion. Si le lot ne démarre pas de transaction, les symptômes
du problème peuvent être que certaines instructions ne sont pas exécutées.
Lors du traitement des résultats d’un lot, SQL Server remplit la mémoire tampon de sortie de la connexion avec
les jeux de résultats créés par le lot. Ces jeux de résultats doivent être traitées par l’application cliente. Si vous
exécutez un lot important avec plusieurs jeux de résultats, SQL Server remplit cette mémoire tampon de sortie
jusqu’à ce qu’elle atteint une limite interne et ne puisse pas continuer à traiter d’autres jeux de résultats. À ce
stade, le contrôle retourne au client. Lorsque le client commence à consommer les jeux de résultats, SQL Server
exécute à nouveau le lot, car il existe désormais de la mémoire disponible dans la mémoire tampon de sortie.
Pour contourner le problème, utilisez l’une des méthodes suivantes :
Méthode 1 : Vider tous les jeux de résultats de sortie. Dès que tous les jeux de résultats de sortie sont
consommés par le client, SQL Server exécute le lot.
Si vous utilisez Open Database Connectivity (ODBC) pour vous connecter à SQL Server, vous pouvez
appeler la méthode jusqu’à ce que la méthode signale qu’il n’y a plus de jeux SQLMoreResults de
résultats.
Si vous utilisez OLE DB pour vous connecter à SQL Server, vous pouvez appeler à plusieurs reprises la
méthode IMultipleResults::GetResult jusqu’à ce qu’elle retourne DB_S_NORESULT .
Méthode 2 : ajoutez SET NOCOUNT ON l’instruction au début de votre lot. Si le lot est exécuté dans une
procédure stockée, ajoutez l’instruction au début de la définition de procédure stockée. Cela empêche
SQL Server renvoyer de nombreux types de jeux de résultats. Par conséquent, il peut réduire les données
à sortie dans la mémoire tampon de sortie du serveur. Toutefois, cela ne garantit pas que le problème ne
se produira pas. Cela augmente uniquement le risque que les données renvoyées à partir du serveur sont
suffisamment petites pour tenir dans un lot de jeux de résultats.
NOTE
Microsoft recommande de toujours consommer tous les jeux de résultats de SQL Server quelle que soit la taille du lot
que vous exécutez. Si vous ne videz pas ces données et que des jeux de résultats réussis doivent être renvoyés avant
l’erreur dans le lot du jeu de résultats, le client risque de ne pas découvrir les erreurs du serveur.
Les applications clientes doivent vider les jeux de résultats pour garantir une exécution correcte.
Statut

1. Créez une SQL stockée dans la base de données pubs avec un lot relativement important d’instructions
de requête de base de données. Vous pouvez créer une procédure semblable à la procédure suivante :
create proc bigBatch as begin transaction update authors set au_fname = 'newname1' where au_id='172-
32-1176' update authors set au_fname = 'newname2' where au_id='172-32-1176' update authors set
au_fname = 'newname3' where au_id='172-32-1176' ... update authors set au_fname = 'newname1000' where
au_id='172-32-1176' commit transaction
NOTE
Remplacez le texte « ... » avec les instructions de requête de base de données appropriées qui sont similaires aux
autres instructions de requête de base de données dans le code.
2. Créez, puis configurez un nom de source de données (DSN) avec une base de données pubs qui se
connecte au SQL Server.
3. Démarrez l’outil Profiler qui est disponible avec SQL Server’installation.
4. Créez, puis démarrez un nouveau suivi pour le SQL Server à partir de l’outil Profiler.
NOTE
Veillez à ajouter la classe d’événement nommée Procédure stockée pour la nouvelle SQL profileur. Lorsque vous le
faites, vous pouvez voir les étapes individuelles de la procédure lorsqu’elle est exécutée.
5. Connecter à SQL Server à l’aide d’ODBC. Pour cela, procédez comme suit :
a. Ouvrez l’exemple d’outil test ODBC disponible avec l’installation du SDK d’accès aux données (MDAC).
b. Dans le menu Conn, cliquez sur Connecter .
c. Dans la boîte de Connecter complète, cliquez sur le nom de la DSN que vous avez créée à l’étape 2.
d. Assurez-vous que la connexion à SQL Server est réussie.
e. Dans le menu Stmt, cliquez sur SQLExecDirect .
f. Dans la zone StatementText, tapez {call bigBatch}, puis cliquez sur OK .
Dans l’analyse du suivi SQL profileur, vous remarquez que le traitement de la procédure stockée n’est pas
terminé. Toutefois, l’outil test ODBC indique que l’exécution a réussi. Pour extraire tous les jeux de résultats et
provoquer la fin du lot sur le serveur, cliquez sur Obtenir toutes les données dans le menu Résultats. Vous
pouvez vous connecter à SQL Server à l’aide de OLE DB. Pour cela, procédez comme suit :
1. Ouvrez l’exemple d’outil RowsetViewer OLE DB disponible avec le SDK MDAC.
2. Connecter la base de données SQL Server pubs à l’aide de l’option Connecter complète.
3. Dans le menu Commande, pointez sur ICommand, puis cliquez sur Exécuter.
4. Dans la zone Texte cmd, tapez {call bigBatch}.
5. Cliquez IID_IMultipleResults dans la liste REFIID, puis cliquez sur Propriétés.
6. Dans la boîte de dialogue ICommandProper ties::SetProper ties, cliquez sur DBPROP_IMultipleResults,
modifiez la valeur en VARIANT_TRUE puis cliquez sur OK .
7. Cliquez sur OK .
Dans l’analyse du suivi SQL profileur, vous remarquez que le traitement de la procédure stockée n’est pas
terminé. Toutefois, l’outil RowsetViewer indique que l’opération a réussi. Pour récupérer tous les jeux de résultats,
cliquez avec le bouton droit sur l’objet MultipleResults dans le volet gauche, pointez sur IMultipleResults,
puis cliquez sur GetResult . Répétez jusqu’à ce que tous les jeux de résultats soient consommés.
Le problème est plus facile à reproduire lorsque vous êtes connecté au SQL Server à l’aide du protocole Canaux
nommés ou du protocole de mémoire partagée (LPC). Cela est dû à la taille de mémoire tampon interne SQL
Server disponible pour les différents protocoles.
Voici les effets possibles de ce problème. Les effets sont variés et dépendent exactement de ce que contient
votre lot.
Considérez qu’un lot d’instructions de requête de base de données est exécuté à partir d’une application.
Si le lot d’instructions de requête de base de données est composé d’une TRANSACTION BEGIN au début
et de COMMIT TRANSACTION à la fin, il se peut que l’opération de validation ne se produise pas même si
le contrôle est renvoyé à l’application. Il s’agit d’un problème, car les verrous éventuellement mis en
attente peuvent provoquer une transaction en attente et rester ignorés.
Dans ce scénario, étant donné que la transaction n’est jamais committede dans le lot, elle reste en attente
et est resserée lors de la déconnexion du SQL Server.
Si vous utilisez une interface de programme d’application (API) pour commencer et valider votre
transaction, vous pouvez voir le comportement suivant :
Si vous utilisez l’API pour envoyer une notification au serveur pour démarrer une transaction, puis que
vous exécutez le lot, SQL ne peut traiter qu’une partie du lot, puis renvoyer le contrôle à l’application.
Après cette étape, si vous utilisez l’API pour valider la transaction, seule la partie du lot qui a été traitée
est valider. Aucune erreur ne se produit.
Par exemple, avec ODBC, vous appelez pour démarrer la transaction, puis vous
SQLSetConnectAttr(SQL_ATTR_AUTOCOMMIT, SQL_AUTOCOMMIT_OFF) l’utilisez SQLEndTran(SQL_COMMIT) pour
valider la transaction.
Références
Utilisation de plusieurs jeux de résultats actifs (MARS)
NOTE
Si vous utilisez ADO, l’appel de la méthode de l’objet entraîne l’exécution de la méthode par le fournisseur
NextRecordset Recordset OLE IMultipleResults::GetResult DB.
Utilisation de plusieurs jeux de résultats actifs (MARS) dans SQL Server Native Client
SET NOCOUNT (Transact-SQL)
SQLMoreResults
IMultipleResults::GetResult
L’outil Administrateur ODBC affiche les DSN
utilisateur 32 bits et 64 bits dans une version 64 bits
de Windows
Cet article fournit une solution de contournement du problème qui se produit dans l’outil Administrateur de
source de données ODBC.
Symptômes
Une version 64 bits du système d’exploitation Microsoft Windows inclut les versions suivantes de l’outil
Administrateur de source de données ODBC (Odbcad32.exe) :
La version 32 bits du fichier Odbcad32.exe se trouve dans le %systemdrive%\Windows\SysWoW64 dossier.
La version 64 bits du fichier Odbcad32.exe se trouve dans le %systemdrive%\Windows\System32 dossier.
Le Odbcad32.exe de données affiche les types de noms de source de données (DSN) suivants :
DSN système
DSN utilisateur
Symptôme 1
La version 32 bits de l’outil Administrateur ODBC affiche les DSN système 32 bits, les DSN utilisateur 32 bits et
les DSN utilisateur 64 bits. La version 64 bits de l’outil Administrateur ODBC affiche les DSN système 64 bits, les
DSN utilisateur 32 bits et les DSN utilisateur 64 bits.
Symptôme 2
La SQLDataSources fonction renvoie toutes les versions des DSN utilisateur, quelle que soit l’architecture de
l’application. La fonction appelée dans une application 32 bits renvoie uniquement les DSN système pour les
pilotes 32 bits, mais renvoie les DSN utilisateur pour les pilotes SQLDataSources 32 bits et 64 bits. De même, la
fonction appelée dans une application 64 bits renvoie uniquement les DSN système pour les pilotes 64 bits,
mais renvoie les DSN utilisateur pour les pilotes SQLDataSources 32 bits et 64 bits. Par conséquent, si
l’application effectue une connexion à l’aide d’un DSN utilisateur renvoyé par la fonction, vous pouvez recevoir
le SQLDataSources message d’erreur suivant :
Nom de la source de données in trouvé et aucun pilote par défaut spécifié
Par exemple, prenons le scénario suivant. Vous créez un nom d’utilisateur DSN pour le pilote 32 bits « Pilote
Microsoft Access (*.mdb) ». Ce pilote n’a pas de version 64 bits correspondante. La fonction appelée dans une
application 64 bits renvoie ce SQLDataSources DSN utilisateur 32 bits. Toutefois, si vous vous connectez via ce
nom d’utilisateur 32 bits, vous recevez le message d’erreur mentionné plus haut dans cette section.
Cause
Les DSN utilisateur sont stockés sous la sous-clé de Registre suivante :
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI
La redirection du Registre n’est pas activée pour cette sous-clé de Registre. Par conséquent, les DSN utilisateur
sont visibles dans les versions 32 bits et 64 bits de l’outil Administrateur ODBC.
Résolution
Pour maintenir la compatibilité ascendante, aucune résolution de ce problème n’est actuellement disponible.
Pour contourner ce problème, utilisez la version appropriée de l’outil Administrateur ODBC. Si vous créez puis
exécutez une application en tant qu’application 32 bits sur un système d’exploitation 64 bits, vous devez créer la
source de données ODBC à l’aide de l’outil Administrateur ODBC dans %windir%\SysWOW64\odbcad32 .exe. Pour
indiquer le type de DSN, vous pouvez ajouter « _32 » aux DSN utilisateur 32 bits et « _64 » aux DSN utilisateur
64 bits.
L’outil Administrateur ODBC 64 bits peut être appelé à partir du Panneau de contrôle pour gérer les DSN
utilisateur et les DSN système utilisés par les processus 64 bits. Sur un système d’exploitation 64 bits, l’outil
Administrateur ODBC 32 bits est utilisé pour Windows sur Windows 64 (WOW64). Vous devez appeler
directement l’outil Administrateur ODBC 32 bits à partir du dossier SysWoW64. Vous pouvez utiliser l’outil
Administrateur ODBC 32 bits pour gérer les DSN utilisateur et les DSN système utilisés par les processus
WOW64.
Les DSN système sont stockés dans la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI
La redirection du Registre est activée pour cette sous-clé de Registre. Par conséquent, les DSN système pour les
pilotes 32 bits et pour les pilotes 64 bits sont séparés. L’outil Administrateur ODBC 64 bits n’affiche pas les DSN
système créés par l’outil Administrateur ODBC 32 bits. De même, l’outil Administrateur ODBC 32 bits n’affiche
pas les DSN système créés par l’outil Administrateur ODBC 64 bits. En outre, l’outil Administrateur ODBC 64 bits
n’affiche pas les DSN système qui utilisent des pilotes 32 bits. De même, l’outil Administrateur ODBC 32 bits
n’affiche pas les DSN système qui utilisent des pilotes 64 bits.
Les DSN utilisateur sont stockés dans la sous-clé de Registre suivante :
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI
La redirection du Registre n’est pas activée pour cette sous-clé de Registre. Par conséquent, les deux outils
d’administrateur ODBC affichent tous les DSN utilisateur.
Pour plus d’informations sur la redirection du Registre, voir Redirection du Registre.
Ouvrir une connexion ADO et des objets Recordset
Cet article explique comment ouvrir une connexion ADO et des objets Recordset.
Résumé
ActiveX Data Objects (ADO) offre plusieurs façons d’ouvrir les objets Connection et Recordset. Cet article
présente un exemple de code pour plusieurs techniques courantes pour chaque objet.
Il existe plusieurs façons d’ouvrir un objet Connection dans ADO :
En fixant ConnectionString la propriété sur une chaîne Connecter valide, puis en appelant la Open()
méthode. Cette chaîne de connexion dépend du fournisseur.
En passant une chaîne Connecter valide au premier argument de la Open() méthode.
En passant un objet Command valide dans le premier argument de la méthode Open d’un objet Recordset.
En passant le nom de la source de données ODBC et éventuellement l’ID utilisateur et le mot de passe à la
méthode de l’objet Open() Connection.
Il existe trois façons d’ouvrir un objet Recordset dans ADO :
En ouvrant le recordset à partir de la Connection.Execute() méthode.
En ouvrant le recordset à partir de la Command.Execute() méthode.
En ouvrant l’objet Recordset sans objet Connection ou Command et en passant une chaîne Connecter valide
au deuxième argument de la Recordset.Open() méthode.
Ce code suppose que Nwind.mdb est installé avec Visual Basic, et se trouve dans
C:\Program Files\DevStudio\VB directory :
Option Explicit
Private Sub cmdOpen_Click()
Dim Conn1 As New adodb.Connection

Dim Cmd1 As New adodb.Command
Dim Errs1 As Errors
Dim Rs1 As New adodb.Recordset
Dim i As Integer
Dim AccessConnect As String
' Error Handling Variables

Dim errLoop As Error
Dim strTmp As String
AccessConnect = "Driver={Microsoft Access Driver (*.mdb)};" & _

"Dbq=nwind.mdb;" & _
"DefaultDir=C:\program files\devstudio\vb;" & _
"Uid=Admin;Pwd=;"
'---------------------------
' Connection Object Methods
'---------------------------
On Error GoTo AdoError ' Full Error Handling which traverses

' Connection object
' Connection Open method #1: Open via ConnectionString Property

Conn1.ConnectionString = AccessConnect
Conn1.Open
Conn1.Close
Conn1.ConnectionString = ""
' Connection Open method #2: Open("[ODBC Connect String]","","")

Conn1.Open AccessConnect
Conn1.Close
' Connection Open method #3: Open("DSN","Uid","Pwd")

Conn1.Open "Driver={Microsoft Access Driver (*.mdb)};" & _
"DBQ=nwind.mdb;" & _
"DefaultDir=C:\program files\devstudio\vb;" & _
"Uid=Admin;Pwd=;"
Conn1.Close
'--------------------------
' Recordset Object Methods
'--------------------------
' Don't assume that we have a connection object.

On Error GoTo AdoErrorLite
' Recordset Open Method #1: Open via Connection.Execute(...)

Conn1.Open AccessConnect
Set Rs1 = Conn1.Execute("SELECT * FROM Employees")
Rs1.Close
Conn1.Close
' Recordset Open Method #2: Open via Command.Execute(...)

Conn1.Open
Cmd1.ActiveConnection = Conn1
Cmd1.CommandText = "SELECT * FROM Employees"
Set Rs1 = Cmd1.Execute
Rs1.Close
Conn1.Close
' Recordset Open Method #3: Open via Command.Execute(...)

Conn1.Open
Cmd1.ActiveConnection = Conn1
Cmd1.CommandText = "SELECT * FROM Employees"
Rs1.Open Cmd1
Rs1.Close
Conn1.Close
' Recordset Open Method #4: Open w/o Connection & w/Connect String
Rs1.Open "SELECT * FROM Employees", AccessConnect, adOpenForwardOnly
Rs1.Close
Done:
Set Rs1 = Nothing
Set Cmd1 = Nothing

Set Conn1 = Nothing
Exit Sub
AdoError:
i = 1
On Error Resume Next
' Enumerate Errors collection and display properties of

' each Error object (if Errors Collection is filled out)
Set Errs1 = Conn1.Errors
For Each errLoop In Errs1
With errLoop
strTmp = strTmp & vbCrLf & "ADO Error # " & i & ":"
strTmp = strTmp & vbCrLf & " ADO Error # " & .Number
strTmp = strTmp & vbCrLf & " Description " & .Description
strTmp = strTmp & vbCrLf & " Source " & .Source
i = i + 1
End With
Next
AdoErrorLite:
' Get VB Error Object's information
strTmp = strTmp & vbCrLf & "VB Error # " & Str(Err.Number)
strTmp = strTmp & vbCrLf & " Generated by " & Err.Source
strTmp = strTmp & vbCrLf & " Description " & Err.Description
MsgBox strTmp
' Clean up gracefully without risking infinite loop in error handler

On Error GoTo 0
GoTo Done
End Sub
REMARQUES D’ERREUR
Seul l’objet Connection ADO possède une collection d’erreurs. Le lecteur observateur remarquera qu’un handler
d’erreurs léger est en vigueur pour les RecordSet.Open exemples. En cas d’erreur lors de l’ouverture d’un objet
RecordSet, ADO doit renvoyer l’erreur la plus explicite du fournisseur OLEDB. Voici quelques erreurs courantes
qui peuvent être rencontrées avec le code précédent.
Si vous omettez (ou qu’une erreur s’est produite) dans le paramètre DefaultDir dans la chaîne de connexion,
vous pouvez recevoir l’erreur suivante :
Erreur ADO # -2147467259

Description [Microsoft][Pilote ODBC Microsoft Access 97] '(inconnu)'
n’est pas un chemin d’accès valide. Assurez-vous que le nom du chemin d’accès est
correctement orthographé et que vous êtes connecté au serveur
sur lequel réside le fichier.
Fournisseur Microsoft OLE DB source pour les pilotes ODBC
En cas d’erreur dans le paramètre Dbq dans la chaîne de connexion, vous pouvez recevoir l’erreur suivante :
Erreur ADO # -2147467259 Description [Microsoft][Pilote ODBC Microsoft Access 97] Impossible de trouver
le fichier '(inconnu) ».
Les erreurs précédentes complètent également la collection d’erreurs de connexion avec les erreurs suivantes :
Erreur ADO # -2147467259

Description [Microsoft][Gestionnaire de pilotes ODBC] Driver’s
Échec de SQLSetConnectAttr
Erreur ADO # -2147467259

Échec de la connexion à la description
NOTE
Pour chaque erreur, le numéro d’erreur ADO est le même, en l’occurrence en 0x80004005, qui est le message d’erreur
E_FAIL générique. Le composant sous-jacent n’a pas de numéro d’erreur spécifique pour la condition rencontrée, mais des
informations utiles n’ont jamais été moins élevées dans ADO.
Références
Microsoft ActiveX Data Objects (ADO)
Utilisation d’un objet Connection
Récupérer des valeurs dans SQL Server procédures
stockées avec ADO
Cet article montre comment récupérer des valeurs dans SQL Server procédures stockées avec ADO.
Résumé
Il existe des problèmes importants à prendre en compte lors de la tentative de récupération de valeurs à partir
SQL Server RAISERROR/PRINT/RETURN procédures stockées via ActiveX Data Objects (ADO). Voici trois problèmes :
RAISERROR dans SQL Server doit être un niveau de gravité de 11 à 18.
Les instructions PRINT SQL Server peuvent également remplir la collection d’erreurs ADO. Toutefois, les
instructions PRINT sont de niveau de gravité zéro (0) de sorte qu’au moins une instruction est requise
dans la procédure stockée pour récupérer une instruction PRINT avec ADO via la RAISERROR collection
Errors.
Les valeurs RETURN d’une procédure stockée doivent être associées à au moins un groupe de résultats.
L’exemple de code suivant illustre la navigation dans la collection Errors ADO pour accéder aux détails à partir
d’SQL Server procédure stockée renvoyant plusieurs RAISERROR/PRINT/RETURN jeux de résultats :
1. Collez et exécutez le code suivant dans la fenêtre SQL Server Management Studio (SSMS) après avoir
créé la base de données Pubs pour créer la procédure stockée utilisée pour l’exemple ADO à l’étape 4 :
use pubs
GO
if exists (select * from sysobjects where id = object_id('dbo.ADOTestRPE') and sysstat & 0xf = 4)
drop procedure dbo.ADOTestRPE
GO
create procedure ADOTestRPE

(
@SetRtn INT=0 OUTPUT,
@R1Num INT=1,
@P1Num INT=1,
@E1Num INT=1,
@R2Num INT=2,
@P2Num INT=2,
@E2Num INT=2
)
AS
DECLARE @iLoop INT
DECLARE @PrintText VARCHAR(255)
DECLARE @iErrNum INT
/* Check for no Resultsets - needed to get the RETURN value back */

IF @R1Num + @R2Num = 0 SELECT NULL
/* Resultset 1 ******************************* */
IF @R1Num > 0
BEGIN
SET ROWCOUNT @R1Num
SELECT 'Resultset 1' RsNum, Title
FROM Pubs..Titles
SET ROWCOUNT 0
END
/* Must raise a default error context in which to return the PRINT */

/* statement */
/* (if none present) since PRINT statements are a severity level of */
/*0. */
IF (@P1Num > 0) AND (@E1Num = 0) RAISERROR ("RAISERROR.PError1", 11, 2)
IF @P1Num > 0
BEGIN
SELECT @iLoop = 0
WHILE @iLoop < @P1Num
BEGIN
SELECT @iLoop = @iLoop + 1
SELECT @PrintText = 'PRINT.Resultset.1: Line ' +
CONVERT(char(2), @iLoop)
PRINT @PrintText
END
END
IF @E1Num > 0
BEGIN
SELECT @iLoop = 0
WHILE @iLoop < @E1Num
BEGIN
SELECT @iErrNum = @iLoop + 201000
RAISERROR ("RAISERROR.Resultset.1", 11, 2)
END
END
/* Resultset 2 ******************************* */
IF @R2Num > 0
BEGIN
SET ROWCOUNT @R2Num
SELECT 'Resultset 2' RsNum, Title
FROM Pubs..Titles
SET ROWCOUNT 0
END
/* Must raise a default error context in which to return the PRINT */

/* statement */
/* (if none present) since PRINT statements are a severity level of */
/* 0. */
IF (@P2Num > 0) AND (@E2Num = 0) RAISERROR ("RAISERROR.PError2",11, 2)
IF @P2Num > 0
BEGIN
SELECT @iLoop = 0
WHILE @iLoop < @P2Num
BEGIN
SELECT @PrintText = 'PRINT.Resultset.2: Line ' +
CONVERT(char(2), @iLoop)
PRINT @PrintText
END
END
IF @E2Num > 0
BEGIN
SELECT @iLoop = 0
WHILE @iLoop < @E2Num
BEGIN
SELECT @iErrNum = @iLoop + 202000

RAISERROR ("RAISERROR.Resultset.2", 11, 2)
END
END
/* Return & Output ************************************ */
select @SetRtn = -1
RETURN @SetRtn
GO
2. Créez un projet .EXE standard dans Visual Basic. Form1 est créé par défaut.
3. Dans le menu Project, choisissez Références et sélectionnez la bibliothèque d’objets ActiveX Microsoft.
NOTE
Vous devez utiliser ADO version 2.0 ou ultérieure pour que le code fonctionne correctement. Vous pouvez obtenir
les derniers composants Microsoft Data Access Components (MDAC) sur le Web à l’adresse : MDAC.
4. Placez un bouton Commande sur le formulaire, puis collez le code suivant dans la section Déclarations
générales du formulaire. Vous devrez peut-être modifier la chaîne de connexion de base de données pour
votre environnement.
'This Code demonstrates RAISERROR/PRINT/RETURN values with ADO and

'multiple resultsets.
Sub CreateParms()
Dim ADOCmd As New ADODB.Command

Dim ADOPrm As New ADODB.Parameter
Dim ADOCon As ADODB.Connection
Dim ADORs As ADODB.Recordset
Dim sParmName As String
Dim strConnect As String
Dim rStr As String
On Error GoTo ErrHandler
strConnect = "driver={SQL
Server};server=(local);uid=sa;pwd=;database=pubs"
Set ADOCon = New ADODB.Connection

With ADOCon
.Provider = "MSDASQL"
.CursorLocation = adUseServer 'Must use Server side cursor.
.ConnectionString = strConnect
.Open
End With
Set ADOCmd.ActiveConnection = ADOCon

With ADOCmd
.CommandType = adCmdStoredProc
.CommandText = "ADOTestRPE"
End With
'Parameter 0 is the stored procedure Return code.

sParmName = "Return"
Set ADOPrm = ADOCmd.CreateParameter(sParmName, adInteger, _
adParamReturnValue, , 0)
ADOCmd.Parameters.Append ADOPrm
ADOCmd.Parameters(sParmName).Value = -1
'Parameter 1 is the setting for the stored procedure Output

' parameter.
sParmName = "Output"
adParamOutput)
ADOCmd.Parameters(sParmName).Value = 999
'Parameter 2
sParmName = "R1Num" 'Number of rows to return in Resultset 1.
adParamInput)
'Parameter 3
sParmName = "P1Num" 'Number of PRINT statements in Resultset 1.
adParamInput)
'Parameter 4
sParmName = "E1Num" 'Number of RAISERROR statements in Resultset
'1.
adParamInput)
'Parameter 5
sParmName = "R2Num" 'Number of rows to return in Resultset 2.
adParamInput)
'Parameter 6
sParmName = "P2Num" 'Number of PRINT statements in Resultset 2.
adParamInput)
'Parameter 7
sParmName = "E2Num" 'Number of RAISERROR statements in Resultset
' 2.
adParamInput)
Set ADORs = ADOCmd.Execute
Do While (Not ADORs Is Nothing)

If ADORs.State = adStateClosed Then Exit Do
While Not ADORs.EOF
For i = 0 To ADORs.Fields.Count - 1
rStr = rStr & " : " & ADORs(i)
Next i
Debug.Print Mid(rStr, 3, Len(rStr))
ADORs.MoveNext
rStr = ""
Wend
Wend
Debug.Print "----------------------"
Set ADORs = ADORs.NextRecordset
Loop
Debug.Print "Return: " & ADOCmd.Parameters("Return").Value

Debug.Print "Output: " & ADOCmd.Parameters("Output").Value
GoTo Shutdown
ErrHandler:
Call ErrHandler(ADOCon)
Resume Next
Shutdown:
Set ADOCmd = Nothing
Set ADOPrm = Nothing
Set ADORs = Nothing
Set ADOCon = Nothing
End Sub
Private Sub Command1_Click()
Call CreateParms
End Sub
Sub ErrHandler(objCon As Object)
Dim ADOErr As ADODB.Error

Dim strError As String
For Each ADOErr In objCon.Errors

strError = "Error #" & ADOErr.Number & vbCrLf & ADOErr.Description _
& vbCr & _
" (Source: " & ADOErr.Source & ")" & vbCr & _
" (SQL State: " & ADOErr.SQLState & ")" & vbCr & _
" (NativeError: " & ADOErr.NativeError & ")" & vbCr
If ADOErr.HelpFile = "" Then
strError = strError & " No Help file available" & vbCr & vbCr
Else
strError = strError & " (HelpFile: " & ADOErr.HelpFile & ")" _
& vbCr & _
" (HelpContext: " & ADOErr.HelpContext & ")" & _
vbCr & vbCr
End If
Debug.Print strError
Next
objCon.Errors.Clear
End Sub
5. Modifiez la valeur des paramètres 2 à 7 pour modifier le nombre d’instructions et/ou d’instructions
générées par la procédure stockée et renvoyées via PRINT RAISERROR ADO. Exécutez à nouveau Visual
Basic exemple de code et notez que les instructions et les instructions sont renvoyées par le biais de la
collection d’erreurs RAISERROR PRINT ADO. Modifiez les valeurs pour expérimenter différentes
combinaisons PRINT/RAISERROR d’instructions avec différents jeux de résultats. Reportez-vous SQL
procédures stockées pour des solutions de contournement spécifiques pour des cas particuliers.
Pour récupérer une valeur RETURN dans ADO avec une procédure stockée, il doit y avoir au moins un resultset.
Pour contourner ce problème, lorsqu’aucun jeu de résultats n’est spécifié (dans l’exemple de code ADO), la
procédure stockée exécute une valeur SELECT NULL pour renvoyer un jeu de résultats null à ADO, ce qui remplit
la valeur RETURN. En outre, pour contourner le problème de spécification d’aucune instruction et d’une
combinaison d’instructions, les instructions par défaut sont générées afin de fournir un contexte pour renvoyer
l’instruction RAISERROR PRINT via RAISERROR PRINT ADO. Vous devez coder les instructions au format indiqué
dans la procédure stockée, car seuls les niveaux de gravité de 11 à 18 reviennent par le biais de la collection
d’erreurs RAISERROR ADO.
Références
RAISERROR (Transact-SQL)
SQL Server clients peuvent modifier les protocoles
lorsque les ordinateurs clients tentent de se
connecter à une instance de SQL Server
Cet article présente SQL Server clients peuvent modifier les protocoles lorsque les ordinateurs clients tentent de
se connecter à une instance de SQL Server.
Résumé
Les ordinateurs clients qui ont microsoft Data Access Components (MDAC) version 2.6 ou ultérieure peuvent
essayer plusieurs protocoles ou mécanismes IPC (Interprocess Communication) pour établir des connexions à
SQL Server.
Une amélioration a été apportée à la bibliothèque réseau côté client, Dbnetlib.dll pour MDAC version 2.6 et
versions ultérieures. Avec MDAC version 2.6 et versions ultérieures, si plusieurs protocoles sont disponibles et
qu’une tentative de connexion avec le premier protocole échoue, l’application cliente tente immédiatement
d’utiliser l’un des autres protocoles.
Par défaut, les clients disposent de protocoles TCP et Canaux nommés en tant que protocoles disponibles. Vous
pouvez manipuler l’ordre de protocole à l’aide de l’utilitaire SQL Server client. L’application cliente utilise les
protocoles dans l’ordre spécifié sur l’ordinateur client. L’ordre de protocole est stocké à l’emplacement de clé de
Registre suivant sous la valeur ProtocolOrder :
HKLM\Software\Microsoft\MSSQLServer\Client\SuperSocketNetLib
Si vous utilisez SQL Server 2005, l’ordre de protocole est stocké dans l’entrée de Registre ProtocolOrder sous
la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI<version>
Par exemple, si un ordinateur client dispose à la fois de TCP et de canaux nommés, et que la commande est la :
TCP
Canaux nommés
Lorsque l’ordinateur client tente d’établir une connexion TCP au serveur et que la tentative de connexion renvoie
un code de retour non nul, le client tente de façon transparente une connexion à l’aide du protocole suivant de la
liste, nommé Canaux. Dans ce scénario, le client ne peut pas établir de connexion TCP ; toutefois, le client a réussi
à établir une connexion Canaux nommés.
NOTE
Le client ne reçoit pas d’erreur qui indique que le premier protocole a échoué.
Si l’application cliente utilise le deuxième protocole et renvoie également une erreur, une erreur est renvoyée au
client.
Si vous créez un alias à l’aide de l’une des méthodes suivantes, l’application cliente utilise les informations d’alias
pour établir une connexion au serveur et n’utilise aucun protocole supplémentaire.
Utilisation de l’utilitaire SQL Server client
À l’aide Gestionnaire de configuration SQL Server
Lorsque vous créez un nom de source de données ODBC (DSN)
Si vous souhaitez contrôler le protocole utilisé par une application cliente pour chaque tentative de connexion et
ne pas autoriser le client à essayer plusieurs protocoles, vous pouvez :
Utilisez l SQL ou l’Gestionnaire de configuration SQL Server client pour créer un alias en spécifiant le
protocole de votre préférence.
Spécifiez le protocole dans votre chaîne de connexion. Par exemple :
DSN=DSNName;SERVER=servername;DATABASE=YourDataBaseName;Network=DBMSSOCN;Address=IP_Address,1433;UID=
YourUID;PWD=YourPassword;
Dans cet exemple, vous spécifiez le protocole réseau comme , ce qui signifie que vous souhaitez utiliser le
protocole DBMSSOCN TCP/IP. Si vous spécifiez le protocole à l’intérieur de votre chaîne de connexion,
Dbnetlib utilise uniquement le protocole spécifié et n’essaie aucun autre protocole. De même, pour activer
le protocole Named Pipe uniquement, utilisez une chaîne de connexion semblable à celle-ci :
DSN=DSNName;SERVER=servername;DATABASE=YourDataBaseName;Network=DBNMPNTW;Address=\\.\pipe\sql\query;U
ID=YourUID;PWD=YourPassword;
Utilisez l’utilitaire réseau client pour supprimer d’autres protocoles.
RÉFÉRENCES
Résolution des erreurs de connectivité SQL Server
SQLDescribeCol renvoie un type de données et une
longueur de colonnes erronés dans une requête
Union complexe avec des paramètres
Cet article vous aide à résoudre le problème où la commande renvoie une longueur de colonne et un type de
données erronés dans une requête Union complexe qui possède SQLDescribeCol des paramètres.
Version du produit d’origine : SQL Server 2008, Microsoft SQL Server 2005
Résumé
Vous utilisez une version de Microsoft SQL Server Native Client antérieure à Microsoft SQL Server Native
Client 11.0.
Votre code appelle la fonction pour une requête Union complexe qui contient des SQLDescribeCol
paramètres et une clause WHERE.
Dans ce scénario, renvoie une longueur de colonne et un SQLDescribeCol type de données incorrects.
Cause
Ce problème se produit car le pilote tronque la requête pour les métadonnées sur le mot clé UNION. Par
conséquent, SQL Server les métadonnées uniquement pour la première requête et ignore la deuxième requête.
Si vous modifiez l’ordre des requêtes, SQLDescribeCol renvoie les données correctes.
Résolution
Pour résoudre ce problème, utilisez SQL Server Native Client 11.0 ou une version ultérieure dans votre
application. Pour obtenir SQL Server Native Client 11.0 ou pour plus d’informations, voir Microsoft SQL Server
2012 SP4 Feature Pack.
Pour contourner ce problème, prenez l’une des mesures suivantes :
Compilez la requête en une procédure stockée qui utilise des paramètres.
Inverser l’ordre des instructions dans la requête Union afin que le champ SELECT constant se trouve dans la
dernière SELECT instruction.
État
Microsoft a confirmé qu’il s’agit d’un problème connu dans les versions SQL Server et SQL Server Native Client.
Microsoft a confirmé qu’il s’agit d’un bogue dans les produits Microsoft répertoriés au début de cet article.
S’applique à
v R2 Enterprise
Microsoft SQL Server 2005 Êdition Entreprise
Microsoft SQL Server 2005 Édition Standard
Utiliser le paramètre nom du serveur dans une
chaîne de connexion pour spécifier la bibliothèque
réseau cliente
Résumé
Cet article explique comment spécifier par programme la bibliothèque réseau cliente dans la chaîne de
connexion lorsque vous vous connectez à une base de données SQL Server client.
Dans Microsoft Data Access Components (MDAC) 2.6 et les ultérieures, vous pouvez spécifier la bibliothèque
d’accès au client à l’aide du paramètre nom du serveur dans la chaîne de connexion. Par conséquent, vous
pouvez spécifier une bibliothèque d’accès au client spécifique lorsque vous êtes invité par une application à
indiquer un nom de serveur auquel vous connecter. Ce comportement peut être utile lorsque vous testez et
dépannage des problèmes de connectivité pour SQL Server.
Par exemple, vous pouvez utiliser l’utilitaire de ligne de commande Osql pour vous connecter à SQL Server et le
forcer à utiliser la bibliothèque réseau TCP/IP :
osql -Stcp:myServer,portNumber -E

Exemple de code
L’exemple de code Microsoft Visual C# .NET suivant montre comment définir la chaîne de connexion. La chaîne
de connexion a le même format quelle que soit la langue que vous utilisez :
using System;
using System.Data;
namespace getCurrentProtocol
{
/// <summary>
/// Main Application Driver Class
/// </summary>
class Driver
{
static void Main(string[] args)
{
string sCxn = "server=myServer;Integrated Security=SSPI; database=master";
//string sCxn = "server=np:myServer;Integrated Security=SSPI; database=master";
//string sCxn = "server=tcp:myServer;Integrated Security=SSPI; database=master";
//string sCxn = "server=rpc:myServer;Integrated Security=SSPI; database=master";
//string sCxn = "server=lpc:myServer;Integrated Security=SSPI; database=master";
string sCmd = "SELECT net_library from sysprocesses where spid=@@spid";
SqlConnection cxn = new SqlConnection(sCxn);
SqlCommand sqlCmd = new SqlCommand(sCmd, cxn);
SqlDataAdapter sqlDa = new SqlDataAdapter(sCmd, cxn);
DataTable dt = new DataTable();
try
{
sqlDa.Fill(dt);
Console.WriteLine("Hit ENTER to continue ...");
Console.ReadLine();
foreach (DataRow dr in dt.Rows)
Console.WriteLine(dr["net_library"]);
}
catch (SqlException e)
{
Console.WriteLine(e.StackTrace);
Console.WriteLine("SQL Error Number: " + e.Number);
Console.WriteLine("SQL Error Message: " + e.Message);
}
}
}
}
NOTE
Chaîne de connexion et en particulier la valeur du paramètre serveur :
string sCxn = "server=myServer;Integrated Security=SSPI; database=northwind"
Utiliser l’exemple de code avec diverses bibliothèques réseau

Les exemples de code suivants montrent comment utiliser la valeur du paramètre serveur pour spécifier
différentes bibliothèques réseau :
TCP/IP :
server=tcp:hostname
Vous pouvez éventuellement spécifier un numéro de port spécifique. Par défaut, le port est 1433.
server=tcp:hostname, portNumber
Canaux nommés :
server=np:hostname
Vous pouvez éventuellement spécifier un canal nommé spécifique.
server=np:\\hostname\pipe\pipeName
Par défaut, le nom du canal est sql\query. Si vous vous connectez à une instance nommée, le nom du
canal est généralement au format suivant :
MSSQL$instnaceName\sql\query
La valeur par défaut du protocole sous-jacent est déterminée par les paramètres du système
d’exploitation où un protocole peut avoir l’une des valeurs suivantes :
VA L EUR P ROTO C O L E SO US- JA C EN T
ncacn_np Canaux nommés
ncacn_ip_tcp Protocole TCP/IP (Transmission Control Protocol/Internet

Protocol)
ncalrpc Appel de procédure locale
Mémoire partagée :
server=lpc:hostname
Références
Pour plus d’informations, consultez l’Annexe A : Entrées de Registre.
Détecter une inclinaison des données sur les valeurs
des clés de distribution
Cet article montre comment détecter une inclinaison sur la clé de distribution d’une table distribuée dans une
appliance Parallel Data Warehouse.
Version du produit d’origine : SQL Server 2008 R2 Parallel Data Warehouse
Résumé
Une inclinaison des données peut se produire à différents niveaux dans Microsoft SQL Server Parallel Data
Warehouse. Cet article se concentre sur les lignes qui sont obliques vers certaines valeurs. Une table distribuée
peut ainsi placer plus de données sur une distribution que sur les autres distributions. La requête suivante
compte le nombre de lignes qui ont une valeur spécifique pour la clé de distribution de la table :
select distribution_key, count(distribution_key)
from distributed_table
group by distribution_key
--having count(distribtuion_key) >5000
order by count(distribtuion_key) desc
NOTE
La having clause est commentée. Toutefois, si vous souhaitez vérifier rapidement s’il existe une inclinaison significative,
cette clause peut vous indiquer. Vous de devez peut-être ajuster la valeur ayant un sens pour votre jeu de résultats. Par
exemple, si toutes les valeurs ont 5 000 enregistrements, nous vous recommandons de définir cette valeur sur 7 500 ou
10 000 pour indiquer un problème.
La question de savoir quand une inclinaison devient un problème n’a pas de réponse déterministe. Une
inclinaison devient un problème lorsque les performances des distributions obliques deviennent perceptibles et
que l’application ne peut pas tolérer la situation. La règle générale est que l’appliance peut tolérer une
inclinaison de 10 à 20 % dans toutes les tables. À l’intérieur de ce seuil, les distributions obliques doivent même
sortir en cas de concurrence. Au-dessus de ce seuil, vous pouvez commencer à voir certaines distributions de
longue durée lorsque les données sont traitées. Certaines implémentations peuvent être en mesure de tolérer
une plus grande inclinaison, et d’autres peuvent ne pas pouvoir tolérer autant. Des tests sont nécessaires pour
déterminer le seuil réel de votre implémentation.
Si la valeur oblique est également utilisée comme condition de jointeur et que l’autre côté est oblique vers la
même valeur, il peut y avoir une explosion dans le nombre de lignes à partir de la jointeur. Cela peut entraîner
un temps d’exécution de requête long.
IMPORTANT
Prêtez une attention particulière au nombre de valeurs NULL, car cela peut entraîner des problèmes pour les jointeurs.
Erreur 105005 lors de l’opération CETAS sur le
stockage d’objets blob Azure
Cet article vous aide à résoudre le problème qui se produit lorsque vous faites une opération sur le stockage
CREATE EXTERNAL TABLE AS SELECT (CETAS) Blob Azure à l’aide de PolyBase.
Version du produit d’origine : SQL Server 2012 Parallel Data Warehouse (APS), SQL Server 2008 R2 Parallel
Data Warehouse
Symptômes
Lorsque vous faites une opération CREATE EXTERNAL TABLE (Transact-SQL) vers le stockage d’objets blob Azure
à l’aide de PolyBase ? à partir de l’appliance Microsoft SQL Server Parallel Data Warehouse (PDW), le service
Azure renvoie le message d’erreur suivant :
Msg 105005, Level 16, State 1, Server [Server name], LineLineNumber

CREATE EXTERNAL TABLE AS SELECT statement failed as the path name 'wasbs://[Container name]@[Storage
name].blob.core.windows.net/[Location name]' could not be used for export.
Please ensure that the specified path is a directory which exists or can be created, and that files can be
created in that directory.
Cause
Cette erreur se produit car PolyBase ne peut pas terminer l’opération. L’échec de l’opération peut être dû à l’une
des opérations suivantes ou les deux :
Défaillance du réseau lorsque vous essayez d’accéder au stockage d’objets blob Azure sur les ports réseau
requis.
Configuration du compte de stockage Azure
Résolution
Pour résoudre ce problème, assurez-vous que les conditions préalables suivantes sont remplies.
Exigences réseau :
Autorisez les ports de pare-feu local 80 et 443 sortants vers *.blob.core.windows.net à partir du nœud
CTL01 via une connectivité Internet fournie.
Stockage conditions requises pour les comptes :
Assurez-vous que le compte de stockage est configuré en tant que compte de stockage standard
qui utilise l’une des options de réplication de stockage suivantes (classique ou basée sur le
Gestionnaire de ressources) :
Standard Locally Redundant Stockage (Standard-LRS)
Standard Geo-Redundant Stockage (Standard-GRS)
Pour les comptes de stockage basés sur le Gestionnaire de ressources :
Configurez le compte à des fins générales.
NOTE
Lorsque vous utilisez des comptes de stockage basés sur le Gestionnaire de ressources, assurez-vous que le compte est
configuré à des fins générales. Si vous utilisez le Magasin d’objets Blob, un message d’erreur est renvoyé.
Pour plus d’informations sur PolyBase, consultez les articles Azure suivants :
Didacticiel : Charger des données dans le pool de SQL Azure Synapse Analytics
Meilleures pratiques pour le chargement des données à l’aide du pool SQL synapse
Évaluer la précision des statistiques PDW
Cet article montre comment évaluer la précision des statistiques PDW d’une table PDW ou de toutes les tables
d’une base de données PDW en fonction du nombre total de lignes.
Version du produit d’origine : SQL Server 2012 Parallel Data Warehouse (APS), SQL Server 2008 R2 Parallel
Data Warehouse
Résumé
Cet article contient une requête pour comparer le nombre réel de lignes et le nombre de lignes dans les
statistiques parallel Data Warehouse pour une table spécifique ou pour toutes les tables de la base de données
actuelle. Si les valeurs de nombre de lignes diffèrent trop fortement, Parallel Data Warehouse n’a pas de
statistiques précises pour cette table. Cela peut entraîner le choix par l’optimiseur Parallel Data Warehouse des
opérations et des mouvements de données qui ne sont pas efficaces et qui peuvent entraîner de longs temps
d’utilisation des requêtes.
Exécutez la requête suivante pour afficher une comparaison entre le nombre réel de lignes et le nombre de
lignes CTL affiché dans les statistiques parallel Data Warehouse :
SELECT db_name() as [Database],
pdwtbl.name as [Table],
Sum(part.rows)/ max(pdwpart.partition_number)/8 AS CMP_ROW_COUNT,
sum(pdwpart.rows)/max(size.distribution_id)/max(pdwpart.partition_number)/8 AS CTL_ROW_COUNT
FROM sys.pdw_nodes_partitions part
JOIN sys.pdw_nodes_tables tbl
ON part.object_id = tbl.object_id
AND part.pdw_node_id = tbl.pdw_node_id
JOIN sys.pdw_distributions size
on size.pdw_node_id = tbl.pdw_node_id
JOIN sys.pdw_table_mappings map
ON map.physical_name = tbl.name
JOIN sys.tables pdwtbl
ON pdwtbl.object_id = map.object_id
JOIN sys.partitions pdwpart
ON pdwpart.object_id = pdwtbl.object_id
join sys.pdw_table_distribution_properties dist
on pdwtbl.object_id = dist.object_id
WHERE dist.distribution_policy = 2
-- uncomment the below if you are looking for row counts for a specific table
-- this table will also need to be added below
-- and pdwtbl.name = 'table_name'
GROUP BY pdwtbl.name
UNION ALL
SELECT db_name() as [Database],
pdwtbl.name,
Sum(part.rows)/ sum(pdwpart.partition_number) AS CMP_ROW_COUNT,
sum(pdwpart.rows) /max(pdwpart.partition_number) /(select count(type) from sys.dm_pdw_nodes
where type = ''' + 'COMPUTE' + ''')
AS CTL_ROW_COUNT
FROM sys.pdw_nodes_partitions part
JOIN sys.pdw_nodes_tables tbl
ON part.object_id = tbl.object_id
AND part.pdw_node_id = tbl.pdw_node_id
JOIN sys.pdw_table_mappings map
ON map.physical_name = tbl.name
JOIN sys.tables pdwtbl
ON pdwtbl.object_id = map.object_id
JOIN sys.partitions pdwpart
ON pdwpart.object_id = pdwtbl.object_id
join sys.pdw_table_distribution_properties dist
on pdwtbl.object_id = dist.object_id
where dist.distribution_policy = 3
-- uncomment the below if you are looking for row counts for a specific table
-- this table will also need to be added below
-- and pdwtbl.name = 'table_name'
GROUP BY pdwtbl.name
NOTE
Cette requête évalue uniquement le nombre de lignes et non la cardinalité. Il nécessite également que des statistiques
de niveau entrepôt de données parallèles existent sur au moins une colonne du tableau. Il ne prend pas en compte
l’existence de statistiques sur plusieurs colonnes ou la colonne pour laquelle elles existent.
La valeur de nombre par défaut dans Parallel Data Warehouse est de 1 000 lignes. Si aucune statistiques parallel Data
Warehouse n’a été créée, une valeur de 1 000 est renvoyée pour le nombre de lignes CTL.
Msg 104381 lors de l’exécution d’INSERT... Instruction
SELECT dans Analytics Platform System 2016 ou
versions ultérieures
Cet article vous aide à résoudre le problème qui se produit lorsque vous exécutez une instruction dans
INSERT ... SELECT Microsoft Analytics Platform System (APS) 2016 ou une version ultérieure de APS et cette
instruction inclut une ORDER BY clause.
S’applique à : Microsoft Analytics Platform System
Symptômes
Lorsque vous exécutez une instruction dans APS 2016 ou une version ultérieure de APS et que cette instruction
inclut une clause, vous recevez un message d’erreur ressemblant à ce qui INSERT ... SELECT ORDER BY suit :

La clause ORDER BY n’est pas valide dans les affichages, CREATE TABLE AS SELECT, INSERT SELECT,
fonctions inline, tableaux dérivés, sous-quers et expressions de tableau courantes;
sauf si le XML TOP ou FOR est également spécifié.
Cause
Ce problème se produit car les opérations de tri ne sont pas valides avec INSERT ... SELECT l’instruction. Ce
comportement est voulu par la conception même du produit.
Résolution
Pour résoudre ce problème, supprimez ORDER BY la clause de l’instruction.
Dans les versions antérieures APS, aucune erreur n’a pu être renvoyée. Toutefois, la ORDER BY clause n’a pas été
honorée.
System Center Operations Manager ne peut pas
surveiller SQL Server système de plateforme
d’analyse
Cet article vous aide à résoudre le problème où System Center Operations Manager ne peut pas surveiller SQL
Server’appliance système de plateforme d’analyse.
Version du produit d’origine : SQL Server 2012 Parallel Data Warehouse, SQL Server 2008 R2 Parallel Data
Warehouse
Symptômes
Vous avez installé les packs d’administration Microsoft System Center Operations Manager.
Vous ajoutez une appliance SQL Server Du système de plateforme d’analyse (APS) en exécutant
new-apsappliance.ps1 .
Vous pouvez configurer les comptes Watcher et Monitoring.
Dans ce scénario, l’appliance n’est pas surveillée et vous devez faire face à l’un des problèmes suivants :
Problème A : L’appliance n’est pas découverte et n’est pas visible dans Operations Manager.
Problème B : L’appliance est répertoriée dans Operations Manager, mais elle est dans l’état NOT
MONITORED.
Cause
Ce problème est dû à une erreur qui se produit lors de la découverte. Pour voir les informations d’erreur,
consultez le journal des événements Operations Manager sur le nœud de l’observeur. Les scénarios d’erreur
suivants peuvent se produire.
Scénario A :
Erreurs pour le APS de l’utilisateur, telles qu’un mot de passe incorrect.
Scénario B :
Erreur consignée dans le journal des événements :
SQL2012APS MP.Appliance:<Fabric name>.Script:APSApplianceNodesDiscovery.vbs: Connection failed

Error Number: 16389
Description: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver
specified
NOTE
Il s’agit d’une erreur ambiguë. APS ne nécessite plus de DSN. Les informations sur l’appliance sont ajoutées et
utilisées dans le Registre.
Résolution
Pour résoudre ce problème, suivez ces étapes selon le scénario d’erreur.
Pour le scénario A :
Corrigez le mot de passe dans Operations Manager.
Pour le scénario B :
Vérifiez que l’appliance est ajoutée au Registre du nœud de l’observeur.
NOTE
L’adresse IP spécifiée doit être pour l’APS IP du nœud de contrôle. Elle doit se trouver sous la sous-clé de
Registre suivante :
HKLM\SOFTWARE\Microsoft\Analytics Platform System\Management Pack\Appliances
Vérifiez que SQL Server Native Client est installé.

Un appel à la fonction API
AuthzInitializeContextFromSid échoue lors de la
remise d’un abonnement de messagerie SQL Server
Reporting Services
Cet article vous aide à résoudre le problème que vous pouvez avoir avec l’appel de fonction API lors de la
remise AuthzInitializeContextFromSid d’un abonnement de messagerie.
Résumé
Cet article décrit la cause et certaines résolutions possibles d’un problème qui peut se produire dans Microsoft
SQL Server Reporting Services et Power BI Report Server, en SQL Server Reporting Services, lorsque vous
essayez de créer et de traiter un abonnement de messagerie à l’aide d’un compte d’utilisateur de domaine. Le
problème se produit lorsqu’un appel de fonction API dans AuthzInitializeContextFromSid le fichier Authz.dll'est
pas réussi.
NOTE
Ce problème ne se produit pas dans Windows Server 2008.
Les résolutions abordées dans cet article sont les suivantes :

Comment configurer le service Reporting Services Windows pour qu’il s’exécute sous un compte d’utilisateur de
domaine. Si cela ne résout pas le problème, vous devez également utiliser l’une des méthodes suivantes :
Accordez l’autorisation de lecture pour le compte d’utilisateur de domaine sur tous les comptes d’utilisateur
et tous les groupes du domaine.
Accordez l’autorisation de lecture pour le compte d’utilisateur de domaine spécifiquement sur un compte
d’utilisateur ou sur un groupe dont l’utilisateur est membre.
Introduction
Cet article traite d’un problème associé à l’appel de fonction API qui se produit lors de la remise
AuthzInitializeContextFromSid d’un abonnement de messagerie. Cet article traite également de certaines
résolutions possibles du problème.
Informations détaillées
Lors de la livraison d’un courrier électronique pour un abonnement de messagerie, le programme Reporting
Services peut appeler la fonction API définie dans le AuthzInitializeContextFromSid fichier Authz.dll de
messagerie. Le programme Reporting Services peut appeler la fonction API si l’une
AuthzInitializeContextFromSid des conditions suivantes est vraie :
Un état est incorporé dans le courrier électronique.

Un rapport est joint au courrier électronique.
Si vous créez et traiter l’abonnement de messagerie à l’aide d’un compte d’utilisateur de domaine différent du
compte d’connexion de service du service Reporting Services Windows, l’appel de la fonction API peut
AuthzInitializeContextFromSid échouer.
Si l’appel de fonction échoue, il se peut que vous demandons de configurer les paramètres sur le domaine de
l’ordinateur qui exécute Reporting Services pour résoudre le problème.
Le programme Reporting Services appelle la fonction API pour vérifier si le compte d’utilisateur qui a été utilisé
pour créer l’abonnement dispose toujours des autorisations correctes pour afficher
AuthzInitializeContextFromSid le rapport. Cette vérification n’est pas requise lorsque le courrier électronique
contient uniquement un lien, une URL, vers le rapport, car Reporting Services effectue la vérification des
autorisations utilisateur lorsque l’utilisateur tente d’accéder au rapport à l’aide de l’URL.
L’appel de la fonction API lit l’attribut AuthzInitializeContextFromSid tokenGroupsGlobalAndUniversal (TGGAU)
du numéro d’identification de sécurité (SID) spécifié dans l’appel de fonction API pour déterminer les
informations d’appartenance au groupe Windows pour l’utilisateur AuthzInitializeContextFromSid actuel.
Reporting Services appelle la fonction API à l’aide du contexte de sécurité du compte d’connexion de service du
service Windows AuthzInitializeContextFromSid Reporting Services. Par conséquent, le compte d’utilisateur
que vous utilisez pour exécuter le service Reporting Services Windows doit avoir les autorisations suffisantes
pour lire l’attribut sur le compte d’utilisateur utilisé pour créer et traiter les abonnements de TGGAU messagerie.
Si l’ordinateur n’est pas configuré correctement pour accéder à la fonction API et l’exécuter dans le fichier
Authz.dll, vous pouvez recevoir un AuthzInitializeContextFromSid message d’erreur. En outre, un message
d’erreur peut être écrit dans le fichier journal Reporting Services. Pour déterminer l’erreur qui s’est produite,
suivez les étapes suivantes :
1. Ouvrez ReportServerService_ fichier .log d’timestamp. Recherchez le mot authz .
NOTE
Par défaut, le ReportServerService_ .log d’timestamp se trouve dans
<Installation drive>:\Program Files\Microsoft SQL Server\<InstanceOfSQLServer>\Reporting
Services\Logfiles folder
le fichier .
Dans le ReportServerService_ .log d’timestamp, vous pouvez remarquer des messages d’erreur
semblables aux suivants :
ReportingServicesService!library!718!06/16/2004-00:00:03:: e ERROR: Throwing

Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The
Report Server has encountered a configuration error; plus de détails dans les fichiers journaux,
AuthzInitializeContextFromSid : Erreur Win32 : 5; raison possible : le compte de service n’a pas
le droit de vérifier les SID d’utilisateur de domaine. Info :
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException : le
serveur de rapports a rencontré une erreur de configuration ; plus de détails dans les fichiers
journaux.
ReportingServicesService!library!7e4!05/24/2004-10:00:22:: e ERROR: Throwing

Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The
Report Server has encountered a configuration error; plus de détails dans les fichiers journaux,
AuthzInitializeContextFromSid : Erreur Win32 : 1722; Info :
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException : le
serveur de rapports a rencontré une erreur de configuration ; plus de détails dans les fichiers
journaux.
2. Modifiez l’abonnement de messagerie à l’origine du message d’erreur. N’incorporez pas ou n’attachez pas
de rapport dans le courrier électronique. Utilisez un lien vers le rapport. Après avoir traitée l’abonnement
modifié, si vous ne recevez pas de message d’erreur, vous pouvez confirmer que l’erreur s’est produite en
raison de l’échec de l’appel de la fonction AuthzInitializeContextFromSid API.
Vous pouvez utiliser la méthode 1 si les conditions suivantes sont vraies :
Le service Windows Reporting Services est en cours d’exécution sous le compte service réseau.
Vous ne souhaitez pas modifier le compte sous Windows service Reporting Services. Vous pouvez utiliser la
méthode 2 pour une résolution générale. Si la méthode 2 ne résout pas le problème, utilisez la méthode 3.
Méthode 1
1. Ajoutez le Windows au groupe Accès à la compatibilité pré-Windows 2000 à l’aide du logiciel en ligne
Utilisateurs et ordinateurs Active Directory.
2. Ajoutez le Windows au groupe d’accès Windows’autorisation à l’aide du logiciel en ligne Utilisateurs et
ordinateurs Active Directory.
3. Redémarrez l’ordinateur qui exécute Reporting Services.
NOTE
Le Windows à l’étape 1 et à l’étape 2 est le compte que vous utilisez pour exécuter Reporting Services.
Une fois que vous avez ajouté le compte à ces groupes, il est garanti que Reporting Services peut accéder à l’attribut
TGGAU.
Cette méthode ne vous oblige pas à modifier les autorisations sur un utilisateur ou un groupe.
Méthode 2
Configurez le service Windows Reporting Services pour qu’il s’exécute sous un compte d’utilisateur de domaine.
NOTE
Un message d’erreur peut être écrit dans le journal de suivi de Reporting Services lorsque vous essayez de modifier le
compte d’utilisateur utilisé pour exécuter le service d’Windows Reporting Services.
Méthode 3
Configurez les paramètres sur le domaine de l’ordinateur qui exécute Reporting Services. Pour ce faire, utilisez
l’une des méthodes suivantes.
Accorder l’autorisation de lecture sur tous les comptes d’utilisateurs et sur tous les groupes du domaine
Vous pourrez peut-être résoudre le problème en accordant des autorisations de lecture pour le compte
d’utilisateur que vous utilisez pour exécuter le service Reporting Services Windows afin de lire l’attribut sur tous
les comptes d’utilisateur et tous les groupes dans le TGGAU domaine. Pour ce faire, utilisez les informations de
l’une des sections suivantes, en fonction du système d’exploitation que vous utilisez.
Pour un domaine Microsoft Windows 2000
Si le domaine est en mode d’accès préalable à la compatibilité Windows 2000, le groupe EVERYONE dispose de
l’autorisation de lecture sur l’attribut pour tout le compte d’utilisateur et tous les TGGAU groupes. Par
conséquent, le compte d’utilisateur que vous utilisez pour exécuter le service Reporting Services Windows a
accès à l’attribut sur le compte d’utilisateur que Reporting Services utilise pour créer l’abonnement TGGAU de
messagerie.
Si le domaine n’est pas en mode d’accès à la compatibilité pré-Windows 2000, également appelé mode natif,
vous devez accorder une autorisation de lecture pour le compte d’utilisateur utilisé pour exécuter le service
Windows Reporting Services afin qu’il puisse lire l’attribut sur le compte d’utilisateur que Reporting Services
utilise pour créer TGGAU l’abonnement. Vous pouvez créer un groupe local de domaine qui simule le groupe de
compatibilité pré-Windows 2000, ajouter le compte d’utilisateur que vous utilisez pour exécuter le service
Windows Reporting Services à ce groupe, puis accorder des autorisations de lecture pour le groupe sur tous les
comptes d’utilisateur. Pour cela, procédez comme suit :
NOTE
Vous devez avoir des autorisations d’administrateur sur le domaine pour suivre ces étapes.
1. Cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis cliquez sur
Utilisateurs et ordinateurs Active Director y.
2. Dans la fenêtre Utilisateurs et ordinateurs Active Director y, dans le volet gauche, développez
DomainName .
3. Cliquez avec le bouton droit sur Utilisateurs, pointez sur Nouveau, puis cliquez sur Groupe.
4. Dans la boîte de dialogue Nouvel objet - Groupe, tapez MyAuthZGrp dans la zone Nom du groupe.
5. Sous l’étendue Groupe, sélectionnez l’option locale Domaine, puis cliquez sur OK. Le groupe
MyAuthZGrp peut apparaître dans le volet droit.
6. Dans le volet gauche de la fenêtre Utilisateurs et ordinateurs Active Director y, cliquez avec le bouton droit
sur le dossier Utilisateurs, puis cliquez sur Propriétés.
7. Dans la boîte de dialogue Propriétés des utilisateurs, cliquez sur l’onglet Sécurité.
8. Cliquez sur Ajouter .
9. Dans la boîte de dialogue Sélectionner des utilisateurs, des ordinateurs ou des groupes,
sélectionnez le groupe que vous avez créé à l’étape 5.
10. Cliquez sur Ajouter , puis sur OK .
11. Accordez une autorisation de lecture au compte d’utilisateur que vous avez sélectionné à l’étape 9.
Pour un domaine Microsoft Windows Server 2003
Si le domaine est au niveau fonctionnel Windows 2000, le groupe EVERYONE dispose d’autorisations de lecture
sur l’attribut TGGAU de tous les comptes et groupes d’utilisateurs. Par conséquent, le compte de service
Reporting Service dispose des autorisations correctes sur le compte d’utilisateur qui a créé l’abonnement de
messagerie.
Si le domaine se trouve à un niveau fonctionnel Windows Server 2003, le groupe d’accès à l’autorisation
Windows (groupe WAA) dispose d’autorisations de lecture sur l’attribut TGGAU de tous les comptes et groupes
d’utilisateurs. Par conséquent, si vous ajoutez le compte de service Reporting Services au groupe WAA, le
compte de service Reporting Services dispose d’autorisations de lecture sur l’attribut TGGAU des comptes
d’utilisateurs qui peuvent créer des abonnements de messagerie.
Pour ajouter le compte de service Reporting Services au groupe WAA, suivez les étapes suivantes :
1. Sur le contrôleur de domaine, cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils
d’administration, puis cliquez sur Utilisateurs et ordinateurs Active Director y.
2. Dans la fenêtre Utilisateurs et ordinateurs Active Directory, développez DomainName, puis cliquez sur
Utilisateurs ou une autre unité d’organisation appropriée.
3. Double-cliquez sur le compte de service Reporting Services.
4. Dans la boîte de dialogue Propriétés, cliquez sur l’onglet Membre de.
5. Sous l’onglet Membre de, cliquez sur Ajouter.
6. Dans la boîte de dialogue Sélectionner des groupes, tapez Windows groupe d’accès d’autorisation sous
Entrez les noms des objets à sélectionner, puis cliquez sur OK.
7. Redémarrez le service Reporting Services.
Accorder des autorisations de lecture à un compte d’utilisateur ou à un groupe spécifique qui peut créer un
abonnement Reporting Services
Vous ne souhaitez peut-être pas accorder d’autorisations de lecture à l’attribut TGGAU de tous les comptes et
groupes d’utilisateurs. Au lieu de cela, vous pouvez accorder des autorisations de lecture à l’attribut TGGAU d’un
compte d’utilisateur ou d’un groupe spécifique.
NOTE
Le compte d’utilisateur que Reporting Services utilise pour exécuter l’abonnement est le compte Windows utilisateur
qui se connecte au Gestionnaire de rapports lors de la création de l’abonnement.
Ces étapes ne sont pas nécessaires si le compte de service Reporting Services se trouve dans le groupe WAA.
Vous devez suivre ces étapes pour chaque compte d’utilisateur ou groupe qui peut créer un abonnement de
messagerie dans Reporting Services.
Pour accorder des autorisations de lecture à l’attribut d’un compte d’utilisateur ou d’un groupe TGGAU
spécifique, suivez les étapes suivantes :
1. Sur un contrôleur de domaine, cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils
d’administration, puis cliquez sur Utilisateurs et ordinateurs Active Director y.
2. Dans le menu Affichage, assurez-vous que l’élément Fonctionnalités avancées est sélectionné.
3. Double-cliquez sur le compte d’utilisateur ou le groupe qui peut créer un abonnement Reporting Services.
4. Dans la boîte de dialogue Propriétés , cliquez sur l'onglet Sécurité .
5. Sous l’onglet Sécurité , cliquez sur Ajouter .
6. Dans la boîte de dialogue Sélectionner des utilisateurs, des ordinateurs ou des groupes, tapez le compte de
service Reporting Services sous Entrez les noms des objets à sélectionner, puis cliquez sur OK .
7. Dans la boîte de dialogue Propriétés, cliquez sur le compte d’utilisateur que vous avez ajouté à l’étape 6
sous Les noms de groupes ou d’utilisateurs.
8. Sous Autorisations pour Utilisateur, cliquez pour cocher la case Autoriser en regard de l’autorisation de
lecture, puis cliquez sur OK.
NOTE
Les modifications peuvent ne pas prendre effet immédiatement.
Comment configurer les paramètres de domaine sur l’ordinateur

La configuration du domaine dépend du mode d’exploitation du Windows Microsoft. En outre, vous devez
activer les fonctionnalités avancées sur Windows domaine. Pour rechercher le mode d’opération de domaine sur
le contrôleur de domaine et activer les fonctionnalités avancées, suivez les étapes suivantes :
1. Cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis cliquez sur
Utilisateurs et ordinateurs Active Director y.
2. Dans la fenêtre Utilisateurs et ordinateurs Active Director y, dans le volet gauche, cliquez avec le bouton
droit sur DomainName, puis cliquez sur Propriétés.
3. Dans la boîte de dialogue ****Propriétés domainName, consultez la zone de texte Mode d’opération
Domaine sous l’onglet Général.
La zone de texte Mode d’opération Domaine indique le mode d’opération de domaine actuellement utilisé
par le domaine. 4. Dans le volet gauche de la fenêtre Utilisateurs et ordinateurs Active Director y, cliquez sur
DomainName . 5. Dans le menu Affichage , cliquez sur Fonctionnalités avancées . Pour plus d’informations
sur les API qui nécessitent l’accès à l’autorisation sur les comptes d’utilisateur, voir Certaines applications et API
nécessitent l’accès aux informations d’autorisation sur les objets de compte.
Meilleures pratiques pour modifier le compte de
service pour le serveur de rapports dans SQL
Server Reporting Services
Cet article présente les meilleures pratiques pour modifier le compte de service pour le serveur de rapports
dans Microsoft SQL Server Reporting Services et Power BI Report Server.
Introduction
Dans Microsoft SQL Server Reporting Services, vous pouvez configurer le serveur de rapports pour utiliser le
type d’informations d’identification du service pour la connexion de base de données. Lorsque vous essayez de
modifier le compte de service à l’aide de la console de gestion Services.msc, l’opération peut endommagé la clé
de chiffrement utilisée pour protéger les informations sensibles stockées dans la base de données du serveur de
rapports. Nous vous recommandons de modifier le compte de service pour le serveur de rapports à l’aide de
l’une des méthodes suivantes :
Méthode 1
Utilisez Reporting Services Configuration Manager pour modifier le compte de service pour le serveur de
rapports. Pour ce faire, suivez les étapes suivantes :
1. Ouvrez Reporting Services Configuration Manager, puis connectez-vous à l’instance de SQL Server
Reporting Services.
2. Cliquez sur Identité du ser vice Microsoft dans le volet gauche.
3. Modifiez le compte et le mot de passe dans les zone de texte Compte et Mot de passe, puis cliquez sur
Appliquer .
Méthode 2
Utilisez Rsconfig.exe l’utilitaire pour modifier le compte de service pour le serveur de rapports. Pour ce faire,
exécutez la commande suivante :
Rsconfig -c -s <Server Name> -d <Database Name> -u <User Name> -p <Password> -a <Authentication Method>
NOTE
Si l’instance de SQL Server qui héberge la base de données du serveur de rapports est une instance nommée, ajoutez le
commutateur -i pour spécifier le nom de l’instance.
Méthode 3
Si les méthodes 1 et 2 ne fonctionnent pas, utilisez rskeymgmt l’utilitaire. Lorsque vous utilisez cet utilitaire, vous
devez back up the encrypted keys before you change the user account that is used to run the Report Server
Microsoft service or the Report Server Web service, and then you must apply the keys that were backed up.
Pour ce faire, suivez les étapes suivantes sur l’ordinateur qui exécute le service :
1. Démarrez le service Microsoft du serveur de rapports et le service Web Report Server à l’aide du compte
d’utilisateur pour qui le service s’erait correctement.
2. Utilisez rskeymgmt l’utilitaire de ligne de commande pour la back up des clés de chiffrement. Pour ce
faire, exécutez la commande à l’invite de commandes : RSKeyMgmt -e -f <FileName> -p <StrongPassword>
NOTE
Par défaut, rskeymgmt l’utilitaire de ligne de commande se trouve dans
<InstallationDrive>:\Program Files\Microsoft SQL Server\80\Tools\Binn folder le .
Pour plus d’informations sur l’utilitaire de ligne de rskeymgmt commande, exécutez la commande
suivante à l’invite de commandes : rskeymgmt /?
3. Utilisez rskeymgmt l’utilitaire de ligne de commande pour supprimer la référence aux clés existantes. Pour
ce faire, exécutez la commande à l’invite de commandes : rskeymgmt -r <InstallationID>
NOTE
Remplacez l’espace réservé à l’aide de l’ID d’installation fourni dans le paramètre InstallationID du
InstallationID RSReportServer.config fichier. Par défaut, le RSReportServer.config est stocké dans le
<InstallationDrive>:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer
folder
fichier .
4. Arrêter Internet Information Services (IIS).

5. Arrêtez le service Microsoft du serveur de rapports.
6. Modifiez le compte d’utilisateur utilisé pour exécuter le service Microsoft Report Server ou le service
Web Report Server sur le compte d’utilisateur que vous souhaitez.
7. Démarrez IIS.
8. Démarrez le service Microsoft Report Server.
9. Utilisez l’utilitaire de ligne de commande rskeymgmt pour appliquer les clés de chiffrement qui ont été
backed à l’étape 2. Pour ce faire, exécutez la commande suivante à l’invite de commandes :
rskeymgmt -a -f <FileName> -p <StrongPassword>
NOTE
Remplacez l’espace réservé et l’espace réservé par le nom de fichier et le mot de passe que vous avez utilisés pour
la protection des clés de chiffrement symétriques à <FileName> <StrongPassword> l’étape 1.
Vous ne pouvez pas commencer SQL Server
Reporting Services après avoir appliqué la mise à
jour abordée dans la 2677070
Cet article vous aide à résoudre une erreur de délai et un problème dans lequel les ID d’événement 7000, 7009
et 1530 sont enregistrés lorsque vous démarrez SQL Server Reporting Services (SSRS).
Symptômes
Supposons que vous appliquez la mise à jour décrite dans l’article de la Base de connaissances Microsoft
2677070 sur un ordinateur qui exécute SSRS. Lorsque vous essayez de démarrer SSRS, vous recevez une erreur
de délai d’délai, et l’ID d’événement 7000 et l’ID d’événement 7009 sont enregistrés dans le journal des
applications.
En outre, l’ID d’événement 1530 est journalisé et les informations qui ressemblent à ce qui suit sont consignées
dans le journal des applications :
NOTE
L’espace réservé < l'> événement représente l’heure à l’heure de l’événement. L’espace réservé < nom du serveur SSRS
> représente le nom du serveur SSRS.
Cause
Ce problème se produit en raison de l’impossibilité de récupérer des listes d’autorisation de certificat (CTL)
fiables et non fiables. Si le système n’a pas accès à Windows Update, soit parce que le système n’est pas
connecté à Internet, soit parce que Windows Update est bloqué par des règles de pare-feu, la récupération du
réseau arrive à son heure d’attente avant que le service puisse poursuivre sa procédure de démarrage. Dans
certains cas, ce délai d’attente de récupération réseau peut dépasser le délai d’attente de démarrage du service
de 30 secondes. Si un service ne peut pas signaler que le démarrage s’est terminé après 30 secondes, le
gestionnaire de contrôle de service (SCM) arrête le service.
Les URL pour mettre à jour la CTL ont été modifiées avec cette mise à jour. Par conséquent, si les URL
précédentes ont été codées en dur en tant qu’exceptions dans le pare-feu ou le proxy, ou s’il n’y a pas d’accès à
Internet sur l’ordinateur, la CTL ne peut pas être mise à jour.
Pour télécharger les CTL les plus récentes, utilisez les URL mises à jour suivantes :
disallowedcertstl.cab
authrootstl.cab
Pour contourner ce problème, configurez l’ordinateur afin que le réseau ne récupère pas les CTLs fiables et non
fiables. Pour ce faire, utilisez l’une des méthodes suivantes :
Méthode 1
Validez que les pare-feux de limite, les règles d’accès du routeur ou les serveurs proxy en aval autorisent
les systèmes qui ont des mises à jour 2677070 à contacter Microsoft Update. Pour plus d’informations
sur cette exigence, voir : un programme de mise à jour automatique des certificats révoqués est
disponible pourWindows Vista, Windows Server 2008, Windows 7 et Windows Server 2008 R2 (cela
inclut les URL accessibles par la mise à jour CTL).
Méthode 2
Modifier les paramètres de stratégie de groupe. Pour cela, procédez comme suit :
1. Sous le nœud Configuration de l’ordinateur dans l’Éditeur de stratégie de groupe local, double-
cliquez sur Stratégies.
2. Double-cliquez sur Windows Paramètres, double-cliquez sur Sécurité Paramètres, puis double-
cliquez sur Stratégies de clé publique.
3. Dans le volet d’informations, double-cliquez sur Validation du chemin d’accès du cer tificat
Paramètres .
4. Sélectionnez l’onglet Récupération réseau, cochez la case Définir ces paramètres de stratégie, puis
cochez la case Mettre à jour automatiquement les certificats dans la case à cocher Programme de
certificat racine Microsoft (recommandé).
5. Sélectionnez OK, puis fermez l’Éditeur de stratégie de groupe local.
Méthode 3
Modifiez le Registre. Pour cela, procédez comme suit.
IMPORTANT
problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, veillez à
suivre ces étapes scrupuleusement. Pour une meilleure protection, sauvegardez le registre avant de le modifier.
Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations sur la façon de la back up et de la
restauration du Registre, voir : Comment le restaurer dans Windows.
1. Sélectionnez Démarrer, sélectionnez Exécuter, tapez regedit dans la zone Ouvrir, puis cliquez
sur OK.
2. Recherchez puis sélectionnez la sous-clé de Registre suivante :
HKLM\Software\Policies\Microsoft\SystemCertificates .
3. Cliquez avec le bouton droit sur AuthRoot, sélectionnez Nouveau, puis cliquez sur DWORD.
4. Tapez DisableRootAutoUpdate, puis appuyez sur Entrée.
5. Cliquez avec le bouton droit sur DisableRootAutoUpdate, puis cliquez sur Modifier .
6. Dans la zone Données de la valeur, tapez 1, puis cliquez sur OK.
7. Dans le menu Fichier, cliquez sur Quitter.
Méthode 4
Augmentez le délai d’int rement du service par défaut.
IMPORTANT
problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, veillez à
suivre ces étapes scrupuleusement. Pour une meilleure protection, sauvegardez le registre avant de le modifier.
Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations sur la façon de la back up et de la
restauration du Registre, voir : Comment le restaurer dans Windows.
Pour augmenter le délai d’accès au service par défaut, suivez les étapes suivantes :
1. Cliquez sur Démarrer , puis Exécuter , entrez regedit dans la zone Ouvrir et cliquez sur OK .
2. Recherchez, puis sélectionnez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control .
3. Cliquez avec le bouton droit sur Contrôle, pointez sur Nouveau, puis cliquez sur DWORD .
4. Dans la zone Nouvelle valeur, tapez ServicesPipeTimeout, puis appuyez sur Entrée.
5. Cliquez avec le bouton droit sur Ser vicesPipeTimeout, puis cliquez sur Modifier.
6. Cliquez sur Décimal, tapez le nombre de millisecondes que vous souhaitez attendre jusqu’à
l’attente du service, puis cliquez sur OK. Par exemple, pour attendre 60 secondes avant l’heure
d’attente du service, tapez 60000.
7. Dans le menu Fichier, cliquez sur Quitter, puis redémarrez l’ordinateur.
Pour plus d’informations sur le programme de certificat racine Windows, les certificats, l’autorisation de
certificat et la liste d’autorisation de certificat, voir la section Plus d’informations de l’article de la Base de
connaissances Microsoft : An-automatic-updater-of-untrusted-certificates-is-available-for-window.
Des blocages de base de données se produisent
lorsque vous essayez d’afficher un rapport SSRS en
mode intégré SharePoint après la mise à jour d’une
source de données
Cet article fournit des solutions aux blocages qui se produisent lorsque vous essayez d’afficher un rapport SQL
Server Reporting Services (SSRS) en mode SharePoint intégré.
Symptômes
Vous configurez une instance de Microsoft SSRS pour utiliser le mode SharePoint’intégration.
Vous créez un rapport qui possède plusieurs sources de données.
Vous déployez le rapport sur un site SharePoint web.
Vous mettez à jour l’une des sources de données.
Vous essayez d’afficher le rapport à partir d’une page SharePoint personnalisée. Le rapport est incorporé
dans un contrôle IFrame de la page à l’aide de l’accès URL direct au point de terminaison du proxy SSRS
comme suit :
http://<Server Name >/< Site Name >/_vti_bin/ReportServer/<Report Name >.rdl?<Report URL
Parameters >
Dans ce scénario, vous pouvez être face à un ou plusieurs des symptômes suivants.
Symptôme 1
Les blocages de base de données se produisent sur l’une des procédures stockées suivantes dans la base
de données du serveur de rapports principal :
[dbo].[GetDataSources]
[dbo].[DeleteDataSources]
Symptôme 2
Vous recevez l’un des messages d’erreur suivants :
Message d'erreur 1
Une erreur s’est produite dans la base de données du serveur de rapports. Cela peut être dû à
une défaillance de connexion, un délai d’accès ou une condition de disque faible au sein de la
base de données. (rsReportServerDatabaseError)
Message d'erreur 2
Expiration du délai d’expiration. Le délai d’expiration s’est produit avant la fin de l’opération ou
le serveur ne répond pas.
Symptôme 3
Le chargement SharePoint pages de sites est très lent lorsque vous essayez d’accéder SharePoint contenu
du site.
Cause
Ce problème se produit car la source de données n’est pas synchronisée correctement après sa mise à jour.
Résolution
Méthode 1
Affichez le rapport directement à partir de la bibliothèque SharePoint documents une fois que vous avez
mis à jour la source de données du rapport. Cela permet de s’assurer que la source de données est
synchronisée correctement avant d’afficher le rapport via le point de terminaison du proxy SSRS.
Méthode 2
Utilisez un partie Web De la Visionneuse de rapports pour afficher le rapport.
Erreur (l’extension de données sélectionnée n’est pas
installée ou ne peut pas être chargée) lorsque vous
chargez des extensions personnalisées dans SQL
Server Outils de données <Custom Extension
Name> 2012
Cet article vous aide à résoudre le problème où vous recevez un message d’erreur lorsque vous essayez de
charger des extensions personnalisées dans des projets de serveur de rapports dans SQL Server 2012 Data
Tools.
S’applique à : SQL Server 2012 Enterprise, SQL Server 2012 Business Intelligence, SQL Server 2012 Developer,
SQL Server 2012 Standard, SQL Server 2012 Web
Symptômes
Vous développez une extension de traitement des données Reporting Services personnalisée.
L’assembly d’extension de traitement des données personnalisé fait référence à
Microsoft.ReportingServices.Interfaces.dll fichier. Le fichier est inclus dans Microsoft SQL Server 2005
Reporting Services, SQL Server 2008 Reporting Services ou SQL Server 2008 R2 Reporting Services.
Vous installez SQL Server Data Tools (SSDT) dans Microsoft SQL Server 2012.
Vous déployez l’assembly d’extension de traitement des données à l’aide de SSDT.
Vous créez un projet de serveur de rapports basé sur le modèle Business Intelligence et vous essayez de
sélectionner l’extension de traitement des données personnalisée afin d’ajouter une nouvelle source de
données.
Impossible de se connecter à la source de données ' <Data Source Name> '. L’extension de données
sélectionnée <Custom Extension Name> ' n’est pas installée ou ne peut pas être chargée. Vérifiez que
l’extension de données sélectionnée est installée sur le client pour les rapports locaux et sur le serveur de
rapports pour les rapports publiés.
NOTE
Le nom de la source de données est un espace réservé pour le nom de la source de données et le nom de
l’extension personnalisée est un espace réservé pour le nom de l’extension personnalisée.
Si vous chargez l’extension personnalisée dans un rapport SQL Server Reporting Services (SSRS), puis exécutez le
rapport via un service web SSRS ou une interface web, l’extension personnalisée s’exécute correctement.
Ce problème n’est pas limité aux extensions de traitement des données. Vous pouvez rencontrer des erreurs
similaires lorsqu’une extension personnalisée fait référence au fichier Microsoft.ReportingServices.Interfaces.dll
inclus dans SQL Server 2005 Reporting Services, SQL Server 2008 Reporting Services ou SQL Server 2008 R2
Reporting Services.
Cause
Le problème se produit en raison d’un bogue dans le processus d’installation de SSDT.
Lorsque SSDT est installé, les entrées incorrectes suivantes sont ajoutées au fichier devenv.exe.config et au
PreviewProcessingService.exe.config suivant :
<dependentAssembly>
<assemblyIdentity name="Microsoft.ReportingServices.Interfaces" publicKeyToken="89845dcd8080cc91"
culture="neutral"/>
<bindingRedirect oldVersion="9.0.242.0" newVersion="10.0.0.0"/>
</dependentAssembly>
Si une extension personnalisée fait référence au fichier Microsoft.ReportingServices.Interfaces.dll dont la version

d’assembly est 9.0.242.0, SSDT recherche le fichier Microsoft.ReportingServices.Interfaces.dll dont la version
d’assembly est 10.0.0.0. Toutefois, ce nouvel assembly n’existe peut-être pas sur l’ordinateur sur lequel SSDT est
installé.
Résolution
Pour résoudre ce problème, utilisez les entrées correctes dans devenv.exe.config fichier et dans
lePreviewProcessingService.exe.config fichier.
Pour corriger l’entrée dans devenv.exe.config fichier, suivez les étapes suivantes :
Ouvrez ledevenv.exe.config qui se trouve à l’emplacement :
%Program Files%\Microsoft Visual Studio 10.0\Common7\IDE .
NOTE
Le PreviewProcessingService.exe.config se trouve dans
%Program Files%\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies .
Dans le devenv.exe.config, recherchez l’entrée suivante :
<dependentAssembly>
culture="neutral"/>
<bindingRedirect oldVersion="9.0.242.0" newVersion="10.0.0.0"/>
Remplacez l’entrée par ce qui suit :

<dependentAssembly>
culture="neutral" />
culture="neutral" />
<bindingRedirect oldVersion="8.0.242.0" newVersion="11.0.0.0" />
Enregistrez devenv.exe.config fichier.

Fermez, puis rouvrez Visual Studio ou SSDT.
NOTE
Les étapes de correction de l’entrée dansPreviewProcessingService.exe.config fichier sont les mêmes.
Le workbook contient des lignes et des colonnes
masquées lorsque vous exportez des rapports de
SQL Server Reporting Services vers Excel
Cet article vous aide à contourner le problème où des lignes ou des colonnes masquées sont insérées dans un
workbook Excel lorsque vous exportez des rapports de SQL Server Reporting Services (SSRS) vers Excel.
Symptômes
Lorsque vous exportez un rapport Microsoft SSRS vers un Excel, il existe des lignes ou des colonnes masquées
dans le manuel. L’image suivante illustre ce problème :
Cause
Ce problème se produit parce que les hauteurs de ligne ou les largeurs de colonne sont arrondies.
Le langage RDL (Report Definition Language) vous permet d’utiliser plusieurs unités de mesure (par exemple, ,
et ) pour spécifier des valeurs de inches pixels position et de centimeters points taille. Toutefois, Excel
utilise uniquement points . Par conséquent, l’extension de rendu Excel SSRS convertit la hauteur et la largeur
du tableau, les hauteurs des lignes et les largeurs des colonnes en points . Ce processus peut inclure l’arrondi
de certaines valeurs. Dans ce cas, la hauteur ou la largeur du tableau et la somme des hauteurs de ligne ou des
largeurs de colonne sont différentes. Pour compenser la différence, l’extension de rendu Excel SSRS insère une
petite ligne ou colonne dans le workbook.
Pour contourner ce problème, spécifiez l’unité de mesure dans points .
NOTE
Vous pouvez convertir d’autres unités de mesure en points. Par exemple, vous pouvez convertir des pouces en points à
l’aide d’un rapport de 1 pouce à 72 points.
Message d’erreur au démarrage du service Serveur
de rapports ou lorsque vous essayez d’accéder au
site Web Reporting Services ou à la Power BI
Report Server : « Clé non valide pour une utilisation
dans l’état spécifié »
Cet article vous aide à résoudre le problème qui se produit lorsque vous réinitialisez le compte de service
Report Server.
Symptômes
Lorsque vous travaillez avec un ordinateur qui exécute Microsoft SQL Server, vous pouvez recevoir le message
d’erreur suivant dans le journal de suivi du service Report Server :
Une erreur interne s’est produite sur le serveur de rapports. Pour plus d’informations, voir le journal des
erreurs. (rsInternalError) Obtenir la clé d’aide en ligne non valide pour une utilisation dans l’état spécifié.
(Exception de HRESULT : 0x8009000B)
Vous pouvez recevoir ce message d’erreur lorsque l’une des actions suivantes se produit :
Le service Serveur de rapports démarre.
Vous essayez d’accéder au site Web Reporting Services.
En outre, vous pouvez recevoir le message d’erreur suivant dans le journal de suivi du service Report Server :
ERREUR : Exception capturée lors du démarrage du service.

Erreur : Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerDisabledException : le serveur de
rapports ne peut pas déchiffrer la clé symétrique utilisée pour accéder aux données sensibles ou chiffrées
dans une base de données du serveur de rapports. Vous devez restaurer une clé de sauvegarde ou
supprimer tout le contenu chiffré. Pour plus d’informations, consultez la documentation.
Cause
En règle générale, ce problème se produit lorsque le mot de passe du compte de service Report Server est
réinitialisé.
Résolution
Méthode 1 : restaurer la clé symétrique
NOTE
Pour utiliser cette méthode, vous devez avoir une copie de sauvegarde de la clé symétrique disponible.
Pour restaurer la clé symétrique, suivez les étapes suivantes :

1. Démarrez l’outil de configuration de Reporting Services, puis connectez-vous au serveur de rapports que
vous souhaitez configurer.
2. Dans la page Clés de chiffrement, cliquez sur Restaurer.
3. Cliquez sur le fichier .snk qui contient la copie de sauvegarde.
4. Tapez le mot de passe qui déverrouille le fichier.
5. Cliquez sur OK .
Méthode 2 : supprimer le contenu chiffré
IMPORTANT
Cette méthode supprime tout le contenu chiffré. Cela inclut les chaînes de connexion et les informations d’identification
stockées. Ensuite, cette méthode crée une clé symétrique. Utilisez cette méthode uniquement si vous ne pouvez pas
restaurer la clé symétrique.
Après avoir supprimé le contenu chiffré, vous devez reenter les chaînes de connexion manquantes et les
informations d’identification stockées manquantes dans les rapports et dans les sources de données partagées
qui n’ont plus ces valeurs. En outre, vous devez mettre à jour tous les abonnements qui utilisent des extensions
de remise qui stockent des données chiffrées. Cela inclut l’extension de remise du partage de fichiers et toute
extension de remise tierce qui utilise des valeurs chiffrées.
Il n’existe aucun moyen automatisé de mettre à jour ces informations. Vous devez mettre à jour chaque rapport,
chaque abonnement et chaque source de données partagée qui utilise les informations d’identification stockées
et les chaînes de connexion un par un.
Pour supprimer le contenu chiffré, suivez les étapes suivantes :
1. Démarrez l’outil de configuration de Reporting Services, puis connectez-vous au serveur de rapports que
vous souhaitez configurer.
2. Dans la page Clés de chiffrement, cliquez sur Supprimer le contenu chiffré.
Références
Pour plus d’informations sur le journal de suivi du service Report Server, voir Report Server Service Trace
Log.
Pour plus d’informations sur la restauration de la clé symétrique, voir Clés de chiffrement SSRS - Back Up
and Restore Encryption Keys.
Pour plus d’informations sur les clés de chiffrement, voir Encryption Keys (Reporting Services Configuration).
Le volet paramètre n’est pas visible dans le rapport
drillThrough SharePoint mode intégré dans SSRS
Cet article vous aide à contourner le problème dans lequel le volet paramètres d’un rapport enfant est
définitivement masqué.
Version du produit d’origine : SQL Server 2012 Business Intelligence, SQL Server 2012 Developer, SQL Server
2012 Enterprise, SQL Server 2012 Standard, SQL Server 2012 Web
Symptômes
Vous avez un serveur SSRS qui s’exécute en SharePoint mode intégré.
Un rapport parent (rapport principal) qui s’exécute sur le serveur ne possède que des paramètres masqués
ou n’a aucun paramètre.
Un rapport enfant (rapport de drillthrough) est en cours d’exécution sur le même serveur et ce rapport est
associé à un ou plusieurs paramètres.
Vous allez dans le rapport enfant à partir du rapport parent.
Dans ce scénario, le volet de paramètres de l’état enfant est définitivement masqué et vous ne pouvez pas
sélectionner ou modifier les valeurs de paramètre du rapport enfant.
Cause
Ce problème se produit en raison d’une limitation connue au sein du SSRS.
Pour contourner ce problème, créez un paramètre factice pour le rapport parent et assurez-vous que le
paramètre est paramétrable.
Rendu des problèmes de SQL Server Reporting
Services rapports dans Internet Explorer
Cet article répertorie différents problèmes dans lequel les rapports ne sont pas rendus comme prévu dans
Internet Explorer 8 et versions ultérieures en mode standard.
Version du produit d’origine : SQL Server 2012 Enterprise
Résumé
Vous pouvez rencontrer différents problèmes avec les rapports Microsoft SQL Server Reporting Services (SSRS)
dans lesquels les rapports ne sont pas rendus comme prévu dans Internet Explorer 8 et versions ultérieures en
mode standard (également appelé mode documents). Les problèmes sont les suivants :
Les rapports du tableau de bord Dynamics CRM et d’autres rapports ne sont pas correctement rendus. Plus
précisément, les rapports sont réduit et s’affichent dans une colonne étroite plutôt que dans la page entière
du navigateur.
L’alignement des rapports est oblique en mode SharePoint reporting Services et en mode natif.
Dans la mesure où SSRS prend entièrement en charge le mode « Quirks » d’Internet Explorer, les clients
Dynamics CRM ne peuvent pas effectuer de personnalisations. Les personnalisations sont uniquement pris
en charge en mode standard Internet Explorer.
Étant donné que SSRS prend entièrement en charge le mode quirks d’Internet Explorer, les clients qui
utilisent une application personnalisée pour s’intégrer à SSRS ne peuvent pas utiliser le mode standard
Internet Explorer par défaut.
Les options d’exportation disparaissent lorsqu’un rapport est rendu en mode standard Internet Explorer.
Les performances d’exploration diminuent considérablement en mode standard Internet Explorer.
Lorsque vous sélectionnez la propriété Rotate270 (qui spécifie le texte vertical du bas vers le haut) dans une
zone de texte, puis que vous affichez un état en mode intégré WritingMode SharePoint (SharePoint Server
2010 ou une version ultérieure), vous diminuez particulièrement la clarté du texte lorsque le rapport est
affiché dans le navigateur. Le texte est beaucoup moins clair en mode standard (il s’agit de la valeur
SharePoint par défaut) dans Internet Explorer 7 et versions ultérieures qu’en mode Quirks d’Internet Explorer
5.
Lorsque vous exécutez System Center Configuration Manager rapports sur les clients qui utilisent le
navigateur Internet Explorer 11, vous êtes figé. Ces rapports sont effectivement restituer conformément au
journal SSRS. Toutefois, le client voit le volant de rotation vert et l’état ne semble jamais s’restituer. Pour
corriger ce problème, il s’est possible de définir Internet Explorer 11 en mode « Quirks ».
Dans les versions d’Internet Explorer ultérieures à Internet Explorer 7, si nous zoomons sur le texte
Rotation270 dans un état, le texte s’déborde en dehors des limites de la zone de texte qui est destinée à le
contenir. Par conséquent, le texte devient partiellement ou complètement masqué.
NOTE
Les rapports SSRS ne prend en charge Internet Explorer qu’en mode quirks. Ce comportement est inhérent au produit.
Pour plus d’informations, voir : Planning for Reporting Services and Power View Browser Support
Conditions requises pour le navigateur pour le Gestionnaire de rapports

Pour exécuter le Gestionnaire de rapports et utiliser le Gestionnaire de rapports pour afficher les rapports,
Windows Internet Explorer 7 ou une version ultérieure est requis et l’écriture de scripts doit être activée. Le
Gestionnaire de rapports prend uniquement en charge le mode quirks et ne prend pas en charge le mode
standard. Si vous utilisez un navigateur en mode standard, vous pouvez être en situation de problèmes de taille
de fenêtre et de barres de défilement qui ne sont pas toujours visibles.
Notre équipe produit s’engage à prendre en charge les navigateurs à jour. Cela inclut le mode standard Internet
Explorer. Toutefois, étant donné que ce mode est la base du rendu des rapports, le correctif est assez complet et
ne peut pas être inclus dans une mise à jour cumulative ou un Service Pack pour Reporting Services. Nous
mettreons à jour cet article en cas de modification de la stratégie de prise en charge pour le mode standard.
Impossible de récupérer des fichiers d’application.
Erreur de déploiement des fichiers endommagés
lorsque vous essayez de démarrer la version
ClickOnce de Report Builder à partir de SQL Server
2012 Reporting Services
Cet article vous aide à résoudre l’impossibilité de récupérer des fichiers d’application. Fichiers
endommagés lors d’une erreur de déploiement qui se produit lorsque vous essayez de démarrer la version
ClickOnce de SQL Server Report Builder.
Symptômes
Lorsque vous essayez de démarrer la version ClickOnce de Microsoft SQL Server Report Builder pour Microsoft
SQL Server 2012 sur un ordinateur client, vous pouvez recevoir un message d’erreur semblable à ce qui suit :
Impossible de récupérer des fichiers d’application. Fichiers endommagés lors du déploiement.
En outre, lorsque vous cliquez sur Détails dans la boîte de dialogue du message d’erreur, vous voyez des
informations détaillées sur l’erreur qui ressemblent à ce qui suit :
ERREUR + L’exception s’est produite lors du chargement du manifeste à partir MSReportBuilder.exe fichier :
le manifeste peut ne pas être valide ou le fichier n’a pas pu être ouvert. + Impossible de charger le manifeste
interne à partir du fichier de composant. DÉTAILS DE L’ERREUR Les erreurs suivantes ont été détectées au
cours de cette opération. * [31/10/2012 9:25:34 AM]
System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Une exception s’est produite
lors du chargement du manifeste à partir du MSReportBuilder.exe de fichier : le manifeste peut ne pas être
valide ou le fichier n’a pas pu être ouvert. - Source : System.Deployment - Stack trace: at
System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception
exception, String filePath) at
System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at
System.Deployment.Application.DownloadManager.ProcessDownloadedFile(Object sender,
DownloadEventArgs e) at
System.Deployment.Application.FileDownloader.DownloadModifiedEventHandler.Invoke(Object sender,
DownloadEventArgs e) at
System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem next) at
System.Deployment.Application.SystemNetDownloader.DownloadAllFiles() at
System.Deployment.Application.FileDownloader.Download(SubscriptionState subState) at
System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState subState,
AssemblyManifest deployManifest, AssemblyManifest appManifest, Uri sourceUriBase, String
targetDirectory, String group, notification IDownloadNotification, Options DownloadOptions) sur
System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState subState,
ActivationDescription actDesc, Int64 transactionId, TempDirectory& downloadTemp) at
System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState& subState,
ActivationDescription actDesc) at
System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri,
Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings
browserSettings, String& errorPageUrl) at
System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state) --- Inner
Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal
manifest from component file.
Cause
Ce problème se produit car Microsoft .NET Framework 4 ou une version ultérieure du .NET Framework n’est pas
installé sur l’ordinateur client.
Résolution
Pour résoudre ce problème, installez le .NET Framework 4. Le fichier suivant est disponible en téléchargement à
partir du Centre de téléchargement Microsoft :
Téléchargez le package .NET Framework 4 maintenant.
Pour plus d’informations sur le téléchargement des fichiers de support Microsoft, voir : Comment obtenir des
fichiers de support Microsoft à partir des services en ligne
Revendication de l’analyse antivirus
Microsoft a analysé ce fichier à la recherche de virus, à l’aide du logiciel de détection de virus le plus actuel
disponible à la date à laquelle le fichier a été publié. Le fichier est stocké sur des serveurs à sécurité améliorée
qui permettent d’empêcher toute modification non autorisée.
Configuration requise pour le redémarrage
Vous devez redémarrer votre ordinateur après avoir installé ce package, puis redémarrer l Report Builder
ClickOnce application.
Pour plus d’informations sur .NET Framework, voir : .NET
Pour plus d’informations sur les conditions préalables pour SQL Server Report Builder, voir : Prerequisites for
Tutorials (Report Builder)
S’applique à
SQL Server Web 2012
Vous recevez un message d’avertissement lorsque
vous ajoutez un assembly Reporting Services en
tant que références à un projet d’élément de
rapport personnalisé dans SQL Server 2012
Reporting Services
Cet article vous aide à comprendre les messages d’avertissement qui se produisent lors de l’ajout d’une
référence à des assemblys de services de création de rapports lors du développement d’un projet de rapport
personnalisé à l’aide SQL Server Business Intelligence Development Studio.
Symptômes
Dans Microsoft SQL Server 2012 Reporting Services, vous développez un projet d’élément de rapport
personnalisé à l’aide SQL Server Business Intelligence Development Studio.
Vous définissez la .NET Framework cible du projet sur .NET Framework 3,5.
Vous ajoutez l’un des assemblys suivants en tant que références au projet d’élément de rapport personnalisé
:
Microsoft.ReportingServices.Interfaces.dll
Microsoft.ReportingServices.ProcessingCore.dll
Lorsque vous ajoutez l’assembly, vous recevez le message d’avertissement suivant :
« Microsoft.ReportingServices.ProcessingCore.dll » ou l’une de ses dépendances nécessite une version

ultérieure du .NET Framework que celle spécifiée dans le projet.
Vous pouvez modifier la cible .NET Framework en cliquant sur Propriétés dans le menu Project, puis en
sélectionnant une nouvelle cible dans la zone déroulante « .NET Framework ». (Dans Visual Basic, il se trouve
sous l’onglet Compiler en cliquant sur « Options avancées du compilateur... » bouton.)
Voulez-vous toujours ajouter une référence à « Microsoft.ReportingServices.ProcessingCore.dll » dans le
projet ?
Une fois que vous avez .NET Framework la .NET Framework 4.0, le projet peut être compilé avec succès.
Toutefois, le service SQL Server Reporting Services (SSRS) ne peut pas charger l’élément de rapport
personnalisé. L’élément de rapport personnalisé ne s’affiche dans aucun rapport SQL Server 2012 Reporting
Services.
Résolution
Pour résoudre ce problème, vous pouvez ignorer le message d’avertissement en toute sécurité. Le projet est
compilé et peut être déployé avec succès sur le serveur de rapports.
Choisir un modèle de licence pour SQL Server sur
Linux
Cet article explique comment choisir un modèle de licence pour SQL Server sur Linux.
Version du produit d’origine : SQL Server 2017 sur Linux (toutes éditions)
Résumé
Si vous installez Microsoft SQL Server sur Linux à l’aide de l’outil d’installation mssql-conf et si vous avez acheté
la licence appropriée via le Centre de gestion des licences en volume (VLSC), vous pouvez sélectionner l’une des
options PAYANTes appropriées parmi les éditions SQL Server suivantes :
Évaluation (gratuite, aucun droit d’utilisation de production, limite de 180 jours)
Développeur (gratuit, aucun droit d’utilisation de production)
Express (gratuit)
Web (PAYANT)
Standard (PAID)
Enterprise (PAID)
Enterprise Core (PAID)
« J’ai acheté une licence par le biais d’un canal de vente au détail et j’ai une clé de produit à entrer. »
Pour plus d’informations, consultez les sections suivantes de SQL Server sur Linux Forum Aux Questions (FAQ).
Comment fonctionne la gestion des licences sur Linux ?
SQL Server est sous licence de la même manière pour Windows linux. Vous sélectionnez la plateforme de votre
choix pendant le processus de gestion des licences. Pour plus d’informations, voir Comment obtenir une licence
SQL Server.
Quelle édition de SQL Ser ver dois-je choisir si je l’ai déjà achetée ?
Lorsque vous exécutez le programme d’installation mssql-conf, vous avez les options d’installation suivantes :
Choisissez une édition de SQL Server :
Évaluation (gratuite, aucun droit d’utilisation de production, limite de 180 jours)
Développeur (gratuit, aucun droit d’utilisation de production)
Express (gratuit)
Web (PAYANT)
Standard (PAID)
Enterprise (PAID)
Enterprise Core (PAID)
J’ai acheté une licence via un canal de vente au détail et j’ai une clé de produit à entrer.
Si vous avez obtenu votre licence par le biais de licences en volume dans le cadre d’un Accord Entreprise ou de
votre abonnement MSDN, vous devez choisir parmi les options 4 à 7. Si vous avez acheté une édition Standard
via un canal de vente au détail, vous devez sélectionner l’option 8.
SQL Server se termine et génère un vidage
principal sur RHEL 7.4 lorsque vous essayez
d’exécuter mssql-conf
Cet article vous aide à résoudre le problème où SQL Server se termine et génère un vidage principal sur RHEL
7.4 lorsque vous essayez d’exécuter mssql-conf après l’installation.
Symptômes
Après avoir installé Microsoft SQL Server sur RHEL 7.4, le programme s’termine et génère un vidage principal
lorsque vous essayez d’exécuter l’outil mssql-conf. En outre, l’entrée suivante est consignée dans les journaux
systemctl du service mssql-server ( journalctl -u mssql-server.service) :
Ce programme a rencontré une erreur fatale et ne peut pas poursuivre son exécution.
Les informations de diagnostic suivantes sont disponibles :
Raison : 0x00000003
Message : résultat
Stacktrace : 00005577212bcd92 0000557721266767
Processus : 590 - sqlservr
Thread : 594 (thread d’application 0x1000)
ID d’instance : afe0f97b-fdbc-4a4d-910c-038e7ee2049b
ID d’incident : 544c4c67-0f49-4877-a959-92c14798d58e
Cachet de build : f7473acad6f0299cd161863aaa02e4284434ab6d915c7b467e2a14e907290249
Capture du vidage principal et des informations...
Cause
Ce problème se produit car SQL Server sur Linux est incompatible avec les dispositions VA héritées. En raison
des paramètres activés sur RHEL 7.4, tous les processus commencent par using legacy_va_layout .
Au démarrage, SQL Server sur Linux vérifier les plages d’adresses. Lorsqu’elle trouve une incompatibilité en
raison d’une disposition VA héritée, elle génère une affirmation, met fin au programme et génère un vidage
principal.
RHEL 7.4 peut basculer vers une disposition VA héritée pour l’une des raisons suivantes :
La valeur de limite de pile souple est définie sur Unlimited (par exemple, un script limits.conf modifié ou un
paramètre ulimit -s).
Une disposition va héritée globale est activée (par exemple, sysctl vm.legacy_va_layout ou
modify/etc/sysctl.conf ).
Résolution
1. Dans la /etc/security/limits.conf disposition, ajoutez une nouvelle ligne, puis entrez le code :
mssql soft stack 8192

root soft stack 8192
2. Dans la /etc/sysctl.conf disposition, ajoutez une nouvelle ligne, puis entrez le code :
vm.legacy_va_layout = 0 .
3. Redémarrez l’ordinateur reboot :.
4. Assurez-vous que le paramètre de pile souple pour les utilisateurs, racine et mssql , est 8192 . Basculez
vers le contexte de l’utilisateur, puis exécutez la commande suivante ulimit -s :
5. Assurez-vous que la disposition va héritée globale est 0 : Sysctl vm.legacy_va_layout .
Vérification de la limite de taille de pile

Vérification de la taille limite de la pile et du paramètre legacy_va_layout (valeurs par défaut, provenant
d’une nouvelle installation RHEL-7).
[root@localhost ~]# sysctl vm.legacy_va_layout

vm.legacy_va_layout = 0
[root@localhost ~]# ulimit -s
8192
Lorsque ces paramètres sont effectués dans un système x64, la disposition de l’espace d’adressare ressemble à
ce qui suit :
+----------------------+ TASK_SIZE ((1UL << 47) - PAGE_SIZE)

| Stack |
+----------------------+
+----------------------+ MMAP_BASE (STACK_SIZE + RND_OFFSET)
| MMAP() |
|vvvvvvvvvvvvvvvvvv|
||
||
||
||
||
||
||
||
||
||
||
|^^^^^^^^^^^^^^|
| Tas |
+----------------------+
| SEGMENTS DE SEGMENTS |
+----------------------+
+----------------------+ 0
MMAP_BASE se trouve près de la partie supérieure de l’espace d’adressan. À mesure que les mappages sont
ajoutés, l’allocation d’espace d’adressare augmente. Il s’agit de la configuration par défaut pour RHEL, et c’est ce
que SQL Server s’attend à rencontrer au démarrage.
Exécution d’un programme simple

Exécution d’un programme simple qui mappe une page et renvoie l’adresse renvoyée par le noyau (exemple) :
mmap code
=========
#include <stdio.h>
#include <sys/mman.h>
int main()
{
void* result = mmap(NULL, 0x1000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
printf("mmap %p\n", result);
return 0;
}
[root@localhost ~]# ./mmap

mmap 0x7fb6976d6000
Toutefois, si l’un des paramètres ou les deux sont modifiés, la disposition va peut revenir à sa disposition héritée
:
+----------------------+ TASK_SIZE ((1UL << 47) - PAGE_SIZE)

| Stack |
|vvvvvvvvv^vvvvvvvv|
||
||
||
||
||
||
||
||
||
|^^^^^^^^^^^^^^|
| MMAP() |
+----------------------+ TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 3))
||
||
||
|^^^^^^^^^^^^^^|
| Tas |
+----------------------+
| SEGMENTS DE SEGMENTS |
+----------------------+
+----------------------+ 0
Ici, MMAP_BASE il est placé à un tiers de l’espace d’adressan. À mesure que les mappages sont ajoutés, l’allocation
d’espace d’adressace augmente (augmente).
Étant donné que nous avons un espace d’adressare virtuel 47 bits, dans Linux 64 bits, il est placé autour de la
0x2A0000000000 MMAP_BASE virtuelle de 42 0x2A0000000000. Par conséquent, mssql se déchaille sur les
adresses qui sont déjà mappées en dessous de 64 To lorsqu’elle tente de définir ses cartes fixes.
Ajustement de la taille de la pile, pour augmenter illimitée - illimité

[ root@localhost ~]# ulimit -s unlimited
[ root@localhost ~]# ./mmap
mmap 0x2b6634464000
Ajustement des vm.legacy_va_layout

[ root@localhost ~]# ulimit -s 8192
[ root@localhost ~]# sysctl -w vm.legacy_va_layout=1
vm.legacy_va_layout = 1
[ root@localhost ~]# ./mmap
mmap 0x2b46f28f9000
Vous pouvez obtenir le même effet que la définition en ajustant la taille de vm.legacy_va_layout la pile pour
qu’elle augmente de manière illimitée. La différence est qu’après la configuration d’un administrateur, le système
utilise globalement cette disposition VA héritée vm.legacy_va_layout=1 pour tous les processus. (La seule façon
de remplacer cette situation est de réinitialiser ce sysctl à 0 .) Toutefois, si vous l’avez fait, vous pouvez ajuster
cette caractéristique en ajustant la limite de taille de pile par session de connexion en émettant ulimit (ou en
personnalisant vm.legacy_va_layout=0 (default) limits.conf).
SQL restauration de base de données échoue sur
les serveurs Linux
Cet article vous aide à contourner le problème d’échec d’une opération de restauration SQL base de données
sur des serveurs Linux.
S’applique à : SQL Server 2017 sur Linux, SQL Server 2017 Developer Linux, SQL Server 2017 Enterprise Core
Linux, SQL Server 2017 Enterprise Linux, SQL Server 2017 Standard Linux
Symptômes
Lorsque vous essayez de restaurer une base de données SQL sur un serveur Linux Microsoft SQL Server 2017,
l’opération échoue pendant le processus de restauration et renvoie un message d’erreur semblable à ce qui suit :
MODIFY FILE a rencontré l’erreur du système d’exploitation 31(Un appareil connecté au système ne
fonctionne pas.) lors de la tentative de développement du fichier physique
Cause
Ce problème peut se produire parce que le disque dur est à court d’espace. Sur les serveurs Linux, SQL Server
ne vérifie pas l’espace disponible avant le démarrage de l’opération.
Pour contourner ce problème, restituer la base de données sur un volume qui dispose de suffisamment
d’espace.
Références
Découvrez la description de la terminologie standard utilisée pour décrire les mises à jour logicielles Microsoft
que Microsoft utilise pour décrire les mises à jour logicielles.
Vous ne pouvez pas faire basculer le volet de
résultats dans SQL Server Management Studio
Cet article vous aide à résoudre le problème dans lequel vous ne pouvez pas faire basculer le volet de résultats
SQL Server Management Studio dans SQL Server.
Symptômes
Lorsque vous utilisez SQL Server Management Studio (SSMS) dans SQL Server 2012 ou versions ultérieures, la
possibilité de faire basculer le volet de résultats peut être manquante. Par conséquent, vous ne verrez pas le
raccourci Masquer le volet De résultats ou Afficher les résultats dans le menu Fenêtre. En outre, lorsque vous
appuyez sur Ctrl+R, la visibilité du volet de résultats ne bascule pas.
NOTE
Lorsque vous appuyez sur Ctrl+R, vous recevez le message suivant dans la barre d’état :
(Ctrl+R) a été pressé. En attente de la deuxième clé de l’int re...
Cause
Ce problème se produit parce que .vssettings le fichier de SSMS est endommagé.
NOTE
Par défaut, ce fichier est nommé NewSettings.vssettings et se trouve dans le dossier suivant :
%USERPROFILE%\Documents\SQL Server Management Studio\Settings\SQL Server Management Studio
Remarque : pour SSMS versions 18.x, le fichier se trouve .vssetting dans le dossier suivant :
%LOCALAPPDATA%\Microsoft\SQL Server Management Studio\18.0_IsoShell\Settings\SQL Server Management Studio
Pour contourner ce problème, réinitialisez le schéma de mappage de clavier par défaut. Pour cela, procédez
comme suit :
1. Ouvrez SQL Server Management Studio.
2. Dans la barre de menus, cliquez sur Outils, puis sur Options.
3. Dans le volet arborescence sur le côté gauche de la boîte de dialogue, cliquez sur Clavier .
4. Cliquez sur Réinitialiser pour réinitialiser le schéma de mappage de clavier par défaut.
5. Dans la boîte de dialogue qui s’affiche, cliquez sur Oui.
6. Cliquez sur OK .
SQL Server 2016 l’agent ne parvient pas à démarrer
ou l’erreur « Échec de récupération des données »
lorsque vous essayez de lire le journal des erreurs
depuis SSMS 2016
Cet article répertorie les différents problèmes qui se produisent dans SSMS lors de l’utilisation d’une version
antérieure du pilote ODBC 13 MS et la résolution de ces problèmes.
Version du produit d’origine : SQL Server Développeur 2016
Symptômes
Lorsque vous avez une instance nommée Microsoft SQL Server 2016 RTM ou SQL Server 2016 RTM CU1, vous
pouvez être face à l’un des symptômes suivants.
Symptôme 1
Le fichier journal SQL Server Agent de sécurité affiche un message semblable à ce qui suit :
2016-08-06 14:54:41 - ! [000] Impossible de se connecter au serveur « servername\instancename » ;

SQLServerAgent ne peut pas démarrer
2016-08-06 14:54:46 - ! [298] Erreur SQLServer :
65535, SQL Server network interfaces: Error Locating Server/Instance Specified
[xFFFFFFFF]. [SQLSTATE 08001]
2016-08-06 14:54:46 - ! [165] Erreur ODBC : 0,
Délai d’expiration de connexion expiré [SQLSTATE HYT00]
2016-08-06 14:54:46 - ! [298]
Erreur SQLServer : 65535, une erreur liée au réseau ou à l’instance s’est produite lors de l’établissement
d’une connexion SQL Server.
Le serveur n’est pas trouvé ou n’est pas accessible.
Vérifiez si le nom de l’instance est correct et si SQL Server est configuré pour autoriser les connexions à
distance. Pour plus d’informations, voir SQL Server Books Online. [SQLSTATE 08001]
Symptôme 2
Lorsque vous essayez de lire le journal d SQL Server des erreurs, la tentative échoue et une erreur semblable à
ce qui suit est renvoyée :
Échec de la récupération des données pour cette demande. (Microsoft.SqlServer.Management.Sdk.Sfc)

En outre, lorsque vous essayez d’exécuter xp_readerrorlog, cela peut déclencher les erreurs suivantes :

Échec de l’ouverture de la connexion en boucle. Pour plus d’informations, voir le journal des événements.
Emplacement du journal des erreurs in trouvé.
Symptôme 3
Certains plans de maintenance ou SQL de l’agent de maintenance, tels qu’une tâche de nettoyage de
maintenance pour supprimer les anciens fichiers de sauvegarde ou signaler « silencieusement » l’échec. Dans le
cas de la tâche de nettoyage, les fichiers que vous prévoyez de supprimer ne sont pas supprimés lorsque le
travail correspondant est exécuté et aucune erreur n’est écrite dans le journal SQL Server. L’exécution
sp_readerrorlog entraînerait le symptôme 2.
Cause
Ce problème est dû à un défaut du pilote ODBC 13 MS. SQL Server Management Studio (SSMS) et l’agent SQL
Server utilisent ce pilote pour se connecter à SQL Server ordinateur.
Résolution
This issue is fixed in the MS ODBC 13.1 driver.
Message d’erreur lorsque vous cliquez sur le nœud
Bases de données SQL Server Management Studio
dans SQL Server
Cet article décrit un message d’erreur qui se produit généralement dans SSMS lorsqu’un problème survient lors
de la récupération d’informations sur une ou plusieurs bases de données d’une instance SQL Server données.
Symptômes
Vous pouvez recevoir un message d’erreur semblable au suivant lors de l’utilisation SQL Server Management
Studio (SSMS)
Échec de la récupération des données pour cette demande (Microsoft.SqlServer.Management.sdk.sfc)

Plusieurs causes peuvent contribuer à ce problème. Les éléments suivants peuvent vous aider à comprendre et
résoudre le problème :
Vérifiez si vous êtes en cours d’exécution dans les problèmes connus répertoriés ci-dessous et utilisez les
résolutions documentées dans les articles correspondants :
SQL Server agent 2016 ne parvient pas à démarrer ou à l’erreur « Échec de récupération des
données » lorsque vous essayez de lire le journal des erreurs depuis SSMS 2016
KB4550657 - CORRECTIF : une erreur se produit lorsque vous interagissez avec un agent SQL
Server dans SQL Server 2019
Vous pouvez exécuter ce problème si vous utilisez une version antérieure de SSMS et lorsque l’une des
conditions suivantes est vraie :
SQL Server Management Studio ne peut pas lire correctement une ou plusieurs bases de données.
Par conséquent, certaines propriétés d’une base de données ne peuvent pas être récupérées.
Une ou plusieurs bases de données sont en mode hors connexion et vous utilisez une version
antérieure de SSMS pour vous connecter à cette instance SQL hébergeant cette base de données
hors connexion.
Dans ces situations, la collection d’objets **** n’apparaît pas dans le volet Explorateur d’objets ou dans le
volet Détails de l’Explorateur d’objets. Par conséquent, certaines propriétés de la base de données ne
sont pas calculées en tant que groupe dans la collection d’objets.
NOTE
Ce problème se produit également si vous n’êtes pas membre du groupe Sysadmins.
Pour contourner ce problème, utilisez l’ancienne version SSMS les étapes suivantes :
1. Fermez le message d’erreur.
2. Appuyez sur F7 pour ouvrir le volet Détails de l’Explorateur d’objets.
3. Cliquez avec le bouton droit sur les en-têtes de colonne et assurez-vous que seules les colonnes
suivantes sont sélectionnées :
Nom
Date de création
État de la stratégie
Propriétaire
4. Cliquez avec le bouton droit sur le nœud Bases de données, puis cliquez sur Actualiser.
Vous pouvez également télécharger et installer SSMS à partir de Download SQL Server Management
Studio (SSMS) et voir si le problème disparaît. Si le problème se produit toujours avec la nouvelle version
de SSMS, consultez SQL Server’aide et vos commentaires pour obtenir de l’aide supplémentaire sur votre
problème.
Vous vous connectez à SQL Server 2008 R2 ou à une version antérieure de SQL Server et lorsque
l’utilisateur invité est désactivé dans la base de données msdb. Pour plus d’informations, vous ne devez
pas désactiver l’utilisateur invité dans la base de données msdb dans SQL Server
L’Explorateur d’objets se bloque par intermittence
lorsque vous utilisez SSMS 2012 ou une ultérieure
Cet article vous aide à résoudre le problème où l’Explorateur d’objets se bloque par intermittence lorsque vous
utilisez SQL Server Management Studio (SSMS) 2012 ou une version ultérieure.
Version du produit d’origine : Microsoft SQL Server Management Studio
Symptômes
L’Explorateur d’objets se bloque par intermittence lorsque vous utilisez SSMS. Ce problème s’applique à toutes
les versions SSMS 2012.
Ce problème peut se produire chaque fois que l’Explorateur d’objets est en focus (par exemple, lorsque vous
cliquez sur un élément dans l’arborescence). Toutefois, ce problème se produit uniquement si toutes les
conditions suivantes sont vraies :
SQL Server’authentification est utilisée.
La base de données par défaut de la connexion utilisée pour la connexion n’est pas la base de données
principale.
La SSMS est 2012 ou une version ultérieure.
L’Explorateur d’objets est connecté au moteur de base de données.
NOTE
Les fenêtres de requête ne font pas l’expérience de ce problème.
Cause
Ce problème est dû à un type de condition de course qui se produit entre des threads utilisés par l’Explorateur
d’objets.
Résolution
Pour éviter ce problème, utilisez l’une des méthodes suivantes :
Méthode 1 : utiliser l’authentification Windows utilisateur.
Méthode 2 : modifiez le paramètre de base de données par défaut en base de données maître pour la
connexion.
Méthode 3 : modifier la chaîne SSMS connexion pour demander une connexion à la base de données maître.
For, méthode 2
Pour modifier la base de données par défaut pour la connexion, exécutez les commandes suivantes à l’aide
d’une connexion qui dispose de l’autorisation ALTER ANY LOGIN :
USE [master]
GO
ALTER LOGIN [YourLogin] WITH DEFAULT_DATABASE=[master]
GO
For, méthode 3
Pour modifier la chaîne SSMS connexion, suivez les étapes suivantes :
1. Dans l’Explorateur d’objets, cliquez Connecter, puis cliquez sur Moteur de base de données .
2. Dans la fenêtre Connecter ser veur, cliquez sur le bouton Options.
3. Sous l’onglet Propriétés de connexion, entrez maître dans le Connecter de base de données, puis
cliquez sur Connecter .
Exception lorsque vous exécutez une requête dans
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez SQL Server Management
Studio (SSMS) pour exécuter une requête SQL qui renvoie une grande quantité de données.
Version du produit d’origine : SQL Server 2012, SQL Server 2008, SQL Server 2005
Symptômes
Lorsque vous utilisez SSMS pour exécuter une requête SQL qui renvoie une grande quantité de données, vous
recevez un message d’erreur qui ressemble à ce qui suit :
Une erreur s’est produite lors de l’exécution du lot. Message d’erreur : exception de type «
System.OutOfMemoryException » a été lancée
Cause
Ce problème se produit car SSMS mémoire est insuffisante pour allouer des résultats importants.
NOTE
SSMS est un processus 32 bits. Par conséquent, elle est limitée à 2 Go de mémoire. SSMS impose une limite artificielle sur
la quantité de texte qui peut être affichée par champ de base de données dans la fenêtre de résultats. Cette limite est de
64 Ko en mode « Grille » et de 8 Ko en mode texte. Si le jeu de résultats est trop grand, la mémoire requise pour afficher
les résultats de la requête peut dépasser la limite de 2 Go du processus SSMS de requête. Par conséquent, un jeu de
résultats important peut provoquer l’erreur mentionnée dans la section Symptômes.
Pour contourner ce problème, essayez l’une des méthodes suivantes.
Méthode 1 : sortie des résultats sous la mesure du texte

Configurez la fenêtre de requête pour qu’elle envoie les résultats de la requête en tant que texte. Une sortie de
texte utilise moins de mémoire que la grille et peut être suffisante pour afficher les résultats de la requête. Pour
effectuer cette modification, suivez les étapes suivantes :
1. Cliquez avec le bouton droit sur la fenêtre de requête.
2. Cliquez sur Résultats sur .
3. Cliquez sur Résultats dans le texte.
Méthode 2 : Sortie des résultats dans un fichier

Configurez la fenêtre de requête pour obtenir les résultats de la requête dans un fichier. Une sortie de fichier
utilise une quantité minimale de mémoire. Cela réserve davantage de mémoire pour le stockage du jeu de
résultats. Pour effectuer cette modification, suivez les étapes suivantes :
1. Cliquez avec le bouton droit sur la fenêtre de requête.
2. Cliquez sur Résultats sur .
3. Cliquez sur Résultats pour fichierr.
4. Exécutez la requête, puis sélectionnez l’emplacement dans lequel enregistrer le fichier de résultats.
Méthode 3 : utiliser sqlcmd

Utilisez l’utilitaire sqlcmd au lieu de SSMS pour exécuter SQL requêtes. Cette méthode permet d’exécuter des
requêtes sans les ressources requises par SSMS’interface utilisateur. En outre, vous pouvez utiliser la version 64
bits de Sqlcmd.exe pour éviter la restriction de mémoire qui affecte le processus de SSMS 32 bits.
S’applique à
SQL Server Web 2012
SQL Server Web 2008
L’enregistrement des modifications n’est pas autorisé
dans SSMS
Cet article vous aide à contourner le problème dans lequel vous recevez un message d’erreur lorsque vous
essayez d’enregistrer une table dans SQL Server Management Studio (SSMS).
Symptômes
Lorsque vous essayez d’enregistrer une table après avoir apporté des modifications à la table à l’aide de
Designer dans SQL Server management Studio, vous pouvez recevoir le message d’erreur suivant :
L’enregistrement des modifications n’est pas autorisé. Les modifications que vous avez apportées
nécessitent l’abandon et la re-création des tableaux suivants. Vous avez apporté des modifications à une
table qui ne peut pas être re-créée ou activé l’option Empêcher l’enregistrement des modifications qui
nécessitent la re-création de la table.
Ce problème se produit lorsque vous a apporté une ou plusieurs des modifications suivantes au tableau :
Vous modifiez le paramètre Autoriser les valeurs Null pour une colonne.
Vous réordez les colonnes du tableau.
Vous modifiez le type de données de colonne.
Vous ajoutez une nouvelle colonne.
Vous modifiez filegroup la table ou ses text/image données.
Cause
Ce problème se produit car l’option Empêcher l’enregistrement des modifications qui nécessitent l’option de re-
création de table est activée par défaut dans SQL Server Management Studio.
Lorsque vous modifiez une table de sorte que vous modifiez la structure des métadonnées de la table, puis que
vous enregistrez la table, la table doit être re-créée en fonction de ces modifications. Cela peut entraîner la perte
de métadonnées et une perte directe de données lors de la re-création de la table. Si vous activez l’option
Empêcher l’enregistrement des modifications qui nécessitent l’option de re-création de tableau dans la section
Concepteur de la fenêtre Options de SQL Ser ver Management Studio (SSMS), vous recevez le message
d’erreur mentionné dans la section Symptômes.
Pour contourner ce problème, utilisez des instructions Transact-SQL pour apporter les modifications à la
structure des métadonnées ALTER TABLE d’une table.
Par exemple, pour modifier la colonne MyDate de type datetime dans la table appelée MyTable afin d’accepter
des valeurs NULL, vous pouvez utiliser :
alter table MyTable alter column MyDate7 datetime NULL
IMPORTANT
Nous vous recommandons vivement de ne pas contourner ce problème en 2013 en 2013, en 2013, en 2013. Pour plus
d’informations sur les risques de cette option, consultez la section « Plus d’informations ».
Pour modifier l’option Empêcher l’enregistrement des modifications qui nécessitent l’option de re-
création de tableau, suivez les étapes suivantes :
1. Ouvrez SQL Server Management Studio.
2. Dans le menu Outils , cliquez sur Options .
3. Dans le volet de navigation de la fenêtre Options, cliquez sur Concepteurs.
4. Sélectionnez ou clear the Prevent saving changes that require the table re-creation check box,
and then click OK .
NOTE
Si vous désactivez cette option, vous n’êtes pas averti lorsque vous enregistrez la table que les modifications que vous
avez apportées ont modifié la structure des métadonnées de la table. Dans ce cas, une perte de données peut se produire
lorsque vous enregistrez la table.
Risque de la mise hors option « Empêcher l’enregistrement des modifications qui nécessitent une nouvelle
création de tableau »
Bien que la non-création de cette option vous évite de créer une table, elle peut également entraîner la perte de
modifications. Par exemple, supposons que vous activez la fonctionnalité Suivi des modifications dans SQL
Server pour suivre les modifications apportées au tableau. Lorsque vous effectuez une opération qui entraîne la
re-création de la table, vous recevez le message d’erreur mentionné dans la section Symptômes. Toutefois, si
vous dés désactiver cette option, les informations de suivi des changements existantes sont supprimées lors de
la re-création de la table. Par conséquent, nous vous recommandons de ne pas contourner ce problème en 2013
en 2013.
Pour déterminer si la fonctionnalité Suivi des changements est activée pour un tableau, suivez les étapes
suivantes :
1. Dans SQL Server Management Studio, recherchez le tableau dans l’Explorateur d’objets.
2. Cliquez avec le bouton droit sur le tableau, puis cliquez sur Propriétés.
3. Dans la boîte de dialogue Propriétés du tableau, cliquez sur Suivi des changements. Si la valeur de l’élément
Suivi des changements est True, cette option est activée pour la table. Si la valeur est False, cette option est
désactivée.
Lorsque la fonctionnalité est activée, utilisez Change Tracking les instructions Transact-SQL pour modifier la
structure des métadonnées de la table.
1. Dans SQL Server Management Studio, créez une table qui contient une clé primaire dans l’outil Concepteur
de tableau.
2. Cliquez avec le bouton droit sur la base de données qui contient cette table, puis cliquez sur Propriétés.
3. Dans la boîte de dialogue Propriétés de la base de données, cliquez sur Suivi des changements.
4. Définissez la valeur de l’élément Suivi des changements sur True, puis cliquez sur OK.
5. Cliquez avec le bouton droit sur le tableau, puis cliquez sur Propriétés.
6. Dans la boîte de dialogue Propriétés du tableau, cliquez sur Suivi des changements.
7. Définissez la valeur de l’élément Suivi des changements sur True, puis cliquez sur OK.
8. Dans le menu Outils , cliquez sur Options .
9. Dans la boîte de dialogue Options, cliquez sur Concepteurs.
10. Cliquez pour cocher la case Empêcher l’enregistrement des modifications qui nécessitent la re-création
d’une table, puis cliquez sur OK.
11. Dans l’outil Concepteur de tableau, modifiez le paramètre Autoriser les valeurs Null sur une colonne
existante.
12. Essayez d’enregistrer la modification dans le tableau.
Erreur lorsque vous essayez de modifier un tableau
de grande taille à l’aide de SQL Server
Management Studio
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez de modifier une grande table à
l’aide du concepteur de tableaux SQL Server Management Studio.
Symptômes
Lorsque vous essayez de modifier un tableau de grande taille à l’aide du concepteur de table dans Microsoft
SQL Server Management Studio, vous pouvez recevoir un message d’erreur semblable au suivant :
Impossible de modifier la table.

Expiration du délai d’expiration. Le délai d’expiration s’est produit avant la fin de l’opération ou le serveur ne
répond pas.
Cause
Ce comportement se produit en raison du délai d’délai de transaction pour le concepteur de table et pour le
concepteur de base de données dans SQL Server Management Studio. Vous pouvez spécifier ce paramètre dans
le délai d’issue de la transaction. Par défaut, ce paramètre est de 30 secondes.
NOTE
Ce paramètre diffère du paramètre dans le délai d’SQL Server Management Studio. Par défaut, le paramètre dans le délai
d’exécution de l’Éditeur de requêtes SQL Server Management Studio est zéro . Par défaut, le paramètre dans la zone Délai
d’absence de requête (secondes) de l’Éditeur de requêtes dans SQL Server 2000 SQL Query Analyzer est également
zéro . Par conséquent, l’Éditeur de requêtes attend indéfiniment que la requête se termine et ne s’achève jamais.
Résolution
Pour résoudre ce problème, utilisez l’une des méthodes suivantes :
Cliquez pour effacer la case à cocher Remplacer le délai d’délai de chaîne de connexion pour les mises à
jour du concepteur de table pour le concepteur de table et pour le concepteur de base de données dans
SQL Server Management Studio.
Spécifiez un paramètre élevé dans le délai d’issue de transaction pour le concepteur de table et pour le
concepteur de base de données dans SQL Server Management Studio.
Modifiez la grande table à l’aide des instructions Transact-SQL dans l’Éditeur de requêtes dans SQL
Server Management Studio.
Pour plus d’informations sur ces paramètres, voir Options (Designers - Table and Database Designers Page).
Statut
La modification d’un tableau de grande taille peut prendre beaucoup de temps. Cela est dû au SQL Server
effectuer les actions suivantes lorsque vous essayez de modifier le schéma de la table :
1. Créez une table temporaire avec le même schéma de table.
2. Copiez toutes les données de la table réelle vers la table temporaire.
3. Déposez le tableau réel.
4. Renommons la table temporaire en nom de table réelle.
Désinstaller SQL Server Management Studio
Cet article explique comment désinstaller les Microsoft SQL Server Management Studio incluses dans SQL
Server 2014 et les versions antérieures du produit.
Introduction
Cet article pas à pas décrit comment désinstaller le SQL Server Management Studio inclus dans SQL Server
2014 et les versions antérieures du produit. Vous de devez peut-être désinstaller ces outils si vous recevez le
Le programme d’installation a détecté une version SQL Server Management Studio sur cet ordinateur. SQL
Server Management Studio et SQL Server Management Studio Express ne peuvent pas être installés sur le
même ordinateur. Pour installer SQL Server Management Studio Express, vous devez d’abord désinstaller
SQL Server Management Studio, puis réexécuter SQL Server Management Studio configuration d’Express
Edition. Pour plus d’informations, voir l’article 909953 la Base de connaissances Microsoft.
NOTE
À partir SQL Server 2016, SQL Server management studio est proposé en tant que téléchargement distinct et peut donc
être installé en tant qu’application autonome. En tant que tel, vous pouvez utiliser n’importe quel processus documenté
dans Désinstallerou supprimer des applications et des programmes dans Windows 10 . Les étapes ci-dessous s’appliquent
uniquement à SQL Server 2014 et aux versions antérieures, où SSMS a peut-être été installé en tant que fonctionnalité
partagée lors de l’installation.
Windows 10 / 2016 +
Pour désinstaller SQL Server Management Studio de Windows 10, Windows Server 2016, Windows Server
2019 et les autres, suivez les étapes suivantes :
1. Pour commencer le processus de suppression, accédez à Paramètres à partir du menu Démarrer, puis
choisissez Applications.
2. Recherchez sql dans la zone de recherche.
3. SQL Server (Version) (Bit). Par exemple, SQL Server 2012 (64 bits).
4. SélectionnezDésinstaller/Modifier.
5. SélectionnezSupprimer dans la fenêtre SQL Server boîte de dialogue pour lancer l’Assistant SQL
Server’installation.
6. Dans**** la page Sélectionner une instance, utilisez la zone de drop-down pour spécifier une instance de
SQL Server à supprimer, ou spécifiez l’option permettant de supprimer uniquement les fonctionnalités
partagées SQL Server et les outils de gestion. Pour continuer, sélectionnezSuivant.
7. Dans la pageSélectionner des fonctionnalités, spécifiez les fonctionnalités à supprimer pour
sélectionner Outils de gestion – De base à partir de l’instance spécifiée de SQL Server.
8. Dans la pagePrêt à supprimer, examinez la liste des composants et des fonctionnalités qui seront
désinstallés. Cliquezsur Supprimer pour commencer la désinstallation.
Windows 2008 - 2012 R2

Pour désinstaller SQL Server de Windows Server 2008, Windows Server 2012 et Windows 2012 R2, suivez les
étapes suivantes :
1. Pour commencer le processus de suppression, accédez au Panneaude contrôle, puis
sélectionnezProgrammes et fonctionnalités.
2. Cliquez avec le bouton Microsoft SQL Ser ver (Version) (Bit) et sélectionnez Désinstaller. Par
exemple, SQL Server 2012 (64 bits).
3. SélectionnezSupprimer dans la fenêtre SQL Server boîte de dialogue pour lancer l’Assistant SQL
Server’installation.
4. Dans la pageSélectionner une instance, utilisez la zone de drop-down pour spécifier une instance de [!
INCLUDEssNoVersion] à supprimer, ou spécifiez l’option de suppression uniquement du [!
IncluDEssNoVersion] fonctionnalités partagées et outils de gestion. Pour continuer, sélectionnezSuivant.
5. Dans la pageSélectionner des fonctionnalités, spécifiez les fonctionnalités à supprimer de l’instance
spécifiée de [! INCLUDEssNoVersion].
6. Dans la pagePrêt à supprimer, examinez la liste des composants et des fonctionnalités qui seront
désinstallés. Cliquezsur Supprimer pour commencer la désinstallation.
7. Actualisez la fenêtre Programmes et fonctionnalités pour vérifier que l’instance SQL Server a bien été
supprimée et déterminez les composants de SQL Server existants. Supprimez également ces
composants de cette fenêtre, si vous le souhaitez.
Références
Télécharger SQL Server Management Studio (SSMS)
Vous pouvez recevoir un message d’erreur lorsque
vous essayez d’utiliser SQL Server Management
Studio pour mettre à jour une ligne d’un tableau
dans SQL Server
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez de mettre à jour une table à
l’aide de SQL Server Management Studio dans SQL Server.
Symptômes
Prenons le cas de figure suivant. Vous essayez d’utiliser SQL Server Management Studio pour mettre à jour un
tableau dans Microsoft SQL Server. Dans l’Explorateur d’objets, cliquez avec le bouton droit sur le nom de la
table, puis cliquez sur Ouvrir la table. Vous mettez à jour une ligne du tableau. Dans ce scénario, vous pouvez
recevoir l’un des messages d’erreur suivants de manière inattendue dans la boîte de Microsoft SQL Ser ver
Management Studio suivante :
Les données ont changé depuis la dernière récupération du volet Résultats. Voulez-vous enregistrer
vos modifications maintenant ?
(Erreur de contrôle d’curité optimiste)
Cliquez sur Oui pour valider vos modifications dans la base de données.
Cliquez sur Non pour ignorer votre modification et récupérer les données actuelles de cette ligne.
Cliquez sur Annuler pour continuer la modification.
NOTE
Si vous cliquez sur Oui dans cette boîte de dialogue de message d’erreur, la ligne est correctement mise à jour.
Aucune ligne n’a été mise à jour.

Les données de la ligne X n’ont pas été engagés.
Source de l’erreur : Microsoft.VisualStudio.DataTools.
Message d’erreur : la ou les valeurs de ligne mises à jour ou supprimées ne rendent pas la ligne
unique ou modifient plusieurs lignes (N lignes).
Corrigez les erreurs et réessayez ou appuyez sur ÉCHAP pour annuler le ou les changements.
NOTE
Si vous recevez cette boîte de dialogue de message, vous ne pouvez pas mettre à jour la ligne.
Ce problème se produit si les conditions suivantes sont vraies :

Le tableau contient une ou plusieurs colonnes du type texte ou ntext.
La valeur de l’une de ces colonnes contient les caractères suivants :
Signe pourcentage (%)
Trait de soulignement (_)
Crochet gauche ([)
La table ne contient pas de clé primaire.
NOTE
This issue also occurs when you try to use Table Designer in Microsoft Visual Studio to update a table that is in a SQL
Server database.
Cause
Ce problème se produit car SQL Server Management Studio génère une instruction SQL incorrecte pour
l’opération de mise à jour. Lorsque le tableau ne contient pas de clé primaire, les valeurs de toutes les colonnes
sont utilisées pour identifier la ligne à mettre à jour. Lorsque SQL Server Management Studio cette instruction,
l’opérateur de comparaison incorrect (=) est utilisé pour comparer les colonnes des types de données texte,
ntext ou image.
Pour contourner ce problème, créez une fenêtre de requête dans SQL Server Management Studio. Ensuite,
exécutez une instruction SQL UPDATE pour mettre à jour la ligne dans le tableau.
NOTE
Si vous recevez le premier message d’erreur mentionné dans la section Symptômes, vous pouvez cliquer sur Oui pour
mettre à jour la ligne.
Références
UPDATE (Transact-SQL)
Message d’erreur lorsque vous ouvrez Gestionnaire
de configuration SQL Server dans SQL Server :
impossible de se connecter au fournisseur WMI.
Vous n’avez pas d’autorisation ou le serveur est
inaccessible
Cet article vous aide à contourner le problème qui se produit lorsque vous ouvrez Gestionnaire de configuration
SQL Server.
Symptômes
Vous pouvez recevoir l’un des messages d’erreur suivants lorsque vous ouvrez Gestionnaire de configuration
SQL Server :
Impossible de se connecter au fournisseur WMI. Vous n’avez pas d’autorisation ou le serveur est
inaccessible. Notez que vous ne pouvez gérer SQL Server serveurs 2005 et ultérieurs qu’avec Gestionnaire
de configuration SQL Server.
Espace de noms non valide [0x8004100e]
ou
Impossible de se connecter au fournisseur WMI. Vous n’avez pas d’autorisation ou le serveur est
inaccessible. Notez que vous pouvez uniquement gérer SQL Server serveurs 2005 et ultérieurs avec
Gestionnaire de configuration SQL Server.
Classe non valide [0x80041010]
Cause
Gestionnaire de configuration SQL Server utiliser Window Management Instrumentation (WMI) pour afficher et
modifier certains paramètres du serveur. Lors de la connexion aux serveurs, Gestionnaire de configuration SQL
Server utilise WMI pour obtenir l’état des services SQL Server (MSSQLSERVER) et SQL Server Agent. Ce
problème se produit car le fournisseur WMI est supprimé lorsque vous désinstallez une instance de SQL Server.
Ce fichier se trouve dans le %programfiles(x86)% dossier.
Vous pouvez utiliser l’une des options suivantes pour résoudre le problème.
Option 1 : Recompiler SQL fournisseur WMI à l’aide du compilateur MOF (Managed Object Format)
Pour cela, procédez comme suit :
1. Le fichier MOF (sqlmgmproviderxpsp2up.mof) de votre instance SQL se trouve dans le dossier «
%programfiles(x86)%\Microsoft SQL Server\nnn\Shared ». Déterminez l’emplacement du fichier
mofcomp pour votre version à l’aide du tableau suivant comme référence :
VERSIO N NN
Microsoft SQL Server 2019 150
Microsoft SQL Server 2008 R2 100
2. Ouvrez une invite de commandes avec élévation de niveau élevé et modifiez le répertoire en
emplacement de dossier à l’étape 1.
3. Tapez ensuite la commande suivante, puis appuyez sur Entrée :
mofcomp "sqlmgmproviderxpsp2up.mof"
NOTE
Pour que cette commande réussisse, le fichier Sqlmgmproviderxpsp2up.mof doit être présent dans le
%programfiles(x86)%\Microsoft SQL Server\nnn\Shared dossier.
4. Après avoir exécuté l’outil mofcomp, redémarrez le service WMI pour que les modifications prennent
effet. Le nom du service est Windows Instrumentation de gestion.
Option 2 : réparer votre installation SQL Server’installation. Pour plus d’informations, examinez La réparation
d’une installation SQL Server échouée
NOTE
Cette option est requise uniquement si le sqlmgmproviderxpsp2up.mof est absent de l’emplacement.
%programfiles(x86)%\Microsoft SQL Server\nnn\Shared
Voir aussi
Gestionnaire de configuration SQL Server
Configurer WMI pour afficher l’état du serveur dans SQL Server outils
La base de données MSDB s’accroît SQL Server
avec des classements de caractères supplémentaires
Version du produit d’origine : SQL Server 12 et versions ultérieures
Symptôme
Vous avez installé une instance avec un classement à l’aide de caractères supplémentaires pour la base de
données système dans SQL Server.
Vous avez configuré Management Data Warehouse (MDW) et la collecte de données.
Dans ce scénario, lorsque les packages SQL Server Integration Services (SSIS) créés par la collecte de données
s’exécutent, vous constatez que la base de données MSDB augmente de manière inattendue.
NOTE
Ce type de nom de classement se termine par _SC, par exemple, Latin1_General_100_CI_AS_SC .
Toutes les 10 secondes, les 11 messages d’avertissement suivants sont insérés dans la msdb.dbo.sysssislog
table système :
La troncation peut se produire en raison de la récupération de données à partir de la colonne de base de

données « task_state » d’une longueur de 20 à la colonne de flux de données « task_state » d’une longueur
de 10.
données « request_status » d’une longueur de 30 à la colonne de flux de données « request_status » avec
une longueur de 15.
données « session_status » d’une longueur de 30 à la colonne de flux de données « session_status » avec
une longueur de 15.
données « host_name » d’une longueur de 40 à la colonne de flux de données « host_name » d’une
longueur de 20.
données « program_name » d’une longueur de 100 à la colonne de flux de données « program_name »
d’une longueur de 50.
données « login_name » d’une longueur de 60 à la colonne de flux de données « login_name » d’une
longueur de 30.
données « wait_type » d’une longueur de 60 à la colonne de flux de données « wait_type » d’une longueur
de 45.
données « last_wait_type » d’une longueur de 60 à la colonne de flux de données « last_wait_type » avec une
longueur de 45.
La troncation peut se produire en raison de la récupération de données de la colonne de base de données «
wait_resource » d’une longueur de 100 à la colonne de flux de données « wait_resource » d’une longueur de
50.
données « resource_description » d’une longueur de 280 à la colonne de flux de données «
resource_description » d’une longueur de 140.
Colonnes externes pour ODS : obtenir une capture instantanée dm_exec_requests ne sont plus
synchronisées avec les colonnes de source de données. La colonne externe « task_state » doit être mise à
jour. La colonne externe « request_status » doit être mise à jour. La colonne externe « session_status » doit
être mise à jour. La colonne externe « host_name » doit être mise à jour. La colonne externe « program_name
» doit être mise à jour. La colonne externe « login_name » doit être mise à jour. La colonne externe «
wait_type » doit être mise à jour. La colonne externe « last_wait_type » doit être mise à jour. La colonne
externe « wait_resource » doit être mise à jour. La colonne externe « resource_description » doit être mise à
jour.
Par conséquent, le msdb.dbo.sysssislog tableau s’agrandit d’une page (8 Ko) toutes les 10 secondes. L’impact
sur l’espace disque est :
2,8 Mo par heure (8 Ko x 6 x 60)
67,5 Mo par jour (8 Ko x 6 x 60 x 24)
1,97 Go par mois (8 Ko x 6 x 60 x 24 x 30)
Cause
Les classements utilisant des caractères supplémentaires modifient la taille de certaines colonnes du dynamic
management view (DMV). L’outil Collecteur de données capture le contenu de certains DMV, par exemple, et
ajoute les résultats dans la base de données MDW à l’aide de sys.dm_exec_requests packages SSIS. Dans ces
packages SSIS, les tailles de colonne sont prédéfinie en fonction de la taille des colonnes pour les classements
sans utiliser de caractères supplémentaires. Lorsque les packages s’exécutent, un message d’avertissement est
renvoyé pour chaque colonne dont la taille est plus grande que la taille prédéfinit et est ajouté au
msdb.dbo.sysssislog tableau.
NOTE
Ces messages d’avertissement n’affectent pas l’insertion des données réelles de la DMV dans la table de collecte de
données.
Le processus de collecte de données collecte les métadonnées du premier jeu de résultats lors de
sp_syscollector_snapshot_dm_exec_requests l’appel. Le script sql suivant est un exemple :
exec [sys].sp_describe_first_result_set N'EXEC [msdb].[dbo].[sp_syscollector_snapshot_dm_exec_requests]

5',NULL,1
Cet appel renvoie des résultats différents selon le classement, à l’aide de caractères supplémentaires ou non :
Instance avec un classement qui n’utilise pas de caractères supplémentaires :
NOTE
Pour plus de clarté, seules les lignes et colonnes affectées sont affichées.
P EUT AVO IR N O M DU
O RDIN A L DE L A VA L EUR SY ST ÈM E SY ST ÈM E LO N GUEUR C L A SSEM EN
C O LO N N E NAME N UL L T Y P E_ID T Y P E_N A M E M A XIM A L E T
11 task_state 1 231 nvarchar(10) 20 SQL_Latin1_

General_CP1
_CI_AS
12 request_stat 1 231 nvarchar(15) 30 SQL_Latin1_

us General_CP1
_CI_AS
13 session_stat 1 231 nvarchar(15) 30 SQL_Latin1_

us General_CP1
_CI_AS
...
17 host_name 1 231 nvarchar(20) 40 SQL_Latin1_

General_CP1
_CI_AS
18 program_na 1 231 nvarchar(50) 100 SQL_Latin1_

me General_CP1
_CI_AS
19 login_name 1 231 nvarchar(30) 60 SQL_Latin1_

General_CP1
_CI_AS
20 wait_type 1 231 nvarchar(45) 90 SQL_Latin1_

General_CP1
_CI_AS
21 last_wait_typ 1 231 nvarchar(45) 90 SQL_Latin1_

e General_CP1
_CI_AS
22 wait_duratio 0 127 bigint 8 NULL

n_ms
23 wait_resourc 1 231 nvarchar(50) 100 SQL_Latin1_

e General_CP1
_CI_AS
24 resource_des 1 231 nvarchar(14 280 SQL_Latin1_

cription 0) General_CP1
_CI_AS
Instance avec un classement qui utilise des caractères supplémentaires :

NOTE
Pour plus de clarté, seules les lignes et colonnes affectées sont affichées.
P EUT AVO IR N O M DU
O RDIN A L DE L A VA L EUR SY ST ÈM E SY ST ÈM E LO N GUEUR C L A SSEM EN
C O LO N N E NAME N UL L T Y P E_ID T Y P E_N A M E M A XIM A L E T
11 task_state 1 231 nvarchar(20) 40 SQL_Latin1_

General_CP1
_CI_AS
12 request_stat 1 231 nvarchar(30) 60 SQL_Latin1_

us General_CP1
_CI_AS
13 session_stat 1 231 nvarchar(30) 60 SQL_Latin1_

us General_CP1
_CI_AS
...
17 host_name 1 231 nvarchar(20) 40 SQL_Latin1_

General_CP1
_CI_AS
18 program_na 1 231 nvarchar(10 200 SQL_Latin1_

me 0) General_CP1
_CI_AS
19 login_name 1 231 nvarchar(60) 120 SQL_Latin1_

General_CP1
_CI_AS
20 wait_type 1 231 nvarchar(60) 120 SQL_Latin1_

General_CP1
_CI_AS
21 last_wait_typ 1 231 nvarchar(60) 120 SQL_Latin1_

e General_CP1
_CI_AS
23 wait_resourc 1 231 nvarchar(50) 100 SQL_Latin1_

e General_CP1
_CI_AS
24 resource_des 1 231 nvarchar(28 560 SQL_Latin1_

cription 0) General_CP1
_CI_AS
Les deux instances montrent la différence sur certaines colonnes. Par exemple, la colonne a un nom de type
système wait_type de nvarchar(45) avec une longueur maximale de 90 sur un classement standard.
Toutefois, les classements utilisant des caractères supplémentaires ont un nom de type système nvarchar(60)
d’une longueur maximale de 120. La différence de taille entraîne les messages d’avertissement enregistrés par
le package SSIS.
Vous pouvez utiliser l'une des solutions de contournement suivantes :
IMPORTANT
Si vous utilisez la solution de contournement 1 et la solution de contournement 2, les connexions, les travaux ou les
packages existants seront perdus. Ces solutions de contournement ne doivent être utilisées que dans un environnement
hors production.
Solution de contournement 1
Désinstallez et réinstallez l’instance SQL Server avec un classement sans utiliser de caractères supplémentaires.
Reconstruire l’instance des bases de données système avec un classement sans utiliser de caractères
supplémentaires.
Créez un travail pour supprimer les avertissements inutiles de la msdb.dbo.sysssislog table. Dans l’exemple
suivant, le travail est programmé pour s’exécuter toutes les heures. Vous pouvez définir une planification
différente selon vos besoins en modifiant la @freq_subday_interval valeur.
Par exemple, vous pouvez modifier la valeur @freq_subday_interval de 1 à 2 pour exécuter le travail toutes les
deux heures.
USE [msdb]
GO
/****** Object: Job [Data Collection Warnings Cleanup] Script Date: <Datetime> ******/
BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
/****** Object: JobCategory [[Uncategorized (Local)]] Script Date: <Datetime> ******/
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'[Uncategorized (Local)]' AND
category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Uncategorized (Local)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
END
DECLARE @jobId BINARY(16)

EXEC @ReturnCode = msdb.dbo.sp_add_job @job_name=N'Data Collection Warnings Cleanup',
@enabled=1,
@notify_level_eventlog=0,
@notify_level_email=0,
@notify_level_netsend=0,
@notify_level_page=0,
@delete_level=0,
@description=N'This jobs removes uneccessary Data Colletion Warnings from msdb.dbo.sysssislog
table. These warnings are logged when system uses a supplementary characters collation.',
@category_name=N'[Uncategorized (Local)]',
@owner_login_name=N'WIN-BINNHII7A8S\Administrator', @job_id = @jobId OUTPUT
/****** Object: Step [Delete warrnings] Script Date: <Datetime> ******/
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Delete warrnings',
@step_id=1,
@cmdexec_success_code=0,
@on_success_action=1,
@on_success_step_id=0,
@on_fail_action=2,
@on_fail_step_id=0,
@on_fail_step_id=0,
@retry_attempts=0,
@retry_interval=0,
@os_run_priority=0, @subsystem=N'TSQL',
@command=N'set nocount on
declare @system_collation nvarchar(128)

declare @CountWarn1 int, @CountWarn2 int
declare @InfoMsg nvarchar(200)
select @system_collation = cast(SERVERPROPERTY(''collation'') as nvarchar(128))

set @CountWarn1 = 0
set @CountWarn2 = 0
if upper(right(@system_collation,2)) = ''SC''
begin -- we have a supplementary characters collation we need to remove unnecessary warnings from
msdb.dbo.sysssislog table
delete
from msdb.dbo.sysssislog
where event = ''OnWarning''
and source like ''Set%Master_Package_Collection''
and message like ''Truncation may occur%''
Set @CountWarn1 = @@ROWCOUNT
delete
from msdb.dbo.sysssislog
where event = ''OnWarning''
and source like ''Set%Master_Package_Collection''
and message like ''The external columns for ODS - Get snapshot of%''
Set @CountWarn2 = @@ROWCOUNT
set @InfoMsg = ''Data Collection warning clean up job deleted

''+ltrim(str(@CountWarn1+@CountWarn2,8))+'' warnings from msdb.dbo.sysssislog table.''
print @InfoMsg
end
',
@database_name=N'master',
@flags=0
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule @job_id=@jobId, @name=N'Run every Hour',
@enabled=1,
@freq_type=4,
@freq_interval=1,
@freq_subday_type=8,
@freq_subday_interval=1,
@freq_relative_interval=0,
@freq_recurrence_factor=0,
@active_start_date=20201224,
@active_end_date=99991231,
@active_start_time=0,
@active_end_time=235959,
@schedule_uid=N'684bccd2-7424-4011-85d6-1d81791c53fe'
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:
GO
Un ensemble de collections de collecteurs de
données peut ne pas être chargé si un fichier cache
est endommagé
Cet article indique qu’en cas de corruption d’un fichier cache, il se peut que le jeu de collections de collecteurs de
données ne soit pas chargé.
Symptômes
Vous configurez un ensemble Microsoft SQL Server collection de collecteurs de données. Ensuite, vous
remarquerez que les nouvelles données ne sont pas téléchargées vers la base de données d’entrepôt de
données de gestion. Lorsque vous affichez les journaux des ensembles decollections, vous recevez l’un des
messages d’erreur suivants :
Le fichier avait des informations de version et d’indicateurs mauvaises. Le fichier est endommagé ou
n’est pas un fichier de données brutes produit par SSIS.
le composant « Destination du fichier brut » (57) a échoué à la phase de pré-exécution et a renvoyé le
code d’erreur 0xC0202061
Métadonnées non appropriées rencontrées dans l’en-tête de fichier. Le fichier est endommagé ou
n’est pas un fichier de données brutes produit par SSIS.
code d’erreur 0xC020205E
Fin de fichier inattendue rencontrée lors de la lecture d’octets X à partir du fichier « Y ». Le fichier a
pris fin prématurément en raison d’un format de fichier non valide.
code d’erreur 0xC0202069
L’adaptateur a rencontré un type de données X non reconnu. Cela peut être dû à un fichier d’entrée
endommagé (source) ou à un type de tampon non valide (destination).
code d’erreur 0xC020206B
Chaîne trop longue. L’adaptateur lit une chaîne qui a été X octets longs et attendu une chaîne ne plus
plus que les octets Y, au décalage Z. Cela peut indiquer un fichier d’entrée endommagé. Le fichier
affiche une longueur de chaîne trop grande pour la colonne de mémoire tampon.
code d’erreur 0xC020206C
Cause
Ce problème se produit lorsqu’un ou plusieurs fichiers cache du collecteur de données sont endommagés.
L’altération peut être causée pour l’une des raisons suivantes :
Le collecteur de données a rencontré une exception.
Le disque est à court d’espace libre pendant que le collecteur de données écrit dans un fichier cache.
Un microprogramme ou un problème de pilote se produit.
Résolution
Recherchez le fichier cache endommagé et supprimez-le. Pour cela, procédez comme suit :
1. Démarrez SQL Server Management Studio, puis connectez-vous à l’instance de SQL Server où l’erreur se
produit.
2. Développez le dossier Gestion, cliquez avec le bouton droit sur Collecte de données, puis sélectionnez
Propriétés.
3. Si un répertoire est affiché pour le répertoire de cache, il s’agit de l’emplacement des fichiers de cache du
collecteur de données. Allez à l’étape 5.
4. Si un répertoire n’est pas affiché pour le répertoire de cache, le répertoire de cache par défaut est le
répertoire temporaire local du compte qui exécute le jeu de collections. Ce compte peut être le compte SQL
Server service agent de sécurité. Par exemple, sur Windows Server 2008, si le jeu de collections a été exécuté
par un compte nommé sqlacct, le répertoire temporaire de ce compte se trouve dans un chemin d’accès
semblable à ce qui suit : C:\Users\sqlacct\AppData\Local\Temp
5. Recherchez tous les fichiers qui ont un *. Cache file name extension, and move the files to a different
directory. Si l’ensemble de collections est celui de la collection Utility Information, n’essayez pas d’exécuter le
jeu de collections directement. Patientez 30 minutes pour voir si le problème est résolu. Si l’ensemble de
collections est un autre ensemble de collections, redémarrez le jeu de collections.
Collecte de données
Entrepôt de données de gestion
SQL Server Problème PowerShell lorsque
RemoteSigned n’est pas définie dans le contrôleur
de domaine pour SQL Server
Cet article vous aide à résoudre le problème qui se produit lorsque la stratégie d’ordinateur du contrôleur de
domaine n’est pas définie sur RemoteSigned par GPO pour SQL Server.
Symptômes
Lorsque vous ouvrez SQL Server console PowerShell de Microsoft SQL Server 2012 ou Microsoft SQL Server
2014 et que la stratégie d’ordinateur du contrôleur de domaine n’est pas définie sur RemoteSigned by Group
Policy Object (GPO), vous pouvez recevoir le message d’erreur suivant :
set-executionpolicy : Windows PowerShell votre stratégie d’exécution a été correctement mise à jour, mais le
paramètre est retenté par une stratégie définie à une étendue plus spécifique. En raison du remplacement,
votre shell conservera sa stratégie d’exécution effective actuelle de Non restreint. Tapez Get-ExecutionPolicy -
List pour afficher vos paramètres de stratégie d’exécution.
Pour plus d'informations, consultez
« Get-Help Set-ExecutionPolicy ».
À line:1 char:1
+ set-executionpolicy RemoteSigned -scope process -Force
En outre, le travail échoue à la troisième étape si le contrôleur de domaine n’est pas définie sur RemoteSigned
par GPO et que vous pouvez recevoir le syspolicy_purge_history message d’erreur suivant :
Exécuté en tant qu’utilisateur : AJ\devARsqlagt. Une étape de travail a reçu une erreur à la ligne 1 dans un
script PowerShell. La ligne correspondante est « set-executionpolicy RemoteSigned -scope process -Force ».
Corrigez le script et reprogrammez le travail. Les informations d’erreur renvoyées par PowerShell sont : «
Erreur de sécurité. '. Code de sortie du processus -1. L’étape a échoué.
Cause
Ce problème se produit parce que la stratégie de l’ordinateur n’est pas définie sur RemoteSigned par GPO et
qu’elle est poussée vers les serveurs membres. Par exemple, si la stratégie d’exécution pour la configuration du
contrôleur de domaine est la suivante :
Scope - ExecutionPolicy
--------------------------------------------------------------
MachinePolicy - Unrestricted
UserPolicy - Undefined
Process - RemoteSigned
CurrentUser - Undefined
LocalMachine - RemoteSigned
MachinePolicy est prioritaire sur toutes les autres stratégies.

La stratégie de groupe est poussée du contrôleur de domaine vers les serveurs membres associés à cette
stratégie de groupe. Cela définit le MachinePolicy mode Non restreint et SQL Server PowerShell tente de
s’exécuter avec la stratégie RemoteSigned d’exécution. Par conséquent, une situation conflictuelle se produit et le
syspolicy_purge_history travail échoue. Le même travail s’exécute SQL Server quelle que soit la stratégie de
l’ordinateur dans le contrôleur de domaine.
Par mesure de sécurité, SQL Server 2012 démarre SQL PowerShell dans la stratégie RemoteSigned. Cela
entraîne l’échec du travail et le problème précédent se produit.
Unrestricted n’est absolument pas recommandé du point de vue de la sécurité, car cela signifie aucune
restriction. C’est la raison pour laquelle lorsque vous démarrez à partir SQL 2012, les scripts PowerShell
s’exécutent correctement lorsque MachinePolicy est définie comme RemoteSigned in Domain Controller.
Ne définissez pas la stratégie ordinateur du contrôleur de domaine par GPO. Si elle n’est pas définie, cela
signifie que la stratégie de niveau suivant (par exemple, UserPolicy, puis Process, CurrentUser et enfin
LocalMachine) sera prioritaire.
Créez une unité d’organisation dans Utilisateurs et ordinateurs Active Directory et lier cette unité
d’organisation à votre stratégie de groupe. Activez-la ensuite pour la stratégie RemoteSigned. Pour cela,
1. Go to Active Director y Users and Computers .
2. Cliquez avec le bouton droit sur votre nouvelle unité d’organisation de domaine pour créer une
unité -> -> d’organisation.
3. Tapez gpmc.msc dans Exécuter, puis cliquez avec le bouton droit sur Nouvel objet de stratégie de
groupe pour créer un objet de stratégie -> de groupe.
4. Cliquez avec le bouton droit sur la modification de l’GPO -> nouvellement créé. Elle ouvre une
nouvelle fenêtre.
5. Go to Computer Configuration -> Policies -> Administrative Templates -> Windows
components -> Windows PowerShell -> double-click Turn on Script Execution .
6. Définissez la stratégie d’exécution pour autoriser les scripts locaux et les scripts signés à distance.
7. Dans la zone Plan de numérotation (contexte téléphonique) , cliquez sur Parcourir pour
localiser le plan de numérotation de l’utilisateur.
8. Go to Active Director y Users and Computers, and then click Computers . Vous trouverez une
liste d’ordinateurs pour le domaine. Cliquez avec le bouton droit sur le ou les ordinateurs que vous
souhaitez déplacer dans l’unité d’organisation nouvellement créée. De cette manière, vous pouvez
déplacer un seul ordinateur ou un groupe d’ordinateurs vers une unité d’organisation.
9. Go to Group Policy Management , right-click newly created Organizational Unit , click Link an
Existing GPO , select the newly created GPO , and then click OK .
10. Mettez à jour la stratégie sur le contrôleur de domaine et sur l’ordinateur client en exécutant cette
commande dans PowerShell.
gpupdate /force
11. Vérifiez que la stratégie de l’ordinateur pour l’unité d’organisation et le composant client doit être
RemoteSigned.
Références
À propos des stratégies d’exécution
Description des utilitaires de langage de marques
de relecture pour SQL Server
Cet article décrit un groupe d’utilitaires qui aide les professionnels à résoudre les SQL Server.
Introduction
L SQL Server de support technique utilise plusieurs utilitaires écrits en interne pour faciliter le travail lié à un cas
de support client classique. Cet article décrit une suite d’utilitaires appelée utilitaires RML (Replay Markup
Language) pour SQL Server. Les développeurs de bases de données et les administrateurs système peuvent
utiliser les utilitaires RML pour SQL Server.
Vous pouvez utiliser les utilitaires RML pour SQL Server pour effectuer les tâches suivantes :
Vous pouvez déterminer l’application, la base de données, SQL Server connexion ou la requête qui utilise le
plus de ressources.
Vous pouvez déterminer si le plan d’exécution d’un lot est modifié lorsque vous capturez le suivi du lot. En
outre, vous pouvez utiliser les utilitaires RML SQL Server pour déterminer comment SQL Server exécute
chacun de ces plans d’exécution.
Vous pouvez déterminer les requêtes qui s’exécutent plus lentement qu’auparavant.
Après avoir capturé un suivi pour une instance de SQL Server, vous pouvez utiliser les utilitaires RML pour SQL
Server pour relire le fichier de suivi par rapport à une autre instance de SQL Server. Si vous capturez également
le suivi pendant la relecture, vous pouvez utiliser les utilitaires RML pour SQL Server pour comparer le nouveau
fichier de suivi au fichier de suivi d’origine. Vous pouvez utiliser cette technique pour tester le comportement
SQL Server après avoir appliqué les modifications. Par exemple, vous pouvez utiliser cette technique pour tester
le comportement SQL Server après avoir procédé comme suit :
Vous installez un SQL Server Service Pack.
Vous installez un correctif SQL Server logiciel.
Vous mettez à jour une procédure stockée ou une fonction.
Vous mettez à jour un index ou créez un index.
Historique des versions

N UM ÉRO DE VERSIO N DESC RIP T IO N
9.04.0100 La version Web actuelle disponible à partir du Centre de

téléchargement Microsoft qui prend en charge toutes les
versions publiées de SQL Server
N UM ÉRO DE VERSIO N DESC RIP T IO N
9.04.0098 La version actuelle est empaqueté avec Assistant

Expérimentation de base de données utilitaire qui prend en
charge toutes les versions de SQL Server
9.04.0097 La version actuelle disponible à partir du site SQL Nexus qui

prend en charge toutes les versions publiées de SQL Server
9.04.0051 Version Web précédente disponible à partir du Centre de

téléchargement Microsoft qui prend en charge SQL Server
2000, SQL Server 2005, SQL Server 2008 SQL Server 2008
R2, SQL Server 2012 et SQL Server 2014
9.04.0004 Version Web précédente qui prend en charge SQL Server

2000, SQL Server 2005, SQL Server 2008 SQL Server 2008
R2, SQL Server 2012 et SQL Server 2014

2000, SQL Server 2005, SQL Server 2008 et SQL Server
2008 R2.

2000 et SQL Server 2005
8.10.0010 Version Web initiale qui prend en charge SQL Server 7.0 et
SQL Server 2000
Cette version actuelle des utilitaires RML pour SQL Server les versions antérieures. Vous devez désinstaller toute
version antérieure des utilitaires RML pour SQL Server avant d’installer la version actuelle. La version actuelle
des utilitaires RML pour SQL Server prise en charge de SQL Server 2000, SQL Server 2005, SQL Server 2008,
SQL Server 2008 R2, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server
2017, SQL Server 2019. En outre, la version actuelle des utilitaires RML pour SQL Server contient des mises à
jour logicielles importantes, des fonctionnalités améliorées (fichiers .trc et .xel de processus) et des rapports,
ainsi que des améliorations en matière de performances et d’évolutivité.
Obtenir les utilitaires RML pour SQL Server

Lorsque vous installez l’Assistant Expérimentation de base de données vous pouvez obtenir les utilitaires RML
(ReadTrace et ostress) à partir du dossier : C:\Program Files (x86)\Microsoft Corporation\Assistant
Expérimentation de base de données\Dependencies\X64\
Si vous utilisez des utilitaires RML avec SQL Nexus, vous pouvez obtenir ReadTrace et ostress à partir de
l’emplacement :https://github.com/microsoft/SqlNexus/releases/tag/09.04.0097
Les utilitaires RML pour SQL Server sont disponibles en téléchargement à partir du Centre de téléchargement
NOTE
Microsoft fournit les utilitaires RML pour SQL Server en l’temps. Les services de support technique Microsoft (CSS) ne
fournissent pas de support ni de mises à jour pour les utilitaires RML pour SQL Server. Si vous avez une suggestion ou si
vous souhaitez signaler un bogue, vous pouvez utiliser l’adresse de messagerie dans la rubrique Problèmes et assistance
du fichier d’aide (RML Help.pdf). Le fichier d’aide est inclus dans les utilitaires RML pour SQL Server.
Avantages des utilitaires RML pour SQL Server
Les utilitaires RML pour SQL Server sont utiles si vous souhaitez simuler le test d’application lorsqu’il est difficile
ou impossible de le tester à l’aide de l’application réelle. Par exemple, dans un environnement de test, il peut être
difficile de générer la même charge utilisateur que celle qui existe dans l’environnement de production. Vous
pouvez utiliser les utilitaires RML pour SQL Server pour relire une charge de travail de production dans un
environnement de test et évaluer l’impact sur les performances des modifications, telles qu’une mise à niveau
vers SQL Server 2008 ou l’application d’un Service Pack SQL Server. En outre, vous pouvez utiliser les utilitaires
RML pour SQL Server analyser et comparer différentes charges de travail de relecture. Ce type d’analyse de
régression serait sinon un processus difficile à effectuer manuellement.
Le fichier d’aide contient une rubrique de démarrage rapide. Cette rubrique inclut un bref exercice qui vous
familiarisera avec chaque utilitaire RML. Pour ouvrir le fichier d’aide, cliquez sur Démarrer, pointez sur Tous les
programmes, pointez sur Utilitaires RML pour SQL Server, pointez sur Aide, puis cliquez sur Aide RML .
Utilitaires dans les utilitaires RML pour SQL Server

Les utilitaires RML pour SQL Server contiennent les utilitaires suivants :
ReadTrace
Reporter
OStress
OStress Replay Control Agent (ORCA)
Pour obtenir une description complète de chaque utilitaire et exemple d’utilisation, voir l’aide RML incluse dans
les utilitaires RML pour SQL Server.
Dépendances pour les utilitaires RML pour SQL Server

IMPORTANT
Les applications fournies dans le cadre de la suite d’utilitaires RML nécessitent la mise à disposition de plusieurs
dépendances supplémentaires.
Dépendances pour reporter

Vous devez vous assurer que les contrôles de l’Observateur de rapports sont disponibles dans le même dossier
que Reporter.exe ou dans le GAC. Les DLL dont vous avez besoin Reporter.exe sont
Microsoft.ReportViewer.Common.dll Microsoft.ReportViewer.DataVisualization.dll
Microsoft.ReportViewer.ProcessingObjectModel.dll Microsoft.ReportViewer.WinForms.dll
Vous pouvez obtenir ces DLL à l’aide du script PowerShell suivant :
Register-PackageSource -Name MyNuGet -Location https://www.nuget.org/api/v2 -ProviderName NuGet
Get-PackageSource
Find-Package Microsoft.ReportViewer.Common -AllVersions

Install-Package Microsoft.ReportViewer.Common -RequiredVersion 10.0.40219.1
Copy-Item -Path "C:\Program

Files\PackageManagement\NuGet\Packages\Microsoft.ReportViewer.Common.10.0.40219.1\lib\Microsoft.ReportViewer
.Common.dll" -Destination "C:\Program Files\Microsoft Corporation\RMLUtils"
.DataVisualization.dll" -Destination "C:\Program Files\Microsoft Corporation\RMLUtils"
.ProcessingObjectModel.dll" -Destination "C:\Program Files\Microsoft Corporation\RMLUtils"
Find-Package Microsoft.ReportViewer.WinForms -AllVersions

Install-Package Microsoft.ReportViewer.WinForms -RequiredVersion 10.0.40219.1

Files\PackageManagement\NuGet\Packages\Microsoft.ReportViewer.WinForms.10.0.40219.1\lib\Microsoft.ReportView
er.WinForms.dll" -Destination "C:\Program Files\Microsoft Corporation\RMLUtils"
Dépendances pour Expander

Vous devez vous assurer que les contrôles de compression/décompression sont disponibles dans le même
dossier que Expander.exe ou dans le GAC. Les DLL dont vous avez besoin Expander.exe sont
BRICOLSOFTZipx64.dll UnRar64.dll XceedZipX64.dll
Vous pouvez obtenir ces DLL auprès des packages logiciels respectifs des fournisseurs.
https://www.rarlab.com/rar/UnRARDLL.exe
https://www.7-zip.org/a/7z1900-x64.exe
https://www.nuget.org/packages/Xceed.Products.Zip.Full/
Erreur lorsque vous utilisez Gestionnaire de
configuration SQL Server pour redémarrer le
service agent SQL Server dans SQL Server
Cet article vous aide à résoudre le problème qui se produit lorsque vous utilisez Gestionnaire de configuration
SQL Server pour redémarrer le service d’agent SQL Server après avoir changé le mot de passe du compte de
service.
Symptômes
Lorsque vous utilisez Gestionnaire de configuration SQL Server pour redémarrer le service SQL Server Agent
de Microsoft SQL Server, vous recevez le message d’erreur suivant :
La demande a échoué ou le service n’a pas répondu en temps voulu. Pour plus d’informations, consultez le
journal des événements ou d’autres journaux d’erreurs applicables.
Lorsque ce problème se produit, l’utilisation du processeur est élevée et vous ne pouvez pas ignorer le message
d’erreur en cliquant sur OK . Vous de devez peut-être utiliser le Gestionnaire des tâches pour mettre fin
Gestionnaire de configuration SQL Server processus.
NOTE
Vous pouvez également recevoir ce message d’erreur dans d’autres circonstances.
Pour contourner ce problème, démarrez le service SQL Server Agent à l’aide de la console de gestion des
services (Services.msc).
Étapes pour reproduire ce problème

1. Spécifiez un compte pour le service SQL Server Agent.
2. Modifiez le mot de passe du compte SQL Server de démarrage de l’agent.
3. Utilisez Gestionnaire de configuration SQL Server pour redémarrer le service SQL Server Agent de sécurité.
Erreur lorsque vous essayez d’exécuter l’utilitaire
Sqlmaint après la mise à niveau vers SQL Server
2008 ou une version ultérieure
Cet article vous aide à résoudre le problème qui se produit lorsque vous exécutez l’utilitaire Sqlmaint après la
mise à niveau de SQL Server 2000 SP4 vers SQL Server 2008 ou une version ultérieure.
Symptômes
Vous avez réussi Microsoft SQL Server 2000 Service Pack 4 (SP4) vers SQL Server 2008 ou 2008 R2. Toutefois,
lorsque vous essayez d’exécuter l’utilitaire Sqlmaint (Sqlmaint.exe), vous recevez le message d’erreur suivant :
L’objet « Application » SQLDMO n’a pas réussi à s’initialiser (erreur spécifique : l’un des fichiers de
bibliothèque nécessaires pour exécuter cette application est inamorcable.)
NOTE
This issue also occurs in SQL Server 2012
Cause
Ce problème peut se produire si la version SQL Server Distributed Management Objects (SQL-DMO) installée
ne peut pas se connecter à une instance de SQL Server 2008 ou SQL Server 2008 R2.
Dans SQL Server 2012 ou une version ultérieure, SQL DMO est l’une des fonctionnalités abandonnées et les
clients sont invités à utiliser SQL Server Management Objects (SMO). Pour plus d’informations, voir
Discontinued Moteur de base de données Functionality in SQL Server 2012.
C AT ÉGO RIE F O N C T IO N N A L IT É A B A N DO N N ÉE REM P L A C EM EN T
Programmabilité SQL Server Distributed Management SQL Server Objets de gestion (SMO)
Objects (SQL-DMO)
Résolution
Méthode 1 : mettre à niveau les plans de maintenance au format SQL

Server 2008 ou SQL Server 2008 R2 (recommandé)
Cette méthode migre les plans de maintenance vers SQL Server format 2008. Si tous les anciens plans de
maintenance sont mis à niveau, la méthode 2 n’est pas requise.
Pour utiliser les SQL Server Management Studio mettre à niveau les plans de maintenance, suivez les étapes
suivantes :
1. Démarrez SQL Server Management Studio, puis connectez-vous à l’instance de SQL Server.
2. Dans l’Explorateur d’objets, développez Gestion, Développement hérité, puis Plans de maintenance de
base de données.
3. Cliquez avec le bouton droit sur chaque plan de maintenance à migrer, puis cliquez sur Migrer. Cette étape
crée un plan de maintenance non hérité au format SQL Server 2008.
4. Cliquez avec le bouton droit sur le dossier Plans de maintenance de base de données, puis cliquez sur
Actualiser pour mettre à jour les plans de maintenance dans le dossier Gestion.
Méthode 2 : installer la dernière SQL-DMO à partir du programme

SQL Server compatibilité ascendante
Cette méthode installe la dernière version de SQL-DMO pour permettre à l’ancien format de plan de
maintenance de continuer à fonctionner SQL Server 2008.
NOTE
Si vous n’avez plus de plans de maintenance dans l’ancien format, cette méthode n’est pas requise.
Pour exécuter l’SQL Server d’installation de compatibilité ascendante, suivez les étapes suivantes :
1. Recherchez le dossier source d’installation suivant pour SQL Server 2008 : drive :\Servers\Setup .
NOTE
L’espace réservé au lecteur est la lettre du lecteur de DVD.
2. Double-cliquez sur le fichier SQLSer ver2005_BC.ms i pour exécuter l’Assistant Installation SQL
Server compatibilité ascendante, puis cliquez sur Suivant.
3. Cliquez sur Modifier, puis sur Suivant.
4. Assurez-vous que la fonctionnalité SQL Objets de gestion distribuée (SQL-DMO) est définie pour être
installée sur le disque dur local, puis cliquez sur Suivant.
5. Cliquez sur Installer .
Références
Utilitaire sqlmaint
SQL Server Compatibilité ascendante
SQL Server Compatibilité ascendante
S’applique à
SQL Server Web 2008
Utilisez l’utilitaire Sqldumper.exe pour générer un
fichier de vidage dans SQL Server
Cet article fournit des instructions générales pour Sqldumper.exe utilitaire inclus dans SQL Server. Vous pouvez
utiliser cet utilitaire pour générer différents types de fichiers de vidage.
Server 2008, SQL Server 2005
Résumé
LSqldumper.exe'utilitaire est inclus dans Microsoft SQL Server. Cet article explique comment utiliser l’utilitaire
Sqldumper.exe pour générer un fichier de vidage pour le rapport d’erreurs Watson ou pour les tâches de
débogage.
NOTE
Outre l’utilitaire Sqldumper.exe, les méthodes suivantes sont également disponibles :
Vous pouvez utiliser la commande STACKDUMP DBCC pour générer un fichier de vidage dans SQL Server. Pour plus
d’informations, voir Comment utiliser DBCC STACKDUMP.
Vous pouvez également utiliser un script Powershell pour automatiser la ligne de commande SQLDumper.
WARNING
La génération de fichiers de vidage de processus peut affecter la disponibilité du service (ici SQL Server) et déclencher le
failover des ressources dans les contextes Always On (instance de cluster de failover et groupe de disponibilité). Les
options utilisées pour générer les fichiers de vidage feront une grande différence. Veillez à lire les sections Impact de la
génération des vidages et des types de vidage.
Lorsque vous capturez un fichier de vidage de processus SQL Server (en particulier un fichier de vidage filtré ou
un fichier de vidage complet) sur un SQL Server en cluster ou un SQL Server hébergeant une instance de
groupe de disponibilité AlwaysOn (AG), le SQL Server en cluster ou ag peut faire échouer vers un autre nœud si
le fichier de vidage prend trop de temps. Pour éviter un éventuel changement, vous pouvez utiliser les
paramètres suivants avant de capturer le fichier de vidage, et vous pouvez revenir à la modification après avoir
pris un fichier de vidage :
Pour les SQL Server cluster, cliquez avec le bouton droit sur SQL Server ressource dans l’administrateur de
cluster, sélectionnez « En cas d’échec de la ressource, ne pas redémarrer » sous l’onglet Stratégies.
Pour ag ag, appliquez tous les paramètres suivants :
Augmentez le délai d’ouverture de session, par exemple, 120 secondes pour tous les réplicas. Dans
SQL Server Management Studio, cliquez avec le bouton droit sur le réplica à configurer, puis
sélectionnez Propriétés. Modifiez Session-Timeout champ (secondes) à 120 secondes. Pour plus
d’informations, voir Modifier la Session-Timeout période de disponibilité d’un réplica de disponibilité
(SQL Server).
Modifiez le failover automatique de tous les réplicas en un failover manuel. Dans SQL Server
Management Studio, cliquez avec le bouton droit sur le réplica, sélectionnez Propriétés, puis modifiez
le « failover automatique » de tous les réplicas pour le faire manuellement sous l’onglet Propriétés.
Pour plus d’informations, voir Change the Failover Mode of an Availability Replica (SQL Server).
Augmentez la période jusqu’à LeaseTimeout 60 000 ms (60 secondes) et changez-la à
HealthCheckTimeout 90 000 ms (90 secondes). Dans l’Administrateur de cluster, cliquez avec le bouton
droit sur la ressource AG, sélectionnez Propriétés, puis basculez vers l’onglet Propriétés pour modifier
les deux paramètres. Pour plus d’informations, voir Configure HealthCheckTimeout Property
Paramètres.
Comment exécuter l’utilitaire Sqldumper.exe manuellement

Exécutez Sqldumper.exe utilitaire dans le contexte du dossier dans lequel SQL Server l’utilitaire a été installé à
l’origine. Par défaut, le chemin d’installation de l’utilitaire Sqldumper.exe est le suivant :
SQLServerInstallDrive:\Program Files\Microsoft SQL Server\90\Shared\SQLDumper.exe
NOTE
SQLServerInstallDrive est un espace réservé au lecteur sur lequel vous avez installé SQL Server 2005.
Pour générer un fichier de vidage à l’aide Sqldumper.exe'utilitaire, suivez les étapes suivantes :
1. Ouvrez le dossier suivant :
SQLServerInstallDrive:\Program Files\Microsoft SQL Server\number\Shared
NOTE
Dans ce chemin d’accès de dossier, le numéro est un espace réservé pour l’un des dossiers suivants :
140 pour SQL Server 2017
2. Assurez-vous que le Dbghelp.dll se trouve dans ce dossier.

3. Sélectionnez Démarrer, Sélectionnez Exécuter, tapez cmd, puis sélectionnez OK.
4. À l'invite de commandes, tapez la commande suivante, puis appuyez sur Entrée :
cd SQLServerInstallDrive:\Program Files\Microsoft SQL Server\number\Shared
NOTE
Dans ce chemin d’accès de dossier, le même espace réservé change avec la version SQL Server comme décrit
number précédemment.
5. Pour générer un type spécifique de fichier de vidage, tapez la commande correspondante à l’invite de
commandes, puis appuyez sur Entrée :
Fichier de vidage complet
Sqldumper.exe ProcessID 0 0x01100
Fichier de mini-vidage
Fichier de mini-vidage qui inclut la mémoire référencé indirectement. Il s’agit de l’option

recommandée et est également utilisée par SQL Server par défaut lors de la génération
automatique de vidages mémoire
Fichier de vidage filtré
NOTE
ProcessID est un espace réservé pour l’identificateur de processus de l’application Windows pour laquelle vous
souhaitez générer un fichier de vidage.
Si lSqldumper.exe'utilitaire s’exécute correctement, l’utilitaire génère un fichier de vidage dans le dossier où

l’utilitaire est installé.
Le fichier de vidage généré par Sqldumper.exe'utilitaire a un modèle de nom de fichier semblable à ce qui suit :
SQLDmpr xxxx .mdmp
Dans ce modèle, xxxx est un nombre croissant qui est déterminé en fonction d’autres fichiers dont le nom de
fichier est similaire dans le même dossier. Si vous avez déjà des fichiers dans le dossier qui ont des noms de
fichiers dans le modèle spécifié, vous de devez peut-être comparer la date et l’heure de création du fichier pour
identifier le fichier que vous souhaitez.
Informations et considérations supplémentaires

SQLDumper.exe existe principalement pour générer des vidages de mémoire pour le processus SQL Server dans
les scénarios où un vidage de mémoire est nécessaire pour résoudre des problèmes spécifiques (exceptions,
affirmations, scheduleurs sans rapport de rendement, etc.). Dans ce cas, SQL Server appelle le SQLDumper.exe
pour générer un vidage mémoire de son processus. Le vidage mémoire est stocké dans un chemin configuré
dans le Gestionnaire de configuration SQL Server avec un répertoire d’emplacements MSSQL\LOG\ par défaut. Si,
dans certains cas, la taille du vidage est trop importante, par exemple, vous pouvez modifier le chemin d’accès
en faisant ce qui suit :
1. Ouvrez Gestionnaire de configuration SQL Ser ver
2. Sous SQL Ser ver ser vices localisez le SQL Server en cours d’examen
3. Cliquez dessus avec le bouton droit, sélectionnez Propriétés et sélectionnez l’onglet Avancé
4. Modifiez ce répertoire de vidage sur le chemin d’accès souhaité et sélectionnez OK
5. Redémarrez SQL Server (dans la mesure du possible) pour que le nouveau paramètre prenne effet.
Lorsque l’utilitaire Sqldumper.exe est utilisé manuellement pour générer un fichier de vidage pour n’importe
quelle application Windows, le fichier de vidage peut être aussi grand que la mémoire que l’application
Windows utilise actuellement. Assurez-vous que l’espace disque disponible est suffisant sur le lecteur sur lequel
l’utilitaire Sqldumper.exe écrit le fichier de vidage.
Vous pouvez spécifier le répertoire dans lequel vous souhaitez que l’utilitaire Sqldumper.exe écrive le fichier de
vidage. Le répertoire doit déjà exister avant d’exécuter l’utilitaire Sqldumper.exe'annuaire. Sinon,
l'Sqldumper.exe'utilitaire échoue. N’utilisez pas de chemin UNC comme emplacement pour le fichier de vidage.
Voici un exemple de la façon de spécifier l’emplacement du fichier de vidage du fichier de mini-vidage :
2. À l'invite de commandes, tapez la commande suivante, puis appuyez sur Entrée :
cd **SQLServerInstallDrive** :\Program Files\Microsoft SQL Server\number\Shared
3. Tapez la commande suivante à l’invite de commandes, puis appuyez sur Entrée :
Sqldumper.exe ProcessID 0 0x0128 0 MdumpPath
NOTE
MdumpPath est un espace réservé pour le répertoire dans lequel vous souhaitez que l’utilitaire Sqldumper.exe
écrive le fichier de vidage. Par défaut, le fichier est écrit dans le dossier actuel.
Si vous spécifiez un fichier de vidage complet ou un fichier de vidage filtré à générer, l’utilitaire Sqldumper.exe
peut prendre plusieurs minutes pour générer le fichier de vidage. L’heure dépend des variables suivantes :
Quantité de mémoire que l’utilitaire Sqldumper.exe utilise actuellement
Vitesse du lecteur sur lequel l’utilitaire écrit le fichier de vidage
Pendant ce temps, l’utilitaire Sqldumper.exe ne traitera pas les commandes. Vous remarquerez que le serveur a
cessé de répondre. En outre, un échec de cluster peut se produire.
Pour exécuter l’utilitaire Sqldumper.exe, vous devez vous connecter à Windows à l’aide de l’une des méthodes
suivantes :
Utilisez un compte membre du groupe de l’administrateur sur l’ordinateur.
Utilisez le même compte d’utilisateur sous lequel le service SQL Server’exécution.
Pour que l’utilitaire Sqldumper.exe fonctionne correctement via le Bureau à distance ou les services Terminal
Services, vous devez démarrer les services Bureau à distance ou Terminal Services en mode console. Par
exemple, pour démarrer Le Bureau à distance en mode console, sélectionnez Démarrer, Exécuter, tapez
mstsc /console, puis sélectionnez OK . Si le serveur cible s’Windows 2000, l’option /console est ignorée
silencieusement. Vous pouvez vous connecter au serveur via le Bureau à distance. Mais vous n’utiliserez pas la
session console.
Si vous remarquez qu’aucun fichier de vidage n’a été généré dans le dossier actuel après avoir exécuté l’utilitaire
Sqldumper.exe, examinez les informations générées par l’utilitaire sur la ligne de commande pour déterminer la
cause possible de l’échec. Ces informations sont également consignées dans le fichier Sqldumper_errorlog.log
dans le répertoire actuel. Voici deux messages d’erreur possibles et leurs causes :
Message 1
Échec de l'0x57 OpenProcess : le paramètre est incorrect
Un ID de processus non valide a été transmis à lSqldumper.exe utilitaire.

Message 2
Valeur non valide pour l’ID de thread - <invalid parameter> Erreur de paramètre
Un paramètre non valide a été transmis à l’utilitaire Sqldumper.exe de données.

Si un message d’erreur semblable à l’un des messages suivants est généré, vous pouvez ignorer ce message en
toute sécurité :
Type de rappel inconnu pendant la minidump 6

Type de rappel inconnu pendant la minidump 7
Impact de la génération du vidage

Lorsqu’un vidage d’un processus en mode utilisateur est demandé (comme décrit dans cet article, pour être
contrasté avec les vidages du noyau du système d’exploitation, qui sont en dehors de notre étendue), le
processus cible (ici SQLServer.exe) est figé pendant la durée nécessaire pour sérialiser le contenu du vidage sur
sa cible de fichier.
Figé signifie qu’il ne sera pas en mesure de traiter une demande utilisateur ou de faire avancer une opération
interne, y compris un mécanisme d’interrogation des ressources tel que l’implémentation de l’isalive de
clustering Windows et Looks Alive (voir la section « Cluster failovers and the Sqldumper.exe utility » pour plus
d’informations sur la gestion de cette situation). Tout délai d’horloge s’appuyant sur l’horloge du mur peut
également être enfreint en raison du blocage.
Comme peut être dérivé de l’instruction précédente, la durée du blocage est donc le facteur essentiel ici et est
pilotée par les éléments suivants :
Type de vidage sélectionné
La taille du SQL Ser ver en mémoire, qui, dans le cas d’une instance active unique exécutant des
paramètres par défaut, est souvent proche de la mémoire RAM physique totale du ser veur.
Performances du disque utilisé comme cible pour le vidage.
En outre, la taille du fichier de vidage sur disque doit être planifiée, en particulier si plusieurs vidages sont
possibles et si des types de vidage non par défaut importants sont sélectionnés. Veillez à consulter la section «
Types de vidage » pour savoir à quoi s’attendre. Par défaut, certaines méthodes de vidage créent le vidage dans
le dossier \Log de l’instance de SQL Server, qui, dans la configuration simple par défaut, serait également disque
système et disque de données+journal pour SQL Server. La saturation de ce disque aura un impact considérable
sur la SQL Server et/ou la disponibilité du système.
Trois améliorations majeures ont été ajoutées aux versions récentes de SQL Server pour réduire la taille du
fichier de vidage et/ou le temps de génération du vidage mémoire :
Mécanisme de filtrage des bitmaps
Élimination des vidages répétés sur le même problème
Sortie raccourcie dans le rapport d’erreurs
SQL Server alloue une bitmap qui conserve le suivi des pages mémoire à exclure d’un vidage filtré.
Sqldumper.exe lit l’bitmap et filtre les pages sans avoir à lire d’autres métadonnées du gestionnaire de mémoire.
Vous verrez les messages suivants dans le journal des erreurs SQL Server lorsque l’bitmap est activée ou
désactivée respectivement : Page exclusion bitmap is enabled. et Page exclusion bitmap is disabled.
SQL Server 2016
À partir SQL Server 2016 SP2 CU13, le filtrage des bitmaps est activé par défaut.
SQL Server 2017
Cela n’est pas disponible dans rtm à CU15.
Dans SQL Server CU16 2017, vous pouvez activer le filtrage des bitmaps via T8089 et le désactiver en
désactivant T8089.
À partir SQL Server CU20 2017, le filtrage des bitmaps est activé par défaut. L’indicateur de suivi
T8089 ne s’applique plus et est ignoré s’il est allumé. Le filtrage bitmap peut être désactivé via T8095.
SQL Server 2019
Cette option est activée par défaut dans SQL Server 2019 RTM. Il peut être désactivé via T8095.
Élimination des vidages répétés sur le même problème : les vidages mémoire répétés sur le même problème
sont désormais éliminés. À l’aide d’une signature de pile, le moteur SQL suit si une exception s’est déjà produite
et ne produit pas de nouveau vidage mémoire s’il en existe déjà un. Cela s’applique aux violations d’accès, au
dépassement de la pile, aux affirmations et aux exceptions de corruption d’index. Cela réduit considérablement
la quantité d’espace disque utilisée par les vidages mémoire et ne fige pas temporairement le processus pour
générer un vidage. Cette valeur a été ajoutée SQL Server 2019.
Sortie raccourcie dans le journal des erreurs : le contenu généré dans le journal d’erreurs SQL Server à partir
d’un vidage mémoire unique ne peut pas seulement être écrasant, mais il a également ralenti le processus de
génération d’un vidage mémoire en raison du temps que toutes ces informations ont dû être sérialisées dans un
format de texte dans le journal des erreurs. Dans SQL Server 2019, le contenu stocké dans le journal des erreurs
lors de la génération du vidage a été considérablement réduit et il peut ressembler à ceci :
DateTimespidS pid **Dump thread - spid = 0, EC = 0x0000015C7169BF40

DateTimespidS pid *
DateTimespidS pid *User initiated stack dump. This is not a server exception dump.
DateTimespidS pid *
DateTimespidS pid Stack Signature for the dump is 0x00000000788399E5
DateTimespidS pid External dump process return code 0x20000001.
External dump process returned no errors.
Auparavant SQL Server imprimerait les informations de chaque session/thread lorsqu’un vidage manuel était
déclenché par l’utilisateur, par exemple.
Types de vidage
Les méthodes décrites peuvent générer trois types différents de vidages : les mini-vidages, les vidages complets
et les vidages filtrés.
Les mini-vidages avec mémoire référencé sont un instantané de tous les threads actifs du processus (« piles de
threads »), ainsi qu’un extrait limité de la mémoire référencé par les piles de threads et d’autres données de
processus/thread clés. Ils ont généralement une taille de quelques mégaoctets et sont rapides à générer (de
moins d’une seconde à quelques secondes). Les systèmes serveur encore plus volumineux (avec des centaines
de processeurs indirectement à l’avant-plan du nombre de threads dans le processus SQL Server) dépassent
rarement 20 à 30 Mo : la taille d’un mini-vidage n’augmente pas avec la taille du processus SQL Server. Ce type
de vidage est le type par défaut utilisé par les SQL Server lors de la génération automatique de vidages de
mémoire sur des exceptions, des problèmes de planification, des problèmes de verrou, etc.
NOTE
SQL Server, dans le cadre de son instrumentation intégrée, génère des « mini-vidages de diagnostic » automatisés dans
certaines situations spécifiques. Cette opération est donc considérée comme suffisamment sûre pour SQL Server peut la
déclencher automatiquement si nécessaire.
Les vidages complets sont une copie complète de l’espace de processus cible actif. Cela inclut donc tout l’état du
thread, tous les processus alloués à la mémoire et tous les modules chargés. Les vidages complets auront donc
une taille, qui est à peu près identique à SQL Server processus, qui à son tour peut être presque aussi grande
que la RAM système totale . Sur des serveurs de grande taille dédiés à SQL Server instance unique, cela peut
signifier un fichier, c’est-à-dire plusieurs centaines de gigaoctets ou plus. Inutile de le dire, un tel fichier prendra
beaucoup de temps à générer et provoquera donc un blocage prolongé. Les performances du disque pour la
cible de fichier du vidage seront un facteur majeur pour le temps de blocage. Ce type de vidage est rarement
utilisé pour SQL Server d’aujourd’hui**, comme la description du type suivant l’explique.
Vidages filtrés : à mesure que la taille de RAM des serveurs classiques exécutant SQL Server a augmenté de
façon constante, les vidages complets sont devenus de plus en plus difficile à gérer. Les vidages filtrés ont donc
été implémentés : il s’agit d’un sous-ensemble de vidages complets, où de grandes zones de structures de
mémoire se rapportant à SQL Server sont délibérément ignorées et non sérialisées sur disque, car elles
n’apportent aucune valeur ajoutée de dépannage (généralement, les pages de données/d’index, certains caches
internes tels que les pages de données Hekaton et la mémoire du pool de journaux). Cela entraîne un fichier, qui
est plus petit qu’un vidage complet tout en conservant presque toute son utilité, et cela a remplacé les vidages
complets comme option préférée dans une grande majorité de situations où les mini-vidages n’étaient pas
suffisants. La réduction de la taille par rapport au vidage complet peut varier considérablement, mais il s’agit
toujours d’un fichier assez grand, qui est souvent de 30 à 60 % de la taille de processus de SQL Server, il est
donc préférable de planifier une taille possible aussi grande qu’un vidage complet comme une pire option, ce
qui devrait laisser une bonne marge de sécurité. Un vidage filtré n’est peut-être pas nécessairement plus rapide
à générer qu’un vidage complet dans tous les cas : il s’agit de savoir si les gains liés au nombre d’E/S évités
dépassent le temps nécessaire à l’implémentation de la logique de filtre (donc la vitesse du disque et la vitesse
du processeur et de la RAM influenceront cette situation).
Vous pouvez utiliser l’utilitaire Sqldumper.exe pour générer un fichier de vidage à la demande pour n’importe
quelle application Microsoft Windows. Par exemple, vous pouvez générer un fichier de vidage pour le débogage
d’un problème d’application lorsqu’un ordinateur qui exécute Microsoft SQL Server ne répond pas aux
demandes des utilisateurs. Un fichier de vidage peut être un fichier de mini-vidage ou un fichier de vidage
complet. Un fichier de vidage filtré n’est applicable et significatif que dans le contexte SQL Server.
Le SQL Server appelle l’utilitaire Sqldumper.exe en interne pour générer un fichier de vidage lorsque le
processus subit des exceptions. SQL Server passe des indicateurs à l’utilitaire Sqldumper.exe'outil. Vous pouvez
utiliser des indicateurs de suivi pour modifier les indicateurs que SQL Server passe à l’utilitaire dans le contexte
d’une exception ou dans le contexte d’une assertion. Ces indicateurs de suivi sont dans la plage de 2540 à 2559.
Vous pouvez utiliser ces indicateurs de suivi pour générer certains types de fichiers de vidage. Par exemple :
Indicateur de suivi 2551 : produit un vidage de mémoire filtré.
Indicateur de suivi 2544 : produit un vidage mémoire complet.
Indicateur de suivi 8026 : SQL Server un déclencheur de vidage après avoir généré le vidage une seule fois.
Si au moins deux indicateurs de suivi sont actifs, l’option indiquant le vidage mémoire le plus important est
honorée. Par exemple, si les indicateurs de suivi 2551 et 2544 sont utilisés, SQL Server créera un vidage
mémoire complet.
Comment obtenir un identificateur de processus Windows’application Microsoft
Pour générer un fichier de vidage à l’aide de l’utilitaire Sqldumper.exe, vous devez avoir l’identificateur de
processus de l’application Windows pour laquelle vous souhaitez générer un fichier de vidage. Pour obtenir
l’identificateur de processus, suivez les étapes suivantes :
1. Appuyez sur Ctrl+ALT+DELETE, puis sélectionnez Gestionnaire des tâches.
2. Dans la boîte Windows de dialogue Gestionnaire des tâches, sélectionnez l’onglet Processus.
3. Dans le menu Affichage, sélectionnez Sélectionner des colonnes.
4. Dans la boîte de dialogue Sélectionner des colonnes, cochez la case PID (identificateur de processus),
puis sélectionnez OK.
5. Notez l’identificateur de processus Windows’application pour laquelle vous souhaitez générer un fichier de
vidage. Pour l’SQL Server application, notez l’identificateur de processus du Sqlservr.exe processus.
6. Fermez le Gestionnaire des tâches.
Vous pouvez également obtenir l’identificateur de processus de l’application SQL Server qui s’exécute sur votre
ordinateur à l’aide du SQL Server journal des erreurs. Par exemple, une partie du fichier journal SQL
Server’erreurs est semblable à ce qui suit :
Date/Time Server Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)

Date/Heure
Copyright (c) 1988-2005 Microsoft Corporation
Êdition Entreprise sur Windows NT 5.2 (build 3790 : Service Pack 1)
Date/Time Server (c) 2005 Microsoft Corporation.

Date/Time Server Tous droits réservés.
L’ID de processus du serveur de date/heure est 3716.
Le nombre qui apparaît après l’ID de processus serveur est l’identificateur de processus pour Sqlservr.exe
processus.
Les failovers de cluster et l’utilitaire Sqldumper.exe de cluster
Dans les scénarios de SQL Server de cluster, la DLL de la ressource SQL Server peut désormais obtenir un fichier
de vidage avant que le failover ne se produise. Lorsque la DLL de ressource SQL Server détermine qu’une
ressource SQL Server a échoué, la DLL de ressource SQL Server utilise l’utilitaire Sqldumper.exe pour obtenir un
fichier de vidage du processus SQL Server. Pour vous assurer que l’utilitaire Sqldumper.exe génère correctement
le fichier de vidage, vous devez définir les trois propriétés suivantes comme conditions préalables :
SqlDumperDumpTimeOut A user-specified time-out. La DLL de ressource attend que le fichier de vidage soit
terminé avant que la DLL de ressource arrête SQL Server service.
SqlDumperDumpPath
Emplacement où l’utilitaire Sqldumper.exe génère le fichier de vidage.
SqlDumperDumpFlags
Indicateurs que l’utilitaire Sqldumper.exe utilise.
Si l’une des propriétés n’est pas définie, l’utilitaire Sqldumper.exe ne peut pas générer le fichier de vidage. Un
message d’avertissement est consigné à la fois dans le journal des événements et dans le journal du cluster
chaque fois que la ressource est mise en ligne.
Pour SQL Server 2012 et ultérieures
Vous pouvez utiliser la commande ALTER SERVER CONFIGURATION (T-SQL) pour modifier ces propriétés. Par
exemple :
ALTER SERVER CONFIGURATION set FAILOVER CLUSTER PROPERTY SqlDumperDumpTimeOut =0;

ALTER SERVER CONFIGURATION set FAILOVER CLUSTER PROPERTY SqlDumperDumpPath ='C:\temp\';
ALTER SERVER CONFIGURATION set FAILOVER CLUSTER PROPERTY SqlDumperDumpFlags =296;
Vous pouvez également utiliser des scripts PowerShell. Par exemple, pour une instance nommée SQL2017AG :
Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Set-ClusterParameter -Name "SqlDumperDumpPath" -Value
"C:\temp"
Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Set-ClusterParameter -Name "SqlDumperDumpFlags" -Value
296
Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Set-ClusterParameter -Name "SqlDumperDumpTimeOut" -
Value 0
Pour valider que les paramètres ont été appliqués, vous pouvez exécuter cette commande PowerShell :
Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Get-ClusterParameter
Pour SQL Server 2008/2008 R2 ou Windows 2012 et les Windows antérieures

Pour définir les propriétés Sqldumper.exe utilitaire de cluster pour le cluster, suivez les étapes suivantes :
2. Pour chaque propriété, tapez la commande correspondante à l’invite de commandes, puis appuyez sur Entrée
:
Propriété Pour définir la propriété d’un type spécifique de fichier de vidage, tapez la commande
correspondante à l’invite de commandes, puis appuyez SqlDumperDumpFlags SqlDumperDumpFlags
sur Entrée :
Fichier de vidage complet de tous les threads
Instance par défaut
cluster resource "SQL Server" /priv SqlDumperDumpFlags = 0x01100
Instance nommée
cluster resource "SQL Server (INSTANCE1)" /priv SqlDumperDumpFlags = 0x01100
Fichier de mini-vidage de tous les threads

Instance nommée
Filtrage de tous les fichiers de vidage de thread

Instance nommée
La SqlDumperDumpPath propriété
cluster resource "SQL Server" /priv SqlDumperDumpPath= DirectoryPath
NOTE
DirectoryPath est un espace réservé pour le répertoire dans lequel le fichier de vidage sera généré et
doit être spécifié entre guillemets ( » « ).
Propriété SqlDumperDumpTimeOut
cluster resource "SQL Server" /priv SqlDumperDumpTimeOut= Timeout
NOTE
Le délai est un espace réservé pour le délai d’délai en millisecondes (ms).
Le temps nécessaire à l’utilitaire pour générer un fichier de vidage d’un processus SQL Server de données
dépend de la configuration de l’ordinateur. Pour un ordinateur qui a beaucoup de mémoire, le temps peut être
important. Pour obtenir une estimation du temps nécessaire au processus, utilisez l’utilitaire Sqldumper.exe pour
générer manuellement un fichier de vidage. Les valeurs valides pour la propriété SqlDumperDumpTimeOut
sont de 10 000 ms à MAXDWORD. MAXDWORD représente la valeur la plus élevée dans la plage du type
de données DWORD (4294967295).
Pour vérifier que les paramètres ont été activés, vous pouvez exécuter la commande suivante :
cluster resource "SQL Server" /priv "
Pour supprimer les propriétés Sqldumper.exe utilitaire de cluster pour le cluster, suivez les étapes suivantes :
2. Pour une propriété spécifique, tapez la commande correspondante à l’invite de commandes, puis
appuyez sur Entrée :
La SqlDumperDumpFlags propriété
cluster resource "SQL Server" /priv:SqlDumperDumpFlags /usedefault
Instance nommée
cluster resource "SQL Server (INSTANCE1)" /priv:SqlDumperDumpFlags /usedefault
La SqlDumperDumpPath propriété
cluster resource "SQL Server" /priv:SqlDumperDumpPath /usedefault
Instance nommée
cluster resource "SQL Server (INSTANCE1)" /priv:SqlDumperDumpPath /usedefault
La SqlDumperDumpTimeOut propriété
cluster resource "SQL Server" /priv:SqlDumperDumpTimeOut /usedefault
Instance nommée
cluster resource "SQL Server (INSTANCE1)" /priv:SqlDumperDumpTimeOut /usedefault
Utilisation du DBCC STACKDUMP

La commande peut vous aider à créer un vidage mémoire dans le répertoire LOG de DBCC STACKDUMP votre
installation SQL Server’instance. La commande crée par défaut un minidump avec tous les threads, dont la taille
est limitée et qui est adéquate pour refléter l’état SQL Server processus. Exécutez simplement la commande
suivante dans un client SQL Server client :
DBCC STACKDUMP
Pour obtenir des fonctionnalités étendues du DBCC STACKDUMP SQL Server 2019, consultez cette section.
Pour activer cette méthode afin de créer un vidage filtré, activez les indicateurs de suivi 2551 avec la commande
suivante :
dbcc traceon(2551, -1)

go
dbcc stackdump
Pour créer un vidage complet, utilisez l’indicateur de suivi 2544.
NOTE
Une fois que vous avez le fichier de vidage, vous devez désactiver l’indicateur de suivi à l’aide de la commande suivante
pour éviter par inadvertance la mise à niveau de tous les minidumps auto-diagnostic SQL Server supplémentaires vers
des vidages plus volumineux :
DBCC TRACEOFF (TraceNumber, -1);
Où TraceNumber se trouve l’indicateur de suivi que vous avez précédemment activé comme 2551 ou 2544.
Si vous ne savez pas quel indicateur de suivi reste actif, vous pouvez exécuter les opérations ci-après :
DBCC TRACESTATUS(-1)
Un jeu de résultats vide indique qu’aucun indicateur de suivi n’est actif. À l’inverse, si 2551 est toujours actif,
vous verrez :
T RA C EF L A G ÉTAT GLO B A L SESSIO N
2551 1 1 0
NOTE
Les traceflag éléments activés par DBCC TRACEON sont réinitialisés (supprimés) après un redémarrage du service.
Fonctionnalité STACKDUMP DBCC étendue introduite dans SQL Server 2019

À partir de SQL Server 2019 CU2, la commande STACKDUMP du DBCC a été étendue pour prendre en charge la
génération de vidages de différents types : mini, filtrés, vidages complets, ce qui élimine la nécessité d’utiliser
des indicateurs de suivi. Il vous permet également de limiter la sortie de texte dans le fichier texte
supplémentaire généré avec le vidage mémoire. Cela peut offrir un gain de performances visible en temps
SQLDumper.exe pour générer un vidage mémoire.
DBCC STACKDUMP WITH MINI_DUMP | FILTERED_DUMP | FULL_DUMP [, TEXT_DUMP = LIMITED | DETAILED]
Il TEXT_DUMP = LIMITED s’agit de l’option par défaut. Si vous souhaitez recevoir une sortie détaillée dans le fichier
SQLDump000X.txt que vous pouvez TEXT_DUMP = DETAILED utiliser.
Pour générer un vidage filtré avec une sortie limitée dans le fichier .txt, vous pouvez exécuter la commande
suivante :
DBCC STACKDUMP WITH FILTERED_DUMP , TEXT_DUMP = LIMITED
Comment utiliser un script PowerShell pour générer un fichier de vidage avec SQLDumper
Enregistrez le code suivant en tant que fichier ps1, par exempleSQLDumpHelper.ps1:
Détails du code
$isInt = $false
$isIntValDcnt = $false
$isIntValDelay = $false
$SqlPidInt = 0
$NumFoler =""
$OneThruFour = ""
$SqlDumpTypeSelection = ""
$SSASDumpTypeSelection = ""
$SSISDumpTypeSelection = ""
$SQLNumfolder=0
$SQLDumperDir=""
$OutputFolder=""
$DumpType ="0x0120"
$ValidPid
$SharedFolderFound=$false
$YesNo =""
$ProductNumber=""
$ProductStr = ""
Write-Host ""
Write-Host "`**********************************************************************"
Write-Host "This script helps you generate one or more SQL Server memory dumps"
Write-Host "It presents you with choices on:`
-target SQL Server process (if more than one)
-type of memory dump
-count and time interval (if multiple memory dumps)
You can interrupt this script using CTRL+C"
Write-Host "***********************************************************************"
#check for administrator rights

#debugging tools like SQLDumper.exe require Admin privileges to generate a memory dump
if (-not ([Security.Principal.WindowsPrincipal]
[Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]:
:Administrator))
{
Write-Warning "Administrator rights are required to generate a memory dump!`nPlease re-run this
script as an Administrator!"
#break
}
#what product would you like to generate a memory dump

while(($ProductNumber -ne "1") -and ($ProductNumber -ne "2") -and ($ProductNumber -ne "3") -and
($ProductNumber -ne "4") -and ($ProductNumber -ne "5"))
{
Write-Host "Which product would you like to generate a memory dump of?" -ForegroundColor Yellow
Write-Host "1) SQL Server"
Write-Host "2) SSAS (Analysis Services)"
Write-Host "3) SSIS (Integration Services)"
Write-Host "4) SSRS (Reporting Services)"
Write-Host "5) SQL Server Agent"
Write-Host ""
$ProductNumber = Read-Host "Enter 1-5>"
if (($ProductNumber -ne "1") -and ($ProductNumber -ne "2") -and ($ProductNumber -ne "3") -and
($ProductNumber -ne "4")-and ($ProductNumber -ne "5"))
{
Write-Host ""
Write-Host "Please enter a valid number from list above!"
Write-Host ""
Start-Sleep -Milliseconds 300
}
}
if ($ProductNumber -eq "1")

{
$SqlTaskList = Tasklist /SVC /FI "imagename eq sqlservr*" /FO CSV | ConvertFrom-Csv
$ProductStr = "SQL Server"
}
elseif ($ProductNumber -eq "2")
{
$SqlTaskList = Tasklist /SVC /FI "imagename eq msmdsrv*" /FO CSV | ConvertFrom-Csv
$ProductStr = "SSAS (Analysis Services)"
}
{
$SqlTaskList = Tasklist /SVC /FI "imagename eq msdtssrvr*" /FO CSV | ConvertFrom-Csv
$ProductStr = "SSIS (Integration Services)"
}
{
$SqlTaskList = Tasklist /SVC /FI "imagename eq reportingservicesservice*" /FO CSV | ConvertFrom-
Csv
$ProductStr = "SSRS (Reporting Services)"
}
{
$SqlTaskList = Tasklist /SVC /FI "imagename eq sqlagent*" /FO CSV | ConvertFrom-Csv
$ProductStr = "SQL Server Agent"
}
if ($SqlTaskList.Count -eq 0)
{
Write-Host "There are curerntly no running instances of $ProductStr. Exiting..." -ForegroundColor
Green
break
}
#if multiple SQL Server instances, get the user to input PID for desired SQL Server
if ($SqlTaskList.Count -gt 1)
{
Write-Host "More than one $ProductStr instance found."
$SqlTaskList | Select-Object PID, "Image name", Services |Out-Host
#check input and make sure it is a valid integer

while(($isInt -eq $false) -or ($ValidPid -eq $false))
{
Write-Host "Please enter the PID for the desired SQL service from list above" -
ForegroundColor Yellow
$SqlPidStr = Read-Host ">"
try{
$SqlPidInt = [convert]::ToInt32($SqlPidStr)
$isInt = $true
}
catch [FormatException]
{
Write-Host "The value entered for PID '",$SqlPidStr,"' is not an integer"
}
#validate this PID is in the list discovered

for($i=0;$i -lt $SqlTaskList.Count;$i++)
{
if($SqlPidInt -eq [int]$SqlTaskList.PID[$i])
{
$ValidPid = $true
break;
}
else
{
$ValidPid = $false
}
}
}
Write-Host "Using PID=$SqlPidInt for generating a $ProductStr memory dump" -ForegroundColor Green
Write-Host ""
}
else #if only one SQL Server/SSAS on the box, go here
{
$SqlTaskList | Select-Object PID, "Image name", Services |Out-Host
$SqlPidInt = [convert]::ToInt32($SqlTaskList.PID)
Write-Host "Using PID=", $SqlPidInt, " for generating a $ProductStr memory dump" -ForegroundColor
Green
Write-Host ""
}
#dump type
if ($ProductNumber -eq "1") #SQL Server memory dump

{
#ask what type of SQL Server memory dump
while(($SqlDumpTypeSelection -ne "1") -and ($SqlDumpTypeSelection -ne "2") -And
($SqlDumpTypeSelection -ne "3") -And ($SqlDumpTypeSelection -ne "4" ))
{
{
Write-Host "Which type of memory dump would you like to generate?" -ForegroundColor Yellow
Write-Host "1) Mini-dump"
Write-Host "2) Mini-dump with referenced memory " -NoNewLine; Write-Host "(Recommended)"
Write-Host "3) Filtered dump " -NoNewline; Write-Host "(Not Recommended)" -ForegroundColor
Red
Write-Host "4) Full dump " -NoNewline; Write-Host "(Do Not Use on Production systems!)" -
ForegroundColor Red
Write-Host ""
$SqlDumpTypeSelection = Read-Host "Enter 1-4>"
if (($SqlDumpTypeSelection -ne "1") -and ($SqlDumpTypeSelection -ne "2") -And

($SqlDumpTypeSelection -ne "3") -And ($SqlDumpTypeSelection -ne "4" ))
{
Write-Host ""
Write-Host "Please enter a valid type of memory dump!"
Write-Host ""
}
}
Write-Host ""
switch ($SqlDumpTypeSelection)
{
"1" {$DumpType="0x0120";break}
default {"0x0120"; break}
}
elseif ($ProductNumber -eq "2") #SSAS dump
{
#ask what type of SSAS memory dump

while(($SSASDumpTypeSelection -ne "1") -and ($SSASDumpTypeSelection -ne "2"))
{
Write-Host "2) Full dump " -NoNewline; Write-Host "(Do Not Use on Production systems!)" -
ForegroundColor Red
Write-Host ""
$SSASDumpTypeSelection = Read-Host "Enter 1-2>"
if (($SSASDumpTypeSelection -ne "1") -and ($SSASDumpTypeSelection -ne "2"))

{
Write-Host ""
Write-Host ""
}
}
Write-Host ""
switch ($SSASDumpTypeSelection)
{
}
}
elseif ($ProductNumber -eq "3" -or $ProductNumber -eq "4" -or $ProductNumber -eq "5") #SSIS/SSRS/SQL
Agent dump
{
{
#ask what type of SSIS memory dump

while(($SSISDumpTypeSelection -ne "1") -and ($SSISDumpTypeSelection -ne "2"))
{
Write-Host "2) Full dump"
Write-Host ""
$SSISDumpTypeSelection = Read-Host "Enter 1-2>"
if (($SSISDumpTypeSelection -ne "1") -and ($SSISDumpTypeSelection -ne "2"))

{
Write-Host ""
Write-Host ""
}
}
Write-Host ""
switch ($SSISDumpTypeSelection)
{
}
}
# Sqldumper.exe PID 0 0x0128 0 c:\temp

#output folder
while($OutputFolder -eq "" -or !(Test-Path -Path $OutputFolder))
{
Write-Host ""
Write-Host "Where would your like the memory dump stored (output folder)?" -ForegroundColor
Yellow
$OutputFolder = Read-Host "Enter an output folder with no quotes (e.g. C:\MyTempFolder or C:\My
Folder)"
if ($OutputFolder -eq "" -or !(Test-Path -Path $OutputFolder))
{
Write-Host "'" $OutputFolder "' is not a valid folder. Please, enter a valid folder location"
-ForegroundColor Yellow
}
}
#strip the last character of the Output folder if it is a backslash "\". Else Sqldumper.exe will fail
if ($OutputFolder.Substring($OutputFolder.Length-1) -eq "\")
{
$OutputFolder = $OutputFolder.Substring(0, $OutputFolder.Length-1)
Write-Host "Stripped the last '\' from output folder name. Now folder name is $OutputFolder"
}
#find the highest version of SQLDumper.exe on the machine

$NumFolder = dir "c:\Program Files\microsoft sql server\1*" | Select-Object @{name = "DirNameInt";
expression={[int]($_.Name)}}, Name, Mode | Where-Object Mode -Match "da*" | Sort-Object DirNameInt -
Descending
for($j=0;($j -lt $NumFolder.Count); $j++)

{
$SQLNumfolder = $NumFolder.DirNameInt[$j] #start with the highest value from sorted folder
names - latest version of dumper
$SQLDumperDir = "c:\Program Files\microsoft sql server\"+$SQLNumfolder.ToString()+"\Shared\"
$TestPathDumperDir = $SQLDumperDir+"sqldumper.exe"
$TestPathResult = Test-Path -Path $SQLDumperDir
if ($TestPathResult -eq $true)

{
break;
}
}
#build the SQLDumper.exe command e.g. (Sqldumper.exe 1096 0 0x0128 0 c:\temp\)
$cmd = "$([char]34)"+$SQLDumperDir + "sqldumper.exe$([char]34)"

$arglist = $SqlPidInt.ToString() + " 0 " +$DumpType +" 0 $([char]34)" + $OutputFolder + "$([char]34)"
Write-Host "Command for dump generation: ", $cmd, $arglist -ForegroundColor Green
#do-we-want-multiple-dumps section
Write-Host ""
Write-Host "This utility can generate multiple memory dumps, at a certain interval"
Write-Host "Would you like to collect multiple memory dumps (2 or more)?" -ForegroundColor Yellow
#validate Y/N input

while (($YesNo -ne "y") -and ($YesNo -ne "n"))
{
$YesNo = Read-Host "Enter Y or N>"
if (($YesNo -eq "y") -or ($YesNo -eq "n") )

{
break
}
else
{
Write-Host "Not a valid 'Y' or 'N' response"
}
}
#get input on how many dumps and at what interval

if ($YesNo -eq "y")
{
[int]$DumpCountInt=0
while(1 -ge $DumpCountInt)
{
Write-Host "How many dumps would you like to generate for this $ProductStr ?" -
$DumpCountStr = Read-Host ">"
try{
$DumpCountInt = [convert]::ToInt32($DumpCountStr)
if(1 -ge $DumpCountInt)

{
Write-Host "Please enter a number greater than one." -ForegroundColor Red
}
}
{
Write-Host "The value entered for dump count '",$DumpCountStr,"' is not an
integer" -ForegroundColor Red
}
}
[int]$DelayIntervalInt=0
while(0 -ge $DelayIntervalInt)
{
Write-Host "How frequently (in seconds) would you like to generate the memory dumps?" -
$DelayIntervalStr = Read-Host ">"
try{
try{
$DelayIntervalInt = [convert]::ToInt32($DelayIntervalStr)
if(0 -ge $DelayIntervalInt)

{
Write-Host "Please enter a number greater than zero." -ForegroundColor Red
}
}
{
Write-Host "The value entered for frequency (in seconds) '",$DelayIntervalStr,"'
is not an integer" -ForegroundColor Red
}
}
Write-Host "Generating $DumpCountInt memory dumps at a $DelayIntervalStr-second interval" -

ForegroundColor Green
#loop to generate multiple dumps

$cntr = 0
while($true)
{
Start-Process -FilePath $cmd -Wait -Verb runAs -ArgumentList $arglist
$cntr++
Write-Host "Generated $cntr memory dump(s)." -ForegroundColor Green
if ($cntr -ge $DumpCountInt)

{
break
}
Start-Sleep -S $DelayIntervalInt
}
#print what files exist in the output folder

Write-Host ""
Write-Host "Here are all the memory dumps in the output folder '$OutputFolder'" -ForegroundColor
Green
$MemoryDumps = $OutputFolder + "\SQLDmpr*"
Get-ChildItem -Path $MemoryDumps
Write-Host ""
Write-Host "Process complete"
}
else #produce just a single dump

{
Start-Process -FilePath $cmd -Wait -Verb runAs -ArgumentList $arglist
#print what files exist in the output folder

Write-Host ""
Write-Host "Here are all the memory dumps in the output folder '$OutputFolder'" -ForegroundColor
Green
$MemoryDumps = $OutputFolder + "\SQLDmpr*"
Get-ChildItem -Path $MemoryDumps
Write-Host ""
Write-Host "Process complete"
}
Write-Host "For errors and completion status, review SQLDUMPER_ERRORLOG.log created by SQLDumper.exe
in the output folder '$OutputFolder'. `Or if SQLDumper.exe failed look in the folder from which you
are running this script"```
Run it from Command Prompt as **** Administrator by using the following command:
Powershell.exe -File SQLDumpHelper.ps1
Ou exécutez-la à partir Windows PowerShell console et exécutez-la en tant qu’administrateur à l’aide de

la commande suivante :
.\SQLDumpHelper.ps1
NOTE
Si vous n’avez jamais exécuté de scripts PowerShell sur votre système, vous pouvez recevoir le message d’erreur : les
...SQLDumpHelper.ps1 de fichiers ne peuvent pas être chargés car l’exécution de scripts est désactivée sur ce système.
Vous devez activer la possibilité de les exécuter en suivant les étapes suivantes :
1. Démarrez Windows PowerShell console avec l’option Exécuter en tant qu’administrateur. Seuls les
membres du groupe Administrateurs sur l’ordinateur peuvent modifier la stratégie d’exécution.
2. Activez l’exécution de scripts non signés par la commande suivante :
Set-ExecutionPolicy RemoteSigned
NOTE
Cela vous permettra d’exécuter des scripts non signés que vous créez sur votre ordinateur local et des scripts
signés à partir d’Internet.
Utiliser l’utilitaire SQLIOSim pour simuler SQL
Server activité sur un sous-système de disque
Cet article explique comment utiliser l’utilitaire SQLIOSim pour effectuer des tests de contrainte sur des sous-
systèmes de disque afin de simuler SQL Server activité.
Résumé
Pour Microsoft SQL Server 2005, SQLIOSim a été livré en tant que package de téléchargement distinct. À partir
SQL Server 2008, SQLIOSim est inclus dans l’installation SQL Server produit. Lorsque vous installez SQL Server,
vous trouvez l’outil SQLIOSim dans le dossier BINN de votre installation SQL Server’installation. Il est
recommandé d’utiliser ces versions mises à jour de l’outil pour simuler l’activité d’O/S sur le sous-système de
disque.
L’utilitaire SQLIOSim remplace l’utilitaire SQLIOStress. L’utilitaire SQLIOStress était anciennement appelé
utilitaire SQL70IOStress.
Cet article contient également des informations de téléchargement pour l’utilitaire SQLIOSim.
Introduction
Cet article décrit l’outil SQLIOSim. Vous pouvez utiliser cet outil pour effectuer des tests de fiabilité et d’intégrité
sur des sous-systèmes de disque. Ces tests simulent les activités de lecture, d’écriture, de point de contrôle, de
sauvegarde, de tri et de lecture avant pour Microsoft SQL Server. Toutefois, si vous devez effectuer des tests de
référence et déterminer la capacité d’I/S du système de stockage, vous devez utiliser l’outil Diskspd.
Présentation
L’utilitaire SQLIOSim a été mis à niveau à partir de l’utilitaire SQLIOStress. L’utilitaire SQLIOSim simule plus
précisément les modèles d’Microsoft SQL Server.
Pour plus d’informations SQL Server des modèles d’SQL Server,voir le chapitre 2.
NOTE
Pour vous aider à maintenir l’intégrité et la sécurité des données appropriées, nous vous recommandons d’effectuer des
tests de contrainte de votre sous-système d’I/S avant de déployer SQL Server sur un nouveau matériel. L’utilitaire
SQLIOSim simule les modèles de lecture, les modèles d’écriture et les techniques d’identification des SQL Server. Pour
effectuer ces tâches, l’utilitaire SQLIOSim simule l’activité utilisateur et l’activité système d’SQL Server système. L’utilitaire
SQLIOSim effectue cette simulation indépendamment SQL Server moteur.
L’utilitaire SQLIOSim ne garantit ni ne justifie la sécurité ou l’intégrité des données. L’utilitaire a été conçu pour
fournir des tests de référence d’un environnement système. L’utilitaire SQLIOSim peut exposer des problèmes
potentiels d’intégrité des données.
Pour plus d’informations sur la journalisation et le stockage des données, voir Description des algorithmesde
journalisation et de stockage de données qui étendent la fiabilité des données dans SQL Server .
Le package de téléchargement contient deux fichiers exécutables, SQLIOSim.com et SQLIOSim.exe. Les deux
fichiers exécutables fournissent des fonctionnalités de simulation identiques. SQLIOSim.com est un outil en
ligne de commande que vous pouvez configurer pour s’exécuter sans intervention de l’utilisateur. Pour ce faire,
vous pouvez utiliser des paramètres de ligne de commande, un fichier de configuration ou une combinaison de
ces deux méthodes. SQLIOSim.exe est une application graphique qui n’accepte aucun paramètre de ligne de
commande. Toutefois, SQLIOSim.exe charge les données de configuration par défaut à partir des fichiers de
configuration.
SQLIOSim.com de ligne de commande

SQLIOSim.com accepte un nombre limité de paramètres de ligne de commande pour contrôler le
comportement de base. Le fichier de configuration de l’utilitaire SQLIOSim fournit un contrôle de
comportement avancé. Lorsque les paramètres de ligne de commande et les options de fichier de configuration
se chevauchent, les paramètres de ligne de commande prévalent.
PA RA M ET ER C O M M EN TA IRE
Fichier -cfg Remplacez le Sqliosim.cfg.ini de configuration par défaut.

L’utilitaire SQLIOSim renvoie une erreur si l’utilitaire ne peut
pas trouver le fichier.
-save file Enregistrez la configuration résultante dans le fichier de

configuration. Vous pouvez utiliser cette option pour créer le
fichier de configuration initial.
-log file Spécifiez le nom du fichier journal des erreurs et le chemin

d’accès au fichier journal des erreurs. Le nom de fichier par
défaut est Sqliosim.log.xml.
-dir dir Définissez l’emplacement pour créer le fichier de données

(.mdf) et le fichier journal (.ldf). Vous pouvez exécuter cette
commande plusieurs fois. Dans la plupart des cas, cet
emplacement est une racine de lecteur ou un point de
montage de volume. Cet emplacement peut être un chemin
long ou UNC.
-d secondes Définissez la durée de l’utilisation principale. Cette valeur

exclut la phase de préparation et la phase de vérification.
-size MB Définissez la taille initiale du fichier de données en

mégaoctets (Mo). Le fichier peut atteindre jusqu’à deux fois
la taille initiale. La taille du fichier journal est calculée comme
la moitié de la taille du fichier de données. Toutefois, le fichier
journal ne peut pas être supérieur à 50 Mo.
Fichier de configuration SQLIOSim

Des exemples de fichiers de configuration pour différents tests peuvent être téléchargés à partir SQL Server
référentiel github de l’équipe de support technique ici.
Vous n’avez pas besoin d’utiliser un fichier de configuration. Si vous n’utilisez pas de fichier de configuration,
tous les paramètres prennent des valeurs par défaut à l’exception de l’emplacement du fichier de données et de
l’emplacement du fichier journal. Vous devez utiliser l’une des méthodes suivantes pour spécifier l’emplacement
du fichier de données et l’emplacement du fichier journal :
Utilisez les paramètres de ligne de commande dans SQLIOSim.com fichier.
Utilisez la boîte de dialogue Fichiers et configuration après avoir exécuté SQLIOSim.exe fichier.
Utilisez la section Fichier x du fichier de configuration.
NOTE
Si le nom du paramètre indique que le paramètre est un ratio ou un pourcentage, la valeur du paramètre est exprimée
en tant que pourcentage ou ratio, divisé par 0,01. Par exemple, la valeur du paramètre CacheHitRatio est 10 pour
cent . Cette valeur est exprimée sous la valeur 1 000, car 10, divisé par 0,01, est égal à 1 000. La valeur maximale d’un
paramètre de pourcentage est 10 000 .
Si le type de paramètre est numérique et que vous affectez une valeur non numérique au paramètre, l’utilitaire
SQLIOSim définit le paramètre sur 0 .
Si le type de paramètre est , les valeurs valides que vous pouvez affecter au paramètre Boolean sont true et false . En
outre, les valeurs sont sensibles à la cas. L’utilitaire SQLIOSim ignore les valeurs non valides.
Si une paire de paramètres indique une valeur minimale et une valeur maximale, la valeur minimale ne doit pas être
supérieure à la valeur maximale. Par exemple, la valeur du paramètre ne doit MinIOChainLength pas être supérieure à
la valeur du MaxIOChainLength paramètre.
Si le paramètre indique un certain nombre de pages, l’utilitaire SQLIOSim vérifie la valeur que vous affectez au
paramètre par rapport au fichier que l’utilitaire SQLIOSim traite. L’utilitaire SQLIOSim effectue cette vérification pour
s’assurer que le nombre de pages ne dépasse pas la taille du fichier.
Section CONFIG
L’utilitaire SQLIOSim prend les valeurs que vous spécifiez dans la section CONFIG du fichier de configuration
SQLIOSim pour établir un comportement de test global.
PA RA M ÈT RE VA L EUR PA R DÉFA UT DESC RIP T IO N C O M M EN TA IRES
ErrorFile sqliosim.log.xml Nom du fichier journal de

type XML
CPUCount Nombre de processeurs sur Nombre de processeurs La valeur maximale est de

l’ordinateur logiques à créer 64 processeurs.
Affinité 0 Masque d’affinité Le masque d’affinité doit se

processeur physique à trouve dans le masque de
appliquer aux UC logiques processeur actif. Une valeur
de
0 signifie que toutes les
PROCESSEUR disponibles
seront utilisées.
MaxMemoryMB Mémoire physique Taille du pool de mémoires La valeur ne peut pas

disponible au démarrage de tampons en Mo dépasser la quantité totale
l’utilitaire SQLIOSim de mémoire physique sur
l’ordinateur.
StopOnError true Arrête la simulation lorsque

la première erreur se
produit
TestCycles 1 Nombre de cycles de test Une valeur de 0 indique un

complets à effectuer nombre infini de cycles de
test.
TestCycleDuration 300 Durée d’un cycle de test en

secondes, à l’exclusion de la
passe d’audit à la fin du
cycle
CacheHitRatio 1000 Taux d’hit du cache simulé

lorsque l’utilitaire SQLIOSim
lit à partir du disque
MaxOutstandingIO 0 Nombre maximal La valeur ne peut pas

d’opérations d’entreprise en dépasser 140 000. Une
suspens autorisées à valeur de 0 signifie que
l’échelle du processus jusqu’à environ 140 000
opérations d’entreprise sont
autorisées. Il s’agit de la
limite de l’utilitaire.
TargetIODuration 100 Durée des opérations Si la durée moyenne des

d’opérations d’entreprise, en opérations d’entreprise
millisecondes, ciblées par dépasse la durée
limitation d’opérations d’exploitation
cible, l’utilitaire SQLIOSim
limite le nombre
d’opérations d’entreprise en
attente afin de réduire la
charge et d’améliorer le
temps d’exécution des
opérations d’entreprise.
AllowIOBursts true Autoriser la non-publication Les rafales d’I/S sont

de nombreuses demandes activées lors de la mise à
d’I/S par la limitation jour initiale, du point de
contrôle initial et des points
de contrôle finals à la fin
des cycles de test. Le
paramètre
MaxOutstandingIO est
toujours honoré. Vous
pouvez vous attendre à de
longs avertissements d’I/S.
NoBuffering true Utiliser l’option SQL Server ouvre les

FILE_FLAG_NO_BUFFERING’ fichiers de base de données
option à l’aide
FILE_FLAG_NO_BUFFERING
== true. Certains utilitaires
et services, tels que Analysis
Services, utilisent
FILE_FLAG_NO_BUFFERING
== false. Pour tester
entièrement un serveur,
exécutez un test pour
chaque paramètre.
WriteThrough true Utiliser l’option SQL Server ouvre les

FILE_FLAG_WRITE_THROUG fichiers de base de données
H’option à
l’FILE_FLAG_WRITE_THROU
GH == true. Toutefois,
certains utilitaires et
services ouvrent les fichiers
de base de données
FILE_FLAG_WRITE_THROUG
H == false. Par exemple,
SQL Server Analysis
Services ouvre les fichiers
de base de données à l’aide
FILE_FLAG_WRITE_THROUG
H == false. Pour tester
entièrement un serveur,
exécutez un test pour
chaque paramètre.
ScatterGather true Utiliser les API Si ce paramètre est

ReadScatter/WriteGather paramétré sur true, le
paramètre NoBuffering est
également paramétré sur
true.
SQL Server utilise des

nuages de points/de
collecte d’I/S pour la plupart
des demandes d’I/S.
ForceReadAhead true Effectuer une opération de L’utilitaire SQLIOSim

lecture avant même si les émettra la commande de
données sont déjà lues lecture même si la page de
données se trouve déjà
dans le pool de mémoires
tampons.
Microsoft SQL Server La

prise en charge a
correctement utilisé le vrai
paramètre pour exposer les
problèmes d’I/S.
DeleteFilesAtStartup true Supprimer des fichiers au Un fichier peut contenir

démarrage s’il existe des plusieurs flux de données.
fichiers Seuls les flux spécifiés dans
l’entrée File x FileName sont
tronqués dans le fichier. Si le
flux par défaut est spécifié,
tous les flux sont
supprimés.
DeleteFilesAtShutdown false Supprimer des fichiers une Un fichier peut contenir

fois le test terminé plusieurs flux de données.
Seuls les flux de données
que vous spécifiez dans
l’entrée File x FileName sont
tronqués dans le fichier. Si le
flux de données par défaut
est spécifié, l’utilitaire
SQLIOSim supprime tous
les flux de données.
StampFiles false Développez le fichier en Ce processus peut prendre

horodaté des zéros beaucoup de temps si le
fichier est de grande taille.
Si vous définissez ce
paramètre sur false,
l’utilitaire SQLIOSim étend
le fichier en paramétrer un
marqueur de données
valide.
SQL Server 2005 utilise la

fonctionnalité d’initialisation
de fichiers instantanés pour
les fichiers de données. Si le
fichier de données est un
fichier journal, ou si
l’initialisation du fichier
instantané n’est pas activée,
SQL Server effectue un
tampon zéro. Les versions
de SQL Server antérieures à
SQL Server 2000 effectuent
toujours un cachet zéro.
Vous devez changer la

valeur du paramètre
StampFiles pendant le test
pour vous assurer que
l’initialisation du fichier
instantané et l’horodaage
zéro fonctionnent
correctement.
Section Filex
L’utilitaire SQLIOSim est conçu pour permettre plusieurs tests de fichiers. La section Fichier x est représentée
par [Fichier1], [Fichier2] pour chaque fichier du test.

FileName Aucune valeur par Nom de fichier et chemin Le paramètre FileName

défaut d’accès peut être un chemin long
ou un chemin UNC. Il peut
également inclure un nom
et un type de flux
secondaires. Par exemple, le
paramètre FileName peut
être définie sur
file.mdf:stream2.
REMARQUE Dans SQL

Server 2005, les opérations
DBCC utilisent des flux.
Nous vous recommandons
d’effectuer des tests de flux.
InitialSize Aucune valeur par Taille initiale en Mo Si le fichier existant est

défaut supérieur à la valeur
spécifiée pour le paramètre
InitialSize, l’utilitaire
SQLIOSim ne réduit pas le
fichier existant. Si le fichier
existant est plus petit,
l’utilitaire SQLIOSim
développe le fichier existant.
MaxSize Aucune valeur par Taille maximale en Mo Un fichier ne peut pas

défaut devenir plus volumineux
que la valeur que vous
spécifiez pour le paramètre
MaxSize.
Increment 0 Taille en Mo de l’incrément L’utilitaire SQLIOSim ajuste

par lequel le fichier le paramètre Increment au
augmente ou diminue. Pour démarrage afin que la
plus d’informations, voir la situation suivante soit
partie « ShrinkUser » de cet établie :Increment *
article. MaxExtents <
MaxMemoryMB /
NumberOfDataFiles
Si le résultat est 0, l’utilitaire
SQLIOSim définit le fichier
comme non réduit.
Shrinkable false Indique si le fichier peut Si vous définissez le

être réduit ou développé paramètre Increment sur 0,
vous définissez le fichier
comme non réduit. Dans ce
cas, vous devez définir le
paramètre Shrinkable sur
false. Si vous définissez le
paramètre Increment sur
une valeur autre que 0,
vous définissez le fichier sur
shrinkable. Dans ce cas,
vous devez définir le
paramètre Shrinkable sur
true.
Sparse false Indique si l’attribut Sparse Pour les fichiers existants,

doit être définie sur les l’utilitaire SQLIOSim
fichiers n’effacera pas l’attribut
Sparse lorsque vous
définissez le paramètre
Sparse sur false.
SQL Server 2005 utilise des

fichiers peu nombreux pour
prendre en charge les bases
de données de capture
instantanée et les flux DBCC
secondaires.
Nous vous recommandons

d’activer le fichier faible et
les flux, puis d’effectuer une
passe de test.
REMARQUE Si vous
définissez Sparse = true
pour les paramètres de
fichier, ne spécifiez pas
NoBuffering = false dans la
section de configuration. Si
vous utilisez ces deux
combinaisons conflictuelles,
vous pouvez recevoir une
erreur semblable à celle-ci
de l’outil :
Error:-====Error:
0x80070467
Texte d’erreur : lors de
l’accès au disque dur, une
opération de disque a
échoué même après des
tentatives.
Description : échec de la
validation de la mémoire
tampon
C:\SQLIOSim.mdx Page:
28097
LogFile false Indique si un fichier Vous devez définir au moins

contient des données un fichier journal.
d’utilisateur ou de journal
des transactions
Section RandomUser
L’utilitaire SQLIOSim prend les valeurs que vous spécifiez dans la section RandomUser pour simuler un travail
SQL Server qui effectue des opérations de requête aléatoires, telles que les modèles d’E/S OLTP (Online
Transaction Processing).
UserCount -1 Nombre de threads d’accès La valeur ne peut pas

aléatoire qui s’exécutent en dépasser la valeur suivante :
même temps CPUCount 1023-100 Le
nombre total de tous les
utilisateurs ne peut pas non
plus
dépasser cette valeur. La
valeur 0 signifie que vous
ne pouvez pas créer
d’utilisateurs d’accès
aléatoires. Une valeur de -1
signifie que vous devez
utiliser la configuration
automatique de la valeur
suivante : min(CPUCount 2,
8)
REMARQUE Un SQL
Server système peut avoir
des milliers de sessions. La
plupart des sessions n’ont
pas de demandes actives.
Utilisez la fonction dans les
requêtes par rapport à
l’affichage de gestion
dynamique (DMV) comme
base pour établir cette
valeur count(*)
sys.dm_exec_requests de
paramètre de test.
CPUCount fait ici référence

à la valeur du paramètre
CPUCount dans la section
CONFIG.
La min(CPUCount*2, 8)
valeur se traduit par la plus
petite des valeurs entre
CPUCount*2 et 8.
JumpToNewRegionPercenta 500 Possibilité de passer à une Le début de la région est

ge nouvelle région du fichier sélectionné de manière
aléatoire. La taille de la
région est une valeur
aléatoire entre la valeur du
paramètre
MinIOChainLength et la
valeur du paramètre
MaxIOChainLength.
MinIOChainLength 1 Taille de région minimale en

pages
MaxIOChainLength 100 Taille de région maximale en SQL Server 2005 Êdition

pages Entreprise 2005 et SQL
Server 2000 Êdition
Entreprise peuvent lire
jusqu’à 1 024 pages.
Le minimum est 0. La valeur

maximale est limitée par la
mémoire système.
En règle générale, l’activité

aléatoire de l’utilisateur
entraîne de petites
opérations d’analyse.
Utilisez les valeurs spécifiées
dans la section
ReadAheadUser pour
simuler des opérations
d’analyse plus importantes.
RandomUserReadWriteRatio 9000 Pourcentage de pages à Une chaîne de longueur

mettre à jour aléatoire est sélectionnée
dans la région et peut être
lue. Ce paramètre définit le
pourcentage de pages à
mettre à jour et à écrire sur
le disque.
MinLogPerBuffer 64 Taille minimale de La valeur doit être un

l’enregistrement journal en multiple de la taille du
octets secteur sur disque ou une
taille qui s’adapte de
manière également à la
taille du secteur sur disque.
MaxLogPerBuffer 8192 Taille maximale Cette valeur ne peut pas

d’enregistrement du journal dépasser 64 000. La valeur
en octets doit être un multiple de la
taille du secteur sur disque.
RollbackChance 100 Il est possible qu’une Lorsque cette opération de

opération en mémoire récupération se produit,
entraîne une opération de SQL Server n’écrit pas dans
récupération. le fichier journal.
SleepAfter 5 Temps de veille après

chaque cycle, en
millisecondes
Section AuditUser
L’utilitaire SQLIOSim prend les valeurs que vous spécifiez dans la section AuditUser pour simuler l’activité DBCC
afin de lire et d’auditer les informations sur la page. La validation se produit même si la valeur du paramètre
UserCount est définie sur 0.
UserCount 2 Nombre de threads d’audit La valeur ne peut pas

dépasser la valeur suivante :
CPUCount 1023-100 Le
plus
8)
REMARQUE Un SQL
requêtes sur le DMV
comme base pour établir
cette valeur de count(*)
sys.dm_exec_requests
paramètre de test.

CONFIG.
CPUCount*2 et 8.
BuffersValidated 64
DelayAfterCycles 2 Appliquer le paramètre

AuditDelay une fois le
nombre de cycles
BuffersValidated terminé
AuditDelay 200 Nombre de millisecondes à

attendre après chaque
opération DelayAfterCycles
Section ReadAheadUser
L’utilitaire SQLIOSim prend les valeurs spécifiées dans la section ReadAheadUser pour simuler SQL
Server’activité de lecture avant. SQL Server tirez parti de l’activité de lecture avant pour optimiser les
fonctionnalités asynchrones d’I/S et limiter les retards de requête.
UserCount 2 Nombre de threads en La valeur ne peut pas

lecture avant dépasser la valeur suivante :
CPUCount 1023-100 Le
plus
8)
REMARQUE Un SQL
paramètre de test.

CONFIG.
CPUCount*2 et 8.
BuffersRAMin 32 Nombre minimal de pages à Le minimum est 0. La valeur

lire par cycle maximale est limitée par la
mémoire système.
BuffersRAMax 64 Nombre maximal de pages SQL Server Entreprise

à lire par cycle éditions peuvent lire jusqu’à
1 024 pages dans une seule
demande. Si vous installez
SQL Server sur un
ordinateur qui dispose de
nombreuses ressources de
processeur, de mémoire et
de disque, nous vous
recommandons
d’augmenter la taille de
fichier et la taille de lecture
avant.
DelayAfterCycles 2 Appliquer le paramètre

RADelay une fois le nombre
de cycles spécifié terminé
RADelay 200 Nombre de millisecondes à

Section BulkUpdateUser
L’utilitaire SQLIOSim prend les valeurs que vous spécifiez dans la section BulkUpdateUser pour simuler des
opérations en bloc, telles que SELECT... Opérations INTO et OPÉRATIONS INSERT EN BLOC.
UserCount -1 Nombre de threads DE La valeur ne peut pas

MISE À JOUR EN BLOC dépasser la valeur suivante :
CPUCount*1023-100
La valeur -1 signifie que
vous devez utiliser la
configuration automatique
de la valeur suivante :
min(CPUCount*2, 8)
REMARQUE Un SQL
paramètre de test.

CONFIG.
CPUCount*2 et 8.
BuffersBUMin 64 Nombre minimal de pages à

mettre à jour par cycle
BuffersBUMax 128 Nombre maximal de pages Le minimum est 0. La valeur

à mettre à jour par cycle maximale est limitée par la
mémoire système.
DelayAfterCycles 2 Appliquer le BUDelay

paramètre une fois le
nombre de cycles spécifié
terminé
BUDelay 10 Nombre de millisecondes à

Section ShrinkUser
L’utilitaire SQLIOSim prend les valeurs que vous spécifiez dans la section ShrinkUser pour simuler les
opérations de réduction DBCC. L’utilitaire SQLIOSim peut également utiliser la section ShrinkUser pour agrandir
le fichier.
PA RA M ÈT RE VA L EUR PA R DÉFA UT DESC RIP T IO N
MinShrinkInterval 120 Intervalle minimal entre les opérations

de réduction, en secondes
MaxShrinkInterval 600 Intervalle maximal entre les opérations

de réduction, en secondes
MinExtends 1 Nombre minimal d’incréments par

lequel l’utilitaire SQLIOSim augmente
ou réduit le fichier
MaxExtends 20 Nombre maximal d’incréments par

lequel l’utilitaire SQLIOSim augmente
ou réduit le fichier
Commentaires sur .ini fichier de configuration

Le point-virgule (;) au début d’une ligne dans le fichier .ini configuration entraîne le traitement de la ligne
comme un seul commentaire.
Création de fichiers
L’utilitaire SQLIOSim crée des fichiers de données et des fichiers journaux distincts pour simuler les modèles
d’SQL Server générés dans son fichier de données et dans son fichier journal. L’utilitaire SQLIOSim n’utilise pas
le moteur SQL Server pour effectuer l’activité de contrainte. Par conséquent, vous pouvez utiliser l’utilitaire
SQLIOSim pour tester un ordinateur avant d’installer SQL Server.
Lorsque vous exécutez l’utilitaire SQLIOSim, veillez à spécifier le même emplacement de fichier que celui que
vous utilisez pour SQL Server base de données. Dans ce cas, l’utilitaire simule le même chemin d’accès d’SQL
Server base de données.
Vous pouvez activer l’attribut compresser ou chiffrer les fichiers de test existants. Vous pouvez également activer
ces attributs pour le répertoire existant dans lequel les fichiers de test seront créés. Les options correspondantes
pour activer ces attributs se trouvent dans la boîte de dialogue Propriétés d’un fichier ou d’un répertoire.
Par défaut, l’utilitaire SQLIOSim crée des fichiers de test qui ont les extensions de nom de fichier .mdx et.ldx. Par
conséquent, ces fichiers ne sont pas en cours de réécriture des données et des fichiers journaux existants.
WARNING
Ne spécifiez pas les fichiers de base de données SQL Server à tester. L’utilitaire SQLIOSim va réécrire les données avec des
modèles de test aléatoires, et vos données SQL Server réelles seront perdues.
Journal des erreurs et gestion SQLIOSim

L’utilitaire SQLIOSim crée le fichier journal des erreurs dans l’un des emplacements suivants :
Emplacement que vous spécifiez dans le paramètre de démarrage du journal
Emplacement que vous spécifiez dans la ligne ErrorFile= du fichier Sqliosim.cfg.ini
Le journal SQLIOSim.log.xml'erreurs contient des détails sur l’exécution. Ces détails incluent des informations
sur les erreurs. Examinez attentivement le journal pour obtenir des informations sur les erreurs et des
avertissements.
NOTE
Si vous découvrez une erreur dans l’utilitaire SQLIOSim, nous vous recommandons de demander à votre fabricant de
matériel de vous aider à déterminer la cause première du problème.
Copies multiples
L’utilitaire SQLIOSim permet de tester plusieurs niveaux de fichiers et de plusieurs utilisateurs. L’utilitaire
SQLIOSim ne nécessite pas plusieurs appels. Toutefois, l’utilitaire SQLIOStress nécessite plusieurs appels. Vous
pouvez exécuter plusieurs copies de l’utilitaire SQLIOSim si les conditions suivantes sont vraies :
Toutes les copies font référence à des fichiers de test uniques par instance de l’utilitaire.
Le paramètre de chaque instance fournit une région de mémoire qui ne se chevauche pas MaxMemoryMB et qui
est suffisante pour chaque instance.
La somme du paramètre pour chaque instance doit être inférieure ou égale à la MaxMemoryMB mémoire physique
totale. Certaines phases de test, telles que la simulation de point de contrôle, peuvent être très longues en
mémoire et créer des conditions de mémoire en dehors de la mémoire lorsque vous exécutez plusieurs copies.
Si vous faites l’expérience d’erreurs de mémoire, vous pouvez réduire le nombre de copies utilitaires en cours
d’exécution.
Exemples de fichiers de configuration

Outre le fichier d'Sqliosim.cfg.ini par défaut, le package fournit les exemples de fichiers suivants.
PA RA M ÈT RES Q UI DIF F ÈREN T DU

F IC H IER DE C O N F IGURAT IO N PA R
EXEM P L E DE F IC H IER DESC RIP T IO N DÉFA UT
Sqliosim.hwcache.cfg.ini Réduire les lectures Pour la section AuditUser et pour la

section ReadAheadUser :
Les fichiers sont petits pour les
conserver entièrement en mémoire CacheHitRatio=10000
UserCount=0
Aucune lecture séquentielle
PA RA M ÈT RES Q UI DIF F ÈREN T DU
F IC H IER DE C O N F IGURAT IO N PA R
EXEM P L E DE F IC H IER DESC RIP T IO N DÉFA UT
Sqliosim.nothrottle.cfg.ini Supprimer la limitation des I/S TargetIODuration=1000000

AuditDelay=10
Réduire le temps d’attente pour RADelay=10
augmenter le volume d’O/S
Sqliosim.seqwrites.cfg.ini Réduire les lectures Shrinkable=FALSE
Les fichiers sont petits pour les Pour la section AuditUser, pour la
conserver entièrement en mémoire section ReadAheadUser et pour la
section RandomUser :
Les fichiers sont rendues non
shrinkables CacheHitRatio=10000
ForceReadAhead=FALSE
Aucune lecture séquentielle BuffersBUMin=600
BuffersBUMax=1000
Aucun accès aléatoire BUDelay=1
UserCount=0
Mise à jour en bloc en blocs
volumineux sans délai
Sqliosim.sparse.cfg.ini Utiliser seulement 32 Mo de mémoire MaxMemoryMB=32

TestCycles=3
Rendre la durée d’O/S cible TestCycleDuration=600
suffisamment importante pour activer TargetIODuration=10000
de nombreuses demandes d’I/S en UseScatterGather=FALSE
suspens
[Fichier1]
Désactiver les API de nuages de FileName=sqliosim.mdx
points/de collecte pour émettre des InitialSize=1000 MaxSize=1000
demandes d’entrée/heure distinctes Increment=10
pour chaque page de 8 Ko Shrinkable=FALSE
LogFile=FALSE
Créer un fichier non réduit de 1 Go Sparse=FALSE
Créer un flux secondaire non réduit de [Fichier2]

1 Go dans le fichier FileName=sqliosim.ldx
InitialSize=50
MaxSize=50
Increment=0
Shrinkable=FALSE
LogFile=TRUE
Sparse=FALSE
[Fichier3]
FileName=sqliosim.mdx:replica
InitialSize=1000
MaxSize=1000
Increment=10
Shrinkable=FALSE
LogFile=FALSE
Sparse=TRUE
Références
Description de la mise en cache des contrôleurs de disque dans SQL Server
KB826433 : SQL Server diagnostics ajoutés pour détecter les problèmes d’I/S non signalés dus à des
lectures obsolètes ou à des écritures perdues
Visual Studio 2010 Shell est installé avec SQL Server
2014 et 2012
S’applique à : SQL Server 2014, SQL Server 2012
Symptômes
Après avoir installé SQL Server 2014 ou SQL Server 2012 avec SQL Server Management Studio (SSMS) ou SQL
Server Data Tools (SSDT), les programmes suivants sont installés et répertoriés comme programmes installés :
Microsoft Visual Studio 2010 Shell (isolé)
Microsoft Visual Studio 2010 Shell (intégré)
Lors de l’analyse du serveur avec un logiciel de sécurité, Visual Studio 2010 Shell peut être marqué comme
logiciel de fin de prise en charge (EOS) ou obsolète.
Cause
Lors de l’installation de SQL Server 2014 ou SQL Server 2012, SSMS nécessite Visual Studio 2010 Shell (isolé)
et SSDT nécessite Visual Studio 2010 Shell (intégré).
Conformément à la politique de cycle de vie de Microsoft Visual Studio 2010, le support a pris fin le 14 juillet
2020. Toutefois, si Visual Studio 2010 Shell (isolé) ou Shell (intégré) est installé avec SQL Server 2014 ou SQL
Server 2012, Visual Studio 2010 Shell sera pris en charge jusqu’à la fin de la prise en charge de SQL Server
2014 (09/07/2024) ou de SQL Server 2012 (12/07/2022).
Voici comment résoudre ce problème :
1. Utilisez l SQL Server d’installation pour désinstaller la version installée de SSMS ou SSDT.
2. Téléchargez et installez la dernière version de SSMS ou SSDT.
NOTE
Si vous utilisez SSMS pour gérer les packages SSIS (SQL Server Integration Services), voir Supported SQL
offerings.
Si vous utilisez Business Intelligence Development Studio (BIDS) pour concevoir et gérer des packages SSIS, voir
Supported SQL versions.
3. Assurez-vous Visual Studio 2010 Shell (isolé) ou Shell (intégré) n’est pas utilisé par d’autres applications
ou services.
4. Désinstallez Visual Studio 2010 Shell (isolé) ou Shell (intégré) via Ajouter ou supprimer des
programmes.

Depannage SQL Module Complet

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Depannage SQL Module Complet

Transféré par

Droits d'auteur :

Formats disponibles

Contents

Utiliser une formule pour calculer la croissance de la période

IIF (measures.PreviousPeriodCurrentBalance = 0, NULL,

([Measures].[Balance Current], [Date Balance].[Hierarchy].currentmember.Prevmember)

Connexion impossible <server name>

VERSIO N D’A N A LY SIS SERVIC ES VERSIO N DU F O URN ISSEUR M SO L A P

SQL Server 2008 MSOLAP.4

SQL Server 2012 MSOLAP.5

SQL Server 2014 MSOLAP.6

SQL Server 2016 MSOLAP.7

SQL Server 2017 et versions ultérieures MSOLAP.8 (considéré comme persistant)

Office MSI 64 bits

Office C2R 32 bits

Office C2R 64 bits

Voici un exemple de Office C2R 32 bits configuré pour utiliser MSOLAP.5 :

VERSIO N D’A N A LY SIS SERVIC ES EM P L A C EM EN T

2019 %ProgramFiles%\Microsoft SQL

2017 %ProgramFiles%\Microsoft SQL

2016 %ProgramFiles%\Microsoft SQL Server

2014 %ProgramFiles%\Microsoft SQL Server

2012 %ProgramFiles%\Microsoft SQL Server

VERSIO N D’A N A LY SIS SERVIC ES SO US- C L É DE REGIST RE

Instance par défaut HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLServerOLAPService\ImageP

Instance nommée HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSOLAP$InstanceName\ImagePath

Les fichiers minidump incluent les informations suivantes :

Désactiver le fichier de vidage automatique de mémoire pour Analysis

VA L EUR DESC RIP T IO N

0 Cette valeur indique qu’Analysis Services ne génère aucun

1 Cette valeur par défaut active le fichier de vidage mémoire.

2 Cette valeur spécifie que SQL Server Analysis Services

Lorsque le paramètre CreateAndSendCrashReports est 1 ou 2, les autres paramètres de la section Exception

Configurer SQL Server Analysis Services pour générer

Générer un fichier de vidage complet qui inclut la poignée des

Sqldumper.exe PID 0 0x34:0x4 0 PathToDumpFile

VERSIO N D’A N A LY SIS SERVIC ES EM P L A C EM EN T

2019 %ProgramFiles%\Microsoft SQL Server\150\Shared

2017 %ProgramFiles%\Microsoft SQL Server\140\Shared

2016 %ProgramFiles%\Microsoft SQL Server\130\Shared

2014 %ProgramFiles%\Microsoft SQL Server\120\Shared

2012 %ProgramFiles%\Microsoft SQL Server\110\Shared

N O M M N ÉM O N IQ UE VA L EUR H EXA DÉC IM A L E DESC RIP T IO N

SQLDUMPER_DBGBREAK 0x0001 Cet indicateur entraîne

SQLDUMPER_NOMINIDUMP 0x0002 Lorsque vous utilisez cet indicateur,

SQLDUMPER_NOWATSON 0x0004 En règle générale, cet indicateur est

SQLDUMPER_REFERENCED_MEMORY 0x0008 Cet indicateur entraîne la

SQLDUMPER_ALL_MEMORY 0x0010 Cet indicateur entraîne la

SQLDUMPER_DUMP_ALL_THREADS 0x0020 Cet indicateur n’est pas requis lorsque

SQLDUMPER_MATCH_FILE_NAME 0x0040 Vous pouvez utiliser cet indicateur

SQLDUMPER_SKIP_DW_REG_READ 0x0080 Cet indicateur permet à

SQLDUMPER_VERBOSE 0x0100 Cet indicateur peut être utile si vous

SQLDUMPER_WAIT_AT_EXIT 0x0200 Vous pouvez utiliser cet indicateur

SQLDUMPER_FILTERED 0x0800 Vous pouvez utiliser cet indicateur

O P T IO N VA L EUR DESC RIP T IO N

MiniDumpNormal 0x00000000 Créez un fichier de mini-vidage

MiniDumpWithDataSegs 0x00000001 Inclure un segment de données pour

MiniDumpWithFullMemory 0x00000002 Créez un fichier de vidage utilisateur

MiniDumpWithHandleData 0x00000004 Inclure les informations de handle.

MiniDumpFilterMemory 0x00000010 La mémoire de la pile et du magasin

MiniDumpWithUnloadedModules 0x00000020 Cet indicateur fournit des informations

MiniDumpWithIndirectlyReferencedMe 0x00000040 Inclure les pages qui comportent des

MiniDumpFilterModulePaths 0x00000080 Si le chemin d’accès du module est

MiniDumpWithProcessThreadData 0x00000100 Cet indicateur fournit des informations

MiniDumpWithPrivateReadWriteMemo 0x00000200 Analysez l’espace d’adressa visite

MiniDumpWithoutOptionalData 0x00000400 Réduisez les données qui sont vidées