Don't be an ORTHODOX DBA

Most of the times we DBA's take on the developers like underdogs , even I used to but things have changed as my years of experience in the industry is growing by , Every person is equally important right from the application developers, DB developers, Network Administrator.... to DBA's . Anyone one role in the Software life Cycle is neglected , the whole application gets affected

I myself have neglected DB Development like creating procedures . Recently , very recently I happened to create some custom stored procedures which will help the DBA's , they save a lot of time

Ill discuss one case I have come across , I usually use the google drive to store my documents where in I store all my custom administrative queries I use daily

I use to copy paste the respective query depending on my need , because all the time you don't have sufficient time to write the query every time , say a tablespace DMS container size is full for some reason and you need to EXTEND it immediately , You cannot frame the query at that peak time which will be time consuming as every second counts

One day there came a issue and I don't have my laptop on hand , so connected through my other colleagues system where in I cannot access my google drive as I'm already connected to VPN , by the time I framed the query and issued the command some transactions in the application got affected

I then started thinking after resolving this issue as to how can I save this time I have wasted in framing my query at that peak time which made to go through basics of STORED PROCEDURES and yes they really help me a lot

Friendship between REORG and Temp Tablespace's - Part2

In my previous post we have discussed about REORG utility and some monitoring utilities for REORG

Friendship between REORG and Temp Tablespace's

Normally when you issue a REORG on a table like one below

REORG TABLE DB2INST1.EMPLOYEE

db2 does the reorganization of the table in the same tablespace it is residing on ,which is not a good thing always , especially when your data is growing there is no sense in doing reorg in the same tablespace and disturbing the other physical objects like tables and MQT's performance

That is where system temporary tablespaces save us from the performance degradations while REORG

So how do we achieve this ? , we create separate bufferpools for all different page sizes i.e., 4K, 8K, 16K, 32K

Friendship between REORG and Temp Tablespace's

Let us look into what db2 does when a traditional classic offline REORG on a table is issued

When you issue the REORG TABLE DB2INST1.EMPLOYEE the table EMPLOYEE will go through the following phases shown in the image

reorg phases

Let's go through what actually is happening in these phases


3 key Areas never to miss in InformationCenter .

People Wonder a new version of db2 is released , what are the new features , how will i know these features ?

Now say the documentation or Information center for the product have been released , So where to look first in that documentation to know the new features .

3 sections to look-in first :


Basic Shell command to make ourselves comfortable at all times - Part 2


Welcome to the Part 2 of this series , We have discussed about grep,ls,awk,find in my last post

Basic Shell command to make ourselves comfortable at all times


In this post we are gonna see some crontab and vi editor options.

Crontab :


Crontab is a utility provided by linux to schedule jobs or scripts , Like if you want to run a job every morning 8:00 am , you can do this with the crontab utility
dbadm@linux122:~> crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.XXXX7mwgtU installed on Tue Nov 12 17:53:36 2013)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)

####   BACKUPS

01 01 * * * /home/DB_BKPS/scripts/sample1_backup.sh
01 02 * * * /home/DB_BKPS/scripts/sample2_backup.sh

Basic Shell command to make ourselves comfortable at all times


People might wonder why i need to learn a scripting language , if i am a hardcore DBA , let me tell you , if you are in the administration side of your career you cannot avoid these scripting languages. Whether it might be a

Shell Scripting
Perl Scripting
Batch Scripting

These should become the primary skill in par Database Administration

If you work on linux server make sure you are good with at these least basics of Shell commands

If you work on windows machine you should be comfortable with Batch scripting

And Perl , this is a friend of all , The moment you make yourself comfortable with Perl , you break the environment barriers doesn't matter which machine you work on , Perl is supported almost in all the Platforms

Keeping apart Perl as this post is to discuss some basic and common commands to grip yourself while working on Linux environment

Shell Basic Commands :
  • grep
  • ls,ls -lrt
  • find
  • awk
  • sed
  • crontab
  • vi editor

DB2 Partitioned Tables - Life made easy - Part 3

So all we are going to see in this post is some left-outs from the last 2 posts from this series

Please refer to my previous posts
DB2 Partitioned Tables - Life made easy - Part 1 &
DB2 Partitioned Tables - Life made easy - Part 2 to catch up this series .

Nevertheless of our discussions in previous posts we have seen the partition's being attached and detached from the base partitioned table (i.e., DB2INST1.PARTBLE), You can also do this Roll-In of data from the other tables also .

ALTER TABLE DB2INST1.PARTBLE
   ATTACH PARTITION PART JAN15 
   STARTING '1/1/2015' 
   ENDING '3/31/2015' IN TBSP2
FROM TABLE DB2INST1.EMPLOYEE


DB2 Partitioned Tables - Life made easy - Part 2

Continuing from my first post of this series DB2 Partitioned Tables - Life made easy - Part 1

Go through that post to get an idea of the table structure created and partitions used in this exercise .

We now go through some workout examples of the following categories

  1. Attaching a partition
  2. Detaching a partition
  3. Roll in a partition
  4. Roll out a partition 
Detaching / Roll out a partition : 

DB2 Partitioned Tables - Life made easy - Part 1

Why partitioned tables ???

Well this cannot be said in a single statement

  • It makes the DBA's life lot more easier ?
Sure it does , If you are a DBA and you opted partitioned table , you need not worry of the purging activity . If the data is growing beyond your foresight , decided to keep only 3 or 6 or 9 months of active data in table and you have partitioned your table , simply detach the old partition and you are done .
  • Query will be processed faster than ever
Obviously , Say you have a table partitioned for every 3 months and same table without any partitions , Now both the tables have 30 million records , in the latter db2 has to scan all the table to get your result whereas in the former db2 has an advantage to take of every 3 months split , Once you update the statistics db2 goes directly to that respective 3 months slot and collects the data . So how large the table , its only 3 months data for db2 .