Discussion :

[janlouk]

Bonjour à tous,

Alors je lis donc qu'il faut un fichier par CPU, parfois si 16, en avoir 12 c'est déjà bien assez. Faire une "évaluation" de la taille qu'un seul fichier prendrait et donc diviser cette taille par le nombre de fichier.

Je lis aussi ici à la page 18, de Paul Randal ce n'est pas si "simple" : http://sqlskills.com/blogs/paul/comm...ervermyths.pdf

Bref, avec cette requête, je compte le nombre de CPU (http://blog.sqlauthority.com/2012/02...al-processors/)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT cpu_count
FROM sys.dm_os_sys_info;

Voici le résultat sur mes 12 instances en PROD

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
cpu_count
16
1
8
8
4
8
16
16
8
4
8
2

J'ai besoin d'une précision svp. J'en ai une avec 16 CPU et uniquement 2 disques. Est-ce vraiment utile de créer, même 7 ndf, sur 2 disques ? Soit 4 fichiers sur un même disque ?

Si oui, petite précision pour l'autogrowth. Si 4 fichiers (1 mdf et 3 ndf), si j'active l'autogrowth sur les 4. Est-ce que les 4 vont grandir "ensemble" ou uniquement 1 seul et les autres ne grandiront "jamais" ?

Merci
Jean-Luc

[rudib]

mais nooooon....

avec l’augmentation du nombre de cœurs, on a laissé tomber. La recommandation de Microsoft est maintenant, un fichier par socket.
je ne crois pas que tu puisses savoir combien il y a de coeurs sur ta machine avec une requête SQL. Il y a de nouvelles DMV en 2012 pour voir plus d'info sur l'OS, mais si tu es virtualisé en plus, ça n'aide pas.

donc : un fichier par socket, et surtout des fichiers de même taille. ça se fait tout seul apparemment à l'installation de SQL Server 2016.

[janlouk]

Sorrryyyy :-)

Mais si j'arrive à connaitre le nombre de coeur. Imaginons un serveur avec 4 coeurs, sur lequel il y a 4 instances, 8 disques.

je devrais en théorie faire 4 fichiers par tempDB par instance donc ?

[rudib]

Mais si j'arrive à connaitre le nombre de coeur. Imaginons un serveur avec 4 coeurs, sur lequel il y a 4 instances, 8 disques.

Coeurs ? Instances ? disques ? Que viennent-ils faire ici ?

Tu crées 4 fichiers si tu as quatre cœurs. Si tu as 32 cœurs sur 4 sockets (donc quatre processeurs à huit coeurs), tu crées quatre fichiers.

Ne tiens pas compte de la notion de disques. Tu peux créer ces quatre fichiers sur le même disque. Ce n'est pas pour optimiser les I/O physiques, c'est pour optimiser les threads qui vont prendre en charge ces I/O.

Si tu as plusieurs instances de SQL Server sur la même machine :
1/ tu te dis que tu es dans la misère
2/ tu fais la même chose sur chaque instance, il y a un tempdb par instance.

[janlouk]

Tu crées 4 fichiers si tu as quatre cœurs. Si tu as 32 cœurs sur 4 sockets (donc quatre processeurs à huit coeurs), tu crées quatre fichiers.

Ok, je vais faire cela, j'ai reçu la liste des config de nos serveurs.

Dernière précision stp. Si je crée 4 fichiers de 1 GB et que les transactions auront besoin de 8 GB de place. Si j'active l'autogrowth sur les 4 fichiers, il va répartir les 8 GB sur les 4 fichiers, soit 2 GB par fichier ? Ou remplir plus un que l'autre ?

Je demande car s'il remplit un fichier au max, alors autant que j'adapte la taille à 2GB pour tous et que j'active l'autogrowth sur un seul fichier.

[rudib]

Dernière précision stp. Si je crée 4 fichiers de 1 GB et que les transactions auront besoin de 8 GB de place. Si j'active l'autogrowth sur les 4 fichiers, il va répartir les 8 GB sur les 4 fichiers, soit 2 GB par fichier ? Ou remplir plus un que l'autre ?

Attention confusion. Les fichier à créer par socket sont les fichiers de données. Là tu parles des fichiers de journaux de transactions. Un seul fichier de journal

[SQLpro]

Dernière précision stp. Si je crée 4 fichiers de 1 GB et que les transactions auront besoin de 8 GB de place. Si j'active l'autogrowth sur les 4 fichiers, il va répartir les 8 GB sur les 4 fichiers, soit 2 GB par fichier ? Ou remplir plus un que l'autre ?

Entre nous si vous savez à l'avance que ceci va produire 8 Go il serait masochiste d'imposer à SQL Server de faire de l'autogrowth qui pénalise fortement les performances en allongeant artificiellement la durée de certaines requêtes, provoque des blocages, de la contention, des attentes et peut être des verrous mortels !

C'est un peu comme sis vous disiez, je vais gonfler mes pneus à moitié, afin d'éviter de gâcher de l'air et que vous partiez sur l'autoroute !!!

A +