Βλέποντας τα παραπάνω αγαπητέ μου φίλε μπορώ ασφαλώς να συμπεράνω ότι κάτι σοβαρό είναι πάνω σε αυτή σωστά;

(Δεν μπορώ διαφορετικά να εξηγήσω τον αριθμό των αρχείων)

Με βάση αυτή την εκτίμηση αλλά και το μέγεθος του ελεύθερου χώρου που μας δίνεις δεν βλέπω το λόγο να κάνεις κάτι γιά αυτή.

Αν κάτσεις να υπολογίσεις τον χρόνο που θα χρειαστείς να κάνεις shrink  σε σχέση με το κόστος των GB που θέλεις να πάρεις πίσω στους δίσκους σου νομίζω ότι δεν αξίζει την φασάρια.

Πρίν κάνεις οτιδήποτε υπολόγισε πόσο σου κοστίζει το GB στο storage σου (θεωρώ ότι με αυτά που δίνεις σαν στοιχεία έχεις storage) και πόσο κοστίζει η ώρα που δεν είναι διαθέσιμη η βάση σου στην εταιρία σου.

vmakrin:

μετά από όσα είπαμε δεν μου φαίνεται καλή ιδέα να κάνω shrink στην βάση, απλά με ανησυχεί ο χώρος στους δίσκους και όλα αυτά τα datafiles.

Κάποια πράγματα που ίσως θα έπρεπε να ψάξεις περισσότερο:
data size  = 155327624 KB
index size = 135162832 KB
Η μισή βάση είναι δεδομένα και η άλλη μισή είναι indexes. Χωρίς αυτό να είναι "κακό" ίσως θα έπρεπε να κοιτάξεις
πως χρησιμοποιούνται οι υπάρχοντες indexes και αν όντως χρειάζονται όλοι.

Το log file, (if i am not mistaken), έχει μέγεθος γύρω στα 18 GB.
Ίσως αξίζει να κοιτάξεις τo disaster-recovery πλάνο για την συγκεκριμένη βάση, καθώς και υπάρχοντα maintenance plans-jobs (:κυρίως index rebuilds)

Ο αριθμός των filegroups&files είναι λίγο "περίεργος". Ίσως θα πρέπει να ελέγξεις την κατανομή των files per filegroup και το μέγεθος του κάθε file:
Αν πχ. σε ενα filegroup (με 5 datafiles) υπαρχουν 3 files με μεγεθος 1GB και 2 files με μεγεθος 3GB.
Αν στο primary filegroup δεν αποθηκευονται δεδομένα και το primary filegroup έχει περισσότερα από ένα data files κτλ.

Επίσης, αν η βάση έχει πίνακες χωρίς clustered index (heaps) ίσως υπάρχουν allocated pages οι οποίες δεν περιέχουν "ενεργά" δεδομένα.
--pay attention to heaps με μικρό αριθμό rows και ιδιαίτερα μεγάλο αριθμό xx_pages (σε σχέση με το μέσο μέγεθος data/index record)

SELECT  OBJECT_NAME(i.object_id) AS tbl_name, ISNULL(i.name, 'heap_table_data') AS indexname, p.partition_id, p.rows, dp.*, lobp.*
FROM sys.indexes AS i
 JOIN sys.partitions AS p on i.object_id = p.object_id AND i.index_id = p.index_id
 OUTER APPLY (SELECT SUM(total_pages) AS total_pages, SUM(used_pages) AS used_pages, SUM(data_pages) AS data_pages
    FROM sys.allocation_units AS al
    WHERE al.container_id = p.hobt_id
    AND al.type IN (1,3)) AS dp
 --lob pages are deallocated when heap records are deleted, display them for a complete overview
 OUTER APPLY (SELECT SUM(total_pages) AS lob_total_pages, SUM(used_pages) AS lob_used_pages, SUM(data_pages) AS lob_data_pages
    FROM sys.allocation_units AS al
    WHERE al.container_id = p.partition_id
    AND al.type = 2) AS lobp    
WHERE OBJECTPROPERTYEX(i.object_id, N'TableHasClustIndex') = 0 --table is a heap
AND OBJECTPROPERTYEX(i.object_id, N'IsUserTable ') = 1