Jun 29, 2017

Caché License Key monitoring


One of our Caché database servers stopped working last week. Because, the License key got expired. There was an oversight in checking the License key expiration date.

To avoid any such issues in future, I coded a shell script that runs everyday on Caché database servers and does the following:
       1. Compare License key expiration date with future date (current date + 1 week)
       2. Trigger an email to DBA if the License key expiration date is less than the future date

I'm sure that the Date handling (in the script) could be done in a better way. Still working on improving my scripting skills.
The script as below.

#!/bin/ksh
#coder: Bharath Nunepalli

LICKEY_EXP=/home//lickey_exp
LICKEY_EXP1=/home/lickey_exp1
LICKEY_EXP2=/home/lickey_exp2
LICKEY_EXP3=/home/lickey_exp3
LICKEY_EXP_DATE=/home/lickey_date

timezone=$(date +%Z)
NEXT_WEEK=$(TZ=$timezone-168 date +"%Y%m%d")

csession cache "^CKEY" | grep -i ExpirationDate > $LICKEY_EXP
 cat $LICKEY_EXP | read LINE
  LIC_EXP_DT=$(echo $LINE | awk '{print $3}')

echo $LIC_EXP_DT|awk -F'/' '{ print $1 }' > $LICKEY_EXP1
 cat $LICKEY_EXP1 | read LINE
  LIC_EXP_DT1=$(echo $LINE | awk '{print $1}')
   if (( $LIC_EXP_DT1 < 10 )) then
     LIC_EXP_MON=$(echo "0"$LIC_EXP_DT1)
   fi

echo $LIC_EXP_DT|awk -F'/' '{ print $2 }' > $LICKEY_EXP2
 cat $LICKEY_EXP2 | read LINE
  LIC_EXP_DT2=$(echo $LINE | awk '{print $1}')
   if (( $LIC_EXP_DT2 < 10 )) then
     LIC_EXP_DAY=$(echo "0"$LIC_EXP_DT2)
   fi

echo $LIC_EXP_DT|awk -F'/' '{ print $3 }' > $LICKEY_EXP3
 cat $LICKEY_EXP3 | read LINE
  LIC_EXP_DT3=$(echo $LINE | awk '{print $1}')

echo $LIC_EXP_DT3$LIC_EXP_MON$LIC_EXP_DAY > $LICKEY_EXP_DATE
 cat $LICKEY_EXP_DATE | read LINE
  LIC_EXP_DATE=$(echo $LINE | awk '{print $1}')
  if (( $LIC_EXP_DATE < $NEXT_WEEK )) then
    mail -s "LICENSE KEY ABOUT TO EXPIRE ON $HOSTNAME "  <email ID>
  fi
  else exit
exit

The above script can be coded as below.

#!/bin/ksh
#Coder: Bharath Nunepalli

DB_STATUS=/home/db_status
ccontrol list | grep -i running > $DB_STATUS
if [[ -s $DB_STATUS ]] then
  #collect expiration date from cache
  EXPR_DATE=$(csession cache "^CKEY"|grep -i ExpirationDate|awk '{print $3}'|awk -F'/' '{printf("%d%02d%02d\n",$3,$2,$1)}')
  #get future date
  NEXT_WEEK=$(TZ="$(date +%Z)-168" date "+%Y%m%d")
  # compare date
  if [[ $EXPR_DATE -lt $NEXT_WEEK ]] then
    echo mail -s "LICENSE KEY ABOUT TO EXPIRE ON $HOSTNAME "  <email ID>
    exit 0
   else exit 0
  fi
 else exit 0
fi



Jun 23, 2017

Dropped-object recovery using Recovery Expert for z/OS


Dropped-object recovery is one such activity that no DBA would ever want to happen. Unfortunately, my team faced a dreadful situation recently of recovering 2 dropped databases (total 277 Tablespaces).
We used Recovery Expert for z/OS tool for this activity. This Tool has its own repository/database called Schema-level repository (SLR), holding replica of all DB2 catalog Tables (with some additional columns). Smart thing we are doing is updating the SLR on daily basis (Data from all DB2 catalog Tables will get copied into the SLR), and this helped us a lot in recovering the dropped databases.

There are 2 approaches to perform dropped-object recovery using Recovery Expert for z/OS.
                     1. Log-based recovery
                     2. Standard recovery

1. Log-based recovery: This approach can be used when the SLR is not getting updated on regular basis. 
This approach involves these steps.
a. Select Log based as the Recovery Type in Create Application Profile panel.
b. Select the time window during which the objects got dropped. 
    This will submit a Log analysis job, that searches in logs for the dropped objects.
         
               
c. Once the Log analysis job is completed, dropped objects can be selected into the Application Profile from the LBDR Scanned Log Range created by Log analysis job.
d. Recovery PIT timestamp will be automatically populated by the Tool. Using that, Recovery Plans will be generated.
e. Appropriate Recovery Plan should be selected for building the Recovery JCLs.
            Recovery JCLs have job steps for
            i.   Re-creation of dropped objects (DDLs execution)
            ii.  Recovery
            iii. REBUILD INDEX

2. Standard recovery: This approach can be used when the SLR is getting updated on regular basis.  
This approach involves these steps.
a. Select Standard as the Recovery Type in Create Application Profile panel.
b. Create an Application Profile to add the dropped objects to that (Tool will read the objects' details from SLR as no entries will be present in DB2 catalog Tables).
c. Update the Recovery options, select PIT timestamp and generate the Recovery Plans.
d. The, build the Recovery JCLs.
            Recovery JCLs have job steps for
            i.   Re-creation of dropped objects (DDLs execution)
            ii.  Recovery
            iii. REBUILD INDEX


So, updating SLR regularly makes the dropped-object recovery activity easy.