ok here is a brief on the below mentioned 3 technologies:
Q Replication:
Utilizes asynchronous queues to deliver and acknowledge data movement
from source to target. The main product doing this could be IBM's MQ
Series. The benefit is that you are not generating SQL logs for the
metadata tables of replication ( Change data tables). Its is
separately licensed product from IBM, which you need to purchase.
SQL Replication.
Utilizes SQL tables and apply and capture processes to deliver and
acknowledge the data movement from source to target. it comes free
with some versions of DB2. for other versions, you need to purchase
the license separately. It has an IO impact on the databases due to
the extra logging overhead due to transactions happening at
replication metadata level.
HADR:
HADR is not a replication solution, but a hot standby solution. At any
given time, which the log movement is in progress, only one of the two
servers can be online and actively serving clients.
hth,
dotyet.
On Jul 9, 10:00 am, Veeru71 <m_ad...@hotmail.comwrote:
We have got 2 DB2-UDB databases (DB1 & DB2) running on separate
instances( Inst1 & Inst2).
DB1 has got Schema1 and DB2 has got Schema2.
We would like to setup some kind of replication to replicate both
Schema1 & Schema2 onto a 3 rd database (DB3) running on a 3 rd
instance (Inst3). This is basically to separate out Data Reads
(Reports module of the app) from the primary databases for performace
reasons. Also, Some of the Reports join tables across Schemas (hence
we would like to have both the schemas on the same database on the
target side).
Both Schema1 & Schema2 have got hundreds of tables and the total size
would be @ 800 GB.It is really a humongous database. We CAN afford to
have time lag (probably few mins to an hour) between source DBs & the
targe DB.
I have heard things like Websphere Information Integrator, Q
Replication, SQL Replication, HADR etc, but I am not sure which one of
them is the right choice for our need.
Can someone throw some light on this ?
Thanks