Dataguard won't help, you cannot write to both sides at once.

Active/active demands a few things, and not just from the DBA:

A technology as John mentioned to keep the data flowing between systems
An understanding of how the technology actually replicates information as this may affect day to day operation
Strong application discipline for collision handling and fault detection
In fact, strong application discipline in general
A plan in place for the breakdown of ACID compliance, i.e. I would anticipate dirty reads
A more complex than usual recovery strategy


Exceptions exist to these of course, but they are few. An example would be where either side only writes to her own parts so there is no possible DML/DDL collision whilst still allowing either DB to see the others data in 'near' real-time (YMMV, I often see lag between systems).

Bluntly, if you are a DBA and not the developer of the system then I would say the most important thing you can likely do is ensure your responsibilities stop and start at the database/s being up, available and backed up. Anything else is asking for an absolute world of pain you do not want. If you are the developer, you're going to have your work cut out for you, it'll be a great challenge for a while but I wager you'll soon end up cursing this approach as the requirements evolve over time.

In all honesty, I've never seen a good use case of this where transactional integrity matters anywhere. I tend to see it presented as a fait-accompli as a questionable solution to a non existent problem.

Thanks Roachcoach, Unfortunately I am in an umbrella role. I was hired as a DBA and am receiving Developer tasks.

Thanks Roachcoach, Unfortunately I am in an umbrella role. I was hired as a DBA and am receiving Developer tasks.

Thanks Roachcoach, Unfortunately I am in an umbrella role. I was hired as a DBA and am receiving Developer tasks.