December 3, 2003 at 12:50 pm
I was reading Kumar Part's article on Federated databases and the interesting part was about marking transactions so that recovery of all databases could be synchronized. The problem is that if the name of the transaction is either hard coded in a procedure or even if it's variable it would be difficult to determine which marked transaction you're trying to stop at. The only way that I can see is to included the mark name (which would have to be unique) with the record being inserted or updated so that you would now where to stop the recovery. You could use the AFTER parameter but if it is a highly transacted application there could be tens or hundreds of transactions a second so you still might include and unwanted transaction in your recovered database. What has been your experience with this?
December 3, 2003 at 8:12 pm
Hi there
To be honest, federated DB's are a complete waste of time and is such a crazy hair brained scheme I wouldnt touch it with a 20ft pole for my prod system 🙂 trying to recover from system failure, where we have multiple instances for the same "logical database" is not my idea of solid, architectural design sence (nothing personal, just my honest thoughts on federation).
Anyhow.... *grin*
Did you check msdb..logmarkhistory as a possible guide to resolve your issues?
Cheers
Ck
Chris Kempster
Author of "SQL Server 2k for the Oracle DBA"
Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
December 4, 2003 at 7:22 am
Well, I don't have any issues. I don't have a system implementing federated databases I was just thinking about this as I read the article. However, I am surprised at your response to the concept of federated databases. What would be your solution to scaling an application. Scaling up can go only so far at some point you must consider scaling out. What solution do you recommend for scaling out?
December 4, 2003 at 8:33 am
Hi there
Lets see, multiple database servers all working simultaneously on the same database files, now thats my idea of scaling out. SQL Server has no offerings down this space at present. If you design federation from the ground up you may have a chance, its the same as distruted databases using replication (but is a completely different architecture), and one would probably go down this path over federation. I believe Oracle is a better way to go if scaling out is your last alternative.
Cheers
Ck
Chris Kempster
Author of "SQL Server 2k for the Oracle DBA"
Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
December 4, 2003 at 9:18 am
quote:
Hi thereLets see, multiple database servers all working simultaneously on the same database files, now thats my idea of scaling out.
I think you're confusing federation with clustering. Federation is creating independent databases on separate servers and linking them via distributed partitioned views.
--Buddy
December 4, 2003 at 6:16 pm
Hi there
The federation concept (via the linked servers and unioned views etc) is the architecture im saying is not worth the trouble. I can think of some rare cases, perhaps distributed regional centres, but for a performance gain? spreading your dbms over multiple servers seems very strange to me and a nightmare to manage in terms of DR.
Clustering is very different, only one instance can CRUD the database files at any one time, its only a fail safe solution with some scale up opportunities, no scale out.
Have a good read of oracle rac along with grid computing, and see what they are up to in this space
Cheers
Ck
Chris Kempster
Author of "SQL Server 2k for the Oracle DBA"
Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply