I know it is used in BOL and in a lot of other places. In my not so humble
opinion, it is not correct terminology and is the most misused term dealing
with replication. I've encountered way too many people who see
bi-directional, like it is really cool and exactly what they need, implement
it, and then watch their entire environment melt to the ground. They then
refuse to ever implement replication again, because "it doesn't work" or "I
had a really bad experience and won't ever try that again". That is because
there are a lot of people, you NOT included, who flip that term around all
over the place without the slightest clue what it really means and BOL
exacerbates the problem by trying to make it look a whole lot easier than it
really is.
I have one other term for bi-directional replication that I know Microsoft
doesn't like to hear. "Chaos everywhere" Bi-directional replication has no
arbiter. In a bi-directional system, unless you place a business
restriction on the data flow, there is zero possibility of defining the
state of your data at any point in time. That is because part of the data
is on one server, part of the data on another server, and part of the data
in the distribution database. On top of that, the data in the distribution
database from server 1 has absolutely no clue about the data in the
distribution database from server 2 and no agent in the system has the
slightest clue they are part of the same database "state". In addition, you
have to add in a parameter that prevents the replication engine for working
the way it was designed to work and explicitly preventing it from performing
some of its operations. If you toast the distributor in a bi-directional
system where you allow transactions on both sides, I give you a less than
zero chance of restoring the system without losing data.
Merge replication is two way data movement by default. It is not
bi-directional. Why? It does not suffer from any of the flaws of a
bi-directional system. The engine always knows the precise state of the
data. There is always a single arbiter which can define the master set of
data. And, you do not have to configure anything to prevent the engine from
working the way it was designed. The same holds true for queued updating as
well as immediate updating. There is a reason that for the last 8 years,
I've been VERY careful to distinguish between two way data movement and
bi-directional replication.
--
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com http://www.mssqlserver.com
