Les écritures sur TempDB entraînent-elles toujours une véritable écriture physique sur le disque, ou les écritures TempDB sont-elles mises en cache par SQL Server pour une écriture différée comme dans le cache du système de fichiers Windows?
Le font-ils toujours? Certainement pas. Le font-ils jamais? Oui mais pas à cause du mécanisme typique. La référence est ici Que fait le point de contrôle pour tempdb? .
Dans un système "bien comporté", les écritures dans un fichier de base de données utilisateur ont lieu au point de contrôle. Dans un système mal comporté, des écritures se produisent également lorsque le paresseux doit vider des pages du pool de mémoire tampon pour faire de la place pour d'autres pages.
Un point de contrôle n'est effectué pour tempdb que lorsque le fichier journal tempdb atteint 70% - c'est pour empêcher le journal tempdb de croître si possible (notez qu'une transaction de longue durée peut toujours essentiellement garder le journal en otage et l'empêcher de s'effacer) , comme dans une base de données utilisateur).
Mais il n'est pas nécessaire de vider tempdb sur le disque, car la récupération après incident n'est jamais exécutée sur tempdb, elle est toujours recréée au démarrage.
Tempdb n'est pas récupéré en cas de plantage, et il n'est donc pas nécessaire de forcer les pages tempdb sales sur le disque, sauf dans le cas où le processus lazywriter (partie du pool de tampons) doit faire de la place pour les pages d'autres bases de données.
C'est remarquablement (c'était une surprise pour moi) est le seul mécanisme par lequel les pages tempdb seront écrites sur le disque. En cas de pression du pool de mémoire tampon, les pages tempdb peuvent être vidées sur le disque. S'il n'y en a pas, cela ne devrait pas se produire.
Edit: discutable si "mal comporté" est une description appropriée pour une base de données utilisateur qui écrit des pages en dehors du point de contrôle. Insolite, atypique, ou tout simplement pas idéal peut-être?
Modification supplémentaire (commentaires / discussion suivants avec @PaulWhite):
L'omission flagrante ci-dessus est que les tables temporaires ne sont pas la seule source de trafic tempdb. Citant la compréhension des événements de hachage, de tri et d'échange :
Certaines opérations d'exécution de requêtes SQL Server sont calibrées pour fonctionner de manière optimale en utilisant une quantité (quelque peu) importante de mémoire comme stockage intermédiaire. L'optimiseur de requêtes choisira un plan et estimera le coût en fonction de ces opérateurs à l'aide de ce bloc-notes de mémoire. Mais ce n'est bien sûr qu'une estimation. Lors de l'exécution, les estimations peuvent s'avérer erronées et le plan doit se poursuivre malgré le manque de mémoire. Dans un tel événement, ces opérateurs se déversent sur le disque.
J'avais supposé à tort que le mécanisme derrière une écriture physique pour une opération de déversement était exactement le même que celui décrit précédemment, à savoir le lazywriter forçant les pages tempdb sur le disque en raison de la pression sur le pool de mémoire tampon (causée par le déversement).
@PaulWhite a expliqué où j'avais tort (merci Paul!):
Je pense que vous demandez pourquoi l'activité physique de tempdb se produit lorsqu'une requête dépasse son allocation de mémoire d'espace de travail, plutôt que de simplement utiliser tempdb-in-memory. subventions en premier lieu.
Les déversements sont en effet particuliers dans l'écriture jusqu'au stockage. L'activité physique de tempdb est observée sur un déversement, même face à des tas de mémoire libre et à une pression nulle sur tempdb.
Paul m'a également signalé son article de blog Advanced TSQL Tuning: Why Internals Knowledge Matters, qui comprend des exemples de scripts pour démontrer les déversements, pour ceux qui veulent approfondir.