|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: 2 days ago @ 7:25 AM
Points: 19,
Visits: 74
|
|
| 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.
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Today @ 8:05 AM
Points: 13,382,
Visits: 25,181
|
|
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 2012 Query Performance Tuning SQL Server 2008 Query Performance Tuning Distilled and SQL Server Execution Plans
Product Evangelist for Red Gate Software
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: 2 days ago @ 7:25 AM
Points: 19,
Visits: 74
|
|
| Its basically a storage issue and they are not in a position to expand the LUN being a UAT box
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Today @ 1:01 AM
Points: 74,
Visits: 420
|
|
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.
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Yesterday @ 5:25 PM
Points: 60,
Visits: 304
|
|
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.
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Today @ 1:01 AM
Points: 74,
Visits: 420
|
|
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.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Today @ 8:10 AM
Points: 1,164,
Visits: 3,339
|
|
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.
"Wise people understand the 10,000 things without going to each one. They know them without having to look at each one, and they transform all without acting on each one." - The Tao Te Ching: Verse 47
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Today @ 8:52 AM
Points: 11,645,
Visits: 27,745
|
|
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
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Friday, May 10, 2013 7:30 AM
Points: 225,
Visits: 317
|
|
Sorry, I'm a newbie. What's a 'LUN', and what's a 'UAT'?
Jim
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 8:14 AM
Points: 32,910,
Visits: 26,802
|
|
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."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|