Discussion :

[agdid04]

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+

[mikedavem]

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 ...

++

[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 ...

[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 :

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

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;

++

[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 :

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

1
2
physical_memory_MB	    visible_target_KB	committed_kb	committed_target_kb
745808	                    494281232	        494281232	494281232

A+

[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 :

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

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;

++

[agdid04]

Merci bien.

Code :

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

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+

[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.

++

[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+

[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.

[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) ?

[janlouk]

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

MB

[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+

[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 ?

[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+

[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 ?

[agdid04]

Bonjour,

Voici la structure de mon index:

Code :

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

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+

[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 +

[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 !

[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.