CRS Not Starting after Removing OS User: How to Workaround and How to Solve!

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?

Continue reading

OGG-00446 No data selecting position from checkpoint table GGATE.CHECKPOINTTABLE for group

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 .


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.


GGSCI ( 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 ( 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 ( 29> start R_CRM

Sending START request to MANAGER ...


ORA-07445: exception encountered: core dump [nstimexp()+45] [SIGSEGV] [ADDR:0x58] [PC:0x7F42ABB] [Address not mapped to object] []

Hello all,
I had faced some occourrences of this error in a 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
However, on upgrading to it’s a hit on Bug 3934729 which is fixed in

Recommended actions are:
– Upgrade databases do or higher. (best solution, but may require more efforts to validate the upgrade).
– 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:

Continue reading

ORA-24093: AQ agent SCHED$_% not granted privileges of database user %

These days, when trying to add dbms_scheduler notifications for different user I was getting this strange error:

 DBMS_SCHEDULER.add_job_email_notification (
  job_name   =>  'APPOWNER.MYJOB',
  recipients =>  '',
  events     =>  'job_started, job_succeeded'

ORA-24093: AQ agent SCHED$_XXX not granted privileges of database user APPUSER
ORA-06512: at "SYS.DBMS_ISCHED", line 8296
ORA-06512: at "SYS.DBMS_SCHEDULER", line 4353
ORA-06512: at line 3

The issue is that “secure queue access must be granted to an Oracle Database Advanced Queuing (AQ) agent explicitly for both enqueue and dequeue operations. You grant the agent these privileges using the ENABLE_DB_ACCESS procedure in the DBMS_AQADM package” (

So, problem solved with this:

    agent_name  => 'SCHED$_XXX',
    db_username => 'APPUSER');

See you next week!