C
ChUIMonster
Guest
You have to issue two proquiets. One for each db. They know nothing about each other and make no attempt to synchronize. Sure, they will usually be close. And if close is good enough that's fine. If close really isn't good enough then there is always two-phase commit. But you better be really sure that's what you really need because it carries a performance penalty. At least that's what "people" say -- I don't actually know because I've never felt like it was something that I needed and I have never had a customer feel that way either. In practice most of the multi-database implementations that I come across have one main database that is the target of most transactions. The other databases are read-mostly or are some sort of largely independent bolt-on where exact synchronization is not critical. You could also always consider restore and roll-forward to a point in time. In practice simply restoring the backup isn't adequate. You cannot just toss out X hours of transactions. You also have to recover from your after-image logs to some particular moment. So you could use the point in time recovery as a method to get everything synchronized. On 10/30/14, 4:13 PM, Thomas Mercer-Hursh wrote: RE: Online Backup of Multiple Databases Reply by Thomas Mercer-Hursh If you have a user active with a transaction that spans the two databases ... or, simpler, perhaps, two users, each with a transaction active each in separate databases, what happens when one issues the proquiet? Stop receiving emails on this subject. Flag this post as spam/abuse. -- Tom Bascom 603 396 4886 tom@greenfieldtech.com
Continue reading...
Continue reading...