Oracle 11g Release 2 (11.2) Advanced Replication Guide

oracle

需积分: 5 130 浏览量更新于2024-06-25 收藏 2.9MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Oracle Database Advanced Replication 11g Release 2 (11.2)-220" Oracle数据库高级复制是Oracle数据库系统的一个关键特性，它在11g Release 2 (11.2)版本中得到了进一步增强。这个功能主要用于解决大型企业环境中数据的分布式管理、高可用性以及灾难恢复需求。Oracle Advanced Replication提供了多种复制类型，包括单向复制、双向复制和多路复制，以及同步和异步模式，以适应不同业务场景。 1. **物质化视图（Materialized Views）**: 物质化视图是复制的一种形式，它允许在远程数据库上创建本地数据的快照。这些视图可以定期刷新，确保远程站点的数据与主站点保持一致。这在数据分析和报表生成中非常有用，因为用户可以在本地快速访问汇总或处理过的数据，而无需直接查询主数据库。 2. **全局序列号（Global Sequence Numbers, GSNs）**: GSNs是用于追踪事务顺序的关键组件，确保在复制过程中事务的一致性和完整性。每个事务都有一个唯一的GSN，这样就可以确保即使在分布式环境中，事务的执行顺序也能正确无误。 3. **发布/订阅（Publish/Subscribe）模型**: 在这种模型中，一个数据库作为发布者（Publisher），将更改发布给一个或多个订阅者（Subscriber）。发布者可以指定哪些表或视图的数据需要被复制，而订阅者则接收并应用这些更改。 4. **同步与异步复制**: 同步复制意味着更改在主数据库上提交后立即在副本上应用，确保数据一致性但可能影响性能。异步复制则允许在网络条件不佳或性能要求不高的情况下，将更改批量传输到副本，以提高系统的总体吞吐量。 5. **冲突检测与解决**: Oracle Advanced Replication提供了一套机制来检测和解决复制过程中可能出现的冲突。这可能涉及到时间戳比较、用户定义的冲突解决策略，甚至回滚某些事务以保持数据一致性。 6. **数据库链接（Database Links）**: 数据库链接是连接不同数据库实例的通道，它们在复制中扮演着重要角色，允许在不同的数据库之间进行查询和事务处理。 7. **闪回复制（Flashback Replication）**: 这种特性允许在出现错误或需要恢复到某个历史状态时，轻松地将复制的数据库“闪回”到过去的某个点。 8. **故障转移和容灾**: 高级复制为实现高可用性和灾难恢复提供了基础。在主数据库发生故障时，可以无缝切换到复制数据库，确保业务连续性。 9. **分区复制**: 对于大型表，Oracle支持分区级别的复制，这意味着只复制表的特定部分，降低了网络带宽的需求，并提高了复制效率。 10. **安全性与权限管理**: Oracle数据库内置的安全特性也适用于高级复制，确保只有授权用户可以访问和修改复制的数据。 Oracle Database Advanced Replication 11g Release 2 提供了强大且灵活的工具，帮助企业管理和保护分布式数据库环境中的数据，同时提升了系统的性能和可用性。通过深入理解和有效利用这些特性，IT专业人员可以构建出能够满足复杂业务需求的数据库解决方案。

资源详情

资源推荐

Types of Replication Environments

1-6 Oracle Database Advanced Replication

A materialized view can be read-only, updatable, or writeable, and these types of

materialized views provide benefits in addition to those listed previously.

Overview of Read-Only Materialized Views

In a basic configuration, materialized views can provide read-only access to the table

data that originates from a master site or master materialized view site. Applications

can query data from read-only materialized views to avoid network access to the

master site, regardless of network availability. However, applications throughout the

system must access data at the master site to perform data manipulation language

changes (DML). Figure 1–2 illustrates basic, read-only replication. The master tables

and master materialized views of read-only materialized views do not need to belong

to a replication group.

Read-only materialized views provide the following benefits:

■ Eliminate the possibility of conflicts because they cannot be updated.

■ Support complex materialized views. Examples of complex materialized views are

materialized views that contain set operations or a

CONNECT

clause.

Figure 1–2 Read-Only Materialized View Replication

Overview of Updatable Materialized Views

In a more advanced configuration, you can create an updatable materialized view

that allows users to insert, update, and delete rows of the target master table or master

materialized view by performing these operations on the materialized view. An

updatable materialized view can also contain a subset of the data in the target master.

Figure 1–3 illustrates a replication environment using updatable materialized views.

Updatable materialized views are based on tables or other materialized views that

have been set up to support replication. In fact, updatable materialized views must be

See Also: "Available Materialized Views" on page 3-5 for more

information about complex materialized views

Replicate table data

Network

Refresh

Materialized View

(read-only)

Master

database

Master Table

(updatable)

Client applications

Remote update

Local

query

Materialized

View

database

Types of Replication Environments

Introduction to Advanced Replication 1-7

part of a materialized view group that is based on another replication group. For

changes made to an updatable materialized view to be pushed back to the master

during refresh, the updatable materialized view must belong to a materialized view

group.

Figure 1–3 Updatable Materialized View Replication

Updatable materialized views have the following properties.

■ They are always based on a single table, although multiple tables can be

referenced in a subquery.

■ They can be incrementally (or fast) refreshed.

■ Oracle propagates the changes made to an updatable materialized view to the

materialized view's remote master table or master materialized view. The updates

to the master then cascade to all other replication sites.

Updatable materialized views provide the following benefits:

■ Allow users to query and update a local replicated data set even when

disconnected from the master site or master materialized view site.

■ Require fewer resources than multimaster replication, while still supporting data

updates. Materialized views can reduce the amount of stress placed on network

resources because materialized views can be refreshed on demand, while

multimaster replication propagates changes at regular intervals. In addition,

because materialized views can reside in a database that contains far less data, the

disk space and memory requirements for materialized view clients can be less

than the requirements for an Oracle server containing master sites.

Overview of Writeable Materialized Views

You can create a materialized view using the

FOR

UPDATE

clause during creation but

then never add the materialized view to a materialized view group. In this case, users

can perform data manipulation language (DML) changes on the materialized view,

Replicate table data

Network

Refresh

Materialized

View

database

Materialized View

(updatable)

Master

database

Master Table

(updatable)

Client applications

Remote update

Local

query

Local

update

Types of Replication Environments

1-8 Oracle Database Advanced Replication

but these changes cannot be pushed back to the master and are lost if the materialized

view refreshes. Such materialized views are called writeable materialized views.

Overview of Row and Column Subsetting with Materialized Views

Both row and column subsetting enable you to create materialized views that contain

a partial copy of the data at a master table or master materialized view. Such

materialized views can be helpful for regional offices or sales forces that do not require

the complete data set.

Row subsetting enables you to include only the rows that are needed from the masters

in the materialized views by using a

WHERE

clause. Column subsetting enables you to

include only the columns that are needed from the masters in the materialized views.

You do this by specifying particular columns in the

SELECT

statement during

materialized view creation.

Materialized View Refresh

To ensure that a materialized view is consistent with its master table or master

materialized view, you must refresh the materialized view periodically. Oracle

provides the following three methods to refresh materialized views:

■ Fast refresh uses materialized view logs to update only the rows that have

changed since the last refresh.

■ Complete refresh updates the entire materialized view.

■ Force refresh performs a fast refresh when possible. When a fast refresh is not

possible, force refresh performs a complete refresh.

Refresh Groups

When it is important for materialized views to be transactionally consistent with each

other, you can organize them into refresh groups. By refreshing the refresh group, you

can ensure that the data in all of the materialized views in the refresh group

correspond to the same transactionally consistent point in time. Both read-only and

updatable materialized views can be included in a refresh group. A materialized view

in a refresh group still can be refreshed individually, but doing so nullifies the benefits

of the refresh group because refreshing the materialized view individually does not

refresh the other materialized views in the refresh group.

Materialized View Log

A materialized view log is a table at the materialized view's master site or master

materialized view site that records all of the DML changes to the master table or

master materialized view. A materialized view log is associated with a single master

table or master materialized view, and each of those has only one materialized view

Note: Column subsetting of updatable materialized views is

supported only with deployment templates and the Advanced

Replication interface in Oracle Enterprise Manager. This restriction

does not apply to column subsetting of read-only materialized

views.

See Also:

■ "Data Subsetting with Materialized Views" on page 3-12

■ "Column Subsetting with Deployment Templates" on page 4-15

Types of Replication Environments

Introduction to Advanced Replication 1-9

log, regardless of how many materialized views refresh from the master. A fast refresh

of a materialized view is possible only if the materialized view's master has a

materialized view log. When a materialized view is fast refreshed, entries in the

materialized view's associated materialized view log that have appeared since the

materialized view was last refreshed are applied to the materialized view.

Deployment Templates

Deployment templates simplify the task of deploying and maintaining many remote

materialized view sites. Using deployment templates, you can define a collection of

materialized view definitions at a master site, and you can use parameters in the

definitions so that the materialized views can be customized for individual users or

types of users.

For example, you might create one template for the sales force and another template

for field service representatives. In this case, a parameter value might be the sales

territory or the customer support level. When a remote user connects to a master site,

the user can query a list of available templates. When the user instantiates a template,

the materialized views are created and populated at the remote site. The parameter

values can either be supplied by the remote user or taken from a table maintained at

the master site.

Online and Offline Instantiation When a user instantiates a template at a materialized view

site, the object DDL (for example,

CREATE

MATERIALIZED

VIEW

CREATE

TABLE

statements) is executed to create the schema objects at the materialized view site, and

the objects are populated with the appropriate data. Users can instantiate templates

while connected to the master site over a network (online instantiation), or while

disconnected from the master site (offline instantiation).

Offline instantiation is often used to decrease server loads during peak usage periods

and to reduce remote connection times. To instantiate a template offline, you package

the template and required data on some type of storage media, such as tape, CD-ROM,

and so on. Then, instead of pulling the data from the master site, users pull the data

from the storage media containing the template and data.

Multimaster and Materialized View Hybrid Configurations

Multimaster replication and materialized views can be combined in hybrid or "mixed"

configurations to meet different application requirements. Hybrid configurations can

have any number of master sites and multiple materialized view sites for each master.

For example, as shown in Figure 1–4, multimaster (or n-way) replication between two

masters can support full-table replication between the databases that support two

geographic regions. Materialized views can be defined on the masters to replicate full

tables or table subsets to sites within each region.

Administration Tools for a Replication Environment

1-10 Oracle Database Advanced Replication

Figure 1–4 Hybrid Configuration

Key differences between materialized views and replicated master tables include the

following:

■ Replicated master tables must contain data for the full table being replicated,

whereas materialized views can replicate subsets of master table data.

■ Multimaster replication enables you to replicate changes for each transaction as

the changes occur. Materialized view refreshes are set oriented, propagating

changes from multiple transactions in a more efficient, batch-oriented operation,

but at less frequent intervals.

■ If conflicts occur because of changes made to multiple copies of the same data,

then detection and resolution of conflicts always occurs at a master site or a master

materialized view site.

Scheduled Links

Both master sites and materialized view sites use scheduled links to propagate data

changes to other sites. A scheduled link is a database link with a user-defined schedule

to push deferred transactions. A scheduled link determines how a master site

propagates its deferred transaction queue to another master site, or how a materialized

view site propagates its deferred transaction queue to its master site. When you create

a scheduled link, Oracle creates a job in the local job queue to push the deferred

transaction queue to another site in the system.

Administration Tools for a Replication Environment

Several tools are available for configuring, administering, and monitoring your

replication environment. The Advanced Replication interface in Oracle Enterprise

Manager provides a powerful graphical user interface (GUI) to help you manage your

environment, while the replication management application programming interface

(API) provides you with a familiar API to build customized scripts for replication

Materialized

View

Site

Replication

Group

Materialized

View

Site

Replication

Group

Materialized

View

Site

Master

Site

Replication

Group

Master

Site

Replication

Group

Replication

Group

or.example.com pa.example.com

sf.example.com ph.example.com

kc.example.com

剩余219页未读，继续阅读

weixin_40191861_zj

粉丝: 69
资源: 1万+

会员权益专享

Oracle 11g Release 2 (11.2) Advanced Replication Guide

Oracle Database Advanced Replication Management API Reference 11

OracleDatabaseAdvancedReplication.pdf 英文原版

利用Oracle的Advanced Replication实现数据库跨平台实时数据迁移

ora-20783: oracle goldengate ddl replication setup

kafka-topics.sh --create --topic kafka_direct0 --partitions 3--replication-factor 1 --zookeeper hadoop01:2181,hadoop02:2181,hadoop03:2181 Missing required argument "[replication-factor]"这个报错如何解决？

kafka-topics.sh --create --zookeeper niit01:2181 --topic test --replication-factor 1 --partitions

bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test --config segment.bytes=1073741824

怎么在K8S中搭建MySQL主从

报错了 Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).

/opt/module/kafka/bin/kafka-topics.sh --zookeeper hadoop102:2181 --topic calllog --create --replication-factor 1 --partitions 3

如何通过replicationcontroller来设置pod的副本数

bin/kafka-topics.sh --create --zookeeper 10.0.0.151:9192/kafka_vpc_lf --replication-factor 1 --partitions 1 --topic topic_30

Microsoft SQL Server Replication

mysql 配置主从复制如何设置参数 "start-position" 或 "start-datetime"

kubectl scale --replicas=2 rc/nginx-controller replicationcontroller/nginx-controller scaled哪里出错了

gerrit replication命令

AI提示词prompt系列：因果溯源大师

Airdoc2023版基于视网膜人工智能评估的四百万体检人群健康蓝皮书-爱康集团鹰瞳(1).pdf

会员权益专享

最新资源