Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

JDBC_83 - Cannot switch from in-memory buffering to reading committed data only

Hi,

when trying to use the local buffer settings in the Oracle CDC origin, I receive the above error on 3.5.2.

Here are some settings:

image description

When i change to non-local buffering, the logminer session is started like this (from oracle trace):

BEGIN
   DBMS_LOGMNR.START_LOGMNR (
      STARTSCN   => 719910088118,
      ENDSCN     => 719912577365,
      OPTIONS    =>   DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG
                    + DBMS_LOGMNR.CONTINUOUS_MINE
                    + DBMS_LOGMNR.NO_SQL_DELIMITER);
END;

SELECT TIMESTAMP
FROM V$LOGMNR_CONTENTS
ORDER BY TIMESTAMP

The second statement runs for 13 hours (i killed it afterwards) - btw. I do not understand the reason for this statement. Is it for matching timestamp and SCN?

So I do not have a chance to "CDC" this database so far.

Interestingly, I have a second DB where everthing goes fine with buffering on Oracle. After a while, it starts reading.

Any idea? .

Thanks and Regards, Peter

JDBC_83 - Cannot switch from in-memory buffering to reading committed data only

Hi,

when trying to use the local buffer settings in the Oracle CDC origin, I receive the above error on 3.5.2.

Here are some settings:

image description

When i change to non-local buffering, the logminer session is started like this (from oracle trace):

BEGIN
   DBMS_LOGMNR.START_LOGMNR (
      STARTSCN   => 719910088118,
      ENDSCN     => 719912577365,
      OPTIONS    =>   DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG
                    + DBMS_LOGMNR.CONTINUOUS_MINE
                    + DBMS_LOGMNR.NO_SQL_DELIMITER);
END;

SELECT TIMESTAMP
FROM V$LOGMNR_CONTENTS
ORDER BY TIMESTAMP

The second statement runs for 13 hours (i killed it afterwards) without returning anything. Only due to the ORDER BY - btw. without an order by, it starts returning data immediately. I do not understand the reason for this statement. Is it for matching timestamp and SCN?

So SCN? What is the implication of sorting a result using continuous mining?

Now I do not have a chance to "CDC" this database so far.

Interestingly, I have a second DB where everthing goes fine with buffering on Oracle. After a while, it starts reading.

Any idea? .

Thanks and Regards, Peter

JDBC_83 - Cannot switch from in-memory buffering to reading committed data only

Hi,

when I've got two issues with the CDC stage.

(1) When trying to use the local buffer settings in the Oracle CDC origin, I receive the above error on 3.5.2.

Here are some settings:

image description

(2) When i change to non-local buffering, the logminer session is started like this (from oracle trace):

BEGIN
   DBMS_LOGMNR.START_LOGMNR (
      STARTSCN   => 719910088118,
      ENDSCN     => 719912577365,
      OPTIONS    =>   DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG
                    + DBMS_LOGMNR.CONTINUOUS_MINE
                    + DBMS_LOGMNR.NO_SQL_DELIMITER);
END;

SELECT TIMESTAMP
FROM V$LOGMNR_CONTENTS
ORDER BY TIMESTAMP

The second statement runs for 13 hours (i killed it afterwards) without returning anything. Only due to the ORDER BY - without an order by, it starts returning data immediately. I do not understand the reason for this statement. Is it for matching timestamp and SCN? What is the implication of sorting a result using continuous mining?

Now I do not have a chance to "CDC" this database so far.

Interestingly, I have a second DB where everthing goes fine with buffering on Oracle. After a while, it starts reading.

Any idea? .

Thanks and Regards, Peter

JDBC_83 - Cannot switch from in-memory buffering to reading committed data only

Hi,

I've got two issues with the CDC stage.

(1) When trying to use the local buffer settings in the Oracle CDC origin, I receive the above error on 3.5.2.

Here are some settings:

image description

(2) When i change to non-local buffering, the logminer session is started like this (from oracle trace):

BEGIN
   DBMS_LOGMNR.START_LOGMNR (
      STARTSCN   => 719910088118,
      ENDSCN     => 719912577365,
      OPTIONS    =>   DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG
                    + DBMS_LOGMNR.CONTINUOUS_MINE
                    + DBMS_LOGMNR.NO_SQL_DELIMITER);
END;

SELECT TIMESTAMP
FROM V$LOGMNR_CONTENTS
ORDER BY TIMESTAMP

The second statement runs for 13 hours (i killed it afterwards) without returning anything. Only due to the ORDER BY - without an order by, it, it starts returning data immediately. I do not understand the reason for this statement. Is it for matching timestamp and SCN? What is the implication of sorting a result using continuous mining?SCN (one can use sys.smon_scn_time to return that immediately)?

Now I do not have a chance to "CDC" this database so far.

Interestingly, I have a second DB where everthing goes fine with buffering on Oracle. After a while, it starts reading.

Any idea? .

Thanks and Regards, Peter