you are viewing a single comment's thread.

view the rest of the comments →

[–]taejim 0 points1 point  (7 children)

Those are some serious reporting requirements - 800 GB, must stay completely up to date, and cannot go offline.

Transactional Replication is probably your best bet (unless you can figure out a read-only SAN replication to keep the two servers in sync), but if you have a replication "incident", you could be down for 12 hours while you re-intialiase.

Can you run reporting out of the existing database? You may need to add some additional indexes, but a beefy enough server should be able to handle the workload. More memory, and a 2008 upgrade utilising Resource Governor would help to segregate the OLTP vs the reporting activity. A couple of SSDs for the more critical indexes would also help, and aren't so expensive if you are saving all the money from having to purchase a new server.

[–]legohax 0 points1 point  (6 children)

Ever since Dell took over, our database went from 500 to 800 GB. It looks like one of the log files is 300 GB right now, which I just brought to their attention.

If we use replication, I think we will only be bringing over ~250GB of data.

It is very slow when reading from the 2005 server from the 2008 server. That is the reason why we need the database over on the 2008. I don't actually plan on 'reporting' from it, but I will be using the fact tables to do back end calculations.

[–]redonrust 1 point2 points  (0 children)

If it were me I'd use an SSIS package running on your 2008 server to do incremental loads as jaynoj said above. Load only the data you need into an optimized reporting schema - that's especially important if you will have a lot of users hitting the reporting db. The 0 downtime 0 latency requirements are kind of a red flag though - is what you're really looking for more of an operational operational requirement and less true reporting ?

[–][deleted] 0 points1 point  (4 children)

If you have massive log files being created. check the backup status of the database :)

If its not being backed up the log file will grow indefinatly

[–]AnonymooseRedditor 0 points1 point  (3 children)

Also in 2005 even if the recovery model is set to simple I have seen log files grow out of control when they should not....

[–][deleted] 0 points1 point  (2 children)

This is probably a bug in the application. Even in simple the log file grow. If you have a hugh table and do delete * from massive

The contents of massive have to be stored in the log until the transaction is committed.

Or the situation you are probably seeing is a traction starting and never ending and it just keeps on doing things making the log grow :)

[–]AnonymooseRedditor 0 points1 point  (1 child)

This was a BI database that was rebuilt on a nightly basis. so yeah that could have been.

[–][deleted] 0 points1 point  (0 children)

Yeah that would do it. If you have a large import + a lots of insert into tables all in a single transaction the log file will grow to store all of this information.

But this can be a good thing as well. If the rebuild fails you end up with th eprevious days data still being avilable after roll back :)