When SharePlex is running with ASM on 11g, the trace files under the ASM grid home/rdbms/log keep growing with these messages
*** 2015-01-21 01:37:53.680
2015-01-21 01:37:53.680: [ GPNP]clsgpnp_dbmsGetItem_profile: [at clsgpnp_dbms.c:313] Result: (0) CLSGPNP_OK. got ASM-Profile.DiscoveryString='/dev/mapper/asmshared*p1'
2015-01-21 01:37:54.072: [ default]failed to initialize skgp context
2015-01-21 01:37:54.072: [ default]slos op : sslssreghdlr
2015-01-21 01:37:54.072: [ default]slos dep : Error 0 (0)
2015-01-21 01:37:54.072: [ default]slos loc : sskgpinit1
2015-01-21 01:37:54.072: [ default]slos info:
[ CLWAL]clsw_Initialize: OLR initlevel [30000]
2015-01-21 01:37:54.073: [ default]a_init: Unable to get log name. Retval:[-4]
2015-01-21 01:37:54.103: [ GPNP]clsgpnp_dbmsGetItem_profile: [at clsgpnp_dbms.c:313] Result: (0) CLSGPNP_OK. got ASM-Profile.DiscoveryString='/dev/mapper/asmshared*p1'
2015-01-21 01:37:54.484: [ default]failed to initialize skgp context
2015-01-21 01:37:54.485: [ default]slos op : sslssreghdlr
2015-01-21 01:37:54.485: [ default]slos dep : Error 0 (0)
2015-01-21 01:37:54.485: [ default]slos loc : sskgpinit1
2015-01-21 01:37:54.485: [ default]slos info:
SharePlex is querying v$asm_disk and v$asm_diskgroup thus hitting an oracle issue, see below
An ASM Rebalance Trace File Constantly Growing While No Rebalance Is Running In ASM (Doc ID 1582990.1)
Per non-bug 15835734:
The problem is that every time the the GPnP profile is queried to find out the discovery string for ASM, that trace information is written in the RBAL trace file for debugging purposes. Therefore every time a query on v$asm_disk or v$asm_diskgroup is executed it will cause the ASM to query the GPnP daemon to find the discovery string for available disks and that's when the debug information is dumped into the RBAL trace.
STATUS:
This issue will be addressed in 8.6.3
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center