February 22, 2010 at 7:03 am
stoviber (2/22/2010)
My big gripe at the moment is the size of the database, circa 300GB meaning any recovery wont be quick and when I start looking at replicating the database for fault tolerance I'll need a big disk on any second box. I was thinking that I could easily offload the large portion of the current DB to a seperate archive database, allowing me to have a slightly more nimble 'front end' database.
Do you guys think this is a viable option?, we have no real burning desire to look at the historical data, its only queried on occasion.
If you are currently using partitioning to slide out your historical data then thats a big preformance gain to lose. If not then I don't see why not if a smaller 'live ' database is important to you. either way the historical data should be read only, either in filegroups or a separate database.
---------------------------------------------------------------------
February 23, 2010 at 2:27 am
Yip I think i'm pretty much set on the archival idea at the moment, it makes lots of sense for some other ideas we have. Thanks again for your help guys.
February 23, 2010 at 4:20 am
If I have understood your question, you have 2 log file on eof SCSI and other on RAID 5, then you added another log file on RAID 5. Now you dont want SQL to use the 2nd log file that was created earlier.
Solutions: Take the log backup, Shrink the second log file to the minimal. Then stop the auto growth for these 2nd file. Log file would grow on 2 files i.e. one on the orginal SCSI file and second on the new log file that you have created last. Also if there is no data in the log file you can go-ahead and delete the file from SSMS.
brijesh
February 23, 2010 at 4:23 am
Brijesh Mehta (2/23/2010)
...<snip>...
The original question was solved a long time ago.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply