Unable To Start OID 11g or 12c OR Intermittently Slows with High Optime or Etime After Migration or Upgrade of Backend Database to Oracle 12.1.0.2, 12.2.1.3.0 or 19c. OID Log Shows: Guardian: Database Search Error.
(Doc ID 2142279.1)
Last updated on AUGUST 30, 2023
Applies to:
Oracle Internet Directory - Version 11.1.1.7.0 and laterInformation in this document applies to any platform.
Symptoms
After a cold backup from the backend source database (11.2.0.3), upgraded Oracle Internet Directory (OID) backend database (DB) to 12.1.0.2 ,12.2.1.3.0 or 19c following all checklists for the standard 12c/19c upgrade procedure.
Changed the $ORACLE_INSTANCE/config/tnsnames.ora on the OID 11g server to point to the new 12c/19c database.
The OID services fails to startup.
Reverting back to the OLD database works fine.
Errors similar to the following found in the OID logs:
[2016-04-12T14:08:15+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: gslsggDelete: Deleting entry cn=asinst_6_oid2_1_<HOSTNAME>,cn=osdldapd,cn=subregistrysubentry
[2016-04-12T14:08:15+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: Database Search Error.
[2016-04-12T14:08:15+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: Instance cn=asinst_6_oid2_1_<HOSTNAME>,cn=osdldapd,cn=subregistrysubentry search failed
[2016-04-12T14:08:15+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: OIDLDAPD Instance 1 deletion failed
[2016-04-12T14:08:15+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: Starting OIDLDAPD cmdLine args = "instance=1 inst=1 "
[2016-04-12T14:08:15+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: Starting OIDLDAP Server,PID=22233
[2016-04-12T14:08:15+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: Updating Process Table...
[2016-04-12T14:08:15+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: gsldda_DeleteEntry:gsldfgGetEntryID Error..1010
[2016-04-12T14:08:15+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: CreateInstance: Successfuly created entry cn=asinst_6_oid2_1_<HOSTNAME>,cn=osdldapd,cn=subregistrysubentry
[2016-04-12T14:10:14+00:00] [OID] [NOTIFICATION:16] [] [OIDMON] [host: <HOSTNAME>] [pid: <PID>] [tid: 0] Guardian: Shutting down
OR:
From time to time LDAP operations in OID slow down quite considerably and applications dependent on OID, such as OAM, may become unresponsive.
OID continues to work and ldapbind tests may succeed quite fast.
However, heavy trace debug and higher shows high OPtimes in the oidldapd logs, eg:
<host>] [pid: <pid>] [tid: <tid>] [ecid:
<ecid>] ServerWorker (REG):[[
BEGIN
ConnID:26 mesgID:125460 OpID:1747 OpName:search
ConnIP:::ffff:<IP.:<port>
ConnDN:cn=<username>,cn=users,dc=<company>,dc=com
gslesabAddToBer: Added mail to the Ber
2021-05-11T15:26:30.614813 * gslesabAddToBer: Added <attriute> to the Ber
2021-05-11T15:26:30.614968 * gslesabAddToBer: Added objectclass to the Ber
2021-05-11T15:26:30.614991 * gslesabAddToBer: Added orclpassword to the Ber
2021-05-11T15:26:30.615003 * gslesabAddToBer: Added postalcode to the Ber
2021-05-11T15:26:30.615877 * gslesabAddToBer: Added sn to the Ber
2021-05-11T15:26:30.615921 * gslesabAddToBer: Added st to the Ber
2021-05-11T15:26:30.615944 * gslesabAddToBer: Added uid to the Ber
2021-05-11T15:26:30.615957 * gslesabAddToBer: Added userpassword to the Ber
2021-05-11T15:26:30.616505 * gslesabAddToBer: Added authpassword;oid to the
Ber
2021-05-11T15:26:30.616655 * gslesabAddToBer: Added
authpassword;orclcommonpwd to the Ber
2021-05-11T15:26:32.451255 * Entry sent as a search result.
2021-05-11T15:26:47.219301 * INFO:gsleswrASndResult OPtime=77198406 micro sec
Qtime=60217384 micro sec DBtime=16259 micro sec RESULT=0 tag=101 nentries=1
2021-05-11T15:26:47.219352 * Exit: gslsbsSearch()
2021-05-11T15:26:47.219485 * Exit gslfseADoSearch
2021-05-11T15:26:47.219970 *
BASE DN = dc=<company>,dc=com
SCOPE = 2
FILTER = (uid=<uid>)
REQD ATTRS = * cn orclmemberof
EVENT "BER READ " time : 5348 micro sec
EVENT "InmemFilt " time : 1893 micro sec
EVENT "DIME OVRD " time : 16975045 micro sec
EVENT "PRE DIME " time : 547 micro sec
EVENT "DB Fetch " time : 18282 micro sec
EVENT "RS LOOKUP " time : 17731 micro sec
EVENT "RS INSERT " time : 4 micro sec
EVENT "EC LOOKUP " time : 2 micro sec
EVENT "BValFetch " time : 3912 micro sec
EVENT "Post Dime " time : 16955428 micro sec <---- most of the OPtime is seen in this event
EVENT "ACL overhd " time : 24366 micro sec
EVENT "ACL ATTR " time : 322205 micro sec
EVENT "Ber Flush " time : 142 micro sec
EVENT "Ber flush " time : 140 micro sec
EVENT "Ber flush " time : 17 micro sec
TOTAL "Operation " time : 16981024 micro sec <---- this would be equivalent to 16.98 seconds, whereas in a properly tuned OID server LDAP operations should not take longer than milli- or microseconds
TOTAL "Worker " time : 16981657 micro sec
END
Changes
Upgraded OID Metadata repository database from 11g to 12c or 19c.
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Changes |
| Cause |
| Solution |
| References |