Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have 2 servers. They both host identical applications, each with its own local database. The application needs to lock the database row for write sometimes, so sharing the same database would be a performance hit (or is it?).

If I want the two servers share the same database to avoid data redundancy, how do I do it without a performance hit? Is database clustering the right direction?

share|improve this question

migrated from Dec 13 '10 at 2:12

This question came from our site for professional and enthusiast programmers.

What kind of redundancy? Do the applications need to share any data? Or do you just want to save resources (but the two data sets are completely unrelated)? – Thilo Dec 11 '10 at 7:48
Please also provide some information on which database you're using as the way to cluster and/or replicate a database greatly depends on the database used. And please also give some more information on what type of application is in front of the database and for instance how many reads and writes these applications perform in general. – Tim Dec 11 '10 at 7:53

You could put all the database load on one server, and all the web server load on the other, ie have one database, and one webserver. That might be the simplest way to distribute load without complex clustering.

It depends on the load which each component is creating, and where the bottle neck is, as to the right solution.

share|improve this answer

If the two applications share the same data (I mean really the same data, same schema, same tables, not just the same database server process), then they need to be synchronized when updating the shared data. You mention row locks. Those need to be present, whether you cluster the database or not. However those locks are fine grained, they only block concurrent access to the same row (or table in case of a table lock). With Oracle, a row lock does not even block queries to the same row (just other updates). So you should only encounter lock contention when the two applications are really updating the same shared table very frequently.

If the two applications do not share any data, then any locks on tables or rows will not affect the other application at all. They will only compete for global locks (very rare in sophisticated database servers) and shared resources (memory, server CPU, disk space, I/O and network bandwidth). If a single database server instance is not even close to being saturated when hosting the two applications, you do not have any problem here. When you see saturation, you can put the two applications' schemas on separate machines.

share|improve this answer

you can use ETL Extract transform load technique for migrate your data. after u use ETL both of your database existed. you can run them on pararel test to avoid performance hit. the database clustering is not need for this issue.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.