Hello all!
Having this error? Probably something like this:
ORA-00600: internal error code, arguments: [17147], [0x7F0315C53788], [], [], [], [], [], [], [], [], [], []
This is a known error. The best match on MOS is GoldenGate 12c IntRep Crash W/ ORA-600 [kghfrmrg:nxt] ;ORA-600[kghfrh:ds]; ORA 600 [17114]; [17147] (Doc ID 1666909.1)
Hey,
Don’t create so much expectations on this post.
This is because I don’t exactly fixed the issue, but workarounded…
The thing is: This error is caused in catalog database, so the workaround is simple: do a RMAN-nocatalog, I mean, simply don’t connect in catalog to perform the backup.
After completing the backup, I’d suggest you to force a synchronization with command “RESYNC CATALOG“. In worst case, on next execution the implicit resync will fix everything. 🙂
There is no bigger explanations on this, but you can same workaround in MOS Bug 12588237 – RMAN-3002 ORA-1: unique constraint (ckp_u1) violated after dataguard switchover (Doc ID 12588237.8).
And this is it for today!
See you next week!
Hello all,
This is because the error is generated by an unpublished bug 17891564, as per described in MOS ORA-7445 [ocl_lock_get_waitobj_owner] on an Exadata storage cell (Doc ID 1906366.1).
It affects Exadata storage cell with image version between 11.2.1.2.0 and 11.2.3.3.0. The CELLSRV process crash with this error as per:
Cellsrv encountered a fatal signal 11 Errors in file /opt/oracle/cell11.2.3.3.0_LINUX.X64_131014.1/log/diag/asm/cell//trace/svtrc_11711_27.trc (incident=257): ORA-07445: exception encountered: core dump [ocl_lock_get_waitobj_owner()+26] [11] [0x000000000] [] [] [] Incident details in: /opt/oracle/cell11.2.3.3.0_LINUX.X64_131014.1/log/diag/asm/cell//incident/incdir_257/svtrc_11711_27_i257.trc
The CELLSRV process should auto restart after this error.
Hello all,
Yeah, these days I got some errors and when validating the server found the fllowing error:
su: cannot set user id: Resource temporarily unavailable
As you can imagine, in order to fix the issue, I adjusted the /etc/security/limits.conf increasing oracle nprocs to:
oracle soft nproc 4047 oracle hard nproc 20384
Ok, turns out that after a while I got the same errors again…
After some investigating I find that the EM Agent process was with 5020 threads!
Take a look:
Quick one today!
Having message below in your 11.2.0.3 on AIX like this?
WARNING: Heavy swapping observed on system in last 5 mins. pct of memory swapped in [31.28%] pct of memory swapped out [3.81%]. Please make sure there is no memory pressure and the SGA and PGA are configured correctly. Look at DBRM trace file for more details.
Stand down, this issue is caused by unpublished Bug 11801934, mentioned in MOS False Swap Warning Messages Printed To Alert.log On AIX (Doc ID 1508575.1).
Basically happens because the v$osstat does not reflect proper stats for the swap space paging.
So, stay calm and see you next week!
Hi all!
This days I faced some ORA-600 as per below in a database:
ORA-00600: internal error code, arguments: [13030], [20], [], [], [], [], [], [], [], [], []
Checking for error in Database I find it was related to a pretty complex UPDATE, as per:
More“ORA-00600: internal error code, arguments: [13030], [20]”
This post is just a reflection, basically based on my last post about Adaptive Query Optimization/SQL Plan Directives. Several times we find some situations that can be solved by setting a parameter (likely a “_”) and we just proceed with an “alter system” disregarding about all the impact of this.
This is specially important when talking about “optimizer” parameters even for bugs causing ORA-600’s or performance issues… Changing those parameters in system will affect not only the SQL with the error but all SQLs in database, which may cause a really bad effect in some cases.
Ok Matheus, but what can I do?
Let’s to the obvious and generally applied methods:
More“Parameter Workarounds: Changing your Entire Database’s Behavior Because of a Query”
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”
Hello!
After discover your new 12c targets you are facing target status down for MGMT targets, similar to image below?
And checking on server all looks to be ok, right?
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] [] [] [] [] [] [] [] [] [] []”
