Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
NewMedia42
Starting Member
35 Posts |
 Posted - 2001-06-15 : 14:20:18
|
| I'm in the process of writing an application that relies heavily on a somewhat large database; the complete database is around 2gig of information. The snag is that the actual contents of the database are COMPLETELY regenerated once (or more) a week (none of the previous information is valid enough to be useful). My question is, what is the best way to update the database without having any (significant) downtime? My current solution (which I am not thrilled with) is to have two duplicate databases, and while db1 is live, I rebuild db2 and then manually change the ODBC account to use the second database (is this scriptable somehow?). Here are some of the ideas I've toyed around with trying, but haven't yet:1. Instead of manually changing the database from the ODBC account, change it inside of SQL by issuing some sort of command (I like this one, but don't know if it's possible)2. Copying the information from the newly built database over the old one.3. Changing the query programs to load a value stating which database is active, and then making all subsequent requests using that value.Anyway, I hope someone can help or shed some insight on the problem... I think that it should be interesting (to say the least) to anyone who maintains a realtime database that requires massive updates periodically without any downtime. |
|
|
|
|
|
Updating a large (2gig) database without downtime