I
have used both.
Replication, like archive log movement , happens whenever you set it up
to happen. That can be anywhere from every minute to once a day to
beyond. It just depends on your needs. In the case of my old job,
we had replication happening at different times for different
tables. Our key table was replicating IMMEDIATELY upon any
changes to the parent table. This happened via
trigger. Other , not so important tables, would replicate at
anywhere from 30 to 60
minutes. We did this using scheduled jobs.
I
see two real nice advantages of replicated databases. One,
they are accessible. i.e. you can run reports, queries, etc on
them. They are nothing more than instances that get updated via a
foreign database. Two, depending on what kind of software you use,
you can update the database from an outside source. We used to
have data sent down from our DB2 database into our Oracle database using an
oracle product called Replication Services (nothing more than triggers and a
specific data structure) and an IBM product called Data Propogator.
Archive log transport for standbys can happen in
multiple ways also. The newer oracle versions support direct archiving
from a production database to a standby database. I have not tried this
yet but we are looking into it. Our current standby databases are
brought up to date with a shell script that is scheduled via cron every 20
minutes.
The thing about the standbys, they are all or
nothing ... you can not just say I want only tables 1-10 to be updated.
They all are. Also, in the older oracle versions, the standbys could not
be accessed via software so you could not use them as any sort of read only
database. This is not the case in a replicated database.
But, they are also very easy to rebuild and resetup. Just copy your
production files over, create a standby control file, and bring the databse up
in standby mode. Very easy.
Now... which would I recommend ???
Depends on your needs.
If you really need to access that copy of the
database for other purposes and you only want certain tables to be updated,
then I would consider replication. If, on the other hand, you do
not have to access the data (until such a time as your production gets killed
and you need your standby up) and you need a fast way to rebuild the second
database, I would suggest the Standby
approach.
Kevin
Is
replication faster than a standby database. As I understand it, the
standby database will be receive arch logs at preset intervals. Does
replication have the same functionality and about how much data is sent to
the replicated site.
The way I see it ..... the question comes down to whether or
not you need two way replication or just one way. If both
databases can update those tables and you need them synced between the
databases then Advanced Replication would be the route. If all
you need are data changes from 1 database to be replicated to another
database then simple replication is all you need.
Depends on your need.
You can have read only snapshots, updatable
snapshots
or multimaster...
Again if you think of multimaster... then
you would need to make decision
based on your application requirements
about sync or async
I donot have any expereince of snapshot
replication.
But, if you are planning multimaster
replication, then better
spend a couple of months studying it and
testing on test boxes...
Make 100% sure that your
application really needs the replication
and there is no other simpler
option...
Just 2 cents...
+Rahul
----- Original Message -----
Sent: Monday, March 04, 2002 3:33
AM
Subject: replication
question
Dear Gurus,
The clients will enter records to a
database all day and I will update the other database .
I need to replicate 10 tables in a
database to other database at a specific time.
Do I need Advanced replication or
basic replication . ?
How can I understand that replication is
supported in my both databases. ?
Bunyamin