GOLDENGATE process show RUNNING status, when not RUNNING.

This might occur in case of crash on host or database node where goldengate is running.

Goldengate maintains information about the process status in the file system, when the server crashes the file that has PID data is not released, and the process status in GGSCI shows erroneous information.

In GGSCI, process status it’s OK:

GGSCI (greporaLAB.net) 7> info mgr

Manager is running (IP port greporaLAB.net.7809, Process ID 42064).

If you try to stop process, you will not be able to:

More“GOLDENGATE process show RUNNING status, when not RUNNING.”

OGG-02077 Extract encountered a read error in the asynchronous reader thread and is abending: Error code 1683

Have this crazy in ggserr.log?

Source Context :
SourceModule : [er.redo.ora]
SourceID : [/scratch/aime/adestore/views/aime_stuya22/oggcore/OpenSys/src/app/er/redo/oracle/redoora.c]
SourceFunction : [REDOORA_handle_read_error(errmsg_t &)]
SourceLine : [11630]

ERROR OGG-02077 Extract encountered a read error in the asynchronous reader thread and is abending: Error code 1683, error message: ORA-01683: unable to extend index . partition by in tablespace.

Check db alert_*.log, you should find some alert.

ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_1470969483_24757 by 128 in tablespace SYSAUX
ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_1470969483_24757 by 128 in tablespace SYSAUX

Resolving issue:

alter tablespace SYSAUX add datafile '+DG' size 1g;

Some options are:
Reduce AWR retention:

SQL> SELECT extract(day from snap_interval) *24*60+extract(hour from snap_interval) *60+extract(minute from snap_interval) snapshot_Interval,
extract(day from retention) *24*60+extract(hour from retention) *60+extract(minute from retention) retention_Interval
FROM dba_hist_wr_control;
SQL> exec DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(retention => 10800, interval => 10);

Reduce Statistics Level:

SQL> show parameter STATISTICS_LEVEL
NAME                 TYPE        VALUE
---------------------------------------------------------
statistics_level     string     ALL

SQL> alter system set STATISTICS_LEVEL = TYPICAL scope=both sid='*';

Type your message when beep 🙂

EM Repository: ORA-00060: Deadlock detected error in alert log

Hello!
Some time ago I found some ORA-00060: Deadlock detected. errors in a client OEM database… Like this:

Thu Dec 22 09:01:55 2016
ORA-00060: Deadlock detected. More info in file /oracle/oemdb/diag/rdbms/oemdb/oemdb/trace/oemdb_ora_1757.trc.
Thu Dec 22 09:02:07 2016
ORA-00060: Deadlock detected. More info in file /oracle/oemdb/diag/rdbms/oemdb/oemdb/trace/oemdb_ora_1759.trc.
ORA-00060: Deadlock detected. More info in file /oracle/oemdb/diag/rdbms/oemdb/oemdb/trace/oemdb_ora_1759.trc.

In summary, after investigating the trace (as per below), found that the issueis caused by the following command:

More“EM Repository: ORA-00060: Deadlock detected error in alert log”

“java.sql.SQLException: ORA-28040: No matching authentication protocol” After Upgrade Database to 12c

Hello everyone!

I already wrote a post about it but I think I was not clear and easy to find enough. So let me make another post about and add some information…

Ok, are you facing a “java.sql.SQLException: ORA-28040: No matching authentication protocol” after upgrade your database to 12c?

It’s related to old jdbc driver version in your application. Please review matrix available in this post and check your application. The MOS noted below have good information about it…

More““java.sql.SQLException: ORA-28040: No matching authentication protocol” After Upgrade Database to 12c”

RS-7445 [Serv MS leaking memory] [It will be restarted] [] [] [] [] [] [] [] [] [] []

Hello!
Having this error from cell alerthistory.log? Don’t panic!
Take a look in MOS: Exadata Storage Cell reports error RS-7445 [Serv MS Leaking Memory] (Doc ID 1954357.1). It’s related to Bug  – RS-7445 [SERV MS LEAKING MEMORY].

The issue is a memory leak in the Java executable and affects systems running with JDK 7u51 or later versions. This is relevant for all versions in Release 11.2 to 12.1.

What happens is that MS process is consuming high memory (up to 2GB).  Normally MS use around 1GB but because of the bug the memory allocated can grow upt to 2GB.  You can check it as per example below:

[root@exaserver ~]# ps -feal|grep java
0 S root     16493 14737  0  80   0 - 15317 pipe_w 18:34 pts/0    00:00:00 grep java
0 S root     22310 27043  2  80   0 - 267080 futex_ 18:15 ?       00:00:27 /usr/java/default/bin/java -Xms256m -Xmx512m -XX:-UseLargePages -Djava.library.path=/opt/oracle/cell/cellsrv/lib -Ddisable.checkForUpdate=true -jar /opt/oracle/cell/oc4j/ms/j2ee/home/oc4j.jar -out /opt/oracle/cell/cellsrv/deploy/log/ms.lst -err /opt/oracle/cell/cellsrv/deploy/log/ms.err

Note that: 267080 * 4096 = 1143MB (1GB). If your number is higher than this, it indicates the presence of the bug.

More“RS-7445 [Serv MS leaking memory] [It will be restarted] [] [] [] [] [] [] [] [] [] []”

Error OGG-00354 Invalid BEFORE column:(column_name)

When we use extraction process with certain macro filters, and send the trails to a goldengate with JAVA adapter, the java extract process fails with the following error: OGG-00354 Invalid BEFORE column:(column_name).

EXTRACT PROCESS

EXT01
exttrail ./dirdat/e1, FORMAT RELEASE 11.1
GETUPDATEBEFORES
include ./dirmac/filter.mac
TABLE OWNER01.TABLE01, #filter01();

PUMP PROCESS

PUMP01
rmthost ggjava.net
rmttrail ./dirdat/j1 , format release 11.1
GETUPDATEBEFORES
TABLE OWNER01.TABLE01;

EXTRACT GG JAVA

EXTRACT JAVA01
GETUPDATEBEFORES
TABLE OWNER01.TABLE01;

In some cases, this issue can be resolved just removing the clause “GETUPDATEBEFORES”, as reported in the Oracle note (Doc ID 2151605.1). But in some environments this procedure not resolve, because it is an undocumented bug in goldengate JAVA 11.1, which is caused by the use of format release 11.1.
This same process has been testing in goldengate 12.1, with format release 12.1, and the problem not occurs.

The solution is the upgrade!  \o/
Dieison.

Materialized View with DBLink: ORA-00600: internal error code, arguments: [kkzuasid]

Hello guys!
Not being able to refresh you Materialized View because of this error?

bamdb> exec dbms_mview.refresh('PROD_ORABAM.MVIEW_TEST','C');
BEGIN dbms_mview.refresh('PROD_ORABAM.MVIEW_TEST','C'); END;

*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kkzuasid], [2], [0], [1], [], [], [], [], [], [], [], []
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2809
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 3025
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2994
ORA-06512: at line 1

The bad new is there is no workaround (I usually prefer workaround for this, is quicker and less complicated).
But the good new is there is a patch for this: Patch 17705023 : ORA-600 [KKZUASID] ON MV REFRESH

More“Materialized View with DBLink: ORA-00600: internal error code, arguments: [kkzuasid]”

ORA-01153: an incompatible media recovery is active

When trying to start or increase parallel of recover manager on datagauard (MRP):

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
*
ERROR at line 1:
ORA-01153: an incompatible media recovery is active

I simply happen because there already are a process runnning, let’s check:

More“ORA-01153: an incompatible media recovery is active”

x$kglob: ORA-02030: can only select from fixed tables/views

Hi all!
While selecting on x$kglob with DBA credentials hanging on:

SQL> select count(*) from sys.x$kglob;
ERROR at line 1:
ORA-00942: a tabela ou view não existe

But with sys it succeed. Ok, let’s grant privilege:

SQL> grant select on sys.x$kglob to dba;
grant select on sys.x$kglob to dba
*
ERROR at line 1:
ORA-02030: can only select from fixed tables/views

What a hell! I couldn’t grant it any way!
So the MCGayver solution was:

More“x$kglob: ORA-02030: can only select from fixed tables/views”

Searching entries on Alert.log: A Better Way

Hi all!
As the oldest readers know, someday I had to found some entries in the alertlog and I had a really big log. So I jerrry-ringed some scripts for grepping alert with auxiliar files and etc.
I can see the posts here: Grepping Alert by Day  and Grepping Entries from Alert.log.

So… They are functional, but probably the worst ways to get it. I didn’t know and was innocent to not search by the view x$dbgalertext.
There is also possible to write on alert through the procedure SYS.DBMS_SYSTEM.KSDWRT.

Ok, so let me fix this situation with theese two good guys: @write_alert and @find_alert

More“Searching entries on Alert.log: A Better Way”