Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Reduce database size Expand / Collapse
Author
Message
Posted Thursday, November 29, 2012 7:23 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, September 22, 2014 4:36 PM
Points: 30, Visits: 138
Have been asked by a customer to reduce the database size to latest 10% of its data. Not sure how to achieve this. Any help regarding this would be very useful. Thanks in advance.
Post #1390534
Posted Thursday, November 29, 2012 8:35 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 8:42 AM
Points: 14,037, Visits: 28,407
Your choices are pretty limited. You can remove data and then shrink the database. You can use storage compression if you're using Enterprise in SQL Server. You can look at a third party product like Red Gate SQL Storage Compress (disclosure, I work for Red Gate).

In general, simply saying, make the database smaller, is somewhat difficult to answer. Why do they need this. What are you trying to achieve? Is it just a storage issue or something else going on?


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1390611
Posted Thursday, November 29, 2012 9:29 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, September 22, 2014 4:36 PM
Points: 30, Visits: 138
Its basically a storage issue and they are not in a position to expand the LUN being a UAT box
Post #1390663
Posted Thursday, November 29, 2012 11:43 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, October 3, 2014 1:55 PM
Points: 199, Visits: 735
A further possibility could be hidden within the indexes. Do indexes have much fragmentation or are they reorganized regularly? Fragmented indexes can have a lot of impact on the their size .I have seen tables without doing maintenance for some weeks, after rebuilding they needed about 50 GB (!) less storage.
Another step could be to analyze index usage. If indexes are not used they should be dropped as they need storage space too. (Please don't start dropping indexes now, analyzing is a little bit of work )

Another possibility is thinking of the storage type. If your storage is for hig availability it might be expensive. Is there data that can be moved to an archive? Could the archive be placed on an less expensive storage as the archive might be "less secure"?

Also check the size of the database log files and analyze if the size is really needed. Check if you can reduce log growing using a more frequently log backup.

Check the size of the database files too. A database file might have lots of storage reserved but only less of it actually used (maybe the file growed for example due to index rebuild operations). Try to shrink the file to an appropriate size.
Post #1390746
Posted Sunday, December 2, 2012 11:50 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, November 10, 2014 5:24 PM
Points: 68, Visits: 377
Grant is right about the indexes and transaction logs. Be sure the database is in simple mode, and run the DBCC ShrinkDatabase(<databasename>, 10) to recover any disk space that may be available from the log commitments. You mentioned that it is UAT. What are the testing requirements? Do you need to do a load test? Can you cull down the data, based on a date field? I just went throught this excercise on a development system. I asked our business users for the primary filter criteria, which turned out to be Member State. I applied a filter that focused on just 3 states for claims data. Once I deleted all the unwanted data and did a ShrinkDatabase, I reduced the database size on disk from 222GB to 74GB.
Post #1391784
Posted Monday, December 3, 2012 1:16 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, October 3, 2014 1:55 PM
Points: 199, Visits: 735
I would NOT recommend use SHRINKDB "just for fun". Of course is clears all unused disk space but it also can have it's negative impact, from maximum fragmented indexes to performance, as for some operations the file has to grow again.
Also setting recovery model to simple should be diskussed. It depends on how many data you lose if your system crashes. The full recovery model is no problem if you backup and thus empty the log file regularly.
Post #1391796
Posted Tuesday, December 4, 2012 12:44 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Sunday, November 23, 2014 2:48 PM
Points: 1,754, Visits: 4,966
ranganathleo (11/29/2012)
Have been asked by a customer to reduce the database size to latest 10% of its data. Not sure how to achieve this. Any help regarding this would be very useful. Thanks in advance.

Perhaps the easiest way to approach this disk space issue in UAT would be to periodically drop and restore the datbase from a backup.
Post #1392665
Posted Tuesday, December 4, 2012 1:37 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 1:08 PM
Points: 12,927, Visits: 32,333
to get it to 10% of it's original size, that means deleting 90% of the data? i don't think that's what you are really asking.

besides the points above, (and compresison would be my first choice), find every table that is a HEAP, and put a clustered index on it; HEAP tables never release the space taken by deleted rows.


Lowell

--There is no spoon, and there's no default ORDER BY in sql server either.
Actually, Common Sense is so rare, it should be considered a Superpower. --my son
Post #1392680
Posted Tuesday, December 4, 2012 1:57 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 3:02 PM
Points: 325, Visits: 441
Sorry, I'm a newbie. What's a 'LUN', and what's a 'UAT'?

Jim
Post #1392690
Posted Tuesday, December 4, 2012 5:35 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:55 PM
Points: 35,618, Visits: 32,214
WolfgangE (12/3/2012)
I would NOT recommend use SHRINKDB "just for fun". Of course is clears all unused disk space but it also can have it's negative impact, from maximum fragmented indexes to performance, as for some operations the file has to grow again.
Also setting recovery model to simple should be diskussed. It depends on how many data you lose if your system crashes. The full recovery model is no problem if you backup and thus empty the log file regularly.


It is, however, a UAT box. Unless you're doing Point-in-time backups on your UAT box, there's no need to use any recovery mode other than SIMPLE. Also, a UAT box probably won't suffer the same amount of activity so it's not likely the log fie needs to be as large as the production box.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1392749
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse