Exigences du sous-système d’e/s de Microsoft SQL Server pour la base de données tempdb

S’applique à : Microsoft SQL Server 2005 Express EditionMicrosoft SQL Server 2005 Standard EditionMicrosoft SQL Server 2005 Workgroup Edition

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 entièrement respectent les exigences de Write-Ahead Logging (WAL) par l’intermédiaire des entités d’e/s spécifiques. Ces exigences sont nécessaires pour respecter les propriétés ACID des transactions : atomique, cohérente, isolée et Durable. Vous trouverez plus d’informations sur les exigences de conformité du sous-système d’e/s dans les références suivantes :La liste suivante est un résumé rapide de la configuration requise :
  • Ordre d’écriture doit être maintenue.
  • La cohérence des écritures dépendantes doit être maintenue.
  • Écritures doivent toujours être sécurisés dans/sur un support stable.
  • Déchirée prévention d’e/s doit se produire.
Maintenance de durabilité reste essentiel pour toutes les autres bases de données, mais peut être assouplie pour la base de données tempdb . Le tableau suivant résume plusieurs des exigences d’e/s critiques pour les bases de données SQL Server.
Demande d’e/sBrève descriptionSystème ou utilisateurtempdb
Écrire des commandes

Cohérence des écritures dépendantes
La capacité du sous-système de maintenir l’ordre correct des opérations d’écriture. Cela peut être particulièrement important pour la mise en miroir des solutions, les exigences de cohérence de groupe et l’utilisation du protocole WAL de SQL Server.ObligatoireRecommandé
Lecture après écritureLa capacité du sous-système au service des demandes avec la dernière image de données de type lecture lorsque la lecture est émise après que toute écriture est effectuée avec succès.ObligatoireObligatoire
Survie sur panneLa possibilité pour les données restent entièrement intacts (durables) sur une panne, par exemple un système de redémarrer.ObligatoireNe s'applique pas
Prévention d’e/s déchiréeLa capacité du système, pour éviter de fractionner les demandes d’e/s individuelles.ObligatoireRecommandé
Réécriture du secteurLe secteur peut uniquement être écrit dans son intégralité et ne peut pas être réécrite en raison d’une demande d’écriture sur un secteur à proximité.* Déconseillée, uniquement autorisés si transactionnelle* Déconseillée, uniquement autorisés si transactionnelle
Sécurité renforcée des donnéesL’attente que lorsqu’une demande d’écriture ou une opération FlushFileBuffers est effectuée avec succès, des données ont été enregistrées sur un support stable.ObligatoireNe s'applique pas
Taille et l’alignement de secteur physiqueSQL Server interroge les emplacements de stockage des fichiers journaux et de données. Tous les périphériques sont nécessaires pour prendre en charge les attributs de secteur permettant de SQL Server pour effectuer des écritures sur des limites physiques aligné sur le secteur et d’un multiple de la taille de secteur.ObligatoireObligatoire
* Secteur transactionnelle réécritures impliquent des opérations entièrement consignées par le sous-système autoriser un secteur à être entièrement déplacé, remplacé ou restaurée à l’image d’origine. Ces réécritures sont généralement déconseillés en raison des temps de traitement requis pour effectuer des actions supplémentaires. Un exemple de cela est un utilitaire de défragmentation qui déplace les données du fichier. Impossible de remplacer le secteur d’origine dans le fichier avec le nouvel emplacement de secteur jusqu'à ce que le nouveau secteur et les données sont entièrement sécurisées. Le remappage du secteur doit se produire de façon transactionnelle afin que tout échec, y compris une panne de courant, 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 genre de processus pour empêcher l’accès des données non valides, ainsi bas les autres locataires d’e/s de SQL Server.

Survie sur panne

La base de données tempdb est une zone de brouillon pour SQL Server et est reconstruite à chaque démarrage de SQL Server. L’initialisation remplace n’importe quel besoin en données de résister à un redémarrage.

Opérations de réécriture secteur transactionnelle

Pour garantir la réussite des processus de récupération, tel que la récupération sur incident et de restauration, les enregistrements du journal doivent être correctement stockés sur un support stable avant la page de données est stockée et ne peut pas être réécrite sans en respectant les propriétés transactionnelles. Cela nécessite le sous-système et SQL Server pour mettre à jour des attributs spécifiques, tels que de l’ordre d’écriture, secteur alignée et taille d’écriture et autres ces attributs de sécurité d’e/s indiquées dans les documents mentionnés précédemment. La base de données tempdb , la récupération après incident n’est pas nécessaire, car la base de données est toujours initialisée lors du démarrage de SQL Server. Toutefois, la base de données tempdb nécessite toujours des possibilités de retour. Par conséquent, certains attributs du protocole WAL peuvent être assouplies.

L’emplacement de stockage pour la base de données tempdb doit agir en stricte conformité avec les protocoles de disque établie. Dans tous les cas, le périphérique sur lequel se trouve la base de données tempdb doit apparaître et d’agir comme un disque physique fournissant la lecture après les capacités d’écriture. Opérations de réécriture de secteur de transaction peuvent être une exigence supplémentaire des implémentations spécifiques. Par exemple, SQL Server ne gère pas les modifications à l’aide de compression du système de fichiers NTFS car la compression NTFS peut réécrire des secteurs du journal qui ont déjà été écrit et considéré comme renforcées de la base de données. Une défaillance au cours de ce type de réécriture peut provoquer inutilisable, endommage les données de la base de données que SQL Server déjà considéré comme sécurisé.

Remarque SQL Server 2005 étendu de compression ou prise en charge pour lire uniquement les bases de données et les groupes de fichiers. Consultez le SQL Server 2005 Books Online pour plus de détails.

Opérations de réécriture secteur transactionnelle sont appliquent à toutes les bases de données SQL Server qui incluent la base de données tempdb . Une diversité croissante des technologies de stockage étendu utilisent des périphériques et utilitaires qui peuvent réécrire des données de SQL Server estime sécurisé. Par exemple, certaines des nouvelles technologies effectuent en mémoire cache ou la compression de données. Afin d’éviter les dommages graves de la base de données, n’importe quel secteur de réécriture doit être prise en charge transactionnelle complète de telle sorte que si une défaillance se produit, les données sont restaurées vers les images de secteur précédente. Cela garantit que SQL Server n’est jamais exposée à une interruption inattendue ou l’avarie de données.

Vous ne pourrez pas placer la base de données tempdb sur des sous-systèmes spécialisés, tels que des disques virtuels, à l’état solide ou d’autres implémentations à grande vitesse qui ne peut pas être utilisées pour d’autres bases de données. Toutefois, les facteurs clés présentés dans la section « Informations supplémentaires » prendre en considération lors de l’évaluation de ces options.

Plus d'informations


Plusieurs facteurs doivent être étudiées avec soin 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, mais il n’est pas limitée à, faible encombrement mémoire, plan de requête et les décisions d’e/s. Le réglage approprié et la mise en oeuvre de la base de données tempdb peuvent améliorer l’évolutivité et la réactivité d’un système. Cette section explique les facteurs déterminants pour déterminer les besoins en stockage de la base de données tempdb .

Sous-systèmes à grande vitesse

Il existe diverses implémentations de sous-système haute vitesse sur le marché qui fournissent des exigences du protocole sous-système e/s de SQL Server, mais qui ne fournissent pas de durabilité du support.

Important Toujours confirmer avec le fabricant du produit afin de garantir la pleine conformité avec les besoins d’e/s de SQL Server.

Un disque virtuel est un exemple courant de cette implémentation. Les disques RAM installer les pilotes nécessaires et activer des partie du disque RAM principal s’affiche en tant qu’et fonctionne comme n’importe quel lecteur de disque qui est connecté au système. Tous les sous-systèmes d’e/s doivent fournir la pleine conformité avec les exigences d’e/s de SQL Server. Toutefois, il est évident qu’un disque de RAM n’est pas support durable. Par conséquent, une implémentation telle qu’un disque virtuel peut uniquement être utilisée comme l’emplacement de la base de données tempdb et ne peut pas être utilisée pour toute autre base de données.

Clés à prendre en compte avant la mise en œuvre et de déploiement

Il y a différents points à prendre en compte 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 les résultats similaires se produisent dans d’autres implémentations à grande vitesse.

Sécurité d’e/s

Conformité de lecture après écriture et écritures de secteur transactionnelle est indispensable. Jamais de déployer SQL Server sur un système qui ne prend pas entièrement en charge les exigences d’e/s de SQL Server, ou vous risquez de dommages et la perte de vos données.

Pages déjà en cache (cache RAM Double)

Les tables temporaires sont comme toutes les autres tables dans une base de données. Ils sont mis en cache par le pool de tampons et gérés par les opérations d’écriture différée. Stocker les pages de table temporaire sur un disque virtuel entraîne la RAM double la mise en cache, une dans le pool de tampons et l’autre sur le disque RAM. Cela prend directement à partir de la taille du pool de mémoire tampon possible et généralement diminue les performances de SQL Server.

Abandonner la RAM

Le disque RAM désigne une partie de la mémoire RAM principale, comme son nom l’indique. Il existe plusieurs implémentations de disques RAM et les caches de fichiers basés sur la mémoire vive disponible. Certains permettent également d’e/s physiques, les opérations de sauvegarde. L’élément clé du cache du fichier de base de RAM est qu’il prend directement la mémoire physique qui peut être utilisée par SQL Server. Toujours avoir une preuve évidente que l’ajout un cache basé sur la mémoire vive de fichiers améliore les performances de l’application et ne diminue pas des performances de la requête ou de l’application.

Tout d’abord de régler

Une application doit régler pour supprimer les hachages qui pourraient entraîner l’utilisation de la base de données tempdb et les tris inutiles et indésirables. Nombre de fois où l’ajout d’un index peut supprimer la nécessité de tri ou de hachage dans le plan, de pointe pour des performances optimales sans exiger l’utilisation de la base de données tempdb .

Avantage possible de points

Les avantages de mettre la base de données tempdb sur un système à grande vitesse ne peuvent être déterminées grâce à des tests rigoureux et des mesures des charges de travail d’application. La charge de travail doit être soigneusement étudié les caractéristiques qui peut-être bénéficier de la base de données tempdb , et la sécurité d’e/s doit être confirmée avant le déploiement.

Les opérations de tri et de hachage fonctionnent avec les gestionnaires de mémoire de SQL Server pour déterminer la taille de la zone de travail 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 le plan de montage de mémoire alloué, les données peuvent être écrites dans la base de données tempdb . Cet algorithme a été développé dans SQL Server 2005, ce qui réduit les demandes d’utilisation de base de données tempdb sur des versions antérieures de SQL Server. Par exemple, en utilisant un tri pur forcé d’une table, sans index, l’ordre décroissant et la même configuration matérielle, SQL Server 2005 affiche des améliorations notables par rapport à SQL Server 2000.

Attention SQL Server est conçu pour prendre en compte les niveaux de mémoire et les activités de requête en cours 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 performance varient considérablement en fonction des charges de travail et de la conception de l’application. Nous vous recommandons de procéder à la meilleure solution pour déterminer les gains possibles et d’évaluer les besoins de sécurité d’e/s avant un tel déploiement de test.

SQL Server utilise la base de données tempdb pour gérer les diverses activités impliquant des tris, des hachages, le magasin de version de ligne et tables de température :
  • Les tables temporaires sont conservées par les routines de pool de mémoire tampon commune pour les pages de données et en règle générale, ne présentent pas des avantages de performance à partir des implémentations de sous-système de spécialisation.
  • La base de données tempdb est utilisée comme zone de travail pour les hachages et les tris. Réduction de la latence d’e/s pour des opérations peut être utile. Toutefois, connaître que l’ajout d’un index pour éviter un hachage ou un tri peut fournir le même avantage.
Exécuter des lignes de base avec et sans la base de données tempdb sur le sous-système haute vitesse pour comparer les avantages. Partie des essais doit inclure des requêtes sur la base de données de l’utilisateur qui n’impliquent des tris, des hachages ou des tables temporaires et confirmez que ces requêtes ne sont pas affectés de façon défavorable. Lorsque vous évaluez le système, les indicateurs de performance suivants peuvent être utiles.
IndicateurDescription/usage
Page lectures et écrituresAmélioration des performances de tempdb la base de données e/s peut changer le taux de lectures de page et les écritures des bases de données utilisateur en raison de la latence réduite associée à la base de données tempdb d’e/s. Pour les pages de base de données d’utilisateur, le nombre global ne doit pas varier au sein de la même charge de travail.
Physique, lire et écrire des octets vers la base de données tempdbSi le déplacement de la base de données tempdb sur un périphérique, tel qu’un disque RAM, augmente l’e/s réelles de la base de données tempdb , il indique que la mémoire du pool de tampons est à l’origine une activité de base de données accrue tempdb à se produire. Ce modèle est un indicateur que l’espérance de vie de page de base de données des pages mai également être affectées de manière négative.
Espérance de vie de pageUne baisse de l’espérance de vie de page peut indiquer une augmentation des exigences d’e/s physiques pour une base de données de l’utilisateur. La diminution du taux indique probablement que la mémoire du pool de tampons oblige les pages de base de données pour quitter le pool de tampons prématurément. Combiner avec les autres indicateurs et de test afin de comprendre parfaitement les limites du paramètre.
Débit global
Utilisation de l’UC
Évolutivité
Temps de réponse
L’objectif principal d’un changement de configuration de base de données tempdb est d’augmenter le débit global. Votre test doit inclure une combinaison des charges de travail reproductibles qui peut être distribuée horizontalement afin de déterminer la manière dont le débit est affecté.

Par exemple, une implémentation basée sur la compression de disque RAM peut fonctionner avec 10 utilisateurs. Toutefois, la charge de travail accrue, peut pousser les niveaux du processeur au-delà des niveaux souhaités et avoir des effets négatifs sur le temps de réponse lorsque les charges de travail sont élevés. Les tests de stress trues futures prévision et tests de charge sont vivement encouragés.
Fichiers de travail et les actions de création de table de travailSi la base de données tempdb sur un périphérique, tel qu’un disque RAM, changement du plan de requête en augmentant le nombre ou la taille des fichiers de travail ou des tables de travail, il indique que la mémoire du pool de tampons est à l’origine une activité de base de données accrue tempdb à se produire. Ce modèle est une indication que l’espérance de vie de page des pages de base de données peuvent également être affectée de manière négative.

Exemple de réécriture secteur transactionnelle

L’exemple suivant décrit plus en détail la sécurité des données requis par les bases de données SQL Server.

Supposons qu'un fournisseur du disque RAM utilise une implémentation de la compression en mémoire. La mise en oeuvre doit être encapsulé correctement en fournissant l’apparence physique du flux de fichier, comme si le secteur a été aligné et dimensionné de sorte que SQL Server est ignore et correctement sécurisé à partir de l’implémentation sous-jacente. Examinez de plus près l’exemple de compression.
Action
Secteur 1 est écrit sur le périphérique et est compressée pour économiser de l’espace.
Secteur 2 est écrit sur le périphérique et est compressé avec le secteur 1 pour économiser de l’espace.
Le périphérique peut effectuer les actions suivantes pour aider à sécuriser les données de secteur de 1 lorsqu’il est combiné avec des données de secteur 2.
Action
Bloquer toutes les écritures dans les secteurs 1 et 2.
Décompressez le secteur 1 dans une zone de travail, sorties du stock de secteur 1 en cours en tant que les données actives à récupérer.
Compressez les secteurs 1 et 2 dans un nouveau format de stockage.
Bloquer toutes les lectures et écritures des secteurs 1 et 2.
Stockage ancien secteurs 1 et 2 avec un nouveau stockage pour Exchange.
Si la tentative d’exchange échoue (rollback) :
  • Restaurer le stockage d’origine pour les secteurs 1 et 2.
  • Supprimer les données de secteurs 1 et 2 combinées à partir de la zone de travail.
  • Échec de l’opération d’écriture le secteur 2.
Débloquer les lectures et écritures des secteurs 1 et 2.
La possibilité de fournir des mécanismes de verrouillage autour de la modification du secteur et d’annuler les modifications en cas d’échec de la tentative d’exchange de secteur est considéré comme conforme transitoirement. Pour les implémentations qui utilisent le stockage physique pour le stockage étendu, il inclut les aspects du journal de transaction approprié pour aider à sécuriser et annuler les modifications qui ont été appliquées aux structures sur disque pour maintenir l’intégrité des fichiers de base de données SQL Server.

N’importe quel périphérique qui permet la réécriture des secteurs doit prendre en charge les réécritures de façon transactionnelle afin que SQL Server n’est pas exposée à une perte de données.

Remarque L’instance de SQL Server est redémarré lorsque les e/s en ligne et les échecs de restauration se produisent dans la base de données tempdb .

Soyez prudent lorsque vous déplacez la base de données tempdb

Soyez prudent lorsque vous déplacez la base de données tempdb , car si la base de données tempdb ne peut pas être créé, SQL Server ne démarre pas. Si la base de données tempdb ne peut pas être créé, démarrez SQL Server en utilisant le (-f) paramètre de démarrage et de déplacer la base de données tempdb à un emplacement valide.

Pour modifier l’emplacement physique de la base de données tempdb , procédez comme suit :
  1. Pour modifier les noms de fichier physique de chaque fichier dans la base de données tempdb pour faire référence à un nouvel emplacement physique, tel que le nouveau disque, utilisez l’instruction ALTER DATABASE et la clause MODIFY FILE.
    Alter database tempdb modify file 
    (name = tempdev, filename = 'C:\MyPath\tempdb.mdf')

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

Certifications de produits partenaires ne sont pas un garantir de compatibilité ou de sécurité

Un produit tiers ou un fournisseur particulier peut recevoir un logo de certification Microsoft. Toutefois, certification partenaire ou un logo spécifique de Microsoft ne certifie pas la compatibilité ou l’adéquation à un usage particulier dans SQL Server.

Prise en charge

Si vous utilisez un sous-système avec SQL Server qui prend en charge les garanties d’e/s pour une utilisation de base de données transactionnelle comme décrit dans cet article, Microsoft fournira la prise en charge de SQL Server et les applications basées sur SQL Server. Toutefois, des problèmes, ou dû, le sous-système sera fait référence au fabricant.

Pour les problèmes liés à la base de données tempdb , les Services de support technique de Microsoft vous demande de déplacer la base de données tempdb . Contactez votre fournisseur de périphérique pour vérifier que vous avez correctement déployé et configuré le périphérique pour une utilisation de base de données transactionnelle.

Microsoft ne certifie pas ou ne sont pas valider que des produits tiers fonctionnent correctement avec SQL Server. En outre, Microsoft ne fournit pas toute garantie ou déclaration d’adéquation du produit de tout tiers pour une utilisation avec SQL Server.

Références


Pour plus d’informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :

826433 PRB : diagnostics supplémentaires de SQL Server pour détecter les problèmes d’e/s non signalés

828339 message d’erreur 823 peut indiquer des problèmes de matériel ou système dans SQL Server

234656 à l’aide de la mise en cache du lecteur de disque avec SQL Server

Description de 304261 de prise en charge pour les fichiers de base de données réseau dans SQL Server

913945 Microsoft ne certifie pas la que des produits tiers fonctionneront avec Microsoft SQL Server

Exigences en matière de 910716 pour SQL Server 2005 et SQL Server 2000 pour prendre en charge la mise en miroir à distance de bases de données utilisateur

917043 les facteurs de clé à prendre en compte lors de l’évaluation des systèmes de cache de fichiers tiers avec SQL Server

À l’aide de SSDs dans Azure VM pour stocker TempDB de SQL Server et des Extensions de Pool de mémoire tampon

Méthodes conseillées en matière de performances de SQL Server sur des Machines virtuelles Azure

Optimisation de votre requête Plans avec le SQL Server estimation de cardinalité 2014

Performances de la requête


Les informations contenues dans ce document représentent l’affichage actuel de Microsoft Corporation sur les points cités à la date de publication. Étant donné que Microsoft doit s’adapter aux conditions changeantes du marché, il ne doit pas être interprétée comme un engagement de la part de Microsoft, et Microsoft ne peut garantir l’exactitude des informations présentées après la date de publication.

Ce livre blanc est publié à des fins d’information. MICROSOFT NE FAIT AUCUNE GARANTIE, EXPRESSE, IMPLICITE OU LÉGALE CONCERNANT LES INFORMATIONS CONTENUES DANS CE DOCUMENT.

Respecter toutes les lois sur le copyright est la responsabilité de l’utilisateur. Sans limitation des droits d’auteur, aucune partie de ce document peut être reproduit, stocké dans ou introduite dans un système de récupération ou transmise sous quelque forme ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement ou autre) ou à toute fin, sans la permission expresse et écrite de Microsoft Corporation.

Microsoft peut avoir des brevets, brevets, marques, droits d’auteur ou autres droits de propriété intellectuelle couvrant un sujet dans ce document. Sauf disposition expressément stipulée dans un contrat de licence écrit de Microsoft, la fourniture de ce document non permet 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 soit des marques déposées ou des marques déposées de Microsoft Corporation aux États-Unis et/ou dans d’autres pays.
SQL Server nécessite des systèmes pour prendre en charge la « remise garantie sur un support stable » comme indiqué dans les Conditions du programme d’e/s la fiabilité de SQL ServerPour plus d’informations sur la configuration d’entrée et de sortie pour le moteur de base de données SQL Server, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :

Configuration requise de base de données moteur d’entrée/sortie 967576 de Microsoft SQL Server