RMAN ACTIVE DATABSE DUPLICATION On NETWORK SERVER

Creation of Database same as it in source DB by using Active database duplication.

 Prerequisite:-
1. Oracle_home is already created.
2. Oracle Binary already copied.

 SOurce DB:- Prod(192.168.1.101)
Target DB:-Test(192.168.1.102)

 On source DB perform.

 [oracle@Prod 11.2.0]$ . oraenv
ORACLE_SID = [oracle] ? Prod
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 is /u01/app/oracle
[oracle@Prod 11.2.0]$ sqlplus / as sysdba

 SQL> select name from V$database;

 NAME
---------
Prod


SQL> select name from V$controlfile;

 NAME
--------------------------------------------------------------------------------
/u02/Prod/redologcontrol/control01.ctl
/u02/Prod/redologcontrol/control02.ctl

SQL> select member from V$logfile;

 MEMBER
--------------------------------------------------------------------------------
/u02/Prod/redologcontrol/redo01.log
/u02/Prod/redologcontrol/redo02.log
/u02/Prod/redologcontrol/redo03.log

 SQL> select name from V$datafile;

 NAME
--------------------------------------------------------------------------------
/u05/Prod/oradata/Prod/system01.dbf
/u05/Prod/oradata/Prod/sysaux01.dbf
/u05/Prod/oradata/Prod/undotbs01.dbf
/u05/Prod/oradata/Prod/users01.dbf

 SQL> show parameter pfile

 NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      /u01/app/oracle/product/11.2.0
                                                 /dbhome_1/dbs/spfileProd.ora
SQL> create pfile from spfile;

 File created.

 SQL> exit

[oracle@Prod 11.2.0]$ cd /u01/app/oracle/product/11.2.0/dbhome_1/dbs/
[oracle@Prod dbs]$ scp initProd.ora oracle@192.168.1.102:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/
oracle@192.168.1.102's password:
initProd.ora                                                   100%  973     1.0KB/s   00:00   
[oracle@Prod dbs]$


On TARGET DB
===========
1. Create all the directories structure

mkdir -p /u02/Test/redologcontrol  ---- For Redo log file and Control file
mkdir -p /u03/Test/archivelog   -- for archive log file
mkdir -p /u04/Test/backup    -- for Backup
mkdir -p /u05/Test/oradata/    -- for database file
chown -R oracle:oinstall /u02 /u03 /u04 /u05
chmod -R 0775 /u01 /u02 /u03 /u04 /u05
mkdir -p /u01/app/oracle/admin/Test/adump
mkdir -p /u01/app/oracle/flash_recovery_area/


2. change the Prod database parameter file according to Test database.


[oracle@Test ~]$ cd /u01/app/oracle/product/11.2.0/dbhome_1/dbs/

 [oracle@Test dbs]$ cp initProd.ora initTest.ora
 [oracle@Test dbs]$ rm -r *Prod*---------------------TO delet file related to Prod DB

 3.Edit initTest.ora file

*.audit_file_dest='/u01/app/oracle/admin/Test/adump'
*.control_files='/u02/Test/redologcontrol/control01.ctl','/u02/Test/redologcontrol/control02.ctl'
*.db_name='Test'
*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=TestXDB)'
*.log_archive_dest_1='LOCATION=/u03/Test/archivelog'
DB_FILE_name_CONVERT=('/u05/Prod/oradata/Prod', '/u05/Test/oradata')
LOG_FILE_NAME_CONVERT=( '/u02/Prod/redologcontrol','/u02/Test/redologcontrol')

 4. create sid and password file

 [oracle@Test admin]$ export oracle_sid=Test
[oracle@Test admin]$ . oraenv
ORACLE_SID = [oracle] ? Test
ORACLE_HOME = [/home/oracle] ? /u01/app/oracle/product/11.2.0/dbhome_1/
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1/ is /u01/app/oracle

 SCP password file from source /u01/app/oracle/product/11.2.0/dbhome_1/dbs/ to target server /u01/app/oracle/product/11.2.0/dbhome_1/dbs/

 $mv orapwProd orapwwTest

 5.>Startup database in nomount
 [oracle@Test admin]$ sqlplus /as sysdba

Connected to an idle instance.

 SQL> startup nomount
ORACLE instance started.

Total System Global Area  828608512 bytes
Fixed Size                  1339684 bytes
Variable Size             490737372 bytes
Database Buffers          331350016 bytes
Redo Buffers                5181440 bytes
SQL>

 6>Creation of Listener .

 cle@Test bin]$ pwd
/u01/app/oracle/product/11.2.0/dbhome_1/bin
[oracle@Test bin]$ netmgr

7> startup listener

[oracle@Test admin]$ lsnrctl start

8>Make entries of Test and Prod databases in tnsnames.ora file
[oracle@Test admin]$ vi tnsnames.ora
[oracle@Test admin]$ cat tnsnames.ora
Test =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.102)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = Test)
    )
  )

 Prod =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.101)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = Prod)
    )
  )

9>Make the entry of Test database in soure DB (Prod)
[oracle@Prod admin]$ cat tnsnames.ora
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

 Test =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.102)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = Test)
    )
  )

 10>Check command tnsping on both the server.

 11.Run RMAN Active duplication command

 [oracle@Test admin]$ rman target sys/oracle@Prod auxiliary /

 Recovery Manager: Release 11.2.0.1.0 - Production on Fri Oct 2 11:09:22 2015

 Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

 connected to target database: Prod (DBID=1314861233)
connected to auxiliary database (not started)


RMAN> DUPLICATE TARGET DATABASE  TO 'Test' FROM ACTIVE DATABASE ;

 Starting Duplicate Db at .......
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=19 device type=DISK
.
.
.
.
executing Memory Script

 database dismounted
Oracle instance shut down

 connected to auxiliary database (not started)
Oracle instance started

 Total System Global Area     828608512 bytes

 Fixed Size                     1339684 bytes
Variable Size                490737372 bytes
Database Buffers             331350016 bytes
Redo Buffers                   5181440 bytes

 sql statement: alter system set  db_name =  ''Test'' comment= ''Reset to original value by RMAN'' scope=spfile

 sql statement: alter system reset  db_unique_name scope=spfile

 Oracle instance shut down

 connected to auxiliary database (not started)
Oracle instance started

 Total System Global Area     828608512 bytes

 Fixed Size                     1339684 bytes
Variable Size                490737372 bytes
Database Buffers             331350016 bytes
Redo Buffers                   5181440 bytes
sql statement: CREATE CONTROLFILE REUSE SET DATABASE "Test" RESETLOGS ARCHIVELOG
  MAXLOGFILES     16
  MAXLOGMEMBERS      3
  MAXDATAFILES      100
  MAXINSTANCES     8
  MAXLOGHISTORY      292
 LOGFILE
  GROUP  1 ( '/u02/Test/redologcontrol/redo01.log' ) SIZE 50 M  REUSE,
  GROUP  2 ( '/u02/Test/redologcontrol/redo02.log' ) SIZE 50 M  REUSE,
  GROUP  3 ( '/u02/Test/redologcontrol/redo03.log' ) SIZE 50 M  REUSE
 DATAFILE
  '/u05/Test/oradata/system01.dbf'
 CHARACTER SET WE8MSWIN1252


contents of Memory Script:
{
   set newname for tempfile  1 to
 "/u05/Test/oradata/temp01.dbf";
   switch clone tempfile all;
   catalog clone datafilecopy  "/u05/Test/oradata/sysaux01.dbf",
 "/u05/Test/oradata/undotbs01.dbf",
 "/u05/Test/oradata/users01.dbf";
   switch clone datafile all;
}
executing Memory Script

 executing command: SET NEWNAME

 renamed tempfile 1 to /u05/Test/oradata/temp01.dbf in control file

 cataloged datafile copy
datafile copy file name=/u05/Test/oradata/sysaux01.dbf RECID=1 STAMP=892036279
cataloged datafile copy
datafile copy file name=/u05/Test/oradata/undotbs01.dbf RECID=2 STAMP=892036279
cataloged datafile copy
datafile copy file name=/u05/Test/oradata/users01.dbf RECID=3 STAMP=892036279

 datafile 2 switched to datafile copy
input datafile copy RECID=1 STAMP=892036279 file name=/u05/Test/oradata/sysaux01.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=2 STAMP=892036279 file name=/u05/Test/oradata/undotbs01.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=3 STAMP=892036279 file name=/u05/Test/oradata/users01.dbf

 contents of Memory Script:
{
   Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at .......

 RMAN>

 RMAN>

 RMAN> exit

 12> Check location of Logfile,archive log file,data file,control file and redo log file

 Recovery Manager complete.
[oracle@Test admin]$ . oraenv
ORACLE_SID = [Test] ?
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 is /u01/app/oracle
[oracle@Test admin]$ sqplus
bash: sqplus: command not found
[oracle@Test admin]$ sqlplus

 Enter user-name: /as sysdba

 Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

 SQL> select name,open_mode from V$database;

 NAME      OPEN_MODE
--------- --------------------
Test      READ WRITE

 SQL> select name from V$datafile;

 NAME
--------------------------------------------------------------------------------
/u05/Test/oradata/system01.dbf
/u05/Test/oradata/sysaux01.dbf
/u05/Test/oradata/undotbs01.dbf
/u05/Test/oradata/users01.dbf

 SQL> select name from V$controlfile;

 NAME
--------------------------------------------------------------------------------
/u02/Test/redologcontrol/control01.ctl
/u02/Test/redologcontrol/control02.ctl

 SQL> select member from V$logfile;

 MEMBER
--------------------------------------------------------------------------------
/u02/Test/redologcontrol/redo03.log
/u02/Test/redologcontrol/redo02.log
/u02/Test/redologcontrol/redo01.log

 SQL>    
SQL> select name from V$archived_log;

 NAME
--------------------------------------------------------------------------------
/u03/Test/archivelog/1_1_892036280.dbf

 SQL> show parameter archive

 NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      LOCATION=/u03/Test/archivelog
log_archive_format                   string      %t_%s_%r.dbf

11gR2 Standby Command

Start Apply Process

Start the apply process on standby server.

# Foreground redo apply. Session never returns until cancel. 
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

# Background redo apply. Control is returned to the session once the apply process is started.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

If you need to cancel the apply process, issue the following command.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

If you prefer, you can set a delay between the arrival of the archived redo log and it being applied on the standby server using the following commands.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 30 DISCONNECT FROM SESSION;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT FROM SESSION;

Provided you have configured standby redo logs, you can start real-time apply using the following command.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

Test Log Transport

On the primary server, check the latest archived redo log and force a log switch.

ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';

SELECT sequence#, first_time, next_time
FROM   v$archived_log
ORDER BY sequence#;

ALTER SYSTEM SWITCH LOGFILE;

Check the new archived redo log has arrived at the standby server and been applied.

ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';

SELECT sequence#, first_time, next_time, applied
FROM   v$archived_log
ORDER BY sequence#;

Protection Mode

There are three protection modes for the primary database:

• Maximum Availability: Transactions on the primary do not commit until redo information has been written to the online redo log and the standby redo logs of at least one standby location. If no standby location is available, it acts in the same manner as maximum performance mode until a standby becomes available again.
• Maximum Performance: Transactions on the primary commit as soon as redo information has been written to the online redo log. Transfer of redo information to the standby server is asynchronous, so it does not impact on performance of the primary.
• Maximum Protection: Transactions on the primary do not commit until redo information has been written to the online redo log and the standby redo logs of at least one standby location. If not suitable standby location is available, the primary database shuts down.

By default, for a newly created standby database, the primary database is in maximum performance mode.

SELECT protection_mode FROM v$database;

PROTECTION_MODE
--------------------
MAXIMUM PERFORMANCE

SQL>

The mode can be switched using the following commands. Note the alterations in the redo transport attributes.

-- Maximum Availability.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

-- Maximum Performance.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

-- Maximum Protection.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
ALTER DATABASE OPEN;

Database Switchover

A database can be in one of two mutually exclusive modes (primary or standby). These roles can be altered at runtime without loss of data or resetting of redo logs. This process is known as a Switchover and can be performed using the following statements.

-- Convert primary database to standby
CONNECT / AS SYSDBA
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;

-- Shutdown primary database
SHUTDOWN IMMEDIATE;

-- Mount old primary database as standby database
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

On the original standby database issue the following commands.

-- Convert standby database to primary
CONNECT / AS SYSDBA
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

-- Shutdown standby database
SHUTDOWN IMMEDIATE;

-- Open old standby database as primary
STARTUP;

Once this is complete, test the log transport as before. If everything is working fine, switch the primary database back to the original server by doing another switchover. This is known as a switchback.

Failover

If the primary database is not available the standby database can be activated as a primary database using the following statements.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
ALTER DATABASE ACTIVATE STANDBY DATABASE;

Since the standby database is now the primary database it should be backed up immediately.
The original primary database can now be configured as a standby. If Flashback Database was enabled on the primary database, then this can be done relatively easily (shown here). If not, the whole setup process must be followed, but this time using the original primary server as the standby.

Flashback Database

Although a switchover/switchback is safe for both the primary and standby database, a failover renders the original primary database useless for converting to a standby database. If flashback database is not enabled, the original primary must be scrapped and recreated as a standby database.
An alternative is to enable flashback database on the primary (and the standby if desired) so in the event of a failover, the primary can be flashed back to the time before the failover and quickly converted to a standby database. That process is shown here.

Read-Only Standby and Active Data Guard

Once a standby database is configured, it can be opened in read-only mode to allow query access. This is often used to offload reporting to the standby server, thereby freeing up resources on the primary server. When open in read-only mode, archive log shipping continues, but managed recovery is stopped, so the standby database becomes increasingly out of date until managed recovery is resumed.
To switch the standby database into read-only mode, do the following.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;

To resume managed recovery, do the following.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

In 11g, Oracle introduced the Active Data Guard feature. This allows the standby database to be open in read-only mode, but still apply redo information. This means a standby can be available for querying, yet still be up to date. There are licensing implications for this feature, but the following commands show how active data guard can be enabled.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Since managed recovery continues with active data guard, there is no need to switch back to managed recovery from read-only mode in this case.

Snapshot Standby

Introduced in 11g, snapshot standby allows the standby database to be opened in read-write mode. When switched back into standby mode, all changes made whilst in read-write mode are lost. This is achieved using flashback database, but the standby database does not need to have flashback database explicitly enabled to take advantage of this feature, thought it works just the same if it is.
If you are using RAC, turn off all but one of the RAC instances. Make sure the instance is in MOUNT mode.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

Make sure managed recovery is disabled.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Convert the standby to a snapshot standby. The following example queries the V$DATABASE view to show that flashback database is not enabled prior to the conversion operation.

SELECT flashback_on FROM v$database;

FLASHBACK_ON
------------------
NO

ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
ALTER DATABASE OPEN;
SELECT flashback_on FROM v$database;

FLASHBACK_ON
------------------
RESTORE POINT ONLY

SQL>

You can now do treat the standby like any read-write database.
To convert it back to the physical standby, losing all the changes made since the conversion to snapshot standby, issue the following commands.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
SELECT flashback_on FROM v$database;

FLASHBACK_ON
------------------
NO

SQL>

The standby is once again in managed recovery and archivelog shipping is resumed. Notice that flashback database is still not enabled.

Golden Gate Concept

1. Introduction
===========
Data Replication:-

In simplest term data replication is nothing but storing same data on multiple storage devices.
Replication is the process of copying and maintaining database objects in multiple databases that make
up a distributed database system. Changes applied at one site are captured and stored locally before
being forwarded and applied at each of the remote locations. Replication provides user with fast, local
access to shared data, and protects availability of applications because alternate data access options
exist. Even if one site becomes unavailable, users can continue to query or even update the remaining
locations.
Database replication can be used on many database management systems, usually with a master/slave
relationship between the original and the copies. The master logs the updates, which then ripple
through to the slaves. The slave outputs a message stating that it has received the update successfully,
thus allowing the sending (and potentially re-sending until successfully applied) of subsequent updates.
Multi-master replication, where updates can be submitted to any database node, and then ripple
through to other servers, is often desired, but introduces substantially increased costs and complexity
which may make it impractical in some situations. The most common challenge that exists in
multi-master replication is transactional conflict prevention or resolution. Most synchronous or eager
replication solutions do conflict prevention, while asynchronous solutions have to do conflict resolution.
For instance, if a record is changed on two nodes simultaneously, an eager replication system would
detect the conflict before confirming the commit and abort one of the transactions. A lazy replication
system would allow both transactions to commit and run a conflict resolution during resynchronization.
The resolution of such a conflict may be based on a timestamp of the transaction, on the hierarchy of
the origin nodes or on much more complex logic, which decides consistently on all nodes.
When data is replicated between database servers, so that the information remains consistent
throughout the database system and users cannot tell or even know which server in the DBMS they are using, the system is said to exhibit replication transparency.

Data Replication Techniques

Materialized Views:-

Oracle uses materialized views (also known as snapshots in prior releases) to replicate data to
non-master sites in a replication environment. A materialized view is a replica of a target master
from a single point in time. The master can be either a master table at a master site or a
master materialized view at a materialized view site. Whereas in multi-master replication tables
are continuously updated by other master sites, materialized views are updated from one or
more masters through individual batch updates, known as a refreshes.

Triggers

Oracle lets you define procedures called triggers that run implicitly when an INSERT, UPDATE, or
DELETE statement is issued against the associated table or, in some cases, against a view, or
when database system actions occur. These procedures can be written in PL/SQL or Java and
stored in the database, or they can be written as C callouts.
Triggers are similar to stored procedures. A trigger stored in the database can include SQL and
PL/SQL or Java statements to run as a unit and can invoke stored procedures. However,
procedures and triggers differ in the way that they are invoked. A procedure is explicitly run by a
user, application, or trigger. Triggers are implicitly fired by Oracle when a triggering event
occurs, no matter which user is connected or which application is being used.
Insert, update, delete statements can be used in Triggers to replicate data to another
database(Using old & New qualifiers) after initial loading, Initial loading can be done by
export/import or through data pump.

Data Guard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for
enterprise data. Data Guard provides a comprehensive set of services that create, maintain,
manage, and monitor one or more standby databases to enable production Oracle databases to
survive disasters and data corruptions. Data Guard maintains these standby databases as copies
of the production database. Then, if the production database becomes unavailable because of a
planned or an unplanned outage, Data guard can switch any standby database to the
production role, minimizing the downtime associated with the outage. Data Guard can
be used with traditional backup, restoration, and cluster techniques to provide a high level of
data protection and data availability.
With Data Guard, administrators can optionally improve production database performance by
offloading resource-intensive backup and reporting operations to standby systems.

Oracle Streams

Oracle Streams enables information sharing. Using Oracle Streams, each unit of shared
information is called a message, and you can share these messages in a stream. The stream can
propagate information within a database or from one database to another. The stream routes
specified information to specified destinations. The result is a feature that provides greater
functionality and flexibility than traditional solutions for capturing and managing messages, and
sharing the messages with other databases and applications. Oracle Streams provides the
capabilities needed to build and operate distributed enterprises and applications, data
warehouses, and high availability solutions. You can use all of the capabilities of Oracle
Streams at the same time. If your needs change, then you can implement a new capability of
Oracle Streams without sacrificing existing capabilities.
Using Oracle Streams, you control what information is put into a stream, how the stream flows
or is routed from database to database, what happens to messages in the stream as they flow
into each database, and how the stream terminates. By configuring specific capabilities of
Oracle Streams, you can address specific requirements. Based on your specifications, Oracle
Streams can capture, stage, and manage messages in the database automatically, including, but
not limited to, data manipulation language (DML) changes and data definition language (DDL)
changes. You can also put user-defined messages into a stream, and Oracle Streams can
propagate the information to other databases or applications automatically. When messages
reach a destination, Oracle Streams can consume them based on your specifications

2. Oracle GoldenGate Replication

Golden gate software was initially developed by Cullinet software company which is located at
Massachusetts. In 2009 Oracle acquired Golden Gate software. Oracle Golden Gate can be used as a
replication tool,ETL and even as a DR solution.
GoldenGate enables us to extract and replicate data across a variety of topologies Business Continuity
and High Availability Data migrations and upgrades Decision Support Systems and Data Warehousing
Data integration and consolidation Oracle GoldenGate enables the exchange and manipulation of data
at the transaction level among multiple, heterogeneous platforms across the enterprise. Its modular
architecture gives you the flexibility to extract and replicate selected data records, transactional
changes, and changes to DDL (data definition language2) across a variety of topologies. With this
flexibility, and the filtering, transformation, and custom processing features of Oracle GoldenGate, you can support numerous business requirements

Advantages Of Golden Gate:-

Oracle GoldenGate 11gR2 provides the following features and benefits that enable you to achieve
real-time data integration and continuous availability for mission-critical systems:
Real-time data.

1.  Immediately captures, routes, transforms, and delivers transactional data to other

systems with sub-second latency.

      2. Improves organizational decision-making through enterprise-wide visibility into

accurate, up-to-date information. Heterogeneous support.
      3. Supports heterogeneous databases and platforms to increase IT flexibility.

Heterogeneous support.

1. Supports heterogeneous databases and platforms to increase IT flexibility.
2. Extracts data from existing IT investments and lowers your total cost of ownership while
   unifying data from all enterprise systems.

Reliability

•  Delivers all committed records to the target, even in the event of network outages.

•  Moves data without requiring system interruption or outage windows.

High performance with low impact

•  Moves thousands of transactions per second with negligible impact on source and

target systems. Enables to access critical information in real time without bogging down
production systems.

Transaction integrity

•  Maintains transaction commit boundaries and atomicity, consistency, isolation, and

durability (ACID) properties as transactions are moved between source and target
systems. Ensures data consistency and referential integrity across multiple masters,
back-up systems, and reporting databases.
Integration

•  Integrates with Oracle Data Integrator Enterprise Edition and complements other ETL

solutions. Via Oracle Golden Gate Application Adapters, it allows to capture from, or
deliver to, Java Message Services based messaging solutions such as Oracle WebLogic.

Flexible topology support.

•  Moves data in one-source-to-one-target, one-to-many, many-to-one, many-to-many,cascading, and bidirectional configurations.
  

  Conflict detection and resolution

  •  Enables conflict detection and resolution in multi-master configurations where two
  systems can modify separate instances of the same table.
  Event based infrastructure
  
  •  Triggers immediate actions based on specific database operations captured and stored
  in Trail Files.
  

  Routing and compression

  • Utilizes TCP/IP to send data and eliminate geographical distance constraints. Applies
  additional compression to the data as it is routed.
  

  Data encryption

  •  Securely transmits data for domestic and international applications with variable key
  length encryption.
  

  Deferred apply

  • Applies data immediately or at a deferred time chosen by the user, without losing
  transaction integrity.