Tuesday, April 26, 2011

Chitti aa gayi (Letter Came)

Finally much awaited letter came in the mail and set rest to the rumors floating around coffee rooms and drive ways in my office. It gave me realistic picture of where I stand now and how valuable is me as an Oracle DBA for a company.

At least it is good in one aspect. My dad worked for just one employer for more than 38 years till his retirement. He was loyal to the employer and did not digest when I use to tell him that I don’t feel what I am doing now and I want to change company. Things have changed lot in last 20 years and now no one work for any employer for an average of more than 5 years. They learn new things, gain experience and move on for a better career. What I noticed is that only those people succeeds in their professional life. Others just stay in the same place for years, do same thing over and over and don’t really learn any new tools  and don’t have the mindset at least to try something new. We could argue that it is because of Inertia (remember old Newton) or H1 and Green Card dream.  What I am saying is that it is not late to learn new things and try to be at the cutting edge. Spend at least 1 hour every day on learning 11gR2 new features and we won’t regret when it is time to look for another job. No one want to hire a regular DBA who knows only basic 10g and no programming or project/people management experience.

“Uthishtatha jagratha praapyavaraan nibodhata!!” - meaning  “Arise , awake and stop not till the Goal is Reached.” - Mundakoupanishad

Tuesday, April 19, 2011

Upgrading stats table after database is migrated to Oracle 11gR2

Sometimes we keep statistics for some application tables in a stats table for importing it later. You might get following error if your database has been upgraded to Oracle 11gR2 and you try to perform import of stats table

--  Import stats for HELPER_TABLE table from HELPER_TABLE_STATS table
exec dbms_stats.import_table_stats(ownname =>'ETRADM',tabname =>'HELPER_TABLE',stattab =>'HELPER_TABLE_STATS',cascade =>true,statown =>'ETRADM');

I receieved following error.
SQL> exec dbms_stats.import_table_stats(ownname =>'ETRADM',tabname =>'HELPER_TABLE',stattab =>'HELPER_TABLE_STATS',cascade =>true,statown =>'ETRADM');
BEGIN dbms_stats.import_table_stats(ownname =>'ETRADM',tabname =>'HELPER_TABLE',stattab =>'HELPER_TABLE_STATS',cascade =>true,statown =>'ETRADM'); END;

*
ERROR at line 1:
ORA-20002: Version of statistics table ETRADM.HELPER_TABLE_STATS is too old.  Please try upgrading it with dbms_stats.upgrade_stat_table
ORA-06512: at "SYS.DBMS_STATS", line 11013
ORA-06512: at "SYS.DBMS_STATS", line 12396
ORA-06512: at line 1

Here is the fix. We need to upgrade stats table to Oracle 11gR2 format

SQL> exec dbms_stats.upgrade_stat_table('ETRADM','HELPER_TABLE_STATS');
PL/SQL procedure successfully completed.

SQL> exec dbms_stats.import_table_stats(ownname =>'ETRADM',tabname =>'HELPER_TABLE',stattab =>'HELPER_TABLE_STATS',cascade =>true,statown =>'ETRADM');
PL/SQL procedure successfully completed.

Friday, April 8, 2011

Don't ignore NLS and NLS_LANG

I would like to share an interesting finding about effect of NLS and NLS_LANG on performance which I learned recently. I don’t know if Database administrators and developers really pay attention to some of the environmental variables like NLS_LANG and NLS. NLS_LANG variable tell Oracle what character set the client is using so that Oracle server could do conversion while sending and receiving data from Oracle client tools. This is different from any server parameter setting. I believe you could have a different NLS_LANG setting on client side when compared with server end and it should not affect performance (Some one needs to validate). NLS environmental variable is used for native language support. Setting it in the client helps the terminal to display correct character set which you could read.

We could query NLS_DATABASE_PARAMETERS settings in database to find database settings.
select * from NLS_DATABASE_PARAMETERS where parameter in ('NLS_LANGUAGE','NLS_CHARACTERSET');

PARAMETER                 VALUE
------------------------- -----------------------------------
NLS_LANGUAGE              AMERICAN
NLS_CHARACTERSET          AL32UTF8

And here are the values I had for client
[oracle@tstxxc03:/home/oracle] $ echo $LANG
en_US.ISO8859-1
[oracle@tstxxc03:/home/oracle] $ echo $NLS_LANG
AMERICAN_AMERICA.WE8ISO8859P1

The rule is that you should have matching values for NLS_LANG and LANG variables. OS host needs to spend considerable amount of time converting characters from one character set to another character set and it could add significant run times to your batch script and CPU load to the host.

I tested this behavior in QJDA1 instance which is used by JDA application and used following script
-- This script is used to check CPU utilization of Oracle processes when run from multiple windows
-- Used by Madhu K Nair 11/05/2010
-- Checking STSC.DFUTOSKU table
set heading off
set linesize 10000
set recsep off
set echo off
set termout off
set trimspool on
set serveroutput off
set feedback off
set pages 0
set time on timing on
spool /backup/qjda1/exp/dfutosku1.lst;

select 'DMDUNIT'||'||'||'DMDGROUP'||'||'||'DFULOC'||'||'||'ITEM'||'||'||'SKULOC'||'||'||'ALLOCFACTOR'||'||'||'CONVFACTOR'||'||'|| 'EFF'||'||'||'DISC'||'||'||'FCSTTYPE'||'||'||'HISTTYPE'||'||'||'MODEL'||'||'||'SUPERSEDESW'||'||'||'FF_TRIGGER_CONTROL' from dual;

select /*+ PARALLEL (d, 4) */ DMDUNIT||'||'||DMDGROUP||'||'||DFULOC||'||'||ITEM||'||'||SKULOC||'||'||ALLOCFACTOR ||'||'||CONVFACTOR||'||'|| EFF||'||'||DISC||'||'||FCSTTYPE||'||'||HISTTYPE||'||'||MODEL||'||'||SUPERSEDESW|| '||'||FF_TRIGGER_CONTROL from stsc.dfutosku d;
spool off;

Above script took 53:24 seconds to finish with mismatched setting and only 7:24 seconds with correct NLS settings.

## Below 2 lines are the original one which was causing high CPU and long run times
#export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
#export LANG=en_US.ISO8859-1
## Below 2 lines are the  modified one which should improve run times
export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
export LANG=en_US.ISO8859-1

Let me thank Israel Anandan again for finding out this mismatch and advising me ways to fix it. I urge all of you to verify these environmental variables in your systems for any potential issues.

Cloning Oracle Binary in Oracle 11gR2

I get several questions even from my collegues about installing Oracle 11gR2 binaries for a stand alone database instance. So I created a pdf document. Cloning software will help you to install Oracle binary with all customized patches/PSU etc in less than 15 minutes. No need to work on X-Window and navigate through several Oracle installation screens and make costly configuration mistakes. I used IBM AIX for testing these steps. But will work in HP-UX and Solaris if source and target are same Operating system. Please note that you cannot clone Oracle binary from one OS to another one. You also need to make sure that you followed Oracle’s prerequisites for kernel settings, memory, swap, file system and TEMP space needed. You can download entire document from this link.