Discussion :

[olivierB75]

Bonjour,

Après initialisation d'une table de 15 millions de lignes (size 4GO) , je constate que la memoire du serveur initialement a 4,20GO est passée à 9GO,
situation normal car sql server travaille exclusivement en memoire des lors que cette dernière est suffisante.

En revanche, après execution d'un TRUNCATE TABLE sur cette table de 4GO l'espace memoire de 9GO demeure à 9GO.

Existe t-il un moyen de liberer la memoire à l'issu de ce truncate table.

PI, 60GO de RAM est dediée à sql server sur ce serveur de 90GO.
la base de données est en mode recovery simple

Merci pour vos réponses.

Cordialement,

Olivier,

[darkelend]

Existe t-il un moyen de liberer la memoire à l'issu de ce truncate table.

Redémarrer le service SQL... mais je ne te le conseille pas. Sql server libèrera la mémoire lorsqu'une autre opération le nécessitera

[olivierB75]

En effet, mais je souhaiterais savoir si il existe une alternative à ces redémarrages fréquents du service sql pour libérer la memoire.

[mikedavem]

SQL Server ne va libérer la mémoire que s'il est contraint de le faire (c'est son mode de fonctionnement) . Le système d'exploitation peut lui demander de libérer de la mémoire en cas de besoin.

Sinon il faudra redémarrer le service pour cela. La vrai question est de savoir pourquoi tu veux la libérer puisque visiblement tu as prévu 60Go RAM pour cette instance SQL ?

++

[SQLpro]

La vrai question est de savoir pourquoi tu veux la libérer puisque visiblement tu as prévu 60Go RAM pour cette instance SQL ?

++

Pour économiser du courant parce que les bit à 1 ça consomme plus...

J'ai bon là ??? ;-)

A +

[olivierB75]

Pour votre info, le serveur heberge un conglomerat de 3 base de données ...

Parmi ces 3 bases, une base est destinée à accueillir des données externes SAP, il s'agit donc ici de faire des truncate\insert via des lots SSIS.

Le pbm c'est qu'au terme d'un certain nombre d'init, la memoire saturée entraine un echec d'execution d'un lot SSIS qui ne dispose de memoire suffisante
pour l'execution d'un dataflow, cela a pour consequent la mise en echec du job concerné.

Un redemarrage frequent du service pénalise les utilisateurs lors des premières executions des SP car les donnéees doivent être rechargés en memoire, recompilation des SP etc..

[mikedavem]

PI, 60GO de RAM est dediée à sql server sur ce serveur de 90GO.
la base de données est en mode recovery simple

Je ne comprends pas très bien mais j'espère que tu vas nous préciser les choses.

Tu as un serveur avec 90Go de RAM dont 60Go RAM réservé à SQL Server (je suppose avec l'option max server memory = 60Go). Tu dis que ton lot SSIS plante car pas assez de mémoire. En principe il reste 30Go à SSIS pour fonctionner ce qui me paraît plus que largement suffisant ... à moins que SSIS ne soit pas exécuté sur le même serveur ?

++

[olivierB75]

En effet pour les premières execution du job aucun pbm de memoire, SSIS a suffisamment de memoire pour s'executer.

Mais au terme d'une dizaine d'execution du job, la RAM s'incremente progressivement jusqu'a atteindre le Max autorisé.

Le truncate table ne semble pas liberer la RAM des données precedemment initiliasées par les insert du SSIS

NB: SSIS est installer sur le même serveur

[mikedavem]

Le truncate table ne semble pas liberer la RAM des données precedemment initiliasées par les insert du SSIS

Non effectivement un TRUNCATE TABLE ne libèrera pas la mémoire allouée à SQL Server comme expliqué plus haut. Cependant la désallocation des pages suite à l'opération de TRUNCATE permettra de réutiliser cet espace par SQL Server.

Que te donne cette requête après un chargement via ton lot SSIS :

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
17
18
19
20
21
22
SELECT COUNT(*) * 8 / 1024 AS cached_size_mb, 
    database_id,name , index_id 
FROM sys.dm_os_buffer_descriptors AS bd 
    INNER JOIN 
    (
        SELECT object_name(object_id) AS name 
            ,index_id ,allocation_unit_id
        FROM sys.allocation_units AS au
            INNER JOIN sys.partitions AS p 
                ON au.container_id = p.hobt_id 
                    AND (au.type = 1 OR au.type = 3)
        UNION ALL
        SELECT object_name(object_id) AS name   
            ,index_id, allocation_unit_id
        FROM sys.allocation_units AS au
            INNER JOIN sys.partitions AS p 
                ON au.container_id = p.partition_id 
                    AND au.type = 2
    ) AS obj 
        ON bd.allocation_unit_id = obj.allocation_unit_id
GROUP BY database_id , name, index_id 
ORDER BY cached_pages_count DESC;

Que fait ton lot SSIS exactement ? Quand tu dis que SSIS n'a plus assez de mémoire tu as une erreur concernant ce phénomène ?

++