Discussion :

[Boubou2020]

Bonjour a tous
Dans le but de gérer bien mes espaces disques je viens d'activer la compression du donné de type page sur un de mon gros table , suivi par une opération de suppression massive du données après j'ai fait une opération d'organisation d'index afin d'assurer une bonne défragmentation d'index
ces opérations sont fait avec sucés ensuite j'ai procéder a faire un shrinkfile avec l'option truncatonly tout ça dans le but de récupérer plus d'espace ,j'était surpris que l'opération est fini et j'ai pas gagner même un 1MB malgré que je peuvent gagner plus de 10GO
comment dans ce cas je doit procéder surtout qu'il faut récupérer plus d'espace ???

[mikedavem]

Il vaut mieux passer par un SHRINKFILE dans ce cas et pas un SHRINKDATABASE comme stipulé sur l'image.

++

[SQLpro]

SHRINK ne récupère que les pages vides.

Tant que vous n'avez pas procédé à une défragmentation logique de vos index et tables, les espaces morts sont disséminés dans les pages. Or comme le SHRINK supprime des pages, cela n'a pratiquement aucun effet.

Commencez donc par défragmenter tous vos index par un ALTER INDEX REBUILD ou bien ALTER TABLE REBUILD.

A +

[Boubou2020]

merci pour vos réponse et vos conseil

sur le même piste j'ai une deuxième question ,j'ai appliquer la stratégie du compression de donné sur une de mes bases (compression du page + colonne) tout a était passer mais après j'ai eu une réclamation du production sur

une dégradation de performance, en analysant le serveur j'ai remarquer une augmentation de consommation du CPU (voir imprime écran ) j'ai utiliser ce script pour mesurer la cons somation du CPU par Database

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
23
24
;WITH 
 
  DB_CPU_STAT AS 
  ( 
    SELECT    D.database_id 
        , D.name AS database_name 
        , SUM(total_worker_time) / 1000 AS total_CPU_time_ms 
    FROM    sys.dm_exec_query_stats AS QS 
    CROSS APPLY  ( 
          SELECT  CONVERT(int, value) AS database_id  
          FROM  sys.dm_exec_plan_attributes(QS.plan_handle) 
          WHERE  attribute = N'dbid' 
        ) AS DB 
    INNER JOIN  sys.databases AS D 
          ON DB.database_id = D.database_id 
    GROUP BY  D.database_id, D.name 
  ) 
SELECT  database_name 
  , total_CPU_time_ms / 1000 AS total_CPU_time_s 
  , CAST(total_CPU_time_ms * 1.0 / SUM(total_CPU_time_ms) OVER() * 100.0 AS decimal(5, 2)) AS [CPU_%] 
FROM  DB_CPU_STAT 
WHERE  database_id > 4 -- system databases 
AND  database_id <> 32767 -- ResourceDB 
ORDER  BY total_CPU_time_ms DESC

j'était surpris que seul la base ligne6(ou j'ai appliquer la stratégie du compression ) consomme 33% du ressource CPU

Alors comment je peuvent mesurer le besoin en ressource CPU sur ce serveur si je veux appliquer cette stratégie sur tout mes bases (11 bases)

autre point exit'il une méthode pour retour en arriéré ??

merci

[SQLpro]

En matière informatique rien n'est gratuit ! Si vous compressez vos données vous allez gagner beaucoup sur les lectures par balayage (scan), très peu sur les lectures par recherche (seek) et perdre énormément sur toutes les écritures car il faut décompresser, modifier et recompresser chaque page avec génération quais systématique de nombreux "split" de page (dans une page pleine il n'est pas possible de rajouter de l'info, alors il faut créer une nouvelle page et déporter la moitié des lignes).

A +

[Boubou2020]

En matière informatique rien n'est gratuit ! Si vous compressez vos données vous allez gagner beaucoup sur les lectures par balayage (scan), très peu sur les lectures par recherche (seek) et perdre énormément sur toutes les écritures car il faut décompresser, modifier et recompresser chaque page avec génération quais systématique de nombreux "split" de page (dans une page pleine il n'est pas possible de rajouter de l'info, alors il faut créer une nouvelle page et déporter la moitié des lignes).

A +

bonjour

malgré que j'ai fait un rebuild de mes indexes et l'opération a été fait avec sucé mais aucun gain avec le shrinkfile au contraire j'ai perdu plus d'espace