Oracle

Replicación
Ing. Erick López Ch. M.R.I.
 What is Replication

• Replication is the process of copying and

maintaining schema objects in multiple
databases that make up a distributed database
system.
• Replication can improve the performance and
protect the availability of applications because
alternate data access options exist.
 Basic Replication

• Data replicas provide read-only access to the

table data that originates from a primary or
“master” site.
• Applications can query data from local data
replicas to avoid network access regardless of
network availability.
• Applications throughout the system must access
data at the primary site when updates are
necessary.
Basic Replication
 Advance Replication

• Extend the capabilities of basic read-only replication by

allowing applications to update table replicas
throughout a replicated database system.
• With advanced replication, data replicas anywhere in
the system can provide both read and update access to a
table’s data.
• Participating Oracle database servers automatically
work to converge the data of all table replicas, and
ensure global transaction consistency and data integrity.
Advance Replication
 Basic Replication Concepts

• Support applications requiring read-only

access to table data originating from a
primary site.
• Uses of Basic Replication.
• Read-Only Table Snapshots.
• Snapshot Refreshes.
 Uses of Basic Replication
• Basic replication
is useful for information
distribution.

• Information Off-Loading

• Information Transport
 Read-Only Table Snapshots

• A read-only table snapshot is a local copy

of table data originating from one or more
remote master tables.
• An application can query the data in a read-
only table snapshot, but cannot insert,
update, or delete rows in the snapshot.
Read-Only Table Snapshots
 Read-Only Table Snapshots

• A Snapshot’s Defining Query The logical data

structure of table snapshots is defined by a query
that references data in one or more remote
master tables. A snapshot's defining query
determines what data the snapshot will contain.
• Should be such that each row in the snapshot
corresponds directly to a row or a part of a row
in a single master table.
 Read-Only Table Snapshots

• A Snapshot’s Defining Query The logical data

structure of table snapshots is defined by a query
that references data in one or more remote
master tables. A snapshot's defining query
determines what data the snapshot will contain.
• Should be such that each row in the snapshot
corresponds directly to a row or a part of a row
in a single master table.
 Read-Only Table Snapshots

• Should not contain a distinct or aggregate

function, a GROUP BY or CONNECT BY
clause, join, restricted types of
subqueries, or a set operation.
• CREATE SNAPSHOT sales.customers AS
SELECT * FROM
[email protected]
 Read-Only Table Snapshots

• CREATE SNAPSHOT sales.orders AS

SELECT * FROM [email protected] o
WHERE EXISTS
( SELECT c_id FROM
[email protected] c
WHERE o.c_id = c.c_id AND zip = 19555);

• SNAP$_snapshotname
 Snapshot Refreshes
• You must decide how and when to refresh each
snapshot to make it a more current.
• Analyze application characteristics and requirements
to determine appropriate snapshot refresh intervals.
• To refresh snapshots, Oracle supports different types
of refreshes, “complete” and
“fast” snapshot refresh groups, as well as “manual”
and “automatic” refreshes.
 Complete and Fast Refreshes

• Complete Refreshes
• The server that manages the snapshot executes
the snapshot's defining query.
• The result set of the query replaces the existing
snapshot data to refresh the snapshot.
• Oracle can perform a complete refresh for any
snapshot.
 Complete and Fast Refreshes
• Fast Refreshes
• The server that manages the snapshot first identifies the
changes that occurred in the master since the most recent
refresh of the snapshot and then applies them to the
snapshot.
• Fast refreshes are more efficient than complete refreshes
when there are few changes to the master because
participating servers and networks replicate less data.
• Fast refreshes are available for snapshots only when the
master table has a snapshot log.
 Complete and Fast Refreshes

• Complete Refreshes
• The server that manages the snapshot executes
the snapshot's defining query.
• The result set of the query replaces the existing
snapshot data to refresh the snapshot.
• Oracle can perform a complete refresh for any
snapshot.
 Materialized View
• A materialized view is a database object that contains
the results of a query.
• The FROM clause of the query can name tables, views,
and other materialized views.
• Collectively these objects are called master tables (a
replication term) or detail tables (a data warehousing
term).
• A materialized view, or snapshot as they were
previously known, is a table segment whose contents
are periodically refreshed based on a query, either
against a local or remote table.
 Prerequisites

• CREATE MATERIALIZED VIEW

• CREATE ANY MATERIALIZED VIEW

• To create a refresh-on-commit materialized view (ON

COMMIT REFRESH clause), in addition to the preceding
privileges, you must have the ON COMMIT REFRESH object
privilege on any master tables that you do not own or you must
have the ON COMMIT REFRESH system privilege.
Basic Syntax
 Basic Syntax
• The BUILD clause options are:
• IMMEDIATE : The materialized view is populated immediately.
• DEFERRED : The materialized view is populated on the first requested
refresh.
• Refresh types
• FAST : A fast refresh is attempted. If materialized view logs are not
present against the source tables in advance, the creation fails.
• COMPLETE : The table segment supporting the materialized view is
truncated and repopulated completely using the associated query.
• FORCE : A fast refresh is attempted. If one is not possible a complete
refresh is performed.
 Basic Syntax

• ON COMMIT : The refresh is triggered by a committed data

change in one of the dependent tables.
• ON DEMAND : The refresh is initiated by a manual request or
a scheduled task.
 Advanced Replication Concepts

• Disconnected Environments
• Advanced replication is useful for the
deployment of transaction processing
applications that operate using disconnected
components.
• Failover Site
• Protect the availability of a mission critical
database.
 Advanced Replication Concepts

• Distributing Application Loads

• Transaction processing applications that require
multiple points of access to database
information
• Information Transport
• Data warehouse or data mart.
 Advanced Replication
Configurations

• Multimaster Replication
• Allows multiple sites, acting as equal peers, to
manage groups of replicated database objects.
• Applications can update any replicated table at
any site in a multimaster configuration.
Advanced Replication Configurations
 Advanced Replication Configurations

• Snapshot Sites and Updatable Snapshots

• Master sites in an advanced replication system
can consolidate information that applications
update at remote snapshot sites.
• Facility allows applications to insert, update,
and delete table rows through updatable
snapshots.
Advanced Replication Configurations
 Advanced Replication Configurations

• Updatable snapshots have the following properties:

• Updatable snapshots are always simple, fast-refreshable
table snapshots.
• Oracle propagates the changes made through an updatable
snapshot to the snapshot’s remote master table.
• If necessary, the updates then cascade to all
other master sites.
• Oracle refreshes an updatable snapshot as part of a refresh
group identical to read-only snapshots.
 Advanced Replication Configurations

• Hybrid Configurations
• Multimaster replication and updatable
snapshots can be combined in hybrid or
“mixed” configurations to meet different
application requirements.
• Can have any number of master sites and
multiple snapshot sites for each master.
Advanced Replication Configurations
 Advanced Replication Configurations
• Differences between updatable snapshots and
replicated masters:
• Replicated masters must contain data for the full table
being replicated, whereas snapshots can replicate
subsets of master table data.
• Multimaster replication allows you to replicate
changes for each transaction as the changes occur.
• If conflicts occur from changes made to multiple
copies of the same data, master sites detect and resolve
the conflicts.
 Replication Conflicts
• Uniqueness Conflicts
• A uniqueness conflict occurs when the replication of a
row attempts to violate entity integrity (a PRIMARY
KEY or UNIQUE constraint).
• Update Conflicts
• Occurs when the replication of an update to a row
conflicts with another update to the same row. Update
conflicts occur when two different transactions
originating from different sites update the same row at
nearly the same time.
 Replication Conflicts
• Delete Conflicts
• Occurs when two transactions originate from different
sites, with one transaction deleting a row that the other
transaction updates or deletes.
 Using Basic Replication
1. Design the basic replication environment. Decide
which master tables you want to replicate using
read-only table snapshots, and which databases
require such snapshots.
2. At each snapshot site, create the schemas and
database links necessary to support snapshots.
3. At the master site, create the snapshot logs
necessary to support fast refreshes of all
snapshots.
 Using Basic Replication

4. Create the snapshots at each snapshot site.

5. At each snapshot site, create the refresh groups

that the snapshots will use to refresh, and assign
each snapshot to a refresh group.

6. Grant privileges necessary for application users

to access snapshots.
 Step 2:

Create Snapshot Site Schemas and

Database Links

• CONNECT system/manager@dbs2;
• CREATE USER scott IDENTIFIED BY tiger QUOTA
UNLIMITED ON data;
• GRANT CONNECT TO scott;
• CONNECT scott/tiger@dbs2;
• CREATE DATABASE LINK dbs1 CONNECT TO scott
IDENTIFIED BY tiger USING ‘dbs1’;
 Step 3:

Create Necessary Master Site Snapshot Logs

• CONNECT system/manager@dbs1;
• CREATE SNAPSHOT LOG ON scott.emp;
• CREATE SNAPSHOT LOG ON scott.dept;
 Step 4:

Create Snapshots

• CONNECT system/manager@dbs2;
• CREATE SNAPSHOT scott.emp AS
SELECT * FROM [email protected];
• CREATE SNAPSHOT scott.dept AS
SELECT * FROM [email protected];
 Step 5:
Create Snapshot Site Refresh Groups

• CONNECT system/manager@dbs2;
• DBMS_REFRESH.MAKE(
name => ’scott.refgrp1’,
list => ’scott.dept,scott.emp’,
next_date => SYSDATE,
interval => ’SYSDATE+1/24’); (1/1440)
• COMMIT;
 Step 6:
Grant Access to Snapshots

• GRANT SELECT ON scott.emp TO ... ;

 With Materialized View – Step 1
• GRANT CREATE MATERIALIZED VIEW TO scott; GRANT
CREATE DATABASE LINK TO scott;

• CONNECT scott/tiger@db2
• CREATE DATABASE LINK DB1.WORLD CONNECT TO scott
IDENTIFIED BY tiger USING 'DB1';
• CREATE MATERIALIZED VIEW emp_mv
BUILD IMMEDIATE
REFRESH FORCE
ON DEMAND
AS SELECT * FROM emp@db1
 Gather stats - Step 2

Gather stats after building the materialized view

BEGIN
DBMS_STATS.gather_table_stats(
ownname => 'SCOTT',
tabname => 'EMP_MV');
END;
/
 Create Materialized View Logs – Step 3

• CONNECT scott/tiger@db1

CREATE MATERIALIZED VIEW LOG ON scott.emp

TABLESPACE users
WITH PRIMARY KEY
INCLUDING NEW VALUES;
Refresh Materialized Views Manual
 Refresh Materialized Views Manual

• A materialized view can be manually refreshed using the

DBMS_MVIEW package.

• EXEC DBMS_MVIEW.refresh('EMP_MV');
 Cleaning Up
CONNECT scott/tiger@db2
DROP MATERIALIZED VIEW emp_mv;
DROP DATABASE LINK DB1;
BEGIN
DBMS_REFRESH.destroy(
name => 'SCOTT.MINUTE_REFRESH');
END;
/
CONNECT scott/tiger@db1
DROP MATERIALIZED VIEW LOG ON scott.emp;