I have a 90 GB SQL Server database that I want to make more manageable. It stores stock data from 50+ different stocks from 2009 and 2010, and each stock is a separate table. Some tables have hundreds of millions of rows, and other have just a few million.
What I want to do is somehow split the database, so that I don't have a single database file that is 90 GB.
What I want is to be able to somehow magically split all the tables so that I can backup the 2009 data once and not have to keep on including it in the backup every time I backup the entire database, however, I would like the 2009 data to be included whenever I do a query.
Is partitioning the database the way to go? Will it do the above for me, or will I need some other solution? I research partitioning, but I wasn't sure if that would solve all my problems. I wasn't able to find anything that would tell me whether or not it would migrate prexisting data, or whether it only worked for newly inserted data.
Any help or pointers would be much appreciated.
Thanks in advance,
Ken
Best Answer
Kimberly Tripp put out a great webcast series that answers questions just like these. Instead of making a general recommendation fro your specific case, I think it would be better to check out this webcast. I'm sure it will give you the guidance on partitioning and aging to make the right decision for your situation.