Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
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: Tuesday, April 12, 2016 4:24 AM
Points: 31, Visits: 155
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


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: 2 days ago @ 4:17 AM
Points: 16,596, Visits: 31,178
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
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: Tuesday, April 12, 2016 4:24 AM
Points: 31, Visits: 155
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 Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, December 15, 2015 11:38 PM
Points: 202, Visits: 772
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
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, April 4, 2016 2:07 PM
Points: 77, Visits: 425
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 Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, December 15, 2015 11:38 PM
Points: 202, Visits: 772
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


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 9:40 AM
Points: 3,440, Visits: 7,980
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.



"If you break a few eggs, then make an omelet."
Post #1392665
Posted Tuesday, December 4, 2012 1:37 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 10:57 AM
Points: 14,208, Visits: 37,138
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

--
help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!
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: Wednesday, April 27, 2016 6:45 PM
Points: 336, Visits: 443
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-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 8:18 AM
Points: 40,410, Visits: 37,618
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."

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