February 2011

February 15, 2011 There is an interesting problem in the ERP platform that I support.  When production floor workers begin working on a particular job, the employee “clocks into” the job in the computer system.  When production floor workers stop working on a particular job, the employee “clock out of” the job in the computer [...]

Sometimes I get questions as to whether Pythian is one of the competitors battling with Oracle for MySQL support. The answer lies in the distinction of product support and operational support.

At Pythian, we are laser focused on supporting applications and data infrastructure using Oracle, MySQL and Microsoft SQL Server products. A vast majority of our Oracle customers (there are few customers who have very old 7.x and 8.x products running without vendor support) have Oracle maintenance subscriptions that include product updates and product support. Product support entitles the customer to open support requests when the product doesn’t perform according to the specifications (bug reports) as well as fill in enhancement requests. It also covers deployment blue-prints and deployment guidelines in the official vendor documentation and support database.

What you can’t expect from product support are answers to questions like these:

• How do I architect my infrastructure?
• How much CPU do I need to run this database
• How do I setup my backups?
• How do I tune that SQL statement?
• What I need to monitor in my environment to keep it healthy and avoid service outages?

Of course you cannot expect product support to login to your systems and help monitor them, recover a corrupted database or resolve performance issues etc.

Oracle customers usually have clear understanding of the differences between product support and operations support and consulting that Pythian provides. Even then, every now and again we hear rare statements like “I’m not renewing our Oracle product support because we now have you, Pythian, supporting our databases.” Hearing that, we’re catching our breath for few seconds and then patiently explain that this is inadvisable and the product support is totally different from what Pythian does.

Because of its open-source nature, MySQL database customers have somewhat less incentive to sign up for product support relying on public community releases and the ability to patch the product themselves but even then there is a clear distinction between product support and operational support.

All that was a long prelude to answering the question — “Is Pythian Competing with Oracle and other vendors for MySQL product support”? The answer is NO — Pythian provides plan, deploy, manage services — we analyze, design, implement and maintain the infrastructure. We are working with the vendor providing product support (or as part of the community at large when it comes to the open-source community MySQL releases).

I had an error message today from one of my grid agents which was cut short in the GUI just when it became interesting. So I thought of a way of running the command on the comand line to get the full output.

This has been a little easier than I thought. I based my approach on an earlier blog article on my knowledgebase to get the perl environment variables set. I then needed to figure out where some of the libraries (perl scripts ending in *.pm) the agent script are referring were located.

A simple “locate -i *pm | grep $ORACLE_HOME” did it. This enabled me to write a preliminary script to run an EM agent task, shown below. It expects that you have ran “oraenv” previously to set the environment to the AGENT_HOME. When referring to ORACLE_HOME in the following, the AGENT_HOME is meant. It takes the full parameter to the script to be executed as the parameter and checked for ORACLE_HOME and $1 to exist.

#!/bin/bash

if [ "${ORACLE_HOME}" == "" ]; then
echo "Need to specify the ORACLE_HOME first!"
exit 1
fi

if [ "$1" == "" ]; then
echo "Need to specify the full path to the script to run"
exit 1;
fi

LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

PERLBIN=$ORACLE_HOME/perl/bin/perl
PERLV=`${PERLBIN} -e 'printf "%vd", $^V'`

PERLINC="-I ${ORACLE_HOME}/perl/lib/${PERLV}"
PERLINC="${PERLINC} -I ${ORACLE_HOME}/perl/lib/site_perl/${PERLV}"
PERLINC="${PERLINC} -I ${ORACLE_HOME}/lib"
PERLINC="${PERLINC} -I $ORACLE_HOME/sysman/admin/scripts/"

RUNTHIS="${PERLBIN} ${PERLINC} $1"

exec ${RUNTHIS}

This allowed me to run the script crs_status.pl – $ORACLE_HOME/sysman/admin/scripts/ without problem.