Failed to elevate VKTM's priority from 0 to 60 and Failed to elevate LGWR's priority from 0 to 60 on solaris

OS : Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC
Database version : 11.2.0.4

When the Oracle database started, two trace files were noticing my attention :

<SID>_lgwr_9955.trc with contents :
ksesethighpri: (ksb.c:4201) Failed to elevate LGWR's priority from 0 to 60
 Error Info: Category(-2), Opname(skgdism_send), Loc(sp.c:1667), ErrMsg(Not owner) Dism(1024)

<SID>_vktm_9946.trc with contents :
ksesethighpri: (ksb.c:4201) Failed to elevate VKTM's priority from 0 to 60
 Error Info: Category(-2), Opname(skgdism_send), Loc(sp.c:1667), ErrMsg(Not owner) Dism(1024)
 kstmmainvktm: failed in setting elevated priority
 Verify: SETUID is set on ORADISM and restart the instance
 highres_enabled
VKTM running at (100ms) precision
 kstmrmtickcntkeeper: param _dbrm_quantum will not be effective

In found the following bugs on Metalink
19651732 : ON 11204 TRACES KSESETHIGHFAILED TO ELEVATE VKTM'S AND LGWR'S PRIORITY
12951619 : DATABASE TO USE CRITICAL THREADS FEATURE IN SOLARIS. Patch needed 16387058
16605688 : PATCH 16387058 NOT CHANGING LGWR PRIORITY SCHEDULE TO FX
17344824 : LGWR CANNOT GET OS PRIORITY ALTHOUGH PATCH 12951619 APPLIED
17930649 - ORADISM IS IMPROPERLY BUILT  

But they all seemed not related to my database version (11.2.0.4)

The following note was interesting because it recommends to place the LWGR process in the FX scheduling class at priority sixty.

SPARC: Reducing High waits on 'log file sync' on Oracle Solaris SPARC by Increasing Priority of Log Writer (Doc ID 1523164.1)

To do that, the Oracle installer account (oracle) must haven been granted the proc_priocntl role.
I checked the privilege with the following command :
$ppriv -l -v zone|grep prio
and get no result, so apparently user oracle did not have the proper privileges.

Before given the proper privileges I checked the class and priority of the LGWR and VKTM processes :

$ps -ef|grep -i ora_lgwr_<SID>
oracle  9955  9935   0 08:56:56 ?           0:00 ora_lgwr_<SID>
 $ps -ef|grep -i ora_vktm_<SID>
oracle 994699350 08:56:56 ?0:00 ora_vktm_<SID>

$ps -ecl|grep 9955
0 S   1101  9955  9935   TS  59        ? 148354        ? ?           0:00 oracle
$ps -ecl|grep 9946
0 S   1101  9946  9935   TS  59        ? 146788        ? ?           0:00 oracle

There were both running with priority 59 on the timeshare class.

From the global zone the neccessary privileges were given :
global#zonecfg -z userzone
zonecfg:userzone>set limitpriv="default,proc_priocntl"

I checked it on the local with the following command :
$ppriv -l -v zone|grep prio
proc_priocntl
       Allows a process to elevate its priority above its current level.

So the privileges are in place. Just a reboot of the local zone with init 6 needed.

After the local zone and the database were booted I checked the trace files :

For the LWGR there was no trace generated. The tracefile for the VKTM was generated with the following contents :

kstmmainvktm: succeeded in setting elevated priority
 highres_enabled
VKTM running at (1)millisec precision with DBRM quantum (100)ms
 [Start] HighResTick = 742578877597
 kstmrmtickcnt = 0 : ksudbrmseccnt[0] = 1417769168

So setting the elevated priority for the VKTM process succeeded.

Again I checked the class and priority of the LGWR en VKTM processs :
oracle  6246  6236   FX  60        ? 160986        ? 08:43:05 ?           0:00 ora_lgwr_<SID>
oracle  6237  6236   RT 101        ? 159588        ? 08:43:05 ?           0:03 ora_vktm_<SID>

The priority and class for the LGWR changed from 59 and TS to 60 and FX (fixed-priority). For the VKTM it changed from 59 and TS to 101 and RT (real-time).

So the only thing needed was to give the Oracle installer account the neccessary proc_priocntl privilege.

Note :
Hidden parameter "_high_priority_processes" tells Oracle to automatically set background processes to a higher than normal priority when the database is started. For my database the parameter has the following value  :
_high_priority_processes LMS*|LGWR|VKTM                         

So Oracle tried to set the priority for the LWGR and VKTM background processes higher than normal priority. Probably the Oracle installer account needed the proc_priocntrl privilege.

Critical Thread is a new scheduler optimization available in Oracle Solaris releases Solaris 10 Update 10 (8/11) and later versions. From database point of view, logwriter (lgwr) is one such process that can benefit from CT optimization on Solaris platform.

Create userdefined reports in Grid Control

You can define your own reports in Grid Control.

Login as sys on the Grid Repository and execute the following:

SQL> insert into sysman.mgmt_ip_report_elem_def values('target_user_table_from_sql','database_target_type','target_user_table_from_sql',
'oracle.sysman.db.util.reports.TableTargetRenderController',0,NULL,'EM',NULL,
'10.2.0.1.0');

SQL> insert into SYSMAN.MGMT_IP_ELEM_PARAM_CLASSES
(ELEMENT_NAME_NLSID, ELEMENT_TYPE_NLSID, ELEMENT_PARAM_CLASS, DISPLAY_ORDER)
values ('target_user_table_from_sql','database_target_type'
,'oracle.sysman.eml.ip.render.elem.HeaderParamController',1);

SQL> insert into SYSMAN.MGMT_IP_ELEM_PARAM_CLASSES
(ELEMENT_NAME_NLSID, ELEMENT_TYPE_NLSID, ELEMENT_PARAM_CLASS, DISPLAY_ORDER)
values ('target_user_table_from_sql', 'database_target_type', 'oracle.sysman.eml.ip.render.elem.SQLStatementParamController', 2);
sql> Commit;

Once completed, you will get a new report element called "target_user_table_from _sql" on the report page and you will be able to create reports that query target databases.

Reset the Grid Control agent

If you would like to reset the agent and clear all the files do the following :

$AGENT_HOME/bin/emctl stop agent
$rm $AGENT_HOME/sysman/emd/agntstmp.txt
$rm $AGENT_HOME/sysman/emd/lastupld.xml
$rm $AGENT_HOME/sysman/emd/state/*.*
$rm $AGENT_HOME/sysman/emd/upload/*.*
$AGENT_HOME/bin/emctl start agent

Policy evaluation cycle

The following table describes the default evaluation cycles for Grid Control 10g, which will also determine when a violation is cleared :

1.     Configuration Policies:  once every 12 hrs
2.     Storage Policies:  once every 3 days
3.     Object Policies:  once every 12 hrs
4.     Security Policies:  once every day

These intervals are fixed for EM version 10.1.0.
Note that they are tied to the polling frequency of the associated metric.

If you would like to reevaluate the policies right now than perform the following steps :

$cd $AGENT_HOME/bin
$./emctl stop agent
$./emctl start agent
$./emctl clearstate agent
$./emctl upload agent
$./emctl clearstate agent

ypmatch: the domainname hasn't been set on this machine

Metric error received in Grid Control 10.1.0.4.0 view for AIX 5.2 target host: "ypmatch: the domainname hasn't been set on this machine."

The cause of this problem is that "bos.net.nis.client" fileset is installed, but NIS is not configured for use. The existence of this fileset causes the ypmatch command to be used as part of host metric collection, but this command will fail if NIS is not configured for use on the system.

To disable the file give the command: chmod -x /usr/bin/ypmatch, so the command cannot be sent and the error is not generated.