Monday, October 22, 2018

Steal Percentage on the Virtual Machine

Recently have been working with a customer who was running high workload on virtual machine. After a complete review , DBAs have identified the database is running non optimized codes/sql/programs. During high peak load we observed very high Steal %

Image result for Steal Percentage Top

In a virtual environment, CPU cycles are shared across virtual machines on the server. If your virtual machine displays a high %st in top (steal time), this means CPU cycles are being taken away from your virtual machine to serve other purposes. You may be using more than your share of CPU resources or the physical server may be over-sold. Move the virtual machine to another physical server. If steal time remains high, try giving the virtual machine more CPU resources.

In this case this database was not having any noisy neighbor and it was the same machine fighting against itself. The reason was over-provisioning. The underlying hardware had 48 CPU but virtual machine was over provisioned for 64 CPU.

To resolve the issue , virtual machine was migrated from 48 CPU bare metal to 82 CPU bare metal.

The Steal is gone.

it is highly recommended to have a metric collection on the monitoring tool to have Steal monitored on high workload virtual machines. This will help take action and move environment to have better performance.

Thursday, October 11, 2018

ADOPValidations EBS 12.2

ADOPValidations_detailed.log reported a warning message for one of the critical error "Cross Reference"

ValidateFSConfigFilesForCrossRef:
        [WARNING]: Found invalid cross references in FS config files.

cross reference is nothing but having incorrect values in the context file of EBS 12.2

for example : run file system context file having path of patch file system 


$ echo $CONTEXT_FILE
/prod/inst/fs1/inst/apps/PROD_node1/appl/admin/PROD_node1.xml

$ grep -i fs2 /prod/inst/fs1/inst/apps/PROD_node1/appl/admin/PROD_node1.xml
         /prod/applmgr/fs2
         /prod/applmgr/fs2/EBSapps/comn/adopclone_node1
$
 

$ grep -i fs1 /prod/inst/fs2/inst/apps/PROD_node1/appl/admin/PROD_node1.xml /prod/applmgr/fs1
         /prod/applmgr/fs1/EBSapps/comn/adopclone_node1
         /prod/applmgr/fs2/EBSapps/comn/util/jdk/jre/lib/sparcv9/server:/prod/applmgr/fs2/EBSapps/comn/util/jdk/jre/lib/sparcv9:/prod/applmgr/fs2/EBSapps/appl/pay/12.0.0/vendor/quantum/lib:/prod/applmgr/fs2/FMW_Home/webtier/jdk/jre/lib/sparcv9:/prod/applmgr/fs2/FMW_Home/webtier/jdk/jre/lib/sparcv9/native_threads:/prod/applmgr/fs2/EBSapps/appl/cz/12.0.0/bin64:/prod/applmgr/fs2/EBSapps/appl/sht/12.0.0/lib64:/prod/applmgr/fs1/EBSapps/comn/adopclone_node1/oui/lib/solaris
$

here on the patch file system there is a cross reference which can be very costly mistake if you ignore it. so consider having all validations reviewed.

how to fix it then ....
simple

just update the context file and upload it to the database

$ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer action=upload contextfile= logfile=/tmp/patchctxupload.log

then run ADOP operations...

Popular Posts