SQL Question Mémoire

Version imprimable

24/03/2019, 19h04
agdid04

SQL Question Mémoire

Bonjour,

Je découvre une instance 2012 pour CRM ... avec une limite mémoire max à 495 Go

Alors je me pose la question est ce un bien ou un mal pour cette instance ....?

MERCI

A+
24/03/2019, 21h26
mikedavem

Citation:

Je découvre une instance 2012 pour CRM ... avec une limite mémoire max à 495 Go

Si tu parles de l'option de configuration 'max server memory (MB)' combien de mémoire physique côté système ?
Ceci dit 495GB cela me parait énorme pour un CRM mais bon à la rigueur vu que je ne crois pas avoir tout vu pour le moment ... :)

++
25/03/2019, 01h23
agdid04

Personnellement, je suis surpris mais 495 Go sur un un total de 800 Go est dédiée à l'instance SQL ... je n'étais pas là pour la mise en place ...
25/03/2019, 11h42
mikedavem
Quelle quantité de données pour ta ou tes bases de données CRM?

Pour valider le montant de la mémoire allouée pour ton instance tu peux commencer avec cette requête:
Code:

1 2 3 4 5 6 select physical_memory_kb / 1024 AS physical_memory_MB, visible_target_KB, committed_kb, committed_target_kb from sys.dm_os_sys_info;
++
25/03/2019, 12h15
agdid04
Bonjour,

Merci bien de votre retour ...

La plus "grosse" basse ne dépasse pas 120 Go sur une vingtaine de bases ....

Resultats de votre requête:
Code:

1 2 physical_memory_MB visible_target_KB committed_kb committed_target_kb 745808 494281232 494281232 494281232
A+
25/03/2019, 14h03
mikedavem
Il faudrait voir en excluant l'activité de maintenance des bases (rebuild d'index etc ..) mais je dirai qu'à priori il semblerait que cet espace mémoire soit nécessaire. Que donne cette requête? (Tu peux cacher le nom des bases si information sensible dans ton cas)
Code:

1 2 3 4 5 6 SELECT DB_NAME(database_id) AS [database_name], COUNT(*) / 128 AS size_mb FROM sys.dm_os_buffer_descriptors WITH (NOLOCK) GROUP BY database_id ORDER BY size_mb DESC;
++

Merci bien.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
database_name	   size_mb
Base1	                   71739
Base2	                   67067
Base3	                   52016
Base4	                   51534
Base5	                   49432
Base6	                   48179
Base7	                   37493
Base8	                  37165
tempdb	                  10718
Base9	                  8585
Base10	                  7220
Base11	                  5105
Base12	                 2207
msdb	                      567
Base13	                 557

A+

25/03/2019, 15h03
mikedavem

Ok vu de loin tes bases 1 à 8 semblent prendre la majorité de ta place en mémoire disponible pour SQL Server. Ceci est explique cela.
Après que ce soit normal ou pas il faudrait le déterminer avec une étude plus approfondie mais ce qui est sûr c'est que la quantité de mémoire provisionnée semble censée à l'heure actuelle.

++
26/03/2019, 00h15
hmira

Bonjour,

En complément de ce qui a été dit, il faut aussi tenir compte des éventuelles autres applications qui tourneraient sur ce même Serveur. En d'autres termes, s'agit-il d'un Serveur dédié SQL Server, ou bien, sur ce même Serveur, coexistent d'autres applications importantes, éventuellement dévoratrices de mémoires ? Ce qui pourrait justifier cette limite de 495 Go sur les 800 Go.

Comme cela a été dit, seule une étude approfondie, intégrant l'analyse des indicateurs traitant de la mémoire (Buffer cache hit ratio, Page life expectancy, Memory pressure, etc.) permettrait d'en juger de la pertinence de ce seuil de 495 Go.

A+
26/03/2019, 10h02
StringBuilder

Outre d'autres applications éventuelles sur le serveur : y a-t-il d'autres instances SQL ?

En règle générale, un serveur dédié doit avoir 100 % - 2 à 4 Go de mémoire réservée pour SQL Server. L'OS plus les éventuels outils d'administration ont largement de quoi faire dans 2 ou 4 Go. C'est domage d'obliger SQL Server à swaper/utiliser tempdb alors que de la mémoire est disponible.

En revanche, s'il y a d'autres applications (genre serveur de traitement, web etc.) c'est une très mauvaise idée : il faut mieux partir sur deux serveurs plus petits, mais dédiés chacuns à leur tâche.
26/03/2019, 19h33
Michel.Priori

La valeur par défaut de la limite est de 2 147 483 647 Go.
Donc quelqu'un y a touché !
Où est la doc ???

Hypothèse 1 :
Augmentation de la RAM après configuration initiale

Hypothèse 2 :
L'instance ne serait-elle pas en cluster "face à face" (2 instances Actif-Passif mutuellement en opposition, quand tout va bien) ?
27/03/2019, 11h42
janlouk

Citation:

Envoyé par Michel.Priori

La valeur par défaut de la limite est de 2 147 483 647 Go.

MB ;)
29/03/2019, 18h14
agdid04

Bonjour,

J'ai une table sur laquelle j'ai fait un REBUILD car avg_fragmentation > à 30% mais en moins de 24% avg_fragmentation est repassé à plus de 60% ....
Alors je me demande que faut-il surveiller ...? comment peux-je récupérer les actions faites sur cette table ....

Merci.

A+
29/03/2019, 18h28
StringBuilder

24% de quoi ? Du rebuild ?

Ca ne me semble pas anormal que faire un rebuild bordelise la table tant qu'il n'est pas terminé.

T'as déjà fait des légos dans ta vie ?

Quand t'as un mur avec des briques de toutes les couleurs, et que tu veux regrouper les briques par couleur pour que ce soit plus joli, c'est difficile pas pas démonter les 3/4 du mur durant l'opération... c'est pas pour autant que quand tu auras fini ton mur ne sera pas remonté avec les briques triées par couleur !

PS : et si "24%" est à comprendre "24h" alors je me demande si tu n'as pas indiqué un fill factor trop juste... ça expliquerait pourquoi la moindre modification faire par la suite le fragmente...

Il y a beaucoup de modifications sur ton index ?
29/03/2019, 19h08
agdid04

Pardon je voulais dire 24h !

Comment je peux récupérer le fill factor de tous mes index de ma base pour voir s'il y a une marge ou pas ...?

Merci.

A+
29/03/2019, 19h27
Michel.Priori

Vu qu'on parle de table fragmentée, j'imagine qu'il s'agit d'une table munie d'un index cluster.

Peut-on savoir :
1- quelle est la définition de l'ensemble de colonne qui porte l'index cluster ?
2- quelle est la valeur par défaut (si elle existe) et le nombre d'insert / delete par 24h ?
3- si il est d'usage de modifier les informations qui dépendent de l'index cluster ?

Bonjour,

Voici la structure de mon index:
Code:

1 2 3 4 5 6 7 8 CREATE UNIQUE CLUSTERED INDEX [MonIndex_PK_Suivi] ON [dbo].[RESPRD] ( [creatdate] DESC, [SuiviId] DESC ) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 100) ON [PRIMARY] GO
Il est re-fragmenté 100% après uniquement ~ 6h après l'avoir reconstruit ! à part passer FILLFACTOR à 80 (valeur recommandé par MS) je continue mes recherches ....

Merci aux éclaireurs ...

A+

01/04/2019, 21h00
SQLpro

Ce n'est jamais une bonne idée que de créer un index cluster sur une informations constamment mis à jour et constitué de plusieurs colonnes. Vous devriez choisir une seule et autre colonne UNIQUE et de petite taille max 8 octets et immuable pour cet index clustered.

A +
01/04/2019, 21h21
StringBuilder

Et accessoirement un FILLFACTOR de 100 indique qu'il ne laisse aucun trou pour une éventuelle insertion.
C'est pour ça qu'il fragmente.

Et il fragmente d'autant plus qu'autant que "createDate" est à priori un horodatage, donc un bon candidat pour un index cluster, autant le statut… comment dire… il est voué à évoluer au fil du temps… ce qui le rend absolument déconseillé pour un index cluster !
05/04/2019, 14h35
aieeeuuuuu

Bonjour,

Pour ma part, je ne serai pas aussi péremptoire sur l'index :
La première colonne est un horodatage sur la date de création, donc a priori toujours croissant, et a priori, quasi unique.

ainsi, une modification de la colonne SuiviID, s'il y en a, ne devrait pas fragmenter l'index, sauf cas exceptionnel.

En revanche, en effet, le fillfactor à 100% n'est probablement pas une bonne idée.
05/04/2019, 15h46
StringBuilder

Ca devient gênant si la colonne creatdate est de type date (ou autre type ne stockant que la partie date, sans l'heure).

Si c'est bien un datetime / datetime2 ou un autre type dans lequel on stocke une granularité suffisante (seconde ?), c'est bon.
05/04/2019, 21h10
Michel.Priori

Bonsoir,

Deux choses sur le code de création de l'index :
*un index unique n'est pas une PK, pourquoi l'avoir nommée ainsi ?
*un index cluster, du fait qu'il se retrouve en tant que pointeur logique au niveau feuille des index non-cluster, se doit d'être le plus "léger" possible. Peut-on faire des économies de sur les types ?

Sinon pour ton histoire de fragmentation, il manque des réponses à mes questions précédentes :

2- quelle est la valeur par défaut (si elle existe) et le nombre d'insert / delete par 24h ?
3- si il est d'usage de modifier les informations qui dépendent de l'index cluster ?
auxquelles j'ajouterais

4- l'occupation physique des données

Fuseau horaire GMT +2. Il est actuellement 21h12.