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.

Friday, March 25, 2011

Steps to create auto login of ssh without typing passwords for oracle user in AIX


Ability for ORACLE user to login with ssh to peer RAC instance is a prerequisite for RAC installation. Verify that ssh daemon is configured on node1 and node2 before proceeding with steps listed here. Steps documented here was tested on 2 node RAC cluster on AIX 6.1 with OpenSSH

Perform steps 1, 2 and 3 on node1 and node2

1) cd /home/oracle/.ssh

2) Generate public keys for the oracle user as follows
$ ssh-keygen -t rsa

This will generate a private (id_rsa) and public file (id_rsa.pub)

3) Copy id_rsa.pub to nodename_username.pub format
Example: cp id_rsa.pub node1_oracle.pub

4) Transfer this file to the node2 to which you need to configure auto login with ssh.
So in my case, I transferred it to tstndc02 using sftp

5) Now on node2, execute following steps,
$ cd /home/oracle/.ssh
$ cat node1_oracle.pub node2_oracle.pub >>authorized_keys

6) As we want to perform auto login from both nodes, we need to share authorized_keys which we created in step 5 to node1.
$ scp authorized_keys oracle@node1:/home/oracle/.ssh/

7) Now you should be able to login from node1 to node2 with ssh without password. To complete this process, please test following steps on node1 and node2 and accept the security keys if it prompts (It will ask you only first time)

$ ssh oracle@localhost
$ ssh oracle@node1
$ ssh oracle@node1.domainname.com
$ ssh oracle@node2
$ ssh oracle@node2.domainname.com

Try ssh to localhost, node1, node2, package name etc to make sure all combinations are working without typing password. If you get PNRG is not seeded error, Contact Unix SA and ask him to change permission for /dev/random and /dev/urandom

You could download same document in pdf  from Google Docs. Here is the link

Saturday, March 19, 2011

DBA at Snake Mobile

Please enjoy a blog about an Oracle DBA’s typical day and how he reacts to the issues. Characters and situation in this story are fictitious. If you see any resemblance it is just coincidental and is used for educational purpose.

It was another Thursday morning at Snake Mobile and Oracle DBAs were enjoying Chai with their colleagues at Chandni Chowk CafĂ© in their company Cafeteria. Then all of a sudden Manmeet Singh got a call from his manager, Bothering Gupta about an unhappy email from an end user. He explained that one of the customer report is running slow and he want Singh to look into it.Manmeet started gathering all his tools and sticky notes to take a look at what is happening within the database. He IMed the customer to get details about the job and what time it runs daily. He also enquired about expected run time and last run time. Customer informed him that it use to finish in 30 minutes, but in last 3 days it is taking 1 hr 15 minutes to complete.

Using Oracle Grid Control Manmeet found the sql query and its SQL_ID. The sql was a 170 line complicated query with UNION, left and inner joins with several sub selects and inline views. He grabbed another cup of newly brewed Charbucks Coffee from the coffee machine to get over the shock of this tsunami sql.

He tried to see if this sql has more than 1 execution plan. So he used following sql
SQL > select * from table(dbms_xplan.display_awr('csu1z5zqf7sbc')); -- csu1z5zqf7sbc is the SQL_ID

This query listed details of all execution plans available with plan hash value in a nicely formatted way. He found 3 different execution plans for the above sql. But he is not sure which one is the good one and which one is used by system now. So he need to look at some other view. So some more queries from his arsenal. He need to find SNAP_ID, query execution time, number of records processed

SQL> select a.snap_id,a.begin_interval_time,b.executions_total,b.executions_delta,b.elapsed_time_delta,
round((elapsed_time_delta / 1000 / executions_delta),3) avgelapsetimems,
b.rows_processed_total,b.rows_processed_delta,
round((cpu_time_delta / 1000 / executions_delta),3) avgcputimems
from sys.wrh$_sqlstat b, sys.wrm$_snapshot a
where executions_delta > 0 and a.snap_id = b.snap_id and a.dbid = b.dbid
and b.instance_number=a.instance_number
and sql_id ='csu1z5zqf7sbc' and a.begin_interval_time > sysdate - 10
order by a.snap_id,a.begin_interval_time;

SQL> select distinct dbid, sql_id, plan_hash_value from dba_hist_sql_plan where sql_id='csu1z5zqf7sbc';
DBID SQL_ID PLAN_HASH_VALUE
---------- ------------- ---------------
2797229286 csu1z5zqf7sbc 1007430168
2797229286 csu1z5zqf7sbc 1942751973
2797229286 csu1z5zqf7sbc 3495545440
SQL> select distinct a.snap_id,a.plan_hash_value from sys.wrh$_sql_plan a, v$database b where a.dbid = b.dbid and a.sql_id = 'csu1z5zqf7sbc';
SNAP_ID PLAN_HASH_VALUE
---------- ---------------

16850 1007430168
16970 1942751973
17114 3495545440

SQL> select * from sys.wrm$_snapshot where snap_id in (16850,16970,17114);

SNAP_ID DBID INSTANCE_NUMBER STARTUP_TIME
---------- ---------- --------------- ---------------------------------------------------------------------------
BEGIN_INTERVAL_TIME END_INTERVAL_TIME
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
FLUSH_ELAPSED SNAP_LEVEL STATUS ERROR_COUNT BL_MOVED SNAP_FLAG
--------------------------------------------------------------------------- ---------- ---------- ----------- ---------- ----------
16850 2797229286 1 22-JUL-10 10.56.01.000 PM
07-MAR-11 07.00.15.751 PM 07-MAR-11 08.00.28.204 PM
+00000 00:00:17.8 1 0 0 0 0
16970 2797229286 1 22-JUL-10 10.56.01.000 PM
12-MAR-11 07.00.31.943 PM 12-MAR-11 08.00.44.143 PM
+00000 00:00:15.9 1 0 0 0 0

He noticed that something has changed with statistics for the tables used in this complicated query in last 10 days. He can find current values of statistics from DBA_TABLES view. But what about history. He used following query to find that detail. He decided to use a bind variable in his query as there are 6 separate tables involved in the slow running sql from same schema.

SQL> select a.savtime,a.flags,a.rowcnt,a.blkcnt,a.avgrln,a.samplesize,to_char(a.analyzetime,'DD-MON-YY HH24:MI:SS') as anlzetime from sys.WRI$_OPTSTAT_tab_history a, dba_objects b where a.obj#=b.object_id and b.owner='TCSDBOWNER' and b.object_name='&table_name' order by 1;
Enter value for table_name: EXTRA_FIELD

Hurray, he found a sudden change in ROWCNT value for 2 of the big tables used in the query. That explains the reason for slowness.

BONUS QUESTION: Manmeet Singh is planning to lock table stats with the statistics values which gave him a good execution plan. Will it work and is it a good approach?

Wednesday, March 16, 2011

Transferring table statistics from Instance 1 to Instance 2

Following steps need to be done to transfer statistics of a table from Instance 1 to Instance 2.
  • create stats table
  • export stats to this stats table
  • export newly created stats table
  • transfer export dump file to other server
  • import this dump file
  • import stats from newly imported stats table 
On Instance 1

Step 1) Create stats table
exec dbms_stats.create_stat_table('STSC','STAT_PROCESSSKU_MAR16');
PL/SQL procedure successfully completed.

Step 2) Export stats for a particular table to this stats table
SQL> exec dbms_stats.export_table_stats(ownname =>'STSC',tabname =>'PROCESSSKU',stattab =>'STAT_PROCESSSKU_MAR16',cascade =>true,statown =>'STSC');
PL/SQL procedure successfully completed.

Step 3) Export stats_table using Oracle export
$ exp / file=exp_stsc_processsku_stats_from_pjda1.dmp tables=STSC.STAT_PROCESSSKU_MAR16 log= exp_stsc_processsku_stats_from_pjda1.log

On Instance 2
Step 1) Create stats table
SQL> exec dbms_stats.create_stat_table('STSC','STAT_PROCESSSKU_MAR15');
PL/SQL procedure successfully completed

Step 2) Export stats for a particular table to this stats table
SQL> exec dbms_stats.export_table_stats(ownname =>'STSC',tabname =>'PROCESSSKU',stattab =>'STAT_PROCESSSKU_MAR15',cascade =>true,statown =>'STSC');
PL/SQL procedure successfully completed.

Step 3) Export stats_table using Oracle export (Optional , just for additional backup)
$ exp / file=exp_stsc_processsku_stats_from_qjda1.dmp tables=STSC.STAT_PROCESSSKU_MAR15 log= exp_stsc_processsku_stats_from_qjda1.log
Export: Release 10.2.0.4.0 - Production on Wed Mar 16 10:24:29 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses AL32UTF8 character set (possible charset conversion)

About to export specified tables via Conventional Path ...
Current user changed to STSC
. . exporting table STAT_PROCESSSKU_MAR15 19 rows exported
Export terminated successfully without warnings.

Step 4) Transfer exp_stsc_processsku_stats_from_pjda1.dmp file from Instance 1 to Instance 2 for import in Instance 2

Step 5) Import stats table from pjda1 using imp command in Instance 2
$ imp / file=exp_stsc_processsku_stats_from_pjda1.dmp full=y log=imp_stsc_processsku_stats_from_pjda1.log

Step 6) Unlock schema stats if it is already locked (Optional. In my case needed)
SQL> exec DBMS_STATS.UNLOCK_SCHEMA_STATS(ownname => 'STSC');
PL/SQL procedure successfully completed.

Step 7) Import stats for STSC.PROCESSSKU table and its index from STSC.STAT_PROCESSSKU_MAR16 stats table
SQL> exec dbms_stats.import_table_stats(ownname =>'STSC',tabname =>'PROCESSSKU',stattab =>'STAT_PROCESSSKU_MAR16',cascade =>true,statown =>'STSC');
PL/SQL procedure successfully completed.

Step 8) Lock schema stats again
SQL> exec DBMS_STATS.LOCK_SCHEMA_STATS(ownname => 'STSC'); (Again optional in your case)
PL/SQL procedure successfully completed.