RMAN catalog full resync fails with ORA-02290

Posted in Oracle RMAN with tags , , on September 13, 2011 by John Jeffries

Problem

Having registered an Oracle 11.2.0.2 database successfully with an Oracle RMAN 11.1.0.7 recovery catalog, I initiated a backup.
RMAN subsequently performed an implicit resync of the recovery catalog with the target database’s controlfile which failed to the following error(s).

***********************************************************************
starting full resync of recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03008: error while performing automatic resync of recovery catalog
ORA-02290: check constraint (RMAN11G.RT_C_STATUS) violated
************************************************************************

Solution

The solution is to upgrade the RMAN recovery catalog schema to 11.2.0.2. This is required by the RMAN client and can be achieved by executing the following command at the RMAN prompt, once connected to the catalog database:

$ rman catalog rman11g/rman11g@rmancat
Recovery Manager: Release 11.2.0.2.0 - Production on Wed Sep 14 07:45:56 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to recovery catalog database

RMAN> upgrade catalog;

recovery catalog owner is RMAN11G

enter UPGRADE CATALOG command again to confirm catalog upgrade

RMAN> upgrade catalog;

recovery catalog upgraded to version 11.02.00.02
DBMS_RCVMAN package upgraded to version 11.02.00.02
DBMS_RCVCAT package upgraded to version 11.02.00.02

N.B.
You will notice, to confirm your action, Oracle prompts for the “upgrade catalog” command to be entered twice before upgrading the schema.

Oracle Doc ID: 1331611.1 suggests that the issue is caused by patch for Bug 9044053. I do not have patch 9044053 applied to the target database and the platform is Linux (OEL) not Windows.

Packt Enterprise has just published the first ever GoldenGate book

Posted in GoldenGate on February 23, 2011 by John Jeffries

For more information visit:

https://www.packtpub.com/article/packt-publishes-first-goldengate-book

The TCP Time-out Issue affecting Streams Downstream Capture

Posted in Oracle Streams with tags , , , on May 19, 2010 by John Jeffries

Problem

In a 2 node RAC environment where Streams downstream capture is running between 2 clusters, it is possible for the log shipping to hang when the public network is disconnected on one of the target nodes. The Virtual IP (VIP) moves to the surviving node, but connectivity does not immediately failover as expected. This is largely due to a TCP time-out issue.

When the Network Interface Card (NIC) dies or the network cable is unplugged on the server making the TCP/IP network unavailable, the client connection ultimately times-out to TNS-12170, TNS-12560, TNS-12535 and TNS-00505 as seen in the source database alert log below:

**************************************************************

Fatal NI connect error 12170.

  VERSION INFORMATION:
     TNS for Linux: Version 11.1.0.7.0 - Production
     Unix Domain Socket IPC NT Protocol Adaptor for Linux: Version 11.1.0.7.0 - Production
     TCP/IP NT Protocol Adapter for Linux: Version 11.1.0.7.0 - Production
  Time: 14-MAY-2010 11:54:32
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535

TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505

TNS-00505: Operation timed out
    nt secondary err code: 110
    nt OS err code: 0
 

The following process explains the individual steps the client goes through to try and resolve the connection error:

1. The Client talks to a host service on a host that does not exist, ie. there is no system operational on the IP address the client is trying to connect to. Therefore there is no possibility that something will even respond to that IP address.

2. As per the connection model, the client initiates a TCP/IP three-way handshake, but there is no response.

3. The client waits a specified amount of time (OS configurable) like 200ms.

4. It sends the SYN packet again, but still gets no response. So it waits 400ms and tries again. Still no response, so it waits 800ms and tries again. Again, no response, so it waits 1600ms and tries again. After another wait of 3200ms, the client gives up.

5. The client keeps retrying every 3200ms until a predefined time-out is hit and it stops.

On Linux, the kernel parameter that governs tcp time-out is net.ipv4.tcp_retries2 and defaults to 30 minutes (1800 seconds).

In Oracle 10g and above, SQLNet now has the capability of timing out within a desired period, instead of waiting for the TCP timeout to occur.

The following settings can be used in the sqlnet.ora file on the client or server:

sqlnet.inbound_connect_timeout (server)
sqlnet.send_timeout (client and/or server)
sqlnet.recv_timeout (client and/or server)

However, these are not for connect-time failover, but rather for TAF operations.
In other words, the SQLNet settings will not correct any shortcomings at the TCP layer.
Oracle is heavily reliant on the TCP layer. The timeout values will only work when the TCP/IP address is alive and available.

Solution

The following Linux kernel parameters address the TCP time-out issue:

/proc/sys/net/ipv4/tcp_keepalive_time

• How often TCP sends out keepalive messages when keepalive is enabled. Default: 7200 secs (2 hours)

/proc/sys/net/ipv4/tcp_retries2

• How may times to retry before killing alive TCP connection. Default: 15 corresponds to 13-30min

/proc/sys/net/ipv4/tcp_syn_retries

• Number of SYN packets the kernel will send before giving up on the new connection. Default: 5

Follow the steps below to dynamically reconfigure the Linux kernel parameters from their default settings:

1. As root user on the client node, add the following lines to /etc/sysctl.conf

net.ipv4.tcp_keepalive_time=3000
net.ipv4.tcp_retries2=5
net.ipv4.tcp_syn_retries=1

2. Dynamically update the Linux kernel with the new settings

sysctl -p

All parameters will be displayed following the reload of /etc/sysctl.conf

Conclusion

So, the above solution fixes the TCP timeout issue. However, the LNS process will not resume log shipping to the surviving node, nor will Streams continue to mine and apply the logs, until a logfile switch occurs at the source database.

Should the load (tps) be low at the source, it may be prudent to introduce the archive_lag_target parameter on the source database to force a logfile switch every n seconds.

Furthermore, when the public i/f is disconnected from a node, the DB listener stops. This is expected behaviour because the VIP is relocated to other node. However, it can take up to 10 minutes for CRS to automatically start the listener after the network is restored. This is the default setting for the racgimon process.

Defining Multiple Replicat Processes to Increase GoldenGate Performance

Posted in GoldenGate with tags , on April 9, 2010 by John Jeffries

Oracle states that GoldenGate can achieve near real-time data replication. However, out of the box, GoldenGate may not meet your performance requirements.

The GoldenGate documentation states “The most basic thing you can do to improve GoldenGate’s performance is to divide a large number of tables among parallel processes and trails. For example, you can divide the load by schema”.

But what if you have some large tables with a high data change rate within a source schema and you cannot logically separate them from the remaining tables due to referential constraints? GoldenGate does provide a solution to this problem by “splitting” the data and not the schema via the @RANGE function.

The Replicat process is typically the source of performance bottlenecks because, in its normal mode of operation, it is a single-threaded process that applies operations one at a time by using regular SQL. Therefore, to leverage parallel operation, the more Replicats the better (dependant on the number of CPUs on the target system).

Read the complete article at http://www.oracle11ggotchas.com/articles/Defining%20Multiple%20Replicats%20to%20Increase%20GoldenGate%20Performance.pdf

Recreating Physical Standby Database after recovery of Primary Database

Posted in Oracle Data Guard with tags , , , , , on February 24, 2010 by John Jeffries

In an Oracle 11g Data Guard environment, the following steps will recreate the Physical Standby Database from the Primary Database. Both databases are 2 node RAC using ASM shared storage.

A number of reasons may influence the decision to recreate the Standby database, these include:

  • Point in time Recovery (PITR) of Primary database
  • The standby (DR) site had to be rebuilt due to hardware failure
  • The network link was down for a long period, resulting in a huge backlog of archive logs waiting to be shipped and applied on the Standby database.

 

All the above have one thing in common; data synchronisation required between Primary and Standby. In terms of restoration time, it may be advantageous to recreate the Standby Database from the Primary. This is easily accomplished using RMAN’s Oracle 11g new feature;

“duplicate target database for standby from active database”…

Read the full article by clicking on the following link:

http://www.oracle11ggotchas.com/articles/Recreate%20Physical%20Standby%20Database%20after%20recovery%20of%20Primary%20Database.pdf

Making Oracle Streams Fly

Posted in Oracle Streams with tags , on February 21, 2010 by John Jeffries

Not wishing to clog my Blog with 8 pages of text, please view the article by following the link below:

http://www.oracle11ggotchas.com/articles/Making%20Oracle%20Streams%20Fly.pdf

Streams Fails after Applying 11.1.0.7.1 PSU

Posted in Oracle Streams with tags , , , on January 27, 2010 by John Jeffries

I recently applied Patch 8833297 – 11.1.0.7.1 Patch Set Update to a 2 node RAC database running on Oracle Enterprise Linux (OEL 5.2) x86-64. Despite following the post installation procedures documented in the README.txt that recompiles invalid objects, I could not start the Streams downstream capture process on either instance in the cluster.

Streams initially failed with the following error seen in the database instance alert log:

ORA-01355: logminer tablespace change in progress

So I looked up the error on the command line:

$ oerr ora 1355
01355, 00000, "logminer tablespace change in progress"
// *Cause:  The tables used by logminer are in the process of being
//          moved to another tablespace.
// *Action: Wait until the move is complete and try again.

Having waited a few minutes I reattempted to start Streams which then failed to the following errors:

ORA-00604: error occurred at recursive SQL level 1
ORA-04045: errors during recompilation/revalidation of XDB.XDB_PI_TRIG
ORA-01031: insufficient privileges

Fortunately, this error is easy to fix. The answer is in the last error seen (ORA-01031), the streams_admin user has only execute privilege on object XDB.XDB_PI_TRIG.

Solution

The solution therefore is to recompile the Trigger as SYSDBA:

sqlplus / as sysdba
SQL> alter trigger XDB.XDB_PI_TRIG compile;
Trigger altered.

Tip

A useful SYS table exists that allows the DBA to query the database patching status, including post-installation steps:

SELECT * FROM registry$history;
ACTION_TIME     ACTION  NAMESPACE  VERSION        ID COMMENTS            
--------------- ------- ---------- --------- ------- ------------------  
26-JAN-10 12.33 APPLY   SERVER     11.1.0.7        1 PSU 11.1.0.7.1     
26-JAN-10 12.43 CPU                          6452863 view recompilation
 

Re-instantiating Schema Replication following Database Incomplete Recovery

Posted in Oracle Streams with tags , , , on January 8, 2010 by John Jeffries

After an incomplete recovery of the source database, where the database was opened using “ALTER DATABASE OPEN RESETLOGS”, your Oracle Streams downstream capture process will fail to the following errors, seen in the target database instance alert log:

ORA-01346: LogMiner processed redo beyond specified reset log scn

ORA-01280: Fatal LogMiner Error.

The following procedure can be used to reinstate the downstream capture process:

1. Logon to target database as Streams Admin user and stop the downstream capture and apply processes.

sqlplus streams_admin/streams_admin

SQL> exec dbms_apply_adm.stop_apply(apply_name=>’SRC_SCHEMA_APPLY’)

SQL> exec dbms_capture_adm.stop_capture(capture_name=>’SRC_SCHEMA_CAPTURE’)

2. Logon to source database as Streams Admin user. Generate and implicitly obtain the first SCN on source DB containing the data dictionary.

sqlplus streams_admin/streams_admin
SQL>
SET SERVEROUTPUT ON
DECLARE
     scn NUMBER;
BEGIN
     DBMS_CAPTURE_ADM.BUILD(
     first_scn => scn);
     DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);
END;
/
First SCN Value = 1900359521

PL/SQL procedure successfully completed.

3. Logon to target database as Streams Admin user and drop capture process.

sqlplus streams_admin/streams_admin

SQL> exec dbms_capture_adm.drop_capture (‘SRC_SCHEMA_CAPTURE’);

PL/SQL procedure successfully completed.

4. Create capture process on target database. Use SCN obtained in step 2 for both start_scn and first_scn parameters of DBMS_CAPTURE_ADM.CREATE_CAPTURE procedure.

BEGIN
   DBMS_CAPTURE_ADM.CREATE_CAPTURE(
         queue_name         => 'STREAMS_ADMIN.STREAMS_SRC_Q',
         capture_name       => 'SRC_SCHEMA_CAPTURE',
         rule_set_name      => NULL,
         start_scn          => 1900359521,
         source_database    => '&src_db_name',
         use_database_link  => TRUE,
         first_scn          => 1900359521,
         logfile_assignment => 'implicit');
END;
/

5. Add capture rules using DBMS_STREAMS_ADM.ADD_SCHEMA_RULES procedure, as in example below:

BEGIN
   DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
          schema_name     => 'SRC',
          streams_type    => 'CAPTURE',
          streams_name    => 'SRC_SCHEMA_CAPTURE',
          queue_name      => 'STREAMS_ADMIN.STREAMS_SRC_Q',
          include_dml     => TRUE,
          include_ddl     => FALSE,
          source_database => '&src_db_link',
          and_condition   => ':dml.get_command_type() != ''DELETE'');
END;
/

6. Add capture performance settings using DBMS_STREAMS_ADM.SET_PARAMETER and DBMS_STREAMS_ADM.ALTER_CAPTURE procedures, as in example below:

BEGIN
   dbms_capture_adm.set_parameter( capture_name => 'SRC_SCHEMA_CAPTURE',
                                   parameter    => '_CHECKPOINT_FREQUENCY',
                                   VALUE        => '1000');
   dbms_capture_adm.alter_capture( capture_name => 'SRC_SCHEMA_CAPTURE',
                                   checkpoint_retention_time => 7);
   dbms_capture_adm.set_parameter( capture_name => 'SRC_SCHEMA_CAPTURE',
                                   parameter    => 'PARALLELISM',
                                   VALUE        => '2');
   dbms_capture_adm.set_parameter( capture_name => 'SRC_SCHEMA_CAPTURE',
                                   parameter    => '_SGA_SIZE',
                                   VALUE        => '100');
END;
/

7. Start the combined capture and apply process on the target database.

SQL> exec dbms_apply_adm.start_apply(apply_name=>’SRC_SCHEMA_APPLY’)

SQL> exec dbms_capture_adm.start_capture(capture_name=>’SRC_SCHEMA_CAPTURE’)

8. Log back onto source database and switch log files to initiate the downstream capture process.

sqlplus / as sysdba

SQL> alter system archive log current;

System altered.

9. Logon to target database and check capture process is “capturing changes”.

sqlplus streams_admin/streams_admin
SQL> select CAPTURE_NAME, STATE from v$streams_capture;
CAPTURE_NAME            STATE
------------------      -----------------
SRC_SCHEMA_CAPTURE      CAPTURING CHANGES

10. If you wish to re- enable downstream real-time mine, this can be done by executing the following procedure after Streams archivelog downstream mine has reinitialised. (downstream real-time mine also requires standby redolog files on the target database). Then re-execute step 8 to make the transition.

BEGIN
   dbms_capture_adm.set_parameter( capture_name => 'SRC_SCHEMA_CAPTURE',
                                   parameter    => 'downstream_real_time_mine',
                                   VALUE        => 'Y');
END;
/

____________________________________________________________

Should the capture process not advance and appears stuck in one of the following states:

 select * from v$streams_capture shows : 
  • INITALIZING / DICTIONARY INITIALIZATION (the state alternates between these states), or
  • WAITING FOR DICTIONARY REDO: FIRST SCN <SCN> , or
  • WAITING FOR REDO: LAST SCN MINED <SCN> , or
  • WAITING FOR DICTIONARY REDO: FILE <filename>

 Then perform these additional steps: 

11. Repeat step 1 and 2 above

12. Make a note of the System Change Number returned from step 2 and alter the downstream capture process on the target database to change the start SCN to this number.

SQL> exec dbms_capture_adm.alter_capture(capture_name=>’SRC_SCHEMA_CAPTURE’,start_scn=><SCN>)

13. Start the apply and capture processes on the target database.

SQL> exec dbms_apply_adm.start_apply(apply_name=>’SRC_SCHEMA_APPLY’)

SQL> exec dbms_capture_adm.start_capture(capture_name=>’SRC_SCHEMA_CAPTURE’)

14. Check the capture process is “capturing changes”.

SQL> select CAPTURE_NAME, STATE from v$streams_capture;
CAPTURE_NAME            STATE
------------------      -----------------
SRC_SCHEMA_CAPTURE      CAPTURING CHANGES

Resolving OPatch error when Installing Interim Patches on 11.1.0.7.1 PSU

Posted in OPatch with tags , on December 9, 2009 by John Jeffries

Patch Set Updates (PSUs) are proactive cumulative patches containing recommended bug fixes that are released on a regular and predictable schedule.
PSUs include recommended Patch Bundles and Critical Patch Updates (CPUs)

When installing interim patches on top of 11.1.0.7.1 PSU, it is possible to encouter an Opatch error code 73 as seen in the example below.

[oracle@g###01a patches]$ unzip p7006588_111071_Linux-x86-64.zip
Archive:  p7006588_111071_Linux-x86-64.zip
   creating: 7006588/
   creating: 7006588/files/
   creating: 7006588/files/lib/
   creating: 7006588/files/lib/libserver11.a/
  inflating: 7006588/files/lib/libserver11.a/kfn.o
  inflating: 7006588/files/lib/libserver11.a/kfnc.o
  inflating: 7006588/files/lib/libserver11.a/ksmp.o
  inflating: 7006588/files/lib/libserver11.a/kspt.o
   creating: 7006588/etc/
   creating: 7006588/etc/config/
  inflating: 7006588/etc/config/inventory.xml
  inflating: 7006588/etc/config/actions.xml
   creating: 7006588/etc/xml/
  inflating: 7006588/etc/xml/GenericActions.xml
  inflating: 7006588/etc/xml/ShiphomeDirectoryStructure.xml
  inflating: 7006588/README.txt
[oracle@g###01a patches]$ cd 7006588/
[oracle@g###01a 7006588]$ opatch apply
Invoking OPatch 11.1.0.6.2
Oracle Interim Patch Installer version 11.1.0.6.2
Copyright   2007, Oracle Corporation.  All rights reserved.
Central Inventory : /u01/app/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.2
OUI version       : 11.1.0.7.0
OUI location      : /u01/app/oracle/product/11.1.0/asm/oui
Log file location : /u01/app/oracle/product/11.1.0/asm/cfgtoollogs/opatch/opatch2009-12-08_15-07-33PM.log
ApplySession failed: Patch ID is null.
System intact, OPatch will not attempt to restore the system
OPatch failed with error code 73
[oracle@g###01a 7006588]$

Solution

Upgrading OPatch to 11.1.0.6.8 or higher will resolve the issue.

Oracle recommends that all customers be on the latest version of OPatch.
The following Metalink Note: 224346.1 provides the instructions
to update OPatch to the latest version.

Read the complete article by clicking on the link below:

http://www.oracle11ggotchas.com/articles/OvercomingOPatchIssues.htm

Re-instantiating Schema Replication with Oracle Streams Downstream Capture

Posted in Oracle Streams with tags , , on December 8, 2009 by John Jeffries

Have you ever had Streams fail to replicate data to a target database (for whatever reason) during heavy load on the source database and Streams has fallen behind by several hours? You are not concerned about the data on the target database as this is a test system; you just want Streams to “catch-up” as quickly as possible to a point where testing can continue.

The following steps illustrate how to fast-track the “catch-up process”, to get Streams back to “WAITING FOR REDO” state.

Note. This procedure will not apply any changes made on the source database to the target database from time of failure to when you re-instantiate the schema.

1. Logon to target database as Streams Admin user and stop the downstream capture and apply processes.

sqlplus streams_admin/streams_admin

SQL> exec dbms_apply_adm.stop_apply(apply_name=>’SRC_SCHEMA_APPLY’)

SQL> exec dbms_capture_adm.stop_capture(capture_name=>’SRC_SCHEMA_CAPTURE’)

2. Instantiate source schema so we know from what point to start replication

SQL> set serverout on
SQL>
DECLARE
iscn NUMBER;
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER@&src_db_name();
DBMS_APPLY_ADM.SET_SCHEMA_INSTANTIATION_SCN(
source_schema_name => ‘SRC’,
source_database_name => ‘&src_db_name’,
instantiation_scn => iscn,
recursive => TRUE);

dbms_output.put_line(‘Instantiation SCN = ‘||iscn);

END;
/

Instantiation SCN = 1256797484

PL/SQL procedure successfully completed.

3. Make a note of the Instantiation System Change Number and alter the downstream capture process on the target database to change the start SCN to this number.

SQL> exec dbms_capture_adm.alter_capture(capture_name=>’SRC_SCHEMA_CAPTURE’,start_scn=>1256797484)

4. The following messages can be seen in the alert log of the database instance where Streams is running:

Thu Nov 26 12:01:12 2009
knlciAlterCapture: start scn changed.
scn: 0×0000.4ae9352c
Thu Nov 26 12:01:46 2009
knlciAlterCapture: start scn changed.
scn: 0×0000.4ae9352c

(Convert the SCN Hex number 4ae9352c to Decimal to get 1256797484)

5. Start the apply and capture processes on the target database.

SQL> exec dbms_apply_adm.start_apply(apply_name=>’SRC_SCHEMA_APPLY’)
SQL> exec dbms_capture_adm.start_capture(capture_name=>’SRC_SCHEMA_CAPTURE’)

6. The following messages can be seen in the alert log of the database instance where Streams is running:

Thu Nov 26 12:02:30 2009
Streams APPLY AP01 for SRC_SCHEMA_APPLY started with pid=73, OS id=20087
Thu Nov 26 12:02:30 2009
Streams CAPTURE CP01 for SRC_SCHEMA_CAPTURE started with pid=74, OS id=20089

CP02: Warning: capture (SRC_SCHEMA_CAPTURE) start_scn is higher than last_acked scn. LCRs not seen at apply (SRC_SCHEMA_APPLY) might be filtered out!
Streams CAPTURE CP02 for SRC_SCHEMA_CAPTURE with pid=132, OS id=26534 is in combined capture and apply mode.
Streams CAPTURE CP01 for SRC_SCHEMA_CAPTURE with pid=97, OS id=26438 is in combined capture and apply mode.
Streams downstream capture SRC_SCHEMA_CAPTURE uses downstream_real_time_mine: TRUE
Starting persistent Logminer Session with sid = 8 for Streams Capture SRC_SCHEMA_CAPTURE
LOGMINER: Parameters summary for session# = 8
LOGMINER: Number of processes = 4, Transaction Chunk Size = 1
LOGMINER: Memory Size = 100M, Checkpoint interval = 1000M
LOGMINER: SpillScn 0, ResetLogScn 1
LOGMINER: krvxpsr summary for session# = 8
LOGMINER: StartScn: 1337626267 (0×0000.4fba8e9b)
LOGMINER: EndScn: 0
LOGMINER: HighConsumedScn: 1394932052 (0×0000.5324f954)
LOGMINER: session_flag 0×1
LOGMINER: LowCkptScn: 1337320672 (0×0000.4fb5e4e0)
LOGMINER: HighCkptScn: 1337545817 (0×0000.4fb95459)
LOGMINER: SkipScn: 1337320672 (0×0000.4fb5e4e0)
Thu Nov 26 12:02:39 2009
LOGMINER: session#=8, reader MS00 pid=143 OS id=20298 sid=974 started
Thu Nov 26 12:02:39 2009
LOGMINER: session#=8, builder MS01 pid=144 OS id=20300 sid=979 started
Thu Nov 26 12:02:39 2009
LOGMINER: session#=8, preparer MS02 pid=145 OS id=20302 sid=969 started
..
LOGMINER: Begin mining logfile for session 8 thread 1 sequence 51427, +FLASH/tgt_db/archivelog/2009_11_25/thread_1_seq_51427.5942.703879123
LOGMINER: Begin mining logfile for session 8 thread 2 sequence 53349, +FLASH/tgt_db/archivelog/2009_11_25/thread_2_seq_53349.5900.703879313
LOGMINER: Begin mining logfile for session 13 thread 1 sequence 51417, +FLASH/tgt_db/archivelog/2009_11_25/thread_1_seq_51417.4816.703877451
LOGMINER: Begin mining logfile for session 13 thread 2 sequence 53346, +FLASH/tgt_db/archivelog/2009_11_25/thread_2_seq_53346.4910.703877989
LOGMINER: End mining logfile for session 13 thread 1 sequence 51417, +FLASH/tgt_db/archivelog/2009_11_25/thread_1_seq_51417.4816.703877451

7. It is sometimes necessary to perform a log file switch on the source database in order for Streams to start mining logs.

SQL> alter system archive log current;

System altered.

Conclusion

Streams combined capture and apply processes will start and LogMiner will mine each of the Foreign Archived Log files sent from the source database, searching for the new Instantiation SCN. This process provides a considerably faster “catch-up” method as only the capture process is executing, the apply process remains idle as seen in the query output below.

CAPTURE PROCESS STATUS

SQL> select CAPTURE_NAME, STATE from v$streams_capture;
CAPTURE_NAME 	STATE
------------------ -----------------
SRC_SCHEMA_CAPTURE CAPTURING CHANGES
or
CAPTURE_NAME 	STATE
------------------ -----------------
SRC_SCHEMA_CAPTURE CREATING LCR

APPLY PROCESS STATUS

SQL> select APPLY_NAME, STATE from v$streams_apply_reader;
APPLY_NAME 	STATE
------------------ -----------------
SRC_SCHEMA_APPLY 	DEQUEUE MESSAGES

SQL> select APPLY_NAME, STATE from v$streams_apply_server;
APPLY_NAME 	STATE
------------------ -----------------
SRC_SCHEMA_APPLY 	IDLE
SRC_SCHEMA_APPLY 	IDLE
SRC_SCHEMA_APPLY 	IDLE
SRC_SCHEMA_APPLY 	IDLE

SQL> select APPLY_NAME, STATE from v$streams_apply_coordinator;
APPLY_NAME 	STATE
------------------ -----------------
SRC_SCHEMA_APPLY 	IDLE
Follow

Get every new post delivered to your Inbox.