Discussion :

[ghohm]

Bonjour,

Je viens de réaliser une migration vers SQL Server car l'éditeur de mon application, qui utilise actuellement PostgreSQL, refuse d'assurer du support tant que je serai sous PostgreSQL.

Mon problème est que la volumétrie de ma base de données a explosée !

PostgreSQL = 270 Go d'espace disque total.

SQL Server 2008 R2 = 320 Go !!!


Sauriez-vous me dire d'où cela peut bien venir ? Sachant que d'après mes quelques premières vérifications, l'espace disque occupé par chaque type de donnée est identique (nombre d'octets).

Pour info, j'ai réalisé une initialisation des données de ma base de données sous SQL Server à partir de Business Objects Data Services. J'ai constaté que l'augmentation de la volumétrie allait crescendo.

J'insère une semaine de données, c'est un peu plus volumineux (quelques centaines de Mo). J'insère quelques mois (quelques Go). Etc.

J'ai entendu parler du journal des transactions qui pouvait poser des problèmes de volumétrie. N'étant pas expert SQL Server ... loin de là ... pourriez-vous m'en dire plus ?



Gôm

PS : En interne à mon entreprise, non je n'ai pas de support, expert, etc. SQL Server.

[SQLpro]

Commencez par nous donner les infos suivantes :
1) SELECT file_id, type_desc, name, physical_name, size FROM sys.database_file (exécutée dans le contexte de la base)
2) SELECT name, recovery_model_desc FROM sys.databases
3) DBCC SQLPERF (LOGSPACE)

Et le nom de la base.

A +

[simonlourson]

Commencez par nous donner les infos suivantes :
1) SELECT file_id, type_desc, name, physical_name, size FROM sys.database_file (exécutée dans le contexte de la base)
2) SELECT name, recovery_model_desc FROM sys.databases
3) DBCC SQLPERF (LOGSPACE)

Et le nom de la base.

A +

Bonjour, ci joint les informations demandées. (Désolé pour le format on me les a fournies comme ça.)

[ghohm]

Bonjour SQLPro,

Merci de m'avoir répondu !

C'est un collègue qui a envoyé les informations demandées ... pendant que je suis déjà en weekend !


Merci encore.

Gôm

[SQLpro]

Vous n'avez pas renvoyé le LOGSPACE

Quels types de données utilisez vous pour les littéraux ? ASCII (CHAR, VARCHAR) ou UNICODE (NCHAR, NVARCHAR) ?

Avez vous défragmenté globalement l'ensemble des tables et index de la base après votre import ?

A +

[simonlourson]

Vous n'avez pas renvoyé le LOGSPACE

Quels types de données utilisez vous pour les littéraux ? ASCII (CHAR, VARCHAR) ou UNICODE (NCHAR, NVARCHAR) ?

Avez vous défragmenté globalement l'ensemble des tables et index de la base après votre import ?

A +

Bonjour,

Notre logspace est vide,

Nous utilisons le type VARCHAR pour nos chaines de caractères,

Nous n'avons rien défragmenté après l'import de la base.

[ghohm]

Bonjour SQLpro,

Est-ce les informations fournies te suffisent pour nous mettre sur une piste ?


Gôm

[SQLpro]

1) DBCC SQLPERF (LOGSPACE) ne peut pas être vide... Il renvoie une table avec tous les JT de toutes les bases
2) évidemment commencez par défragmenter :

Code :

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

1
2
3
4
5
6
7
DECLARE @SQL VARCHAR(max); 
SET @SQL = ''; 
SELECT  @SQL  =  @SQL + 'ALTER INDEX ALL  ON [' 
              + TABLE_SCHEMA +'].[' + TABLE_NAME + '] REBUILD;' 
FROM   INFORMATION_SCHEMA.TABLES
WHERE  TABLE_TYPE = 'BASE TABLE' 
EXEC (@SQL);

Puis reverifiez votre espace de stockage avec :

Code :

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

sp_spaceused @updateusage = 'true'

A +

[WOLO Laurent]

Je ne vois pas le problème vu que 270 * 1,1 =Environ 300 Go.
En fait, 320 Go ce n'est pas la taille occupé que par les données et les index, il y'a aussi des l'espace des pages non occupées !

[ghohm]

Le problème venait en fait de 2 Index qui étaient CLUSTERED que non avons passé en NONCLUSTERED !


Merci à tous !

Gôm