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
L’ID d’événement 1814 et SQL Server ne démarre pas
L’ID d’événement 33565 et SQL Server ne démarre pas
L’ID d’événement 33566 et SQL Server ne démarre pas
L’ID d’événement 7000 et SQL Server ne démarre pas
Erreurs 1450 et 665 lors de l’exécution du DBCC
Erreurs 17053 et 926 lors de l’exécution du DBCC
Erreurs 8967 et 8921 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
Utilisation SQL Server 2016 en mode conforme FIPS 140-2
Utilisation SQL Server 2008 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
13/08/2021 • 2 minutes to read
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.
NOTE
La formule ci-dessus utilise un membre calculé créé sur une hiérarchie PreviousPeriodCurrentBalance de dates avec la
formule suivante :
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
15/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 2429685
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 :
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
14/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4488253
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.
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.
Plus d’informations
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)
ou
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\
{DBC724B0-DD86-4772-BB5A-FCC6CAB2FC1A}\ProgID
ou
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\
{DBC724B0-DD86-4772-BB5A-FCC6CAB2FC1A}\ProgID\(Default)
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
13/08/2021 • 9 minutes to read
Cet article explique comment configurer SQL Server Analysis Services pour générer automatiquement des
fichiers de vidage mémoire.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 919711
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.
Plus d’informations
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 :
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.
<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.
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.
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.
Vous pouvez utiliser le paramètre MiniDumpFlagsOn pour fournir des indicateurs minidump. Le tableau suivant
répertorie les indicateurs minidump disponibles :
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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 301934
Plus d’informations
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 :
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 :
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 :
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 :
La requête MDX pour rechercher le premier membre avec des données prend ensuite la forme
et la requête MDX pour rechercher le dernier membre avec des données prend ensuite la forme :
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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 4088924
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.
Plus d’informations
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
SQL Server 2014 Enterprise
SQL Server 2012 Enterprise
Activer le niveau d’isolation des transactions
instantanées dans SQL Server 2005 Analysis
Services
13/08/2021 • 3 minutes to read
Cet article décrit les étapes à suivre pour activer le niveau d’isolation des transactions instantanées dans
Analysis Services.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 919160
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é.
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.
NOTE
Pour afficher la colonne TransactionID, cochez la case Afficher toutes les colonnes.
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.
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
14/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 2811566
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)
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.
Plus d’informations
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
15/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4533057
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 :
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
14/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 2658571
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.
Plus d’informations
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
14/08/2021 • 3 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 922673
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
Message d’erreur 2
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 :
Statut
Ce comportement est inhérent au produit.
Message d’erreur lors du traitement d’une
dimension
14/08/2021 • 2 minutes to read
Cet article vous aide à résoudre le problème qui se produit lorsque vous traitez une dimension dans SQL Server
Analysis Service.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2002757
Symptômes
Dans SQL Server Analysis Service, le traitement des dimensions et vous pouvez recevoir un message d’erreur
semblable à ce qui suit :
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.
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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2607106
Symptômes
Prenons l’exemple du scénario suivant :
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 :
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 .
Mis à jour
<binding name="RedirectorBinding">
<webMessageEncoding
webContentTypeMapperType="Microsoft.AnalysisServices.SharePoint.Integration.Redirector.RawCont
entTypeMapper, Microsoft.AnalysisServices.SharePoint.Integration" />
<httpTransport manualAddressing="true" authenticationScheme="Negotiate"
transferMode="Streamed" maxReceivedMessageSize="9223372036854775807"/>
</binding>
<binding name="RedirectorSecureBinding">
<webMessageEncoding
webContentTypeMapperType="Microsoft.AnalysisServices.SharePoint.Integration.Redirector.RawCont
entTypeMapper, Microsoft.AnalysisServices.SharePoint.Integration" />
<httpsTransport manualAddressing="true" authenticationScheme="Ntlm" transferMode="Streamed"
maxReceivedMessageSize="9223372036854775807"/>
</binding>
Mis à jour
<binding name="RedirectorSecureBinding">
<webMessageEncoding
webContentTypeMapperType="Microsoft.AnalysisServices.SharePoint.Integration.Redirector.RawCont
entTypeMapper, Microsoft.AnalysisServices.SharePoint.Integration" />
<httpsTransport manualAddressing="true" authenticationScheme="Negotiate"
transferMode="Streamed" maxReceivedMessageSize="9223372036854775807"/>
</binding>
Cet article décrit un problème qui se produit si l’ensemble dans la Aggregate fonction contient un membre
calculé.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 942981
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 :
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.
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
14/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4560494
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
14/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4038458
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.
Solution de contournement
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
12/08/2021 • 6 minutes to read
Cet article explique comment effectuer une requête distribuée SQL Server avec OLAP Server.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 218592
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 :
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.
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
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.]
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.]
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
14/08/2021 • 4 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2607575
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 ».
Plus d’informations
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 ».
Solution de contournement
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
15/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 2747616
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.
Solution de contournement
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
15/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4100766
Symptômes
Prenons l’exemple du scénario suivant :
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
14/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 4041637
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 :
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.
Plus d’informations
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
13/08/2021 • 3 minutes to read
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
Numéro de la ko d’origine : 4525647
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 :
Dans ce cas, vous pouvez voir les informations supplémentaires suivantes dans le fichier journal Details.txt dans
le dossier SQL Server’installation :
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
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
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
13/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 2712972
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.
Plus d’informations
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
14/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 2702283
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 :
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
Plus d’informations
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
13/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 2715968
Symptômes
Prenons l’exemple du scénario suivant :
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 :
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.
Solution de contournement
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
13/08/2021 • 3 minutes to read
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.
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.
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
(MSSQLSERVER) sur l’ordinateur local.
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
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
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
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.
Windows n’a pas pu démarrer SQL Server (MSSQLSERVER) L’ID d’événement 33565 et SQL Server ne démarre pas
sur l’ordinateur local. Pour plus d’informations, examinez le après l’activer
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
propre au service 2146885628.
Windows n’a pas pu démarrer SQL Server (MSSQLSERVER) L’ID d’événement 33566 et SQL Server ne démarre pas
sur l’ordinateur local. Pour plus d’informations, examinez le après l’activer
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 Erreur « Accès refusé » et SQL Server ne démarre pas
(MSSQLSERVER) sur l’ordinateur local.
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
13/08/2021 • 2 minutes to read
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é.
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 :
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
13/08/2021 • 3 minutes to read
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 :
À l’aide de l’applet services :
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.
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 :
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
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 :
À l’aide de l’applet services :
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.
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 :
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 Error: 17182, Severity: 16, State: 1.
<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 Error: 17826, Severity: 18, State: 3.
<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 Error: 17120, Severity: 16, State: 1.
<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 :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\Tcp\Enabled
Canaux nommés :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
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
15/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 307288
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.
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 :
Plus d’informations
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
13/08/2021 • 7 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 282254
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 :
À l’aide de l’applet services :
Windows n’a pas pu démarrer SQL Server service (MSSQLSERVER) sur l’ordinateur local.
Erreur 1069 : le service n’a pas commencé en raison d’un échec d’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.
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
To ensure that the service is configured properly, use the Services snap-in in Microsoft Management Console
(MMC).
Action de l'utilisateur
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.
To ensure that the service is configured properly, use the Services snap-in in Microsoft Management Console
(MMC).
Action de l'utilisateur
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.
To ensure that the service is configured properly, use the Services snap-in in Microsoft Management Console
(MMC).
Action de l'utilisateur
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.
To ensure that the service is configured properly, use the Services snap-in in Microsoft Management Console
(MMC).
Action de l'utilisateur
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
15/08/2021 • 2 minutes to read
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 :
À l’aide de l’applet services :
Windows n’a pas pu démarrer SQL Server service (MSSQLSERVER) sur l’ordinateur local.
Erreur 1067 : Le processus s’est terminé de manière inattendue.
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 :
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
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 :
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.
L’ID d’événement 1814 et SQL Server ne démarre
pas
13/08/2021 • 2 minutes to read
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 :
Log Name: Application
Source: MSSQLSERVER
Date: <Datetime>
Event ID: 5123
Task Category: Server
Level: Error
Keywords: Classic
User: N/A
Computer: <Server name>
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>.
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.
L’ID d’événement 33565 et SQL Server ne démarre
pas après l’activer
13/08/2021 • 2 minutes to read
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 :
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 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
semblables à ce qui suit :
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.
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
L’ID d’événement 33566 et SQL Server ne démarre
pas après l’activer
13/08/2021 • 2 minutes to read
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 :
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.
Résolution
1. Consultez le journal des applications et vérifiez que vous voyez deux entrées d’événement semblables à
ce qui suit :
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 :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\Certificate
Cette erreur se produit si des caractères non valides sont copiés dans la valeur de Registre.
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.
L’ID d’événement 7000 et SQL Server ne démarre
pas
13/08/2021 • 2 minutes to read
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 :
À l’aide de l’applet services :
Windows n’a pas pu démarrer SQL Server service (MSSQLSERVER) sur l’ordinateur local.
Erreur 2 : le système ne peut pas trouver le fichier spécifié.
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 :
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
13/08/2021 • 4 minutes to read
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
Numéro de la ko d’origine : 2002606
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 :
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
13/08/2021 • 8 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 926070
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
informational message only. No user action is required.
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 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.77 spid53 Error: 17053, Severity: 16, State: 1.
2006-09-01 17:36:31.77 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.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:31.90 spid53 Error: 17053, Severity: 16, State: 1.
2006-09-01 17:36:31.90 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.90 spid53 Error: 17053, Severity: 16, State: 1.
2006-09-01 17:36:31.90 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:32.30 spid54 Error: 926, Severity: 21, State: 6.
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
Ce comportement est inhérent au produit.
Plus d’informations
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 :
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 :
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
informational message only. No user action is required.
2008-05-21 13:03:45.84 spid500 2 transactions rolled back in database 'MYDATABASE' (12). This is an
informational message only. No user action is required.
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 Error: 17053, Severity: 16, State: 1.
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.
2008-05-21 13:36:48.27 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
'C:\MSSQL\DATA\MyDatabase.mdf:MSSQL_DBCC12'.
2008-05-21 13:36:48.27 spid480 Error: 17053, Severity: 16, State: 1.
2008-05-21 13:36:48.27 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.
2008-05-21 13:36:48.37 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
'C:\MSSQL\DATA\MyDatabase.mdf:MSSQL_DBCC12'.
2008-05-21 13:36:48.37 spid480 Error: 17053, Severity: 16, State: 1.
2008-05-21 13:36:48.37 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.
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
13/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 960791
Symptômes
Prenons l’exemple du scénario suivant :
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.
Solution de contournement
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
14/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2014
Enterprise
Numéro de la ko d’origine : 3177997
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 :
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.
Plus d’informations
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
13/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 2666213
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 :
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'
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 :
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
14/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 4033835
Symptômes
Prenons l’exemple du scénario suivant :
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 :
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 :
Solution de contournement
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
14/08/2021 • 2 minutes to read
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é.
Version du produit d’origine : SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012, SQL
Server 2008 R2
Numéro de la ko d’origine : 3163368
Symptômes
Prenons l’exemple du scénario suivant :
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 :
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.
Solution de contournement
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 :
Plus d’informations
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 :
Vous pouvez interroger l’état du moniteur de file d’attente en exécutant la requête suivante :
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
15/08/2021 • 4 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2492477
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. »
Msg 65535, Niveau 16, État 1, Ligne 0
SQL Interfaces réseau : serveur de localisation d’erreurs/instance spécifiée [xFFFFFFFF].
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. »
Msg 65535, Niveau 16, État 1, Ligne 0
SQL Interfaces réseau : serveur de localisation d’erreurs/instance spécifiée [xFFFFFFFF].
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.
Solution de contournement
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é).
Plus d’informations
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.
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
14/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4465462
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.
Plus d’informations
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
13/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 2700641
Symptômes
Prenons l’exemple du scénario suivant :
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.
Solution de contournement
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.
Informations supplémentaires
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
13/08/2021 • 3 minutes to read
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
Numéro de la ko d’origine : 4504103
Symptômes
Prenons l’exemple du scénario suivant :
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 » :
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.
[-,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
[-,0x00c390:0xbb80:0x0eba42eb] sqlwriter.pé\sqlwriter\FileName(LineNumber) : STDMETHODCALLTYPE
CSqlWriter::OnPostSnapshot: Throwing HRESULT code 0x8077000e. Code HRESULT précédent =
0x8077000e
[-,0x00c390:0xbb80:0x0eba42eb] sqlwriter.pé\sqlwriter\FileName(LineNumber) : STDMETHODCALLTYPE
CSqlWriter::OnPostSnapshot: EXCEPTION HRESULT CAUGHT: hr: 0x8077000e
[-,0x00c390:0xbb80:0x0eba42eb] Entrez {Snapshot::~Snapshot}:
Solution de contournement
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
Plus d’informations
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
13/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4504104
Symptômes
Prenons l’exemple du scénario suivant :
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.
Solution de contournement
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.
Plus d’informations
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) :
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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2014054
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 :
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.
Plus d’informations
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
13/08/2021 • 13 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 224071
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.
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.
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.
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
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$.
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 :
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
Plus d’informations
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
13/08/2021 • 2 minutes to read
Cet article décrit un comportement « par conception » qui se produit lorsque vous utilisez VSS pour la back up
files sur un volume.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 951288
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.
USE msdb
GO
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 .
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.
Cet article présente le comportement des sauvegardes compressées lorsque vous les appendez à un jeu
multimédia existant.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2297053
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.
Plus d’informations
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.
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)
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 .
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.
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.
restore headeronly from DISK = N'E:\testbackup.bak'
--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
restore headeronly from DISK = N'E:\testbackup.bak'
-- 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,
NAME = N'testbackup-Full Database Backup', SKIP,NOUNLOAD, STATS = 10
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
restore headeronly from DISK = N'E:\testbackup.bak'
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
restore headeronly from DISK = N'E:\testbackup.bak'
-- 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,
NAME = N'testbackup-Full Database Backup', SKIP,NOUNLOAD, STATS = 10
GO
Après avoir exécuté le script sql, vous pouvez recevoir le message d’erreur 3098 et 3013 :
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
Après avoir exécuté le script sql, vous pouvez recevoir le message d’erreur 3098 et 3013 :
Message d’erreur 3098 et 3013
Message d’erreur 3098
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.
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.
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 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
3. Dans le menu Edition, cliquez sur Ajouter une valeur, puis ajoutez cette valeur de Registre :
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
12/08/2021 • 8 minutes to read
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.
Plus d’informations
Voici quelques éléments à prendre en compte si vous décidez d’affiner vos paramètres derow automatique et
d’autoshrink.
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 :
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.
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.
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
13/08/2021 • 5 minutes to read
Cet article décrit les considérations qui s’appliquent lorsque vous utilisez le moteur SQL Server Full-Text
recherche pour le japonais.
S’applique à : SQL Server
Numéro de la ko d’origine : 2252955
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.
Plus d’informations
Par exemple, vous créez un tableau et insérez des expressions japonaises en exécutant les instructions suivantes
dans SQL Server :
c1c2
2Fw : テスト
3KK-Information :テスト
6テスト
Requête 2
c1c2
2 Fw : テスト
3 KK-Information :テスト
6 テスト
8 テストフィルタ１
9 RE : テストメール
10 テストメール
Requête 3
c1c2
2 Fw : テスト
3 KK-Information :テスト
6 テスト
8 テストフィルタ１
9 RE : テストメール
10 テストメール
À 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
Voici le résultat :
c1c2
6 テスト
8 テストフィルタ１
10 テストメール
Requête 5
Voici le résultat :
c1c2
1 添付テスト
2 Fw : テスト
3 KK-Information :テスト
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 :
Voici le résultat :
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
12/08/2021 • 2 minutes to read
Cet article vous aide à résoudre un problème qui peut se produire lorsque vous exécutez une requête de
serveur lié Oracle.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2295405
Symptôme
Prenons l’exemple du scénario suivant :
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.
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 :
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
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.
Solution de contournement
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 : /* */ .
Plus d’informations
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
12/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4502458
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.
Solution de contournement
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 :
Plus d’informations
RESTORE Statements - VERIFYONLY (Transact-SQL)
GRANT Database Permissions (Transact-SQL).
SQL Server Moteur de base de
données’entrée/sortie requises
13/08/2021 • 4 minutes to read
Cet article décrit les conditions requises SQL Server Moteur de base de données’entrée/sortie.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 967576
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 :
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
Plus d’informations
Le tableau suivant fournit des liens vers des informations supplémentaires relatives à des configurations
d’opérations d’opérations d’information spécifiques.
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
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
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)
NAS (Network Attached Stockage) Description de la prise en charge des fichiers de base de
données réseau dans 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
12/08/2021 • 2 minutes to read
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*).
S’applique à : SQL Server
Numéro de la ko d’origine : 200043
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 .
Solution de contournement
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.
Plus d’informations
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
12/08/2021 • 5 minutes to read
Cet article fournit des conseils concernant la défragmentation des lecteurs de SQL Server base de données.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 3195161
Informations supplémentaires
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.
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
12/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2270849
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
semblables à ce qui suit :
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 :
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.
Plus d’informations
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
13/08/2021 • 2 minutes to read
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 :
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.
Solution de contournement
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)
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
14/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4534430
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 :
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
13/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4316959
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:
Plus d’informations
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
13/08/2021 • 2 minutes to read
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 :
Message d’erreur 1
[Microsoft] [Pilote SQL Server ODBC] [SQL Server] Ressources insuffisantes pour créer un
programmeur de SSM.
Msg 3267, SevLevel 16, State 1, SQLState 42000
Message d’erreur 2
[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
Message d’erreur 3
Le message suivant peut être consigné dans le journal SQL Server’erreurs :
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.
Solution de contournement
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.
Plus d’informations
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
13/08/2021 • 3 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 918040
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 :
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 :
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.
Solution de contournement
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.
USE <DatabaseName>
GO
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.
Plus d’informations
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
13/08/2021 • 3 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2513181
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
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.
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 !
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.
Plus d’informations
Étapes de la repro :
1. Créez un tableau simple comme suit :
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>')
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
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 4045273
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 :
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à.
Solution de contournement
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 :
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
15/08/2021 • 19 minutes to read
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
Numéro de la ko d’origine : 917047
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.
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.
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.
Plus d’informations
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.
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.
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.
O P ÉRAT IO N
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
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.
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.
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
13/08/2021 • 4 minutes to read
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
Numéro de la ko d’origine : 2549443
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.
Plus d’informations
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'
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)
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
15/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 919155
Symptômes
Prenons l’exemple du scénario suivant :
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
Ce comportement est inhérent au produit.
S’applique à
SQL Server Développeur 2008
SQL Server 2008 Enterprise
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 2012 Business Intelligence
SQL Server Développeur 2012
SQL Server 2012 Enterprise
SQL Server 2012 Express
SQL Server 2012 Standard
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
13/08/2021 • 20 minutes to read
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
Version du produit d’origine : SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005
Numéro de la ko d’origine : 230785
Plus d’informations
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
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.
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 volatile Tout support qui ne restera pas intact en cas d’échec.
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.
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 :
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 :
SET NOCOUNT ON
GO
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
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
13/08/2021 • 2 minutes to read
Cet article explique comment gérer le journal d’SQL Server journal des erreurs.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2199578
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.
Plus d’informations
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)
Cet article explique comment transmettre une variable à une requête de serveur liée.
Version du produit d’origine : SQL Server Livres en ligne
Numéro de la ko d’origine : 314520
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.
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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017, SQL
Server 2019
Numéro de la ko d’origine : 3210239
Symptômes
Prenons l’exemple du scénario suivant :
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).
Plus d’informations
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
14/08/2021 • 2 minutes to read
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).
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2923956
Symptômes
Prenons l’exemple du scénario suivant :
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 :
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.
Solution de contournement
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
14/08/2021 • 4 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2483090
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 :
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
14/08/2021 • 9 minutes to read
Cet article explique comment exécuter un objet COM basé sur une DLL en dehors SQL Server processus.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 198891
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.
Plus d’informations
Les informations sur les deux méthodes de base que vous pouvez utiliser pour inssérer l’objet COM hors
processus suivent.
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 :
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
NOTE
Si vous ajoutez la ThreadingModel valeur, veillez à tester votre objet COM avant de l’implémenter.
{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 :
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 :
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
13/08/2021 • 5 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2019698
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.
Plus d’informations
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
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
14/08/2021 • 14 minutes to read
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
Numéro de la ko d’origine : 280106
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.
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.
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.
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 :
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
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
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.
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
14/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 913399
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.
Solution de contournement
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 :
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 :
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
15/08/2021 • 4 minutes to read
Cet article décrit le comportement SQL Server de stockage des fichiers de base de données sur les lecteurs
compressés.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 231347
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.
Plus d’informations
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
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
15/08/2021 • 10 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 304261
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.
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.
Plus d’informations
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
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.
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
Informations sur l’utilisation de caches de disque avec des SQL Server que chaque administrateur de
base de données doit connaître
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
15/08/2021 • 2 minutes to read
Cet article présente la prise en charge des SQL Server sur les composants de technologie iSCSI.
Version du produit d’origine : SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005
Numéro de la ko d’origine : 833770
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.
Plus d’informations
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
12/08/2021 • 3 minutes to read
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
Numéro de la ko d’origine : 4502457
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
:
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) :
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:
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
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
13/08/2021 • 3 minutes to read
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
Numéro de la ko d’origine : 2633151
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.
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.
Solution de contournement
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.
Plus d’informations
Vous pouvez utiliser la requête suivante pour identifier le fichier journal des transactions SQL Server base de
données de données :
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
13/08/2021 • 6 minutes to read
Cet article explique comment résoudre les erreurs signalées par la commande DBCC CHECKDB.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2015748
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.
Plus d’informations
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/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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 816701
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 :
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.
Solution de contournement
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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server 2008
Numéro de la ko d’origine : 2600089
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 :
Message d’erreur 1
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.
Message d’erreur 2
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.
Message d’erreur 3
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.
Message d’erreur 4
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.
Message d’erreur 5
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.
Plus d’informations
MSSQLSERVER_824
MSSQLSERVER_823
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.
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
13/08/2021 • 3 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 3191316
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.
Solution de contournement
Pour contourner ce problème, utilisez l’une des méthodes suivantes :
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.
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
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
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
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
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
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 4460005
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
13/08/2021 • 2 minutes to read
Cet article vous aide à résoudre le problème où vous ne pouvez pas vous connecter à distance à SQL à l’aide du
protocole TCP/IP.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2018930
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 :
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 :
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 :
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 :
Plus d’informations
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
13/08/2021 • 3 minutes to read
Cet article décrit l’outil de diagnostic Microsoft Kerberos Configuration Manager pour SQL Server.
S’applique à : SQL Server
Numéro de la ko d’origine : 2985455
Plus d’informations
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.
NOTE
Pour résoudre le problème de connectivité avec SSRS, démarrez la fenêtre de ligne de commande en tant
qu’administrateur.
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.
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].
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.
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.
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: 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 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.
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.
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.
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
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.
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.
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 ?
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.
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.
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
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.
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
[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.
T Y P E DE P RO B L ÈM E RÉSO L UT IO N S SUGGÉRÉES
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)
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é.
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
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
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.
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.
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
É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.
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
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.
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».
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
É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.
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
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.
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
É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).
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.
Pour plus d’conseils et de suggestions, consultez : Résolution des problèmes : Expiration du délai d’expiration.
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
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.
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
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 »
Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.
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
13/08/2021 • 5 minutes to read
Cet article vous aide à résoudre le problème qui se produit lorsque vous essayez d’établir une connexion
chiffrée à SQL Server.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2007728
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
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
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
14/08/2021 • 4 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2000373
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.
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.
Plus d’informations
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.
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;
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.
if (impersonatedUser != null)
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 System.Data.SqlClient;
using Microsoft.SqlServer.Server;
using System.Security.Principal;
using System.Transactions;
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.
Version du produit d’origine : SQL Server 2016
Numéro de la ko d’origine : 4465511
Symptômes
Prenons l’exemple du scénario suivant :
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 :
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.
Solution de contournement
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 .
Informations supplémentaires
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
13/08/2021 • 4 minutes to read
Cet article vous aide à contourner le problème où l’exécution d’objets CLR SQL Server échoue et renvoie une
exception System.TypeInitializationException.
S’applique à : SQL Server
Numéro de la ko d’origine : 4576575
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.
Solution de contournement
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.
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"/>
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
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
Plus d’informations
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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 3051225
Symptômes
Prenons l’exemple du scénario suivant :
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 :
NOTE
Cette requête n’utilise pas l’index filtré suivant :
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.
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é.
Version du produit d’origine : SQL Server 2017, SQL Server 2016
Numéro de la ko d’origine : 4010261
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é.
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 :
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.
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
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
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
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 )
USE [database_name]
GO
GO
DBCC CHECKCONSTRAINTS
GO
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.
GO
c2 datetime,
c3 datetime,
c4 int,
GO
(
convert(datetime, '1900-01-01 00:00:00.997'),
GO
GO
DBCC CHECKCONSTRAINTS
GO
GO
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
GO
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 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
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.
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.
DBCC CHECKCONSTRAINTS
Pour valider les contraintes liées à une seule table ou vue, utilisez le script suivant :
USE [database_name]
GO
GO
DBCC CHECKCONSTRAINTS()
GO
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
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
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.
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 :
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 :
ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL=120
go
c2 datetime,
c3 datetime,
c4 int,
GO
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
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
CHECK (new_constraint_definition)
COMMIT
GO
BEGIN TRANSACTION
COMMIT
GO
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.
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.
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.
GO
c2 datetime,
c3 float
GO
GO
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
GO
GO
GO
-- 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
( 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
-- if the data type is numeric, integer, or money, the only cases that warrent additional checks
-- with DBCC is if the column definition contains a float or datetime value, or a conversion to such value
c1.definition
AND (c2.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
AND (
c1.is_persisted=1
)
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 :
-- if the data type is numeric, integer, or money, the only cases that warrent additional checks
-- with DBCC is where the filter condition contains a float or datetime value
, 62 --float
, 58 --smalldatetime
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint
( 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)
UNION
UNION
--indexed views
SELECT DISTINCT QUOTENAME(sed.referenced_schema_name) + N'.' + QUOTENAME(sed.referenced_entity_name) AS
'object_for_checktable'
FROM sys.sql_expression_dependencies AS sed
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
, 58 --smalldatetime
, 61 --datetime
, 60 --money
, 122 --smallmoney
, 106 --decimal
, 108 --numeric
, 56 --int
, 48 --tinyint
, 52 -- smallint
, 41 --time
, 127 --bigint
)) AS a
PRINT @sql;
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 111401
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.
set rowcount 0
select * into #mytemp from authors
set rowcount 1
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 )
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 :
set rowcount 1
update #mytemp set mykey = 1
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
15/08/2021 • 3 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 922672
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 :
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)
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 3053639
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 :
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
Solution de contournement
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.
Plus d’informations
Pour reproduire ce problème, exécutez le script suivant :
CREATE DATABASE Test_DB
GO
use Test_DB
go
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
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 2014 Business Intelligence
SQL Server Développeur 2014
SQL Server 2014 Enterprise
SQL Server 2014 Enterprise Core
SQL Server 2014 Express
SQL Server 2014 Standard
SQL Server Web 2014
SQL Server 2012 Business Intelligence
SQL Server 2012 Developer
SQL Server 2012 Enterprise
SQL Server 2012 Express
SQL Server 2012 Standard
SQL Server Web 2012
SQL Server 2012 Enterprise Core
SQL Server 2008 R2 Datacenter
SQL Server 2008 R2 Developer
SQL Server 2008 R2 Enterprise
SQL Server 2008 R2 Express
SQL Server 2008 R2 Parallel Data Warehouse
SQL Server 2008 R2 Standard
SQL Server 2008 R2 Web
SQL Server 2008 R2 Workgroup
SQL Server 2008 Developer
SQL Server 2008 Enterprise
SQL Server 2008 Express
SQL Server 2008 Standard
SQL Server Web 2008
SQL Server 2008 Workgroup
SQL Server 2005 Developer Edition
SQL Server 2005 Enterprise Edition
SQL Server 2005 Express Edition
SQL Server 2005 Édition Standard
SQL Server 2005 Standard X64 Edition
SQL Server 2005 Workgroup Edition
Supprimer des lignes en double d’une table SQL
Server à l’aide d’un script
13/08/2021 • 2 minutes to read
Cet article fournit un script que vous pouvez utiliser pour supprimer des lignes en double d’un tableau dans
Microsoft SQL Server.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 70956
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 :
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
DELETE T
FROM
(
SELECT *
, DupRank = ROW_NUMBER() OVER (
PARTITION BY key_value
ORDER BY (SELECT NULL)
)
FROM original_table
) AS T
WHERE DupRank > 1
Plus d’informations
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
14/08/2021 • 2 minutes to read
Cet article explique comment faire pivoter un tableau dans SQL Server.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 175574
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
La requête que vous utiliseriez pour faire pivoter la table se trouve dans la section suivante de cet article.
year=q.year,
SUM(CASE quarter WHEN 1 THEN amount ELSE 0 END) as Q1,
SUM(CASE quarter WHEN 2 THEN amount ELSE 0 END) as Q2,
SUM(CASE quarter WHEN 3 THEN amount ELSE 0 END) as Q3,
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
13/08/2021 • 2 minutes to read
Cet article vous aide à résoudre le problème de délai d’SQL lors du déploiement d’objets CLR Visual Studio.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2011805
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 :
Message d’erreur 2 :
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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 322884
Plus d’informations
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
15/08/2021 • 6 minutes to read
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.
Version du produit d’origine : SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012
Numéro de la ko d’origine : 2922898
Symptômes
Prenons l’exemple du scénario suivant :
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
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 :
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é.
Solution de contournement
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.
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.
Plus d’informations
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 2012 Enterprise
SQL Server 2014 Enterprise
SQL Server 2014 Business Intelligence
SQL Server 2014 Standard
SQL Server 2016 Enterprise
SQL Server 2016 Standard
SQL Server 2017 Enterprise
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
14/08/2021 • 12 minutes to read
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é.
Version du produit d’origine : SQL Server 2012
Numéro de la ko d’origine : 2857849
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
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.
Plus d’informations
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 :
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é :
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é :
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 :
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 :
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 :
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é.
À 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.
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
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
Numéro de la ko d’origine : 2792139
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.
Plus d’informations
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
13/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 4040549
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.
Plus d’informations
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
14/08/2021 • 8 minutes to read
Cet article vous aide à résoudre les problèmes qui se produisent lors du SQL Server.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2833707
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.
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.
Cet article décrit plusieurs raisons possibles pour lesquelles le failover automatique peut échouer et comment
diagnostiquer chaque cause.
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 :
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.
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 :
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.
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 :
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.
Version du produit d’origine : SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2016
Enterprise
Numéro de la ko d’origine : 10179
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
Si le problème existe toujours, consultez plus d’informations sur les groupes de disponibilité AlwaysOn.
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)
Si le problème existe toujours, consultez plus d’informations sur les groupes de disponibilité AlwaysOn.
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)
Si le problème existe toujours, consultez plus d’informations sur les groupes de disponibilité AlwaysOn.
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
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 2490051
Symptôme
Prenons l’exemple du scénario suivant :
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
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 :
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
15/08/2021 • 3 minutes to read
Cet article vous aide à résoudre le problème qui se produit si des clés de Registre spécifiques aux ressources
sont manquantes.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 883732
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.
Message d’erreur 1
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é.
Message d’erreur 2
Un message d’erreur semblable au suivant se trouve dans le fichier journal du cluster :
Message d’erreur 3
Les messages d’erreur semblables aux suivants sont dans le SQL Server journal des erreurs :
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
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.
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 .
Plus d’informations
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
13/08/2021 • 4 minutes to read
Cet article vous aide à résoudre le problème qui se produit lorsque vous installez SQL Server sur Windows
cluster de serveurs.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 953748
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 »
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 :
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.
Solution de contournement
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 :
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.
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
14/08/2021 • 2 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 295732
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.
Plus d’informations
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
12/08/2021 • 2 minutes to read
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
Numéro de la ko d’origine : 4082888
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 :
Cause
Le bouton Autorisations héritées est activé pour le dossier choisi pour les emplacements de base de données.
Solution de contournement
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
13/08/2021 • 3 minutes to read
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.
Version du produit d’origine : Microsoft SQL Server
Numéro de la ko d’origine : 810056
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.
Plus d’informations
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 :
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 :
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
14/08/2021 • 5 minutes to read
Cet article décrit la stratégie de support Microsoft pour les configurations en cluster de SQL Server avec
Windows Server.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 327518
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 2012 R2
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 :
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.
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.
Plus d’informations
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 à
SQL Server 2008 Developer
SQL Server 2008 Enterprise
SQL Server 2008 Standard
SQL Server 2008 R2 Datacenter
SQL Server 2008 R2 Developer
SQL Server 2008 R2 Enterprise
SQL Server 2012 Analysis Services
SQL Server 2012 Business Intelligence
SQL Server 2012 Developer
SQL Server 2012 Enterprise
SQL Server 2012 Standard
SQL Server 2012 Enterprise Core
SQL Server Développeur 2014
SQL Server 2014 Enterprise
SQL Server 2014 Enterprise Core
SQL Server 2014 Standard
SQL Server Développeur 2016
SQL Server 2016 Enterprise
SQL Server 2016 Enterprise Core
SQL Server 2016 Standard
Microsoft Windows des ressources de cluster de
SQL Server
14/08/2021 • 7 minutes to read
Cet article présente les dépendances de ressources par défaut dans SQL Server et les restrictions sur ces
dépendances.
Version du produit d’origine : SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012, SQL
Server 2008
Numéro de la ko d’origine : 835185
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
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.
Plus d’informations
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) :
S’applique à
SQL Server 2008 Standard
SQL Server 2008 Enterprise
SQL Server Développeur 2008
SQL Server 2008 R2 Datacenter
SQL Server 2008 R2 Developer
SQL Server 2008 R2 Enterprise
SQL Server 2008 R2 Standard
SQL Server 2008 R2 Édition Standard for Small Business
SQL Server 2008 R2 Express avec services avancés
SQL Server 2008 R2 Workgroup
SQL Server Développeur 2012
SQL Server 2012 Enterprise
SQL Server 2012 Standard
SQL Server 2012 Enterprise Core
SQL Server 2014 Enterprise
SQL Server 2014 Enterprise Core
SQL Server 2014 Standard
SQL Server 2014 Business Intelligence
SQL Server 2016 Enterprise Core
SQL Server 2016 Enterprise
SQL Server Développeur 2016
SQL Server 2016 Standard
SQL Server 2017 Windows (toutes les éditions)
Configurer la sécurité pour la SQL Server des
journaux de bord
14/08/2021 • 9 minutes to read
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.
Version du produit d’origine : SQL Server
Numéro de la ko d’origine : 321247
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.
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 .
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).
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.
Version du produit d’origine : Microsoft SQL Server
Numéro de la ko d’origine : 2006312
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 :
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
Plus d’informations
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
13/08/2021 • 5 minutes to read
Cet article décrit la .NET Framework requise pour différentes versions SQL à partir de SQL Server 2005.
Version du produit d’origine : SQL Server 2019, SQL Server 2017, SQL Server 2014, SQL Server 2012, SQL
Server 2008, SQL Server 2005
Numéro de la ko d’origine : 2027770
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
Configuration matérielle et logicielle requise pour SQL Server 2017
Configuration matérielle et logicielle requise pour SQL Server 2016
Configuration matérielle et logicielle requise pour SQL Server 2014
Configuration matérielle et logicielle requise pour SQL Server 2012
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.
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.
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?
3.5 SP1 3.5.30729.1 Windows Serv Aucun Aucun 3.5 SP1 Oui, pour
er 2008 R2 Windows
Server 2008
R2
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
13/08/2021 • 3 minutes to read
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
Numéro de la ko d’origine : 4594205
Symptômes
Prenons l’exemple du scénario suivant :
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 :
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.
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.
Plus d’informations
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
15/08/2021 • 2 minutes to read
Cet article explique pourquoi ce dossier est créé et à quoi il est utilisé.
Version du produit d’origine : SQL Server 2008, SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL
Server 2017 sur Windows (toutes les éditions)
Numéro de la ko d’origine : 3196535
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é.
Plus d’informations
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é a