Compression de données + shrinkfile

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

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

++

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 +

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:

---

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

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 +

Citation:

---

Envoyé par 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 +

---

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

Bis

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

++

Citation:

---

Envoyé par mikedavem

Bis

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

++

---

mais j'ai fait un shrinkfile et non pas un shrinkdatabase comme c'est déjà mentionner

l'imprime écran est juste pour vous monter la quantité d'espace qui peuvent être récupérer

Ok dans ce cas il faut que tu donnes des informations cohérentes .. tu fais un shrinkfile mais tu donnes l'espace libre globale par base de données.

Donne nous l'espace utilisé par fichier :

Code:

---

1 2 3 4 5 6 7 8 9 10

USE ligne6; GO   select name, type_desc, size / 128 as size_mb, cast(FILEPROPERTY(name, 'SpaceUsed') * 100. / size as decimal(15,2)) as percent_used, cast((1 - (FILEPROPERTY(name, 'SpaceUsed') * 1. / size)) * 100 as decimal(15,2)) as percent_free from sys.database_files

---

++

Citation:

---

Envoyé par mikedavem

Ok dans ce cas il faut que tu donnes des informations cohérentes .. tu fais un shrinkfile mais tu donnes l'espace libre globale par base de données.

Donne nous l'espace utilisé par fichier :

Code:

---

1 2 3 4 5 6 7 8 9 10

USE ligne6; GO   select name, type_desc, size / 128 as size_mb, cast(FILEPROPERTY(name, 'SpaceUsed') * 100. / size as decimal(15,2)) as percent_used, cast((1 - (FILEPROPERTY(name, 'SpaceUsed') * 1. / size)) * 100 as decimal(15,2)) as percent_free from sys.database_files

---

++

---

Ci joint la résultat

Ok dans ton cas il faudrait essayer sans l'option TRUNCATEONLY car avec cette dernière si tu as une allocation faite à la fin du fichier tu ne pourras pas aller au delà.
Essaye ceci:

Code:

---

DBCC SHRINKFILE(ligne6, 35160)

---

Attention car l'opération peut prendre un peu de temps en fonction de ce que tu auras. Essaye de faire cela dans une période creuse d'activité

++

Super l'espace a été bien récupérer merci bien :ccool::ccool::ccool: