Attention, dès SQL Server 2016, ces deux drapeaux de trace sont activés par défaut pour TempDB.

Pour activer plusieurs drapeaux de trace, on peut aussi écrire : DBCC TRACEON (1117, 1118, ..., -1)

En lisant ta question je devine que tu vas me dire qu'il faut séparer les fichiers sur des disques séparés mais dans mon cas c'est impossible(pour l'instant).
Pas nécessairement. Je ne sais pas s'il est possible que, si un disque est plus lent que les autres, le moteur favorise l'écriture sur les fichiers qui sont sur le volume le plus rapide.
C'est ce qu'il fait pour les sauvegardes multi-fichiers. Cela n'a rien à voir, mais je trouve que ça vaut le coup de tester.

D'où je te repose une autre question : N'y a t il aucun gain à faire du multi fichiers sur tempdb si les fichiers sont sur le même disque?
Si : lorsque la charge de travaille est supportée par un grand nombre de variables de type TABLE (ceci incluant les UDT TABLE), et de tables temporaires, il peut y avoir contention d'accès aux pages de métadonnées.
Elles sont peu nombreuses (pour généraliser, 1 pour 64000 étendues, soit environ 4Go). Ceci peut faire que l'on va observer des attentes de type LATCH_XX sur des resources dont la description est 2:1:X, où :

  • 2 est le database_id de TempDB;
  • 1 est le numéro du fichier de données;
  • X est le numéro de page dans ce fichier.


Je l'ai vu plusieurs fois se produire sur la page qui trace l'allocation et désallocation de pages : sa description est 2:1:1. Il y en a une pour les 8088 pages, soit environ 64Mo.
Donc en multipliant les fichiers de données, on réduit et annule cet effet.

@++