SQL Server - Tables temporaires et tables physiques

14

Un mouvement est en cours à mon lieu de travail pour s'éloigner de l'utilisation des tables #temp et utiliser des tables physiques permanentes avec des SPID. Chaque fois que l' on aurait déjà inséré dans une table #temp, maintenant INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)est nécessaire - avec un tas de DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDdéclarations au début, par exemple , une procédure stockée. De plus, il va sans dire que partout où ces «tables permanentes de stockage de données temporaires» sont utilisées, il faut veiller à inclure a WHERE SPID = @@SPID.

La logique derrière cette évolution est qu'elle améliorera les performances globales du serveur sur lequel les requêtes s'exécutent (en réduisant les E / S et les conflits dans tempdb). Je n'apprécie pas cette approche pour un certain nombre de raisons - elle est moche, potentiellement dangereuse et semble pouvoir nuire aux performances des requêtes qui utilisent le nouveau schéma.

Quelqu'un a-t-il une expérience avec cette approche ou des approches similaires pour éliminer les tables #temp?

sql-server performance

— Will A
source

18

Il peut être démontré assez facilement qu'il ne réduira pas les E / S ni les conflits, mais augmentera plutôt les deux.

IO : chaque ligne insérée, lue ou supprimée d'une table #temp sera désormais insérée, lue ou supprimée de la table @@ SPID. Mais chaque ligne sera plus large avec une colonne @@ SPID supplémentaire, donc le nombre de pages nécessaires augmentera légèrement et l'IO sera toujours légèrement plus grand. Mais plus important encore, la suppression d'une table #temp et l'initialisation de la table #temp d'une nouvelle session par une session devront maintenant être simulées avec un DELETE FROM @@spidTable WHERE spid = @@SPID, et donc l'opération tronquer / créer (c'est-à-dire les opérations de gestion de l'extension de page) sera transformée en ligne, incomparable plus lent.
Contention : chaque analyse qui utilisait des verrous de page sur la table #temp aura désormais le potentiel de verrouiller une page avec des lignes de spid non liées, créant ainsi une contention auparavant inexistante. Chaque mise à jour qui en fait plus qui atteint le seuil d'escalade du verrou a la possibilité de faire passer le verrou au verrou de table et ainsi bloquer tous les autres spid.

Donc, même s'il est vrai que vous ne rencontrerez pas le conflit mythique IAM / SGAM / GAM dans tempdb, la seule raison pour laquelle cela se produirait est que vos opérations deviendront beaucoup plus lentes en raison d'E / S supplémentaires ordinaires et de conflits supplémentaires.

— Remus Rusanu
source

Je suis totalement d'accord avec le Remus ci-dessus - et merci pour une excellente réponse. Le problème est que nous causons un supposé impact sur les performances des applications tierces (avec plusieurs bases de données sur un serveur sur lequel nous avons notre propre base de données - nous devons effectuer des requêtes par rapport à leurs données). Je pense toujours que vous avez raison, l'esprit - en ce qui concerne les E / S, je m'attendrais à ce que la nouvelle approche fonctionne bien pire qu'auparavant - en ce qui concerne les conflits, du point de vue de tempdbs, les choses seront meilleures - de la nôtre, un peu pire.

— Will A

Combien de fichiers tempdb avez-vous? La configuration standard n'est pas vraiment évolutive du tout - vous devez avoir plusieurs fichiers tempdb dile et log, un par cœur de processeur visible (2 chacun si hyper-v).

— TomTom

1

Vous devez lire ces deux articles: sqlskills.com/BLOGS/PAUL/post/… et sqlskills.com/BLOGS/PAUL/post/… car ils traitent des problèmes d'évolutivité tempdb les plus courants.

— Remus Rusanu

@TomTom whoa, whoa. Plusieurs fichiers journaux? Vraiment?

— Aaron Bertrand

5

Cela semble être une solution radicale. Il existe de nombreux articles en ligne sur la réduction des conflits de tempdb (et l'optimisation de son utilisation) - votre organisation a-t-elle soigneusement examiné cette avenue?

http://www.sql-server-performance.com/tips/tempdb_p1.aspx

http://www.sqlservercentral.com/blogs/robert_davis/archive/2010/03/05/Breaking-Down-TempDB-Contention.aspx

http://searchsqlserver.techtarget.com/tip/Optimize-tempdb-in-SQL-Server-by-striping-and-splitting-to-multiple-files

etc.

+1 tout à fait d'accord - optimisez tempdb, ne réinventez pas la roue car votre implémentation sera pire. :)

Je suis tout pour ne pas suivre ce chemin si ce n'est pas justifiable - merci pour l'information Ben - je vais enquêter et faire des suggestions à notre DBA le cas échéant.

— Will A

2

Cela me semble que vous devriez résoudre les problèmes de performances dans tempDB, il y a quelques suggestions ici

— SPE109
source

Semble utile - merci SPE109, je vais vérifier cela et faire des recommandations à notre DBA le cas échéant.

— Will A