Tools such as Toad appeared 2 b very slow.
From mos I quote:
…The bug is fixed in patchset 220.127.116.11 and higher versions.
Release 18.104.22.168 and the patchset 22.214.171.124 are affected by this.
Since patching was not an option the workaround has been followed:
Mos note is offering create or replace view ALL_SYNONYMS.. and to set spfile value (_FIX_CONTROL).
Workaround has been implemented in Test and Preprod environments, no issues found with it and it showed improvement @ user side.
January 5th I wrote a post on the issues we faced with ASM instance which would not let me log in as sqlplus / as sysasm at specific point and time during which time alert log of the databases on that box would also be sending warnings to the alert log “.. ASM communication error”. With information on the web (Metalink) a solution and a workaround had been offered and implemented. For example on that specific box the oinstall gid was lacking in the first place (primary os group is dba (oracle:dba) so I had th Linux colleague added the oinstall onthat box. And as a workaround I created a tnsnames entry and connected via: sys@asm as sysasm that was also working well. So at that point and time we all thought , case closed.
Well…… Not entirely cause the issue showed again recently and even though the workaround (using the connect string method was working) I was not a happy Database Administrator with it. I opened a Tar with Oracle but I was going in circles with it this time.
Last Friday the Issue showed again on a box in one of the clusters. An internal mail was sent within our team about this and a very interesting clue came back from one of the Colleagues who had similar experience in different project. He came up with following information on MOS:
Troubleshooting ORA-1031: Insufficient Privileges While Connecting As SYSDBA [ID 730067.1]
UNIX: Checklist for Resolving Connect AS SYSDBA Issues [ID 69642.1]
UNIX: Diagnostic C program for ORA-1031 from CONNECT INTERNAL / AS SYSDBA [ID 67984.1]
Actually especially last Note 67984.1 was very useful cause it showed that during time of issue the gid ( group Id ) was no longer valid due to an Ldap call.
With the Output of that note and the analyses after that it turned out that the NCSD daemon (http://www.linux.ncsu.edu/realm_linux/usersguide-EL4/ch04s06.php) might be part of the issue when something like that was queried on the OS:
# getent group dba
# getent group 5000
#getent group dba
When the Linux administrator configured the correct (exception) information in /etc/ldap.conf the problem vanished and the Phantom hunt ended.
Bottom line of this:
- Never believe in phantoms, thinks like described happen for a reason.
- Always be willing to communicate with in the team and beyond cause communication might bring a so-called aha – Erlebnis (déjà vu).
- Standardize, standardize, standardize when you are using Ldap and local configurations cause you really let the ghost out of the machine otherwise.
- A special thank you to the colleagues who started the internal mail and to the one who shared his experiences with the team.
A couple of months ago I had the issue that in an 126.96.36.199 environment with Grid Infra structure and ASM on Linux , without any specific reason at a specific point and time would see messages about communication error between the databases and the ASM instance and I was not able to connect to the ASM instance with a sqlplus / as sysasm. I have opened a tar back then and even got myself a fresh bug 14767353 number but no answers. So But practically this remained unsolved. Friday 4th I had same issue again, so it was time to get back to arms and investigate this.
Below you will find the steps , what i saw and how I solved it with the help of my friends(Google and Metalink).
Environment: 4 Node GI 188.8.131.52.0 on Red Hat Linux with ASM. Installations performed as oracle:dba