August 20, 2009 at 8:13 am
HI ,
as a DBA how can we estimate the size of the database at the time of creating database in production servers and what factors need to be considered while we are selecting the autogrowth option .
replies are valuable .
thanks
August 20, 2009 at 8:41 am
First, you look at the data-size expected in the tables, and you look at the expected volume of inserts and deletes. That'll tell you what to expect for each table. Add those together, remembering to include indexes, and perform the necessary math, and you'll have a good idea of the expected size of the database.
Or, for a "rule-of-thumb" solution (less math, more looking), set up a copy of the database and load it up with test/fake data. For example, if you have an orders table, and you expect 100 orders per day, insert 18,000 rows of data into it (enough for about 6 months). Do the same sort of thing for each of the other tables. See how big the database ends up, and how fast it grows, and use that as a starting point.
If you don't want to do all that work yourself, RedGate has a data generator that'll do it for you.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
August 20, 2009 at 8:42 am
Read this: http://msdn.microsoft.com/en-us/library/ms187445.aspx
However the big factor is how much growth you are going to have from new data. If you have no idea what load you'll have, however people will enter data (or systems will), then there's nothing you can do.
What you can, and should, do is track this and regularly adjust the size of the database. Autogrowth is an emergency option, not the way to manage space.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply