BE2010 DLO: How to remove excluded backupdata from SQL database?

[Jukka_H]

Hello,

Backup Exec 2010 R2 on Windows 2003 Server / SQL Server 2005.

We have removed certain filetype from backups by adding that filetype into the global excludes list.
We know that it should be safe to delete the remaining files from backups manually without breaking the SQL database.
The problem is: These excluded files are still located in SQL database and they do not seem to disappear at all,
and files have been excluded for several months now.

Is it possible to remove these files from Database or compress/reset or re-create the database somehow?
if it is possible, what is the safest recommended method?

Regards,

Jukka

[VJware]

What types of files were excluded ?

And the storage media holds the backups and not the SQL DB which is used by BE. What exactly do you mean when you say the excluded files are located in the SQL DB ?

[Jukka_H]

Thanks for the quick response!

The files are .PST -files, and to clarify the issue:

When we run a report from the database before and after deleting the PST -files,
the size of the database will not decrease at all, it will remain the same.

So not really the pst files, but the information remains in the database, is there
any way to remove the pst -information from the database?

[VJware]

No files are stored in the DB and deleting information from the DB would not actually reduce the physical size. Reducing the physical size of a SQL DB requires one to run DBCC SHRINK commands.
 

[Jukka_H]

I understand that the DB does not contain any actual files, but the DB shrinking is
the final goal we are looking for.
There seem to be a lot of discussion about the DBCC SHRINKFILE -function in
all around the SQL forums.
Some say it could be very risky and not recommended action to use the DBCC SHRINKFILE:
http://www.mssqltips.com/sqlservertip/2055/issues-with-running-dbcc-shrinkfile-on-your-sql-server-da...
and also:
http://www.sqlskills.com/blogs/paul/backup-log-with-no_log-use-abuse-and-undocumented-trace-flags-to...
-Any further advise concerning the DBCC SHRINKFILE or rebuilding the database will be greately appreciated!

[VJware]

I am guessing you are referring to the SQL DB used by BE. In that case, the second article wouldn't apply as the recovery model of the BE's database is Simple.

If the DB has really grown large in size, running DBCC SHRINK once in a while would not cause fragmentation as mentioned in the first article. Fragmentation can be caused by continuous activity on the DB and continuous usage of the SHRINK command.

[Jukka_H]

Thank you for the advise!

We shall consider running the SHRINK command, and will let
you know if we decide to try this on the production DB...

Regards,

Jukka