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 %



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.

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...

Golden Gate moving from Classic to Integrated

Golden Gate moving from Classic to Integrated was an option taken in one of our project to have better performance. A lot of effort was put to convert all the extract and replicate to Integrated mode and some optimization parameters were used but still there were not a significant performance improvement.

Then I took a different route to examine the AWR and ASH for the replicate processes. Wow our friend INDEXES. Since we were dealing with build load , some of the unwanted indexes were dropped and Golgen Gate was super fast. Both Integrated and Classic was having better performance. Post the build load we rebuild the indexes.

Better consult a Dr.DBA always.