February 23, 2010 at 7:39 am
Steve Jones - Editor (2/22/2010)
How do you get rows per day?The formulas for calculating space are trivial. It's the information gathering that is hard.
you right steve, from our school we using the word suppose in math, which means virtual value not exact value, like that as per the database we can justify and in client meeting u can take the idea of their daily transaction, as per their final table structure. For that i also given a example of emp table.
M.I.
________________________________________
M.I.
[font="Times New Roman"]
February 23, 2010 at 8:36 am
sqlguy-549681 (2/23/2010)
Hello Steve,,as you said "The formulas for calculating space are trivial. It's the information gathering that is hard."
would you please tell what are the informations I must have?
This deserves an article, but for a new database, how do you know the rows per day? How do you know the distribution? Often you take a guess, but just as often that guess has no basis. You can guess wildly high and pad things, and what often happens is people start to then implement shrinks to keep the database closer to their guesses. Or you can guess low, in which case you need more space.
For an existing database, do you know the count of rows per day as an average? Almost no tables/schemas I see track this. They don't know. If I asked you right now, for your largest database, what is the rows/day could you easily get the info? Maybe on some tables, but not most of them.
My point is that SQL Server doesn't have a good method for tracking the rows/day. So your formula, while correct, isn't useful. Most people have no idea of distribution as well. How does the Employees table grow v the Tasks table, or the Time table?
I've done what Homebrew does for existing databases, track backup size. It doesnt' give you rows per day, but it gives you a rough average of the aggregate growth of data per day. If you track that, then you can guess in the future what you'll need xx months down the road.
February 23, 2010 at 9:26 am
if i use this query so i can find out how many rows does our largest SQL Server table contains?
USE AdventureWorks
SELECT o.name as [Name], i.rowcnt as [Row Count]
FROM sysindexes i
INNER JOIN sysobjects o ON i.id = o.id
WHERE indid < 2 AND o.xtype = 'U'
ORDER BY Name
if we see it today at the day end time so we can find the next day transaction and we can get the approperiate result of daily transaction. we required math daily.
Whats ur openion?
________________________________________
M.I.
[font="Times New Roman"]
February 23, 2010 at 9:52 am
okiftequar (2/23/2010)
if i use this query so i can find out how many rows does our largest SQL Server table contains?USE AdventureWorks
SELECT o.name as [Name], i.rowcnt as [Row Count]
FROM sysindexes i
INNER JOIN sysobjects o ON i.id = o.id
WHERE indid < 2 AND o.xtype = 'U'
ORDER BY Name
if we see it today at the day end time so we can find the next day transaction and we can get the approperiate result of daily transaction. we required math daily.
Whats ur openion?
My opinion is that I usually don't care about individual table growth. I'm concerned about database growth for capacity (storage space) planning, so that's what I look at.
Table growth, index size, etc is a separate topic for me, usually specific to a particular database and it's performance.
February 23, 2010 at 10:23 am
Sure you can run that query, but will you run it for every table adn every day? Or are you going to assume the growth that occurs today is representative? Any particular day isn't. It could be wildly up or down.
February 24, 2010 at 4:07 am
ya offcourse steve we required daily check for this.
Ok thanks for your feedbacks and suggestions. It was a pleasure knowing ur way of thinking.
________________________________________
M.I.
[font="Times New Roman"]
February 28, 2010 at 6:08 am
Guys,
really appreciate the valuable info I have got.. But so far I didn't get a solid way or clear steps to calculate my database required storage. I have thoughts and diff approach
Thanks In advance.
February 28, 2010 at 8:59 am
sqlguy-549681 (2/28/2010)
Guys,really appreciate the valuable info I have got.. But so far I didn't get a solid way or clear steps to calculate my database required storage. I have thoughts and diff approach
Thanks In advance.
It would appear that the question not yet asked nor answered yet would be... is this for new set of databases not yet in existance or is this for a system that is up and running?
If it's for a system that's up and running, then the suggestions that have already been made about monitoring backup sizes would be the best way to go because it's also the easiest to do. Otherwise, if you want clear steps to calculate the database required storage size, then lookup the following in Books Online...
[font="Arial Black"]estimating database size[/font]
--Jeff Moden
Change is inevitable... Change for the better is not.
March 1, 2010 at 4:36 am
thx for "Simple-Complex" reply :),, but at least I have a start point
thx again
March 2, 2010 at 9:35 am
sqlguy-549681 (2/28/2010)
Guys,really appreciate the valuable info I have got.. But so far I didn't get a solid way or clear steps to calculate my database required storage. I have thoughts and diff approach
Thanks In advance.
Perhaps your question and requirements have not been made clear to us.
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply