Configuration requise de sous-système e / S Microsoft SQL Server pour la base de données tempdb

Traductions disponibles Traductions disponibles
Numéro d'article: 917047 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Microsoft SQL Server nécessite que le sous-système d'E / S utilisé pour stocker des bases de données système et utilisateur entièrement respectent les exigences Write-transfert WAL (enregistrement) via les entités d'E / S spécifiques. Ces exigences sont nécessaires dans ordre pour tient compte des propriétés de transactions ACID : atomic, cohérent, isolé et durable. Détails sur les exigences de conformité sous-système d'E / S sont fournis dans les références suivantes :La liste suivante est un résumé rapide de la configuration requise :
  • Classement des écritures doivent être conservés.
  • Cohérence écriture dépendants doit être conservé.
  • Écritures doivent toujours être sécurisées de/sur le média stable.
  • Prévention des e / S déchirée doit exister.
Maintenance de durabilité demeure essentiel pour toutes les autres bases de données mais peut être souple pour la base de données tempdb . Le tableau suivant résume plusieurs les exigences d'E / S critiques pour bases de données SQL Server.
Réduire ce tableauAgrandir ce tableau
demande d'E / S brève description système ou utilisateur tempdb
commande écriture

Cohérence écriture dépendants
La possibilité du sous-système de conserver l'ordre correct des opérations d'écriture. Ceci peut être particulièrement important pour la mise en miroir des solutions, groupe cohérence exigences et SQL Server WAL protocole Utilisation.RequisRecommandé
lire après l'écriture La capacité du sous-système du service de demandes de lecture avec l'image données dernière lorsque la lecture est émise une fois toute écriture terminée avec succès.RequisRequis
survie sur panne La capacité des données soient totalement intact (durable) sur une défaillance, par exemple un système de redémarre.RequisNon applicable
Prévention de l'erreur d'E / S La capacité du système à éviter de fractionner requêtes d'E / S individuelles.RequisRecommandé
secteur de réécrire Le secteur peut uniquement être écrits dans son intégralité et ne peut pas être réécrite en raison d'une demande en écriture sur un secteur à proximité.* Déconseillé, uniquement si transactionnelle* Déconseillé, uniquement si transactionnelle
données renforcé Partant du principe que lorsqu'une demande d'écriture ou une opération FlushFileBuffers est correctement terminée, les données a été enregistrées sur média stable.RequisNon applicable
Alignement de secteur physique et la taille SQL Server interrogates les emplacements de stockage de fichiers journaux et de données. Tous les périphériques sont nécessaires pour prendre en charge les secteurs attributs autorisant SQL Server pour effectuer des écritures sur des limites Alignement de secteur physiques et par multiples de la taille de secteur.RequisRequis
Secteur * transactionnelle récrit implique opérations entièrement connectées par le sous-système autorisant un secteur d'être entièrement déplacé, remplacé ou restaurée vers l'image d'origine. Ces récrit est généralement déconseillé en raison de la surcharge requis pour effectuer ces actions supplémentaires. Un exemple de ce serait un utilitaire de défragmentation se déplace les données du fichier. Le secteur d'origine dans le fichier ne peut pas être remplacé par le nouvel emplacement du secteur jusqu'à ce que le nouveau secteur et les données sont entièrement sécurisées. Remappage du secteur doit exister de manière transactionnelle afin que toute défaillance, y compris une panne de courant, provoque le re-establishment des données d'origine. Assurez-vous que vous disposez mécanismes de verrouillage disponibles lors de ce type de processus pour empêcher les accès de données non valides, bas et les autres domaines d'E / S SQL Server.

Survie sur panne

La base de données tempdb est un plan de montage pour SQL Server et est recréée sur chaque démarrage de SQL Server. L'initialisation remplace nécessaire pour données survivre un redémarrage.

Opérations de réécriture secteur transactionnelle

Pour garantir la réussite des processus de récupération, tels que récupération restauration et de blocage, les enregistrements du journal doivent être correctement stockés sur le média stable avant de la page de données est stockée et ne peut pas être réécrite sans Honorer propriétés transactionnelles. Cela nécessite le sous-système et les SQL Server pour gérer attributs spécifiques, tels que classement des écritures, secteur alignés et dimensionné écritures et autres ces attributs de le sécurité e / S décrites dans les documents mentionnés précédemment. Pour la base de données tempdb , la récupération sur incident est inutile parce que la base de données est toujours initialisée lors du démarrage de SQL Server. Toutefois, la base de données tempdb requiert toujours les capacités de restauration. Par conséquent, certains attributs du protocole WAL peuvent être détendus.

L'emplacement de stockage de la base de données tempdb doit agir en conformité stricte avec protocoles du lecteur de disque établies. De toutes les manières, le périphérique sur lequel est stockée la base de données tempdb doit s'affichent et servir d'un disque physique fournissant lecture après les capacités d'écriture. Transaction secteur réécriture opérations peuvent être un besoin supplémentaire des implémentations spécifiques. Par exemple, SQL Server ne prend pas en charge les modifications apportées à l'aide compression du système de fichiers NTFS car la compression NTFS peut être réécrites secteurs du journal qui ont déjà été écrit et considéré comme renforcées de base de données. Une erreur lors de ce type de réécriture peut entraîner la base de données soit inutilisable, endommager les données que SQL Server est déjà considéré comme sécurisé.

note SQL Server 2005 étendu support ou de compression pour lire uniquement les bases de données et les groupes de fichiers. Consultez la la SQL Server 2005 documentation en ligne pour complète d'informations.

Opérations de réécriture secteur transactionnelle sont pertinentes pour les bases de tous les SQL Server données incluent la base de données tempdb . Croissant différentes technologies de stockage étendu utilisez périphériques et les utilitaires qui peuvent être réécrites données SQL Server considère comme sécurisé. Par exemple, quelques-unes des nouvelles technologies effectuer en mémoire cache ou la compression de données. Pour éviter de base de données graves dommages, tout réécriture secteur doit disposer prise en charge transactionnelle complète de telle sorte que cas d'un échec, les données sont restaurées vers les images de secteur précédente. Cela garantit que SQL Server est jamais exposée à une interruption inattendue ou condition de dommages de données.

Il est possible de placer la base de données tempdb sur spécialité sous-systèmes, comme les disques de mémoire vive (RAM), état solide ou autres implémentations haute vitesse ne peuvent pas être utilisés pour d'autres bases de données. Toutefois, les facteurs clés présentées dans la section ? Plus d'informations ? doivent être considérées comme lorsque vous évaluez ces options.

Plus d'informations

Plusieurs facteurs doivent être soigneusement étudiés lorsque vous évaluez l'emplacement de stockage de la base de données tempdb . Par exemple, l'utilisation de base de données tempdb implique, mais est pas limitée à, occupation en mémoire, de plan de requête et de décisions d'E / S. Les tuning approprié et l'implémentation 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 de stockage pour la base de données tempdb .

Sous-systèmes haute vitesse

Différentes implémentations de sous-système haute vitesse sont disponibles sur le marché qui fournissent des exigences de protocole sous-système e / S de SQL Server mais qui ne fournit pas durabilité du média.

important Vérifiez toujours avec le fournisseur de produit afin de garantir la conformité complète avec les besoins d'E / S de SQL Server.

Un disque virtuel est un exemple courant d'une telle implémentation. Disques de mémoire vive (RAM) installer les pilotes nécessaires et activer partie du disque virtuel principal apparaissent en tant qu'et fonctionnent comme n'importe quel lecteur de disque est attaché au système. Tous les sous-systèmes d'E / S doivent fournir la conformité complète avec les exigences SQL Server d'E / S. Toutefois, il est évident qu'un disque virtuel n'est pas support durable. Par conséquent, une implémentation telle qu'un disque RAM ne peut être utilisée comme emplacement de la base de données tempdb et ne peut pas servir d'une autre base de données.

Touches pour prendre en compte avant implémentation et de déploiement

Il existe différents points à considérer 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 pour étude, mais des résultats similaires surviennent dans les autres implémentations haute vitesse.

Sécurité d'E / S

La conformité de lecture après écriture et écrit secteur transactionnelle est indispensable. Ne jamais déployer SQL Server sur tout système qui ne prend pas totalement 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à mis en cache (cache de mémoire VIVE double)

Les tables temporaires sont comme pour les 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 la table temporaire sur un disque RAM provoque RAM double mise en cache, dans le pool de tampons et une sur le disque RAM. Cela prend directement de taille totale possible sur ?s le pool de tampons et généralement diminue les performances de SQL Server.

Abandonner mémoire vive (RAM)

Le disque RAM désigne une partie de mémoire RAM principale comme l'indique le nom. Il n'y a plusieurs implémentations de disques mémoire vive (RAM) et les caches de fichiers en fonction de RAM disponible. Certains permettent également d'E / S physique opérations de sauvegarde. L'élément clé du cache des fichiers en fonction de RAM est qu'il faut directement éloigné de la mémoire physique peut être utilisée par SQL Server. Ont toujours preuve renforcée qu'ajouter un cache de fichiers en fonction de RAM améliore les performances d'application et ne diminuent pas autres performances requête ou une application.

Régler tout d'abord

Une application doit régler pour supprimer les tris inutiles et indésirables et hachages qui peuvent provoquer l'utilisation de la base de données tempdb . Autant de fois l'ajout d'un index peut supprimer le besoin du tri ou le hachage dans le plan complètement, conduisant à des performances optimales sans exiger l'utilisation de la base de données tempdb .

Points possibles des avantages

Les avantages d'utilisation de la base de données tempdb sur un système haute vitesse peuvent uniquement être déterminés via tests rigoureux et des mesures de l'application charges de travail. La charge de travail est étudié soigneusement caractéristiques de le la base de données tempdb peut-être tirer parti et la sécurité d'E / S doit être confirmée avant le déploiement.

Les opérations de tri et le hachage fonctionne et avec les gestionnaires de mémoire SQL Server pour déterminer la taille du plan d'en mémoire montage pour chaque opération tri ou de hachage. Dès que les données de tri ou de hachage dépassent d'alloué en mémoire montage, données peuvent être écrit dans la base de données tempdb . Cet algorithme a été développé dans SQL Server 2005, réduire les exigences de l'utilisation de base de données tempdb sur les versions antérieures de SQL Server. Par exemple, en utilisant un tri pur forcé d'une table, aucun index, décroissant ordre et la même configuration matérielle, SQL Server 2005 n'indique améliorations notables sur SQL Server 2000.

Avertissement SQL Server est conçu pour justifier niveaux de mémoire et les activités de requête en cours lorsque des décisions de plan de requête qui impliquent l'utilisation des opérations de base de données tempdb . Par conséquent, les gains de performance varient beaucoup selon les charges de travail et la conception application. Nous vous recommandons vivement d'effectuer tests avec la solution par défaut pour déterminer les gains possibles et évaluer les besoins de sécurité d'E / S avant tel un déploiement.

SQL Server utilise la base de données tempdb pour gérer diverses activités impliquant trie, hachages, le magasin de version de ligne et temp tables :
  • Tables temporaires sont maintenus par les routines de pool de mémoire tampon courants pour les pages données et généralement ne présentent pas une avantages de performance d'implémentations de sous-système spécialisé.
  • La base de données tempdb sert un plan de montage pour les valeurs de hachage et trie. Réduction de latence d'E / S de telles opérations peut être intéressant. Toutefois, besoin que l'ajout d'un index pour éviter un hachage ou un tri peut fournir un avantage similaire.
Exécuter les planifications initiales avec et sans la base de données tempdb stockées sur le sous-système haute vitesse pour comparer les avantages. Partie le test doit inclure des requêtes sur la base de données des utilisateurs qui ne pas impliquent trie, hachages ou des tables temporaires et puis confirmons que ces requêtes sont concernés pas affecter. Lorsque vous évaluez le système, les indicateurs de performance suivante peuvent être utiles.
Réduire ce tableauAgrandir ce tableau
indicateur Description de l'utilisation
page lit et écrit Améliorer les performances de la tempdb base de données e / S peut modifier le taux de lectures de page et des écritures pour les 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 utilisateur, le nombre global ne doit pas varier sur la même charge de travail.
physique lire et écrire les octets à la base de données tempdb Si atteindre la base de données tempdb un périphérique, tel qu'un disque RAM, augmente les e / S réelles pour la base de données tempdb , il indique que la mémoire du pool de mémoire tampon hors de pose 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 pages peut également être affectées de manière négative.
espérance de vie de page Un refus d'espérance de vie de page peut indiquer une augmentation des exigences d'E / S physiques pour une base de données utilisateur. La sortie de taux peut indiquer probablement que la mémoire du pool de mémoire tampon hors de forcer le pages de base de données pour quitter le pool de tampons prématurément. Combiner avec les autres indicateurs et tester pour bien comprendre les limites du paramètre.
débit global
L'utilisation du processeur
L'évolutivité
Délai de réponse
Le principal objectif d'un changement de configuration de base de données tempdb est pour augmenter le débit global. Votre test doit inclure un mélange de charges de travail reproductibles qui peut mis à être l'échelle pour déterminer comment débit est affectée.

Quelque chose comme une implémentation de disque RAM en fonction de compression peut fonctionner correctement avec 10 utilisateurs. Toutefois, avec une charge accrue, cela peut pousser les niveaux D'UC au-delà de niveaux souhaité et avoir des effets négatifs sur temps de réponse lorsque les charges de travail sont élevées. Cette propriété a la valeur trues tests de stress et de charge futures prévision tests sont vivement conseillés.
fichiers de travail et actions de création de table travail Si atteindre la base de données tempdb un périphérique, tel qu'un disque RAM, modifie le plan de requête en augmentant le nombre ou taille des fichiers de travail ou les tables de travail, il indique que la mémoire du pool de mémoire tampon hors de pose activité de base de données accrue tempdb à se produire. Ce modèle est une indication que l'espérance de vie 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 montre comment s'articule autour de la sécurité des données requis par les bases de données SQL Server.

Supposons qu'un fournisseur de disque RAM utilise une implémentation de compression en mémoire. L'implémentation doit être correctement encapsulée en fournissant l'apparence physique du flux de fichier comme si le secteur a été aligné et taille de sorte que SQL Server est correctement sécurisé de l'implémentation sous-jacente et ignore. Examinez l'exemple de compression plus près.
Réduire ce tableauAgrandir ce tableau
action
Secteur 1 est écrit sur le périphérique et est compressée afin d'économiser de l'espace.
Secteur 2 est écrit sur le périphérique et est compressé avec secteur 1 pour économiser de l'espace.
Le périphérique peut effectuer les actions suivantes pour sécuriser les données de secteur ?s 1 lorsqu'il est associé à des données de secteur ?s 2.
Réduire ce tableauAgrandir ce tableau
action
Bloquer toutes les écritures à secteurs 1 et 2.
Décompressez le secteur 1 dans une zone de travail, en laissant de stockage secteur 1 en cours que les données actives à extraire.
Compresser secteurs 1 et 2 dans un nouveau format de stockage.
Bloquer toutes les lectures et écritures de secteurs 1 et 2.
Échanger ancien stockage pour les secteurs 1 et 2 avec stockage nouveau.
Si la conversion échoue (annuler) :
  • Restaurer le stockage d'origine des secteurs 1 et 2.
  • Supprimer les données de secteurs 1 et 2 combinées dans le plan de montage.
  • Échec de l'opération d'écriture secteur 2.
Débloquer les lectures et écritures des secteurs 1 et 2.
La possibilité de fournir des mécanismes de verrouillage sur les modifications du secteur et annuler les modifications lorsque la tentative de conversion secteur échoue est considéré comme compatible transitionally. Pour les implémentations utiliser le stockage physique de stockage étendu, il contiendra les aspects de journal de transactions appropriés pour sécuriser et annuler les modifications qui ont été appliquées aux structures sur disque pour conserver l'intégrité des fichiers de base de données SQL Server.

Tout périphérique qui permet la réécriture de secteurs doit prendre en charge la récrit de façon transactionnelle afin que SQL Server n'est pas exposée perte de données.

note L'instance de SQL Server est redémarré si des e / S en ligne et les échecs restauration se trouvent 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 à l'aide de la (-f) paramètre de démarrage et passer 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. Utiliser l'instruction ALTER DATABASE et la clause de modifier le fichier pour modifier les noms physique de chaque fichier dans la base de données tempdb pour faire référence au nouvel emplacement physique, tel que le nouveau disque.
    Alter database tempdb modify file 
    (name = tempdev, filename = 'C:\MyPath\tempdb.mdf')
    
    Alter database tempdb modify file 
    (name = templog, filename = 'C:\MyPath\templog.ldf')
  2. Arrêtez et redémarrez SQL Server.

Certifications produit partenaire ne sont pas un guaranty de compatibilité ou de sécurité

Un produit tiers ou un fournisseur particulier peut recevoir une certification de logo Microsoft. Toutefois, certification partenaire ou un logo de Microsoft spécifique ne validez pas compatibilité ou d'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 prise en charge pour SQL Server et les applications basées sur SQL Server. Toutefois, les problèmes avec, ou dû, le sous-système est référencé au fabricant.

Pour les problèmes de base de données tempdb , services de support 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 et valider que des produits tiers fonctionnent correctement avec SQL Server. En outre, Microsoft ne fournit pas les garantie, guaranty ou déclaration d'adéquation ?s tout produit 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 MODÈLE : SQL Server supplémentaires diagnostics ajoutés pour détecter des problèmes d'E / S non signalés
828339 Message d'erreur 823 peut indiquer des problèmes de matériel ou des problèmes de système dans SQL Server
234656 L'aide de la mise en cache disque avec SQL Server
110352 Optimisation des performances de Microsoft SQL Server
304261 Description de la prise en charge des fichiers de base de données réseau dans SQL Server
913945 Microsoft ne certifie pas que les produits tiers fonctionneront avec Microsoft SQL Server
910716 Configuration requise pour SQL Server 2005 et SQL Server 2000 pour prendre en charge à distance mise en miroir de bases de données utilisateur
917043 Facteurs clés à prendre en considération lors l'évaluation de systèmes de cache de fichiers tiers avec SQL Server
Les informations contenues dans ce document représentent la vue actuel de Microsoft Corporation sur les problèmes abordés la date de publication. Étant donné que Microsoft doit répondre à modifier les conditions du marché, ne doivent pas être considérée comme un engagement de la part de Microsoft et Microsoft ne peut pas garantir la validité des informations présentées après la date de publication.

Ce livre blanc est purement informatif uniquement. MICROSOFT N'OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, QUANT AUX INFORMATIONS CONTENUES DANS CE DOCUMENT.

Conformer aux lois de copyright qui applicables est de la responsabilité de l'utilisateur. Sans limiter les droits d'auteur, aucune partie de ce document ne peut être reproduite, stockée dans ou introduite dans un système de récupération ou transmettre sous toute forme ou par tout moyen (électronique, mécanique, photocopie, enregistrement ou dans le cas contraire) ou à quelque 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 sujet dans ce document. Sauf stipulation expresse contraire dans tout contrat de licence écrit de Microsoft, la fourniture de ce document n'a pas concéder vous toute 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 ou des marques déposées de Microsoft Corporation aux États-Unis d'Amérique et/ou dans d'autres pays.
SQL Server nécessite systèmes afin de prendre en charge ? garantie remise aux médias stable ? comme indiqué dans le programme Microsoft SQL Server Always-On stockage solution analyse. FO Pour plus d'informations sur les exigences entrées 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 :
967576 Microsoft SQL Server Database Engine entrée/sortie configuration

Propriétés

Numéro d'article: 917047 - Dernière mise à jour: vendredi 2 novembre 2007 - Version: 1.6
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 7.0 Standard
  • Microsoft SQL Server 2000 Édition Personelle
  • Microsoft SQL Server 2000 Standard
  • Microsoft SQL Server 2000 Workgroup Edition
  • Microsoft SQL Server 2000 Édition Développeur
  • Microsoft SQL Server 2000 Édition Entreprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Mots-clés : 
kbmt kbsql2005setup kbsql2005engine kbexpertiseadvanced kbinfo KB917047 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 917047
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com