2010-05-21 26 views
3

Pour sélectionner des informations relatives à une liste de centaines d'ID ... plutôt que de faire une énorme déclaration, je crée une table temporaire, y insère les ID, la joint avec une table pour sélectionner les lignes correspondant aux identifiants, puis supprime la table de temp. Il s'agit donc essentiellement d'une opération de lecture, sans modifications permanentes apportées aux tables de base de données persistantes.Dois-je valider ou annuler une transaction qui crée une table temporaire, la lit, puis la supprime?

Je fais ceci dans une transaction, pour m'assurer que la table temporaire est supprimée quand j'ai fini. Ma question est la suivante: que se passe-t-il lorsque je commets une telle transaction par rapport à une transaction? En termes de performances ... le moteur de base de données doit-il faire plus de travail pour annuler la transaction en la validant? Y at-il même une différence puisque les seules modifications sont faites à une table de temp?

question connexe, mais ne répond pas à mon cas spécifique impliquant des tables temporaires: Should I commit or rollback a read transaction?

EDIT (clarification de la question):

Pas la recherche de conseils à point de commettre/rollback. La transaction est absolument nécessaire. Supposons qu'aucune erreur ne se produit. Supposons que j'ai créé une table temporaire, supposons que je sais que l'écriture réelle sur tempdb s'est produite, supposons que j'effectue des opérations en lecture seule (sélection) dans la transaction et supposons que j'émets une instruction delete sur la table temporaire. Après tout ça ... qui est moins cher, commit ou rollback, et pourquoi? Quel autre travail le moteur db peut-il faire à THAT POINT pour un commit contre une restauration, basé sur ce scénario spécifique impliquant des tables temporaires et des opérations en lecture seule?

Répondre

3

Si nous parlons de table temporaire locale (c'est-à-dire que le nom est précédé d'un seul #), au moment où vous fermez votre connexion, SQL Server supprimera la table. Ainsi, en supposant que votre couche de données soit bien conçue pour garder les connexions aussi courtes que possible, je ne m'inquiéterais pas de la création de tables temporaires dans une transaction. Je suppose qu'il pourrait y avoir une légère différence de performance d'emballage de la table dans une transaction, mais je parie qu'il est si petit qu'il est sans importance par rapport au coût de garder une transaction ouverte plus longtemps en raison du temps de créer et de remplir la table de temp.

+0

Je ne pose pas vraiment de questions sur les performances de l'emballage dans une transaction. La connexion est transmise successivement à plusieurs fonctions de l'API de base de données et utilise un nom/une convention de table temporaire commun, de sorte que la transaction garantissant la suppression de la table temporaire est nécessaire. Ce qui m'intéresse, c'est l'effet de l'engagement de cette transaction ou de l'annuler. – Triynko

+0

@Triynko - En quoi êtes-vous curieux de l'effet? L'accessibilité à la table temporaire à partir d'un autre code? – Thomas

+0

@Thomas - Je pose des questions sur la performance de l'engagement vs la rétrocession de la transaction. Ce n'est vraiment pas intuitif, parce que le retour semble impliquer que le travail serait fait, mais si une simple transaction non validée est annulée ... le travail peut simplement être supprimé de la mémoire et aucun travail pour "appliquer" les changements ne serait enregistré , comme la mise à jour des statistiques de base de données C'est difficile à dire, et donc je cherche vraiment quelqu'un qui sait ce qui peut se passer dans SQL Server sous le capot pendant les rollbacks et s'engage dans ce scénario particulier. – Triynko

0

Une manière plus simple de s'assurer que la table temporaire est supprimée est de la créer en utilisant le signe #.

CREATE TABLE #mytable ( rowID int, rowName char (30))

Le # indique SQL Server que cette table est une table temporaire locale. Cette table est uniquement visible pour cette session de SQL Server. Lorsque la session est fermée, la table sera automatiquement supprimée. Vous pouvez traiter cette table comme n'importe quelle autre table, à quelques exceptions près. Le seul vrai majeur est que vous ne pouvez pas avoir de contraintes de clé étrangère sur une table temporaire. Les autres sont couverts dans la documentation en ligne.

Les tables temporaires sont créées dans tempdb.

Si vous faites cela, vous n'aurez pas à l'emballer dans une transaction.

+1

J'ai dit que j'utilise déjà les tables #temp. Mais la connexion est réutilisée car elle est transmise rapidement à plusieurs fonctions API de base de données. Il est donc important qu'une transaction supprime explicitement la table lorsqu'elle est terminée, soit en effectuant la suppression et la validation, soit en annulant la transaction. Je suis particulièrement intéressé par les effets de la validation ou de l'annulation de la transaction (en supposant que la table est définitivement supprimée avant la validation et éventuellement supprimée avant la restauration). – Triynko