Enable
GoldenGate
database archiving mode
The source and target Oracle databases
must be configured to meet Oracle GoldenGate database
requirements. These tasks are normally performed by the
Database Administrators as it requires clean database
shutdown, mount and then open the database for users. The
tasks are mandatory for the source database to enable Oracle
GoldenGate change data capture. For bidirectional Oracle
GoldenGate setup, the tasks are performed on the target
database too.
The database tasks to be performed are
listed below. For the majority of the customers, these
pre-requisites may have been already enabled.
Although Oracle GoldenGate does not
complain when the source database is not operating on
archive log mode, however; it's highly important operating
any production database on archive log mode, which enables
Oracle GoldenGate to perform change data capture using the
archive log files dynamically, in case the online log files
are not available temporary. The following SQL*Plus
administrative commands enable database archiving.
Let's start by determining the current
database operating mode. Connect as SYSDBA user and query
v$database
dictionary view.
S1E2> CONN / as sysdba
Connected.
S1E2> SELECT log_mode
2
FROM
v$database;
LOG_MODE
------------
NOARCHIVELOG
When the source database is operating on
NOARCHIVELOG, as indicated above, enable the database
archive log mode by executing the steps below.
S1E2> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area
535662592 bytes
Fixed Size
1375792 bytes
Variable Size
352322000 bytes
Database Buffers
176160768 bytes
Redo Buffers
5804032 bytes
Database mounted.
S1E2> ALTER DATABASE ARCHIVELOG;
Database altered.
Open the database and verify the source
Database is operating on archive log mode. Oracle GoldenGate
may uses the archive log files in the event the online files
are not available or a log switch has occurs while Oracle
GoldenGate extract processes was not running for a period of
time.
S1E2> ALTER DATABASE OPEN;
Database altered.
S1E2> SELECT log_mode
2
FROM
v$database;
LOG_MODE
------------
ARCHIVELOG
The default location of the archive log
files generated by the archive processes is the database
fast recovery area (FRA). The database FRA area is managed
by two database parameters, as illustrated below.
S1E2>show parameters db_recovery
NAME
TYPE
VALUE
--------------------------
--------
-----------------------------------
db_recovery_file_dest
string /u01/app/oracle/flash_recovery_area
db_recovery_file_dest_size
big integer 6G
In event of disk space shortages, the
database instance start purging files from the FRA, which is
based on the current Recovery Manager (RMAN) retention
policy. To view the current retention policy, start RMAN,
connect to the target database and issue the SHOW command.
$ rman
Recovery Manager: Release 11.2.0.3.0 -
Production on Thu Sep 26 10:38:46 2015
Copyright (c) 1982, 2015, Oracle
and/or its affiliates.
All rights reserved.
RMAN> connect target
connected to target database: S1E2
(DBID=4262461972)
RMAN> show retention policy;
using target database control file
instead of recovery catalog
RMAN configuration parameters for
database with db_unique_name S1E2 are:
CONFIGURE RETENTION POLICY TO
REDUNDANCY 1; # default
When the database is operating on archive
log mode, the FRA may run out of disk space causing the
database to stale and ultimately return an error, which
requires manually deleting the archive log files, then
synchronizing the physical records existence with the
database control file and recovery manager catalog metadata,
if in use. After deleting the files, run the command:
RMAN> crosscheck archivelog all;
|
|
 |
|
Oracle GoldenGate 12c
The above is an excerpt from the upcoming
12c book
Oracle GoldenGate 12c: A Hands-on Guide to Data
Replication & Integration using Oracle & SQL Server.
|
|
|
| |
|
Burleson is the American Team
Note:
This Oracle
documentation was created as a support and Oracle training reference for use by our
DBA performance tuning consulting professionals.
Feel free to ask questions on our
Oracle forum.
Verify
experience!
Anyone
considering using the services of an Oracle support expert should
independently investigate their credentials and experience, and not rely on
advertisements and self-proclaimed expertise. All legitimate Oracle experts
publish
their Oracle
qualifications.
Errata?
Oracle technology is changing and we
strive to update our BC Oracle support information. If you find an error
or have a suggestion for improving our content, we would appreciate your
feedback. Just
e-mail:
 and include the URL for the page.
Copyright © 1996 - 2020
All rights reserved by
Burleson
Oracle ®
is the registered trademark of Oracle Corporation.
|
|
