Bonjour,

Le script ci-dessous vous permettra d'analyser les tables les plus volumineuses de la base.

[
SELECT t.NAME AS TableName, s.Name AS SchemaName, p.rows AS RowCounts,
SUM(a.total_pages) * 8 AS TotalSpaceKB, SUM(a.used_pages) * 8 AS UsedSpaceKB,
(SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM sys.tables t
INNER JOIN sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN sys.schemas s ON t.schema_id = s.schema_id
WHERE t.NAME NOT LIKE 'dt%' AND t.is_ms_shipped = 0 AND i.OBJECT_ID > 255
GROUP BY t.Name, s.Name, p.Rows
ORDER BY UsedSpaceKB DESC
]

Une duplication de la base en utilisant les oid numériques devrait permettre de bien réduire la base mais des tests seront à effectuer.
En effet, certains développements externes peuvent être incompatibles.

La duplication se fait par la Console d'administration, clic-droit sur la base de données > Dupliquer la base de données ...
Dans le champ Pilote, sélectionnez Microsoft SQL Server (odbc, OIDs numériques).

Bons tests.

Cordialement

Bonjour,

J'ai testé la solution. J'ai effectivement constaté une réduction considérable de la base de données. Néanmoins il y a une échec de transfert de données de certaines tables. Je poursuis mes analyses sur ces échecs.

Bonjour,

J'ai testé la solution. J'ai effectivement constaté une réduction considérable de la base de données. Néanmoins il y a une échec de transfert de données de certaines tables. Je poursuis mes analyses sur ces échecs.

Bonjour,

Merci pour votre retour.

SI cela peu vous aider, la seule erreur que j'ai eu en duplication de base provenait d'une clé en double dans une table DSM.