Hello all,
This days I found this in a client’s 12c Database when trying to create a Materialized View:
ORA-00600: internal error code, arguments: [qkswcWithQbcRefdByMain4]
A perfect match to MOS ORA-00600 [qkswcWithQbcRefdByMain4] when Create MV “WITH” clause (Doc ID 2232872.1).
The root cause is documented on BUG 22867413 – ORA-600 CALLING DBMS_ADVISOR.TUNE_MVIEW.
The given solution is to apply Patch 22867413.
After applying patch, issue solved. 🙂
Hello all,
Asking why to use this parameter? Why this is set in your environment? Or even how it can hep you? Here we go:
As per Oracle documentation, this parameter is used to avoid unused sessions to be kept open in database and locking resources.
It describe in minutes how much time a client/probe can be inactive before be ended.
I recently found an environment where this parameter was too low (1 minute), potentially causing some overhead in communication only for validations. By documentation, if it’s decided to enable it, Oracle recommends value “10”.
This way, after checking and no one be aware about this parameter reason to be there, I just suppressed him from SQLNET.ORA (going back to default “0”, which is equivalent to “disabled”), so we could even reduce the network workload.
However, now we are aware that in case we have abnormal closure of clients, we can have some unused connections opened consuming resources… Not a problem at this point… 🙂
Hello all!
Turns that a few days ago a client reached me because his CRSD was simply not starting. Like this:
[root@proddb proddb]$ ./crsctl start res ora.crsd -init CRS-2672: Attempting to start 'ora.crsd' on 'proddb' CRS-2676: Start of 'ora.crsd' on 'proddb' succeeded [root@proddb proddb]$ ps -ef |grep crsd root 19217 13424 0 11:53 pts/0 00:00:00 grep crsd
After some investigation, I found the following:
2017-01-24 14:00:06.859: [ CRSSEC][1690195712]{1:51052:2} Exception: OwnerEntry construction failed to retrieve user id by name with ACL string: owner:jacknobody:rwx and error: 1
2017-01-24 14:00:06.912: [ CRSSEC][1690195712]{1:51052:2} Exception: ACL entry creation failed for: owner:jacknobody:rwx
Hmmm, seems some CRS resources are owned by “Jack Nobody”… Turns that I this us was removed from OS:
[root@proddb proddb]$ cat /etc/passwd |grep jacknobody [root@proddb proddb]$
What to do now?
More“CRS Not Starting after Removing OS User: How to Workaround and How to Solve!”
After GoldenGate upgrade GoldenGate from 12.1 to 12.2, replicat abend with error:
ERROR OGG-00446 No data selecting position from checkpoint table GGATE.CHECKPOINTTABLE for group ‘R_CRM’, key 2028080425 (0x78e20d29), SQL .
ERROR OGG-01668 PROCESS ABENDING.
It appears replicat is not registered on CHECKPOINTTABLE (is’t true, it’s registered)
Try below:
As a workaround you can ALTER the replicat to the same checkpoint location when you do an INFO REP , DETAIL and then START.
Ex:
GGSCI (labp.grepora.net) 27> info R_CRM
REPLICAT R_CRM Last Started 2017-05-09 13:03 Status STOPPED
Checkpoint Lag 00:00:00 (updated 02:40:11 ago)
Log Read Checkpoint File ./dirdat/s5000609
2017-07-04 10:51:44.035765 RBA 98381832
GGSCI (labp.grepora.net) 28> alter R_CRM extseqno 00609 extrba 98381832
2017-07-04 14:44:39 INFO OGG-06594 Replicat R_CRMhas been altered through GGSCI. Even the start up position might be updated, duplicate suppression remains active in next startup. To override duplicate suppression, start R_CRM with NOFILTERDUPTRANSACTIONS option.
REPLICAT altered.
GGSCI (labp.grepora.net) 29> start R_CRM
Sending START request to MANAGER ...
REPLICAT R_CRM starting
Cheers!
Hello all,
I had faced some occourrences of this error in a 11.2.0.1 database recently.
ORA-07445: exception encountered: core dump [nstimexp()+45] [SIGSEGV] [ADDR:0x58] [PC:0x7F42ABB] [Address not mapped to object] []
After some investigation I found a match to Bug 3934729.
This issue is originally to matched to Bug 6918493, that is a reintroduction of Bug 2752985 but it’s fixed in 11.2.0.1.
However, on upgrading to 11.2.0.1 it’s a hit on Bug 3934729 which is fixed in 11.2.0.2.
Recommended actions are:
– Upgrade databases do 11.2.0.2 or higher. (best solution, but may require more efforts to validate the upgrade).
– Apply Patch 3934729: RANDOM ORA-07445 CORE DUMPS FROM DATABASE AND ORA-3113 FROM APPLICATION
– Set sqlnet.expire_time=0 (workaround)
– Ignore error.
After some research I decided to apply workaround, based on recommended usage of sqlnet.expire_time (Next weeks post is about this parameter :)).
This might be the root cause for the ORA-03135: connection lost contact and the actual value of this parameter on environment was 1, which is a very low value.
So, check which action is more suitable for your environment!
Hope it helps 🙂
Below some additional informations on my situation: