yes, assuming they are not using any features of streams to perform 'ETL' on the data as it goes into the reporting instance.

a) yes

b) i would not recommend that, use CDC (change data capture) or streams if you want to "do it yourself"

c) I would look for an approach that did not involve replication myself :) replication complicates everything

Streams would likely suffice given you just want to do this as a straight conversion - one time only - with no 'transformations'. If you just want a database on the other platform that looks like the original, and you'll cut over to it and then turn off streams, that would be my first approach (you already have everything you need)

if you wanted to do complex transformations or do this replication long term - golden gate would become more likely

I guess I made the assumption they wanted to do this move with little to no downtime involved. I made that assumption because of the two tools they mentioned - both of which can accomplish that.

If they can have downtime, then yes, datapump would be the likely tool of choice.


since it is only 10gb (teeny tiny - probably less than 5gb of real data, indexes don't have to move, they get recreated), datapump would be able to do it in minutes - so that would be reasonable.

and both active instances,

that is only reasonable if you make it so that a given row of data can be updated in exactly ONE location at any point in time.

Meaning - you run application A at site 1 and have it 'dr' to site 2. You run application B at site 2 and have it 'dr' to site 1. A's tables are updated at site 1 ONLY unless it fails over to 2. B's tables are updates at site 2 ONLY unless it fails over to site 1.

OR - half of table T1 is updateable at site 1 ONLY (unless site 1 has failed over) and the OTHER HALF is updateable at site 2 ONLY (unless....)


the reason I say this is because I do not know of any developers (self included) that can build an update anywhere system for any piece of non-trivial software that accounts for all update conflicts and can resolve them. It is just way way too hard, far too expensive, and extremely fragile.


It would be much better to just have data guard in place - you can fail over in *seconds* - literally *seconds*. If you do the "run app a at 1 and b at 2" and have 1 and 2 be failovers for B and A - you have what you want - honest. it will work, it will be easy, it will be safe, it will be fast, it won't require better developers than exist in the world to build software, you can use it with off the shelf software - every thing is good.

If you try to do update anywhere replication - you need developers that don't exist, you cannot use off the shelf software, you will be administering and fixing this system 24 hours a day.

Since an appserver connects (and runs dml on any given session without
disconnecting) on just 1 node, isn't it possible for the application to update
what it wants without blocking or damaging other data? Aren't deadlocks (for
example) treated equally?

I don't know what you were trying to say there - it is not active active over a long distance in your example there.


the problem with DR is that the client now has 2 DB servers with RAC and
wants both the safety of 2 remote sites, with the availability of 2 remote
sites and the use of all the servers so that there aren't DBservers or
APPservers "sleeping" while others handle all the workload.

Ahh, the fallacy of active/active. The thought that it will somehow require less resources, or use resources 'better' in some fashion. when in fact - the opposite is true.


Let us say for a minute that you run on one site and just use simple data guard to have a DR site. The one site needs to be able to

a) runs its DML work load and generate undo
b) ship undo to remote site <<<<==== (a) is 'obvious', this is the extra work

If you go with two sites 'active active', then

a) each site must run its DML work load *and the DML work load of the remote site* - only less efficiently (replication via golden gate/streams/etc turns a single sql statement that updates 5 rows into 5 sql statements to update 1 row apiece).

b) ship their undo to remote site

c) each site must process redo and turn it from its binary form into a logical record to to the update (new extra work)

d) each site must apply this converted information all of the while looking for update conflicts (extra work)

e) and then invoke the update conflict code (which is REALLY hard to code/design/implement)

f) and then there is the extra management work of maintaining this rather complex flow of data


You actually need two larger servers than you would if you just ran "active and DR".


So in your opinion, there is no point in using streams or GG (even given my
latest info)? Because in that case, what are streams and GG good for, if the
applicational layer is so heavily impacted by this configuration, and like you
say we can't use of of the box?

I am saying "do NOT go for update anywhere, partition your data so that it is only updateable on ONE SITE at a time, avoid any chance of update conflicts".

The easiest way to do that is run "module1" of application A on site 1 and "module2" of application A on site 2 (or run A on 1, B on 2)

Or, starting to introduce a lot more complexity, Run deptno=10 on site1 and deptno=20 on site2, and so on - partition the data so that it is updateable on one site only.


I'm not sure what you were trying to say with RAC. With RAC you have at least two nodes from day one - or you don't have RAC, you have a single instance.

And RAC is NOT DR, RAC is high availability in a room. Data Guard is DR.

You shouldn't need to do anymore than one data center with a lights out failover if you wanted - you just need the network infrastructure.

I access the single production data center at Oracle (which has a failover). It is in Texas. I live in Virginia. Many people live - well - not in Texas - in fact probably 99% of the company doesn't live in Texas (some in Australia, some in the UK, Japan, Russia, etc). We all use the same apps running in the same data center running on the same database.

Active/Active - you won't be doing that with any 3rd party applications (show me a major product that is available that does that - out of the box, supported, no customization).

Active/Active - you'll need to hire *way* better programmers. I myself wouldn't want to touch it.

are you trying to ask something or just make the statement that "an application has to be built to replicate in order to replicate, you cannot just replicate any old application and think it will work"?

to use streams, you would implement a custom apply process, your apply process would be invoked with a logical change record (LCR) and you can do whatever you want with it.

CDC would not be involved at all.




this is the documentation for the GoldenGate -> JMS interface:

http://docs.oracle.com/cd/E18101_01/doc.1111/e17814.pdf